Scrum 101: Using Scrum outside of software development

Scrum is a working method designed for software development. The Scrum Alliance published a quick but comprehensive summary of what Scrum is, and what its goals are, and that page includes this very condensed outline:

The Scrum framework in 30 seconds

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.
  • At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review and retrospective.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

When I got my Scrum Master training, I was the only person in the room who wasn’t working in software development. That meant that I couldn’t use Scrum exactly as it’s intended to be used: It’s not designed for projects that have lead-times. Software doesn’t really have waiting periods, where you’re waiting for a manufacturer to make a tool for a part, or where you’re waiting on 12 weeks of cycle testing, for instance.

When you’re working in hard goods, you aren’t talking about a potentially shippable product at the end of a sprint, but you are still talking about the work being ready to show to a stakeholder. But once you wrap your head around how you need to scope out the work and break up the tasks, it’s a really useful framework. What you wind up doing is breaking up tasks into smaller pieces that are less time-dependent. For instance, the task isn’t “make parts” — it winds up being several smaller tasks, that can be divvied up into various sprints (“finalize tool design” and “submit purchase order for tool” and “complete first article inspection on parts made with new tool,” for instance).

We used the Scrum framework to organize the development and manufacturing teams’ work to build out and stand up a manufacturing plant. The development team had been using the scrum framework for about a year by that point. I was the team’s Scrum Master. (I wrote a bit about my thinking on the Scrum Master role as a Facilitator role.) During the knowledge transfer process, when the development team and manufacturing team were working very intensively together, the manufacturing team switched to using Scrum as well. One of the engineers got Scrum Master training as well, and I showed the manufacturing team how the development team had been using this slightly-modified version of Scrum. Here’s the quick presentation I made for introducing the method to the whole team:

I did some training with the manufacturing team to help them get up to speed (how to estimate effort for chunks of work, how to get unit-of-measure-loving engineers comfortable with the idea of completely subjective point values for effort, how to build a backlog spreadsheet with a burndown chart — straightforward stuff, but practical examples based on how the company was already using these tools).

Working as two aligned scrum teams had two really valuable impacts. One was that it became much easier to schedule work that involved both teams, because there was a lot more visibility into work scope and schedule. The other was that folks were able to support each other: folks regularly attended the other team’s sprint reviews to see the presented completed work, and celebrate each other’s accomplishments.

Multi-tasking and empathy

It’s not a new concept that multi-tasking is really just task-switching, and that it’s incredibly inefficient (we lose time switching between tasks as our brains catch up to the task at hand …every single time we switch back and forth.). There is no such thing as “being a good multi-tasker.”

Scrum trainer Roger Brown illustrates the inefficiencies of task switching in this 2010 piece, in the context of explaining how using the scrum framework can save organizations time and money.

If everyone on the team is working on three projects concurrently, all three projects will finish at the same time:

But if everyone on the team focuses on one project at a time, the first project finishes at week 7 instead of week 20 in this example, where we haven’t begun to account for “team synergies” as Brown puts it:

And it’s not news, either, that working closely with a team comprised of individuals from across multiple disciplines can increase ability to problem-solve and offer multiple perspectives.

Here’s the pretty remarkable new information: there’s a study linking multitasking with a decrease in empathy. This FastCompany piece — a larger discussion of the costs of multi-tasking — references a study that links multi-tasking with a decrease in density in the areas of the brain controlling emotions and empathy. Correlation is not causation, but it still gives me pause, and at the same time, seems really obvious: when we’re multi-tasking, we’re not fully present. We haven’t committed to the task at hand, whether it’s a solo task or a conversation with a human. We aren’t getting any better at empathy if we’re not practicing it, and we’re not practicing it if we’re not really here.

Scrum Master as Facilitator

Facilitation is rarely discussed outside the context of having meetings, but there are a lot of kinds of facilitation. Teaching is facilitating learning. Project management is facilitating work.

I’m a trained Scrum Master, which is another name for a facilitator within the Agile working framework of Scrum. (Scrum 101: scrum teams work together in a defined span of time called a sprint to complete a discrete and deliverable part of a bigger project. Then they review their working methods in an event called a Retrospective, adjust their process, and then in their next Sprint Planning meeting, they break off another chunk of work to be completed in the next sprint. The fundamental difference between traditional project management and the Agile/Scrum framework is the frequency of review and iteration on smaller, discrete portions of a project vs a focus on delivering an entire complete project all at once).

Scrum Master is an interesting role, rooted in removing obstacles from the working team, but also working to provide a supportive environment in which the team can work.  One of my favorite scrum tools is the daily standup, a meeting not owned by any one person but by the team, in which everybody is asked three questions:

  • What did you do since we last met?
  • What will you do before we meet next?
  • What roadblocks are in your way?

In a true scrum setup, the Scrum Master is the sweeper: removing the roadblocks and making the path smooth!
But that framework is really useful in non-scrum settings, too. I’ve adopted it for use in most projects I’ve worked on, regardless of team type. It makes the most basic and useful meeting agenda format there ever was!

The part of the sprint where the team pauses and reflects is my favorite part of scrum, because the best work happens when you look at your own process and methods. What disrupts your ability to get work done? What disrupts the team’s trust in each other? It’s so important to stop and look honestly and openly at how the team is working together. It requires the team to be vulnerable with each other, to be able to receive and give criticism in a safe and productive way, and to think honestly about how the team is working.

A retrospective will not be productive if you haven’t made  space for people to be vulnerable, and there are a lot of tools and techniques you can use to help create that environment. Here’s an example of a retrospective agenda I’ve used:

  1. Reminder of the goals/objectives of the retrospective
    All team members reflect on the past sprint and make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
  2. Check-in
    “How did the sprint go for you?” in only two words. Each person writes their two words on the board.
  3. Happiness Histogram (see below for examples)
    a) Review the burndown chart and sprint calendar to remember what happened during the sprint.
    b) Draw a graph with time on the x and happiness on the y axis, (Happy is above the axis, Sad is below, and neutral is the X axis). Label significant events e.g. planning, sprint review, and backlog reviews, important meetings, environment failures, branch merges etc. on the x axis.
    c) Everyone draws a line representing how they felt throughout the sprint.
  4. Gather data and generate insight
    Prepare sheets of paper for each team member each with one question:
    In this sprint, what things happened that were unusual?
    In this sprint, what things did we do well?
    In this sprint, what did we do that we should avoid doing in the future?
    Distribute the sheets. Each person writes something, then passes the sheet to their left, then writes something on the next sheet, in response to what has previously been written. Give 3-5 minutes for each round, then instruct the team to pass the paper to their left. Stop when participants have the sheet they started with.
  5. Decide what to do
    Ask people to read their sheets and write the main points on post-its, on the board. Ask people to read the post-its aloud. Distribute 5 dots per person. Each person votes by post-it (however they like). The goal is to select one or two things to actively work on in the next sprint.
  6. Close out (Return On Time Invested)
    (See Facilitation 105 for more info on how to use the ROTI tool.)

I love happiness charts. When we use these, we decide up front that we’ll use them, so we can define our rating system (-3 to 3, for instance, where 0 is neutral) and set up a table to track ratings. Every day during our morning standup meeting, each person gives a number ranking to how they felt about the previous day, the scrum master writes it down, and we map it out as we go (in a spreadsheet, or on a whiteboard, or on paper).

Here are some examples. You can see really readily when the team is in total alignment. Note the huge tank from everyone on the team at the same time, early in the sprint here: IMG_20130403_102712_958.jpg

It also reveals when the team is way out of alignment. Look how everybody’s lines are all over the place in this sprint:


The real value of happiness charts though, is going back through and identifying WHY folks felt great or terrible. Folks often feel more at ease talking about emotion when it’s rooted in “data” (as much as a gut-take feeling on a made-up scale is data) so it can be a lot easier to identify from a graph, rather than from conversation alone,  what the team is struggling with, and thus what you as the facilitator or scrum master may need to focus on. And it also provides a framework for people to point jubilantly at a peak and say what happened that made things go well. I’ve gotten to hear some really lovely and supportive commentary from the team about each other. In one of my favorite retrospectives, we learned that the highest points on the happiness chart were when the team was really struggling, but felt supported by each other and able to work through the struggle.