We have 5231 guests and 11 members online
Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
 Recent history has ushered in the postmodern era in all its fragmented glory. With its arrival comes the displacement of the absolute, the certain, and all that characterizes the modern age. Along with changes in art, politics, and philosophy— there are reverberations in business and technology. The societal shift from Modernism to Postmodernism mirrors and reinforces a shift in software development from traditional waterfall to non-linear Agile methods. The use of rational thought has come to be a foundation of society. The belief in reason as a source of knowledge has enabled democracy and capitalism to advance our civilization into what we call the Modern age. With this comes a sense of hopefulness for the future and the idea that through science and our increasing knowledge of the world, we can solve any problem. However, more and more we are finding a single interpretation of the world to be untenable. Knowledge is spontaneous, subjective, and varies with its interpreter. Postmodernism challenges the Enlightenment ideal of rationalism in favor of plurality and indeterminacy (Best and Kellner 1991: p. 4). Universal grand narratives are abandoned in favor of personal truths garnered through discourse. The philosophy of postmodernism as compared to that of modernism provides a useful perspective from which we can better understand changes in business and technology management including software development. The archetypal development process, typically identified as the Waterfall method, involves a highly structured series of gates that must be completed before progressing through each stage. All design work must be completed before construction and construction before implementation. These controls are appropriate for certain types of projects such as the design and construction of a bridge, though variations are commonly used in the less constrained areas of manufacturing and project management. Unlike building bridges, creating software is a process of transforming ideas into code. Inputs to the software creation process are not raw materials, but user requirements. The relative flexibility of software requirements allows for frequent design changes and even revisions to the method of construction. The transient nature of business rewards agility for its ability to capitalize on new information. The rigidity of the traditional engineering approach is restrictive to changes in requirements and does not allow for change to the process itself. Another issue that prevents Waterfall from being successful in software development and other forms of new product development is the inability of stakeholders to understand and convey what they need in a software application before ever having seen or used it. The ability to develop personal and group understanding of product requirements is something more easily established over time through team collaboration in place of upfront design and documentation. Postmodernism reduces truths to individual interactions through language. The French philosopher Jean-Francois Lyotard drew upon the concept of knowledge as language-games to represent the shift from grand narratives to localized narratives (Lyotard 1979). From this perspective we see that a single system design cannot constitute a basis for universal understanding. Each individual must take part in the creation of that understanding for it to be effective. The first, and arguably the most important, canon in the Agile Manifesto supports this view as it advocates “Individuals and interactions over processes and tools” (Agilemanifesto.org). A function of Agile software development is to use short iterations of development to prototype software early and often. With each iteration, the product sponsor and development team review progress and move towards a common understanding. This is a significant difference from the linear steps of the waterfall method. Waterfall works on the premise that a complete understanding of the end state is known from the start of development, the end state is articulated in objective language, and the team can interpret the requirements just as the sponsor intends. From the postmodern perspective, language has no inherent structure and thus is unable to directly convey information. In a postmodern world there can be multiple understandings; none are privileged above the rest (Hassard 1999: p. 172). The reliance on a packaged, universal understanding destines Waterfall to produce software that does not meet customers’ expectations. In addition to the use of a “ubiquitous language” that keeps developers centered on a common understanding, Agile teams are self-organized and strive to keep individuals cross functional. This aids in adaptability, but also in keeping the team hierarchically flat. Postmodernism eschews vertical management in its tendency to create bureaucracy and centralize decision-making. Empowered teams that have authority to make decisions are not only better able to adapt, but also are more satisfied in creating something they co-own. In the traditional approach to project planning, all tasks including product delivery are given specific dates for completion, leading managers to add buffer periods to work estimates to ensure they come in on or ahead of schedule. The farther out the plan, the more uncertainty and padding included. This cycle highlights the inability of project leads or senior management to accurately estimate new product development. Agile’s approach of planning only the next iteration of development meets long-term targets by adjusting functionality and scope. This breaks the need to overestimate by the development team and helps prevent overwork in the period leading up to a major release. One of the reasons iterative development can accomplish this is because each iteration provides a fully functional and tested version of the system that can be deployed to the end user. At any point a client can decide that the software is done, removing the fear that a deadline will be missed. While Agile can help teams solve some of the problems with the waterfall method, it is not a silver bullet. It is important to note that the Agile movement does not advocate the replacement of an old process for a new one. Agile represents a set of methods that enable iterative development, but more fundamentally Agile is about adapting to change. No single prescription exists for the best way to develop software, but many localized methods that have strengths and weaknesses relative to each project and team. Processes can be tuned for specific goals in a changing environment. Each process step should add value and if not it should be dropped. Through empirical observation, what works should be favored over any idealized method. It would be a betrayal of postmodernism to support a new paradigm as rigid as the paradigm it replaced. In business and in life, we strive to minimize unknowns. Many of us go out of our way to avoid situations with unexpected or uncontrollable outcomes. We strive for predictable, controllable results. This risk-averse view might explain why many managers still rely on detailed project plans to estimate and manage software development. The details in the plan provide a sense of security in the future and a foundation of knowledge to build from, even if the details are nothing more than a comforting illusion. The opposite of a strict plan, total anarchy is not a good approach to management, though it is probably closer to reality. Without having to completely abandon project plans, understanding the gaps in our knowledge and where planning is not effective can help us better manage expectations. Going one step further and factoring in change will better reflect the true nature of business and allow a team to adapt as needed. The belief in knowable truths, more than anything else, signifies the modern age. As we move into the future, technology presents us with a more dynamic environment that will force us to question prior assumptions. If we believe in the philosophy of postmodernism, we should also trust in the philosophy of Agile software development. Reducing the constraints of process dogma, iterative and nonlinear management can help teams produce higher quality products and better respond to change. Beyond software, the postmodern lens can help us better understand the discontinuous world in which we live. The strong links between Agile and postmodernism provide a backdrop for the success of Agile development while giving us a practical application to help us cope with a new de-structured world. References Best, Steven, and Douglas Kellner. Postmodern Theory Critical Investigations. New York: The Guilford P, 1991. Hassard, John. "Postmodernism, philosophy and management: concepts and controversies.” International Journal Management Review June (1999): 171-95. Lyotard, Jean-Francois. “Introduction:The Postmodern Condition: A Report on Knowledge," 1979: xxiv-xxv. About the Author Ryan Fogarty works in New York City managing development processes, standards, and tools in the financial services industry. Ryan received his B.S. in Computer Science from Stevens Institute of Technology.
Set as favorite
Bookmark
Email this
Hits: 2889 Trackback(0)Comments (9)
|
| Last Updated on Tuesday, 07 July 2009 13:04 |
TrackBack URI for this entry
Show/hide comment form
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper