11 Ways to Double Team Velocity

Ever wonder how Jeff Sutherland trains high-performing teams?

Jeff Sutherland, one of the co-creators of Scrum, is full of great insights. Many people don't know that not only is he one of the inventors of Scrum software development, but Jeff also has a PhD in Biometrics and a Masters in Statistics. He spent the early part of his career creating complex statistical models on cancer research, still used today by the medical community.

So when Dr. Jeff Sutherland talks about ways to double your velocity... he's got the data to prove it! Below are 11 patterns that I learned from Jeff to double your team's velocity:

1. Stabilize Teams

"Talent wins games, but teamwork and intelligence wins championships." -Michael Jordan

There are a lot of references and patterns on how to build great teams. One common thread that we've discovered remains true... stable teams are more productive teams. Why?

Predictability: Jeff Sutherland says, "Keep teams stable and avoid shuffling people around between teams. Stable teams tend to get to know their capacity, which makes it possible for the business to have some predictability." In addition, Jeff recommends teams should be "dedicated to a single team, whenever possible."

Teaming Sunk Cost: Bruce Tuckman, creator of the Tuckman Model, describes the team life-cycle as "Forming, Storming, Norming, Performing." He says these are the phases teams experience in order to grow, confront challenges, tackle problems, find solutions, plan work, and deliver results. For every new team, there is a considerable investment of time and emotion to achieve the "performing" phase. The idea of a stable team is NOT to continue to restart this process over and over. Rather, keep the team together and build onto the existing relationship to perform even better over time.

Team Mindset: Teams that are together for a longer duration learn together faster. This is the result of the kinsman-ship of trust and understanding that is created. When trust exists on a team, the speed of learning accelerates.

Google studied this and the #1 factor in creating "high-performing teams" is having psychological safety on the team. Stability helps get you there!

Chris Fry, Head of Engineering at Medium and former Salesforce and Twitter executive, said in an interview in The Review, "As a manager, your focus should really be creating these high-performing squads of people who have good chemistry, who can get things done. Then you figure out how to apply them to problems."

2. Stick to the Daily Scrum

Maximize performance by calibrating daily.

Some teams try to do Scrum without effectively leveraging the Daily Scrum pattern articulated in the Scrum Guide. Per the Scrum Guide, "The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity." Jeff's video further explains the expectations of the Daily Scrum.

The intention of the Daily Standup is to ensure that the team is coordinated and that anything distracting the team from accomplishing their goal is addressed. That's why the key questions that each team member should answer:

• What I did yesterday towards accomplishing helping the Development team reach the Sprint Goal
• What I intend to do today to help the team accomplish the Sprint Goal
• What, if anything, is slowing us down or risking our ability to accomplish the Sprint Goal

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting. So keep your team flowing by inspecting and adapting continuously!

2. Scrumming the Scrum

Scrumming the Scrum is a pattern based on "kaizen" (カイゼン), the Japanese business philosophy of continuous improvement and removing waste. This is an essential Agile pattern as we need to continuously improve how we are getting through "Scrum" itself. That is, look at how we are operating and seek to make it better.

Therefore, to Scrum the Scrum, teams should take at least one impediment from the Sprint Retrospective and remove it before the end of the Sprint. In the Scrum Guide 2017, Jeff Sutherland and Ken Schwaber go so far as to have this impediment added to the Sprint Backlog so that it gets resolved along with other backlog items.

3. Clear Sprint Goal and "Ready State"

"Ready are you? What know you of ready?" -Yoda

Great performance first needs great preparation. Therefore, teams should invest in being "ready" before they start their work. In Agile, this is demonstrated through the Sprint Goal and the Product Backlog.

The Sprint Goal, set by the Scrum Team, is the team's objective that it plans to meet within the Sprint it provides guidance to the Development Team on why it is building the Increment. It gives the team clarity on what the team is intending to accomplish and establishes shared alignment within the team. If the goal is clear, the team will be hyper-focused on working to achieve it.

A "ready" backlog means that your Product Backlog Items are ready to be worked on by the Development team. If work items are not precisely understood, development effort tends to expand exponentially, which causes the Sprint to not reach the Sprint Goal or to not deliver the expected outcome.

Each Product Backlog Item must meet at least the following criteria before it can be considered a candidate for a Sprint during Sprint Planning:

• The work is immediately actionable by the team
• The result to be delivered has value
• It has to have been discussed between the Product Owner and the Developers
• It has been estimated
• It is testable, and the Product Owner has defined tests for it
• The pieces are sized appropriately

A Product Backlog is “ready” if it has enough Product Backlog Items that both meet this criteria and to can sufficiently fill a Sprint. Jeff Sutherland has a great video that speaks to how you should consider your backlog on being "ready".

4. Swarming

Swarming is the practice of getting several, if not all, of your team members to focus one a single item. Its a practice where team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items.

Swarming enables teams to get the maximum leverage of team knowledge to amp up its total team capability. Compared to working as individuals, swarming enables a team to leverage the wisdom across a vast experiences to solve complex problems more efficiently and effectively.

A technology practice made popular by Woody Zuill has teams coding together as a one large group so that the entire time can align to what is being created and so that quality and clarity is maximized as the team codes as one "hive" on each line of code.

5. Small Teams and T-Shaped People

"There is nothing wrong with being small. You can do big things being a small team." -Jason Fried, author of Rework and founder of Basecamp

The US Navy SEALs. Firefighters. Basketball teams. Toyota Car Production teams. What do these teams have in common? The teams are small (5 or less). It turns out that studies have shown that small teams are more effective than larger teams. Jeff Bezos calls this the "two pizza" rule. That is, effectiveness increases where people work in groups where the number of people can be fed with two pizzas or less.

Communication: The more communication paths between people, the more complicated the communications. For a team of 4 people, there are 6 paths. For a team of 5 people, there are 10 paths. And for a team of 10 people, the communication paths spikes to 45. The lower the number, the faster the collaboration and the simpler the alignment. Therefore, smaller teams build faster communication as well as faster paths to create long-term team trust.

Accountability: Small teams also increases accountability. The clarity of work accountability become more obvious and issues are likely to surface more quickly. And inversely, it prevents "social loafing" or abilities to hide. According to Gallup, only 33% of employees are feel like they are engaged in their work. Small teams enables engagement to be higher.

T-Shaped People: T-Shaped people is the concept that team members could have depth in one or more areas of skills and capabilities. The T-shaped person also has broader skills and knowledge and learns by linking up different perspectives from different specialties. In start-ups, we seek full-stack developers for this very reason. We want people who can work on multiple development areas and not limited to one specialty.

Diverse Team Membership: To amp up the idea of small teams and T-shaped people, it's essential to have women on your team. It turns out that women on a team increases the overall "collective intelligence" of a group as reported by researchers from MIT, Carnegie Melon, and Union College. Teams with all men, even with very high IQ's, have a lower total IQ when working together. Called the "c-factor", teams can boost its overall intelligence where there are higher levels of social sensitivity of group members, the equality in distribution of conversational turn-taking, and the proportion of females in the group.

6. Fix Defects within a Day (Daily Clean Code)

Don't delay... fix those bugs as soon as they are discovered.

When teams discover a bug in the work that they've completed, the bugs are to be fixed immediately. Your teams must be testing continuously ensuring that it leaves the end product in a "production ready" state. This means that your teams must create work product that should be ready at a quality level that is ready for the customer (it does not need to be actually released to the customer). This is a pattern that should exist as part of the teams' "Definition of Done".

When bugs are left to be fixed later, this compounds the cost of fixing the bug. Even if the bug is fixed within the sprint, it still is more costly to fix days after the bug is discovered. That's why bugs that make it to production become part of the product's "technical debt". And fixing bugs later is exponentially more expensive to the organization. Even more impactful, unresolved bugs will impact customer value at some point.

7. No telling people what to do - self organize!

Agile itself is driven by certain parameters such as prioritized backlogs and limiting work-in-progress. Due to the framework itself, having the team self-organize around the work helps the team become hyper-productive. The best teams in the world, whether its the Navy Seals or a World Cup team, self-organize to achieve their team goal.

• observing and asking questions;
• facilitating;
• teaching;
• intervening and most importantly,
• actively doing nothing.

“Doing nothing” may be the most important activity because every time the ScrumMaster ‘solves’ a problem or makes a decision for the team, an opportunity for team growth is lost.

8. The A3 Process

The A3 is a process to methodically problem solve and continuously improve a system. It was first created by Toyota and is called an "A3" due to that the results should fit on an A3-sized sheet of paper.

The A3 has 7 sections Based on W. Edward Deming's Plan, Do, Check, Act process. The first 4 sections align with "Plan" and helps the writer clarify the problem, define the goal, and articulate the root case. The next section provides an outline to create countermeasures ("Do"). These are experiments that can be done to help remedy the problem. Once the experiments are identified, the writer can start the sixth section, Confirmation, where results are tracked ("Check"). Like a well-formed experiment, this is a good place to connect each countermeasure with a hypothesis and metric BEFORE the experiment is started. After completion of the experiment, its a good practice to track actual results in this section too. Finally, the seventh section represent the actions to take ("Act"). It's a section where the writer can articulate the adjustments based on the results of the A3.

You can see that the A3 emphasizes the concept of Inspect and Adapt in a structured pattern. This allows for continuous improvements to be better understood and the value of improvements to have greater visibility.

9. Interrupt Buffer

Scrum teams can be interrupted or disrupted during a sprint. In the real world, it's inevitable. Unlike building widgets, cars, or other fixed repetitive work, Scrum teams can presented with dynamic challenges of new discoveries. The Interrupt Buffer creates two major opportunities: Adjust to Overflow and Finishing Early.

Adjust to Overflow

These teams work on projects that are "complex". This is when the understanding of a solution is unclear (what to solve) and/or the implementation of the solution (how to solve) is less known.

Don Reinertsen calls this the principle of variability. Variability is the concept that complex work has many unknowns. And its important to exploit variability where we acknowledge that we need to accommodate for unknowns when we are planning.

Jeff Sutherland recommends that to plan for variability, we should include a "buffer" in our Sprint Plans to allow for our teams to be interrupted. Additionally, do not allow the time to be exceeded (time box it!).

If you work in a complex work environment, add an interrupt buffer to respond to the condition of variability in your work. And be sure that buffer is balanced between work needed to be done and ensuring customer value is reached.

• Team creates the buffer percentage to be allocated for unplanned work.
• All requests are channeled to Product Owner for triage, clarification, prioritization, and ordering.
• If the Product Owner adds more to the sprint than what was allowed for in the team's buffer, the sprint is aborted and the team re-plans the sprint.

Finish Early

"Teams that finish early accelerate faster" is what Jeff Sutherland says. Now this was a mind bender. If teams that finish early go faster - how and why? And how does this even make sense?

Teams often try to work on too many things simultaneously. The result is that work may not get completed at the end of the sprint due to any number of reasons. So if a team takes on work that is intended to be completed before the end of the sprint, it gives them more time to adjust to unknown variables while still completing the sprint.

Teams that take on too much work or underestimate their work fail their sprints as the work items are still "in-progress". When the bottleneck gets built up, the flow slows down. So instead of trying to complete more by starting more, look to reduce your workload to what can be finished before the sprint is done.

The excitement of getting a "successful" sprint and the avoidance of having incomplete work as an overhead will give the team lift. It's about momentum.

10. Plan Based on Yesterday's Weather

The trend is your friend.

I worked for an Wallstreet investment banker who once told me, "the trend is your friend". Catchy right? Scrum planning is no different!

Managers want the work done but if your teams' delivery is not predictable, that makes projects frustrating. Your teams may be wanting to fill a sprint beyond their capacity for a variety of reasons. Maybe this is to meet a milestone or to accommodate a customer request. Or maybe a manager is pressing for more work volume. Whatever the case, help the teams plan based on what they typically complete based on the previous sprints. By using this simple rule, you can help teams become more predictable.

For planning, use "yesterday's weather" as a foundation for estimating the work that can be completed. And it's helpful work with the team to identify a "predictable" outcome by leveraging other metrics like the "Say vs. Do" ratio. The Say vs. Do ratio helps you get a percentage of what was done compared to way was estimated. While your goal is 1:1 (or 100%), its often a telling story if the team under-achieves or over-acheives this ratio. Moreover, this number, along with the velocity, can help balance how much additional work the team can do if they choose to take on more work.

Bottomline, keep your teams pragmatic about their estimates based on real data from earlier sprints.

11. Have Co-Located Teams

What challenges can you imagine in working with teams that aren't physically located together? Communication, culture, time zones/ working hours, time delays, view of a common physical Scrum board, impromptu meetings, language, alignment... and these are only start!

Having teams that are co-located works better overall. But it is possible to have team members located in different locations and still operate effectively. There is, however, an efficiency and effectiveness "tax" that distributed teams pay to ensure that teams perform optimally. This can be measured with the currency being "customer value created per story". The impact of the tax directly affects how well your team responds to low-fidelity ways-of-working (high-fidelity occurs when face-to-face).

When making your decision on co-located teams vs. distributed teams, have leadership decide how the impact of the "distributed team tax" impacts your efficiency and effectiveness. This makes for an economic-based decision.

Stacey Louie (CSP, CSM, CSPO, SPC4), CEO of Hyperdrive Agile Leadership

Stacey Louie is the CEO of Hyperdrive Agile Leadership and has been coaching companies including PayPal, Cisco, HP, Prudential Financial, StubHub and Nike through Agile Transformations. He has been a CIO/CTO and has launched startup companies. Stacey also founded AgileCamp and leads the Silicon Valley Agile Leadership Network.

Feel free to contact Stacey at [email protected]