The Scrum Container

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

The scrum container has more than four walls, so the graphic is for illustration purposes only. Each of the illustrated walls deserves specific mention:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Victor Szalvay

Victor Szalvay currently leads product development for CollabNet’s ScrumWorks® product suite. In that capacity, he works closely with customers, stakeholders, and the development teams to deliver high business value each release cycle. With more than 150,000 active users worldwide, ScrumWorks is used by more than half of the Fortune 100 and boasts the largest market share of any Agile management tool.

Posted in Agile
2 comments on “The Scrum Container
  1. Boris Gloger says:

    Hi Victor,
    I really like your picture or the Scrum Box, what I do not like is the idea of having a team that needs to be threated in the way that a X has to prevent that the team will find wholes in this wall.
    Maybe I am to naive — but my personal experience is that team are not able to perform because the management does stupid things. And this rule is valid always.
    Boris

  2. Victor Szalvay says:

    Hi Boris,
    Thanks for the comment! I agree with you, usually it is management’s doing that creates the holes in the container. For example, adding new work to an ongoing sprint, not providing enough technical mentoring, not creating truly cross-functional teams, not allowing self-organization to take root. These are all things management does to itself on a project.
    I’ve just found this box/container analogy useful for explaining to management why these actions that management sometimes takes work to destroy the process. I guess it’s cruel to think of a team in a box, but in my experience some teams need the scrum process rigidly enforced to keep things visible (unfortunately).

Leave a Reply

Your email address will not be published. Required fields are marked *

*