Monday, May 31, 2010

Scrum Is A Flow-state Interrupter

Overall, Scrum is useful.

But the Daily Interruption is an abomination.

First of all, because the Daily Interruption is supposed to be held every workday, it interferes with no-interruptions days.

Second, the Daily Interruption serves no purpose.

I realize this is heresy, but look at what is supposed to happen in the Daily Interruption. Every team participant is supposed to answer three questions:
  1. What have you done since yesterday?
  2. What are you planning to do today?
  3. Is anything blocking you?
The first two questions can and should be replaced by emailed status reports. Why waste time telling me something I can read (if I care, which I don't)?

The third question is even more asinine. Why would a programmer wait an average of 12 hours to bring up something that's blocking them? Shouldn't they deal with the problem right away?

If someone comes to a Daily Interruption to kvetch about a blocker, my question to them is always why haven't you dealt with this already, dummy.

Because the Daily Interruption serves no purpose, requiring programmers to attend it is fiduciary irresponsibility.

The Daily Interruption was invented to solve communication problems on dysfunctional teams. If a team is not dysfunctional, the Daily Interruption is make-work. Wasteful, flow-killing make-work.

But just try convincing a ScrumMaster that the team can do without the Daily Interruption. They've been to ScrumSchool, you see. They're ScrumCertified.

Except they didn't read the whole book. If they had, they'd know that Agile methodologies (of which Scrum is an instance) support Method Tailoring. And Method Tailoring allows a team to modify a methodology to fit the needs of the team and the project the team is working on.

In other words, a team can, with the blessing of Agile, tailor Scrum to eliminate the Daily Interruption.

As a compromise, if a team simply must have the Daily Interruption, at least only have it on the three days of the week that are already contaminated by other meetings. Leave the no-interruptions days alone.

Because our team has enlightened management, the Daily Interruption is not scheduled on no-interruptions days, and attendance is optional on the other three days.


  1. What I learned from my CSM course was that the tools (in this case, email) are good at hiding problems. Not everyone reads email or is brave enough to write anything useful there.

    Daily standup meetings are the last resort of making everyone in the team know where everyone is going. Team should be able to do things as one so much that there are the standup is very brief as everyone knows what's happening.

    Other parties (product owner, CEO, CEO's dog) can come and listen the daily meeting through but must remain silent; had they checked what's in the task list before the meeting they'd know where we the team is going.

    You should remember that scrum is a framework. While I think that daily email reports are as bad as waterfall if that really suites your team you should try that.

    Even though scrum has these daily meetings it doesn't say that if those become a problem for the team those couldn't be replaced something more suitable.

  2. Judging by the number of blog entries devoted to meetings, I would say your company has a severe case of meeting inflammation and needs an abstinence cure ASAP.

    I like your approach of canceling all reports. I've written that we should have an annual 'cancel all meetings day' on which all recurring meetings are removed from the calendar, and only those which are really necessary are rescheduled. Any ideas how to get people to sign on to that idea?

    I suspect that you'll find the Scrum Meetings (not just the daily scrum) are both purposeful and effective. If you do it right, the Daily Scrum becomes part of the daily flow of the team.

    It's OK to question the Daily Scrum in the retrospectives. Ask your team whether they feel the Daily Scrum is useful. If people aren't sure, it's always OK to try an experiment, say skip it for a Sprint and talk about the experience again at the next retro. Sometimes you need to break the rules to appreciate their value ;-)


  3. My team decided that a daily scrum was too often and that it could be cut down to two a week (with a third day already having a half-hour sit-down meeting in the morning). It worked pretty well. It also helps if it's scheduled for the point in the morning when everyone is still wandering about getting coffee or purging unwanted emails, because you're not actually started into anything important.
    Best 'scrum' I've ever had was when both manager and project lead were out on leave.
    Technical Lead, gathering team into circle: Has everyone got work? Good! Anyone got a problem? Great! Either of those change, you know where to find me. Scrum's over!

  4. The blog entries about meetings aren't directed at my current company. Intuit does a good job of minimizing meeting overhead (it varies by department, of course). We already questioned the dailies, which is why they're optional and only three days a week now.

  5. Hi Jim,

    I think the problem here is exemplified by your comment "Why waste time telling me something I can read (if I care, which I don't)?"

    Daily Scrums don't work if there is nothing meaningful for the team to share with each other. Why would that happen?

    Typically, it's one of these reasons:
    - Everyone has their own goal for the Sprint. Either this is a task level goal (I've already picked up my tasks in the Sprint planning) or a more systematic issue (I've got my component to work on, you've got yours). In either case, there's really quite little to communicate about since, well, why should I care what you're doing?
    - Daily Scrums are used for reporting, or rather, management uses daily Scrums to get reports from the team members. That's micromanagement, and I don't really know anyone who likes that. Getting questioned by the PM once a week is bad enough, so why do it daily?

    The first case is a matter of team formation, the second of lack of self-organization and empowerment. In either case, the daily Scrum is the thermometer showing something's wrong (Agilewise).

    When you feel your daily Scrums aren't useful, don't start with blaming the daily Scrums. Ask yourself why aren't they useful, and fix that. I'd hazard a guess that in 99% of the cases you should find stuff to fix, just like owl would...

    Yours Sincerely, Petri

  6. Why is the onus always on the team to work to find value in the methodology, instead of on the methodologist to produce a methodology that the team finds valuable?

    The methodologists are so convinced of the rightness of their cause, they never stop to think maybe the problem is with them, not with the team.

    We had a very large project with a lot of visibility that was, for a while, doing well (or at least appearing to), and the methodologists--who were consultants, and billing a gazillion dollars a week--were very happy to take credit for that. They gave presentations about it throughout the company that boiled down to "Now *this* is how you should write software". They said the team was following the methodology correctly, and that was why they were doing so well.

    Then the project failed catastrophically, and suddenly the consultants were nowhere to be seen.

    If they had any integrity at all, they would have taken credit for the failure too. They would have been at the post-mortem to figure out why things had gone so horribly wrong, and would have produced a set of "learnings" to do better next time (if anyone was crazy enough to give them a next time).

    But methodologists never do that, do they? If a project is going great, it's because of what they're selling, and if it fails it's the team's fault. Yet wasn't that same team only a few months earlier held up as a paragon of how to follow the methodology? Hmmm.

    This kind of blame-shifting makes Agile and Scrum unfalsifiable, which means they're not scientific, which makes them the software equivalent of alchemy and phrenology.

  7. Jim,

    +1 from me, too. I despise the Daily Interruption. Where I work, it is a daily scrum in name only, but a reporting meeting in fact.

    I recently brought up every one of your points in a meeting with my boss. He basically admitted that he liked the dailies because he could use them to keep track of team progress.

    The dailies do me absolutely no good and invariably jerk me out of the flow state. Gah!