In our previous blog post, we exposed our craving for predictability, our paradigm of causality and the habit of using ‘controlled environments’ when we are producing IT. And we explained why this is the main obstacle in becoming a high performer and Agile as an organisation. We tend to always complete the standard cause-and-effect picture: All thought-patterns are directed this way.

Start cycling and become Agile by nature

We at Cycle To Accelerate love cycling. In cycling we do not yet know why a top-heavy bicycle can stay upright when we cycle on it. What we do know is that the cycling system --cyclist plus bicycle -- becomes better at it by doing it. The system seems to be antifragile because it learns from little mistakes and becomes more accurate and stronger over time, and therefore performance increases. Tacit knowledge is built up implicitly during cycling and it grows when you tackle bigger challenges. The funny thing is that a human does not need to think about how to get better at it because it just happens while doing it. As a result an experienced cyclist can jump on a bike and ride off immediately.

Cycling is the key to becoming a high performer, and performance makes an organisation Agile by nature.

Let’s have a closer look at similarities between cycling and producing IT within an organisation:

• As an organisation we should know where we are heading and why. Next, we formulate our strategy about how to achieve it. It would be even better to formulate a strategic intention because context changes per definition.
• Also, we will formulate multiple goals as part of delivering our strategy, and even better: constantly adjust them based on changing circumstances.
• Next, we need to know how we get there because in this case we do not have a bike to ride. When the whole organisation starts to move, that organisation first needs to build up knowledge about how to move and build up experience by keeping on moving. Also, we need to adapt the way we are moving because we will build up constraints over and over again which will slow us down.
• Last but not least when you know how to move forward, it becomes interesting to add what you like as an outcome and start making small cycles in getting what you want. And what you want should at least attract foreseen customers and give them satisfaction and a positive business case for your organisation.
• To gain success in achieving your goals you need the whole organisation to constantly contribute to the how and what, otherwise you will per definition stand still in delivering output. Contribution means adding value based on understanding the how and what, or facilitating others to add value.
• Performance can only be built up when a team working in the chain of all production activities can add value without waiting on facilities and good circumstances. Remember the Theory of Constraints (ToC) from my last story?
• Last but not least, too much steering without knowledge about how and what makes us fall. This means being agile is not a goal in itself but a result of great performance.

Based on the above the only way within an organisation to steer IT production to the needed outcome is to do it through the principles of cycling. When cycling, you can look ahead far enough to have overview and at the same time gain new insights in how to deliver a better or even high performance. And while looking ahead you are just fast enough to adapt to small variations and learn without cycling into a deep pothole.

Being Agile can therefore only be done by behaving like a cyclist and producing IT through knowledge-based production with freedom of making many small mistakes to support evolution in the production chain. We all know that knowledge and craft is developed when performing production activities. When producing IT together with a great team under great circumstances without too much waiting, we achieve the ultimate state of flow resulting in a high performance.

The cycling way also forces us to improve on our IT-production process. When making IT that is too fragile or too robust, we will be corrected in the process along the way and feel the pain of re-engineering. Constantly looking for better, more adapted ways in making IT to survive the changing circumstances teaches us to work antifragile.