Last week, I facilitated an Agile game, with the goal to increase product delivery throughput.  At the beginning of each iteration, I would remind the team "The seven rules of the game are...".  Upon completion of the third iteration and only seeing modest gains, one of the team members questioned the need for one of the rules and proposed a change in the delivery process.  She asked me, "Is it ok if we do that?"  My response didn't give her much solace.  Though I knew she was concerned with potentially lowering delivery throughput, I said "it's easier to ask forgiveness than it is to get permission. Just do it."  The team then changed their process, resulting in a dramatic increase in delivery throughput. Though I know success isn't always the outcome, if you don't go outside your comfort zone and do something different, you're never going to see dramatic results.  This applies on both organizational and personal levels.  Within the game, I allowed the team to pilot the new processes so they would either fail quickly or prove their theories.  Over the course of a few iterations, they figured out what worked and what did not, while adhering (directly and indirectly) to the original seven rules.

Within an organization, I recognize things can be much more complicated.  We have regulatory compliance, mandates, and policies to contend with.  I do challenge you to question if they all apply to your current situation.  As with the game, the team just assumed if the rule was listed then it must apply to them.  Without questioning the rules, the results are heavy and burdensome processes.

On a personal level, we litter our lives with artificial constraints.  We accumulate a lifetime of unnecessary rules, rarely stopping to ask ourselves why we do things that prevent us from excelling in the areas we desire.  I'm not promoting living or working recklessly or unethically. Uphold a few guiding principles and reteach yourself to intentionally go outside your comfort zone.  Stop asking permission and let the magic happen.

You can also read this post at LeadingAgile