Too many rules makes agility impossible

One of the principles of the Agile Manifesto is “Simplicity—the art of maximizing the amount of work not done—is essential”. Studies from the Standish Group and recorded in one of their Chaos reports shows that 60% of developed features are not or rarely used. If you only deliver the right features your customer will get the product much faster and cheaper.

Looking at the features of the product you are developing is one way to take this principle into account. You could also apply this principle to the process you are using to develop your product. How many rules do you have to follow?

Have you ever played a game of go? Go is an abstract 2500 years old strategy board game for two players, in which the aim is to surround more territory than the opponent. Despite its relatively simple rules, Go is already very complex. Or think about Conway’s life cellular automation. Just a few very simple rules and awesome results. Adding more rules will result in chaos.

I read a story about day care centers in Israel. They were facing the issue that some parents picked up their child too late. As a solution the implemented a new rule that if you pick up your child too late you have to pay a fine. As a result of this rule even more parents picked up their child too late. What used to be a moral trade-off (I can’t be too late) now became a business trade off: I buy off my debt. Rules are not necessarily sacred, principles are.

If you look at some agile frameworks or ways of working, you can ask yourself if the rule makers force you to be rule taker or rule breaker. Many of these are there to help you when building teams of teams who develop one product or service but here too, if you can manage to ‘simplify’ your architecture towards micro services you don’t need those scaling frameworks. If we compare the number of rules of Scrum with SAFe you could ask yourself if you are successful and using agile release trains, if this is due to SAFe’s rules or despite?

If you want to set up an innovation or growth lab, make sure you stay away from bureaucracy. To reduce obstacles, exempt the lab from corporate rules, procedures, manuals, guidelines, principles and formats. Innovative plays can do without!

Jim Johnson dreamer and chairman of the Standish Group stated in an interview for a Dutch PM magazine: “Analyzes of the project data have yielded standards, frameworks and structures, although I am actually quite hesitant about standards, because they limit growth. All things considered, the reflex to build structures increases the chance that an IT project will fail. Structures in the form of complicated management tools, too many rules in the field of governance, too narrowly defined professional requirements, you name it. Structures are built with the best intentions that make projects especially slower, slower, more expensive and more time-consuming. Structures in which no one dares to make any decisions.”

If you are striving for agility think about a quote from Pablo Picasso “Learn the rules like a pro so you can break them like an artist”. Or with my own words use common sense when applying agile frameworks or way of workings and show the right agile mindset by understanding the logic over following the rules.