I’ve heard many people say that their company “is agile”. As it turns out – after a short discussion – what they mean is that their company has a software development team which uses Scrum quite well.
And by “quite well” they mean that they are using some aspects of Scrum (like daily stand-ups and sprints) in an organisation that is about as agile as a super tanker doing a three-point turn. In a dry dock.
Don’t get me wrong, having a single software development team using Scrum can be a good thing – there are plenty of advantages in using stand-ups and sprints – but in isolation from the rest of the organisation, they are missing out on the big bananas.
Because nowhere in the Agile Manifesto does it mention where a team’s work comes from, or which work has the strategic priority, or even what the overall strategic roadmap looks like. Or even that there is one.
The Agile Manifesto “merely” states the value preferences of the “founding fathers” to be adopted by a software development team – once they have been allocated the work.
The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We can see that the manifesto is not a set of concrete steps. It’s not a method. It’s a set of principles. A set of values.
Unsurprisingly, various methodologies have arisen to put some structure around these agile principles, one of which is Scrum.
From Scrum we get:
- Scrum Master
- Product Owner
- Self organising, cross-functional, Scrum team
- Show and tell or sprint demo
- Five year strategic roadmap
- Strategic product priorities
- Investment sign-off
- Organisational change
- Change management
So whereas a particular software development team might be using Scrum “quite well” to carry out the work they have been allocated, the overall organisation is not that much better off.
What we need, then, is a set of values, principles, behaviours and guidelines for tracking, prioritising, governing, sponsoring and planning work over, say, a five year period – before anything gets anywhere near a software development team to execute. Or, more realistically, before it gets anywhere near one of many software development teams to execute.
Moreover, what we need is a structured approach to help us do this.
Because if we’re going to be working with a five-year strategy roadmap, there may well be more than one scrum team required to execute the work. So somehow, we have to coordinate activities across the Business, the business architects, the scrum teams, the sponsors and old uncle Tom Cobbly and all.
So there are two things here:
- There is the strategic, five-year planning side of things.
- There is the scaled agile side of things.
But woe betide anyone who thinks and treats these two things as separate, distinct and unrelated.
Because to get the big bananas, we need to align the strategy-setting team with the business teams, with the change management team and the software development teams.
In other words, end-to-end alignment.
And while we’re at it, we should reorganise ourselves along product lines, so that the end-to-end, strategy to delivery is a product-focussed value chain.
In this scenario, the scrum team’s Product Owner is – guess what – a real product owner. Someone in the business who is accountable to the executive team and strategy setters, and responsible for the success of that product in the market. Someone with skin in the game.
And the scrum team itself is focussed on delivering that product. And only that product. Because that’s what they do. And the scrum team next door, they have one too. And the team next to that.
Remember, we’re not talking about Projects. We’re talking about product development. A Project is where you assemble a group of people to tackle a temporary piece of work, and when it’s complete, the people go back to something else. The work is fixed, the people are fluid. With a project, you must bring the people to the work.
In contrast, in agile it’s the scrum team which is fixed. The work is fluid. We bring the work to the people.
So who decides which work goes to which scrum team? Who decides when the work goes to the scrum team? If the agile scrum team is fixed and we’re going to bring the work to the team, then we better have a hopper of future work available, prioritised, sorted, approved, and ready to send off.
And there’s it is. The central point for all of this. That “hopper” of work is the strategic roadmap.
What we need, then, is a way in which we can pull all this together.
- A way in which we can plan future work according to our strategic priorities,
- A way in which we can allocate work to standing scrum teams to execute,
- A way in which we can govern work to ensure no one drifts off piste,
- A way in which we can coordinate dependencies across the company, and across scrum teams,
- A way in which everyone in the business feels engaged, part of the change journey and with skin in the game.
What we need, then, is an Agile Target Operating Model.
Once that’s in place, in the way in which I have described, then – and only then – can you call your organisation agile. If you must.