The prospect of adopting agile software development practices to deliver value to customers faster while reducing feature fatigue has captured the imagination of Product Managers everywhere. In the past few years a rising number of companies have experimented with agile practices, hoping to bring the most valuable product features faster to the market and gain strategic advantage. But many companies have had difficulties adopting the new agile practices. Some have faced employee or department resistance to change during the transition. Others have failed to demonstrate enough business value to keep the initiatives alive and spread it across the organization.

This article outlines the main principles that will help companies choose the right strategy when adopting agile development. Process and methodology improvements often face skepticism partly because they are seen as tools imposed by the management. It is therefore necessary to take the time to craft a transition plan for a successful agile adoption.
In order to get the return of this important process investment, companies need to start small by choosing a pilot project. Next, they {sidebar id=1} need to define business value in objective and measurable terms. Third, agile methods and practices need to be evaluated according to their contribution to the business value followed by a careful selection of key agile practices. Lastly, companies should measure the success of the pilot project and chart a corporate adoption strategy.

Selecting a Pilot Project for Agile Transition
Before a large scale or permanent process is adopted it is always a good idea to start with a pilot project. A pilot project is valuable because it is experimental. Companies can learn lessons from the pilot, correct any problems, and gain a deeper understanding of the inner workings of each agile practice.

Indeed, many companies' first exposure to Agile will be during the pilot project. Starting with a pilot is a way of creating a success story. It is therefore important to start with a project that is a representative of the average project—if there is such a thing—in the company.
Start by assembling a team of four to six developers for a project of moderate size. Try to keep the size of the project under 300man-days and the schedule no longer than six months. A pilot project could be built into a real product if successful, or abandoned if it fails. Steer clear of risky technologies and platforms, especially if the team has limited training. Remember, the pilot project should be a good representative an average project in the organization.

Once you select a pilot project, it is time to define its business objectives and measures of success.

Defining Business Value
What determines the success or failure of your product? Time to market? Rich feature set? Memorable user experience? Starting with the right questions can pave the path to understanding the real business drivers behind your transition to Agile.

Let's take a look at how some companies have defined business value.

When Taiichi Ohno came to Toyota Motor Company, he realized a fundamental problem with the way new products were developed: it was a long and linear process. In many cases the labor was fruitless, despite long hours and thousands of yens. Mr. Ohno defined one of the key business values as developing product prototypes rapidly and in a non-linear fashion. It was not uncommon for the company to run multiple and, sometimes, competing prototype projects for the same product. In the course of several years the company developed a seminal body of process knowledge, later named the Toyota Production System (TPS) or Lean Product Development. Through the years the TPS was adopted by many engineering disciplines including software development. [1] A leading insurance company was having hard time keeping critical software up to date in a rapidly changing regulatory and reporting environment. The company did two things. First, it determined that disciplined and skilled application of agile methods would guarantee faster and more efficient response to external changes. Secondly, it created a common architecture across web applications, sales and contract execution systems, and accounting applications. By harnessing the flexibility of agile methods the company reacted faster to change. Moreover, by reusing common application code across multiple application domains, it cut costs and became more efficient.

If you are a product company, your product's features may well be your primary business value. In that case, it may be beneficial to rank each feature according to its expected projected revenue, cost and time to develop, and the opportunity cost of delays or not developing it.

TaxFile Inc. was in the process of evaluating a set of new features for the next release of its flagship tax filing software when the Product Manager came up with a chart (see Figure 1).

Figure1: Business value can be a key factor in your selection of new features

Clearly, time-to-market was a major driver for TaxFile. As the costs of delays ran high, the company was forced to look for ways to get critical features to the market faster. It found the solution in defining business value in objective and measurable terms.

Assessing Agile Practices
Once the business value is defined, try to evaluate each Agile practice according to its contribution to your objectives. Do not be afraid to mix and match agile methods to find the best solution. Because there is a lot of hype around various agile methods. many companies are naturally left wondering if certain practices are “OK” according to a particular method. Tryout each practice in the pilot project and evaluate the results for yourself. It is OK to try a new practice and fail during the pilot project. In fact, that’s why you're conducting it. As Thomas Edison famously noted "...you are not going to fail. You'll just find 10,000 ways that won't work...” [2]

Selecting and Adopting Agile Practices
The third element of a successful agile adoption is the careful selection and disciplined implementation of agile practices. When it comes to selecting agile practices there is no shortage of views. These vary greatly depending on the practitioner and can sometimes be recommended by the individual agile methods such as XP, Scrum, Lean, DSDM, and Lean.

It is possible to distill these views into two major groups: one advocating an all-or-nothing method adoption and the other leaving room for process customization. One can label these opposing approaches as Table d'hôte Agile vs. A la Carte Agile. {3] The difference is clear: in the first you are bound by the rules of the particular method, while the second allows you to pick and choose what to adopt. The number of companies practicing Table d'hôte

Agile is small compared to the rest. The levels of agile adoption in these companies also tend to be limited compared to the companies allowed to choose the agile practices that serve their particular business needs.

Measuring Success in Agile Projects

“The measure of success is not whether you have a tough problem to deal with, but whether it is the same problem you had last year.” -- John Foster Dulles

Defining business value in objective and measurable terms set the stage for measuring the success of your agile initiative. It needs to be supported by a set of metrics and benchmarks designed specifically to assess the success of the pilot project. For example, what value did it deliver for the money spent? What was the pace of the team? How about the time to react to changes in requirements or the ability to add new features in the middle of a release?
Demonstrating measurable results in a pilot project can be beneficial in multiple ways:

• It can generate support for future agile initiatives - quantifying business value is a powerful driver behind many corporate programs.
• It can teach the company what works and lead to saving capital during a large-scale process adoption.
• It can be a playground for new ideas by encouraging innovation and risk taking.

Conclusion
To sum up, enhancing business value means that companies have to rethink how they formulate their agile adoption strategy. A five-party methodology can be effective:

First, companies need to select a pilot project. It's much easier and less costly to try and fail and learn in the pilot project before a wholesale adoption.

Second, companies should define business value in clear, concrete and measurable terms. It's all too often that projects spent too much time on activities with little or no real value or they deliver too many, mostly useless, features to the customers.

Third, activities and technologies need to be evaluated according to their contribution to the business value. Agility promotes faster business value, but not necessarily the latest and greatest technical framework.

Fourth, the companies should carefully incrementally select adopt key agile practices. Agile adoption does not have to be an all-or-nothing process. Every practice should be assessed with respect to business goals and only adopted if it makes business sense.

Finally, companies should develop a set of objective evaluation criteria to measure the success of the initiative. Since it is very difficult to improve things that cannot be measured, it is imperative to develop a set of measurable goals to assess the success of the agile initiative.

About the author
Levent Gurses is a Washington, DC-based technology consultant. He is also the co-founder of a US-based technical consulting and development firm specializing in transformations through Lean and Agile development practices. As a Certified ScrumMaster, Levent helps his clients develop better software through SCRUM, XP, and agile. His expertise is in transitioning companies to Agile by establishing technical infrastructure, mentoring, and coaching for Rapid Product Development (RPD). Through his company, Levent provides vital resources such as agile coaches, project managers, architects, and developers.

[1] Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It (Hardcover) - http://www.amazon.com/Product-Development-Lean-Enterprise-Productive/dp/1892538091/ref=cm_lmf_img_3/104-0858217-8760748

[2] Thomas Edison, inventor (1847-1931) - http://en.wikipedia.org/wiki/Thomas_Edison

[3] Definition, Wikipedia - http://en.wikipedia.org/wiki/Table_d_hote and http://en.wikipedia.org/wiki/A_la_carte.