Forrester Agile

May 6, 2009

From Agile Development To Agile
Engagement
by Tom Grant
for Vendor Strategy Professionals

Making Leaders Successful Every Day

For Vendor Strategy Professionals

May 6, 2009
From Agile Development To Agile Engagement
Agile Might Start in Development, but it can’t Stop There
This is the first document in the “Agile company” series.
by Tom Grant
with Peter burris, Dave West, and Madiha Ashour

ExEcuT i V E S u M MA ry
Agile development practices continue to spread across development functions in technology companies.
When technology companies adopt Agile practices in the development organization, these changes
have ripple effects on other departments whose work is tied to the development cycle — such as QA,
product management, marketing, sales, support, consulting, and business development. As our survey
of technology companies shows, Agile can inspire improvements in how technology companies operate,
even if they don’t pay much attention to the effect on relationships between development teams and the
rest of the organization. To reach the full potential of Agile and to avoid the potential pitfalls of these
unintended consequences, companies need more conscious, dedicated efforts around the adoption of
Agile across product-related functions.

TAbl E o F co nTE nTS n oT E S & rE S o u rcE S
2 Agile Tunes The Engine, But The Rest Of The Forrester surveyed 229 technology industry
Car Needs An Upgrade professionals in a variety of roles to determine
2 Agile Methodologies Have Focused More On the effects Agile has on company agility.
The Engine Than The Car To supplement the survey data, Forrester
interviewed 24 technology companies.
5 What Happens If You Only Upgrade The
Engine?
Related Research Documents
10 Agile Development Creates The Need For
“company Agility Evaluator”
Agile Engagement
February 24, 2009.
rEcoMMEnDATionS
“inquiry insights: Agile Development”
14 Tune Performance One Component At A Time
october 6, 2008
WhAT iT MEAnS
15 Agile Development Can’t Ignore Agile “Agile Product Management Makes Agile
Engagement Technology companies”
october 7, 2008
15 Supplemental Material
“Make Agile lean To boost business impact”
December 17, 2008

© 2009, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available
resources. Opinions reflect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar,
and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To
purchase reprints of this document, please email clientsupport@forrester.com. For additional information, go to www.forrester.com.

2 From Agile Development To Agile Engagement

AGIlE TUNES THE ENGINE, BUT THE REST OF THE CAR NEEDS AN UPGRADE
Agile development methodologies can revolutionize how development teams build new products
and services. While these methods may create ripple effects in any organization, the consequences
of going Agile are most profound in technology companies.1

For this study, Forrester surveyed and interviewed technology industry professionals in a variety
of roles — including quality assurance (QA), product management, support, consulting, sales, and
marketing — many of which were not directly involved with the development process. Our data
provides a snapshot of Agile adoption, its benefits and costs, and its contribution to success at both a
departmental and company level.

· Development remains the engine that powers technology companies. Whether the company
focuses on products or services, the development team generates the core value that customers
seek.

· The line from development to the customer is never perfectly straight. Other groups are
responsible for marketing, selling, supporting, and implementing the technology. Reaching
the customer more quickly and successfully, therefore, hinges on working relationships among
many groups in technology companies.

· Changing the engine affects the rest of the machine. Forrester’s research into Agile’s effect
on technology companies shows that, without any conscious effort to use Agile adoption in
development as an excuse or inspiration to make related changes in the company, Agile does
have a significant effect on the operations of technology companies.

· For technology vendors, Agile methodologies need to improve more than the engine. These
organizational changes may define the next stage of the Agile movement, deliberately using
the Agile development as the starting point for changes to the company more broadly. The goal
of this next Agile wave would be increasing technology companies’ responsiveness to market
threats and opportunities.

· Agile development naturally leads to Agile engagement. If the goal is to shorten the path
between development and the customer, Agile must evolve to become more than just a set of
development-centric guidelines. The smooth, efficient engagement of all the relevant moving
parts in a technology company is necessary to reach the original goal of Agile.

AGIlE METHODOlOGIES HAvE FOCUSED MORE ON THE ENGINE THAN THE CAR
Just as a car is a system of interlocking parts — the transmission, steering column, electrical system,
etc. — a technology company is a system of interlocking organizational and procedural components.
While the basic principle of “changes to the engine affect the entire car” might seem obvious,

May 6, 2009 © 2009, Forrester research, inc. reproduction Prohibited

From Agile Development To Agile Engagement 3

Agile techniques have not normally taken the consequences of Agile adoption for other business
functions into account. To date, the Agile methodologies themselves, such as Scrum, XP, and DSDM,
have focused primarily on the development teams and not on their relationships with the rest of the
company. In Agile, adaptive project planning spread over short iterations replaces the traditional
“waterfall” methods, which opt for longer releases requiring more upfront planning. User stories
replace traditional feature lists. New disciplines, such as continuous integration, become part of the
development process. Ultimately, the success of Agile is the degree to which these changes improve
the speed and quality of the development team’s output.

Several years after the publication of the Agile Manifesto, Agile is now successful enough to start
devoting more attention to these downstream effects.2 Even if the Agile Manifesto did not provide
a comprehensive guide to changes outside the development team, the Manifesto implied that the
scope of Agile’s goals covered the entire organization, not just one department (see Figure 1).

Figure 1 The Agile Manifesto implies changes beyond Development

Goal of the Agile Manifesto Implied changes beyond the development function
“Our highest priority is to satisfy the customer Collecting and analyzing customer issues through product
through early and continuous delivery of management, sales, support, and other customer-facing
valuable software.” groups.

Building a collective early-warning system among
development, marketing, and other groups to identify
“Welcome changing requirements, even late in important market shifts.
development. Agile processes harness change
for the customer’s competitive advantage.” Working with business development to recruit partners to
ll in technology gaps faster and more e ectively than the
vendor can address them.

“Business people and developers must work Arranging regular customer feedback in person through
together daily throughout the project.” product management or virtually through additions to the
company Web site, such as innovation management and
community sites.

“At regular intervals, the team re ects on how to Handling these assessments across departments to take
become more e ective, then tunes and adjusts into account the downstream e ects of Agile adoption
its behavior accordingly.” (for example, marketing’s ability to handle more frequent
product launches).

53565 Source: Forrester Research, Inc.

© 2009, Forrester research, inc. reproduction Prohibited May 6, 2009


As Agile further diffuses into technology companies, business decision-makers face serious
questions about the changes it generates. In technology companies that adopt Agile development
practices, what changes naturally occur? Do other groups, outside of development, view the Agile
experiment with the same degree of enthusiasm? Does Agile change anything about the “inbound”
information that guides product and service decisions or the “outbound” information about these
products and services that other groups consume? Does Agile have any impact on development
decision-making or on the company’s ability to execute in tandem to deliver new products and
services?

Fortunately, there’s still time to answer these questions. Agile enjoys serious momentum, but most
development teams believe that they are far from finished with their implementation of Agile (see
Figure 2).

Figure 2 For Most, The Agile Journey is not Finished

“How complete is your implementation of Agile?”

Our implementation
of Agile failed
4%
We are still evaluating Agile
and have not yet begun to adopt it
17% We have a mature implementation
of Agile methods
We have just started 35%
adopting Agile methods
17%

We are midway in our adoption of Agile
33%

Base: 241 technology industry professionals in a variety of roles, including but not limited to development
(percentages do not total 100 because of rounding)
Source: December 2008 Global Agile Company Online Survey



WHAT HAPPENS IF YOU ONlY UPGRADE THE ENGINE?
When development teams go Agile, some changes in the operations of the larger company are
inevitable. Our research shows that, when aggregated, these changes are positive. However, these
adjustments are accidental, and not every technology team successfully makes these changes. In any
case, they represent only the side effects of Agile development, which are far smaller than the full
potential of Agile engagement.

Agile Shortens Release Cycles
During our interviews, we discovered that technology vendors use Agile to break up a single release
into smaller, more manageable iterations. Two-thirds of technology companies report that their
product cycles have shortened as a consequence of adopting Agile in development (see Figure 3).

Figure 3 Faster iterations usually lead To More Frequent releases

“Has Agile changed the frequency of product releases?”

Less frequent
3%

No change
30% More frequent
67%




These organizations see Agile as a way to make more frequent midcourse corrections. Whether or
not the company releases a new version of a product with each iteration, the shorter cycles make it
easier to adjust to changing customer demands and market realities.

According to the companies we interviewed, shorter cycles also make releases more predictable. By
reducing the complexity of the release, managers can more accurately estimate when the work will
be completed.

Once again, we are focusing on the development team. As important as these benefits are,
technology companies are looking for other returns on the Agile investment, too. If technology
companies don’t take concrete steps to harmonize Agile development cycles across both
development and delivery, such as marketing and support, they may not be able to fully harness
Agile’s benefits. For example, even the best marketing team can execute only so many demand-
generating campaigns each year — assuming that each iteration produces something that is new,
different, or valuable enough to market.

Shorter Trips Make It Easier To Understand Where Everyone Is Going
To move at Agile speed, technology companies need to collect, filter, and feed information in to
the development process. This inbound information includes critical details like customer business
problems, use cases, integration challenges, and adoption realities.

However, development is not the only consumer of this information. This information is vital to
both development and delivery — and to harmonizing both business functions. A growing, shared
mosaic of market and customer information, to which every group contributes and which every
group consumes, lowers the risk of all groups making bad decisions, not just the development team.

Fortunately, according to our survey data, Agile development does create some compulsion to better
transmit and share information. Technology industry professionals — and not just those involved
directly in the development process — believe that Agile increases companywide access to critical
market and customer information (see Figure 4).



Figure 4 companywide information increases With Agile Adoption

“Since your adoption of Agile, has there been any change in the companywide
understanding of target customers, markets, and competitors?”

Don’t know
Signi cantly worse, 1% 7% Signi cantly improved
15%
Moderately worse, 2%

No change
40% Moderately improved
34%


These improvements are significant, but detailed analysis shows that they fall short of the
company-level Gestalt that technology vendors would like to achieve. Some interviewees, while
acknowledging that Agile improved the scale of inbound market and customer information, noted
that the scope of these improvements usually is uneven. For example, some vendors indicated
that internal product training was easier to develop and assimilate when each, more frequent
release featured more targeted functional improvements. However, many teams struggle to convert
the “artifacts” of the development process, such as user stories, into deliverables for external
consumption. For instance, the index card-sized chunks of information drafted within development
for development don’t easily translate into product collateral and demos.

But You Still Need To Chart The Route
Our research shows that Agile generates some improvements to “outbound” information and
activities in technology companies. The degree to which the entire company can execute, in sync, a
new product or service release is one of the most important tests of this outbound work. The stakes
are high, maximizing the revenues, market share, or other business goods from the new technology
brought to market. Unfortunately, the pitfalls are all too familiar, such as the gap of weeks or months
between the actual release and the ability of some groups to fully market, sell, implement, or support
the technology.



The improvements on the outbound side are roughly the same as those on the inbound side, if not
slightly smaller (see Figure 5). This result is hardly surprising. The degree to which various groups
share an understanding of the product or service strategy behind a release will limit, in practice,
how well these groups can implement their parts of that strategy. (This assumes, of course, that the
strategy was realistic or accurate in the first place).

Agile Marginally Improves Working Relationships
Both inbound and outbound activities are the proving ground for the relationships among groups. If
the relationship between two groups is bad, any activities that require the participation of both groups
can only achieve limited success. For example, if marketing and development don’t trust each other,
activities such as new product training and reviews of product marketing collateral are likely to suffer.

Our research shows that the unintended ripple effects of Agile only marginally improve the
relationships between development and other groups. Without deliberate efforts to build on the
opportunities that Agile adoption presents, the following rule applies:

· Before adopting Agile. The closer to the development process another group is, the better
the quality of their relationship with development. For example, QA is a direct participant in
development, while sales has only a distant relationship to this process (see Figure 6-1).

· After adopting Agile. The amount of improvement in the relationship between development
and another group is, again, a function of how close that group is to the development process
(see Figure 6-2).3

Figure 5 Agile improves companywide Execution, To A Point

“Since adopting Agile, has there been any change in the company’s ability to work in sync across all
groups (development, sales, support, marketing, etc.) to bring a new product or version to market?”

Don’t know
Signi cantly worse, 2% 5%
Signi cantly improved
Moderately worse, 8% 19%

No change
27%

Moderately improved
38%




Figure 6 Agile has Minimal impact on Working relationships

6-2 “How would you rate the quality of your working relationship with other groups?”
5 — very good 4 3 — neither bad 2 1 — very bad I don’t work with this group
nor good N=
4%
Product management 47% 25% 14% 4% 5% 171
Product development/ 58% 24% 6% 6% 6% 144
engineering
QA 48% 28% 12% 5% 6% 235
3%
Executive management 46% 30% 13% 7% 231

Business development 36% 28% 17% 5% 12% 229
3%
Marketing 33% 29% 17% 8% 11% 231
Operations 31% 35% 20% 5% 9% 236
Support 33% 32% 19% 7% 8% 238
Documentation 34% 23% 18% 7% 17% 240
3%
Sales 29% 28% 19% 6% 15% 238
4%
Consulting 27% 21% 14% 33% 217

6-2 “Since your adoption of Agile, how has this working relationship changed?”

5 — much better 4 3 — no change 2 1 — much worse I don’t work with this group
N=
2%
Product management 39% 26% 25% 6% 156
Product development/ 2%
engineering 39% 23% 30% 3% 124
3%
QA 34% 27% 30% 5% 210
3%
Executive management 23% 28% 40% 5% 207
2%
Business development 23% 13% 53% 9% 206

Marketing 16% 21% 48% 6% 9% 206

Operations 17% 18% 53% 6% 5% 213
2%
Support 17% 18% 53% 7% 213

Documentation 17% 17% 45% 8% 12% 215
2%
Sales 15% 16% 52% 14% 214
2%
Consulting 11% 17% 41% 29% 196

Base: technology industry professionals in a variety of roles, including but not limited to development



Figure 7 Agile Expands And improves The Sources of Product Decisions

Increase or decrease in the influence (very important/moderately important) of
different groups on product decisions since adopting Agile
Very important in uence
Moderately important in uence

Information about customer and partner requirements 20%
2%

Ideas from within the development team 11%
15%

Ideas from other groups in the company 5%
14%

Information about competitors’ o erings 3%
9%

-6%
Ideas from executive management 8%

AGIlE DEvElOPMENT CREATES THE NEED FOR AGIlE ENGAGEMENT
Agile development techniques can provide real benefits to technology companies. However, the
ability to reap these benefits at a company level will remain limited as long as technology vendors
treat Agile as strictly the development team’s concern.

To return to our automotive analogy, continued enhancements to an engine will result in marginal
improvements to the car’s performance. Without upgrading the drivetrain, components like the
differential set a hard limit on how fast the car can run. Worse, a faster car without more responsive
steering is a potential death trap for anyone driving it.

These questions of company-level benefits and efficiencies follow familiar economic principles:
Continued investment in only one aspect of a firm’s performance eventually reaches the point of
diminishing marginal returns (see Figure 8).



Agile Expands The Democracy Of Good Ideas
While other aspects of the relationships between development and other groups may see little or
no improvement, one element changes dramatically. Agile increases the degree to which “outsiders”
inform and influence decisions made within the development team.

It might seem easy to dismiss these results, as most Agile methodologies include “the voice of
the customer” — some procedural or organizational change designed to give customers a greater
say over the final product. While Agile teams might follow these guidelines — for example, by
recruiting some representative users to provide regular feedback — they might be congratulating
themselves for listening to advice that they don’t actually follow.

However, our survey results depict changes in product decision-making that are much harder to
dismiss. Agile contains no “voice of the rest of the company,” but our data clearly shows that groups
outside of the development team play a greater role in product and service decisions (see Figure 7).4

Equally striking is the one group that plays a smaller role in these decisions — executive
management. Agile teams work at too fast a pace and in too independent a fashion for executives
to micromanage them. Executives still retain the power to set strategic direction, shape the
product vision, and programmatically intervene at key decision-making junctures, but they cannot
haphazardly jump into and stomp on low-level (but potentially high-value) discussions of topics like
feature priorities and design options.



Figure 8 continuing To Tune The Engine Will bring Marginal benefits

Investment

Development Development plus
only other groups

Benefits

Agile Engagement Builds On Agile Development
The whole point of improving a car’s performance is to reach a particular destination — the finish
line in a race; home and the office during the daily commute — faster and more reliably. Similarly,
Agile as originally conceived had its own destination in mind: delivering value to the customer.

While Agile development improves some aspects of performance, the next stage requires Agile
engagement. Other groups in the company, not just the development team, must engage in the same
process. Inevitably, this means changes to how these different organizational components interact
with the engine of development.

For example, some gears connecting development and marketing rotate according to the speed
of product launches. The Agile development team might be capable of producing several small
releases each year. However, even the best marketing team has a limited number of opportunities to
craft new product messages and get the attention of the intended audience, including both existing
customers and prospects.

Nevertheless, running development at a higher speed can improve overall performance in other
ways. More frequent iterations that don’t necessarily get released nonetheless provide the marketing
team with several iterations of functional code, each of which can be the raw material needed for
collateral, demos, and other marketing deliverables.



Ultimately, these improvements and accommodations shorten the distance between development
and the customer. However, these improvements are only possible if a technology vendor treats this
process as a companywide engagement.

Agile Engagement Introduces New Requirements
Agile engagement changes many practical elements of Agile adoption (see Figure 9). As the scope
expands, the measures of success change. Just as engine RPMs can’t tell you the actual top speed or
fuel efficiency of a car, technology vendors must craft other metrics to capture how well the Agile
tune-up is succeeding at a company level. As the number of components increases, so too must the
number of tools needed to upgrade and tune them.

Figure 9 Agile Development Versus Agile Engagement

Agile development Agile engagement
Scope The development team, plus groups that The functions that provide and manage pathways
work most directly with it (QA, from product to customer, including marketing,
documentation, etc.) sales, service, and support.

Ambition Improvements to the process and output of Improvements to the ability of the company to
development teams. respond to market opportunities and threats.

Metrics Measures of development team performance, Measures of company-level capabilities and
such as length and predictability of release behaviors, such as the ability to change business
schedules, amount of code refactoring, and plans and reporting relationships to achieve
amount of working code checked in. company goals.

Delivery Products and services, on a more rapid Overall value to the customer, which depends on
schedule. the actions of support, sales, marketing, and
other groups, not just the contents of product
releases or service o erings.

Investment Based on estimates, such as use cases, of Based on estimates, such as sales forecasts, of how
how product and service decisions product and service decisions contribute to
contribute to overall product quality or company goals.
completeness.

Tools Support the actions of the development Support the actions within other groups and, in
team, such as project management, many cases, the working relationships among
application life-cycle management, and development and other groups.
automated testing and deployment. Examples include CRM win/loss data that can
inform product decisions and Web 2.0
technologies that can improve the speed and
e ectiveness with which product information
circulates through the company.




r E c o M M E n D AT i o n S

TUNE PERFORMANCE ONE COMPONENT AT A TIME
The second document in this series will describe what our research indicates are the best
predictors of success at Agile engagement and some best practices for achieving these results. For
now, it’s important to recognize that just as you don’t try to upgrade every component of a car at
the same time, the best strategy for technology company tune-ups focuses on one subsystem at a
time.

· Pick an acute problem to fix during Agile engagement. For example, let’s suppose that
customer-facing parts of the company, such as sales and support, do not receive full training
on a new product until six to nine months after its launch. here is an opportunity to deal
with an urgent need while at the same time demonstrating to the company what the “Agile
company” imperative is all about.
· Determine how Agile development contributes to the solution. An Agile development
team may already have pieces of the solution to this pressing need. For example, Agile often
changes the format and content of product requirements to a more story-based approach.
This information is easier to transform into a product demo for sales and marketing than the
traditional Word documents full of a very different kind of content.
· Reward improvements. if you don’t give employees incentives for participating in Agile
engagement, they will continue to focus on executing according to the priorities of their own
departments. To continue our example, someone within or close to the product team, such
as a product manager, needs to see tangible benefits to increasing the diffusion of product
knowledge immediately after the release. if not, product training might continue to take the
form of “show up and throw up” presentations that don’t provide much information to sales,
marketing, support, consulting, and other groups.
· Change the metrics. At the same time that you change rewards, you probably also need to
change how you measure the behavior being rewarded. For example, technology companies
usually measure post-release company readiness by activities that should increase readiness
but may not. rather than counting the number of 1-hour Webinars that product managers or
product marketers delivered, companies might instead survey support, consulting, sales, and
other groups to see how much they really understand about the new releases.
· Include your customers. Just as the “voice of the customer” needs to be included in Agile
development, it also plays a critical role in Agile engagement. For example, what sort of
post-launch product knowledge is it important that salespeople have? “improved” product
training for sales might equip salespeople with a lot of facts that aren’t really what customers
want to hear about the value of new product releases and service offerings.



W h AT i T M E A n S

AGIlE DEvElOPMENT CAN’T IGNORE AGIlE ENGAGEMENT
Agile is moving past the pioneer phase, in which Agile development teams play the role of frontier
outposts. While we can measure the progress of Agile by looking for more of these outposts, we
must also look at how these settlements mature and prosper. Just as trading posts transform into
larger, more complex settlements, Agile companies expand and replace Agile development teams.

As the number of Agile companies increase, the terms of Agile adoption will change. While the
first steps may still focus on changes within the development team, technology companies will
increasingly view these changes as only a first step. not only will the justifications for going Agile
include these larger, companywide ambitions, but executive management will be increasingly
eager to move from Agile development to Agile engagement.

SUPPlEMENTAl MATERIAl
Methodology
Forrester drew data from its December 2008 Global Agile Company Online Survey, which surveyed
229 technology industry professionals in a variety of roles to determine the effects Agile has on
company agility. We also interviewed the following vendors, as well as three that did not wish to be
named.

Companies Interviewed For This Document
Affiliated Computer Services (ACS) Protegra
BMC Software Quest Software
Borland Software Rally Software Development
Clickability Sabre Holdings
Danube Technologies Serena Software
IBM Singularity Limited
Kaiser Permanente Sybase
KANA Software ThoughtWorks
Liberty Mutual Insurance Company VersionOne
Lumeta XDx
OutSystems



ENDNOTES
1
By “Agile,” we mean the entire spectrum of iterative development methodologies inspired by the Agile
Manifesto.
2
In early 2008, Forrester estimated that approximately one-sixth of all software development teams had
adopted Agile, in some form, to some extent. See the February 6, 2008, “Enterprise Agile Adoption In 2007”
report.

For the complete Agile Manifesto, visit Manifesto for Agile Software Development (http://agilemanifesto.
org).
3
We assigned the following scores to each response about the quality of the relationship: very bad = 1;
moderately bad = 2; neither good nor bad = 3; moderately good = 4; very good = 5.
4
We asked our respondents to rate the importance of various internal groups in the decision-making process.
For the sake of simplicity, we have provided the percentage of respondents who indicated that particular
groups played a moderate or substantial role in product decisions.


Making leaders Successful Every Day

Headquarters Research and Sales Offices
Forrester Research, Inc. Australia Israel
400 Technology Square Brazil Japan
Cambridge, MA 02139 USA Canada Korea
Tel: +1 617.613.6000 Denmark The Netherlands
Fax: +1 617.613.5000 France Switzerland
Email: forrester@forrester.com Germany United Kingdom
Nasdaq symbol: FORR Hong Kong United States
www.forrester.com India

For a complete list of worldwide locations,
visit www.forrester.com/about.

For information on hard-copy or electronic reprints, please contact Client Support
at +1 866.367.7378, +1 617.613.5730, or clientsupport@forrester.com.
We offer quantity discounts and special pricing for academic and nonprofit institutions.

Forrester Research, Inc. (Nasdaq: FORR)
is an independent research company
that provides pragmatic and forward-
thinking advice to global leaders in
business and technology. Forrester
works with professionals in 19 key roles
at major companies providing
proprietary research, consumer insight,
consulting, events, and peer-to-peer
executive programs. For more than 25
years, Forrester has been making IT,
marketing, and technology industry
leaders successful every day. For more
information, visit www.forrester.com.

53565

Forrester Agile

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Forrester Agile

Similar to Forrester Agile (20)

More from Ram Srivastava

More from Ram Srivastava (20)

Recently uploaded

Recently uploaded (20)

Forrester Agile