#89-Scaling Agile to Large Enterprises

How can agile, which has its origins in managing relatively small teams, be scaled to the overall enterprise?  There are some very important issues to address for this to be realistic.

Transcript

Scaling Agile to Large Enterprises 

Agile began as a way to manage the work of a small team, developers initially, where decisions are made quickly and problems solved by those who discover them, immediately.  Because of that origin some have come to believe that agile only applies at that level, that it is not appropriate for a large-scale enterprise to embrace agile processes. 

A large enterprise is like a big ocean-going vessel. If you are in a relatively small craft and want to turn it to change direction, that's usually a fairly low-cost effort. But with large ships, like those that transport iron ore or tons of consumer goods, turning the ship can take a tremendous amount of energy and time because of the inertia involved. This literal problem, at one point in history, led many shipbuilders to believe that there was a maximum size possible for these vessels, because beyond that the energy that it would take to move the rudder would exceed the ability of the ship's engines to turn it without damaging it. But along the way someone had an insight: if the large rudder has a little rudder of its own then you simply turn that smaller rudder in the opposite direction which creates a low pressure zone on one side of the large rudder and makes it much easier to turn.

Legendary designer and theorist R Buckminster Fuller noticed this “trim tab”, as it was called, and realized that almost any difficult human endeavor can be made more realistic and controllable by finding simple things that are low cost and yet solve enough of the problem to make it more reasonable to accomplish. 

The problem of scaling agile to the larger enterprise is a very complex topic and I will only be able to give it an introduction here. Most organizations attempting such a thing usually find it worthwhile to engage with an expert consultant, and there are many available. But I will cover a few of the trim tabs here.

The first and perhaps most important one is that teams should be aligned around value streams, rather than confined to specific business units. This is because specific groups that are siloed from one another require handoffs for the value to flow through the various teams that contribute to it. This impedes alignment, causes delays, and confuses the assignment of responsibilities.

If you think about all the activities that are required in order to create a valuable product, then you have identified a value stream. It begins at the prioritization of a set of requirements and ends when the product is successfully deployed and made useful to stakeholders. If all the various groups that need to be involved in the creation of that value are aligned around that stream of work then this reduces miscommunication, can eliminate many handoffs, and create shared accountability. 

The second trim tab is to implement a way for teams to collaborate around the same enterprise level cadence of work. This means that individuals with quite different skill sets need to be able to communicate and effectively collaborate with one another through some kind of framework. But whether you've chosen SAFe or FLex or any of the myriad of options, you will still need an efficient and smooth way to implement them.

I recommend acceptance testing as that way. Acceptance testing is done using business language, not technical jargon, and therefore can be done by literally anyone. It uses the language of behavior driven development where each behavior is expressed by three pieces: given, when, then. If you've ever written use cases this is a similar idea but it is more precise and can be automated to execute against the system, which is why we call it a “test” even though at the moment we write them they really are more like specifications. In the transcript for this podcast I will link you to a presentation I did about the details of how this works, which I think will help to make it clear why I think this is a good idea.

The third trim tab is to switch the approach of the leaders of the organization from making decisions that everyone must adhere to, to setting a direction and providing guardrails so that the team can make decisions locally. The idea of doing this can be a bit daunting to managers who have, in the past, felt that they needed the command and control structure that they are used to in order to be able to succeed in the metrics that they are accountable for. But once you can achieve a balance of autonomy and alignment you will find that enterprise agility becomes much more powerful. 

But what about organizations that are external to us and yet are part of our delivery of the value stream? How do we interact in an agile fashion with our vendors, and how can our procurement process align itself consistently with value? That will be the topic for next time. 

Webinar Link: https://www.projectmanagement.com/webinars/818036/test-driven-development-in-the-larger-context--tdd---atdd