That awkward talk about scaling

Portrait of a Scrum
Master as a young man.

When the signatories of the agile manifesto got together sixteen years ago, they had no idea what they created would be the basis for a reformation in the business community. I have been part of the agile movement since 2009.  I am a short timer.  During my brief agile practice, I have noticed a trend.  Software projects are getting bigger, and it is becoming increasingly difficult to lead these projects.  This week I want to talk about scaling agile as software eats the world.

When I first learned about agile and scrum, I felt like the apostle Paul on the road back from Damascus.  It was like being struck by lighting and seeing the world for the first time.  The team did work in sustainable chunks.  Stakeholders would receive rapid feedback about how the project was going.  If something was wrong, it could be escalated quickly up the chain of command.  The ability to create software would become more sane and human.

I was deeply deluded.  I did not count on the ingenuity of my fellow software developers to avoid work.  I was blind to the inertia which exists in the modern corporation which rejects new approaches to solving problems.  Finally, executives and financial professionals see agile as a threat because it undermines their need for command and control.  Confronted with these realities, agile and scrum became a means to help small teams ship software promptly.  As individual groups became successful, management began paying attention.  Soon entire Agile consulting teams sprang up offering Scrum Masters and developers who could rapidly bring software to life.  For three years, everything was going well, until enterprise software application attempted to be agile.  It was 2012 and agile hit awkward puberty.

Software teams would be sprinting at different cadences.  Some teams would be sprinting every three weeks while others would be on a two-week cycle.  Network teams were not even sprinting and would treat requests on a first in first out basis.  Finally, the marketing team would be making promises which others would have to keep.  I and others would ask, how do you scale Agile across multiple groups and projects with hundreds or thousands of developers?

The answer has fractured the agile world into three camps; scaling with scrum, SAFe, and LeSS.  I have received formal training in scaling with Scrum and SAFe.  I am looking forward to attending LeSS training in the new year.  Each camp is involved in a friendly rivalry with each other.  Each approach seems to be dealing with project scaling differently.

My first exposure to scaling agile was called, “scaling with scrum.”  The approach was very organic.  As an organization grew, the backlog of work would splinter into smaller backlogs.  These backlogs would then be delegated to teams and completed. In the end, these smaller backlogs would bubble up into a “master backlog,” so that leadership could track what was happening.  I liked it, but it did require plenty of administrative work.  It also assumed that everyone was in perfect communication with everyone else in the organization.

My next exposure to scaling came from the world of SAFe.  This framework has caught on with more prominent organizations because it has a command and control structure which is very familiar with executives.  Scrum Teams bubble up into release trains, and those trains have particular departure dates.  Networking, Software, and Hardware all obey scrum or a Kanban approach to work.  Leadership over three or four sprints then witness a “product increment” and inform what direction to take next.

I like SAFe.  It feels like a good marriage of agile and corporate structure.  I see three principle drawbacks.  First, executives can maintain a top-down approach to innovation and control of the software process.  Next, SAFe depends on quality Product Ownership, and this is the weakest area of the agile movement.  Finally, working in a SAFe development environment feels like being a cog in a giant wheel.  If we can figure out how to mitigate these issues, then SAFe might be the future of agile.

As an agile coach and scrum master, I have borrowed liberally from the scaling frameworks.  One of the tenants of the Agile Manifesto is, “…responding to change over following a plan.” So I found it necessary to incorporate elements of SAFe which work with those which can wait.  I use scaling scrum with scrum all the time in my agile practice.  I also rely on the suggestions and directions of my peers and management to get software shipped out promptly.

In my opinion, we are still in the awkward years of the Agile Reformation.  We are very good at shipping software from small teams, but when we try to scale to large multi-national corporations, we still have plenty of work to do.  Software is eating the world, and if we are not careful, it will consume agile and scrum.

Until next time.