Scrummaster tip – Make your teams stronger by doing less work for them!

Sometimes as Scrummasters we spoon-feed our teams a bit too much by doing loads of small support tasks for them. To make our teams really strong and self-organising we need to take a step back and do as few things for them as possible.

So a simple way to live that day-by-day is to not spoon-feed players [as a coach]. And that might be [something simple like] not handing out a daily plan every day.” Wayne Smith, All Black Coach

This is a list of trivial things that you might be doing that you can easily offload to the team.

  • Bringing postits and sharpies to the Planning meeting
  • Turning on the digital board before the morning standup
  • Printing and drawing the line for the Iteration Burndown chart
  • Printing Story cards form JIRA (or other Agile software)
  • Calls the countdown for Planning Poker – the Product Owner should do this
  • Orders new stationary eg postits and sharpies
  • Cleaning the board at the end of the Iteration
  • Moves the Board into the meeting room for planning
  • Filling out the Capacity Plan for the team
  • Closing the Iteration off in JIRA
  • Starting the new Iteration in JIRA

What else can you think of?

Every iteration try to think of one small thing you are still doing for the Team and let them know that they will be taking responsibility for that from now on. Slowly but surely they will take full control and responsibility for their own Agile journey

Handling risks in Agile

One of my recent BAU Scrum teams ran a fortnightly risk review meeting. The risks were prioritised according to probability and impact and tracked in a risk register spreadsheet in Excel.

If there were Stories that the Team could work on to mitigate risks, these were added to JIRA. The Stories in JIRA and the risks in the risk register were linked.

The importance of the risks became part of the business value that the Product Owner considered when he prioritised Stories for each sprint.

When the stories were DONE in a given iteration, both JIRA and the risk register was updated.

Planning new Stories part way through an Iteration

Sometimes an iteration will get off to a brilliant start and it will become obvious that the Team will finish the planned Stories well before the iteration is finished. When this happens it is important to make sure that any new Stories that are planned in are planned properly.

When planning in new Stories consider the following:

Do

  • Make sure that the Team agree that ALL of the original planned Stories will get DONE.
  • Book an interim-planning meeting with ALL of the Team and the Product Owner to plan in the new Story(s).
  • Make sure that any new Stories are fully written and go through the same planning rigour as any Story planned in at the beginning of an Iteration.
  • Even if a Story is written and estimated it is important to review the Story as you would at any planning session to make sure the details, conditions of satisfaction and estimate are still accurate.
  • The Team must COMMIT to getting the Stories new DONE just like in any other planning session.
  • The new Story(s) become part of the Teams commitment for the Iteration and are included in any post Iteration metrics. If a new Story doesn’t get DONE don’t be tempted to wipe it from the records as it “wasn’t part of the original plan anyway”.
  • Review why the original plan wasn’t accurate at the Team Retrospective.

Don’t

  • Don’t pull work that the team cannot get DONE according to their Definition of DONE
  • Don’t just pull the next highest priority Stories off the backlog
  • Don’t plan in the new work at Standup
  • Don’t let the Product Owner make the decision for the Team
  • Don’t use previously written Stories without the Team fully reviewing them and confirming estimates

Why having extra capacity part way through an Iteration isn’t always great.

It might seem like a good thing to have a load of extra capacity part way through an Iteration but underplanning an iteration is still a failure to estimate and plan accurately. Also planning in new Stories part way through an iteration is less efficient than planning the same Stories the beginning so there is an impact on Velocity.

Retrospective

At the Retrospective ask why they original plan was underestimated. Understanding why we weren’t accurate will help is plan the correct amount of stories in future iterations.

A lesson in how to handle customer feedback on a website.

Last night I was using http://www.homely.com.au/ and a couple of the filters wouldn’t work. I noticed they had a ‘Help us with feedback’ button. so I clicked it and said what was happening. Experience has taught me not to expect too much with these things so imagine my surprise to receive this email less than an hour later

Hi Carl,

Thanks for the feedback, much appreciated. We have tested the link, and it looks like you had ‘Rural’ selected when browsing on a non rural area.

I ran a test on Chrome 35 and Windows 8.1 and our filters seem to be working.

Here is the same link, without any filters activated: http://www.homely.com.au/buy/bondi-junction-waverley-sydney-greater-new-south-wales

Can you confirm if you are still having troubles with the price filters?

Kind regards,
Laura
Homely Customer Team

Lessons

  • Have a prominent button on your site that asks users to help you with feedback
  • When users give feedback capture other useful information like URL, browser, OS …
  • Respond immediately with a useful answer

Users will be blown away as this experience should be far better than what they are used to.

homely