‘How should we become agile?’ is the wrong question. The real question is: how do we learn to incubate (and in doing so, become familiar with agile as a suitable technique to achieve it)?

This post follows on from part one, logically enough! I’d recommend reading that article first, if you haven’t already, to understand the wider context.

Minimise overlap to nurture Incubation

As I mentioned in my earlier post, most established organisations already have well-formed Industrialise and Improve capabilities (even if they’re not aware that they do). The skill in becoming agile is to ring-fence these capabilities – both to avoid unnecessary disruption during the learning process, and to ensure that the value of these areas is properly recognised:

The next step is to find a small, but valuable, idea that the business would like to deliver. It’s important that the work is real and adds meaningful value if you are to test and demonstrate the effectiveness of the approach when used within your domain.

As this is not something you’ve done before, it’s also important to find a trusted delivery partner to work alongside you in delivering the outcome (nudge nudge). These are the people you are going to learn from, so they must be experienced agile practitioners who will work on the delivery with you. You don’t need agile coaches or advisors – they won’t help you learn practical skills. You need to have doers, committed to working side-by-side with your own people, mentoring, supporting and sharing knowledge throughout. There is no room for lone wolves.

A team of many talents

Finally, incubation is a multi-disciplinary exercise; it cannot operate independently of the core supporting functions like legal, finance and procurement, nor can it operate through the existing incarnations of these functions.

Trying to run an agile delivery whilst complying with Industrialise or Improve styles of governance and administration is like trying to ride a motorbike whilst towing a car. And trying to run an agile delivery with no governance at all is like trying to ride the same motorbike without roads, or a helmet; extremely ill-advised!

The art is to find willing participants from each of these central functions to be the trailblazers, and bring them into your emerging agile team. Their job is to find agile-friendly ways to achieve the same outcomes that they achieve in other areas of the business. Their destiny is to become your advocates across the broader community of stakeholders, and also to create the equivalents of their functions within the Incubate capability.

When will we know we’re done?

Another question I’m often asked by people considering introducing agile into their organisations is how long it will take. This emerges from the idea that agile is something you do to an organisation in the form of a transformation.

As I’ve hopefully explained, this is not the case – you are adding a capability to your organisation, and once created, this capability will continue to grow and evolve. You can honestly say that you are introducing agile from the first day you begin a concrete piece of incubation work, but people won’t sit up and truly listen until you deliver your first working thing. Only then can you demonstrate what worked and what didn’t, and move from theory into practice. Only then can you take on the next piece of work, using what you’ve learned to improve and grow the capability.

Of course, ‘done’ is a misnomer; this is only the start. You’ll still have to work out how to maintain long-running product teams to own the things you create while they’re still emerging and very much an incubation issue; you’ll also have to find a collaborative way to transfer products from incubators to industrialisers when the time comes.

But that, as they say, is a whole different story.