There are things you can do right about ‘going Agile’ with your organization. And there are countless blogs, articles and books pushing Agile folk wisdom into minds of the wandering ones. That’s fine. We all need someone to tell us how to do the right thing. But what if your goal is… different?
After all, this whole ‘Agile thing’ is likely to be the new black. You’ve seen it all before, right? You’re too tired of all these Communist-style manifesto things, right? Hacker’s manifesto, Cyberpunk manifesto, Agile manifesto… They’re all the same, a lunacy to lure the young minds, to give them hope, to let them dream of fulfilled life.
Damn hippies, you’ll get neither.
So, if the Agile tornado is about to storm your workplace, here’s the shortlist of things you can do to stop it, or – which is good enough – to make it fail properly.
- Make sure that ‘being Agile’ equals ‘working in sprints’. It’s just enough.
- There are agility prophets claiming it’s all about ‘value delivery’. And that value is not always money. And that it can be not as obvious as you deem it to be. And that it can change over time. Well, to make things go wrong, just make sure that everybody thinks value is the number of Story Points delivered by your team during sprint. And that’s it.
- Agile methodologies (particularly, using just some of the mechanics of Scrum) give you a rare opportunity to deliver the most useless product in the most efficient way possible. How can you achieve such a feat? It’s easy. Make sure your Potentially Shippable Increments are shippable, yet not testable to the end user. Imagine spending four sprints to deliver the architecture. Client can see nothing of it working, just some CPU load going up. Then seven sprints of database changes. Still, nothing for the clients, with exception of some debug printouts. Then six sprints of delivering the business logic. Well, CPU load went up and that’s it. And then, finally, after half year of hard work, there’s the first UI delivery. Usually called the ‘oh f**k!’ delivery. Which, clearly, means that Scrum (and all things Agile) are utterly useless, as the product created with it is.
- Don’t ever ask why is your organization going Agile. It doesn’t matter. In fact, if you have no idea why, odds are it’s just because, as said above, it’s the new black. It sucks to be one of the hermits dwelling in the realms of waterfall approaches.
- I actually love this one. Forget the fact that the use of whatever your approach is (Scrum, Kanban, Lean,…), as it is, without any alterations, proved beneficial to thousands of companies worldwide. Agile prophets will keep reminding you – including firing real life examples as bolts – that it can work anywhere, as long as the scope is negotiable. How can you make sure their claims go forgotten? Simple. Your business is different. Agile gurus were all working with different kind of companies, so their experience is useless. Wait, is your business profile almost identical to the one they refer to?
Oh, just find one excuse and you’re done. - Even the dumbest of coaches can start small. You know, with one team, checking if they’re able to divide the backlog properly, seeing how they interact with rest of the business, improving and growing along the way. Yeah, right. You’re not one of them. You can plan it all, in advance. Teams’ setup, number and structure of Product Owners, all the processes. Yes, you can.
- Some say, you need an ‘Agile leader’ in your transforming company. One to oversee it all, to shed light, to pinpoint you to the right course. Well, odds are, you have no one like this on board. Which is good for you, in your mission to destroy the whole thing. My advice – pick up the eldest board member – but one with proper golden parachute. He’ll do things right, the way he did for years and decades – which is more than likely to be wrong.
- If you’re reading this, you’ve obviously heard of the Scrum Master role. They’re the ones to manage the process, to make sure things are working right. But where could you get one? As long as you want to make sure your corporate agility goes haywire, I have a perfect advice for you. Pick one of the team members which was due for promotion for the longest time, yet possesses the least leadership qualities possible. Then send this person for a two-day long Certified Professional Amazing And Wonderful Scrum Master course. Do not go further. All the soft trainings, coaching courses and other New Age-ish blasphemies are prohibited.
- Some say, it’s tenfold as complicated to hire a good Product Owner as is to hire a proper Scrum Master. Bollocks. Pick up your least capable Project Managers and send them all for a two-day long Certified Professional Amazing And Wonderful Product Owner course. It’s important to immediately disqualify every single manager that ever ran his own business. And by business, I mean something more than being self-employed. Multiple employees, multiple customers, you know the drill. These people know more about proper risk management, brand value and asset management than even the best of ‘all time employee’ managers – which is why they should be prohibited from PO role, as long as you want to make things wrong.
- Send all your executives and high-level managers to the Scrum Master course. This way, they’ll all believe they actually have some idea how the teams work – and might want to ‘help’ them. Imagine all the opportunities. Senior executive advising twenty-something Scrum Master on how to make a better retrospective. Bring some popcorn, sit comfortably and enjoy the show.
- Would you believe you can go too far with transparency? Yes, we’re all Agile. We have stand-ups and stuff. Yes, everyone interested can come and listen to our daily meeting or our demo. But will they want to? Will they find the time to ‘go and see’? You know how it works. The hell would have to freeze first. How would you make sure your team is transparent? Send out charts, daily. Plenty of them. The burndown. The burnup. The cumulative flow diagram with plethora of states possible for each backlog item. The time-sheet reports, detailed down to every five minutes. The TPS reports, whatever they are. Bug count. Give them everything, every single day. They’ll die before they understand it all. Now, you might encounter a Scrum Master that resists. One to claim that most of these charts are useful for team only. And that you should trust them. Defense against this behavior is quite easy. “Yes, I know it, and my manager does – but, you know, those guys up in the board, they only look at numbers”. Cheap lie, yet it works.
- Agile prophets claim that the, so called, ‘trust’ is fundamental to whatever you do. Well, while I’ve actually seen managers stating explicitly to their teams that they don’t trust them (I’m not kidding), that’s not what I would recommend. Unless you want the best of your team to just leave and look for some other job. It can be done differently. A passing nod over the demo, when everyone is cheering. A request for more data as “it doesn’t seem right”. A fantastic misuse of Agile coaches’ typical question “how do we know if it’s right?” Your possibilities are limitless. Keep declaring trust beyond reason – yet do things in a slightly opposite way. People are fantastic at detecting this kind of anomaly. They will feel that something is wrong, yet they’ll have no idea what it is.
- The best of the best. You might be all good hearted and unwilling to do anything of the above. And yet, for any reason, be it the shallowest and the strongest of them – personal, you actually hate the concept. What can you do then? It’s easy. Do everything as the Agile coaches and prophets say. Then, at one point, decide it’s done. This is your Agile team setup, these are your Agile processes, this is you brave new world. Now freeze the rules. Make them solid forever. Can you imagine this? Whenever a newbie asks “Why do we do this this way?” you can reply “This is the way our Agile works. And we’re so Agile. And we’ve always been.”
The menu’s here, sir and madam. What’s your poison of choice?
Fun fact: I posted original version of this text on LinkedIn almost two years ago. Today, with heavy misuses of Agile, it seems to make even more sense. Oh joy.