I get it. You have some Agile teams and things worked out not too bad. But now you have some big projects that must be done, you know, an enterprise project. Some Chief Whatever Officer decided that it was a good idea to stake the entire company on the successful implementation of a gigantic software solution. The Agile leaders (you’re probably one of them) decide it’s now a good idea (hint: it’s not) to “scale” Agile. I’m not talking about turning more teams into Agile teams. Oh no. I’m talking about the cosmic stupid idea of tightly coupling a bunch of Agile teams together with the mission directive of “implement this software.” When the members of your various Agile teams hear about your idea, just know that their blank stares and eye rolling is them realizing just how stupid your idea is. Tread lightly and think about what you say next because, “The vendor says the software can be implemented in less than six months,” will simply confirm what a giant clown you actually are.
But you’re the boss, and your boss demands that this enterprise project move forward. At this point you should think long and hard about handing in your resignation. You stand a better chance of storming the beaches of Normandy—at least the battle was over after several hours as opposed to the months (if not years) of massive stress you’re about to endure. Someone in the company (likely a resident sociopath who thinks the apex of high fashion is to wear big floppy shoes and a red nose) said, “We should implement a scaling framework like SAFe.” I’m telling you, resigning is a viable, and less insane, option at this point. Not only is this a foolish errand, but it’s so clowny that Barnum & Bailey blushed at the mere mention of the idea. You have better odds of achieving a successful outcome by betting the house on a single spin of a roulette wheel in Vegas.
What is SAFe? It’s a bunch of Agile teams following a waterfall pattern—at scale. SAFe, and other “scaling” frameworks were not designed for customers, nor were they designed for organizational agility. Yes, the peddlers of scaling frameworks sell you the idea of organizational agility, but these frameworks rarely, if ever, deliver. Those peddlers just want you to shovel large piles of cash at them for certifications and consulting opportunities. Such frameworks were never meant to achieve organizational agility, they were designed to appease the command and control nature of the authoritarians and sociopaths of companies. Don’t believe me? Go look at the canvas for Full SAFe. Go ahead. I’ll wait. That canvas is nothing more than massive complexity displayed in a nice looking diagram. And you want to spend millions of dollars for that dystopian future.
Look, you can’t add more processes, more roles, more people, more workstreams, more expectations, more rules, and more regulation, and expect to go faster. You can’t strap a boat anchor to the back of Michael Phelps and expect him to set new Olympic records. It’s not going to happen, no matter how much you want it to happen. Michael Phelps achieved Olympic greatness partly because he unencumbered himself as much as possible.
Here are a few things to think about:
Managers and employees spend ~80% of their work week talking about doing work (i.e. collaborating) rather than doing work
~60% of employees must collaborate with a minimum of 10 people to get work done
~30% of employees must collaborate with 20 or more people to get work done
Most employees who do project work are assigned to more than 1 project
Only 3% of large waterfall projects are successful
Only 18% of large Agile projects are successful
~42% of large waterfall projects FAIL
~23% of large Agile projects FAIL
Of projects that fail, 54% fail because of project management techniques and methods
Of projects that fail, 43% fail because of requirements management techniques and methods
Of projects that fail, only 3% fail because of technical challenges
The best bullet was the last one, which means engineers are pretty damn good at solving technical problems—you just need to get out of their way so they can work their magic.
Yeah, I know Agile leaders say things like, “We saw increased collaboration among teams after we switched to SAFe.” You’re telling me you mandated that teams talk to each other and are overjoyed because your employees did what you told them to do? Congratulations. Here’s your red nose.
Your customers don’t give you money so your employees can follow complicated processes, fulfill the requirements of some framework, and spend a majority of their time talking about doing work. They give you money because you provide a valuable product or service that improves their lives in some way. So do that.
I know organizations love SAFe. What’s not to love when you have a catchy name like safe? “Just follow this highly complex process that demands massive overhead and an increase is wasteful activities, but don’t worry, it’s safe. It’s right there in the name!”
Many leaders bought into SAFe because they fell for the marketing hype. And since many of those leaders are authoritarians and sociopaths, they refuse to admit the error of their ways. I can’t really blame them—after all, they spent millions of dollars on trainings, certifications, hiring new people for complicated roles, and upended their organizational structures to fit the demands of their chosen religious ideology. I wouldn’t want to admit I was wrong either. Now their organizations waste even more money on late projects, but at least they follow SAFe.
I’ve been thinking of starting my own Agile framework. Would you be interested in spending millions of dollars on one of the following?
Scaled Lean Agile at Velocity (SLAVe)
Freedom Empowering Agile (FEAr)
Lean Operations at Scale (LOSs)
No? Okay, let’s move on.
A lot of organizations are moving to SAFe. I get it. You feel like you have to, otherwise you’re not doing what everyone else is doing. But if everyone else struggles and fails with large projects—and they’ve always struggled and failed at doing large projects, then so should you, right? No! Why do you insist on doing large projects? Do you like failure? Do you get up in the morning and look for ways to waste money? “I haven’t spent enough money this month so I should crash my car into that lamp post!” Stop the madness.
Just take a breath, and refocus on what Agile taught you. Agile teaches that it’s better to focus on smaller things, not bigger things. There’s a reason we break down user stories. We don’t like big user stories. We know big user stories are a recipe for disaster. So why should any rational person think a big project is the way to go? Small projects are the way to go. After all, ~58% of small Agile projects are successful with only 6% of small Agile projects failing.
“I don’t want a 58% success rate. I’d much prefer an 18% success rate.” Did you learn that in business school?
You don’t need command and control processes to be successful. You need to command and control your assumptions and not dive into the stupid end of the pool simply because everyone else is doing it. To be successful you must:
Break down that large enterprise project into a portfolio of small projects
Define projects so they can be completed by the fewest number of teams, preferably one
I won’t lie to you. It’s not easy to breakdown a large project into smaller ones. But it can be done, and it can be done in a few days at most. You just need a willingness to roll up your sleeves, think about it, and do the work.
Treat your projects as features that are delivered by independent teams. The benefits outweigh the alternative.
If a team runs into trouble, they don’t block the work of other teams
It’s far easier for a team to control its output when they, and they alone, are responsible for results
Teams don’t view the work of other teams as being of high priority (no matter how much you scream about what the priority is), which makes cross-team dependencies likely to destroy projects
It’s simpler for a team to build a stub that other teams will connect to
There’s one last thing to think about: Organizations create software solutions that mirror their organizational structures. Loosely structured teams create loosely structured software. The inverse is also true. If the structure of the organization is tightly coupled and complicated, then that big enterprise solution will also be a collection of tightly coupled features that are complicated. Congratulations. You may eventually deliver that large project, after years of trying, only to find that you incurred a mountain of technical debt and created a solution that is so complicated the cost of maintaining it, let alone expanding it, are astronomical. Well done. Go team you!
Look, the good thing about the CWO is he doesn’t care how you deliver the big enterprise solution, only that you do. Your job is to figure out the how, in a way that reduces the overall risk to the organization. Implementing a scaling framework is just a recipe for failure that increases the overall risk to the organization. No to mention, increasing the risk to you and your teams’ overall health with the sheer amount of stress you’ll endure.
Stop scaling Agile and return to it’s tried and true roots of smaller is better.