What an Agile Process Looks Like
Development teams that want to adopt agile methods need to know what a typical roadmap looks like. This book chapter from the new Becoming Agile shows you how to view Agile concepts from a phase perspective.
Wed, January 23, 2008
CIO —
Traditional software development happens sequentially with clearly defined stages and phases. Sequential development is popular because it is easy to follow from a team member perspective. Team members follow exact steps for every project and quickly learn the process.
In an Agile process activities are frequently concurrent and often repeated. Team members focus on providing value and using the process and steps that best support the project. Applying Agile processes and techniques is not intuitive for team members with a background in sequential software development.
To address this issue I will present the Agile concepts from a sequential phase perspective. If you are familiar with traditional software development you will find the phase descriptions intuitive.
Before we continue, let me expand on what I mean by a generic Agile development process. Scrum and Extreme Programming (XP) are popular packaged Agile methods. These packaged methods come with several Agile practices and a suggested process for using them. Our generic life cycle will be different in that it will allow a development team to pick and choose the Agile practices that work best in their environment.
XP and Scrum are superb Agile packages with strong followings and demonstrated success. Many companies have deployed these packages successfully. An issue with selecting a package, however, is some practices may provide minimal value in your environment or be difficult to implement on day one.
Consider the XP practice of Test Driven Development (TDD). This is an excellent practice that provides benefits such as minimizing the time needed to trace down bugs and quicker deployment of code. No one can deny the value of these benefits. What can be challenged is the complexity of implementing a TDD process.
A TDD process requires a disciplined development team and a mindset change. The development team needs to grasp the value of TDD and support it on a daily basis. This is a stretch for a team that is just learning the value of Agile principles. From my perspective you would not want to attempt to use TDD during your initial migration to Agile. TDD could be revisited once the Agile culture has begun to take hold and the team owns the new process. For reasons such as these, you will select the Agile practices that work best in your environment.
Related, an important aspect of our process is the menu system. We will outline a core flow that all projects should go through, but the required path will represent the least common denominator. It will be low on formality and best used on projects that need to be completed in a few days. The menu will provide options that the team can select as needed, or as the project requires more structure. To see an example, let’s look at the menu that Acme Media will use in table 1.
Table 1
A key to being Agile is using the practices that best support a given project. In this example from Acme Media, the team should perform the tasks first list for every project. The steps in the second list are optional.
| Required of All Projects |
|---|
| Project worksheet (charter) |
| Operational worksheet |
| Feature card/User Story exercise (cards optional) |
| Optional Processes and Documentation |
|---|
| Elevator Statement |
| Document answers to Feasibility Discussion Guide questions |
| Cost/benefit analysis |
| Feature card documented. |
| User scenarios |
| Use cases |
| Prototypes and/or mockups |
| Stand Up Meetings |
| Iteration plan |
| Maintenance plan |
| Additional documentation as required by the team/project. |
| Pair Programming |
| Detailed schedule |
| Launch Plan |
| Information Radiator |
| Demonstrations |
| Action items from project retrospective |
Figure 1 illustrates the Agile phases and their relationship to each other.
The Agile phases
The 5 phases we will discuss are feasibility, planning, development, adapting, and deployment:
The feasibility phase is used to determine if an idea has enough merit to proceed to planning. An individual or small group will scrutinize the idea for customer value, company value, and risk.
If an idea is viable it will proceed to planning. The project team will be assembled at this time and the team will work together to identify features. Features will be examined for value and risk and eventually estimated so they can be assigned to an iteration plan.
Development iterations convert the iteration plan into working code. Features are built, tested, and demonstrated to the customer and stakeholders at the end of each iteration.
The team adapts between development iterations. Customer feedback is used to adjust the plan for the forthcoming iteration. The team also uses this window to evaluate their velocity (pace) and they adjust iteration capacity accordingly.
- When all iterations are complete the team deploys the working code into a production environment.
Now let’s examine the feasibility phase in detail.
