Five-Day Sprint Process meets Raleigh Innovators Program – Part 4 of 5

A 5-day sprint in 45 minutes

Yes, that’s ridiculous.  The concept of a five-day sprint is crazy enough, but to attempt it in 45 minutes is just plain nuts.

In this series, I wrote about what it was like to participate in the five-day process.  After further study, I seized the opportunity to evangelize it to the technical communication community outside of Red Hat.

In October, I led a workshop during SpeedCon, an unconference hosted by some of our summer MSTC interns from NC State.  During my workshop, I attempted to:

  • Give an overview of the Google Ventures 5 day sprint process
  • Articulate its differences from traditional sprints
  • Present a hypothetical project scenario
  • Lead attendees through scenario-based group and individual sprint activities

After introducing this sprint process, I gave a background slide so our workshop could hit the most engaging, mid-sprint activities.

The Scenario

Pretend meetings at your company are a miserable experience. Everyone dreads them.  People arrive late and unprepared, talk over each other, don’t accomplish the task at hand, overuse jargon, constantly complains, etc. Your team has been told to create a mobile app to make meetings better by collecting meeting feedback.  At this point, you and your project team theoretically set a high-level goal, made a process map, interviewed an expert, and took How Might We notes (risks positively phrased starting with “How might we…?”).  Gather around your table and review the preprinted How Might We cards.

The Exercises

(See Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days for more details.)

  • Group the How Might We cards according to trending ideas (5 min/team).  Put an index card with a label atop each section.
  • Silently vote on the How Might We cards (5 min./alone).  Each person gets three sticker votes.
  • Choose a user persona and a highly voted How Might We card (1 min/alone).
  • Sketch a possible solution (8 min/alone).  This could be a process, an interface, an experience, anything.
  • Circle one powerful part of your sketch (1 min/alone).  It could be anything that really gets your attention.
  • Draw 8 rapid variations of that idea (8 min/alone). Crazy 8s!

What I Would Change

Because the activities were the best way to see the value of this sprint style, I hurried through my explanation of the actual process.  I’m not sure how great an appreciation the audience could get in that hurried review, but they can only appreciate the process via participation.  I do think that the exercises were a great initiation to how this specific process drives teams through rapid decisions and creative thinking.  One person commented that she liked the balance of group and individual activities, unlike her current, a pure group led sprint work.

Lessons learned:

  1. This should really be a two-hour workshop.  Doing a weeklong sprint is ideal, but a two-hour workshop is a good introduction to the process.
  2. Have real project teams arrive with an actual problem to solve.  They can get deeper into the exercises and walk away having accomplished real work.
  3. Give away a copy of the book to interested participants.

Resources

My Slide Deck

Sprint checklists

For more on this topic you can read my other article(s) in the series:


The Red Hat portfolio of products empowers professional developers to be more productive and build great solutions.


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

Share