Skip to content
Feb 10 / richard durnall

Agile Adoption Patterns

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?

4 Comments

Leave a comment
  1. Michael A. Smith / Feb 10 2009

    Hi Richard, thanks for this terrific post. Your insight is uncanny to me.

    In my first experience in a small agile team, I witnessed things break in exactly the same order that you are mentioning. My team’s project was one of two that were experimenting with an agile process at the time in our company. However, we were never coached and everything was very touch-n-go.

    Our team begun and seemingly thrived on lean (or subtle?) management, quick feedback cycles, and a seeming abundance of technical resources that were always delivered just-in-time. Things seemed great. In some sense, “people breaking” never took place because this was the plan from the beginning.

    Eventually, our tools broke. Our source control was too much of a bottle neck, our testing deployment process did not have enough automation, and other various technical obstacles weighed us down. Once management corrected the majority of our issues, we were back on a decent pace.

    All of the details of “governance breaking” within our organisation were not fully aware to me, yet there were a few issues I observed and became aware of concerning my PM’s ability to manage our project and another that seem to exhibit what you are referring to.

    Similarly, “financial controls breaking” possesses some details for which I am not intimate, but I did observe our organisation struggling to accommodate a new pricing plan they were not used to implementing for our project, collecting those funds based on deliverables/requirements, planning accordingly compared to the other pay up front projects they had going on, and so on. As the entire world was going into an economic downturn, I’m sure this did not help matters.

    Finally, the organisational structure most certainly broke and was NEVER seemingly assessed or repaired. We experienced a loss in employee motivation based on the limited opportunities and incentives (advertised incentives were also being revoked!). Employee assessment happened too infrequently. Developers wanting to naturally adjust the requirements of their positions toward a more lean system were met with denial. Management positions and organisation changed without making anything clear to underlings than who their new direct was. Role responsibilities were made less transparent in the restructure. Entire development teams were made redundant due to client budget cuts. Directs were incapable of satisfying the technical/requirement needs of their development teams, either by choice or deficiency. Mutiny occurred at a management level. Transparency into managerial practices and personal/organisational goals reached zero.

    I tendered my resignation and I will be starting a new, better job next week.

  2. richard durnall / Feb 11 2009

    Hey Michael,

    Thanks for your response; I’m really glad that the post resonated with you.

    From experience I’ve found that the organisational changes required are the changes that folk are least prepared for and most reluctant to deal with. They are also the ones that create the greatest breakthroughs.

    I’ve found that we can short-cut a lot of these issues by performing short assessments upfront – I plan to write a post on what in my opinion makes a good assessment soon. It would be good to get your thoughts on what kind of impact such an assessment would have had at your previous company.

    Best of luck with your new job!

    Thanks,

    Rich

  3. Michael A. Smith / Feb 12 2009

    I’ll be looking forward to your post :)

    Thanks and good luck.

Trackbacks and Pingbacks

  1. Agile Readiness Assessments at Agile & Lean Software Development by Richard Durnall

Leave a comment