It’s interesting to see how Agile development has evolved, a very good article from Forrester….

There is a session on Agile methodology in the upcoming Architect Council on 10 Jun. Stay tune….  :-)

Executive Summary

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.

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.(see endnote 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, 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. 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

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

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

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.

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).(see endnote 3)

Figure 6: Agile Has Minimal Impact On Working Relationships

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).(see endnote 4)

Figure 7: Agile Expands And Improves The Sources Of Product Decisions

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.

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

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.

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

RECOMMENDATIONS

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.

WHAT IT MEANS

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.

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.

External source: http://www.forrester.com/Research/PDF/0,5110,53565,00.pdf