10 Things to make you Agile adoption successfull

One of the closing slides in my Agile Foundations course includes a quote from Ken Schwaber saying that only 30% of teams who attempt Scrum will be successful. What I find interesting about this quote is that it aligns with many other change management studies. Researchers like Harvard Professor John Kotter regularly say 70% of major change efforts fail.

On his blog Ken Schwaber says he doesn’t remember this and instead suggests only 30% will become “excellent development organizations.”

Either way, the prognosis isn’t optimistic. A few months ago, at the end of the course, someone asked the obvious question, a question so obvious I wonder why nobody has asked it before: “What can we do to ensure that we are in the 30% who make it?”

Given that I had the Managing Director, the Director of Technology and most of the technology team in the room it was an excellent opportunity to set the change agenda. And I fluffed it, despite having written a book on the subject I didn’t have a quick answer to hand. But it set me thinking: “What are the 10 things a team can do to make Agile (any flavour) stick?”

Here then is that list, the team in the room will recognise the first three, it was after that that I had to think.

1) Use a physical board: over the last year I have become convinced that the single biggest difference between teams which successfully adopt Agile working and those who try, fail, or end up stuck is the use of an actual physical board.

I know some teams find this difficult, I know some teams are distributed, I know there is technology out there to do this for you but I stand by my point. If you can make it physical, in a place where many, if not all, can see, then you are more likely to succeed.

2) Start collecting and using statistics and other data: velocity, burn-down, bugs identified, bugs logged, etc. etc. Metrics have a bad name in software development – rightly in most cases. But that only means that have been badly collected, managed and used, it doesn’t mean they aren’t useful. At the very least measure your velocity and create a burn-down chart or cumulative flow diagram of the work to do or arising.

3) Engage a coach/consultant: at the risk of being accused of trying to make work for myself I should say you can adopt Agile all by yourself. You can read the books, you can experiment, you can go on courses. But doing it without help makes the whole process slower and increases the risk that you won’t make it to the 30%.

Personally, I find it difficult to know just how an Agile Coach differs from an Agile Consultant. What ever you call the role you want someone who can:

  • Provide advice on which practices and process to adopt, and how to best adopt them
  • Offer examples of what they have seen work, and not work, elsewhere, and how other team tackle similar issues
  • Observe, examine, query and challenge your thinking on what you are doing
  • Challenge your thinking and point out opportunities and idea that you haven’t seen yet

You may need to work with multiple advisors since few will be able to cover all process, practice, technology, product and strategy bases. On very large team it might be worth having full-time consultants although the model I have had most success with is light-touch coaching in tandem with a pull-change model (below).

I don’t believe such an advisor needs to be full time. I practise, and have written before about, light-touch Agile coaching, in this model I return to companies at intervals, perhaps monthly, perhaps more frequently, sometimes less frequently and continue the discussion.

4) Action over talking: action speaks louder than words, until you start trying to do Agile you can’t foresee all the issues and questions which will arise. The longer you spend talking about doing it, and not actually doing it, the more it anticipation will build up, the more more it will look like jus another management fad.

By all means talk about it, plan a bit but there is no real substitute for just getting stuck in and doing it. In particular do not spend your time agonising over whether to do XP or Scrum, or Lean or FDD, or DSDM or Kanban. They are all pretty much of a muchness and you will end you up crafting your own hybrid anyway.

Likewise, discusses a few weeks ago: don’t waste your time looking for evidence, make your own.

Planning your way to Agile is anathema, just do it – JFDI.

5) Give everyone training and start group wide discussions: teams don’t get to be Agile by management deeming “thou shalt be Agile” – although plenty of managers and team leaders have tried the approach. Reading books works for some people but most books go unread, or the words go in one eye and out the other.

If you want to be Agile then invest in taking the time to explain to people what it is. But don’t stop there, make time for people to talk about what Agile is to them, what they like, don’t like, will do, won’t do. Agile is a team sport and unless the team have a shared understanding they will be playing different games.

6) Enthuse, Pull, don’t Push: Anyone who has worked around companies for a few years will have seen management pushing the latest change initiative: ISO 9000, Sig Sigma, CRM, ERP, etc. etc. Someone dreams up these ideas and then a change machine sets about pushing them out.

Apply a lean principle: Pull, don’t push. Forbid the words “change management.” Enthuse individuals and teams, have them ask for Agile. And when they ask give them the help and support they need. This works at the individual level, at the team level, at the company level.

If you are in management this means you need to engineer a pincer movement: you want enthusiasm for change coming from the bottom up to meet your support coming top down. Introducing Agile top-down alone is, in my opinion, as quite likely to kill it – employees are, rationally, skeptical of top-down management change. We live in a post-modern, post-BRP, post-layoffs, post-recession, post-everything world. Employees aren’t children they’ve heard what happens.

Rather than impose change from the top down managers need to build, kindle people’s curiosity, get people asking questions and for help, create bottom-up change initiative and support it. Do everything build the fire without extinguishing it.

The good news is the Agile marketing machine may already have got there ahead of you. People may already be curious about Agile, or even keen to try it – they may even be doing it when you are not looking. If not then find ways to stir interest. When they come asking for support – for budget for speaker, trainers or coaches – or time to go to conferences, give it, give it generously. Offer more, ask when else they need, and above all else: learn to change your own behaviours to match.

7) Be clear on Why you are going Agile: what ever level you are, engineer, tester, project manager, director, look beyond the Agile hype. What is the problem you want “Agile” to fix for you? Understand why you want change and what you expect from it.

Don’t just “get Agile” because it is this month’s fashion, get “Agile” to achieve something more important.

8) Process and technical, Adopt technical side as well as process side: don’t think you can just change the process and it will all be all right. You need to address the technical side too, you need to improve quality, you need to support the engineers, testers and others who are at the code face doing the work.

I’ve come across big companies who view the technical side as somehow dirty: the attitude seems to be “thats technical” or “ they get their hands dirty” or “we can ship it to [Low cost country of choice this week]”.

Get your hands dirty, talk to engineers, adopt Test Driven Development, refactoring, shun big up front design architecture, learn to live with rough designs and evolving architecture. There are real feedback loops here.

9) Get Product Management/Owner flow to developers clear and clean: it isn’t just about fixing the coding side, the requirements side needs to be addressed to. Specifically there needs to be a clear path from someone who represents requirements – typically called a Product Owner or Product Manager and frequently staffed with a Business Analyst – and the development team. Far more negotiation is going to happen over “what” then “when”. Someone needs to represent – and have authority – over that side of things.

10) Structural changes – Functional groups: Staff your teams to do the work for which they are responsible, end functional groups – i.e. database developers and UI developers in separate teams. This is just the first of more structural changes you will need to make. But if you fail at this you won’t get to play again.

There you go, each of those items could be an entry in its own right, maybe one day they will be. Thats enough to get you started. If there was an eleventh is would be: let go of the past, things change, Agile isn’t purely additive. If you don’t stop doing some of your current things you will never see the full benefit. But 11 can wait, those 10 will get your a long way.

Points based contracts? Just Say No.

With the points-mini-series still fresh in the mind now seems a good time to say publicly something which I’ve been saying privately for a long time.

Avoid points based contracts. i.e. don’t outsource work, or undertake work, on the basis of points – be they story points, abstract points, nebulous units of time or any other name you give them.

I have one client at the moment who wants their software supplier to sign a points based contract, I’ve advised against it. Another client is trying to sell points based contracts to their clients, while they are having some success – I think they rushed in before they had enough data to understand the implications.

Why do I say this? Well three reasons

First is Goodhart’s Law: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” Put it another way: any measurement metric will change behaviour once it is used for control.

In this context it means: points are very good at measuring story size and team velocity, they can be accurate at predicting when a piece of work will be done. But, if you use them for other purposes – like regulating a contract and making payments – they will change their behaviour. They won’t be so useful for predicting end dates, or for controlling contracts for that matter.

This is a problem many readers will be familiar with from traditional time estimation. Estimates are nominally sought to determine how long a piece or work will take, and thus how much it will cost. But they are also used as a means of targeting and for control. They are used as a proxy for commitment and they are gamed (i.e. changed for specific ends) when they don’t give the time/cost numbers desired. (This is something Esther Derby discusses recently in her blog, Estimating is often helpful, estimates are not.)

In fact, time estimates show the same range of problems present in the corporate budgeting processes and which has given rise to the beyond budgeting movement.

One direct result of Goodhart’s Law in this context is…

Inflation, the second reason to avoid points based contracts: points are subjective, they are not grounded in time, complexity, function point analysis, lines of code or any other objective measurement. They are in fact like a fiat currency: they are worth what you can buy with it. If people don’t believe in it, or believe the value will change then it will change. Check out rational expectations theory if you want to understand why.

Overtime points can devalue with the result that point scores increase. Actually, I believe the free floating nature of points is one of the strongest reasons for using them but in terms of signing a contract it makes them useless.

Most teams I see work in low points: 1, 2, maybe a 5, rarely an 8, they score 10, 12 or maybe 20 an iteration. One team I saw worked in tens, and scored hundreds each iteration. It was like one of those old Space Invaders machines were the last digit was a hard coded “0”.

The team’s project manager finished planning meetings with an call for the team to work harder next iteration, to reclaim the lost time. Iteration on iteration velocity increased. Inflation was rampant.

Finally there is practicality. As the recent posts from myself and Vasco Duarte demonstrate points, there is still a lot of debate over points. Personally I have come to the conclusion that exactly how you run iterations and count points makes a big difference. While if you agree with Duarte you might as well dispense with points and sign story based contracts.

Then there is the team: only the team which will do the work can accurately say how many points a piece of work will, or did, take; and then only when they have experience of doing the work. So you shouldn’t sign a points based contract unless you have the team in place and they have done some of the work.

Even a relaxed interpretation of that last point should lead you to conclude you should only sign a points based contract when the team is experienced in using points and you have historical data. If you feel you must sign a points based contract then only do it when you have data.

Still, I’d rather you didn’t do it in the first place.