How do you practice delivering great outcomes at speed while maintaining our expectations for how IT should deliver them? Simple really, you don’t. Taking a leaf from the, 'Lean Startup', what is it we can remove from the process, what assumptions can we test and how can we evaluate the feedback from those tests, to base any determinations on what to do next?

When a child takes its first steps unaided, we know it will fall and so perhaps do they, but with each step they learn, they practice, and gradually become faster and more confident, ultimately perhaps – more agile. Muscle memory, balance and how to fall are just a few of the things we must learn along the way. These first steps are about developing capability, not about reaching the finish line.

So when considering agile, we must consider our organization’s capability to BE agile. What are our baby steps - the processes and frameworks required to enable true, long term agility? Are we giving enough space(and time) to enable our teams to develop the necessary skills, or are

we expecting too much? As leaders, we may clear a path and surely set boundaries to manage risk but we must also allow our team’s time to find their feet, or risk stealing their opportunity and enthusiasm for learning along the way.

You will often hear the ‘fail fast’ concept banded around soon after anyone suggests ‘Going Agile’. What does it mean to fail fast? I believe it means to take the risk out of failing by reducing the scope and scale of failure, but also it means to realize that there is a learning opportunity in every step we take or don’t. We can celebrate getting off the ground by building a plane as it moves down a runway but we learn most with hindsight, when we can turn a one idea into a process or discount another idea as in effective. The discovery of penicillin was by all accounts an accident but it was Dr. Alexander Fleming’s curiosity which lead him to examine exactly what was growing in those petri dishes, which many others may have simply thrown out. Failing fast is great as a concept but without curiosity and reflection, what are we learning, except how to fail?

Many agile project teams begin as a proof of concept and spend much of their time butting heads with the traditional side of the organization, challenged to reconcile their philosophical differences by being ‘bi-modal’. Momentum is often at the mercy of the dreaded weekly CAB which is still there to act as gate keeper, ensuring progress is either a trickle-feed, or batched into higher volume and therefore higher risk changes. Is CAB the enemy, no, but what we need to be asking is not what can go wrong, but instead how likely and how quickly can we recover when something inevitably does. This is the muscle memory we need to encourage in our teams.

Success in Agile is not about failing fast, nor is it about building planes on the runway, it is about establishing a common understanding, a common language and a shared curiosity for how we can move faster with less risk. Rather than instructing our teams to ‘be agile’ we should be building trust, so that when we ask how things are going, they tell us.