Empowerment v Command and Control Game – The Human Knot

For a fun game to teach empowerment v command and control I like the Human Knot game.

In this game, two teams are given a simple problem to solve. The empowered team tries to solve the problem with all members of the team contributing. The other team tries to solve the problem with a manager using command and control.

This video shows the setup and execution of the actual human knot.

Additional Setup for Empowerment v Command and Control Game

  • Split your people into two teams of 8 to 12 people.
  • Ask anyone if they don’t like physical contact and allow them to step out of the game (they can be the Manager or Scribe).
  • Ask each team for a volunteer to be a Manager. The Manager is not part of the human knot.
  • Ask each team for and a Scribe to write down what they see and hear. The Scribe is not part of the human knot.
  • Set the teams into human knots as shown in the video above.
  • Empowered Team – The entire team can work together to make decisions and unknot themselves.
  • Command and Control Team – Only the manager can make suggestions and the team must act on them. Team members are not allowed to take actions without the manager telling them to do so. You may need to police this and remind the command and control team to only do what the manager tells them to.
  • The Scribe writes down things they hear and observations from their team on a whiteboard.
    Record the time it takes for each group to unknot themselves.

Playback

When the human knots are both untied, ask the following questions.

  • How long did each team takes to get untied?
  • Which team was faster? Why?
  • What did people think the difference between the two teams was?
  • Review the notes on the whiteboard.
  • Which team would participants prefer to be part of?
  • What other observations did they have?

Other benefits

Team building
Get to know each other
Fun :)

More information about the power of empowerment

This exercise goes nicely with the Turn the Ship Around video by David Marquet.

 

The case for re-estimating Stories that do not get DONE

We want to build to a DONE culture where teams strive to get every Story DONE, every Sprint.

Taking a relaxed attitude to finishing Stories in the following Sprint doesn’t help set the expectation that DONE is something to strive for.

Partly DONE Stories can lead to an test heavy plan in future Sprints as developers code right up until the end of the Sprint instead of swarming on the Stories the team have already committed to and getting them DONE.

Not DONE Stories are wasteful.

Like it or not, Team’s often equate SP to credit. They often ask, “how do I get my points (credit)”? By letting Team’s take their credit/SP in the following Sprint it sends the wrong message about working towards DONE. Only giving SP/credit for DONE Stories incentivises teams to think about getting Stories DONE if they want the SP/credit.

Team’s velocities are calculated by summing all of the DONE SP and dividing by the number of Sprints. This leads to a slight overestimation of what the team can actually get DONE as it includes SP that got done and SP that the team could not get done. Overestimation leads to over-planning and this has costs associated with it:

Striving to complete the Sprint backlog that the team committed to in Sprint Planning encourages the team to master core Scrum practices that will help the Team get their Stories DONE eg

  • Story writing
  • Estimation
  • Splitting
  • Planning
  • Collaboration
  • Swarming
  • Cross functional behaviours eg developers testing
  • Actively talking about how to get all of the Stories to DONE
  • Scrum ceremonies

Teams need to do some sort of re-estimation of any partially completed Stories so they know how many SP are left for new Stories in the coming Sprint. If some sort of re-estimation of remaining work isn’t completed then there is a risk that the team will be over-planned.

Quick and informal re-estimation of Stories that didn’t get DONE eg by the dev who is working on a Story, are likely to be less accurate than a formal re-estimation process eg whole team and planning poker.

If you are re-estimating anyway, why not update the Stories in the next Sprint with the more accurate numbers?

If a team re-estimates SP but doesn’t update the Stories then only insiders in the team with the secret estimates can accurately read boards, Sprint Burnup/Burndown.

If Stories aren’t updated it makes it difficult for outsiders (RTE, PM, Sponsors etc) to assess how the Sprint is progressing by looking at boards and in tools like JIRA eg if an 8SP Story
hasn’t been started with 3 days to go on a Sprint, is that a problem or not?

If Stories aren’t updated with the new estimates then it can be difficult to interpret reports like burndown charts eg how did the team get a 5SP Story done on day one of the sprint? If the 5SP being burnt on the first day obviously isn’t an accurate representation of effort expended then how can we trust any of the other changes in the Spring Burndown Chart.

Sprint plans with accurate, re-estimated Stories are more honest and transparent. Because of this, better decisions can be made.

Stories that don’t get DONE within the Sprint are wasteful

Every Story that is partially DONE within the Sprint still has to go through some of the following Steps to get DONE in some future Sprint.

  1. The PO must prioritise the Story again
  2. The Team must review and rewrite the story removing the parts that are not required and adding any missing detail and conditions of satisfaction
  3. If the Story is much larger than originally estimate then it may need to be split
  4. The Story must be re-estimated so the team can make a good Sprint Plan
  5. The Story has to be tasked out on the Team Board
  6. The Story must be coded
  7. The Story must be code reviewed
  8. The Story must be retested from scratch across all test cases on all systems, devices and browsers etc
  9. Bugs have to be raised and fixed
  10. The Story must be signed off
  11. Throughout the Iteration the Team must update JIRA/Rally, talk about the story at Standup and communicate with each other in a timely and effective manner to ensure it passes through the Team’s Iteration workflow.

In short, any story that does not get DONE, even stories that are “99% DONE” will still require a fair amount of work from several people in the Team in the next iteration. Teams should be aware of this and they should focus on getting the maximum number of Story Points DONE.

Scrum – Sprint Planning Checklist

A simple checklist for planning a Sprint Backlog.

  1. Quick refresh of change suggestions from previous Retro
  2. Set a Sprint Goal
    1. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment – The Scrum Guide
    2. Goals should be SMART eg Specific, Measurable, Achievable, Realistic and Time-bound.
  3. Capacity Plan – Log team availability in the coming sprint (including feature owners)
  4. Agree Velocity – Based on previous Sprints’ velocity, adjusted for capacity changes
  5. Re-write and re-estimate any not DONE Stories from the previous Sprint (if they are still a PO priority)
  6. Finish writing any incomplete Stories from Grooming
    1. Split Stories where possible – smaller is better
    2. Write Stories according to INVEST http://codesqueeze.com/how-to-invest-in-your-user-stories/
    3. Write tasks on postits
    4. Estimate using planning poker – use fingers for 1, 2, 3, 5, 8, 13, 20 …
  7. Pull prioritised and Estimated Stories into Sprint Backlog  until the Velocity is reached
  8. Hold a fist of 5 vote to check Team’s confidence in getting every Story in the Sprint Plan DONE http://agileanswerman.com/5-reasons-a-scrum-master-should-use-fist-of-five-voting/
  9. Team Commit to getting all of the Stories DONE
  10. Team put printed Stories from Rally and Tasks on their Board
  11. Team hold a mini-huddle to agree the tasks that each Team member will start on first (probably after lunch). Move tasks into In Progress with Avatars.
  12. Update the started Stories in Rally!

What makes a great Scrum team board?

I ran a workshop with my Scrum Masters recently asking them what makes a great Scrum team board. This is what we came up with:

  • A big team name banner / board title
  • Team sheet showing clear photos of everyone and their names
  • Velocity (with label eg a number by itself is not enough)
  • Specific Measurable Achievable Realistic Timebound (SMART) Sprint Goals
  • Clearly labled columns
  • Risks
  • Continuous improvement activities
  • Stories and tasks are colour coded
  • Key explaining what the colours indicate
  • Leave calendar showing when team members will be on leave (up to date)
  • The Team’s Definition of Done
  • Neat writing that is legible from a distance
  • Avatars clearly showing ownership of Stories and Tasks
  • Up to date, accurate and tidy