Finish Early, Accelerate Faster

Stable Teams: Keep teams stable and avoid shuffling people between teams. Stable teams tend to get to know their capacity, which makes it possible for the business have some predictability.
The Scrum framework is built around a Team of three to nine members. Small Teams keep communication paths simple and allow for communication saturation. However, just having a small Team doesn’t mean it will be successful. If members are often pulled off the team to work on other projects or are unable to participate regularly in rituals, the team’s Velocity will suffer. Practitioners realized they not only needed small teams but stable teams.

 

El tiempo ayer: In 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 Log 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 Log using Yesterday’s Weather, they start their Sprint. There are numerous forces that can cause a Sprint to fail. The following four Patterns are designed to address the most common Sprint pitfalls.

 

Enjambre: Focuses 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 Process and aren’t focusing on getting the highest business value Product Backlog Item finished. 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 Log.

Patrón de interrupción: Allot time for interruptions and do not allow the time to be exceeded. Set up three simple rules that will cause the company to self-organize 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 20 points into the Sprint, the team must 
automatically abort, the Sprint must be re-planned, 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.

Daily Clean Code: Fix 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 can 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 isn’t fixed the day it’s created can take as much as 24 times longer to correct three weeks later.

By creating clean code daily, the Team will limit interruptions later in the Sprint or in the next Sprint when the error is harder to correct. The idea is that once an error has been caught, analyzed and corrected, it should never happen again. By eliminating errors and improving the process on a daily basis, teams can continuously improve, increasing quality with corresponding Velocity.

Procedimiento de emergencia: When 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 immediately 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

5 Inform management how release dates will be affected

Stable Teams using Yesterday’s Weather set the Team up for success by helping it get in a ready state. Swarming, the Interrupt Pattern, Daily Clean Code and Stop the Line help the Team deal with Impediments as the arise during the Sprint. The last three Patterns take advantage of those previous Patterns and allow the team to attain a Hyper-Productive state.

Scrumming el Scrum: Identify the single most important impediment in 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 task.

If the team is able to capitalize on Scrumming the Scrum they should create at least one process improvement per sprint. This contributes to increasing Velocity 10% every Sprint. If the team is using Yesterday’s Weather, than they have a good chance to finish their sprint early because they will have one less impediment dragging down their Velocity.

Métrica de la felicidad: Happiness 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 weeks. Whenever the average changes significantly it’s important to talk about it and see how a Team can be made happier. By monitoring the team’s happiness, the Scrum Master can anticipate drops in Velocity and make adjustments.

Teams That Finish Early, Accelerate Faster: Teams 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. Maximize your probability of success by using the pattern Yesterday’s Weather. 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 forward from the next Product backlog, which will raise Yesterday’s Weather for future sprints. To increase the probability of acceleration, apply Scrumming the Scrum to identify your kaizen in the retrospective. Put the kaizen in the sprint backlog with acceptance tests for the next sprint as top priority.
 By using the underlying patterns of FEAF, stable Teams build a realistic Sprint Log and then Swarm.

Mitigating interruptions and handling unforeseen circumstances help teams finish early. When the team finishes early, they can then pull more items from the Product Backlog. When they do this, Velocity increases raising the baseline for Yesterday's Weather. As a result, the Team will pull in more points for the following Sprint, accelerating. If Teams are able to execute these patterns consistently, over time, the Team will reach a Hyper-Productive state.