7 patterns of Hyper-Productive Teams

7 patterns of Hyper-Productive Teams
Agile - 7 patterns of Hyper-Productive Teams

These patterns come from various studies and research where teams have successfully modelled hyper performance in teams.

We will cover 7 patterns of Hyper-Productive teams, these patterns are:

  1. Stable Teams
  2. Yesterday’s Weather
  3. Swarming: One Piece Continuous Flow
  4. Interrupt Pattern: Illigitimus Non Interruptus
  5. Daily Clean Code
  6. Emergency Procedure 
  7. Scrumming the Scrum
  8. Happiness Metric
  9. Teams that Finish Early Accelerate Faster 

The first two patterns help the team get ready for a successful sprint. Patterns 3-6 help the team deal with the most common disruptive problems in a sprint. Patterns 7-8 will drive a team to the HyperProductive state by causing Pattern 9 to emerge as a side effect.

Stable TeamsKeep teams stable and avoid shuffling people between teams. Stable teams tend to get to know their capacity, which makes it possible for the business to have some predictability. 

The Scrum framework is built around a team of three to nine members. Research at Harvard University and elsewhere has shown that the optimum size is five people. Small teams keep communication paths simple and allow for communication saturation, a key to hyperproductivity. However, just having a small team doesn’t mean it will be successful. If members are pulled off the team to work on other projects or are unable to participate regularly in rituals/ceremonies/events, the team’s Velocity will suffer. To solve this problem, practitioners realised they needed small, stable teams. At PatientKeeper during 2005-2007 all teams were Hyper-Productive except an offshore waterfall team. Careful data collection during this period showed the onshore teams were 10 times as productive as the offshore team. A key feature was the stability of the onshore teams with almost no changes in team members during this period. We did 4723 discover, however, that adding a new person to the team about every 6-12 months helped to bring in fresh ideas.

Yesterday’s WeatherIn most cases, the number of Estimation Points completed in the last Sprint is the most reliable predictor of how many Estimation Points will be completed in the next Sprint.

Yesterday’s Weather allows teams to build a more accurate Sprint Backlog, limiting the possibility of the team ambitiously pulling in too many Estimation Points and endangering the Sprint. Stable Teams know their capacity, which enables them to use Yesterday’s Weather. 

Once stable teams have built a realistic Sprint Backlog using Yesterday’s Weather, they start their Sprint. They then encounter numerous forces that can cause a Sprint to fail. The following four Patterns are designed to address the most common Sprint pitfalls. 

SwarmingFocus maximum team effort on one item in the Sprint Backlog to get it done as soon as possible. Whoever takes this item is Captain of the team. Everyone must help the Captain if they can and no one can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the next priority backlog item is the new Captain. 

When Teams struggle to finish Sprints, it is usually because they have too much work in progress and aren’t swarming on high value Sprint Backlog items. Swarming helps teams move items to “Done” quickly, increasing Velocity. Yesterday’s Weather allows Swarming Teams to increase Velocity because the team is building a realistic Sprint Backlog. The next most common problem Scrum teams face is interrupts to work on the Sprint Backlog. Many requests come to the team which are not on the subset of the Product Backlog accepted into the Sprint. Research at Carnegie Mellon and 20 years of experience with Scrum teams has shown that teams that plan for interruptions do significantly better than teams that do not, even when they experience no interruptions.

Interrupt PatternAllot time for interruptions and do not allow the time to be exceeded. Set up three simple rules that will cause the company to selforganize to avoid disrupting production:

  1. The team creates a buffer for unexpected items based on historical data. For example, 30% of the team's work on the average is caused by unplanned work coming into the sprint unexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the interrupt buffer.
  2. All requests must go through the Product Owner for triage. The Product Owner will give some items low priority if there is no perceived value relative to the business plan. Many other items will be pushed to subsequent Sprints even if they have immediate value. A few items are critical and must be done in the current Sprint, so the Product Owner puts them into the interrupt buffer.
  3. If the buffer starts to overflow, i.e. the Product Owner puts one point more than the 20 points allocated to the buffer into the Sprint, the team must automatically abort, the Sprint must be replanned, and management is notified that delivery dates will slip.

The Interrupt Pattern, like Swarming, allows teams to finish their Sprints because they have developed a process to deal with found work. Examples of how to use these patterns to solve common problems were found in many of the OpenView Venture Partners portfolio companies.

Balihoo, a company that automates local marketing campaigns for companies such as Wendy’s, Ace Hardware, and New Balance, failed to deliver half of its planned stories for 18 two-week sprints in a row. The management was not happy with their Scrum team. 

The first problem addressed was that almost all stories were open on their Scrum Board every day. Excessive “work in progress” delays testing and makes it extremely difficult to get things done in a Sprint. We fixed that by Swarming, which caused the whole team to focus on completing a least one story on the board every day. At the same time we implemented the Interrupt pattern. All of the next 18 Sprints, were successful, none were aborted, and velocity more than tripled. The Interrupt pattern generates a side effect that causes the entire company to self-organize to avoid sprint aborts. This means the buffer is never completely used up and teams tend to finish early and pull forward from the next Sprint’s backlog. This increases yesterday’s weather and the team accelerates.

Finishing at least one story every day allowed the team to focus on the second value in the Agile Manifesto – working software with no bugs. This minimizes the amount of undone work at the end of the sprint and maximizes velocity. All great Scrum teams implement the Daily Clean Code pattern.

Daily Clean CodeFix all bugs in less than a day. Aim to have a completely clean base of code at the end of every day. 

If a Team isn’t creating daily clean code, a lot of time will be wasted going back to fix bugs. Errors can be limited by building quality control into the development process so that issues are discovered and corrected at the point of origin. Research in Silicon Valley at Palm, Inc. in 2006, showed that a bug that is not fixed the same day it is created can take as much as 24 times longer to correct three weeks later.

Despite their best efforts, even a great team may find themselves behind on implementing the Sprint Backlog with no clear way to complete the Sprint successfully. In this case, by mid-Sprint they should execute the Scrum Emergency Procedure.

Emergency ProcedureWhen high on the burndown try a technique used routinely by pilots. When bad things happen, execute the emergency procedure designed specifically for the problem. Do not delay execution while trying to figure out what is wrong or what to do. In a fighter aircraft you could be dead in less time than it takes to figure out what is going on. It is the responsibility of the Scrum Master to make sure the team executes the Scrum Emergency Procedure, preferably by mid-sprint, when things are going off track. 

Emergency Procedure Steps: (do only as much as necessary) 

  1. Change the way the work is done. Do something different.
  2. Get help, usually by offloading backlog to someone else.
  3. Reduce scope
  4. Abort the sprint and replan. Inform management how release dates will be affected.

Scrumming the ScrumIdentify the single most important impediment from the previous Sprint during the Sprint Retrospective and remove it before the end of the next sprint. To remove the top impediment, put it in the Sprint Backlog as a user story with acceptance tests that will determine when it is Done. Then evaluate the state of the story in the Sprint Review like any other story. 

If the team is able to capitalise on Scrumming the Scrum they should create at least one process improvement per sprint. The pattern calls this process improvement the Kaizen. This contributes to increasing Velocity. If the team is using Yesterday’s Weather, then they have a good chance to finish their sprint early because they will have one less impediment dragging down their Velocity. (The Kaizen may not be a direct process improvement. It may deal with strong personalities, management impeding the Sprint, or a variety of sticky human issues. These impediments should be treated like process improvements and should be resolved as quickly as possible.)

Happiness MetricHappiness is one of the best metrics because it is a predictive indicator. When people think about how happy they are they are really projecting out into the future about how they feel. If they feel the company is in trouble or doing the wrong thing, they will be unhappy. Or if there is a major roadblock or frustrating system they have to deal with, they will be unhappy. 

A powerful way to take the pulse of the Team is by finding out how happy they are. The Scrum Master asks just 2 questions:

  • How happy are you with the company?
  • How happy are you with your role?

Team Members are asked to rate their feelings on these questions on a scale from one to five. These numbers are kept in a spreadsheet and tracked over time. If the average changes significantly it’s important to talk and see how Team happiness can be improved. By monitoring the team’s happiness, the Scrum Master can anticipate drops in Velocity and make adjustments.

Teams That Finish Early, Accelerate FasterTeams often take too much work into a Sprint and cannot finish it. Failure prevents the Team from improving. Therefore, take less work into a Sprint (see Yesterday’s Weather for guidance Then implement the four Patterns that reduce Impediments within the Sprint, which will systematically deal with any interruptions and help you finish early. On early completion pull work from the Product Backlog which will increase the baseline of Yesterday’s Weather.