Agile Immersion Day Employing Serious Play

Posted on May 3, 2012

4



I am a huge advocate of hands-on learning and avoid ‘death by slideshow’ training methods at all costs.  So, when I was offered the opportunity to facilitate a full-day session on agile for the PMI, I proposed doing an Agile Immersion Day that would consist of a half-day of Serious Play.  The PMI folks went for it and a colleague and I delivered.  This is a recap of what we did…

The first few hours of the day was spent learning the Scrum Framework.  Sticking with the high-touch, low-fidelity approach, we did everything on flip-charts and posted each on the wall as we finished discussing them.  We covered the Scrum Ceremonies first and pushed a more detailed discussion of the Retrospective to a later slot in the morning.  We also walked them through the cadence of the Scrum Framework.  This included the discussion of a Task Board and limiting WIP within a sprint.  To support the discussion around limiting WIP and single piece flow, we covered Building Square-Shaped Teams With T-Shaped People.

Learning Scrum

In the second half of learning Scrum, we revisited the Retrospective and explained Sam Kaner’s Diamond of Participatory Decision-Making.  That discussion highlighted one of the key failure modes of rushing Retrospectives (one of the most important aspects of Scrum).  We then moved into a discussion about the Product Backlog.  We used the backlog pyramid and the INVEST acronym to explain the key characteristics of a well groomed Product Backlog.  We also touched on story splitting.  The last item we covered was the 5-levels of Planning.

Learning Scrum

With their basic understanding of the Scrum Framework with a bit of supporting detail, the group began their Serious Play exercise.  They started by crafting a Vision Statement that represented their perfect city.  Then, they brainstormed the key features that would exist within their city.  They prioritized their main themes and began detailing each one out into stories.  After some grooming, the group formed a Story Map (with a little help).  They then used this Story Map to identify their first Minimum Marketable Product, which would be their first release.

Story Map

The group then broke up into two teams and did Release Planning.  I gave them the constraints of three sprints per release with a sprint length of one hour.  Within the one hour time-box for each sprint, each team would need to complete Sprint Planning, Sprint Review, and a Retrospective.  For Sprint Planning to be considered complete, they needed to have customer approval for each story’s acceptance criteria and task the stories out on their Task Board.  They were also told that I was the customer and each feature would need my approval to be accepted.  The rest of the implementations details of each Sprint were left up to each team to define.  With that, the clock was started and the team’s took off!

Team 1 Task Board & Acceptance Criteria

I left the room shortly after approving each team’s Sprint Planning work.  When I returned, I found everyone swarmed around the table, furiously digging through bags of Legos, trying to complete their stories.  It was complete chaos.

Chaos!

In the first sprint, Team 1 barely completed their work before the time-box was up.  They used their two minutes remaining to do a quick Retrospective.  Team 2 did not complete their items and did not hold a Retrospective.  They had to carry the unfinished work over into the second sprint.  In the following Sprints, Team 1 made huge improvements while Team 2 continued to struggle.  By the last sprint, Team 1 had doubled their velocity and Team 2 was still having trouble getting stories accepted before the end of the sprint time-box.

Finished Product

After the last sprint ended, we discussed what each team observed and learned.  Team 1 cited Retrospectives, actively managing tasks, and frequent feedback from the customer as being the keys to their success.  Team 2 cited playing multiple roles and interpersonal challenges as being the key impediments to improvement.  My observation was that Team 1 succeeded because they were able to come together and work as a team and Team 2 did poorly because they failed to overcome the same teaming challenges.  All in all, it was a very successful day.

Learn more about LEGO® SERIOUS PLAY® here… http://www.seriousplay.com/

If you would like to participate in the next Agile Emersion Day, I will be running this exercise again at Cincinnati Day of Agile.

Advertisement
Posted in: Training