A Week in the Life of a Scrum Team

A Workshop Facilitation Guide

The purposes of this activity are twofold:

• To illustrate a few of the many real challenges that Scrum Masters face;
• And to help people understand how the Manifesto for Agile Software Development can inform solutions to those common business problems.

This is done by presenting participants with problem-circumstances for which they discuss possible solutions and consider the potential results of those solutions.

Required Materials

• 4 to 10 Note cards & 1 marker
• 4 to 10 Pencils or pens
• 4 to 10 Sheets of paper

Instructions

1. Divide the whole group of participants into between 4 and 10 sub-groups. The best outcomes have occurred with 4 or 5 groups of 4 or 5 people.

2. Explain to the room the following:

   "15 minutes from now, we're going to hear a story of a Scrum Team and the problems they encounter throughout a Sprint. I will provide each group with a problem to solve. Your task will be, within your group, to:

   • consider the problem and its potential impact on the Scrum Team
   • refer to the Manifesto for Agile Software Development and discuss which values and principles may inform a solution to the problem
   • then write a brief story, a paragraph or two, about what the team decides to do about it. This snippet will be like a single chapter of the larger story. You'll have 7 minutes for this. At that time, we'll all hear each group share their problem and how their Scrum Team will respond to address that problem.

3. Then Provide each group with a note card, on which is written a scenario, a problem, for their consideration. The following are recommended as a minimum:

   On this day: Sprint Planning

   A team member is missing, at home sick.

   On this day: Sprint Review

   A key stakeholder can't attend.

   On this day: Mid-Sprint

   Another team, working on the same product, have just made a change which causes us unforeseen rework.

   On this day: Mid-Sprint

   Team is waiting on approval of a document from the legal department.

   On this day: Retrospective

   An Ops manager shows up and wants to participate.

   On this day: Retrospective

   A few team members get into a heated discussion about a defect – and they debate about which tool led to the problem.

4. If more than 4 groups, then other scenarios can be added. Consider the following or improvise:

   On this day: Mid-Sprint

   Team is told that an architectural decision made in their previous Sprint doesn't "comply" with company standard.

   On this day: Mid-Sprint

   2 team members are late for the Daily Scrum (it's not the 1st time).

   On this day: Mid-Sprint

   Product Owner asks the team to add an "important" Product Backlog item to the Sprint.

   On this day: Mid-Sprint

   a team member points out that the Burndown Chart has flat-lined for a 3rd day in a row.

   On this day: Mid-Sprint

   a team member worked all weekend (alone) on a feature which was started by a pair.

5. Set a timer for 7 minutes and encourage the groups to start discussing/writing. The goal is to have something written that can can be shared with the room. That reminder will help them focus on writing. (Some groups tend to talk about the problem for 5-6 minutes before any writing occurs. This is not a problem for most groups but they are likely to improvise portions of the story while sharing with the whole room. Among groups who begin writing sooner, the results are often a more concise story.)

6. After 15-minutes, ask the groups to share their stories out loud. The sequence is important:

7. Start with the group that had "Sprint Planning"

8. Follow with any groups that have "Mid-Sprint"

9. End with the two groups that have "Sprint Review" and "Retrospective"

10. Between each group, or after all have read out loud, host brief QnA so that other groups can inquire about detail or discuss possible outcomes/consequences.

Impressions

Experience shows that groups will often tell stories of their current workplace, not of Scrum workplaces. For example, all groups (so far) who have written about the problem, "team is waiting on a document from the legal department" choose some combination of the following:

• Mark the item as "blocked"
• Pick up another item from the Sprint Backlog
• Some groups say "tell the Product Owner"
• Have the Scrum Master coordinate approval of the the document (as though a Scrum Master is like a Project Manager)

This activity presents opportunities then to offer alternative ways to address the problem circumstance. Such as:

• Inform all stakeholders that all work of the team is paused until legal department responds
• Immediately make a request of the appropriate authorities that a representative from the "legal department" be made available to the team for the remainder of their Sprint
• Or various other strategies to dissolve the impediment

How to Use

1. Download the materials above.
2. Conduct the workshop with your own teams & stakeholders.
3. Tell me how it goes via Twitter or LinkedIn.
4. Ask questions or suggest changes. Scroll to bottom of this page to leave a comment or question.

Purpose & Summary

• Reframe our understanding of documentation with respect to knowledge work in complex environments. (Documents are not truth. They are snapshots of current understanding. If not treated carefully, they create fiction not transparency.)

• Reframe our understanding of 'implementation' — when does it occur in product development? (Hints: it isn't a phase or project milestone; it is every moment in which a decision is codified in the product.)

• Compare the purpose of artifacts/documents produce pre and post implementation. (Documents pre-implementation do not represent decisions; they represent, at best, incomplete information. Documents create at or after the point of implementation are obsolete the moment they are produced.)

• Appraise commonly-used documents with respect to customer-value — in contrast to perceived business/process 'importance'. (Documents are often produced because someone demanded they be done; but many documents are not the artifacts that any customer is willing to pay for. How might we focus on documentation which has actual value?)

• Consider and describe ways each artifact may be eliminated or simplified. (Like eliminating a Business Requirements Document in favour of a flexible/dynamic Product Backlog, how might an Agile team simplify the design and production of necessary artifacts/documents?)

Learning Objectives

Attendees will:

• Reframe their understanding of documentation with respect to knowledge work in complex environments. (Documents are not truth. They are snapshots of current understanding. If not treated carefully, they create fiction not transparency.)

• Reframe their understanding of 'implementation' — when does it occur in product development? (Hints: it isn't a phase or project milestone; it is every moment in which a decision is codified in the product.)

• Compare the purpose of artifacts/documents produce pre and post implementation. (Documents pre-implementation do not represent decisions; they represent, at best, incomplete information. Documents create at or after the point of implementation are obsolete the moment they are produced.)

• Appraise commonly-used documents with respect to customer-value -- in contrast to perceived business/process 'importance'. (Documents are often produced because someone demanded they be done; but many documents are not the artifacts that any customer is willing to pay for. How might we focus on documentation which has actual value?)

• Consider and describe ways each artifact may be eliminated or simplified. (Like eliminating a Business Requirements Document in favour of a flexible/dynamic Product Backlog, how might an Agile team simplify the design and production of necessary artifacts/documents.)

Session Timebox

Recommended: 60 minutes