Are daily stand-ups necessary?

On a recent long project, our team’s commitment to continuous improvement led to some interesting results.  Originally, we started with quite a bit of the Scrum ceremony, such as sprint planning meetings, time-boxed iterations, and daily stand-ups.  However, since we practiced “whole team”, the daily stand-ups included around 25 people or so.  As a means of communicating information, these meetings tended to drag quite a bit.

As time went on, the importance of our daily stand-ups waned, to the point where in many cases we stopped doing them altogether.  It wasn’t that we didn’t find value in these meetings, but that instead we found better, more efficient ways to communicate information.

Waiting to communicate

In the daily stand-up, you answer three simple questions:

  • What did I accomplish yesterday?
  • What will I do today?
  • What is preventing me from accomplishing today’s goals?

It took me a while to understand, but a conversation Scott Bellware a couple years back drove a simple point home.  Why are you waiting for a once-a-day meeting to bring up a blocking issue?  Unless this blocking issue happened in the previous 15 minutes before the meeting, how much did you waste by keeping the blocking issue internal?

Scott recommended that each of these questions could be more efficiently answered, and answered in a JIT fashion.  When you need to know the answer, just ask!  When you have a blocking issue, just raise it!  Don’t wait for the next day to raise the flag for help.

Examining the goals

The purposes of a daily stand-up include:

  • Share commitment
  • Communicate status, progress and plans
  • Identify obstacles
  • Set direction and focus
  • Build a team

The problem I have with a daily stand-up is that no matter how short it is, it still stops everyone’s workflow for 10-20 minutes.  That’s 10-20 minutes of downtime, plus whatever time it takes to prepare, plus whatever time it takes to resume activities started before the meeting.

Often, the standup meeting takes place well after the time I’ve arrived at work.  It can take quite a bit of time to “prime the pump” and work efficiently.  Human beings do not deal well with interruptions and context switching.  While these goals are good, are there different, more efficient ways of dealing with them?

Sharing commitment

When I’ve worked with a strong, motivated team, shared commitment came naturally.  Everyone had a shared goal of moving stories to production in the shortest time possible.  Everything else that did not add value to that process was superfluous to that goal.

When our team did not have shared commitment, there were often larger issues at play.  It could be that the goals were not effectively communicated from management.  It could be that work habits were not in tune.  But often I’ve seen people shy away from the individual commitments that a stand-up brings.  You can say it’s a shared commitment, but that’s tough to do psychologically when the questions answered are centered around “I”.  What did “I” do yesterday.  What will “I” accomplish today, and so on.

Instead, I’ve seen that when a commitment made to the team isn’t met, when a mini-deadline is given, the person is often left in a negative, defensive position when the commitment isn’t met for whatever reason.

Communicate status, progress and plans

This can ALL be accomplished with a single, visible, shared and open story wall.  A story wall is a place where you can visually see where a story is in the overall process.  Ideally, the story wall is physical (or at least very visible to everyone).

All three of these items can be seen from a single story board.  Status is just where the story is in the pipeline.  Progress is how far it is along the journey, along with how long it’s been in the current bucket.  Planned work is simply the stories queued up.

Whenever status changes on a story, we move the story from phase to phase.  Whenever anyone wants to know where a story is, they can just look at the wall.  We initial our stories for who’s working on them, so if anyone wants to know more detailed status, they can go ask the individual person currently working on the story.

Identify obstacles

Again, why wait to bring up a blocking issue?  In our story board, we visually indicated a story was blocked by placing it either in a “blocked” bucket at the bottom, or placing a red Post-It note on it.  It was up to the person with the blocked story to communicate with the correct people, as soon as possible.

Set direction and focus

This could be another one of those cases where management should take care of this one.  The direction is to finish stories.  The focus is to finish the story you’re working on.  If you’re done with a story, pick up a new one.

If the process flow is clearly laid out, there really shouldn’t be a question of direction or focus.  For things like product direction, is this something that’s supposed to be communicated on a daily basis?

Build a team

I do admit, daily stand-ups do help build a team.  But for us, it was the shared conversation of how little value we were getting out of our stand-ups any more, besides just observing patterns in other’s daily reports.

I’m just not sure it’s worth stopping the entire line for 10-20 minutes every day to achieve this goal.  There are much more targeted ways for building a team other than a daily stand-up.  Like office Nerf wars, for example.

Achieving the goals

Daily stand-ups are a good way to meet the goals of a daily stand-up.  But that doesn’t mean it’s the only way.  As with any process, it’s important to constantly re-evaluate what the goals and values are, and how they relate back to the ultimate goal of the project.  If the goals are important, we should try to work to the most efficient means of achieving those goals.

For us, moving towards a lean-oriented approach, with a pull-based system, big visible story board, and keeping information visible to all achieved these goals in a more efficient manner.  That’s not to say that daily stand-ups are never a good idea, but I think it’s important to always evaluate the project activities to determine if there are other ways to meet the same goals.  Often, daily stand-ups are the most efficient means to achieve these goals.  In many other cases, it’s not.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Joss

    25 people are too many for a stand-up. Don’t you have a smaller measure of unit for a team? If not, shouldn’t you?

    We have teams of no more than six and then a representative from each team attends the “SRUM of SCRUMs” which occurs directly after the 15 minute team stand-up. The information that is imparted in the stand-up is invaluable to knowing in a macro fashion where things stand and where they are going for that day.

    We use Rally for our storyboard and have full visibility into the status of a project. Roadblocks are well defined to the team and then to the SofS to get action going o a daily basis or to review progress on ones reported in prior stand-ups.

    If you drop the stand-up, how many team members would bypass examining the “story wall” in favor of getting problems solved for their domain? It would be like telling a teenager that homework is optional, in my opinion.

    There are so many worse things than a 20 minute meeting that is conducted well and with rigor and the results seem to be positive for project outcomes. Perhaps it is how you conducting your business that is the problem.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Joss

    A “whole team” includes product owners, analysts, testers, developers, tech lead, architect etc etc. The dev team alone was anywhere from 6-7 people. But when we got everyone together that was contributing to moving stories from one end to the other, it was a lot of folks, all in one room.

    I’m not saying stand-ups are bad. Just that we moved past them for more efficient means of achieving the same goals. The information radiators we employed already imparted the same information, at any time it was needed. Since the information was there at all times, we no longer received the benefits of a daily stand-up, so we stopped.

  • Sean

    @Joss — If your team resembles teenagers and the only thing keeping them on track is a 15-20 minute daily meeting then you have bigger issues!

  • fzamoraj

    I have seen the value of stand-ups wane in many different projects…. Many are the signs that stand-ups can be bad….

    1. Individuals finding nearby chairs to sitdown
    2. Individuals not having any input
    3. Stand-up taking longer than 15 minutes
    4. Individuals not paying attention to what anyone else is saying…
    5. Stand-ups having more than 8 people

    …..

    I think that if you have a better solution use it.

    I am not saying that stand-ups are a waist… but if they are practiced as a religion they can be.

  • http://robtechdiff.blogspot.com Rob

    Well, for daily scrums, only pigs are allowed to talk. Your POs and Analysts at least should be quiet during those meetings, and if there’s a discussion that needs to happen, only those invested in it should have another discussion outside of the stand up. The stand up is for identifying these things, not discussing the resolutions.

    The point of the daily meeting though is to make sure people attend to the points you listed in AT LEAST 24 hours time. For most people, if it wasn’t for that meeting, they wouldn’t address them, until some fire was already raging uncontrollably.

    If your team is really “on the ball” and good about communicating, then yes, you could theoretically get by without them, but most people would tend to slide and and not report roadblocks, get stuck on something for days, etc.

    I understand about it feeling like an interruption (ours is after I’ve been at work for over 2 hours typically), but the pros outweigh the cons. It provides a steady, reliable venue to make sure everything that needs to be addressed is addressed.

  • Steve

    Sounds like a poorly run scrum project. I’ve seen this – where people sit around, talk too long, etc…

    That means the person running it has no control over the meeting and or misses the entire point of the meeting.

    The ‘real topic’ should be ‘how to effectively manage scrum meetings’ ?

  • http://blog.dayleyagile.com Alan Dayley

    Very nice discussion. I can imagine teams that do not need daily stand-up meetings. You define some good ways to get most of the benefit without the meeting.

    Something potentially missing without the meeting is serendipity. Let me explain.

    If I have a problem and I seek out help immediately, that is good, with our without a daily meeting. But I would tend to seek out and discuss the issue only with people who I think are knowledgeable in that area. It may be that a team member I don’t think is part of my issue has just the insight I need to solve my problem. Without that person given the opportunity to hear my problem, it may take longer to solve than otherwise.

    This same sort of “accidental” exposure to insight around plans, architecture and all the other things a team does happens more often with a daily meeting than without. The serendipitous discovery of talent, skill or knowledge is harder if people are not exposed to information outside of their expected expertise.

    This benefit of a daily meeting may not be important to particular teams or projects. However, it should not be discounted. The only other way I can think of to cause such information discoveries is by having the whole team co-located in the same room. If the team is not all in the same room, I don’t know a better way to cause them besides a daily meeting.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Rob

    I find the “pigs vs chickens” comparison didn’t work here. Everyone in the room and who contributed in the standup worked to get the story card from one end of the board to the other.

    @Steve

    Yes, it was a poorly-run scrum project. At least at the end. In that, we gradually, over time, found scrum to be obsolete and its ceremony and overhead more of a waste. At first, we rigorously followed scrum, but over time, we outgrew scrum.

    Which is really the best goal of scrum. A good scrum team will outgrow its usefulness, to more efficient means of communicating and working.

  • http://simpleprogrammer.com John Sonmez

    I agree with much of what you said.

    I have found (in general) that Scrum standup meeting end up becoming more of a show than value. Team members start thinking about what they can report (in order to not look like they didn’t accomplish anything) instead of what they should report.

    Anytime something becomes ceremony instead of value, IMO, you either need to eliminate it, or change it to add value.

    The way I have found to add value is to add accountability.

    1. What did I accomplish that I committed to accomplish, that is relevant to a backlog item? If I didn’t complete what I said I would yesterday, why not?
    2. What do I commit to accomplishing today?
    3. What is slowing me down or hindering me in any way?

  • Steve

    As always, people are more important than the SDLC. So if a group of people can’t make Scrum work, it’s unlikely they can make any other SDLC work.

    One disagreement I have is in your first paragraph, the “waiting to communicate” section. If something is a complete project show stopper, yes they should be communicating it prior to the scrum, but more often than not, the impediment isn’t so important to interrupt everyone else on the team. Besides, there is other work that can (and should) be done in the few hours between scrums.

    Having people run to the rest of the team at the first sign of a problem is not a good thing.

  • David

    Daily stand-ups are indeed a waste of time when you work with people that have good communication skils.

    Which means that they are not afraid to talk but also know when its time to shut up :)

    Most of the teams that I worked in we had this flow of working 90 minutes in silence, then 10 minutes of downtime (smoking/joking around/coffee).
    It’s always better to wait till after downtime to talk to people then doing it JIT.
    Pretty frustating to be interrupted when you are deep in the zone doing complex stuff :p
    Means that you sometimes have to restart your whole though-process

  • http://www.lostechies.com/blogs/sharoncichelli/default.aspx Sharon J. Cichelli

    Whew, what a reaction you’re getting. Jimmy, I appreciate your pointing out that the emperor has no clothes. It’s important to question our habits and look critically at our ceremonies. What dissatisfies me about scrum and is nudging me towards a more abstract philosophy of agility is scrum’s reactionary adherence to practices instead of principles. “Do A, then B, then C, and if you don’t, it’s not Scrum.” Well, fine.

    That said, the idea of ditching the daily standup makes me feel panicky. But that’s good. That panicky feeling means I’m asking an important question. Good food for thought; thanks for putting the idea out there.

  • http://graysmatter.codivation.com Justice~!

    I’m not the hugest fan of Scrum, although I definitely can see problems with the meeting you were talking about, namely 25 people in a Scrum meeting and the fact these meetings were taking 20 minutes. yes, in that case better not to have a standup because there’s no way what everyone is working on is relevant to one another to that degree!

    We split our team into two sub-teams of 10 and did standups that way, along with moderation when needed so people didn’t get off track explaining issues or hangups more than necessary.

  • http://twitter.com/agilescout Agile Scout

    Well said. So much of the standup has become a useless status. A Good ScrumMaster can change that though!

  • Pingback: Standups – take them or leave them | Java Code Geeks