Agile ≠ agility
Agile is having a rough time of late, and perhaps rightly so.
For many this disillusion with Agile, or at least the version that forms the basis of what I’m calling the anti-Agile movement, started a long time ago. For me, it began when I watched Erik Meijer’s talk, ‘One Hacker Way’, just last week. If you haven’t seen it already, then I’d recommend watching before reading on.
Much of Erik’s and the movements’ arguments against Agile usually begin by discussing the downsides of something I like to call ‘Bastardised Scrum’ — a process for developing software where the roles and meetings have lost their meaning, it doesn’t suit the environment that you’re working in, and is only being used because someone told you it would help you achieve twice as much in half the time.
How can you tell the difference between this version of Scrum and others? Well, here are just a few telltale signs:
- Does the Product Owner frequently open planning meetings with phrases like “Marketing have asked us to build this feature as they have a customer that will buy our product if we build it”?
- Is the Daily Standup currently used solely as a forum for discussing what you all ate for dinner last night?
- Perhaps your user stories and sprint commitments need to be signed off by other stakeholders before the team can begin working on them?
If you’ve noticed any of these things then run! Get out while you still can!
While I wholeheartedly agree that this process causes more harm than good, the rest of the arguments against Agile and its various methodologies are, for me, less clear cut. This is largely because they cherry-pick elements, which are more often than not misused, misinterpreted and misunderstood, preferring to focus on the consequences of poorly implemented processes, masquerading as an execution of the Agile principles, rather than the actual principles themselves and the subsequent mindset shift they were intended to create. If you ever heard someone say “we’re doing Scrum so therefore we’re agile”, then you’ll know what I mean.
Of course, there are a number of topics, which have been raised as a result of this movement that we should acknowledge such as, recognising the role developers (and other ‘Makers’ for that matter) play in building great products and powering successful organisations. However, for someone that is relatively new to Agile, Erik’s talk, the proposed alternatives and the many articles that have sprung up in the last year articulating a similar discontentment, while having merit, strike me as a little premature.
Don’t get me wrong I still think that Agile deserves a thorough interrogation, as it’s clear its intended beneficiaries have become disillusioned with how it is being implemented and perceived. What’s more, if we don’t address this now then I feel we may dismiss something that has the potential to be truly useful. I’m not saying that Agile will help solve every problem, as that’s frankly quite far from the truth, but I do think approaching problems with agility is one tried and tested way we can improve communication and reduce unnecessary waste — particularly people’s time and money when they could be spent on better things.
So how do I think we can refocus people’s attention on what I feel is the most important aspect of Agile, actually being agile?
1. Stop with all the jargon.
- Stop calling it Agile. Start saying that you develop products with agility, that you are responsive, not just at a team-level but also organisationally.
- Stop saying things like prioritisation or value optimisation. Start saying that you’re working on what you currently believe to be the most important thing first.
- Stop giving team members titles or roles. Start calling everyone developers. After all we should all seek to play a valued role in developing a product, whether that role involve design, writing code or coaching. If you can’t justify that you play a role in developing a product then either figure out how you can help those that do or get out of the way.
2. Be agile with your implementation of any process.
- Only use the elements that given the team and the current situation are needed. If you think something will help, suggest it to them, making sure to clearly articulate why you think it will help in plain English. If they do decide to give it a go then constantly seek feedback on how it can be made better. And just like features that no one uses anymore, retire any elements that are no longer working for the team.
- Don’t be afraid to cross-pollinate. Steal and adapt elements from every existing methodology, framework and mindset. Whatever you think will help.
3. Truly embrace change.
- Start by questioning everything. Why are you using Agile? What impact is it having on your business? How is it making your team(s) happier? How is it making your customers happier? Would anyone notice if you stopped using it? I could go on…
- Regularly put you, your team, your product and your organisation just outside of their comfort zone. However, you choose to do this doesn’t necessarily matter. It will feel uncomfortable at first (that’s the point after all), but if you are to develop with agility and be responsive then you need to continually expand upon what is ‘normal’ and gain feedback about your performance so that you are better prepared for change. Just take care not to damage anyone or anything in the process.
“Progress is impossible without change, and those who cannot change their minds cannot change anything.” — George Bernard Shaw
Give it a go. Start small. Then reflect and adapt.