Get certified - Transform your world of work today

Close

How to Scale Scrum

Scale Scrum and avoid some common mistakes

9 December 2015

Kenneth Adams
Apple, IBM and more...


Developing complex software requires the efforts of more than just one Scrum team. In this article I'll focus on the following strategies for scaling your Scrum implementation:
  • How to scale Scrum to large programs and portfolio
  • How to avoid common mistakes in Scrum


Scaling Scrum

Got a big product with complex programs and big problems? Then you need to scale your Agile Scrum implementation to many teams and locations. The school of thought and knowledge domain to turn to is the Scaled Agile Framework® (SAFe).

SAFe provides a large framework for scaling the Scrum process and Agile principles to a significantly larger environment, all the way up to the largest enterprise. In the last few years, there has been an uptick in leading companies, in and out of Silicon Valley, not only fully embracing Scrum but adopting SAFe to scale their Agile implementation throughout their enterprises.

The SAFe website contains a breakdown of the framework that covers team, program, and portfolio levels. The SAFe framework is presented on the website as a diagram called the Big Picture. All the elements of the Big Picture diagram on the SAFe website, such as the roles, teams, activities, and artifacts, are all clickable so that you can drill down to a description of each. It’s an excellent way to begin learning SAFe.

Its creator, Dean Leffingwell, has elaborated on SAFe in his books. Dean's most recent book is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. This is one of the three books I highly recommend in my book review article "3 Agile Scrum Books You Must Own." While the website is very useful, if you are committed to scaling Agile, then I recommend that you at least buy this book.

SAFe has a community that supports it, and it is becoming more visible in the job market. It provides formal training and even certifications.
 

Stay close to your customer and your team members

Product management, project management, and User Experience design must have a tight working relationship. Scrum and Agile principles state a need to have team members in the same location, so colocation must be part of your strategy. Teams are dramatically more productive and effective when they're colocated.

We also know that distributed teams are often a fact of life these days, and we can make that work much better with a scaled Agile strategy. But you must first admit and recognize that it is not the best way to manage software development. When teams work closely together, colocated in the same office space, it dramatically improves communication quality and frequency, greatly accelerates response time and issue resolution, and completely collapses cycles of all kinds.

Agile principles, in general, and the Scrum process are specifically about fast communication, continuous delivery, and simplicity (among other things). Distance between team members gets in the way of this. What’s faster and easier? Writing an email or writing an issue in an online issue-tracking tool and waiting a day for a response? Or walking across the room and getting an answer right now?
 
Project Success by Team Distribution
Project success by team distribution

Among other things, Ambysoft publishes a number of useful survey results on various Agile topics. One of their surveys, which was included in the official Scrum training courses that I attended years ago and is frequently referenced in Agile circles, shows that the success rates of colocated teams are significantly higher than those of distributed teams.

Here are the definitions of the team distribution types used in the survey:
  • Colocated Team -- In the same physical room.
  • Near Located -- In different cubicles or offices, on different floors, or in different buildings but could still get together easily, if required.
  • Far Located -- Where some team members are at a different location that would require significant travel to get to.
(Source: Ambysoft's Agile Adoption Rate Survey Results: February 2008)

If the team members are colocated, you get better quality software faster. If you can’t make arrangements for colocation, then you’ve got a problem that you must solve. Admitting that a problem exists is the first step to fixing it. If you continue to fool yourself into believing that distributed teams are better and cheaper and deny the fundamental truths about human nature and Agile and Scrum, then you will suffer from all the downsides that distributed teams bring. If you face the truth, then you can make it better. You'll never make it better than colocated teams, but you can make it work.

So how can you make it better? Here are some guidelines that you can follow:
  • Outsource your tech projects. If you are not in the software business, give the entire tech project to a vendor who is. If your expertise is in retail, manufacturing, or hotel management and not in technology, then outsource your technology projects to the experts.
  • Don’t split a project across vendors. Don’t split a project across vendors and especially do not split teams across vendors. At best, this will cause project teams to be less productive due to additional overhead, communication difficulties, inconsistent or varying skill sets and expertise, deferring approaches to the Scrum process, and more. At worst, this would create conflicts of interest and unhealthy competition.


How to avoid common mistakes in Scrum

Create small Scrum teams

Organize your teams into Scrum teams that are small, focused, and manageable units. If we rigorously follow Scrum guidelines, that means forming ideally five to nine-member teams. If the team is too small, it can’t be as effective. Too large, and it becomes unmanageable and less productive because it requires too much overhead dealing with longer Scrum meetings and large backlogs.

Ensure that the team has complete skill sets

Design the Scrum teams to contain all the skills that are required to complete major units of work. Use the Definition of Done (DoD) as a guide to what a complete unit of work is.

This means that you do not have separate teams doing quality assurance (QA), content management, release engineering to development and QA environments, or anything else needed to build complete and releasable software.

Fully automate the software development process

There are two sets of Agile software engineering practices known as continuous integration and continuous delivery. These practices go beyond the Scrum process and toward being truly Agile. Many organizations do not pay enough attention to the Agile engineering processes, and that causes the Agile transformation efforts to either fail or be less effective.

When implemented, the practices promote the full automation of the software development process. As a result, you gain the benefits of a higher quality product and faster development and release. By full automation, we mean automation of code management, software builds, QA testing, and deployments to all environments.

Keep the team together

Don’t split a Scrum team across offices, geographies, or organizations. All Scrum team members should be colocated in the same office. By doing so, you're upholding a key principle of Scrum. The studies discussed earlier demonstrate how much more effective teams can be when they are colocated.

Create self-sufficient teams

Scrum teams should be self-sufficient and self-contained and not depend on anyone outside the team to complete the work. For example, each Scrum team should have a ScrumMaster, a Scrum product owner, and have all the technical skills necessary to get to DoD. The team should have all the skills needed to deliver a working product every sprint.

In many conventionally organized software companies, they will likely have product managers who would be ideal as Scrum product owners. However, they are often managing many projects and products and don’t have enough capacity to properly support Scrum and Scrum teams. So, a reasonable compromise is staffing the Scrum teams with proxy Scrum product owners. These are people who are colocated with the teams and have product and business analysis expertise and are dedicated to supporting Scrum teams.

Maintain redundancy

Design redundancy into your team infrastructure to capture some of the value and productivity lost when using distributed teams. Create two complete Scrum teams in two different locations with the same skill sets. By doing this, you can still take advantage of varying costs in different markets while scaling up your capabilities faster and lowering your risks by not putting all your eggs in one basket — or job market.

Each Scrum team would manage their own sprint backlogs that can be pulled from their own product backlogs or a master product backlog. To coordinate the separate teams, you would use program and portfolio-level techniques described in SAFe.

Strike a work-life balance

Preach and practice a healthy work-life balance. Many companies just talk about the concept but do little to put it into practice. Providing a healthy work-life balance will make your employees happier and more productive. As a result, you'll experience lower turnover, increased sustainability, and improved quality.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (5 ratings)

Comments

Ryan Eno, CSM,CSPO, 12/9/2015 7:34:45 PM
Here is what I love about this advice on scaling Scrum: to succeed, focus on the basics. Successful Scrum is about disciplined execution, not complex systems.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe