forrester agile

Making Leaders Successful Every Day

May 6, 2009

From Agile Development To Agile Engagementby Tom Grantfor Vendor Strategy Professionals

www.forrester.com

© 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 [email protected]. For additional information, go to www.forrester.com.

For Vendor Strategy Professionals

ExEcuTiVE SuMMAryAgile 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.

TAblE oF conTEnTSAgile Tunes The Engine, But The Rest Of The Car Needs An Upgrade

Agile Methodologies Have Focused More On The Engine Than The Car

What Happens If You Only Upgrade The Engine?

Agile Development Creates The Need For Agile Engagement

rEcoMMEnDATionS

Tune Performance One Component At A Time

WhAT iT MEAnS

Agile Development Can’t Ignore Agile Engagement

Supplemental Material

noTES & rESourcESForrester surveyed 229 technology industry professionals in a variety of roles to determine the effects Agile has on company agility. To supplement the survey data, Forrester interviewed 24 technology companies.

Related Research Documents“company Agility Evaluator”February 24, 2009.

“inquiry insights: Agile Development”october 6, 2008

“Agile Product Management Makes Agile Technology companies”october 7, 2008

“Make Agile lean To boost business impact”December 17, 2008

May 6, 2009

From Agile Development To Agile EngagementAgile Might Start in Development, but it can’t Stop ThereThis is the first document in the “Agile company” series.

by Tom Grantwith Peter burris, Dave West, and Madiha Ashour

2

2

5

10

14

15

15

mailto:[email protected]

www.forrester.com

www.forrester.com

http://www.forrester.com/go?docid=47136&src=53565pdf





© 2009, Forrester research, inc. reproduction ProhibitedMay 6, 2009

From Agile Development To Agile Engagement For Vendor Strategy Professionals

2

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,

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


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

Source: Forrester Research, Inc. 53565

“Our highest priority is to satisfy the customerthrough early and continuous delivery ofvaluable software.”

“Business people and developers must worktogether daily throughout the project.”

“At regular intervals, the team re�ects on how tobecome more e�ective, then tunes and adjustsits behavior accordingly.”

Goal of the Agile Manifesto Implied changes beyond the development function

“Welcome changing requirements, even late indevelopment. Agile processes harness changefor the customer’s competitive advantage.”

Collecting and analyzing customer issues through product management, sales, support, and other customer-facing groups.

Building a collective early-warning system among development, marketing, and other groups to identify important market shifts.

Working with business development to recruit partners to�ll in technology gaps faster and more e�ectively than thevendor can address them.

Arranging regular customer feedback in person through product management or virtually through additions to the company Web site, such as innovation management and community sites.

Handling these assessments across departments to takeinto account the downstream e�ects of Agile adoption(for example, marketing’s ability to handle more frequentproduct launches).



4

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


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

“How complete is your implementation of Agile?”

We have a mature implementation of Agile methods

35%

We are midway in our adoption of Agile 33%

We have just started adopting Agile methods

17%

We are still evaluating Agile and have not yet begun to adopt it

17%

Our implementation of Agile failed

4%



5

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


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


“Has Agile changed the frequency of product releases?”

More frequent 67%

No change 30%

Less frequent 3%



6

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).



7

Figure 4 companywide information increases With Agile Adoption

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.


Moderately improved 34%



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

Signi�cantly improved15%

No change 40%

Moderately worse, 2%

Signi�cantly worse, 1%Don’t know

7%



8

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


Moderately improved 38%



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

Signi�cantly improved19%

No change 27%

Moderately worse, 8%

Signi�cantly worse, 2%Don’t know

5%



9

Figure 6 Agile has Minimal impact on Working relationships


171

144

235

231

229

231

236

238

240

238

217

Base: technology industry professionals in a variety of roles, including but not limited to development Source: December 2008 Global Agile Company Online Survey

Consulting

Sales

Documentation

Support

Operations

Marketing

Business development

Executive management

QA

Product development/ engineering

Product management

5 — much better 4 3 — no change 2 1 — much worse I don’t work with this group

5 — very good 4 3 — neither badnor good

2 1 — very bad I don’t work with this group

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

39% 26% 25% 6% 2%

39% 23% 30% 3% 2%

34% 27% 30% 5% 3%

23% 28% 40% 5% 3%

23% 13% 53% 2%

9%

16% 21% 48% 6% 9%

17% 18% 53% 6% 5%

17% 18% 53% 2%

7%

17% 17% 45% 8% 12%

15% 16% 52% 2%

14%

11% 17% 41% 2%

29%

N=

156

124

210

207

206

206

213

213

215

214

196

Consulting

Sales

Documentation

Support

Operations

Marketing

Business development

Executive management

QA

Product development/ engineering

Product management

“How would you rate the quality of your working relationship with other groups?”6-2

N=

47% 25%

58% 24%

48% 28%

46% 30%

36% 28%

33% 29%

31% 35%

33% 32%

34% 23%

29% 28%

27% 21%

14% 4% 4%

5%

6% 6% 6%

12% 5% 6%

13% 7% 3%

17% 5% 12%

17% 3%

8% 11%

20% 5% 9%

19% 7% 8%

18% 7% 17%

19% 3%

6% 15%

14% 4%

33%



10

Figure 7 Agile Expands And improves The Sources of Product Decisions

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).


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


Increase or decrease in the influence (very important/moderately important) ofdifferent groups on product decisions since adopting Agile

Very important in�uenceModerately important in�uence

Information about customer and partner requirements

Ideas from executive management

Information about competitors’ o�erings

Ideas from other groups in the company

Ideas from within the development team

2% 20%

8% -6%

9% 3%

14% 5%

15% 11%



11

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.



12

Figure 8 continuing To Tune The Engine Will bring Marginal 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.


Investment

Benefits

Development only

Development plus other groups



13

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


Scope

Metrics

Delivery

Agile development Agile engagement

Ambition

Investment

Tools

The development team, plus groups that work most directly with it (QA, documentation, etc.)

The functions that provide and manage pathways from product to customer, including marketing, sales, service, and support.

Improvements to the process and output of development teams.

Improvements to the ability of the company to respond to market opportunities and threats.

Measures of development team performance, such as length and predictability of release schedules, amount of code refactoring, and amount of working code checked in.

Measures of company-level capabilities and behaviors, such as the ability to change business plans and reporting relationships to achieve company goals.

Products and services, on a more rapid schedule.

Overall value to the customer, which depends onthe actions of support, sales, marketing, andother groups, not just the contents of productreleases or service o�erings.

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

Based on estimates, such as sales forecasts, of how product and service decisions contribute to company goals.

Support the actions of the development team, such as project management, application life-cycle management, and automated testing and deployment.

Support the actions within other groups and, inmany cases, the working relationships amongdevelopment and other groups.Examples include CRM win/loss data that caninform product decisions and Web 2.0technologies that can improve the speed ande�ectiveness with which product informationcirculates through the company.



14

r E c o M M E n D A T 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.



15

W h A T 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)

BMC Software

Borland Software

Clickability

Danube Technologies

IBM

Kaiser Permanente

KANA Software

Liberty Mutual Insurance Company

Lumeta

OutSystems

Protegra

Quest Software

Rally Software Development

Sabre Holdings

Serena Software

Singularity Limited

Sybase

ThoughtWorks

VersionOne

XDx



16

ENDNOTES1 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.


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.

Australia

Brazil

Canada

Denmark

France

Germany

Hong Kong

India

Israel

Japan

Korea

The Netherlands

Switzerland

United Kingdom

United States

Headquarters

Forrester Research, Inc.

400 Technology Square

Cambridge, MA 02139 USA

Tel: +1 617.613.6000

Fax: +1 617.613.5000

Email: [email protected]

Nasdaq symbol: FORR

www.forrester.com

M a k i n g l e a d e r s S u c c e s s f u l E v e r y D a y

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

Research and Sales Offices

53565

For information on hard-copy or electronic reprints, please contact Client Support

at +1 866.367.7378, +1 617.613.5730, or [email protected].

We offer quantity discounts and special pricing for academic and nonprofit institutions.

www.forrester.com

mailto:[email protected]