7/30/2019 Agile 1

1/8

THE AGILE MATURITYMODEL APPLIED TO

BUILDING ANDRELEASINGSOFTWARE

Jez Humble & Rolf Russell

2010 ThoughtWorks, Inc.

September 2009

7/30/2019 Agile 1

2/8

01

In this paper we present a maturity model for building andreleasing software. This model is designed to serve several

purposes:

To provide a structure for assessing your team or organizationalcapabilities in building and releasing software

To provide an approach for planning and executing improvements toexisting practices

We start with a discussion of the Agile Maturity Model, move on to building andreleasing software, present the maturity model, and then describe how to use it.

THE AGILE MATURITY MODEL

The Capability Maturity Model Integrated (CMMI) is intended to institutionalize acollection of pre-defined delivery practices and ensure their consistent execution so

as to increase the probability that a team or organization can successfully completeprojects. The definition of successful includes completing the project on time and in

budget.

In contrast, the Agile Maturity Model is an internal tool used at ThoughtWorks andother organizations to help organizations understand their current practices, andwork to improve them with the goal of increased ability to respond to changingbusiness conditions, and better harnessing innovation.

The model used here is a both a specialization and an adaptation of the AgileMaturity Model. Although we share the same goals as the Agile Maturity Model, we

have changed the definition of the levels so as to apply to the practices related tobuilding and releasing software.

BUILDING AND RELEASING SOFTWARE

The delivery of working software involves several activities beside development. In

particular, software must be turned into a form suitable for installation into its targetenvironment, subjected to various forms of testing, and then be released to users.

Our assertion is that this process should be performed continuously rather than as aseries of phases, with the aim of creating a fully automated, reliable, predictable and

visible process with well-understood, quantifiable risk.

7/30/2019 Agile 1

3/8

02

The Ideal State

Ideally each change made to your application, its environment, or their configuration,should go through an automated process. This process should create binaries, run

automated tests against them, and inform all relevant parties of the results of thisprocess. We call such a system the deployment pipeline.

It should also be possible for developers, testers, and operations people to have notonly visibility into this process, but also to be able to self-service processes such asdeployments to testing and environments and the release of applications at the push

of a button. Such processes also form part of the deployment pipeline.

THE MATURITY MODEL

In order to achieve our ideal, it is essential to cover all parts of the process ofbuilding, deploying, testing and releasing software.

Build management and continuous integration are concerned with creating

and maintaining an automated process that builds your application and runstests upon every change, and then provides feedback to the whole team on theprocess.

Environments consist of the entire stack your application requires to work:hardware, infrastructure, networking, application stacks, external services, and

their configuration.

Release management is defined by Forrester as the definition, support andenforcement of processes for preparing software for deployment to production.We have added considerations around compliance to this area, since

conformance to regulatory environments is often one of the strongestconstraints on release management.

Testing, whether through automated tests or manual processes such as

exploratory testing and user acceptance testing, is designed to ensure thatsoftware contains as few defects as possible, as well as conforming to non-

functional requirements. We have focused on the areas of testing that are mostrelevant to building and releasing software.

Finally, data management (usually, but not always, in the context of relational

databases) forms an essential part of the deployment and release process,since it is a frequent source of problems when releasing or upgrading software .

To ensure each part of the process is given due attention, we have divided the modelinto five sections.

7/30/2019 Agile 1

4/8

03

Practice

Level 3 - Optimizing:Focus on process

improvement

Level 2 - Quantitativelymanaged:

Process measured andcontrolled

Level -1 Regressive:processes unrepeatable,

poorly controlled, andreactive

Build management andcontinuous integrationTeams regularly meet to

discuss integrationproblems and resolvethem with automation,faster feedback, and

better visibility.

Build metrics gathered,made visible, and actedon. Builds are not left

broken.

Automated build and testcycle every time a change

is committed.Dependencies managed.

Re-use of scripts andtools.

Regular automated buildand testing. Any build canbe re-created from sourcecontrol using automated

process.

Manual processes forbuilding software. No

management of artifactsand reports.

Environments anddeployment

All environmentsmanaged effectively.

Provisioning fullyautomated. Virtualization

used if applicable.

Orchestrateddeployments managed.Release and rollback

processes tested.

Fully automated, self-service push-button

process for deployingsoftware. Same process

to deploy to everyenvironment.

Automated deployment tosome environments.

Creation of newenvironments is cheap.

All congurationexternalized / versioned

Manual process fordeploying software.

Environment-specicbinaries. Environmentsprovisioned manually.

Release managementand compliance

Operations and deliveryteams regularly

collaborate to managerisks and reduce cycle

time.

Environment andapplication health

monitored and proactivelymanaged. Cycle time

monitored.

Change management andapprovals processesdened and enforced.

Regulatory andcompliance conditions

met.

Painful and infrequent,but reliable, releases.

Limited traceability fromrequirements to release.

Infrequent and unreliable

releases.

Testing

Production rollbacks rare.Defects found and xed

immediately.

Quality metrics andtrends tracked. Non

functional requirementsdened and measured.

Automated unit andacceptance tests, the

latter written with testers.Testing part of

development process.

Automated tests writtenas part of storydevelopment.

Manual testing after

development.

Data management

Release to releasefeedback loop of

database performanceand deployment process.

Database upgrades androllbacks tested withevery deployment.

Database performancemonitored and optimized.

Database changesperformed automaticallyas part of deployment

process.

Changes to databasesdone with automatedscripts versioned with

application.

Data migrations

unversioned andperformed manually.

Level 0 Repeatable:Process documented and

partly automated

Level 1 - Consistent:Automated processesapplied across wholeapplication lifecycle

HOW TO USE THE MATURITY MODEL

The ultimate aim is for your organization to improve. The outcomes you want are:

Reduced cycle time, so you can respond faster to changing businessrequirement and increase revenue

Reduced defects, so you can improve your reputation and spend less onsupport

Increased predictability of your software delivery lifecycle to make planningmore effective

The ability to adopt and maintain an attitude of compliance to any regulatoryregime you are subject to

The ability to determine and manage software delivery risks effectively

Reduced costs due to better risk management and fewer issues delivering

software.

We believe that using this maturity model can help you achieve all of these

outcomes.

7/30/2019 Agile 1

5/8

04

Here are the steps to use the model, based upon the Deming cycle: plan, do,check, act1.

1. Identify where your organization lies on the model. You may find that differentparts of your organization achieve different levels on each of the differentcategories.

2. Choose what to focus on. You should work out what the possible improvementsyou could implement are, how much they will cost, and what benefit they willdeliver. You then choose a few improvements you could make, and decide how

to implement those changes. You should set acceptance criteria to define theresults you are expecting to see so you can decide if the changes were

successful.

3. Implement the changes. First, plan how to implement the changes. You mightdecide to start with a proof of concept. If so, choose a part of your organizationthat is really suffering - these people will have the best motivation to implement

change, and it is there that you will see the most dramatic change. Then ofcourse you have to execute your plan.

4. Check if the changes you implemented had the desired effect. Use theacceptance criteria you created. Hold a retrospective to find out how well thechanges were executed.

5. Repeat these steps, building upon your knowledge. Roll out more improvements

incrementally, and roll them out across your whole organization.

Organizational change is hard, and a detailed guide is beyond the scope of thispaper. The most important advice we can offer is to implement change incrementally.

If you try and go from level one to level five across your whole organization in onestep, you will fail. Changing large organizations can take several years.

Finding the changes that will deliver the most value and working out how to execute

them should be treated scientifically: come up with a hypothesis, and then test.Repeat, and learn in the process. No matter how good you are, it is always possibleto improve. If something doesn't work, don't abandon the process: try somethingelse.

1 W. Edwards Deming - Out of the Crisis, MIT Center for Advanced Engineering Study (1986) See

Management-driven Metrics Versus Metrics-driven Management,

7/30/2019 Agile 1

6/8

05

FURTHER READING

Build Management and Continuous Integration

Fowler, M., Continuous Integration,http://www.martinfowler.com/articles/continuousIntegration.html (2006).Duvall, P., Matyas, S., Glover, A., Continuous Integration: Improving Software Qualityand Reducing Risk, Addison-Wesley (2007).Humble, J., Read, C., North, D., The Deployment Production Line, Agile

Conference 2006 (2006).

Environments and Deployment

Farley, D., Single-Click Software Release, in ThoughtWorks Anthology, ThePragmatic Programmers (2008).Nygard, M., Release It!, The Pragmatic Programmers (2007).

Release management and Compliance

Lacy, S., Macfarlane, I., Service Transition, ITIL Version 3, Stationery Office (2007)Behr, K., Kim, G. and Spafford, G., The Visible Ops Handbook: starting ITIL in 4Practical Steps, Information Technology Process Institute (2004)

Testing

Crispin, L., Gregory, J., Agile Testing: A Practical Guide for Testers and Agile Teams,

Addison-Wesley (2009)

Data Management

Ambler, S., Sadalage, P., Refactoring Databases: Evolutionary Database Design,

Addison-Wesley (2006)

Agile Maturity Model

Pettit, R., An Agile Maturity Model?, Agile Journal (2006)

AUTHORS

Jez Humble

Jez Humble is Product Manager for Cruise, ThoughtWorksStudios' continuous integration and release managementserver. As the founding leader of ThoughtWorks' build and

deployment community, he has worked to capture andpropagate best practices in the build engineering and release

management space.

Jez has ten years of professional experience in IT as adeveloper, system administrator, trainer and manager. Hehas worked with a variety of platforms and technologies,

7/30/2019 Agile 1

7/8

06

consulting for non-profits, telecoms, financial service and insurance service

organizations. Since 2004 he has worked for ThoughtWorks in London, Bangalore,Beijing and San Francisco. He holds a BA in Physics and Philosophy from Oxford

University and an MMus in Ethnomusicology from the School of Oriental and AfricanStudies, University of London.

Rolf Russell

Rolf Russell is Practice Director for Build & ReleaseManagement at ThoughtWorks. In this role he isresponsible for the development of ThoughtWorks'service offerings that enable clients to achieve more

throughput, transparency, security and speed-to-marketin their build and release processes.

Rolf has been a part of ThoughtWorks for seven years ina variety of roles including developer, trainer, projectmanager, innovation facilitator, and as a member of the

North American Operating Committee. His interest hasdrawn him to the build & release world and, prior to becoming Practice Director, Rolfled several teams executing significant B&RM projects. Before joiningThoughtWorks, Rolf worked for a supply chain intelligence startup and for Oracle

Corporation as well as teaching English in Japan. He holds an MSc in ArtificialIntelligence from Edinburgh University and a BS in Computer Science from Cornell

University.

ACKNOWLEDGEMENTS

Thanks to Tim Brown, Rebecca Parsons, Ross Pettit, and Andy Yates for comments,contributions, and feedback.

ABOUT THOUGHTWORKS STUDIOS

ThoughtWorks Studios is a global leader in Agile ALM tools and training. Its productsand services are used by organizations as a foundation for sustainable Agileadoption, where project management, automation and engineering best practices arerequired. The companys Adaptive ALM solution provides a platform for managing all

aspects of the software development lifecycle, from requirements definition andproject management to test automation, quality assurance and release management.The three products that make up Adaptive ALM, Mingle (project management), Twist(test automation) and Go (release management), are available as an integrated

solution or as stand-alone products. The company also provides in-depth trainingcourses that cover all aspects of Agile ALM through it Agile Workshops series.

Backed as an independent division of ThoughtWorks, the pioneering leader in Agile

development and best-practices, ThoughtWorks Studios customers include 3M,

7/30/2019 Agile 1

8/8

Honeywell, BBC, eBay, Barclays, Vodafone, McGraw-Hill and Rackspace. It isheadquartered in San Francisco and Bangalore, with offices in London and select

cities in Europe, Asia and Australia. For more information, please visitwww.thoughtworks-studios.com.

For more information, please visit www.thoughtworks-studios.com.