Managing scaling pains has been an ancient problem for engineering and product development companies. In the 1920s, solutions such as mass production or flow production were used for scaling the quantity of production, while maintaining quality.
Mass production is pretty energy intensive, as it uses a high percentage of machinery and energy in relation to workers. It is also usually automated while total expenditure per unit of product is reduced. However, these techniques did not make it easy to alter the design of the product.
In the 1980s, lean manufacturing principles were popularized by the Japanese manufacturing industry. These principles helped make the scaling process more flexible by using processes like Kanban and value stream mapping. The software Agile industry’s current scaling problem is not very different. The only problem in software products is that we don’t have the same sophisticated automation tools used in manufacturing, like robots and conveyor belts.
Agile software companies do most of their coding manually while automating the integration and deployments continuously. This limitation introduces scaling pains to Agile companies trying to scale at a fast pace.
Agile principles in general do not specify any strategies for scaling. The Agile manifesto simply lists a set of principles to follow in order to be Agile.
Several Agile software development strategies such as Scrum and others were introduced in the early 90s to overcome the limitations faced due to sequential software developments processes such as Waterfall software development lifecycle.
Scrum gained popularity and was effectively used by several smaller sized companies since then but large companies had trouble implementing it. Since the Scrum framework itself does not specify scaling strategies, companies had to come up with their own ideas to scale with Scrum.
Lack of good scaling ideas in Agile environments set a stage for controversy for Scrum and the Agile world in general. Early implementers often blamed Scrum and other Agile methodologies for their implementation failures.
The millennial users of Agile were the pioneers in exploring scaled agile frameworks in the software industry. Since then, several scaled Agile frameworks such as Nexus and Scaled Agile Framework have come up. Pure bred Agile supporters have doubted these scaled strategies by calling them out as not being 100% Agile.
This philosophical conflict has created a more desperate need for an established scaling strategy for Agile companies trying to scale, while not losing their core Agile culture.
10 Ways to Painlessly Scale Your Agile Company
Hiring someone who has been there and done that takes several months of the scaling learning curve away from new Agile adopters. I have seen Agile coaches transform organisations time and time again, speeding up the productivity and transparency within just a few weeks. It is important for the leadership to have faith in the Agile coach and be patient for the efforts to bear fruit. If hiring an Agile coach is not an option for you, you at least need to get a credible Scaled Agile certification like Scaled Agile Framework (SAFe) or Nexus and implement it by the book the first time around.
A costly mistake which many companies make is they only train the product development team on Agile principles. If you want to make a sustainable change you better train your leadership and your clients. Several companies fail to scale in Agile because the upper leadership follows command and control while they expect the product teams to be Agile. Status reports seem out of place in the Agile world, if you know what I mean. This conflict will keep blocking the scaling progress unless the leadership truly understands the core Agile values.
In order to scale in Agile you need much more than a process. You need a collective company culture which is transparent, empowering and follows a bottom up product development approach. After the initial training, empower few enthusiastic employees to play the role of Agile mentors for your projects. Embed these Agile mentors in your product teams and give them the tools to spread the Agile culture.
Scaling becomes literally impossible when the schedule is a driving factor of the project. Before making a schedule use value stream mapping techniques to understand the true value your product brings to the customer. Identify products based on your value stream and drive your project by these products. This ensures the scaling is targeted around products that bring value to the customer.
Scaling is meaningful and productive when each identified product can have its Scrum team. When scaling is done merely for supporting overall project functions such as testing, development etc. then the scaling goes out of control because the focus is shifted from the product to the schedule. When the scaling holds value it will naturally sustain for a longer time without much effort.
Agile release train (ART) is a strategy used in the SAFe framework which gained popularity in the last 5 years or so. One ART is limited to 125 people and includes several Scrum teams within it. There is a Release train engineer (RTE) who is designated to coordinate the various activities of all the product teams. This is a proven concept which has shown productivity increase for scaling Agile teams.
A weak DevOps model is one of the primary causes of scaling pains. A solid DevOps model helps automate with integration, quality, and deployment of the code. If you add a strong DevOps team to this makes scaling easy. Form a DevOps team which handles continuous integration and continuous deployments (CICD) ensuring that the product gets delivered to the customer as soon as it’s shippable.
Depending on the size of your project team, you may end up creating several ARTs which include several Scrum teams. While each ART will be in the safe hands of an RTE, keeping track of all the various events can be a pain. Employ cadence to tackle this problem. Make all teams have iterations of the same length, working in cadence.
Once cadence is employed, synchronize the start and stop dates of the iteration activities of all teams within the ART. This makes events more manageable and outcomes more predictable.
Scrum of Scrums is an effective way for the entire team within the ART to synchronise with each other. This keeps the train moving in the right direction while scaling.
- Scaling has been a problem forever, and the lean manufacturing pioneers were the first to overcome it by automating their processes using robotics.
- Software development has faced similar scaling pains in recent times due to the obvious problem of most coding being written manually.
- There is a growing conflict between pure Agile adopters and scaled agile frameworks such as SAFe that seem to be more rigid.
- In order to scale painlessly you can: hire an Agile coach, train both leaders and subordinates on Agile, empower Agile mentors, use value streams, form teams around products not the schedule, create ARTs, invest in DevOps, follow cadence and synchronicity, and use Scrum of Scrums.
Scaling within Agile companies isn’t nearly a trivial task but it is only as complicated as we can make it. The key is not to reinvent processes that scale but to scale existing Agile processes to our advantage.
In my honest opinion, the conflict of Agile versus command and control culture is what determines whether a company scales well. As long as this conflict exists, scaling will be tough. At the end of day, remember that if the customer is getting the value they deserve at scale, most of your work is done.