The Scrum process (Sprints in particular) can be thought of as a container surrounding a team. This container has walls and works to seal the team inside the container with the sprint’s goals. Each wall of the container represents fundamental scrum processes that work to keep the onus of sprint success squarely on the team’s shoulders. If any of these walls spring a leak or are breached, the team may wiggle through the leak and blame some outside factor for not meeting sprint goals. The ScrumMaster must therefore work to keep the walls of the container intact and often times save management or the customer from their own undoing.
The scrum container has more than four walls, so the graphic is for illustration purposes only. Each of the illustrated walls deserves specific mention:
- Time-boxing: sprints are time-boxed, without exception. The team has finite time to complete it’s work. If you shorten the time-frame or lengthen it, the team may see it as an external reason for failure.
- Impediment Resolution: The ScrumMaster, management, and customer should do everything possible to resolve the team’s impediments. By ignoring impediments or punting them back to the team to take care of internally, the team may identify the impediment(s) as an external reason for failure.
- Cross-Functionality: provide the team with all of the skills and resources it needs to get the job done. If skills are missing from the team, the team has a legitimate hole in it’s wall through which they can point a finger at the missing or separated external resource.
- Self-Organization: this is a broad, catch-all bullet point, but in general management should let the team work on its own without micro-management or task-level direction. Even those “friendly” suggestions on how to work better by management can be used against management and product owner at the end of the sprint if sprint goals are not met.
- Don’t add “extra work” to a sprint: resist the temptation to dump extra work on the team that must get done on top of the team’s existing sprint goals. The team most likely will not succeed and it will be management’s fault. If there is a crisis that can’t wait, alleviate the team’s existing commitments first.
There are other walls to the scrum container, in fact all of the walls described in the scrum books must be maintained as sacred. I often see management ignoring certain scrum walls saying that they don’t really like those particular rules and then wonder why things aren’t working. Any breach in any scrum wall is wide enough for teams to wiggle through and point the finger at someone else.