You are on page 1of 10

March 24, 2009

Ensure Success For Agile Using Four Simple Steps


by Dave West for Application Development & Program Management Professionals

Making Leaders Successful Every Day

For Application Development & Program Management Professionals

A Simple Approach to Agile Adoption And implementation


by Dave West with Mike Gilpin and David DSilva

Ensure Success For Agile Using Four Simple Steps

March 24, 2009

ExEcUt i v E S U M MA ry
In the effort to improve the way applications professionals develop and deliver software, Agile methods focus on changing traditional software development and delivery activities, artifacts, and responsibilities. Application development professionals can significantly smooth the Agile adoption process by concentrating on four key steps that focus on selecting the right projects for Agile adoption, deciding which Agile practices to adopt, working more closely with the business, and keeping the momentum going after the initial implementation. By following these four simple steps, applications professionals can improve their companys adoption of Agile and help ensure successful, long-term change.

tAbl E o F co ntE ntS


2 Agile Implementation Failures Occur When Companies Miss The Basics Failure is Far Easier than you Expect the business Does not Want to See behind the curtain 3 Follow Four Simple Steps To Ensure Agile Success Step one: Pick the right Projects And Deliver results Early Step two: Keep Momentum Going Step three: Make organizational change, Not Agile Development, the Main Focus Step Four: Make the business Part of the Solution
rEcoMMEnDAtionS

n ot E S & rE S o U rcE S
Forrester interviewed 17 vendor and user companies, including Accurev, bluecross and blueShield of nebraska, borland, cognence, cynergy Systems, Danube technologies, HP, rally Software Development, SE2, tata consultancy Services, thoughtWorks, and Wells Fargo.

Related Research Documents the PMboK And Agile: Friends or Foes? January 22, 2009
Make Agile lean to boost business impact December 17, 2008 lean Software is Agile, Fit-to-Purpose, And Efficient December 12, 2008

7 Make Agile Adoption Agile

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.

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

AgIlE IMplEMEnTATIOn FAIluRES OCCuR WhEn COMpAnIES MISS ThE BASICS Agile methods are becoming increasingly popular, but their adoption is proving problematic and prone to failure.1 Application development professionals can avoid the mistakes that drive these failures by following some basic practices. A project manager at a large European insurance company stated, The difficult things we do well, but we always seem to get the easy things wrong. Failure Is Far Easier Than You Expect Firms are still failing more often than they should when implementing Agile processes. By concentrating on the basics, you can quickly implement a sound working process that draws on the best practices for applying Agile methods. If you fail to get these right, it will lead to common problems:

Practitioners may feel tempted to return to old ways. When problems occur with the new

Agile process, it is too easy for practitioners to return to the traditional document-centric, handoff-oriented, bug-and-fix approaches they have followed for years. This can happen explicitly with the team deciding to return to traditional approaches, or with individual members returning to old thinking and approaches. Ken Schwaber, the creator of Scrum, said: A large number of the Scrum projects I encounter are following an approach thats far from optimum. Teams say they are following Scrum, but in reality they are doing what they have always done under a different name.

Teams may dismiss Agile as just another trend. The sometimes-faddish nature of

management theory coupled with brief tenures for the CIO means that some teams see initiative after initiative discussed, plans put in place, and then nothing really changing. A project manager at a large financial institution described the feeling at his company: Teams are skeptical about the latest buzzword or trend coming from senior management. In the majority of cases, these trends just fizzle out after a few workshops or just add more work to their lives.

Lack of documentation and detail may scare management. Even if individual pockets of

management buy off on the value of not producing wasteful documentation and large detailed plans, most management still takes comfort in these artifacts, as these are the artifacts over which it has most control. When Agile methods remove these work products, management often feels that its ability to manage has been greatly undermined.

The Business Does not Want To See Behind The Curtain In his article IT Doesnt Matter, Nicholas Carr tells us that, as with many technologies, business at first views IT as an important and differentiated aspect of the fabric of the company but later views IT as a commodity that provides no competitive advantage.2 This tendency leads many executives today to treat IT work as a separate stream of activity that they can measure solely by cost or delivery schedule. Compounding this problem is that most business leaders still have a poor understanding of software development. A senior manager at large IT vendor illustrated this point, describing how he left development to try to help the marketing organization understand how development works: I moved from development to marketing to make sure that the rest of the value chain worked better.
March 24, 2009 2009, Forrester research, inc. reproduction Prohibited

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

The IT planning process is a great example of this misunderstanding: Business leaders drive their IT departments to plan based on little or no understanding of the problem space, believing that a 10-page document can describe complex business problems in enough detail for IT to develop a software solution. It is not that the business is malicious in its relationship with IT or that IT does not know how to ask the right questions; rather, everyone ignores the elephant in the room because the other party has always ignored it. This dysfunctional relationship leads to:

A planning process disconnected from a real understanding of the solution. At the start of
each financial year, the business identifies its list of key business initiatives or strategic plans. Leaders expect IT to provide a budget and delivery dates with no real understanding of the problem or the range of possible solutions.

Business stakeholders disconnected from the development process. Once a project is under

way, its hard to gain access to business people to help define scope or validate a solution. The business is focused on todays work rather than planning for tomorrows. This disconnect between the business and the development team leads to wasted time and effort as no one steps up to resolve issues and make the correct decisions.

Long and boring requirement documents that nobody reads. With traditional development,

documents are the primary means of conveying understanding, status, and issues. These documents often serve many different stakeholders and thus become long and complex, as they must describe the problem for several distinct audiences. Too many organizations schedule back-to-back meetings and provide very little time for reading these documents.

FOllOW FOuR SIMplE STEpS TO EnSuRE AgIlE SuCCESS By following four simple steps, you can establish an environment that encourages success. The four steps will also help you build strong working relationships with the business and other external stakeholders, which will ensure that they no longer sit on the sidelines highlighting problems but instead become part of the solution. Step One: pick The Right projects And Deliver Results Early Forresters research has identified five characteristics that can help you select the first project that you should target for adoption of Agile practices (see Figure 1). Each characteristic has both a positive and a negative implication to the success of that project. For instance, selecting a project where access to the business is easy and strong working relationships already exist will make the transition to evolving customer requirements and experimentation much easier; however, it may confuse customers who already understood how to work with their IT partner. By focusing on projects that exhibit some or all of our recommended characteristics, you can increase your chances of delivering results early, as these characteristics will pinpoint projects where there is more motivation to deliver and where the typical obstacles to delivery are not present.

2009, Forrester research, inc. reproduction Prohibited

March 24, 2009

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

Figure 1 Five characteristics For Project Success With Agile Development


Project characteristics The project has failed before. The good If Agile is the last hope for a business initiative, this may provide the business and IT groups with the desire to throw away traditional approaches and risk a di erent way of working. The bad The project failed before for a reason; Agile development approaches may not solve problems associated with that initial failure and may in fact just make those problems more visible. The current approach is working and the trust is there for a reason. Rede ning the relationship between IT and the business in the context of Agile may be seen as a waste of time. Enthusiasm can often change to depression when other groups ignore or belittle new ways of working. If speed is the only objective, then development can become chaotic and heroic rather than controlled and team-based. If a team does not consider technology outside its comfort zone, its solutions may become bloated and overly complex.

IT is allowed to make Having a large amount of trust decisions quickly and has between business and IT coupled with access to the stakeholders. easy access to the right people often works to demonstrate how an organization or group can work in an Agile way. The project team is sta ed with people who want to try something new. Having the desire to change is the rst step to change. Without the commitment and drive of the team, new ways of working often fall to the wayside. When increasing speed-to-market is crucial, the group often wants to change the way it works to ful ll that need. If the development team has a great understanding of the technology context for the proposed solution, it will be more able to make quick decisions.

The business needs IT to deliver working software faster. The development team is mature and understands the technology.

54037

Source: Forrester Research, Inc.

Step Two: Keep Momentum going After the initial focus on Agile development and project success, development leaders often lose focus, assuming that the changes will become part of the fabric of the organization and therefore everyone will continue to follow them. A number of our interviewees described situations where after initial success, project teams returned to traditional approaches. A project manager at a large financial company said that without someone reminding people what they should be doing, they always seem to want to return to traditional hand-off-oriented approaches. To keep the Agile momentum going after implementation:

Keep mixing it up. By introducing new ideas to the team and continually challenging the

status quo, you create an environment where change and continuous improvement is the norm. Examples of such continuing innovation that we found during the interview process included the introduction of new development tools, new engineering practices, and regular education sessions on new technology.

March 24, 2009

2009, Forrester research, inc. reproduction Prohibited

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

Focus on the right measures. When companies establish measures that highlight the value

of a certain new process, teams are more likely to follow that process. For instance, if you measure burn down and velocity, a team is more likely to follow a process like Scrum where those measures are more natural. If you include test coverage as a key measure of success, then highlighting the relationship between requirements and testing may encourage developers to use a test-driven approach.

Communicate success. Though communicating success sounds obvious, the majority of

organizations do a poor job of communicating within the development group. By introducing both formal and informal mechanisms to communicate project success and by encouraging that communication with team incentives, IT management can set up opportunities for teams to learn from each other. One example of such a mechanism our research found was project showcases where project teams present their innovations to the department.

Step Three: Make Organizational Change, Not Agile Development, The Main Focus Too many Agile projects fail because the main focus of the implementation is not improving the way IT delivers software but instead simply adopting Agile principles and practices. When Agile itself is the focus, it is too easy to introduce practices that add little value or that are in fact disruptive. Instead of making Agile development the focus, concentrate on:

Delivering software. In most cases, organizations trying to adopt Agile approaches were

building software prior to this adoption. If they focus mainly on using Agile development processes rather than on improving the delivery process, applications professionals will forget many of the good practices that were already in place. By following the maxim if its not broken, dont fix it, organizations can make sure that they focus on the problems with their existing process and apply Agile approaches to fix those. For example, for a company with a long, drawnout requirements process that produces low-quality requirements, adopting Scrum with a focused product owner and the use of stories is a good solution, whereas pair programming would be irrelevant.

Introducing a life cycle that supports many development approaches. A software development

life cycle (SDLC) describes the process of software development in detail, prescribing activities, artifacts, and responsibilities for the team to follow. This approach conforms to the idea that the better the process, the better the software, and the more detailed the process, the easier it is to follow. There are many problems with detailed SDLCs, the biggest one being their inability to support many different project types. The more detailed the SDLC and the more specific the process, the less flexible it becomes. Instead of following the approach that explains the process in great detail, describe the SDLC as a series of milestones and achievements. In this approach, each development process must define the activities and artifacts necessary to deliver the material evidence necessary to move the project through a particular milestone. This allows teams to decouple the process from the life cycle or governance framework.

2009, Forrester research, inc. reproduction Prohibited

March 24, 2009

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

Focusing on practices rather than processes. One interesting trend is organizing processes

into a series of practices. IBM has used this approach in the new releases of the Rational Unified Process (RUP), describing it as a series of practices running within a process kernel or life cycle.3 A practice-based approach allows a much more modular adoption method, enabling teams to introduce a small number of practices in response to a particular pain point. The practice-based approach is much more consumable and usable, as it delivers process material in small chunks instead of in long, complex descriptions.

Step Four: Make The Business part Of The Solution It is easy to adopt Agile methods as an IT organization, even filling key business roles such as product owner with IT people such as business analysts. This can be the path of least resistance because Agile adoption is often driven by the IT organization and not across both IT and the business. However, the problem of business involvement presents an opportunity to adopt Lean Thinking to reduce the friction of Agile adoption.4 To be successful with Agile methods, the IT organization must involve the business. Some of the best ways IT can involve the business include:

Including business stakeholders in Agile training. It is easy to focus training efforts on the

development team and its IT management. But involving business people in the training brings two key advantages. First, involving business representatives helps them understand the problems that Agile methods are trying to address and better appreciate why the new approach will help them. Second, involving business representatives exposes them to Agile methods terminology and style, which will reduce the culture shock that they might experience when first working in or with an Agile team. Training sessions should be either management- or practitioner-oriented. Involving the right business people in each of these forms of training is important, as: 1) including business practitioners who will be involved with the day-to-day activities of the team in the practitioner training helps build team spirit; and 2) including business management in overview and management training will create a shared understand and will help set expectations.

Making the business part of the team. Agile methods such as Scrum provide an explicit role

for the business on the team.5 The person in the product owner role is responsible for defining priorities and making business decisions. Because of structural, budget, and resource issues, a business analyst or project manager both of whom are within the IT organization often play this role. Other Agile methods also encourage active business involvement, as they support the principle of customer collaboration as defined in the Agile Manifesto.6 Business involvement is crucial, but it is too easy to ignore this and make the team IT-centric. To avoid many of the problems associated with customer involvement, include business representatives as members of the team from day one. The business does not need to hold a formal role, as in Scrum, but can function the product owners or business analysts partner.

March 24, 2009

2009, Forrester research, inc. reproduction Prohibited

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

Ensuring that dashboards are available to business management. One of the key tenets

of Agile methods is transparent communication. Agile teams communicate frequently, documenting team progress, issues, and problems in information radiators where everyone can see them.7 By surfacing this information for the business and explaining what it means, an Agile team can build trust with the business. Also, when IT organizations experience problems and communicate them on the dashboards and radiators, it is surprising how helpful business people can be in their suggested resolutions, often coming up with non-IT ways to resolve issues.

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

MAKE AgIlE ADOpTIOn AgIlE


Agile approaches focus on delivery and constant customer feedback, and the process of adopting Agile would benefit from the same focus on delivery and constant customer feedback. An Agile approach to adopting Agile sounds strange but is very effective. to support an Agile approach to adopting Agile:

Start small and focus on delivering results. rather than changing the whole department,
focus on a subset of development projects and a subset of Agile practices for those projects. by focusing delivery on the most valuable practices and the most valuable projects, you are much more likely to succeed. For example, start with the adoption of Scrum, and leave all the other existing practices in place. once a project has adopted Scrum and is doing it well, then you may want to begin adding other practices incrementally as the maturity and capability of the team increases.

Measure the improvement. As you add each new practice, measure its success (or failure),
identifying how this practice improves the delivery approach. this measurement does not have to be empirical but can include more-subjective, soft measures such as improved relationships with the customer or with it operations.

Select initial projects for a reason. For any change to be successful, there must be a reason
for that change. For example, the reason for choosing to implement Agile on a particular project could be tight deadlines or previous project failures. Employ these reasons as catalysts to Agile adoption, using them to help drive through the organizational, process, and governance changes that success requires.

Focus on process improvement rather than Agile methods. implementing Agile methods
should never be the end goal; instead, the ultimate objective must be delivering software in the most effective and efficient way. Deploy only the practices that make the most sense in support of your goal. this may include Agile practices, existing practices, and other practices from other sources such as the Project Management body of Knowledge (PMboK).8

Increase stakeholder involvement. by identifying the key friction points between the Agile
team and other parts of the organization, you can determine who you should involve in the rollout. by including these stakeholders, training them, and in some cases making them part of the team, you can build support for Agile throughout the organization.
2009, Forrester research, inc. reproduction Prohibited March 24, 2009

Ensure Success For Agile Using Four Simple Steps


For Application Development & Program Management Professionals

EnDnOTES
1

For more information on Agile adoption rates, see the February 6, 2008, Enterprise Agile Adoption In 2007 report. There are many versions of this particular article that was published in the Harvard Business Review in May 2003, but for the most-up-to-date thinking on this topic, visit Nicholas Carrs Web site (http://www. nicholasgcarr.com/articles/matter.html). For an interesting discussion on the Rational Unified Process and how it is to be structured around practices, see Per Krolls presentation for the IBM Rational Software Development Conference 2008 entitled Enabling the Agile Enterprise through Incremental Practice Adoption (http://www-07.ibm.com/in/events/ rsdc2008/presentation/Day%202%20PPM%20Track/1_2%20PPM%20Enabling%20the%20Agile%20 Enterprise-Per%20Kroll.pdf). For a discussion on introducing Lean Thinking to the business as a way to advance the use of Agile methods in development groups, see the December 17, 2008, Make Agile Lean To Boost Business Impact report. There are many documents, books and Web sites that describe Scrum. Perhaps the best of the sites is the one that Ken Schwaber created (http://www.controlchaos.com/). The Agile Manifesto can be found at http://agilemanifesto.org/. Information Radiators was a term coined by Alistair Cockburn in his book entitled Agile Software Development. Source: Alistair Cockburn, Agile Software Development, Addison-Wesley Professional, 2001. The Project Management Institute (PMI) provides a comprehensive set of practices focused on the discipline of project management. More information on the PMI and PMBOK can be found on the PMIs Web site (http://www.pmi.org/Pages/default.aspx).

6 7

March 24, 2009

2009, Forrester research, inc. reproduction Prohibited

Making leaders Successful Every Day


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

Forrester Research, Inc. (Nasdaq: FORR) is an independent research company that provides pragmatic and forwardthinking 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.

54037

You might also like