Complex software requires the efforts of more than just 1 Scrum team. So in this article I discuss:
- How to scale Scrum to large programs and portfolio.
- How to avoid common mistakes in Scrum.
Originally Published by Scrum Alliance:
I am proud that the Scrum Alliance editorial team reviewed, approved and published this article on their web site, originally released in December 2015. I am re-publishing a few articles previously published on the Scrum Alliance site, here on my blog because I will soon begin publishing more articles on Scrum expanding on the ideas in these articles and covering new ones.
Scaling Scrum UP
Got a big product with big programs and big problems ? Then you need to scale your Agile Scrum implementation to many teams and locations. The school of thought and knowledge to turn to, to scale Agile is the Scaled Agile Framework (SAFe).
SAFe provides a large framework for scaling the Scrum process and Agile principles to a much much larger environment. All the way up to the largest enterprise. And in the last few years there have been noticeably more 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 Scaled Agile Framework (SAFe) web site contains a break down of the framework covering team, program and portfolio levels. The SAFe framework is presented on the web site as a diagram called the Big Picture (pictured below).
 |
| Scaled Agile Framework Diagram |
All of the elements of the Big Picture diagram on the SAFe web site, the roles, teams, activities and artifacts, are all clickable so you can drill down into a description of each. It’s an excellent way to begin learning SAFe.
It’s creator, Dean Leffingwell, has elaborated into even more detail in his books. Dean’s most recent book is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. This is 1 of the 3 books I highly recommend in my book review article 3 Agile Scrum Books You Must Own. While the web site is very useful, if you are going to be serious about attempting to scale Agile, then you need to buy at least this book.
SAFe has a community that’s developed around it and is becoming more and more visible in the job market. There is formal training and even certifications available.
Stay Close to your Customer and your Team Members
Product management, project management and UX design need to be close together. Like…. in the same office. Scrum and Agile principles state a need to have team members in the same location. So collocation must be part of your strategy. That’s because teams are dramatically more productive and effective that way.
But, we also know that distributed teams are often a fact of life these days. And we can make it work much better with a scaled Agile strategy. But first you need to admit and recognize that it is not the best way to manage software development.
When teams work closely together, co-located 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 specifically are about fast communication, continuous delivery and simplicity – to name just a few. Distance between team members gets in the way of this. What’s faster and easier ? Writing an email or 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 |
Ambysoft publishes a number of useful survey results on various Agile topics, among other things. One of their surveys that was included in the official Scrum training courses that I attended years ago and is referred to often in Agile circles, shows that the success rates of co-located teams are significantly higher than those of distributed teams.
Here are the definitions of the team distribution types used in the survey:
- Co-Located Team – In the same physical room.
- Near Located – In different cubicles/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 which would require significant travel to get to.
Source: Ambysoft’s Agile Adoption Rate Survey Results: February 2008
You get better quality software, much faster, if the team is all in the same location. If you can’t do that, then you’ve got a problem you need to solve. Admitting 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/Scrum, then you will suffer from all the downsides that distributed teams bring. If you admit and face the truth, then you can make it better. You’ll never make it as good as co-located teams, but you can make it work.
How to avoid common mistakes in Scrum
So how can you make it better ? Here are some principles to follow.
Outsource your Tech Projects
If you are not in the software business, then give the entire tech project to a vendor who is. In other words, if your expertise is in retail or manufacturing or hotel management or whatever, and not 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 skill sets and expertise, deferring approaches to the Scrum process, and more. And at worst would create conflicts of interest and unhealthy competition.
Small Scrum Teams
Organize your teams in to Scrum teams. Small, focused and manageable units. Following Scrum guidelines, that means ideally 5 to 9 people. 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.
Complete Skill Sets
Design the Scrum teams to contain all of the skills that are required to complete major units of work. Use the definition of done as a guide to what a complete unit of work is.
This means do not have separate teams doing QA, content management, release engineering to dev and QA environments, or anything else needed to build complete and releasable software.
Full Automation
There are a set of Agile software engineering practices known as Continuous integration and Continuous Delivery or CI / CD. These practices take the next step beyond the Scrum process towards being truly Agile. And many organizations do not pay enough attention to the Agile engineering processes, and that causes there Agile transformation efforts to at worst fail, and at best be much less effective.
When implemented they promote the use of full automation of the software development process, higher quality, and faster development and release, among other benefits. And 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 or geographies or organizations. All Scrum team members should be co-located in the same office room or area. This is a key principle of Scrum. And the studies discussed above demonstrate how much more effective teams can be when they are co-located in the same space.
Self Sufficient Teams
Scrum teams should be self sufficient and self contained, not depending on anyone outside the team to complete work. IE. Each Scrum team should have a ScrumMaster, a Scrum Product Owner and have all the tech skills needed to get to done. The team should have all the skills needed to deliver a working product every Sprint.
Now in many conventionally organizes software organizations they will likely have product managers who would be ideal as Scrum Product Owners. But 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 can be staffing the Scrum teams with proxy Scrum Product Owners. People who have product and business analysis expertise, and can be dedicated to support Scrum teams and be co-located with the teams.
Redundancy
Design in redundancy to capture back some of the value and productivity lost when using distributed teams. IE. Have 2 complete Scrum teams in 2 different locations with the same skill sets. By doing this, you can still take advantage of differing 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 which can be pulled from their own Product Backlogs or 1 large Product Backlog. To coordinate the separate teams you would use program and portfolio levels techniques described in the Scaled Agile Framework (SAFe).
Work Life Balance
Preach and practice a healthy work life balance. Many companies just talk about this, but do little to put it into real practice. Providing a healthy work life balance will make your employees happier, work more productive and as a result lower turnover, increase sustainability and improve quality.