Are You Ready for Agile?

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• What Areas Will You Become More Agile in?
• The Different Flavors of Agile
• Copyright

Yes, you’re ready for Agile. The real questions are as follows:

• How much agility are you ready for today?

• How much agility can you add tomorrow?

• How can you continuously adapt to your ever-changing business climate?

We’re confident you can improve your current development process and obtain a level of agility.

We’ll start this chapter by providing information that helps you understand the goals of an Agile process and how these goals relate to packaged Agile methods such as Extreme Programming (XP) and Scrum. The chapter will conclude by discussing our approach for bringing Agile into your workplace. We’ll start your migration by providing a tool that will let you assess your potential for bringing in Agile practices and cultural changes.

What Areas Will You Become More Agile in?

When people think of becoming Agile, they often envision the practices and not the goals of an Agile process. We often hear people say that they can’t become Agile because their developers don’t want to do pair programming, or they have limitations with co-locating their project team members. Although these types of practices may help you become Agile, they aren’t the only practices that support the goals of an Agile process. Let’s take a moment to look at some of the key Agile goals you’ll be able to accomplish on some level.

Increasing Customer Involvement

A traditional process has the customer involved mainly at the beginning and the end of the project. In Agile, you seek customer feedback and input throughout the project. The customer or product owner is involved in planning, tradeoff decisions, prioritization, and demonstrations. Increased customer involvement leads to several benefits such as quicker feedback, accurate delivery, increased customer satisfaction, and rapid decisions. A great indirect benefit of customer involvement is the customer’s newfound appreciation for the work needed to deliver on requests.

Improving Prioritization of Features

Agile processes improve prioritization and deliver higher-value features first. This is accomplished by creating feature cards or user stories and evaluating features before requirements are detailed. You’ll evaluate features for their customer value, level of risk, frequency of use, and dependencies. This allows you to do the following:

• Estimate work and evaluate risks early in the process.

• Prioritize features in terms of customer value early in the process.

• Deliver features in usable subsets.

In effect, the Agile prioritization process lets your team run leaner and create deep requirements only for work that passes the prioritization test.

Increasing Team Buy-in and Involvement

The majority of people on an Agile project team are involved in planning, estimating, and sequencing. The team is also involved in adapting to discoveries between iterations. Over time, the team begins suggesting features for the product or platform. Increasing team involvement ensures that everyone understands the value of the project before work begins and also increases team satisfaction.

Clarifying Priorities and Reminding Everyone of the Consequences of Changing Them

An Agile team works with the customer and/or sponsor to determine the most critical category for the project. Is schedule the number-one priority, or is staying within

budget? Additional categories may include quality, feature richness, and compliance. The project team learns the priorities and uses this knowledge to make tradeoff decisions along the way.

Many projects wait for a fire before identifying their priorities. An Agile team knows the project priorities in advance of an emergency and can react quickly to keep the focus on the main objective.

Adapting to Change During Development

A more Agile and iterative methodology provides an opportunity to reassess and redirect the project while it’s in motion. You perform development in iterations and offer demonstrations at the end of each. The customer has an opportunity to request changes based on the demonstrations, even though this may affect other features or potentially the project timeline. Team members learn to expect and embrace change.

Better Understanding the Project’s Status

Agile development is time-boxed. You evaluate status by demonstrating functioning code. Supporting tasks are also measured in binary terms (done or not done) to eliminate possible confusion related to expressing status as “percent complete.” An Agile process also involves team members reporting their status themselves versus through a manager or other intermediary. This improves tracking accuracy and personal accountability.

More Efficient Planning and Estimating

Many companies try to plan all of a project’s details at the start. The planning may be at a detailed level even though the amount of uncertainty at this point is extremely high. An Agile team performs a level of planning that correlates to the current level of uncertainty in the project.

As you learn more about desired features you’ll do more detailed planning, but you won’t waste time trying to guess intricate details early in the project. Figure 3.1 illustrates this point.

Figure 3.1 The accuracy of initial feature estimates improves dramatically during the first few hours of estimation but levels out over time. In this example, the effort and time spent after five hours of estimating doesn’t improve accuracy and is wasted project time.

Continuous Risk Management

A secondary definition of Agile could be continuous risk management. The processes are all intended to make the team alert and responsive to new information and changes as the project progresses. The following are a few examples of how Agile manages risk:

• Features are evaluated for requirements uncertainty and technical uncertainty.

• These attributes help determine whether a feature goes into an iteration and what iteration it should go into, to mitigate risk. For example, a feature with high business value and high technical risk, such as an interface, would go into an early iteration to allow more time for uncertainty. On the other hand, a feature with low business value and high technical uncertainty might be moved to the last iteration or removed from the project all together.

• Risk is managed via demonstrations throughout the project. The customer gets a feel for how requirements are translated into an application before the project is complete. This provides a window for adapting and hitting the final target.

• Risk is managed on a daily basis by building and integrating the latest code. This process allows the team and the customer to validate the status of the latest build.

• Deployment risk is also managed by gathering maintenance and deployment concerns as early as possible. This starts early in the planning phase and continues throughout development.

• Risk is managed via team review of potential features. During the feature-card exercise, representatives from all areas can raise risks and concerns with proposed features. These concerns are noted with the feature information and sometimes can lead to a feature not being pursued.

Delivering the Project Needed at the End

Jim Highsmith, one of the founding members of the Agile Alliance, taught Adaptive Software Development a few years before the Agile Manifesto was created. One of Jim’s adaptive principles is, “Deliver the project needed at the end, not the one requested at the beginning.”

This idea is a foundational piece of Agile software development. Jim knew the world wasn’t static during the project lifecycle; therefore the lifecycle should support changes that happen during the project. This includes identifying new requirements, discovering technical risks, and identifying potential changes in the business environment.

Achieving the Right Level of Project Structure

Many companies have created a formal Project Management or Software Development Lifecycle (PMLC/SDLC) to support their projects. These lifecycles are collections of processes that every project must follow. By establishing required processes, companies eliminate variation between projects and provided a safety net for inexperienced project teams and project managers. If you don’t know what to do next, you just look at the lifecycle documentation to determine your next step.

This approach is beneficial when you have inexperienced employees. A standardized process defines roles, provides common tools, and offers gateways to evaluate status.

If your employees are more experienced, this formal methodology has drawbacks. The team will notice that every step or process isn’t needed for their specific project. They will frequently find themselves doing compliance work that adds no value, except to be in compliance.

The Agile process described in this book approaches the issue differently. We suggest a standardized methodology, but the required processes are minimal and are of value to every project. Your team chooses the majority of the processes to use at the start of the project. The team also revisits their process and documentation options as the project proceeds, to see if they need to add or remove a process or document.

To illustrate this idea, let’s look at an example from Acme Media after the company has outlined a new, more Agile process (see Table 3.1).

Acme Media has projects that last from 1 week to 6 months. The company doesn’t require the teams for one-week projects to create iteration plans or to do a cost-benefit analysis every time.

Table 3.1 - Required and optional processes and documentation

These one-week projects are frequently driven by a need to increase readership or to provide support in the aftermath of a major news event such as an election. Executive approval is almost immediate, and the projects use team members already assigned to the website. These teams only need the processes and documents outlined in the first column of Table 3.1.

Conversely, Acme Media pursues some major projects that require funding, synchronization with third parties, and identification of milestones. In these instances, the project teams review the items in the second column of Table 3.1 and decide which ones to use in addition to the required ones in the first column.

In this way, Agile provides the correct amount of structure for the project. Time isn’t wasted on processes that don’t add value, and teams can scale their processes mid-project if needed.

Now that you understand the goals of an Agile process, you need to know the best way to obtain them. You can do this by selecting a prepackaged Agile process, creating a process from scratch, or a combination of the two. Let’s evaluate each option.

The Different Flavors of Agile

Many packaged methods are available for Agile. For our purposes, packaged will mean a framework with a common set of practices. In this section, we’ll discuss two of the most popular packages in use today: Scrum and XP. According to VersionOne’s 2008 “State of Agile Development” survey, 77 percent of the respondents said they use Scrum, XP, or a Scrum/XP hybrid. Each of these packages has its own unique characteristics, strengths, and weaknesses. Let’s examine each package.

Scrum

The Scrum process begins by reviewing a product backlog with the product owner. You identify the highest-priority features and then estimate how many will fit into a sprint. These features then compose the sprint backlog. A sprint is a predefined period of time, usually 2 to 4 weeks, during which the team analyzes, designs, constructs, tests, and documents the selected features. Figure 3.2 shows an overview of the process.

Figure 3.2 A high-level overview of the Scrum process (graphic provided courtesy of Ken Schwaber and Control Chaos)

The team holds a daily status meeting, referred to as the daily Scrum, to review feature status. Individual team members answer these three questions:

• What have you accomplished since our last meeting?

• What will you work on today?

• Are you encountering any impediments or roadblocks in completing your work?

When a sprint is completed, the features are demonstrated to the customer, and the team and the customer decide whether additional work is needed or if the sprint work is approved to be released to a beta or production environment. Each sprint is followed by a retrospective during which the team lists items that went well or poorly; action plans are documented to keep the successes going and to improve the areas that performed poorly.

Some of the characteristics of Scrum are as follows:

• Discipline. Scrum is strict about time-boxing activities, compiling code daily, and team members being punctual and responsible.

• Three major roles. Scrum teams have a ScrumMaster, a product owner, and team members.

• Quality. Features are expected to be totally complete and deployable at the end of a sprint.

Scrum has a number of strengths:

• Prioritized delivery. Features are delivered in a sequence that ties to business value.

• Non-prescriptive on practices performed during a sprint. This is demonstrated by the fact that a Scrum/XP hybrid is the second most popular Agile methodology in use. Many teams pull their detailed practices from XP while using the Scrum framework.

• Demonstrated success across the software industry. Scrum has been successful in multiple environments.

• Status transparency. The daily meetings expose the project status.

• Team accountability. Everyone signs off on the work that will be pursued during the sprint.

• Continuous delivery. Scrum delivers product features (commercial software or web portals) continuously.

Scrum also has some weaknesses:

• Scrum doesn’t want specialists. It may be difficult to quickly convert an existing team from a group of specialists to a group where anyone can perform any task.

• A Scrum team can’t be successful without a strong ScrumMaster, which makes the process highly dependent on one individual.

• Because Scrum is mainly a framework, the team still needs to identify the practices and methods to use within the framework.

Scrum is incredibly popular today—it’s almost become synonymous with the term Agile development. Scrum provides a great, repeatable process that is well suited for product development and steady-state release management. In addition, a plethora of books, consultants, and other resources are available for those who pursue Scrum.

Scrum may be more difficult to use with teams that do one-off projects versus steady-state releases, or if a team has highly specialized resources and skill sets. In addition, the Scrum framework still needs Agile practices inserted to support a complete development lifecycle.

Extreme Programming

Similar to Scrum, XP starts the process by creating a backlog of work to perform during a sprint/iteration. XP creates the backlog by working with customers and creating user stories. In parallel with this work, the team performs an architectural spike, during which they experiment with the features to envision the initial architecture. XP classifies this work as the exploration phase.

The planning phase follows exploration. This phase focuses on identifying the most critical user stories and estimating when they can be implemented. Tasks are defined for each feature, to aid with estimating complexity. The team outlines an overall release schedule, with an understanding that a high level of uncertainty exists until the work begins. A release will have one to many iterations, which are typically 2 to 4 week construction windows.

When an iteration begins, the specific plan for the iteration is revisited. The team adds any new user stories and tasks that have been discovered since the overall release was outlined.

XP integrates customer testing into the development iteration. The customer is asked to identify the acceptance tests, and the team works to automate these tests so they can be run throughout the iteration.

The planning phase is followed by the productionizing phase, during which the code is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response time requirements. You can see an overview of XP in Figure 3.3.

Figure 3.3 The Extreme Programming (XP) lifecycle (graphic provided with permission from Scott Ambler, based on the writings of Don Wells and the first edition of Kent Beck’s XP Explained)

Some of the characteristics of XP are as follows:

• Specific practice. Unlike Scrum, XP is specific about the practices that should be used during a software project. These practices include pair programming, TDD, continuous integration, refactoring, and collective code ownership.

• Modeling. XP teams frequently use modeling to better understand the tasks and architecture needed to support a user story.

• Simplicity. Teams perform the minimum work needed to meet requirements.

• Automation. Unit and functional tests are automated.

• Quality through testing. Features are tested constantly, and developers check each other’s code via pair programming.

These are some of XP’s strengths:

• Customer-focused (it’s all about user stories)

• Quality via frequent testing

• Constant focus on identifying and delivering the critical user stories

• High visibility on project status

• Great support for volatile requirements

It also has weaknesses:

• Need for team maturity. Practices such as pair programming and TDD require responsible developers, and they aren’t always easy to obtain.

• Dependency on testing. If developers know that significant testing will take place downstream, they may be less than diligent when they’re creating designs.

• Scalability. XP may not work well for large projects.

• Dependency on team member co-location. The team usually has a team room.

XP supports many of the critical goals of an Agile process, such as dealing with volatile requirements and delivering prioritized, working software as soon as possible. XP also supports the principle of just enough, keeping with the lean philosophy of minimizing waste.

XP has sometimes been criticized for its lack of formality in system documentation and system design. In recent years this has changed, and XP teams now create the documentation needed to support a project’s customers.

Previous article: Agile and the Bottom Line

Continue on to the next article: Create Your Own Flavor to Become Agile within Your Constraints

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.