Scaling seems to be the word of the day within the agile movement at the moment. Personally I cant help wondering if we're in danger of missing the benefits it brings to a mature agile orientated company by thinking about scaling in the wrong way.
Natural Growth vs Competitive Edge
As agile adoption increases more and more delivery functions are now utilising some degree of agile methodology or practices within their SDLC. Over time this brings with it the obvious challenge of what happens as you mature your process. How do you maintain that competitive advantage if your competitors are all now using the same agile practices to release new, valuable, functionality quickly and frequently to your customers?
"Aha" I hear you say - all you need to do is scale. Scaling the process that currently works will mean that we can do more in the same time period, getting us back to being one step ahead of our competitors.
Whilst this is true, the approach opens up conversations about economies of scale and what exactly we mean about scaling agile.
Whether your scaling approach is based on the Scaled Agile Framework (SAFe), the Spotify tribal model, or something else, the original aim was probably to build on the good things that agile is doing for your organisation and increase the diameter of the delivery pipeline. Basically for the purpose of this article I am imagining that you saw agile working within a small delivery team and wanted to take it to the next level and implement something that would allow you to get more 'product' out of the door. Mentally this may have been visualised through increase the number of development squads in some way.
If so then what you envisaged was horizontal scaling (or scaling out) and is all about increasing capacity. There is no doubt that in a customer centric organisation this does have benefits. An increase in delivery capacity allows more resource to be utilized in responding to customer requests, investing in innovation / prototyping as well as optimization of existing products such as through multivariate or A/B testing.
However when viewed in the context of the rest of the organisation, investing in scaling out is often akin to reverting back to waterfall and throwing work over the wall between business functions. In the same way that we learnt that having a large development team but a undermanned test team would jeopardise the delivery or quality of the product, only scaling out agile delivery brings with it the risk of simply move the pinch point elsewhere within the organisation.
As an example, ask yourself if a faster product delivery capability would really help your brand if you have a call centre which is unable to respond to customers requests for help as they are operating at 100% capacity?
The other type of scaling agile is vertical scaling (or scaling up). This is where the change isn't aimed at increasing the capability of a single business function, but rather targeting the spreading agile principles within the organisation with the aim of uplifting the whole business.
Scaling agile in this way mirrors ideas based around seeing the whole organisation as a holistic system to be uplifted. In the same way that a chain is only as strong as it's weakest link, scaling up attempts to improve the organisation as a whole by sharing what works well between business functions.
Systemic flow mapping of either the information or work within the organisation often highlights the bottlenecks and pinch points which are prime candidates for scaling up. Often these pinch points lie on the handover areas between business functions. For example; does the frequent release of new products and features mean that marketing team are constantly task switching to get the message out to the customers? Are the tools and practices employed by the BI team fully optimized with how the R&D team operate?
It is worth stressing at this point that scaling up agile does not mean implementing a standard process across all teams. Standardization may be the answer for some organisations, but for many others it introduces a notion of "process over people" which is one of the things the whole agile manifesto attempts to get away from.
Instead the practical aspect of scaling up agile may be to take the best of what works well within agile delivery and cross pollinate it into a new team or business function. In the example above, the marketing team may benefit from using WIP limits within a kanban system to prevent context switching and achieve predictable delivery on what is deemed important. Equally the principles of paired programming may be implemented by pairing up members of the BI and the R&D teams onto individual tasks.
The Correct Balance
As with most things in life, the key is a balanced approach. You don't necessarily need to put off scaling out your delivery capability but it should be considered (and planned) as part of a wider agile driven business change strategy.
In some organisations there will always be a desire to grow in order to increase the speed to market of the product. Organisations which do not grow (or scale out) find it all too easy to stagnate and lose ground against competitors. This said though without the holistic improvements which come by scaling up agile, any business growth within delivery would be similar to the notion of tech debt (where compromises are made so that new functionality is released but at the detriment of future work). The organisation is essentially storing up issues which will need to be addressed in the future, usually at a higher cost.
Fundamentally we want to avoid the position where the end customer gets the skewed experience of only receiving the benefits of a shiny new scalable delivery function, whilst the other business functions are left to play catch up... until its time for the next organisational re-structure.