top of page
Search

How to fail at Agile in 8 easy steps




So you're in charge of your organisations structure, performance or delivery approach. You've been doing this for years and sure, projects don't often come in on time and on-budget, but you've been praised many times for your ability to bring a burning project across the line or for identifying the people responsible for their failures. Now all of a sudden everyone is talking about 'Agile'. They say crazy things like 'No more projects' and 'complete transparency' and 'No big up front planning'. You know it's nonsense. Your last 30 years in the industry tells you everything you need to know. The problem is this 'Agile' Buzzword isn't going away. The CEO wants it. The board wants it. You can't just make it go away or they might make YOU go away. Well don't worry, because this guide is going to lay out 8 simple steps to follow to absolutely guarantee that your Agile 'transformation' will fail. Not only that, but you'll once and for all kill any enthusiasm for change so you can get back to comfortably doing what you've been doing for the last few decades.

-Disclaimer- This article is a satire aimed at common missteps in attaining agility. The hope is to point out common pitfalls. Any resemblance to any real persons or organisations, living or dead, well it's just sad really isn't it?


1. Never allow cross functional teams


The first and most important thing they will tell you about becoming agile is that you need 'cross functional teams'. They'll say that all the people with the skills and knowledge to achieve an outcome should work together on a day to day basis. Well obviously, that's just impossible as it would mean a change in the status quo and there's no way you as a leader can be expected to make that successful! So, all you need to do is move around some project managers and BA's, call them 'Scrum teams' and no one will really notice. Make sure these teams don't have everything and everyone they need to actually deliver value or they might go ahead and do that despite all your other hard work. You wouldn't want them making this look easy. Better yet, make sure key people who have the ability to completely derail the work if they are not present are stretched across many different teams with no clear guidance of where to spend their effort.


2. Use as many Agile buzzwords as possible

If item 1 is the most important to ensuring failure, then item 2 is where we ensure everyone blames and forever hates 'Agile'. Make sure your dependent and siloed teams are called scrum teams. People need to know they 'tried going agile' and it didn't work.

Try changing your projects into 'Epics'. You obviously can't be expected to approach the work in a different way and move to the continuous delivery of customer value, but if you call everything an 'Epic' people will just assume you're a high functioning Agile org! While you're at it, start talking about 'Story points' instead of hours. Don't worry, they're exactly the same thing. Some people might complain that we're supposed to be moving away from absolute measures of time because this is something humans are terrible at. They might even say that 'real' story points allow us to empower teams to provide real insights into the complexity of the work. That's nonsense. Hours are hours and this allows us hold people to account when they say that the project should only take 17268 hours but it ends up actually taking 18021 hours. The point here is to make sure to keep throwing out as many Agile buzzwords as possible. This serves two purposes; It stops anyone from questioning whether you're actually committed to this Agile thing, and it ensures that everyone will hate 'Agility' by the time you're done. Win-Win.


3. Never Limit work-in-progress


People will keep telling you that you need to 'limit work-in-progress'. It's as though we live in some bizzarro world where you can go faster by doing LESS. Yeah right. We want to be making forward progress. The more projects we have on the go, the more chances there are to get the next phase of something across the line. Importantly, you want to make sure every person always has something to do. The last thing you want is people wasting time 'thinking' or 'talking'. 100 percent utilisation is 100 percent cost-efficiency so load it up and enjoy the buzz of hundreds of people desperately trying not to drown under the weight of 10 years of work.


This applies to your teams too. If it looks like they might actually reach the end of a sprint having achieved all their goals, well this is just a sign that they are under-committing!


4. Don't measure anything


You might find Scrum masters love to talk about 'inspecting' and 'adapting'. They'll tell you we need all these fancy dashboards to tell us our 'burn' and our 'cycle time'. All they're really doing is try to find a way to justify their salary. As if demonstrating that we're releasing more often or getting better customer feedback over time could tell us whether the project will be successful. You and your fellow managers have developed instinct. Gut feel. All this does is take power away from you and allow teams to make informed decisions on their own. That's the last thing you need!


5. Surround yourselves with Agile Coaches with plenty of Project Management experience


Agile Coaching is a relatively new phenomena, so you might struggle to find real experienced coaches. Thankfully, you don't want or need them if you want your Agile journey to fail. Lucky for you, there are thousands of ex Project Managers out there that have been on a 2 day introductory certification to some agile framework and you can just throw them at the problem and watch as everything gets confused and muddy.

Now you probably have a bunch of Project managers currently in your org. They have tremendous value on certain kinds of work, but just make them Scrum Masters instead. They'll learn. You might find that they hate being thrown into other roles where they can't apply their skills. Just tell them that "this organisation is Agile now!" to scare them into thinking there is simply no other option. What better way to retain skilled people in roles they don't understand than through the fear of redundancy?


6. The Scrum Guide is just a suggestion


The Scrum guide will be talked about a lot. It's pretty lightweight, only a dozen or so pages. Still, who's got time to read it? The important thing to remember is that the Scrum Guide deliberately only prescribes the minimal lightweight things required to enable agile outcomes. It's so minimal, that it can't really hurt to ignore a few things eh? They'll tell you every team needs a Scrum Master and a Product owner. That's okay, just split them across two or three. They'll say retrospectives are required to constantly inspect our ways of working, but who even needs them?


How about teams creating a potentially releasable increment every sprint? Just some Analysis seems like a great goal.


The important thing to keep in mind is that even though the Scrum guide is an incredibly well streamlined and minimal description of steps to success that's been proven time and time again to be a powerful tool, YOU still know better.


7. Implementing SAFe can buy you a year of 'progress' The Scaled Agile Framework (SAFe) is a godsend for failed agile. It contains dozens of guides and approaches to solving common problems when trying to move toward Agile ways of working. When used properly and regularly inspected against desired outcomes, it has helped hundreds of organisations to solve some of the meatier problems that come with Agility at scale.


But it's also a massive, convoluted mess of pictures and text. You could easily spend a year just trying to implement all it's language and processes without any thought for outcomes or genuine improvement. This is like a gold mine for making Agile fail, because no one could possibly question that you're making the organisation more agile while you're rolling out SAFe, right? A year later you'll be left with a bunch of confused people, unclear language and absolutely no improvement in delivery outcomes, but the way you work will look so different on the surface that no one could possibly question your hard work.


8. Create a culture of fear


Saving the best for last. How do you make sure nothing ever gets back to you? That real opportunities for true growth and change never happen? Scrum Master and Agile coaches will tell you all about transparency, but this is just code for 'making management look bad'. If you want to protect your own neck, make sure that whenever something doesn't go as planned that you put someone on the spot to explain what they did wrong. When issues are created by the work we deliver, identify what we did differently and remind people this is why we follow process. (and if current process is the problem, find the person who created to process and make sure everyone knows it's their fault) The goal here is to ensure people never speak up. Never try to improve the way we work. Most importantly, that they never take risks. Conclusion So there you have it. By following these simple steps you can take your organisation through a painful, confusing pseudo-agile transformation that will give you some padding for your CV while you're protected from any repercussions from the failed outcome. Buzzwords come and go, but businesses and their ways of working are forever.

87 views0 comments

Comments


bottom of page