Often posed as an alternative way to develop systems, the agile approach seeks to address common complaints arising over the traditional SDLC approach (for being too time-consuming, focusing on data rather than on humans, and being too costly) by being rapid, iterative, flexible, and participative in responding to changing human information requirements, business conditions, and environments.
Several agile development projects have been chronicled in books, articles, and on Web sites. Many of them were successes, some have been failures, but we can learn a great deal from studying them, as well as the agile values, principles, and core practices. Following are the six major lessons we draw from our examination of agile modeling. Figure illustrated below depicts the six lessons.
The first lesson is that short releases allow systems to evolve. Product updates are made often, and changes are incorporated quickly. In this way the system is permitted to grow and expand in ways that the customer finds useful. Through the use of short releases, the development team compresses the time between releases of their product, improving the product later as the dynamic situation demands.
The second lesson is that pair programming enhances overall quality. Although pair programming is controversial, it clearly fosters other positive activities necessary in systems development such as good communication, identifying with the customer, focusing on the most valuable aspects of the project first, testing all code as it is developed, and integrating the new code after it successfully passes its tests.
The third lesson is that onsite customers are mutually beneficial to the business and the agile development team. Customers serve as a ready reference and reality check, and the focus of the system design will always be maintained via their presence: customers become more like developers and developers empathize more fully with customers.
The fourth lesson we take from the agile approach is that the 40-hour workweek improves effectiveness. Even the hardest-hitting developers are susceptible to errors and burnout if they work too hard for too long a period. When the development team is together, however, every moment counts. Working at a sustainable pace is much more desirable for the life of the project, the life of the system, and the life of the developer! We all know the parable of the hare and the tortoise.
The fifth lesson we draw from taking the agile approach is that balanced resources and activities support project goals. Managing a project doesn’t mean simply getting all resources and tasks together. It also means that the analyst is faced with a number of trade-offs. Sometimes cost may be predetermined, at other junctures time may be the most important factor. The resource control variables of time, cost, quality, and scope need to be properly balanced with the activities of coding, designing, testing, and listening.
The last lesson we take from agile modeling approaches is that agile values are crucial to success. It is essential to the overall success of the project that analysts wholeheartedly embrace the values of communication, simplicity, feedback, and courage in all the work that they do. This type of personal and team commitment enables the analyst to succeed where others, who possess similar technical competencies but who lack values, will fail. True dedication to these values is fundamental to successful development.
Contents
- Prototyping: Kinds of Prototypes
- Developing a Prototype: Guidelines
- Users’ Role in Prototyping
- Rapid Application Development (RAD)
- Comparing RAD to the SDLC
- Agile Modeling : Values and Principles of Agile Modeling
- Activities, Resources, and Practices of Agile Modeling
- The Agile Development Process
- Lessons Learned from Agile Modeling
- Improving Efficiency in Knowledge Work: SDLC Vs Agile
- Risks Inherent in Organizational Innovation
