I’ve worked with organisations at various stages of their Agile transition, during which I’ve seen Agile implemented well, but I’ve also seen it done terribly. In a break from my usual tradition of myth-busting, I wanted to share some hard won lessons from my years as a Scrum Master, and give you some tips to help your Agile transformation succeed where many fail.
Dazed and Confused
I’ll admit, starting out on your Agile journey is a daunting prospect; recent years have seen an explosion in the number of Agile methodologies available. Picking your first framework is a lot like buying your first car, you go into it with a very strong feeling of what you think you need. However, what you think you need, and what you actually need are very different and it’s only possible to truly understand which is which until you’ve driven it around for a few months. For a first step into Agile, my best advice is to read a good primer on Scrum (I recommend this one) and just jump in.
All or Nothing
When you’re getting started it’s tempting to want to do it gradually, pick out the easy bits, do those first, and then gradually introduce new concepts until you’re ‘fully Agile’. I’d strongly recommend not to use this approach. The transition to Agile is a tough one, and by spreading it out over many months, you’re elongating how long this pain lasts, whilst also delaying the time when you can really start reaping the benefits of being an Agile organisation. Humans are also creatures of habit: every opportunity to cling to the old ways that you give them, they will take; and as the pool of what they are familiar with dries up, they will cling ever tighter to the small details from the old ways. By this point you’re trying to tackle the hardest bits of the transition, and this sort of emotional investment in how things used to be only makes it tougher.
You Can’t Always Get What You Want
I’ll occasionally run across people who sell Agile methodologies as some magic bullet that will fix all organisational problems. In a sense this is true, but to an extent – take a saw for example, saws are great for cutting wood with, but the best saw in the world still needs a skilled carpenter to use it. Agile methodologies are tools, and they are only as good as the people using them. Crucially, going Agile won’t magically fix all of your problems. What it will do is paint huge neon targets over every problem your business has, but you need a great team of people to step in and solve them.
Go Your Own Way
Once you’ve been Agile for few months, and I highly recommend doing it by the book for at least your first 3 months, you’ll get a sense of what doesn’t work for you and where things can be tweaked. This is a great time to look at other Agile techniques, and gradually introduce them into your process. This seems to contradict my ‘all or nothing’ advice, but there’s a subtle distinction here. All or nothing is the best way to get people out of their old mindsets – throwing them out of their comfort zone will force them to adapt initially. However, no Agile framework is going to tick all your boxes off the shelf; once you’ve got some core Agile values in place, you can start tailoring things to better suit your needs. As we’re fond of saying around here – prototype fast, then iterate.
Don’t Stop me Now
Most companies want to adopt a form of Agile in order to produce better software quicker – don’t get me wrong, that’s a great ambition. My problem is that most stop there. A part of me feels like this is a bit of a waste. Agile principles can be applied to a much wider spectrum than most people realise, but it’s rare to hear stories of an Agile finance team or HR departments using Scrum, though I’m sure they must exist somewhere. Once you’re comfortable speaking the Agile language, do your colleagues a favour and see if there are others around who might benefit from the lessons you’ve learned along the way. For my part, I’m planning my upcoming wedding with a nifty looking Kanban board: