Scrum teams versus service teams

Scrum is currently the most popular way to organize agile development teams. Scrum teams are different from service teams in some important ways. A Scrum team has 5 to 10 people. It is multifunctional, meaning that it includes not only programmers, but experts in design, database, testing, and other functions that are required to deliver a complete feature or story. All of these team members should be co-located.

Building Scrum teams is a lot of work. It starts with the dreaded "culture change." It often requires coaching to explain roles and rituals. It requires moving people around to get a group of more than five in one place, every day. It requires the other parts of the organization to let go of their functional experts so that they can add the "multifunction" capabilities to the Scrum teams. After formation, scrum teams like to work together without team changes for a number of weeks to improve their estimating and get a consistent velocity.

If you have a high-performing Scrum team, you have a valuable asset. You can keep the team together, and use it as a large service team with expanded product management capabilities. However, you will want to make some process changes. Scrum teams make "sprint" plans every two weeks, and then they stop accepting new work. So, their response time is at least two weeks. You want the fast response that you get from a continuous service team.

We frequently see service teams composed of three developers. This is the smallest team where someone can take a vacation. They are often all programmers - a tech lead, and two other developers that can learn to take over the tech lead role. Teams are small so they can be fast and efficient. They do not need to be multifunctional. They can be composed entirely of programmers. In a continuous delivery process, programmers take a strong role. Programmers call on design and test experts when they need them. The operations team provides tools for monitoring, test, and deployment, and programmers use the tools.

Building a service team is as simple as finding a tech lead, and adding collaborators as required.

Comparison

Size

• Scrum team size: 5-10
• Service team size: 2-8

Composition

• Scrum team composition: Multifunctional, with all roles required to deliver and release a complete "story"
• Service team composition: Programmers. They run the process and pull in other roles as needed. Operations provides tools.

Building the team

• Scrum team: Complicated to build. It often starts with coaches and "culture change." It includes a designated scrum master and product owner. People for all of the different functions (like design, QA, database) need to be pulled out of the functional parts of the organization. Then, the team runs some startup sprints to figure out their velocity and learn to estimate and release together.
• Service team: Build around a Tech lead. Release improvements on day 1.

Self-management

• Scrum team: Teams get product priorities every two weeks, and "self-manage" to plan and control their own two week iterations. Management needs to make sure that change requests go in a list and get prioritized in advance of the sprint planning meeting.
• Service team: Teams see extensive monitoring and feedback on their services. They handle fixes, improvements and requests without going through any management-level planning cycle. They accept new requests as soon as they have time.

SAFe and cadence-based management

SAFe, or Scaled Agile Framework, is a way of organizing Scrum teams to work on large projects. I will use SAFe as an example, because it matches a naive view of how to apply a traditional hierarchical organization to manage agile releases. Other enterprise management frameworks have a similar structure. You can learn more about SAFe from the wonderful diagram at ScaledAgileFramework.com.

SAFe uses the concepts of hierarchy and cadence to bring order out of chaos.

The hierarchy has three levels: portfolio, program, and project.

• At the portfolio level, senior managers decide what programs they want to fund, and what high priority goals they want to ask for. Senior managers in a MAXOS organization will do the same thing.
• Programs can match up with products or lines of business that have a unified deliverable. Programs can include from 5 to 100 projects (Scrum teams), and 50 to 1000 people.
• A project is the container for a Scrum team that can deliver complete features or stories.

SAFe and MAXOS have a similar hierarchy, except that SAFe uses Scrum teams on the bottom level, and MAXOS uses service teams.

SAFe relies heavily on cadence - a shared schedule that synchronizes everyone with a release, and a meeting. Cadence reminds me of the scene in the movie Lord of the Rings, where trolls beat on big drums to keep the orc army marching forward.

• Every ten weeks, all of the programs deliver an integrated system. Then, they have a big meeting where senior management presents the goals for the next iteration, and answers questions.
• Every two weeks, all of the teams in a program deliver a runnable product. Then they meet together, do their sprint planning, and have their "scrum of scrums" meeting where they make sure that other teams are building the things they need.

Naively, this meeting approach seems like a good idea. It guarantees that the organization will have a fully releasable system at least once every ten weeks. It guarantees that senior management gets a chance to communicate coherently at least once every ten weeks, and it motivates people by explaining the big goals. It guarantees that scrum teams will deliver runnable results every two weeks, and coordinate about the things they need from each other.

However, successful tech companies do NOT hold these big meetings. Why not?

• A system that relies on ten week planning and release cycles is too slow.
• Big meetings are difficult to organize, and expensive. Everyone has to come together in one location, or in a small number of locations with videoconferencing. Each meeting requires a day of work from everyone.
• The SAFe hierarchy and the Scrum teams have an intricate structure which takes time and management attention to build and organize. This costs time and money, and makes the organization less responsive.

Comparison

Top level planning

• SAFe: Executives plan at the Portfolio level to fund programs and product teams, not specific deliverables.
• MAXOS: Same

Top level communications

• SAFe: 10 week planning cycles with big meetings and global video connections
• MAXOS: Plan and communicate as needed

Integration cycle

• SAFe: 2 week integration cycles with big program-level meetings
• MAXOS: Continuous integration and release

Dependency management

• SAFe: Scrum of scrums meeting at least every two weeks, and more often if needed
• MAXOS: Continuous integration system continuously finds problems in dependent services and immediately notifies the related service teams to talk to each other.

Team structure

• SAFe: Scrum teams. Hard to build.
• MAXOS: Service teams. Easy to build.

Conclusion

Scrum and SAFe are logical first steps to plan agile releases in a traditional hierarchical organization. However, they are small steps, in a world where competitors make big leaps. Using Scrum and SAFe to compete with a MAXOS organization is not a winning strategy.