A false sense of agility at scale

"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.

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.

An agile enterprise...really ?

Every IT enterprise claims to be agile or wants to transform into one pretty soon. There are roles, processes, consultants and certifications, that specialise in Agile these days. But deep within these big enterprises who want to climb the Agile bandwagon, the meaning of being agile is lost.

If you are part of an IT enterprise ask yourself a few things by observing the people around you who are responsible for building the software to power your business.

Are people around you worried more about what is an Epic versus a Feature or a Story ? Are people discussing about what should happen in an Iteration/Sprint/Release planning meeting endlessly ? Is there disagreement on how things should be stored in that new Agile project management tool that your company just bought ?

 Think Individuals and Interactions over Process and Tools. 

What is more important here is not what an activity or an artefact is labelled as, but how we as software craftsmen create easy mechanisms to interact and collaborate and get the job done. Hiring a smart developer is way more important than coming up with a smart label or a process. That developer you hired will figure out a way automatically, trust me.

I would like to stress even more on the individual. How much is the developer you just hired empowered ? Can he/she pickup a story to be developed , question its business value when in doubt and challenge the product owner into not getting it developed ? Can he/she even visualise this as a remote possibility in between all the "Agile process" loops one has to cross ?

Look at people around you once again. Are they saying a story should not change within a sprint/iteration etc..? Are your sprints and releases locked in for even a few months at a high level ?

Think Responding to change over Following a plan

How are your people embracing or even responding to change ? Isn't it just another way to follow a plan ? What does it take for a developer on the ground to say a particular story will take 2 more days than what he/she thought initially ? What is the behaviour of people around when such a thing happens ? How easy is it to adapt to this reality in your organisation ?

So.. is your enterprise really agile after all ?