Scaling agile without losing agility
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.
So, to scale agile successfully, don’t adopt a framework. Just apply these simple rules and trust your judgement:
- Restrict it to new things.
- Don’t wrap it in controls and frameworks.
- Fund teams not projects.
- 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.
A game of three halves
Welcome back to the second part of this blog post about introducing the delivery focussed start-up mindset to large organisations. In the first part, I compared the two worlds and identified what I believe are the key differentiators that produce very different results. In this second part I draw analogies between what happens in the start-up world and how this can be replicated in an established organisation.
My approach to this is to adopt a model in three parts, that I refer to as Incubation, Industrialisation and Improvement.
- Incubation behaves like a start-up and adopts iterative Agile methods and a more flexible approach to governance and funding. There are three phases to incubation for which I’ve borrowed the terms Discovery, Alpha and Beta.
- Industrialisation adopts Lean techniques to refine the components and processes within a solution for use at scale. It’s all about efficiency and effectiveness.
- Improvement looks more like a traditional waterfall approach and kicks in during rollout of the solution to as wide a user base as possible. Stability, maintainability and repeatability are the guiding principles.
This is not simply about process, nor is it about asking for cultural change; it’s about creating an environment that naturally reproduces the behaviour you’re looking for. Culture is like a spring and the environment is like a force on that spring. Change the force and the spring changes shape, but try taking the force away and the spring falls back into its natural shape. It is only through environmental change that you can bring about sustainable cultural change.
So let’s take a look at the start-up world as it moves from initial idea to working product, and at each stage examine what it looks like, and what I propose you should do to reproduce this in an established organisation. I’ll focus on the Incubation phase as this is the part for which the start-up mindset is required, but I’ll also give an overview of Industrialisation and Improvement to show how it all fits together.
I have a dream (Incubation – Discovery)
What it looks like: Two people meet in a pub and while consuming some fine sparkling mineral water and discussing the world’s problems they have an idea. This is the eureka moment when all the really good stuff happens. Energised by the pure genius of their idea the two colleagues embark on a process of discovery, researching the market, talking to potential users and mocking up the idea on paper. They may even knock up a cardboard model or mock-up to show to focus groups and make it real. The job gets a little more involved now and they may rope in a couple of like-minded friends with additional skills to help in the venture; the team is born.
What you should do: In an established company this happens all the time. All you have to do to make this part of your project approach is to actively encourage it. Don’t expect it to happen without encouragement though. If someone comes to you with a sketch on a piece of paper, an elevator pitch, and a lot of hand waving, don’t tell them to go away and come back with a detailed proposal. As a leader you should be able to quickly decide whether you like the sound of the idea, and if you do, have the courage to find them some space in their workload to go off and explore a little.
Show the thing (Incubation – Alpha)
Almost as often as asking the question “what is the user need?”, Mike Bracken of GDS fame regularly used the phrase “Show the Thing”. The importance of this mantra is far greater and fundamental than many people realise. It goes to the heart of product development and is based on the idea that until someone actually has the real thing in their hands they simply won’t believe in it.
What it looks like: To really develop an idea you need to show it to people, and so the next thing the team needs to do is build a working prototype; an Alpha. This is where all the real questions get answered. In fact, this is where those questions get asked in the first place. Before building something, the team didn’t even know the right questions to ask. This is why an alpha is built quickly from whatever the team has to hand. It is built to try out solutions and to eliminate that which doesn’t work for the user.
What was originally conceived and what emerges from the alpha may be very different beasts. It’s quite possible that the most important thing that emerges is that the idea doesn’t even work. This is probably one of the most important outcomes as it avoids the embarrassment of creating expensive white elephants. This is what some call “failing fast”.
What you should do: It’s a lot cheaper nowadays to develop IT solutions than it used to be, but it still isn’t free. There needs to be a way that the team can tap into petty cash to get an alpha built. It may only be a few hundred pounds or at most a few thousand (if hardware is required) but you can’t expect people to wait for days or weeks for small amounts of cash, or the impetus will evaporate. You need to have this money available to give them and as a leader it is your job to make sure you have a budget available to use at your discretion.
Enter the dragon (Incubation – Beta)
Remember, we’re trying to create a start-up environment here so let’s consider what typically happens next. In a large company we now initiate a project and get bogged down in the approvals process. Waterfall rears its ugly head and everything grinds to a halt. In the outside world, there is no company within which to launch a project and so something different happens.
WARNING: Please don’t mistake this stage for “build” and rename Alpha to “design” and Discovery to “analysis”. This is an agile approach and each stage is a refinement of the previous one. An iteration on previous thinking. Analysis, design, build and test are all going on in each one of these iterations, but in a much more continuous and hands-on way. The emphasis on each activity will change, but they’re all there, all of the time.
What it looks like: The team reaches the point where the idea can go no further without significant funding and they decide to involve the help of keen investors. This is beta, the cycle of invest/prove/pivot, and this takes money that the team simply don’t have. Without the security blanket of a large organisation around them, the team members need to find a backer and they turn to the venture capitalists. For this they need a convincing pitch and that pitch has to come with something to show. Luckily they have this, and hopefully they’ll be successful, but this is where things differ from a large organisation. Dragons are renowned for being fickle and have short attention spans. They are also very protective of their hard earned cash and demand regular demonstrations of progress in order to continue providing investment.
In a start-up you’re always painfully aware that progress is the same thing as survival. There’s nothing quite like the reality of a fixed date on which the money runs out and another meeting with the investor to focus the mind. Dragons are very aware that it is their own money that’s being burnt by the team, and they’re not fooled by attractive progress reports. They want to see real results with real customers, and start-ups only survive if they provide this. Finally, VCs want a return on their money. This can of course come from the profitability of the start-up, but more commonly VCs seek an exit strategy and this is the scenario I will consider. Once the start-up has a successful product, but before it has expanded into the broader market, the VC and founder members seek a buyer, and if successful some remain as part of the deal and others move on, profits in hand, to pursue the next entrepreneurial venture.
What you should do: In companies you don’t have backers, you have stakeholders, and stakeholders rarely have anything personally invested in progress. Instead they are put in the position of having to agree to things progressing, but progress might lead to failure and failure gets you sacked. What you need to do is turn those stakeholders into dragons. Give them budgets to invest in ideas and measure their performance based on return on investment. If they aren’t investing they’re not generating returns and so they’ll fail. If they are investing in things that don’t progress this is even worse as now they’re generating negative returns.
Instead of being critical stakeholders demanding more and more detailed plans and estimates, (prevaricating instead of enabling), they become driven individuals with a personal stake in the success of the project. If things get tricky they might even dive in and get their hands dirty.
But they hold the money, and this is the other important part of the role. That money needs to be spread across a variety of investments and they need to decide where best to place it to get a return (in terms of business benefit). In order to do that they need to drip feed funding into the various “start-ups” they are involved in, and only continue to fund those initiatives that are showing real progress. This creates natural iterative development cycles with real deliverables, and provides checkpoints where genuine go/no-go decisions are made and acted upon. No funding, no start-up. The ones that make no progress are stopped whilst the successful ones produce something of real value.
Then comes the sell – the exit strategy. But we’re inside a large organisation and so instead of looking for a larger organisation to buy them out, the VC and the team pitch the idea to the major stakeholders within the company to take forward to rollout. The product is working, and proven, and all the difficult design work has taken place. The offering is very attractive as all that is left to do is to scale and roll out the solution, and take credit for the benefits. It is here that the currency of the sale becomes apparent. We don’t exchange the product for money; instead we sell it for an agreed business case that demonstrates the costs and resulting benefits.
The case can be worked on between the seller and the buyer in a process analogous to a corporate acquisition, and this then gives us our mechanism for reward. The proposed benefits are effectively assigned to the seller (the VC and the team) and it is against these benefits that the seller is recognised. The buyer inherits the ability to then realise those benefits and gain credit for delivering the results.
Lean, mean fighting machine (Industrialisation)
At this point we move beyond the start-up analogy and out of the core scope of this blog post. However, for the purpose of completeness I’ll summarise what comes next.
What we have now is a tried and tested solution with a proven business benefit. All the moving parts are there and the big issues have been ironed out. What hasn’t happened yet is industrialisation. Let’s assume you want to expand the use of your solution to the whole of a global organisation, or to a world-wide user base. To make this happen you’ll need to industrialise every part of it. Every component will need to be as scalable, efficient and cost effective as possible. The supporting processes will need to cover all eventualities and work at scale without breaking the bank or exceeding the capacity of your people. This is where Lean comes into its own as an approach. We’re starting to move into more familiar territory for a large organisation
World domination (Improvement)
Finally we need to mass produce the solution and roll it out nationally or globally. This is the part where Six Sigma, Waterfall and similarly robust approaches enter the fray. All the unknown are now known, and all the assumptions have been tested and proven. We don’t need to gather ambiguous or predictive requirements because we have a product. We don’t need to guess how long things take because we’ve already done it and we know. We don’t need to hope the sizing is right because we have real metrics from the live service telling us how big it needs to be. With all this certainty we can very quickly produce a roll out plan to which people can work with confidence and against which we can allocate resources and money.
Most importantly, we can grow a team around this service that will live with it, run it, and continuously improve it, and our original founding members can leave to pursue the next great idea (without needing to leave your company).
Throughout this process, the team has been evolving and growing. Some of those involved at the start have moved on to other initiatives, whilst those more attuned to industrialisation and improvement have taken their place. The flavour of the team has evolved, step by step, with the product. There have been no “over the wall” handoffs from one team to another. Group understanding has been maintained throughout.
So, in summary, let’s put aside the agile versus lean versus waterfall discussion and the old versus new debate. There is no old and there is no new; there are simply appropriate techniques for appropriate situations. Detail, discipline and planning are ideal for repetition of well understood situations at scale but stifle creativity and fail dismally in the face of uncertainty. Iteration and experiment work well with chaotic situations and allow innovation to flourish. A solution that works locally can’t just be handed over to a production team and rolled out at scale. First it needs to be industrialised by those with the skills and desire to do so. You cannot apply the rules of any one of these phases to the realities of the others.
Methods are not religions; you’re allowed to believe in more than one.