Context matters

Most organisations considering agile as an approach start small and explore its strengths and weaknesses. If this is you, then I salute you. You did absolutely the right thing. The core principle of any iterative method is “test and learn”, and that’s exactly what you did. So now you’ve hopefully seen the value, and want to scale your agile approach up, so the whole organisation can benefit. Where should you start and what pitfalls should you avoid? 

The first thing I need to tell you before you roll agile out across your organisation is this. Don’t. Agile is an excellent approach, but as with all solutions it has its place. Context is everything. Agile works best in situations where you’re trying something new, or making something for the first time. It’s for situations where you don’t already know the answers. That’s why test-and-learn is so important. Only scale agile up to cover those activities.

(For more information on where agile fits and how to introduce it, take a look at this blog post.)

No one-size-fits-all frameworks

Agile is about autonomy and freedom to change direction. It’s about achieving outcomes, not about completing predetermined tasks. So, avoid frameworks that promise to create control structures and processes that allow you to manage agile at scale. The whole point of agile is it shouldn’t be managed from above. Set goals and guidelines, but don’t micro-manage. 

An agile team explores the unknown and reacts to what it finds. Trying to control that process, and create predictable plans and portfolios is tantamount to practising astrology and reading tea leaves. That’s not to say agile has no rigour. It’s just that the rigour is applied within the team, not from outside. Agile teams seek to achieve an outcome and deliver value. They don’t focus on completing a set of predefined tasks. 

Most frameworks apply techniques from other methods to try to make agile more familiar and comfortable. All this achieves is a conflict between two different approaches designed for two different contexts. 

In short, there’s nothing safe about a scaled agile framework.

Fund teams, not projects

Agile initiatives aren’t about completing a fixed deliverable or task. They’re about achieving an outcome. You can’t define them as tightly bound projects with a gantt chart and fixed budget. While an agile initiative is in progress it should be considered to be an operational activity, and should be funded as such. So, don’t create a project budget.

Form agile teams to deliver specific outcomes that align to your organisation’s strategic goals, and then let them use their skills to deliver results for as long as those outcomes are needed to fulfil your strategy. The benefits you expect from the assigned outcomes should allow you to define an acceptable financial burn rate for the team. The team should then look to deliver regular value that justifies that burn rate, by achieving those outcomes, incrementally.

As outcomes are achieved, new ones will emerge that take your organisation to the next level. This ensures longevity for established teams, and ensures that beneficial change becomes a core part of your business’s operating model. An added benefit is that stable teams become high performing teams as you don’t have to form and reform them each time a new project starts.

Be agile about being agile

If you’ve already started using agile in your organisation, you’ll know it’s an iterative approach. You don’t go straight from nothing to a full roll out. Instead, you advance incrementally, learning and adapting at each stage of the way. You do this because what you’re doing is new. You’re not familiar with the potential pitfalls and unknowns. Doing agile at scale fits this category of activity. You’ve never done it before.

So, practise what you’ve learnt on the exercise of scaling. Move from one team to three. Wait to see how that works, and learn from it. Now, when you expand again, you can use those learnings to do it better. Keep going until you have as many teams as you need to cover all the strategic initiatives for change that you want to pursue. 

Alternatively, grow until the operational cost is at a level that you can sustain and accept that some initiatives can wait. This just needs some careful juggling of cost versus benefit. Something that every successful business is already expert at. And you are, of course, a successful business because you’re still trading.

In summary

So, to scale agile successfully, don’t adopt a framework. Just apply these simple rules and trust your judgement:

1. Restrict it to new things.
2. Don’t wrap it in controls and frameworks.
3. Fund teams not projects.
4. Grow incrementally, learn and iterate.

By taking this approach, you’ll only go as far as is beneficial for your organisation. You’ll achieve sustainable and continuous change without making large, risky step changes. Best of all, if you do end up with a framework, it’ll be one designed specifically for your business, by your people. That’s how you get the buy in necessary to make it last.

That’s it. That’s how you scale agile.