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.

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.

Becoming Agile book cover
This article is based on the book Becoming Agile by Gregory S. Smith, published by Manning Publications.

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
Action items from project retrospective

Figure 1 illustrates the Agile phases and their relationship to each other.

Figure 1
Figure 1 Agile process frequently occurs in parallel, but we will discuss them from a serial perspective to make them easier to learn.

The Agile phases

The 5 phases we will discuss are feasibility, planning, development, adapting, and deployment:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. When all iterations are complete the team deploys the working code into a production environment.

Now let’s examine the feasibility phase in detail.

Feasibility—defining and validating your vision

PHASE OBJECTIVE: Determine if the idea has enough merit to justify going forward with more detailed requirements, planning, funding, and staffing.

Why am I here? Why are we doing this project? What is the value of this request? The feasibility phase pursues the answer to these questions and also evaluates the risk in pursuing an idea. The question that summarizes it all is, “Is this request or idea viable?”

Let’s look at figure 2 to get a better understanding.

Figure 2
Figure 2 Many companies initialize a project without truly quantifying the value and goals. The Feasibility phase eliminates this issue by measuring the value before making a major investment in the project. Costs and benefits are compared at the end of the phase and the team makes a go/no go decision.

The feasibility phase begins with an idea or request. The idea can come from within the team, a customer, or practically any source. The person who collects or provides the idea bounces it off of a supervisor or a management group that vets ideas. If the idea is given approval for further investigation of feasibility, the idea is assigned to a group or person for further research. It could be given back to the person who presented the idea.

The person assigned to the request then makes a decision on whether they can do the research on their own, or if they will need team members for help. To see it in practice, let’s look at an idea within Acme Media.

Wes Hunter, a business analyst, has suggested that Acme start providing news alerts to cell phones. He bounced the idea off of Peggy Romani, the Product Manager for the News website and received a green light to go further on feasibility and research. Wes could see the business value of the feature and explain the value from a perspective of audience share and competitive advantage, but he had no idea how wireless technology worked or the architecture that would be required to support it. Wes requested the assistance of the lead architect, Keith Gastaneau, to help him work through the high level technical implications of pursuing the idea. In this instance the feasibility team will be Wes and Keith.

Once the team or person has been identified they continue the feasibility work. This additional work could include:

  • Talking to customers

  • Performing a cost/benefit analysis

  • Looking at what competitors are doing in related areas

  • Researching whitepapers on the subject from industry experts

  • Check compatibility with the current platform

  • Researching technology needs.

  • Create use cases to better understand the idea

  • Usability testing

  • Mockups/prototypes

The Agile/Lean concept of just enough applies here. We want just enough information to see if this idea is worth the effort needed to create a plan for it. Once the work is complete it is presented to the Product Manager or approving body for discussion. The feasibility investigator will present high level requirements, a guess at project costs (funds and resources needed), risks identified during the research, a list of benefits, and a ballpark project timeline. The meeting is concluded with a go/no-go decision.

This decision only provides approval to continue the investigation and planning for the idea. It is not an endorsement to take the idea all the way through to delivery. Show stoppers can still be identified during planning and development, so an idea can be cancelled at any time.

The last step in the feasibility phase is the assignment of a planning team. If one person has been investigating an idea they will need a team to plan the idea after approval. Resources can be assigned informally or officially by a manager or management group. Team members can come from all areas of the project team, but you need to have representatives who have experience with the product. These team members will help estimate features at the end of the phase.

The team also needs the customer or a customer advocate to provide their input during the prioritization that occurs throughout the phase. It is desirable to have the planning team follow the idea all the way through to deployment.

Planning—speculating and creating a living plan

PHASE OBJECTIVE: Break the idea down into discrete pieces of functionality called features. Prioritize the features and assign them to iterations.

The first step in the planning phase is to orient all of the planning team members on the idea.

Frequently the planning team will conduct an “envisioning” meeting to help everyone synchronize on the benefits of the idea. The envisioning meeting can be viewed as a marketing meeting. The team pretends they are going to sell the idea to a customer. They identify the top 3 to 5 product highlights they would tell the customer about. In addition they create a summary of key features that will be delivered. The idea is becoming a project during this exercise.

Note that the planning phase also continues the feasibility work. We gathered enough information to justify planning during feasibility, now we want to refine our financials based on the additional detailed gleaned during planning. See figure 3.

Figure 3
Figure 3 The planning phase brings the project team together to quickly convert the idea into features. The features are prioritized, sequenced, and estimated during the phase. An iteration plan is created to initialize development.

After features are identified the team goes through the feature card exercise. In this step the features identified during envisioning are fleshed out just enough to prioritize them and sequence them into the order they would be developed in. The team also uses the prioritization as another feasibility check. If a feature comes out of the feature card exercise as a low priority the customer may choose to remove it from the project.

The remaining features are estimated by the team at a high level, identifying the major tasks and resource types needed.

The last step of this phase is to assign features to iterations. The iterations are buckets of time that the team develops features in. A good time frame for an iteration is 2 to 3 weeks. The previous estimates are used to determine which features will fit into the available iterations.

Note that each iteration is structured so that it provides value on its own. This allows deployment even if something prevents all of the iterations from being completed.

The main deliverable from this phase is the iteration plan.

Development—exploring with a schedule

PHASE OBJECTIVE: Create, test, and demonstrate features. Queue iterations for deployment.

The development phase begins with iteration 0. The iteration is so labeled because no features are delivered during it. This iteration is used to put the necessary foundation pieces, both business and technical, in place to start development. Some typical iteration 0 activities are:

  • Finalizing contracts with vendors

  • Initial architecture design

  • Preparing the environments (OS, DB, Development tools)

  • Funding

If you are building on an existing platform, with dedicated resources, you may not need an iteration 0. You can begin development immediately after planning.

When the first development iteration starts the team will refine the tasks they identified during planning. This is very common because the team only provided enough information to estimate the features during planning. Once a project gets through the planning gateway the team knows it is coming and they will begin doing detailed analysis of the work they need to do.

1 2 Page 1
NEW! Download the State of the CIO 2017 report