Old times were simpler. When running a project, you just drew a Gantt chart. Then prayed. When motivating (which, as we are now, is not possible), you gave people more money. Or less. When scaling, you made your pyramid bigger, one level at a time. It’s all more complicated now. With projects, you have plethora of options to choose from, from hardcore (and boring) established methodologies like PMI or PRINCE2 to hippie lightweight approaches allowing you to think you’re cool, or a master of something – think Scrum and Kanban. With motivation, well, there’s the Management 3.0, Simon Sinek’s idea of Why and a ton of voodoo conveniently called leadership. Scaling, especially when you’re all cool and Agile, gives you an option of LeSS (that, some say, works), SAFe (that sells brilliantly, as it addresses all insecurities of old school managers in a perfectly engineered way) and Nexus (which is vague and esoteric enough to feel like a futile attempt to join the scaling bandwagon). It’s not easy to pick the right framework these days, especially considering each one is a viable and useful option.
Then, making this choice altogether might be a mistake.
First, the reason to choose might be wrong. Companies implement (mechanics of) Scrum, so that they are not perceived as fossilized relics of twentieth century. And it’s obviously so cool to send people on two day long courses and title them Masters or Owners. Others brag around their answer to Why, only because Apple did – and they succeeded so, hey! That must make sense! Let’s do it too! Then another see the fantastic big chart of SAFe and stare in awe at the multitude of options to handle literally everything available. In an instant, they know they want it all. Now.
And then they implement the approach, which brings me to my second point.
Every single framework or methodology available is built upon a set of assumptions. Obvious as it seems, the real problem is that they are usually unvoiced. Each of them will work flawlessly and deliver exactly what is promised only if all these assumptions are met. Then, by default, they never are. Every organization, unless seen through heavily simplifying glass, is inherently different from any other. They are all, with varying rate of success, adapted to their business realities. They are as optimal as necessary given the constraints they are bound with. And then, someone wants to implement some specific framework, which gives two options.
- You can fully implement the framework and change your organization to match it (losing some adaptations already in place).
- You can implement some parts of the framework (losing some portion of its benefits in the process) while leaving some specific (and, hopefully, well-tailored) aspects of your organization untouched.
It’s like deciding whether you’d rather have your arm or your leg cut off. In either case, you will not swim straight anymore. Luckily, that’s a false dichotomy – there’s no need for chainsaw fun at all.
What if you take some specific framework and decompose it? It might take some time, but what you’ll inevitably end up with will be a set of tools. Now, each of these tools serves a very specific purpose, has tangible benefits and is based upon some specific assumptions. What you could do now, is taking another, competing framework and following the process. You’ll have another set of tools, serving different purpose, offering different benefits and based upon different assumptions. Then, take another framework…
Which will give you a complete set of different tools, which you can mix and match. You will end up with your own composite framework, one tailored to your business, not the other way around. And if your point is to make your business better, that’s what you need.
Unless you just want to have XYZ implemented, because it sounds cool. Theory and practice of corporate evolution will eventually punish you for that.