The purpose of the daily scrum (you might call it a standup), is for the team to plan the day. Think about that for a second.  When was the last time you left a daily scrum where the team had a plan? That isn't the way it normally plays out.

The activities and purpose don't line up.

In nearly all daily scrums I've witnessed, the format consists of a round robin of three questions.

  1. What did I do yesterday?
  2. What am I doing today?
  3. What impediments do I have?

At that point, everyone looks at each other for an uncomfortable second before declaring the meeting over and we all carry on with our day.  It rarely produces a plan of any sort that isn't focussed on what we, as individuals are going to do.  It feels uncomfortable because we don't know whether what just happened was useful or necessary and we hate wasting time.

Scrum says we should have these planning meetings, advises that we ask those questions and then has nothing to say about how the questions result in a plan. We have to figure that bit out for ourselves.

Depending on how work finds it's way into your development teams, you have a couple of options to start putting this right.

Option One: Focus on Outcomes

This option is going to work for you if you are prepared to really work iteratively. I don't mean you're working in Sprints.  I mean you are deliberately building underdeveloped software, deploying it into production, measuring progress towards your goals, and then refining and building on that design until you have something worthwhile.

If that could be you, the Sprint Goal is your friend. It's the most undervalued aspect of Scrum and it's the best way to get the Daily Scrum back on track.

Most of the Sprint Goals I've come across in the real world are "finish all the work on the board".  They might be worded in a way that isn't so dull but that's the aim; get the work done. I'm going to say that's a piss-poor goal.

Goals like that tell me there is a problem with requirements management.  It assumes that a water-tight solution to whatever problem it is you're trying to solve, has already been produced and all that's left, is to implement it.  That hasn't been the case once in my entire career.

Writing a good Sprint Goal is really tough for most teams and that's why it doesn't happen so much. Effective Sprint Goals is the subject of a future post but one easy way to get some traction is to remove the goal and restate the problem.

Instead of saying the goal is "Create a Login and Forgotten Password System", say "Users can't log in and they keep forgetting their password".  There's a subtle difference there.  One says, there's this Login and Fogotten Password thing we want you to build and here's a bunch of User Stories for you to complete.  The other says, our user's needs aren't being met, design and create something that solves that. How the team go about solving that problem is entirely up to them.

You can drop the three questions and ask the team to how they are solving the problem.  That's a very different position from taking it in turn to talk about our tasks. You don't need an agenda other than that single question.  Teamwork will happen as a result because problem solving is like developer crack!

Option Two: Focus on the Board

If you don't want to work iteratively (it's not for everyone) and you're happy that you are building the right thing, you should focus on finishing more than you start.  Incidentally, you can skip the Sprint Goal. Your goal really is "Get the work done".  If you're cool with that,   I suggest you "walk the board".

Instead of taking it in turns to answer the three questions, ask each team member to talk about the user stories and/or tasks in priority order. High priority here means closest to complete. Unfinished work will drag the whole Sprint down in a heartbeat if left unchecked so when something is started, you want to be confident you can finish it without interruptions.

If you're taking this approach, make sure you can see how long things stay in one column. I usually ask people to put a dot on the post-it for each day it has been in any state of in-progress. 

When the team talk about the work-in-progress, and they can see how long things take, they will start to develop a sense of when something isn't going well. Someone will bring it up. At that point, you can remind them that the whole team is accountable for the Sprint Backlog and someone will step-up and help move things forward.  That's the start of a daily plan. Go Teamwork!

Summary

Daily Scrums are only useless if you don't know or acknowledge what you're trying to achieve. If you just want to get the work finished, admit that openly and focus on how close the work is to being complete.  You still might not get everything done but you'll definitely get more done.

If you're out to really make a difference, and you're willing to accept that you don't know everything up-front, focus on the problem you're trying to solve.

Each approach centres around what you expect from the team and not from what each person is doing.  If you want people to act like a team, treat them as one.