__my.gartner.com_portal_server.pt_gateway_PTARGS_0_2640183.pdf

This research note is restricted to the personal use of Sebastien Blanchette ([email protected]).

Best Practices in Transitioning to Agile: Picking a Methodology21 March 2012 | ID:G00231958

Nathan Wilson

Picking a methodology is a key decision at the start of an agile transition. This research

guides IT leaders through the process of picking an initial agile methodology.

Overview

Key Findings

• More than 15 methods claim to be agile or agile compatible.

• For most organizations, Scrum is the best choice for agile projects, but there are alternatives that may be a better fit for specific situations.

• No off-the-shelf methodology will be a perfect fit for your organization.

• The ability to learn from experience and adapt the methodology to an organization

is more important than the initial choice of methodology.

Recommendations

• Do not try to find a perfect fit for your organization. Use the decision tree in this research to select a "good enough" methodology to start with.

• Make sure that there is adequate training available in your area for the methodology

you pick.

• Focus on methodologies that have a significant number of experienced developers in

the local labor pool.

• Use retrospectives to continuously review and adapt the process.

Analysis

What You Need to Know

Organizations transitioning to agile can spend a lot of time selecting an initial

methodology. By definition, these organizations have little to no agile experience when selecting the methodology; hence, they rarely make a perfect choice. Furthermore, few

mature agile organizations use an unmodified off-the-shelf methodology. Rather than

debating the best initial methodology, application development leaders should:

• Select a methodology that is a reasonable starting point

• Ask a single team to use the methodology in a pilot project

• Incrementally improve the methodology until it is ready for broader rollout

By selecting and piloting a methodology, you can gain the knowledge needed to create a

process that works for your organization and the proof points needed to drive agile

adoption.

The Journey Is More Important Than the Starting Point

Finding the best agile practices for your organization is a journey. No methodology is a perfect fit for a specific organization. By picking a good-enough methodology and using

retrospectives to learn from each iteration and project, organizations can tailor a

methodology that meets their needs. The research is intended to guide IT leaders to an

agile methodology that will be a good starting point for their organizations' agile journey. For a comprehensive list and descriptions of agile methodologies, see "Understanding the

Fundamentals of Agile Methods."

Page 1 sur 4Print Document

2014-01-01http://my.gartner.com/portal/server.pt/gateway/PTARGS_0_2640183_353_260_3460702...

This research is one of four reports in a series on transitioning to agile. The other reports

are:

• "Best Practices in Transitioning to Agile: Getting Started"

• "Best Practices in Transitioning to Agile: Scrum Coding Practices"

• "Best Practices in Transitioning to Agile: The Pilot Project"

Keep in mind that the best methodology for your organization today will probably not be

the best several years from now. Effective agile organizations continuously adapt their

processes and even change to new methodologies to improve them (see Figure 1).

Figure 1. Methodology Decision Tree

Source: Gartner (March 2012)

Kanban for Continuous Stream of Independent Tasks

While Kanban can be used for any software project, it is a better fit for a large number of

small independent tasks. In Kanban, the highest priority task is taken from the backlog and processed. This allows for the items in the backlog to be continuously modified and

prioritized without disrupting work in progress. For example, many organizations use

Kanban for production support, while an interation-based methodology like Scrum is used

for longer-lasting development efforts. The lack of interations or other project phase

structure can make Kanban more difficult for an engineer who is new to agile to understand. Kanban is one technique from lean Toyota Production System (TPS) and total

quality management (TQM) and often combined with before lean or Theory of Constraints

(see "Agile Foundation: Lean Software Development" — Note: This document has been

archived; some of its content may not reflect current conditions).

AgileUP/OpenUP for Strong Unified Process Organizations

Although core UP has been evolving to be more agile, there are several variants that

should be considered if an organization wants an even lighter-weight process. AgileUP and OpenUP are good choices for an organization that uses UP effectively, but wants to become



more agile. Both are based on rational UP (RUP) and, therefore, provide an easier transition to agile for UP practitioners.

The methodologies have a four-phase approach — inception, elaboration, construction and transition — that can be integrated with stage gate governance and funding. AgileUP, like

FDD, is suited to projects that require more formal modeling.

FDD for Agile Model-Driven

For organizations that want to keep a design-driven focus and still become more agile,

FDD can be a good choice. The use of a common project domain model makes FDD

attractive for problem domains that need early design validation or in areas with complex

concepts and relationships.

FDD has demonstrated it can scale to support large distributed projects and has natural

synergy with service-oriented architecture (SOA) and service-oriented development of applications (SODA), which aids team decoupling. Due to limited use in North America,

experienced practitioners may be difficult to find (see "Agile Foundation: Feature-Driven

Development" — Note: This document has been archived; some of its content may not

reflect current conditions).

DSDM Prince 2/PMBOK Integration Required

Atern DSDM is designed to work in conjunction with project management frames like

Prince 2 and to facilitate ISO9000/1 compliance with IT. It is a good fit for an organization

that must keep its development organization Prince 2/PMI certified, but wants to be somewhat more agile. It is a fairly heavyweight process, with an extensive guidebook, but

allows for agility in highly structured environments. Training and certification are available.

Due to limited use outside the U.K. and Europe, experienced practitioners may be difficult

to find (see "Agile Foundation: Dynamic System Development Method" — Note: This document has been archived; some of its content may not reflect current conditions).

Scrum for Everyone Else

Scrum's wide adoption and flexibility makes it a good fit for most organizations. Training and certification are widely available, and many experienced practitioners are available.

Scrum experience is a highly sought skill, resulting in generally high acceptance rates

among developers.

Scrum covers the basic agile concepts of:

• Self-organizing groups

• Incremental delivery

• Story-based development

Scrum provides great transparency into a progress. It has been proven in small and large projects worldwide. Scrum is highly flexible in coding practices. While this increases the

number of situations when it can be used, Scrum should be used in conjunction with

additional coding practices, such as TDD, pair programming and refactoring.

What About Extreme Programming?

Extreme Programming (XP) is probably the most publicized of all the agile methods, after

Scrum. The underlying principal in XP is to pick 12 agile practices and take them to the

logical extreme. As such, it is a great reference model, especially when it comes to coding practices. As a stand-alone methodology, it does not provide the organizational guidance

of Scrum, and some of the direct interactions and colocation with end users can be

impractical. There is, however, powerful synergy when you add XP coding practices into a

Scrum or Kanban managed project (see Figure 2, "Best Practices in Transitioning to Agile:

Scrum Coding Practices" and "Agile Foundation: Extreme Programming" ).

Figure 2. Methodology Matrix: Strengths and Weaknesses



Source: Gartner (March 2012)

Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

"'Just Enough Process' for Applications"

"Understanding the Fundamentals of Agile Methods"

"Agile Development Methodologies"

"Peer Practices: Software Development Practices"

© 2012 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication

in any form without prior written permission is forbidden. The information contained herein has been obtained

from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or

adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be

construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the

information contained herein or for interpretations thereof. The opinions expressed herein are subject to

change without notice.



Documents

__my.gartner.com_portal_server.pt_gateway_PTARGS_0_2640183.pdf