If some is good, then surely more is better? Companies want to expand, and frequently the assumption is that just adding more people will result in successfully growing the organisation. Then, when they realise that’s not working, they decide that what’s needed is more process.
Fortunately, there are frameworks which you can install to fix all your problems; just invest in SAFe training and consultants, then follow their prescriptive framework, and magically you’ll be back to a command and control organisation in no time. Whoops!
It’s quite telling that the “Agile Teams” image is tucked away down in the bottom left corner; the majority of the people in the company are reduced to that little graphic. Meanwhile at the top of that hierarchy are Epic Owners and Enterprise Architect; I wonder at what stage of designing the framework they remembered to remove the picture of a waterfall. You also have to look pretty closely to find a mention of the customer.
I’m not saying there is nothing of value in SAFe – in fact it covers so much that there’s bound to be something useful for everyone! But most of the valuable pieces can be found outside SAFe, e.g. Scrum, Kanban, continuous delivery, DevOps – the key thing is to be selective.
Rather than painting SAFe across the organisation, recognise that each org is different and therefore has different challenges, but also that within an organisation there are departments, groups, and teams with their own circumstances. They should all be working towards the same goals, and following the same principles, but the implementation details within each unit are going to differ… and they will change over time.
And therein lies the challenge: if each team is different, then they need to find their own path… but that is time-consuming and expensive. The temptation is to enforce standardisation, which simplifies the thinking (not necessarily the problem!) and assumes that the same solution can be applied across multiple teams. This should make you shout “slippery slope” because it’s the path back to factory-thinking and turning everyone into widget makers.
The teams are building different things because they are solving different business problems, and with different people in the teams they will have different approaches to creating those solutions. If those differences don’t exist (a) you should probably look at your hiring practices, and (b) your staff might be about to be replaced by robots (or a very small shell script).
So does that mean there’s no easy way to scale up? I don’t think there’s an easy way, but there are things that can help… and it’s similar to how we help teams tackle feature delivery. It starts by understanding the problems you’re trying to address, then breaking them down into manageable chunks, minimising dependencies and risks, and using frequent feedback loops to check you’re heading in the right direction.
You probably don’t need to scale up equally across the organisation – some parts warrant adding more people, e.g. if there’s a promising new business sector. But reducing the impediments that a group faces could also help their growth, and dependencies between teams is one of the biggest obstacles they face. In the same way that developers try to have clean interfaces between services, teams should be clear on their responsibilities and their backlog should reflect that.
Work with the team to identify the challenges; an exercise like Circles and Soup can help identify where the team cannot address the issues on their own – these are slowing progress, so focus on reducing or removing them and that will help your team grow.
If you add people to a team that’s not addressing its impediments, then you just end up with more people struggling with those impediments. Make the teams independent and autonomous; focus on continuous improvement; address the issues which impede the system, and you may not need to scale up!