All too often when a company starts to get larger, the problems that are being solved seem to feel larger also. When addressing the key problems to be solved by the Agile teams working on software or solutions for clients, it is important to make sure that we are clear in what we are trying to solve. Many people believe that scaling frameworks with Agile are necessary to address increase complexity, size or quantity of problems to be addressed or any other myriad of concerns that come up within a company. Let’s look at when it makes sense to scale and when simplification is the answer.
Single Agile Team
Perhaps this is one of the simplest forms of Agile when we have a single threaded backlog and a single team working on that backlog. You might ask yourself, why do we even need to talk about this in relation to scaling? It is crucial to draw the distinction between simple and complex as far as what allows a team or a single backlog to help a team be successful. Clarity of roles and responsibilities is important with having a Scrum Master, Product Owner and Team Members that are familiar with and supportive of one another’s roles. This is so important that it is called out in Step #3 of the AgileDad 12 Step Program. A team with a single thread or single product they are developing and supporting makes it easier for the Product Owner to specify when a new feature is being created versus fixing a pre-existing situation with the system that is causing angst for the customer. The goal is always to have a single prioritized backlog regardless of how many products or solutions are being supported so a team knows what they are focusing on for a given timeframe or sprint. In this example, no particular scaling is necessary as the Product Owner, Scrum Master and Team Members all exist within the single Agile Team to produce real working solutions on a regular basis. A key narrative I like to point out here is that the Scrum Master plays a key role in helping this type of a team improve incrementally. Pointed out in a previous podcast episode entitled “Are ALL ScrumMasters The Same? – CSM – PSM – SAFe SM – DASM”, regardless of the type of certification obtained, the Scrum Master helps the Product Owner take ownership of the product backlog to deliver the right product while helping the team take ownership of building the product right. The Scrum Master in turn takes ownership of the speed of delivery by making sure it is sustainable.
Multiple Agile Teams
When expanding beyond a single thread or single team, again it is important to remember the goal of the single prioritized backlog for a team to operate from. As long as that single backlog can exist for a product or set of products being supported, the necessity of scaling your Agile approach is minimized. However, it is never that simple is it? Taking from an example a few years ago of some teams I worked with, we oftentimes have either multiple platforms that are supported with our products where teams have some type of expertise that allows them to optimize the delivery of solutions on a regular basis. The teams I am thinking of were several within the same company that supported various mobile platforms and a desktop instance of their product. Keeping them in sync required coordination amongst the respective Product Owners assigned to each Agile Team who spoke daily to make sure they were keeping up-to-date with the changes being made across platforms so they would be supported as uniformly as possible. When first working with these teams, there would be significant delays at times between when concerns would be addressed from one team to another. Sometimes it would be days or weeks between when those various challenges would be addressed from a front end or back end perspective. With some regularly scheduled coordination across the teams, insertion of a daily Scrum of Scrums meeting, the teams were able to resolve the vast majority of dependencies that existed across their platforms and get their users the best possible experience that was consistent. This didn’t come without a very specific effort being exerted to make sure that coordination of dependencies could be measured in minutes or hours instead of days and weeks. That is a true measure of success to be had with the need for some scalability but not any overly robust way of increasing the overhead of the development effort needed.
Increased Complexity and Coordination
With the example used before, it’s very possible that many people would suggest an Agile Scaling Framework of some sort because of the number of teams or people involved. Looking at Scaled Agile Framework or SAFe for instance, whenever you have 5-12 teams or 50-125+ people, the creation of a Program or Agile Release Train (ART) is recommended to make sure that coordination of dependencies occurs and allows for the right products or solutions to be worked on at the right time. But my experience over the years has suggested that people jump into too much rigor too soon. Number of people and teams alone is not a reason alone to use a scaling framework. Even with more of a Scrum at Scale or Disciplined Agile Delivery framework being used, we need to be careful to ask ourselves why we are scaling our approach in the first place. What problem are we looking at solving as a result of the scaling effort we want to employ.
Is it helping to address some key concerns that we have with the Products we are trying to support that have dependencies with each other?
Do we have individual teams that don’t have dependencies with each other that can operate outside of a scaling framework?
Are there significant decisions that are impacted across teams that create and economies of scale benefit for being prioritized in more of a centralized area?
Look at the level of complexity and coordination involved in what teams are working on to determine whether there is a need for added support from supplementary Product and Facilitator roles (i.e. Product Manager and Release Train Engineer). Also, it is important to differentiate between product value delivery and project plan delivery. With product value delivery, we are always looking at whether we are delivering the best value for where we are exerting our efforts. In a recent podcast episode reviewing an article on SAFe entitled “I DON’T Like SAFe – A Handy Review”, Lee Henson reiterated that the focus on value delivery and the right outcome is what we need to make sure is focused on. If we focus more on the plan delivery, we risk the result of not getting what the customer really wanted as far as the desired outcome.
When you start stretching the capacity of Product Owners and Scrum Masters to multiple teams, you need to start considering some level of scalability to provide support not just to those people, but to the teams they are supporting in their efforts to deliver working solutions. Working with teams over the years has always shown me that a Product Owner should support a single team or product line being created. A Scrum Master, while they can support more than a single team should always be looked at as to the level of Agile maturity the teams they are working with have as to not overwhelm them. If a Scrum Master works with up to 3 teams and they are all in the forming or storming phase of team development, there is no way they will be available for the team as much as they need to in order to resolve conflicts that arise. I even had this happen over the past year with a Scrum Master assigned to two teams that were in the beginning stages of their Agile journey. He couldn’t dedicate his time equally across the teams and especially to the team that struggled the most. This is turn created some unnecessary tension between Scrum Master and team. Getting the right support in early for those teams is crucial when you don’t have enough people to be fully dedicated to a single team from the Scrum Master or Product Owner role. Those key roles need to be prioritized in your creation of Agile teams to make sure they are set up to be successful from the onset and not continually grasping for the basic needs and support to help them be successful.
Keep it Simple – Scale as Needed
One of the tenets of Agile is maximizing the amount of work that is NOT done. I can’t reiterate this enough when looking at how much process is used to Scale an Agile based approach. If we can resolve the dependencies we have with our Agile teams without too much added process, use that first. Perhaps it is just adding a regular Scrum of Scrums meeting and some added coordination between Product Owners and a Chief Product Owner. It could be synchronizing sprint cadence across your teams to allow for greater collaboration to occur on similar or dependent items. Any larger scaling framework requires the teams to be working reasonably well first and then helping to scale and coordinate their efforts from there. Being an advocate of scaling frameworks and a Scaled Program Consultant (SPC5), I cannot caution enough that jumping straight into a scaling platform without helping teams be more mature in their Agile development can be a recipe for disaster. I have seen it backfire and become much more of a focus on the old way of doing things just with Agile wording mixed in for tolerability sake. A focus on decentralization of decision making to allow teams to be making decisions much faster will ensure that greater success happens regardless of what scaling method you determine is necessary. As with anything Agile, incremental improvement becomes the key to success. When the need for added coordination comes up that is the time to address it and make necessary scaling steps from there. The focus on individuals and the interactions they regularly have helps to make sure the focus gets put back where it should be and ultimately identifies the processes that need to be put in place to get working solutions created on a regular basis for customers.