I spend a lot of time working with large organisations who want to adopt agile, typically they have heard their competitors are having great success with agile and are worried about being left behind or worse they believe adopting agile is going to be the answer to all their problems – but unfortunately there is a big difference between saying “let’s be more agile, starting tomorrow” and implementing agile successfully across the organisation.
One particular client told me “we’ve got whiteboards and post-its everywhere, I’ve hired a tonne of people in T-shirts and jeans but agile is just not working”, when I asked whether their agile teams had a clear understanding of what they needed to achieve and an associated target timeline he looked at me blankly and said “we’ll have to ask them” which tells me everything I need to know.
Most companies typically start using agile to build websites, it’s relatively low risk and agile is perfect for building websites because changes can be made rapidly following user feedback then pushed to live immediately. So everyone gets a slap on the back, smiles all round, agile is working, hooray.
The problem is, it’s not agile, it’s Hippy Agile and it simply will not scale.
What do I mean by Hippy Agile? When there is no goal to aim for, delivery teams drift. They do great work, they mean well, they do what they think is right but they plod along without a care in the world and the result is typically an over bloated product delivered in timelines that are far beyond the original estimation. And everyone blames agile.
Think of it like having your budget cut, the day your boss breaks the news that next year you’re getting 10% less budget your hands go up in the air and most likely your response is “it’s impossible, I can’t do the same for less”, but then you sleep on it and you talk to the team and you find a way – innovation, creativity, a small saving here and there, before you know it you’ve trimmed 10% and maybe you’re even able to produce MORE next year.
Hippy agile is the same, it’s 5pm on Thursday, you still have plenty on the backlog but you hit a few snags earlier in the week and so you’re behind. Stay late and get it done or go home and do it tomorrow? Will it matter if some of it falls into the next sprint?
Deadlines and milestones force good behaviours, they make teams more innovative and creative and they stop feature creep, it’s also great for the team to have a common enemy. The tricky part is getting the milestone date right.
By definition estimates cannot be 100% accurate but agile teams have two perfect weapons at their disposal:
Burn ups are a great way to track how the team is progressing towards that goal and I’ve found them a really useful tool when talking with my stakeholders about progress – the real truth is that if the milestone starts to look under threat it forces the right kind of conversation: cut features, do something different, add resources or accept the milestone needs to move.
Implementing agile is hard, scaling it beyond a handful of teams is even harder – software engineering needs to be treated as a science, the most successful examples of scaling agile I’ve seen is with organisations who understand the science, apply lean principles and are fanatical about measuring and improving, removing bottlenecks and managing team performance.
Agile is a ‘hands on’ sport… it’s not for spectators.