If you are already running Agile/DevOps teams, sooner or later, you will reach a fork in the road where you need to decide how to scale your teams. By “scale”, it means that you seek to expand your current teams into several similar or specialized teams to either increase the volume of work produced, or to enable the teams to collaborate effectively towards a larger, more sophisticated technology solution. In either case, you will likely need to consider many scaling frameworks that are available today. This may be a very difficult decision if you have not yet done research on what may work for your organizational context. In this article, I will offer a few insights based on my experience applying a variety of models, which I hope to assist you in your decision.
When it comes to scaling Agile practices, you will find that many of the popular frameworks in use today are based on the Scrum framework or the Kanban method. Assuming you are familiar with these, you will need to consider a few factors that are worth exploring. Since there are too many possible approaches to be analyzed in a short article, we shall keep this article as focused as possible and explore some of the more popular models such as:
- Scaled Agile Framework (SAFe) – this is the most popular scaling model in use today, based on the 14th Annual State of Agile Report (CollabNet).
- Scrum at Scale (S@S)
- Large Scale Scrum (LeSS)
- Disciplined Agile (DA)
So, what factors do we need to consider prior to choosing a scaling framework?
Scaling Factor #1 – What model do you use today?
If you are primarily using Scrum today for your teams, you there are no huge obstacles that would prevent you from utilizing any of the four frameworks mentioned above, all other things being equal, that is. However, if you are using a Kanban approach, you may find it difficult to scale using Scrum-based models such as Scrum at Scale or Large Scale Scrum, which were designed for Scrum teams.
Scaling Factor #2 – How many teams (or people) need to work together on a single product?
If you have more than 125 people that will be working on a single product, Scaled Agile Framework could become challenging to apply, unless you deploy multiple Agile Release Trains (i.e. teams of teams), which may significantly increase your overhead and complexity. If you are in this situation, you may wish to consider the other models which could be easier to adopt, especially if you already have experience in Scrum.
Scaling Factor #3 – How likely are you to mix or evolve your team models in the future (i.e. switch from Scrum to Kanban teams, or vice versa)?
Based on my experience, most organizations that scale Agile and DevOps teams tend to choose one approach and stick to it for a long period of time, which seems ironic; teams should be prepared to evolve over time in order to optimize their agility and flexibility. It is my recommendation that growing organizations should look ahead and not be too bogged down in the choice of scaling framework that is applied in the short term. This is easier said than done, of course, especially when companies often invest large sums of money sending teams to expensive training classes to learn a new set of terminology in order to adopt a brand new model. I believe that some models are designed to be “sticky”, meaning that once you start using it, it is very difficult (and costly) to change; essentially, you are “joined at the hip” which contradicts the idea of becoming a more agile organization. Hence, it is my preference for organizations that are new to scaling to apply a more flexible scaling approach in order to experiment and learn what works and what does not work. If you agree with this line of thinking, then I would suggest you to consider Disciplined Agile which offers a multitude of variations that enable you to apply either Scrum or Kanban-based methods. In my opinion, DA also provides much more fluidity in terms of evolving the practices using a goal-based approach. As the DA founders say, “Choice is good”…who doesn’t like choices?
Scaling Factor #4 – How important is DevOps to your organization?
Without getting into a debate over whether Agile is possible without DevOps, or vice versa, I strongly encourage you to think about how important “DevOps” is in your organization currently, and in the months to come. The reason that this is important in this context is that many of the scaling models focus solely on the “Dev” component of “DevOps”, meaning that the “Ops” component is either missing completely or barely accounted for. Of the four models I mentioned, Scaled Agile Framework and DA provide some limited guidance on the operational aspect of “DevOps”; I feel obligated to share that the guidance offered is fairly high level, which is expected given that these are frameworks instead of detailed, prescriptive methodologies with detailed procedures. That said, Scaled Agile Framework and DA do indeed establish some connectivity between your Dev activities and your Ops concerns.
In closing, scaling Agile and DevOps practices is no easy task. It can be one of the most challenging and stressful things that an organization aspiring to be more agile will encounter. However, it could (and probably should) also be seen as a great opportunity to do something truly great and meaningful. If you are in a position to scale your teams, that means you are doing something right. Take advantage of this success and build on it. You may achieve even more than you ever imagined.