Skip to content

Skip the Daily Scrum? No, thank you!

March 11, 2009 by Peter Stevens

Last week I gave an introductory talk about Scrum to a group of people in Zürich. One participant asked if it would be OK to make the Daily Scrum a Weekly Scrum? My answer: No way!

The Daily Scrum exists to enable self organization. It helps the team focus, communicate and identify impediments. The team members communicate to each other their progress, goals and impediments. The team members identify how they can help each other to reach the shared goal of the sprint.

Each team member answers three questions:

  1. What did you accomplish yesterday?
  2. What is your goal for today?
  3. What is preventing you from accomplishing your goals?

Syncing up at the Daily Scrum

The first two questions allow the team members to sync up. Yesterday they made commitments to each other. Today they review the results together and make new commitments. Team members can recognize when they need to help each other, work with each other, or just need to talk to each other about specific problems. This is basis of self organization. The ScrumMaster may also identify impediments to progress which require his/her attention.

The answer to the first question confirms that each team member has worked on and achieved what s/he planned to do. Unachieved goals can be a sign that the problem is harder than expected or that the team member needs assistance. Unplanned work can be a sign of many different problems which will prevent the team from achieving its goal. Listening to the answer gives the rest of the team an opportunity to confirm whether the claimed goal has really been achieved.

Focus on your goals for the day

The answer to the second question helps each individual focus on the day’s tasks. Other team members can notice when their work is affected and raise the need to discuss a subject in detail. The second question should also identify free capacity if a team member does not have enough work for the day.

Turn excuses into a Call for Action

The third question serves to systematically identify factors which are impeding the team’s progress, so that these issues can be addressed as quickly as possible. If a team member needs help, e.g. from another team member, from the ScrumMaster, or from somewhere else in the company, this is the time to raise the issue. An impediment is transformed into a call to action and is not allowed to become an excuse for not completing work when the deadline arrives.

So to the participant in Zürich: You’re not doing one now, so it’s not killing you. But if you do Scrum without a Daily Scrum, self organization probably won’t work and impediments won’t get recognized or corrected. From my experience, half of the productivity improvement from Scrum derives directly from the close collaboration among the team members enabled by the Daily Scrum.

You might have compelling arguments why a Daily Scrum is not possible. If Scrum is not suitable for your project, that’s OK. But more likely, you are just trying to accommodate a situation which is suboptimal. So before you skip the Daily Scrum, ask yourself, ‘Can I really afford to skip the productivity benefits? Could I justify this to my Stakeholders?’ And ultimately, your self-organizing Team should have the final word.

About the Author: Peter is an independent Scrum Trainer and Coach. His mission is to help you realize complex projects. He provides coaching, training and project management to help you get started with Scrum, save projects in crisis and make your IT operations leaner and more effective.

Originally from the US, Peter now lives in Zurich. He studied Computer Science at Colgate University, started his career at Microsoft, and is now a Certified Scrum Master (Practitioner). He speaks English, German, French and Italian. An Instrument rated private pilot, his current hobbies are sign language and Sudoku.

Comments

Point one can easily be

March 12, 2009 by tieTYT (not verified), 2 years 47 weeks ago
Comment id: 2345

Point one can easily be abused. Today I was asked which defects I finished. The answer to this question is available to everyone whenever they want: we use a bug tracker! IMO, it violates the DRY principle to bring this into the conversation unless it's related to point 2 / 3.

RTF Bug Tracker?

March 12, 2009 by peterstev, 2 years 46 weeks ago
Comment id: 2352

Hi tieTYT,

Hmm. I must admit, I find the question the legitimate. The idea is you commit to your team-mates to achieve a goal, and then confirm to them that you accomplished that goal the next day. If you're not going to tell them about the bugs you fixed, what are you going to tell them?

If I were a member of your team or your ScrumMaster, I would be wondering what your attitude conveys about your relationship to the team or how the team is functioning as a whole.

Regards,
Peter

How do you keep the SCRUM fun?

March 12, 2009 by Ed Darnell (not verified), 2 years 46 weeks ago
Comment id: 2354

The value is obvious but in my experience these things become "routine" very quickly and in doing so generally lose their value. It is human nature to become bored by repetative process.

So a slightly different question:

How do you make the scrum as energising and valuable on day 30 of a project as it was on day 1?

Keep Scrum Fun

March 12, 2009 by lisagardelle (not verified), 2 years 46 weeks ago
Comment id: 2357

Daily Scrum is essential - it should also be short. Be serious about what you did yesterday, what you're doing today and what the impediments are. As the PO, with a team of 7, we keep the daily to 10 min and the last 5 is for 'chat'. A laugh or two before the grind of the day keeps it fun - but the report out should be meaningful, worthwhile, informative and well businesslike. If not, it becomes useless.

Three questions

March 12, 2009 by Mark (not verified), 2 years 46 weeks ago
Comment id: 2358

What did you accomplish yesterday?
- I prefer to be asked, what did I work on yesterday. I rarely accomplish anything daily.

What is your goal for today?
- I try not to plan that far ahead.

What is preventing you from accomplishing your goals?
- This blog, 24 on Fox, and Scrum meetings typically.

re: How do you keep the SCRUM fun?

March 12, 2009 by peterstev, 2 years 46 weeks ago
Comment id: 2359

Hi Ed

That's a really good question. I'm going to save it for a future article ;-)

I think 'keeping Scrum fun' is a real challenge. Particularly after about the team has been in the groove for about three months, there is a temptation to slack off.

My experience has been that the problem is most critical with the retrospectives: It's important to spice them up and to produce concrete results. So I try to vary the format, change the focus etc.

Cheers,

Peter

re: Three questions

March 12, 2009 by peterstev, 2 years 46 weeks ago
Comment id: 2360

Hey Mark,

I've got a fourth question: Why do they keep asking you embarrassing questions? You could both just give up on the illusion that your are doing some useful work. You could focus completely on 24 (I'm more into Heroes, myself) and save yourself all the hassle of coming to work.

Oh yes, and your employer could save the hassle having to pay you. Seems like everyone would be happier and better off, doesn't it?

Cheers,
Peter

re. Three questions

March 16, 2009 by Dada Mungo (not verified), 2 years 46 weeks ago
Comment id: 2377

Ed,

anyone can find work to do to fill up his/her time. That's why the questions are value-oriented. If we're not focusing on delivering results, then we're more than likely to be less productive.

One might surmise that your not planning 'that far ahead' may be linked to your seldom 'accomplishing anything daily'. Perhaps the tasks on your team's task board are too large? Try breaking them down and make them achievable within a day's time-frame.

Your comment about Scrum Meetings being an impediment is an indicator that you have not yet grasped the value that they bring. Now, there may be several reasons why that is so, but I would suggest you talk to your Scrum Master about it, since it's his/her job to help things click, which they clearly aren't doing for you. In the worst case, you're simply being obstructionist because you have failed to make the change transition to working in a more agile way. Ask yourself if your current modus operandi is really worth protecting.

making scrum more effective..

March 18, 2009 by arpan57 (not verified), 2 years 46 weeks ago
Comment id: 2388

What can be the new things discussed except from 3 questions?
What all innovative things can be tried as part of scrum?

3 questions answer will become "routine". Can we try out something new with these 3 questions?

Re: making scrum more effective..

March 18, 2009 by peterstev, 2 years 46 weeks ago
Comment id: 2389

Hi Arpan57

Gee, I would hope the answers would be different every day.

Today's article on How to hold the Daily Scrum (not yet published as I write this, but should be online in an hour or two) gives some thoughts and links to suggestions.

Cheers,

Peter

third question

March 18, 2009 by Bert Heymans (not verified), 2 years 46 weeks ago
Comment id: 2391

Good essential! I turn the third question around by asking "What do you need to accomplish your goals?" It's a small one but I get the idea that it tends to put attention more on possible solutions.

Re: Third question

March 18, 2009 by peterstev, 2 years 46 weeks ago
Comment id: 2392

Hi Bert,

You know, I've been thinking about that one myself. A colleague suggested exactly that change. I like the positive formulation and it encourages answers like "I need to talk to Joe about the API and to Jane about modifying the Database Schema". These aren't strictly speaking impediments, but it does help identify the need to communicate and self organize. And I think situations like "The build server is down and IT isn't getting it fixed!I need access!" would be evoked by the question.

Any one have experience with pro's and con's of this formulation?

Cheers,

Peter

Osmotic Communication

March 24, 2009 by Hamilton (not verified), 2 years 45 weeks ago
Comment id: 2406

In our agile shop we sit within feet of each other. If a team member doesn't know what the other developers on the team are doing on a daily basis then they are daydreaming instead of working or deaf.

In times when we've had to rush to meet a deadline, we found abandoning the daily scrum to be a valuable reclamation of time. From my perspective as a developer, the daily scrum is not nearly as valuable to me/my co-developers as it is to the management above us - it's their one chance to get a clue about what we're doing day-to-day.

It seems that if members on a team need to communicate with each other on a daily basis what they are doing then the communication channels are already broken. This sort of communication should happen naturally throughout the day. If a blocker is preventing a developer from doing work then that blocker should be identified immediately - you shouldn't have to wait a day until the next standup. Whenever a new task is embarked upon, there should be communication.

The other big slowdown about the daily scrum is that its another interruption. Not all developers get to work at the same time. If the standup has to happen at a particular time of day then it interrupts whatever work the developer was in the middle of when that time of day comes around. Furthermore, developers get the feeling that they don't want to begin their tasks until the daily scrum has begun. As a result, work may not be getting done when it otherwise could be.

Without a skilled scrumMaster, daily scrums quickly spin out of control into discussions about design and architecture. This eats up time.

Just .02,

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com