"Agile does not scale" is one of the common challenges in the Agile community and one of the answers recently has been the Scaled Agile Framework (SAFe). While SAFe has been packaged and marketed really well, every enterprise going through Agile transformation is using it or devising a home grown way of scaling Agile development processes to the wider organisation.
Most of these frameworks break down very quickly. The reason being, the more one tries to scale, the easier solution become standardisation which is counterintuitive to agility in first place. Even the SAFe image has an uncanny resemblance to top-down planning like below.
Most of these frameworks break down very quickly. The reason being, the more one tries to scale, the easier solution become standardisation which is counterintuitive to agility in first place. Even the SAFe image has an uncanny resemblance to top-down planning like below.
Similar top-down planning approaches have been dominating the software industry for ages and have never delivered the agility demanded by today's dynamic business needs. One simple reason is the broken reverse feedback loop between portfolio planners and the actual teams doing the work. This failure is very evident in an organisation within a few months when people talking about the portfolio have no clue about the current engineering practices on the ground and are very soon making numbers of their own. PMOs structured like this live in a fantasy land thinking that they are adding value.
While in the midst of such top-down planning the larger problem often gets forgotten.
If your business needs the level of agility that can push newer products to the market, it will not happen if there is no adaptive budgeting in the organisation. If frameworks like SAFe work within a yearly budgeting model, they are bound to fail. And this is what happens in every large enterprise that has a lot of resistance in moving away from their traditional annual budgeting models. The top down approach puts the budget and the product even further away from each other only to make it extremely difficult to determine the value from the investment made.
The solution to all this lies in keeping investments and products as close to each other, and as close to teams that use the investment to deliver value.
There is no easy path to scaling. And one size does not fit all. Here are some things to try.
- Move away from annual budgeting and look at a rolling wave budgeting model based on return on investment.
- Focus on realising value quickly by reducing time to market and feeding that back into your budgetary processes
- Don't fall into the trap of standardisation when scaling agile development.
- Push more autonomy to the teams and keep teams closer to budget and product so that you have a better sense of return on investment. It also provides the team a larger sense of purpose.