Not invented here

Agile transformation #

How we made all the mistakes so you don’t have to #

Part 2 #

Why does everyone insist on either reinventing the wheel or choosing the ONE framework to rule them all, instead of keeping it simple with Inspect & Adapt?

After being part of several so called “transformations” I have observed two major stances on approach. Either it’s “Not invented here” and you have to create your own framework from scratch because your company or organisation is so special you surely must have your own special framework. Based on the same common frameworks that already exist, but anyhow … The other route is to adopt an existing framework and then be overly stubborn and strict on following every little thing in it without thinking or adaptation to your own situation. There is no middle ground. I have been part of both approaches and they are equally annoying. In one company we even tried to do both.

As our company was special, we just had to customise our agile model or framework. A secret Tiger Team was put together and they created the company “Capability Model”, based on their views, opinions, and methods out in the wild. The reasoning and goal was to take the golden nuggets from lean and agile values and principles to guide us and then we could tweak the model to best fit our organisation. It was unique but also built on methods and experiences proven in the business. On paper it looked good. However, as soon as it was made public everyone else in the company also had ideas and concerns. To say the least, the acceptance and buy-in for the model was not that great. Then as we scaled to include the other countries in Europe, some countries had already been using Scaled Agile Framework for years and naturally wondered “Why would we change to your homegrown model? Why don’t you adopt SAFe like us instead?” A big debate launched and we ended up using SAFe as a “reference point”, for good and bad. Using our own model would require maintenance, updates, keeping a jour with new practices among other things. Using a public scaling framework, any of them, would take care of that.

The next hurdle then became, what and how much do we tweak the framework? Some wanted to change a lot right away and others wanted it run by the book. How to decide what actually was recommendations and what was mandatory for all teams? More about agile leadership and LACE in a later blog post.

But was there really no middle ground? Couldn’t we just have been “agile” and go for the Inspect & Adapt route? Would it have been just as confusing and debated a lot or would it be easier?

^{Photo by Devon Janse van Rensburg on Unsplash}