ABSTRACT
Wolving ◾ : This is what happens when one or more people on a Scrum team are taken away from the team during the sprint to work on something more that is considered to be an emergency or simply more important. Usually when this happens, it involves one or more people that the team cannot spare to lose. Everyone else on the Scrum team is upset when the makeup of the team is changed during the sprint. The team may lose a day or even find they are unable to complete the sprint. No matter what the impact, it is extremely
difficult for the team to do as good a job with one or more missing team members as they could have done with them. Certainly, it is possible that the team may complete most or all of their sprint goals, but remember that they met their commitments while short-staffed. Be prepared for issues (e.g., defects) that may plague the team for the next couple months, if not longer. Just as likely, be prepared for the team to go to the product owner and renegotiate their backlog commitment. Remember, the team made a commitment to the product owner of a certain amount of work during sprint planning. That commitment was based on each team member’s known availability. When that changed, so did their commitment. Resource slicing ◾ : Managers often seem to blur the distinction between the positions that we have in our organization and the people that fill those positions. On paper, you can easily allocate the time that a position is supposed to spend on one or more projects, and the numbers always add up to 100% (e.g., 50% on project 1 and 50% on project 2 = 100%). However, when you ask a developer to work on multiple projects at the same time, that developer incurs delays caused by:
Saving what he or she was working on, physically and mentally − Clearing his or her space to allow for something else − Checking emails and having conversations (as long as he or she is between − tasks, why not?) Frustration caused by having to switch from task to task − Remembering where he or she was on the other project − Realizing he or she forgot some details about where he or she was on the − other project and having to re-create the work/intelligence
There have been many studies that conclusively show that context switching is very expensive. In fact, in Gerald Weinberg’s book Quality Software Management: Systems Thinking,1 he proposes a rule of thumb based on past experiences: when you add a second project to your developer’s plate, he or she loses 20% of his or her productivity. With the third project, add another 20%. Teams not accountable for results ◾ : The Scrum framework creates a clear delineation between responsibilities in the building of a product. Whereas the product owner takes responsibility for building the right product, the Scrum teams take responsibility for building the product right. Scrum teams are accountable for following the Scrum framework, the team’s and the organization’s accepted development practices, and abiding by the team’s and the organization’s definition of DONEness. When a Scrum team makes a commitment to their product owner at sprint planning, the team does everything reasonable to achieve their goals or to alert the product owner immediately if any portion of their sprint goal is in danger of not being properly completed by the end of the sprint, or if any portion of the sprint goal suddenly becomes considerably more expensive than was originally anticipated.
