Viewing Agile Concepts From a Phase Perspective
|This article is based on Becoming Agile, to be published February 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.|
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.
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 in the left column for every project. The steps in the right column are optional.
|Required of All Projects||Optional Processes and Documentation|
Figure 1 illustrates the Agile phases and their relationship to each other.
Figure 1 Agile process frequently occurs in parallel, but we will discuss them from a serial perspective to make them easier to learn.
Page 1 of 4