Model-Based Systems Design - Essay Example

AGILE In comparison to model-based methodologies, agile methodology is more about teamwork and communication than it is about fixed rules, fixed roles, and a linear model of project progression and completion. It is a fairly recent development. “In 2005, a group headed by Alistair Cockburn and Jim Highsmith wrote an addendum of project management principles, the Declaration of Interdependence, to guide software project management according to agile development methods” (Waterfall, 2010). The approach that comes from agile methods is an approach to motivating and coordinating employees that is rather loose and informal. It operates in an open system, in alignment with theories of leadership, and tends to focus less on positional leadership, planning, and formulated strategy in the organization, and more on the open communication between individuals. Agile methods may be more likely to foster open systems type communication than model-based systems, because agile methods rely less on rules and codes of authority. Compared to model-based methods, agile methods could most clearly demonstrate the role of the project manager within the organization, because they are let go to coordinate activities and build teams according to their own creative standards and communication patterns after the rational career development training. “In contrast to the rational-model approach, this area focuses on variables not subject to complete control by the organization and hence not contained within a closed system of logic. It is also clear that students regard interdependence of organization and environment as inevitable or natural, and as adaptive of functional” (Thompson, 2003). The complexity of today’s companies and industries in general also affects motivational levels and how they can be applied to the organization through structural theory. In model-based methods, “The complexity, if fully faced, would overwhelm the organization, hence it must set limits to its definitions of situations it must make decisions in bounded rationality. This requirement involves replacing the maximum-efficiency criterion with one of satisfactory accomplishment, decision making now involving satisficing rather than maximizing (Simon)” (Thompson, 2003). This complexity tends to increase the more the structure is geared towards rationalizing model-based operations, especially in the face of new technological developments macrocosmically. Therefore, there is also perhaps a difference between model-based and agile methods, when it comes to the technology level being employed. Judging by the use of agile methods, positive results can also be seen in the organization in terms of motivation. The perspective of change engendered by the new programs and activities using agile methods draws on knowledge that is also aligned with the open systems perspective. This perspective is not very keen on pointing out the benefits of rational structure in the organization, and rather is more interested, like the open systems agile method perspective, on looking at developmental happenings in the organization moving organically without too much, but with just enough, focus on rules and regulations as well as the bureaucracy of the organization. “One of the main contributions of the open systems perspective is the recognition that many systems—especially social systems—contain elements that are only weakly connected to others and that are capable of fairly autonomous actions” (Thompson, 2003, p. 89). The design choices may be appropriate to give a sort of order to the chaos of complete autonomy, and they seem to have been effective. In other words, model based and agile methods may exist together. In an open system like agile methods, there is more room for change and dynamism than in a traditional model-based system. “There are two types of systems: closed and open. A closed system limits in its interactions with its environments… producing standardized products in an uninterrupted stream. An open system interacts with the external environment” (Hellriegel et al., 2005). There may be different effects depending on the environment, such as a programming environment whether it is at peace after a product launch or planning for a deadline. Agile methods put less emphasis on the deadline, and more on the final product. In today’s business, the formally designated authority structure (model-based system) may place someone in charge of a group or in charge of leading and training either employees or soldiers who does not actually have a lot of real creative ability in terms of leadership, and whose leadership is primarily based on the rational assumptions of positional leadership. Sources also value positional leadership and other leadership styles which may be considered by some to be exclusive or inclusive depending on one’s definition. In one classical definition that seems tradition-based, authors state, “we have tried to set out some of the elements of a classical view of leadership. We have seen how commentators have searched for special traits.. Running through much of this is a set of beliefs that we can describe as a classical view… identified by position… become the focus for answers and solutions… give direction and have vision… have special qualities setting them apart” (Hellreigel and Slocum, 2005). This is as true in the planning situation as it is in the business, where employees often feel more motivated and inspired if they are under a dynamic manager with good leadership skills, who can give the unit or team direction through example. This type of manager can exist under agile or model-based systems. Using agile methods, the software itself is the product, and this represents “Close, daily cooperation between businesspeople and developers, as well as the assumption that face-to-face conversation is the best form of communication (co-location). Projects are built around motivated individuals, who should be trusted, and continuous attention to technical excellence and good design is used” (Waterfall, 2010). Agile methodology was designed to make the process of development more simple, more well-organized, and more based on principles of teamwork and adaptation. To accomplish this goal, “Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning” (Waterfall, 2010). In the swiftly changing IT filed, an adaptive method is needed, but a competing ideology is also ineffective. For programmers and engineers in this field to be successful, they need to work together on integrative teams, and agile methodology is helping them to do this more efficiently. Rational systems theory, when aligned with these theories of leadership mentioned above that tend to polarize leaders as either positional or creative strays to the positional side of the equation. In this paradigm, planning, strategy, and positional authority is exemplified. “In its established usage, a paradigm is an accepted model or pattern, and that aspect of its meaning has enabled me, lacking a better word, to appropriate paradigm here… like an accepted judicial decision in the common law, it is an object for further articulation and specification under new or more stringent conditions” (Hellreigel and Slocum, 2005). The limitations of paradigm unsteadiness are shown in the actual example from the business to the planner as well, because it is very ineffective to state that just because someone is occupying a place of positional authority, they are somehow automatically less of a leader. This provides problems of open systems agile theory, in alignment with model based theories, tends to focus less on positional leadership, planning, and formulated strategy in the organization, and more on the open communication between individuals. This open communication could most clearly demonstrate the role of the programmer or the employee within the organization, because they are, as mentioned above, let go to interpret directives according to their own creative standards and communication patterns after the rational training, in agile method application. Agile systems also looks at the organization or workplace as a social sphere, and this can also be applied to the difference between agile and rational-based model-based objectives. A rational decision-making model assumes and predicts faultless conditions in the organizational or programming environment for decision-making in the first place, but irrational decision-making in the agile systems environment makes no such base assumptions, and therefore accounts more for the chaos and uncertainty that often plague organizational decision-makers as well as programmers who have to make decisions to which there are obstacles. It is a matter of “Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan” (Agile, 2010). By focusing exclusively on the customer, agile methods also hope to drive the industry towards a more responsive paradigm, where it is not just engineers and programmers competing with each other to meet deadlines, but rather a more timeless structure in which programmers and engineers are not afraid to make changes as a project nears its completion. There is a lot of positive reflection of agile methods in existing literature, but since it is a relatively new method, the challenge of the future remains. Organizing a plan requires honing it down and making it workable, and only effective decision-makers who are schooled in the ability to lead positively will be able to make the necessary negations, additions, and alterations that are brought about as the plan begins to enter a real-world frame during the organization process. It is also important at this level to keep a balance of creative solutions and reasonable solutions. Creativity is a great tool when a problem comes up that seems insurmountable through conventional methods and requires thinking outside the box for an effective plan of implementation. But conventional thinking is also important because it represents the status quo to which many other organizations subscribe and which the public may expect. Therefore, a sense of balance is key as the project is eased from the theoretical to the practical sphere by an effective leader who is able to make decisions and take control, as well as accepting responsibilities for their decisions in the context that they are capable of providing relevant leadership. In my personal managerial philosophy, effective leadership is not just about the bottom line, but is also about fostering teamwork. Whether using agile or traditional model-based methods, teamwork and leadership are still integral, and will bring teams to the next level. REFERENCE Hellriegel and Slocum (2005). Management. New York: Pearson. Thompson, J. (2003). Organizations in Action. New Brunswick: Transaction Publishers. Agile development (2010) http://blogs.techrepublic.com.com/programming-and-development/?p=1064 Waterfall vs. Agile (2010). http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/ Read More