What an Agile Process Looks Like

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.

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:

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.

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.

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.

The development done during an iteration is not waterfall. The process will be one of collaborative development. The developer will create code to the minimum specification and demonstrate it to the customer. At this time the customer will identify requirements they missed, or issues with their initial requirements. The developer may also identify technical issues. The developer, customer, and team will work through these issues during the iteration, evolving the code until it supports what is needed at the end if the iteration, not necessarily what was requested at the beginning. Figure 4 illustrates the steps in Development.

Building and testing occurs during an iteration. When an iteration is complete there is a review meeting to adapt (see Adapt in the following section).

Iterations are stored in acceptance environments until all iterations are deemed complete. At that time all of the work is deployed into the Production environment.

Adapting—reacting to new information

PHASE OBJECTIVE: Review the output of an iteration and re-plan based on discoveries (see figure 5).

“Adapting” is one of the special elements of Agile development. We expect change and we embrace it.

Adapting occurs informally throughout an Agile project, but it happens formally during the development phase. A review is performed at the end of each iteration to:

• Demonstrate the state of the features assigned to the iteration.

• Get feedback from the customers and stakeholders.

• Refine feature definitions based on feedback and better understanding

• Incorporate new information that has been discovered during the iteration.

• Evaluate the pace of feature development and adjust the next iteration accordingly.

• Identify defects to repair.

When the review is complete the project manager modifies the iteration plan based on the new information and the team proceeds into the next iteration.

Deployment—delivery, training, and revisiting and closing the project

PHASE OBJECTIVE: Code delivered to Production environment, with all support needs in place.

The deployment phase typically begins after the last iteration is complete. We bundle all of the previously completed iterations and move the code to the production environment.

One of the advantages of iterative development is you can deploy at the end of each iteration if you so choose. Teams that do this usually have very little overhead in deploying, meaning the process can be done quickly with few resources.

Typical tasks for the deployment phase are (figure 6):

• Training support and operations on the forthcoming release

• Turning on your communication plan to employees and customers

• Finalize documentation

• When applicable, enabling the marketing plan

• Ensure all pieces of the maintenance and support plans are in place

• Release the code into Production

• Where applicable, perform post-release QA in the Production environment

• Perform a lessons learned session with the team within 2 weeks of the release

In an Agile methodology you have considered deployment needs throughout the previous phases. Optimally the work done during deployment is tweaking and finalizing the training, maintenance, marketing, and communication plans.

Summary

Agile software development does not occur sequentially, but viewing it from a sequential perspective makes it easier to grasp the concepts. We will use a case study that follows a sequential process to accelerate your learning of Agile concepts.

Want to Learn More About Agile?

How Agile Development Can Lead to Better Results and Technology-Business Alignment

The ABCs of Agile

10 Questions To See If Your Company’s Developers Are Agile

Sign up for our Development and Architecture newsletter

Adopting an Agile process is a significant effort with a level of risk. To help mitigate this risk we will present an iterative approach that allows your team to add agility over time. You will add more agility to your process as knowledge increases and the organization culture becomes more accepting of Agile techniques.

Acme Media will bring the 5 Agile phases to life by:

• Using feasibility studies to validate the value of an idea.

• Using collaborative planning to synchronize the team on project vision and to break the idea down into discrete features.

• Using development iterations to refine our understanding of requirements and deliver working code.

• Demonstrating functioning code to the customer and adapt to their feedback.

• Completing the project by deploying our code into the production environment.

• Stopping to review our process and make adjustments to it, based on lessons we learned.

Beyond the case study, I believe the template outlined in this article can also be used as a starting point for the Agile migration within your own company.

An Agile process is 50% of the work in migrating to Agile. The other 50% is establishing an Agile culture and environment.

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