How to scale scrum for agile teams

Introduction

One of the hottest questions these days, whether online or in the boardroom, is “How does the organization become more ‘agile’?” As the discussion evolves, it leads to, “How do we scale agility from one team to multiple, or should we?” Scrum is the most common agile way that teams work leads to the question of, “How do we scale Scrum over a single team?” However, the question should instead be more concerned with what product(s) is being delivered and what is the most effective way of doing so.

When should you scale Scrum to multiple teams? This question isn’t as difficult as it may sound. Scrum is based on the delivery of a product. The highest development team size is between 3 and 9 people plus the product owner and Scrum Master. This means that if you can deliver your product with a team of 9 people or less, then there is no need to scale. If you determine that you need more people, then the decision to scale must be made, but scaling decisions should not be taken lightly. As soon as you go from a single Scrum team to more than one, you now have added cross-team communication and dependencies. This can be solved, but it is something that has to be considered and addressed.

Agile is fast becoming a general way industries act, work, and behave as they look to improve efficiency, minimize costs, and empower staff. Most software developers naturally act, think, and work this way, and alignment towards agile software methodologies has gathered pace in recent years. VersionOne’s 2018 State of Agile report shows that scrum and its variants remain the most popular implementation of agile. This is in part due to changes made to the Scrum Guide’s wording in recent years that make it more amenable to non-software industries.

  • Understand the challenges of delivering working, integrated product increments with multiple teams, and how Nexus addresses them
  • Form a Nexus around a new or existing product and learn how that Nexus sets plans and goals its work
  • Run Sprints within a Nexus, conduct effective Nexus Sprint reviews, provide transparency into development, and use Nexus Sprint Retrospectives to continuously develop
  • Overcome the distributed team collaboration challenges

Challenges of scale

Too often we hear people at conferences or in meetings talk about how they want to “go agile” or “buy agile,” but they lack the understanding of what that really means. When digging into the conversation, it tends to go down a pathway that they can just buy some tools and apply some processes and now they are magically agile, but that just isn’t the case. There is no “silver bullet.”

Like if you have a team of two people working together, you start to encounter dependencies on each other. Now as you scale up to multiple people, the dependencies boost as well. Imagine now scaling to multiple Scrum teams working together to deliver a product, the dependencies will not only cross individuals but also Scrum teams.  As product backlog items are being decomposed; dependencies will emerge. It is highly recommended that you categorize dependencies and visualize them to make it easier to embrace and communicate them. Categories for dependencies may include products such as:

  • Build Sequence – A product cannot be completed until its parent is complete
  • People / Skills – Only certain people/teams can complete a product
  • External – The parent item is being delivered from outside the Scrum teams

What results have you seen from this approach?

  • We had tremendous success in earlier years in places like Adobe, Intuit, Cisco, Salesforce.com, Google, and smaller companies that were investing heavily in new products, change, new ideas, and being better. The idea of empowerment, change, and lean products were great. The successes created the momentum and buzz of the agile movement. This caused the business press and conferences to laud the agile movement, to identify it as the key to software project success. But even though these organizations see others that have done better, they are comfortable, don’t have any critical problems, and are organized and transaction-based, acculturated to predictive, hierarchically managed organizations. The benefits of agile may be covetable, but there is nothing pressing that justifies the needed work and culture change.
  • These later organizations use the traditional way. Commit to buying a solution that doesn’t require culture or engineering change, only a change of nomenclature and structure. Instead of putting in the hard work of figuring out how agile would work and devising a continuous development plan to get there, organizations are sold agile as an implementing template, one size fit all. rather of the cost being the sweat equity paid by the early organizations, these later organizations try to buy in.
  • So, if we want regularity and prescriptive and we want agile, that’s a conflict. Scrum is very easy, but it’s also very hard. The hardness is putting people in conflict with old habits to get new results. If the problem the organization faces isn’t so compelling or so awful that people know they have to change, they go with what feels comfortable.

Looking beyond scaling scrum and Nexus, what new innovations do you see coming?

  • The software has enough complexity that efforts with more than 100 people are problematic. Efforts that, because of their functional broadness or technology, require more people should have multiple 100-person efforts, multiple maxed-out Nexuses. We are working on development of Nexus, Nexus+, that is a platform approach that provides standards through which the individual Nexuses can combine without creating dependencies. These platforms are including APIs, architectural, operating systems. They even point at the presence of SDKs that further simplify the Nexus development effort.
  • Integrating platforms are being devised to support complex, development and large-scale systems.
  • We also intend to emphasize our evidence-based management tools for measuring the value that organizations get from their approach to agility and scaling. These rely on time to market, measurements of value, and innovation to assess the organization’s software capability, both as a whole and in particular products or systems.

Conclusion
At the end of the day, Scrum is a simple framework that is difficult to master. Scaling Scrum or just scaling up to bigger teams adds complexity to how people and teams work. Being a framework, Scrum provides an excellent way to helps teams scale without having to change their entire worlds. Scaling Scrum is just Scrum. You don’t change how you work as a Scrum team nor do you change the work being delivered. By adding the Nexus framework on top of Scrum, it provides teams with a way to deal with cross-team dependencies and ensure that they are all working together toward a common product increment and product goal

Barghavi

Share