The prospect of adopting Agile 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 in adopting Agile. 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 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 300
man-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.[i]
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 will 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).
Figure
1: 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. There is a lot
of marketing and hype around various Agile methods and companies are naturally
left wondering if certain "things are OK" according to a particular method. Try
out 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..."[ii]
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. À la carte Agile.[iii]
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
sets 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 select and
incrementally 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 Jacoozi,
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.
[i] 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
[ii] "I
have not failed. I've just found 10,000 ways that won't work." --Thomas
Edison, inventor (1847-1931) - http://en.wikipedia.org/wiki/Thomas_Edison
[iii] Definition,
Wikipedia - http://en.wikipedia.org/wiki/Table_d%27h%C3%B4te
and http://en.wikipedia.org/wiki/A_la_carte.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form