Writings and compositions; the dream of better worlds.

Looking for an agent and editors who resonate with my work. Contact: steven@remare.co

All content contained herein is copyright Remare Pty Ltd, all rights reserved. ABN 43 654 275 493

Protips for a good standup

Credit: http://funnypetspictures.com/pdata/t/l-87.jpg

Credit: http://funnypetspictures.com/pdata/t/l-87.jpg

Protips for a good standup

Some general notes for a good standup; specifically written for new/aspiring scrum masters in teams originally setup by myself. This assumes some background - you're already using JIRA and Confluence, you've got a team that's getting more experienced at agile but still requires some coaching.

Let me know if the comments how you go!

What the Scrum Master needs to do

  1. Talk to user stories - use the board
  2. Manage the time (on time and finishing on time)
  3. Help coach team out of lower-level talk
  4. Make it energising
  5. Achieve focus for each member of the team
  6. Serve the team, not lead them - use inclusive language, adopt an attitude of helping them get better each standup
  7. Watch the team's body language - use the 16th minute to coach for the right attitude if you need to
  8. Keep a diary, to be updated right after your own standup - I'd love to look over it with you and see how we can improve

Don't stress, it's your first time! In general, developers make excellent scrum masters of technical teams - just take some time to reflect on the impact you have on people in your team; be mindful of your influence; and work to improve/finesse it.

Some additional items

  • Timing - make sure you start/end on time
  • Bookending - start the standup with an energetic sentence you say like "Let's go team!" to stop the chit-chat.  Doesn't really matter what you say - as long as it's the same thing from day to day, people get used to it.
  • Bookending - end the standup with an energetic sentence you say like "Well done team, that's the standup finished." Doesn't really matter what you say - as long as it's the same thing from day to day, people get used to it.
  • Estimates on new scope - if a PO adds something, make sure the team estimates it
  • Commenting - new-to-agile teams that aren't used to JIRA don't like commenting often; make sure that they do it.
  • Watch for body language - e.g. in a session today, I noticed 2-3 people looking at phones, with bad posture, inattentive. Target them with the question, such as "anything to add, Alex?" or try to bring them into the convo "What do you think about this, Jill?"
  • Super pro-tip: whilst using the likes of Confluence, you can press "m" and write the update as they give it to you. This makes live updating easy.

What your team needs to do

Team tasks: Before standup

  • Review your in-flight tasks
  • update tasks with comments as required
  • Make sure the status represents the current state accurately
  • Make sure new work you've picked up is set to in-progress.

Team tasks: At standup

  • Follow the standup norms (see below).
  • The meeting will run for 15 minutes max
  • Each person answers each question in 30 seconds max
  • Anyone not part of the scrum team, cannot comment or talk
  • Every team member must attend the meeting
  • After everyone has finshed answering to the three questions, the rest of the meeting will be dedicated to discuss the obstacles and impediments. Anyone without any impediments can leave

After standup

  • Update items as per the "before standup" tasks.
  • Catchup with the people your promised to catchup with.
  • Update the tasks you promised to update.

Standup Norms

The normal behaviour for our team will be:

  • Standup is in the same place, same time. No reason to be late.
  • Attentive behavior - pay attention, otherwise don't attend.
  • Everybody stands - it's a standup, not a sit down
  • No electronics - keep your phone/laptop away for 15 mins
  • Pass the token - if you need to, pass a "speaking token" around
  • User stories attend - talk to the story, not the people
  • Each story is a victory - celebrate it!
  • Prepare by knowing what I worked on before standup
  • Own the board - we control its appearance
  • Higher level talk (avoid low level detail) & Use the “16th” minute

Signals of a poor standup

  • Late/non attendance
  • People not listening
  • People “zone out” - sitting comfortably in chair rather than actively listening.
  • People “screen out” - on phones or other devices
  • “Not my turn” to speak
  • Focus on the runners
  • Non-visibility of issues
  • Not proactively pushing
  • Working on outside scope
  • Too much detail, “problem solving”

The signals of a good standup

  • Everyone is prompt to s/u
  • Team has focus
  • S/u is energising
  • Team has focus
  • Focus on the baton
  • Improvement enabled
  • Accountability for delivery
  • Team has focus
  • Team breaks into smaller problem solving chats post-standup
HiPer Lean: Scaling Agile - 4 Awesome, 3 Terrible Things about SAFe

HiPer Lean: Scaling Agile - 4 Awesome, 3 Terrible Things about SAFe

Hi Per Lean: Tools & Impediment-centric view