Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Is there something funny about your Standup?


Software development teams that aim to be more “Agile” often pick and choose the pieces of an agile methodology that suit them.  For some reason standup is usually picked first, way before addressing their waterfall ways.  I guess it’s because it’s hard to do “retrospective” but easy to stand up during a meeting (despite teams that sit through their standup).

I’m a big fan of standups but have also witnessed ones that are poorly executed or even detrimental.  A traditional standup is a five to fifteen minute meeting where each team member stands together and answers three fundamental questions:

  1. What did I accomplish yesterday?

  2. What will I do today?

  3. What obstacles are impeding my progress (blockers)?

A standup is not:

  • A status report for your managers

  • The forum for discussing details at length

  • A replacement for healthy and timely communication with your product team

  • A way to trick developers into coming in early

Walking the Wall

The intent of standup is to share work in progress and highlight blockers — why not use the tool where you manage your agile development process?  This is typically referred to as “Walking the Wall,” and in my opinion creates a quicker and healthier conversation.  Here’s how:

Open Pivotal Tracker (or your agile tracker of choice) on a screen that’s easily viewed by the team.  Standup stations work well for this, otherwise you can huddle around the monitor with the most space.  Close the Icebox and zoom in on Current.

Step through each story in the Accept/Reject state.  Is it clear how a story should be accepted?  Is it clear [for larger teams] who is doing the acceptance for a story?  Side note for story requesters — do your best to accept stories right away.  Nothing is worse for a developer than seeing a rejection at noon for a story that was delivered yesterday.

Moving onto the first story in progress, let the story owner describe the work and give a gut check on how it’s progressing.  This is a great opportunity to raise concerns about an estimate, e.g., “This was pointed as a 2 but we had to do a lot of refactoring of the css.  We’ve probably got another day of refactoring before we deliver.”  Context is important, and highlighting this discrepancy gives the PM a chance to course correct if need be.

Once you’ve covered WIP, move on to the next set of stories in the Backlog.  If any have blockers like a “needs-discussion” label, drill into the detail and identify if you can resolve them on the spot.  If something needs design/assets, hopefully your designer (along with the rest of the core Product team) is there to confirm that they’ll upload the right files, etc.

Lastly, work out your pairs for the day and cover any housekeeping (“we’ll be reticulating the spines at 3pm, no pushing commits”)

If some important topic comes up and can’t be resolved within fifteen minutes, schedule a follow-up meeting with the people needed to resolve the issue.  You don’t get points for dragging out a standup until every problem has been solved!

This is the format for standup that I default to now.  I encourage you to give it a try if you’re finding standups have lost their value, or if you don’t think product stakeholders are in sync with the development process.  As always, ask your doctor if continuous improvement is right for your team.

Share This