###### tags: `agile`

# Agile Adoption Patterns (Richard Durnall)

_taken from https://web.archive.org/web/20090827091137/https://www.richarddurnall.com/?p=57_

I find the patterns that emerge from repeated tasks really interesting. When I first started coaching teams there was no way I could give the team or the organisation any predictions about what they were about to go through. A few years later I find it’s a very different story. I’ve found that no matter the industry, city, size or culture of the organisation, things always break in a common order…

## (1) The People Break

The first thing that starts to hurt are the people. A big ‘orrible coach comes in and starts to introduce crazy ideas and people naturally push-back. They will make a lot of noise, some will adapt, others won’t, but the people within the organisation will be the first barrier to change. I’ve never worked on an engagement where we haven’t been able to get through this first challenge. Applying models like the Dreyfus model (of skill acquisition) and other change management approaches improves our chances of being successful at this stage. We have to stick with it - this stage will pass.

## (2) The Tools Break

Once the people have settled into the new model, they often start to prefer the improved levels of control and collaboration. The next thing to start to hurt are the existing development tools and platforms. Traditional tools are often barriers to the team working as effectively as possible. Examples could be heavy duty portal frameworks that make continuous integration a time consuming chore or automated test tools that don’t support developer/tester collaboration. Change can be hard at this stage as often these products have a large amount of organisational investment behind them, in the form of both money, time and professional reputation. It’s important to develop plans to deal with these issues as soon as possible as they quickly become barriers to throughput. Tool support can become a huge constraint.

## (3) The Governance Process Breaks

Suddenly our governance groups are getting different information from different projects. Our waterfall projects are providing status reports based on task completion, spend and utilisation; our agile projects are providing data based on working software, risk and value realisation. And of course the information from the agile team is much more volatile. It takes a little time to develop a model of consolidating the information and understanding of how to effectively apply it. It’s also worth spending some time to develop methodology selection criteria for our project portfolio at this stage.

## (4) The Customer Breaks

By now our teams have started to hit the point where things are starting to work for them. The velocity is increasing quickly every iteration before it reaches a point where it will stabilise. Our new problem is that the teams are demanding increasingly frequent decisions from the business customer - a once a week meeting isn’t going to cut it. We have to start to think about the longer term business engagement model and how we manage the time required from our business customers to successfully deliver projects.

## (5) The Financial Controls Break

We’ve now delivered a few pilot projects and the results have been good. The business teams have enjoyed the new model and in particular the control that they have over delivery. Our new problem results from our traditional cycle planning process. Historically, we’ve sat down before the start of the financial year and taken a guess at the initiatives that we want to deliver - we’ve then committed ourselves to delivering them. We’ve now got a process that lets us experiment and adapt and we want to maximise it’s usefulness. We don’t want $9M up front to deliver the project, we want $100k to market test the base product and we want to do this for 6 products. Our cycle planning and product pipeline has to change.

## (6) The Organisational Structure Breaks

This is really about getting the best return on our investment. At a management level we often underestimate the impact of introducing agile at the layers higher up the organisational chart. What we often find is that sooner rather than later our constraint becomes that chart. Our working practices are driven by our management structure, performance reward models, strategy deployment processes and the like. The organisations that I’ve seen get the best results are the ones that have made the most significant changes in this area.

So what use is all of this information. Well, what it means is that if we know that it’s going to happen then we can plan for it. We can perform readiness assessments prior to initiating the change activities to mitigate and manage the barriers that we will encounter. Interestingly, we often can’t plan the solution; organisations break in different ways and the solution is often dependent on context. What we can do is prepare to deal with the problem and develop options based on experience that are likely to help.

Have you seen any interesting organisational change patterns that you’d care to share?