Scaling Agile is a hot topic. Adverts for courses on SAFe (Scaled Agile Framework) and LeSS (Large Scale Scrum) seem to be everywhere. Then there is DAD (Disciplined Agile Development – from IBM) and Enterprise Scrum and a few more approaches just emerging. The first advanced certifications announced by ScrumAlliance are concerned with scaling Scrum.
On first thought there is a kind of inevitability about this. Agile has been steadily advancing into mainstream software development since about 2008, and the slower moving large organizations such as global banks, international manufacturers and service providers, and even Government organizations, having had a taste are now preparing to eat their Agile lunch. The knee-jerk reaction is: let’s scale our Agile operations, especially for those big projects we always have. But, even though I am a SAFe Program Consultant (SPC) myself, I have a sneaking suspicion that many scaling efforts are misguided, and generate more waste than business value.
Let me begin by introducing a restaurant analogy. Recently for the birthday celebration of an extended family member, my wife and I, together with a mob of relatives and friends, ate at a chain eatery in Coventry, England near where we live. It is one of those places where you pay a single price and then eat as much as you like from an enormous buffet. Indian, Chinese and Italian specialties are included. There are also a grill, a roast meats station, and a dessert counter. Each station has its own specialist crew of kitchen staff. They make sure that there is a constant supply of food items to keep the counters fully stocked.
One of the attractions of this restaurant is that it is cheap, so I’m guessing there is a major pressure on keeping costs low. Why then, do they employ so many in the kitchen? The answer is because all of the different food items are needed both all at once and continuously. Now compare this to a much more up-market Indian restaurant that, as a couple, we more regularly favour with our custom. It has a small kitchen and a correspondingly small kitchen staff. True, its throughput of customers is not the same as the Coventry one, but it is usually packed, and it has many more menu items than the big eatery. In either place we might eat a starter, a main and a dessert, but in our Indian restaurant the chef is cooking to-order and can start on the mains even while we are eating our starter. The other place has to have all the potential elements of the meal on offer at the same time.
The point is that whether or not organizational scaling is necessary is a judgement call that depends on the timeliness of required features. The big eatery has no option but to scale its kitchen teams because all of the ‘features’ are required at the same time. Most master planned development projects have a similar constraint. ‘Big bang’ delivery means shipping all the required features simultaneously. Low value items and big value items – they all have to be delivered together. This is usually much more than a single development team of 3-9 persons (the size recommended by The Scrum Guide) can handle. Multiple teams are required. Scaling is necessary.
We need to be careful that this old muscle memory of our pre-Agile history does not go unchallenged. Agile in general, and Scrum in particular, uses the motto “Deliver early, deliver often”. And we don’t just deliver any old thing. We deliver the highest business-valued features first. Our customers can munch on those even while we are developing the next set of features.
Think about the difference. If the customers can only get everything at once, then there is likely to be high pressure for the earliest date for that “big bang” delivery. Until they get delivery they can extract no value. Every day they wait, adds cost. From the development side, the features that take the longest to develop hold back the delivery of everything in the product. Scaling is possibly the only option.
On the other hand, if the customers are getting hold of slices of functionality incrementally, and are extracting value from using those early-delivered features then they can afford to wait for the lesser-valued ones. Now perhaps the same team can deliver all of the product. At the very least we can say that scaling (the use of multiple teams) is now optional.
What I’m suggesting is that deciding in advance of development how many teams will be needed is not a great idea. Big projects should, in any case, be started with just one development team. The early technical decisions tend to be architectural ones. They will tend to impact on and constrain later choices. It is better for the architectural integrity of the product that they be taken by a single, cohesive team even as they are developing the highest valued features. It is not uncommon for a so-called ‘Beach-head Team’ (composed of the best programmer-architects available) to take responsibility in this way for the first release.
Judgements about whether to bring other teams to bear on the product can then be made just-in-time: in the usual spirit of Agile. Scale the mindset first. Apply the values and principles of Scrum. Decide empirically whether additional teams are needed to deliver the remaining features in a timely fashion. Of course, the decision-making process will require intense collaboration between the Scrum team and all the stakeholders of the project, but that’s just as it should be. The extra scaffolding of any given scaling framework should never substitute for that.
Downsizing the numbers needed to deliver a product is as much a possibility as scaling as it is traditionally thought of. At J.P. Morgan, moving from “scrum-but” to Scrum in full required removal of a whole layer of functional departments, component teams and associated level-1 managers in order to create Development Teams that could deliver end-to-end functionality to their customers (1).
There is, of course, one important factor that must be present for a single Development team to be able to deliver a large, feature-rich product on its own, without involving multiple teams: it must be truly cross-functional. All the skills necessary to develop the product must be present in the team. It takes time and effort to grow such teams. The routines and practices of the team and the individuals within it have to change as they increasingly become a self-managing group. Once achieved, this level of capability opens up the options to scale or descale.
(1) See the report by Craig Larman and Matt Winn at http://www.infoq.com/articles/large-scale-scrum-jomorgan