Agile, what the hell is going wrong?
By: Andrew Wetherell
Tags: Agile Transformation, Agile, Scrum, Agile Methodology

Late last year I was sitting in a quaint little cafe, waiting for my next meeting and overheard a discussion between two senior business people from one of our favourite large Australian corporations on Scrum. Intrigued, I listened in to learn how some of our business leaders think about the exciting framework which is Scrum, and the conversation went along the lines of something like this:

Man 1: What do you know about this Scrum thing that the engineers are using now?

Man 2: It’s this new Agile shit where the engineers work in 2-week cycles to deliver faster than before. I think it is to set deadlines on teams so they do more work.

Man 1: It sounds like a way to just get lazy people to do work.

Man 2: What the teams don’t even realise is that it can be used for business work as well!

Man 1 & 2: Both laugh with glee at their superior intellect figuring out that Scrum can, in fact, be applied to business teams.

I might have paraphrased a bit and this jolly exchange was probably closer to two years ago but you get the point. While this discussion was going on, there I was sitting thinking “Jesus, if this is the state of senior leaders’ understanding of agile how bad must it be in their teams?”.

Now, to be fair to those gentlemen and anyone else who doesn’t understand Agile it is not their fault. It has been poorly communicated and wrapped into frameworks such as Scrum without any context on what the hell you are trying to achieve other than a vague statement of “increased productivity” or “culture transformation”.

As such, I am going to navigate through common agile myths, debunking ideas where relevant and explain the principles behind Agile in short, layman terms.

Agile Myths

Scrum = Agile. Agile as a term refers to a set of 12 principles which teams and organisations can strive to work with, it is not a framework. Scrum is a project management methodology which is conducive to Agile principles, however, I guarantee you will never see good results if you apply these frameworks by the book without understanding why each practise/ritual is relevant within the framework and how to adapt it for your business. The same goes for any scaled agile framework such as SAFE, you must understand it before applying it. The word “Agile”. The most successful thing to come out of Agile is the use of the word as everyone’s favourite new go-to buzz word. Anyone who practises the principles would never say “we’re doing this in a really agile way”, that just tells me you have no clue what you are talking about. The fault lies with the founders for choosing a term which has pre-existing associations and meaning, like calling a new toilet paper brand “Coarse”…how do you think that will go? Disassociate from the word, I don’t care what you call it, it is about good operational practice. Agile means no planning. There is this destructive idea that doing things in “an agile way” means you don’t set any objectives, milestones or other plans. Let me be very clear, the Agile principles are about execution, not strategy. You absolutely need clear objectives which the team are rallied around, and these should not change. The only reason your objectives will change is because they were shit in the first place, such as some vague statement about what you want to achieve rather than actionable and measurable outcomes that are clear to every team member and track to your long-term goals based on good market research and customer understanding. Agile short-term gains. At the heart of Agile it is cultural, the principles guide how people strive to operate. As such, it is about the long-term, not the short. You can’t justify ‘agile transformation’ with ROI or other short-term metrics. Anyone worth half their weight in strategy knows you balance the short-term gain with long-term capability building and that you need to invest today to be competitive tomorrow. A note to any agile coaches or transformation leaders who tell the executive they don’t know what they’re doing, you should realise that neither do you if you aren’t communicating how a culture working with agile principles hits long-term company objectives (this means key performance indicators, not a washy statement about people and change). Agile doesn’t apply to my industry. The principles won’t always be applicable, but more often than not they will work and if you’re a good company it is very likely that you are using most of the principles without ever calling it Agile. I will use marketing as an example and paraphrase Mark Ritson who puts it greatly: “brand managers are like the parent of an ugly child. They think their child is beautiful and important to the rest of the world when they’re not. Brand managers think the same about their brands”. In other words, stop thinking your brand is special to everyone, go out and understand how customers actually perceive you and what they want from you. Stop sending us 100 emails a week with crap no one cares about — principle #1, customer-first.

Agile Principles in Layman Terms

Customer-First: Work backwards from the customer experience. Go out into the real world as frequently as possible, shut up and listen to your customers and learn what they want. If customers tell you your product is shit, then it is. Stop fiddling with solutions before you know your problem and stop playing with new technology and realise it’s all a tool to deliver solutions, no one cares if you are using blockchain, ‘AI’ or any other tool. Support Change: If your customer tells you they don’t like what you’ve delivered, or someone on the team figures out a better way to deliver the work, then support this change. It is not a change in objectives, it is a change in how you get there. Deliver Frequently: The faster you deliver work, the faster you can get feedback and ultimately fail. This helps you ensure that your work is adding real value and that it is aligned with what the customer (or any recipient) wants. If something is 80% of the way there in the first week of work then show it, don’t wait another 3 weeks to do the last 20% of work and find out it was all shit. Interdisciplinary Teams: The more diverse the team is the better the idea generation and delivery will be. Interdisciplinary teams, that is, business people with developers etc, ensures that work is aligned across departments and objectives. Autonomy & Trust: Give your teams clarity in what they are trying to achieve in the form of very simple, measurable objectives that they are excited to achieve, then let them figure out how to get there. Give the support they need along the way to reach the objective, but the people on the ground are closer to the problems and better fit to figure out the best path to achieving the company objectives. Face-to-Face: Face-to-face communication is best (not exactly possible at the moment). This creates the strongest bonds across teams and enables instantaneous feedback and brainstorming within teams. Real Output Shows Progress: Use real work output to measure progress, not an update saying my report is 50% there, show me the report. Demo’ing real work also helps to keep the whole team in the know of what work is being done and engages the rest of the team in our work. Sustainable Work Pace: Keep the workload to a sustainable pace. You don’t need to run a business like Steve Jobs, make sure your people are not burning themselves out by trying to deliver unrealistic deadlines. High Standards: Maintain attention to doing great work, we don’t want to get lazy on output for the sake of fast delivery. Your goal is not to put out crap for feedback, but it is to balance between that and spending 4 weeks on a report that was at 80% within the first week and now you’ve spent 3 weeks doing shit all when you could have got feedback and delivered a much better result overall. Focus: Do one task at a time. You can’t deliver 10 things at once. You are much faster and deliver a far better quality when you focus on completing a task at a time and avoid context switching every 30 mins because you are trying to progress on multiple tasks at once. If your team has 10 objectives to hit, then talk with your manager because that is shit strategy which means good operations can’t happen. Self-Organising Teams: Let the people on the ground tell you what skills and resources they need to deliver great results. The outcome will always be better if you let the team figure out how to deliver and who they need to deliver because they are closer to the problems. However, encouraging frugality is still important, a team shouldn’t be rewarded for headcount, they should be for results. Continuous Improvement: Regularly review how you can improve as a team and organisation to deliver greater benefits overall. Use the other principles as areas to reflect against, or use anything else that you see as important to improve on.

Final note

Hopefully by now you are feeling some relief and understand that Agile is all about principles, not framework. However, I don’t really care what you call it, it is about great operations and the principles represent an attitude of how people work. The principles are also not the be-all and end-all. Seek to understand why each one is effective and how to implement it really well, but also explore far beyond these principles because what is relevant to you really depends on your company objectives. For example, if I worked in IDEO the design-thinking pioneers, I would imagine that Creative Confidence is a principle which they encourage and build.

Finally, if there is one most important takeaway that I want you to have, it is THINK FOR YOURSELF. Agile has been a shambles partly because it has been badly communicated, but also because we keep applying frameworks without any clue why. If you are a manager or executive implementing Agile without understanding it and you want to know how bad this feels for those who understand Agile, go ask an engineer to apply a strategy framework and see how shit the outcome is, this is what you’re doing by requesting Scaled Agile Frameworks or any other form of framework.