In another conversation on an internal email thread, someone asked some newbie questions about Scrum daily standup meetings, like do they have to be every day or could they be done every three days or so? There were some good replies that encouraged the standard practice of daily meetings, then someone else mentioned that since his team sits together in one common team room, they communicate all day long and they’ve found the daily standup meeting to be not really necessary at all.
I thought that was a interesting point and replied:
That’s a good example of why it’s important to understand the goals that any given methodology is trying to achieve, not just the ceremonies that it uses to achieve them. The goal in this case is a short feedback cycle, shared understanding of what all team members are doing, and identification of the most important things to be working on right at this moment. The mechanism you use to achieve that is really beside the point if you’re able to effectively drive the goal. Scrum’s mechanism of the daily standup meeting is very effective for the vast majority of Microsoft teams who have individual offices. If you’re fortunately enough to have extremely high communication going on all day long, then sure, I can see how a daily standup would not be as important.
Anyone who tries to implement Scrum (or any other new methodology) without understanding the end goals and how the individual practices are intended to express those goals is pretty much doomed to failure. I suppose you can start out that way (I guess I did, come to think of it) but you can’t continue for very long that way. You have to understand the “why”, not just the “how”.
Time and time again when I see a person or a team who is fumbling along with agile practices (whether that’s Scrum, XP, TDD, design patterns, or anything else) and it’s not really working for them, it’s usually because people are just going through the motions they’ve read about without any real understanding of the principles, the philosophy, and the goals involved. There’s usually some cargo cult engineering going on. This causes at least two types of serious problems:
- Either they slavishly follow every detail of the methodology without considering the unique circumstances of their project and adapting certain aspects of the process to best fit what they need,
- Or they start slicing and dicing the methodology, throwing out whatever they don’t immediately like or whatever seems difficult to implement without having any sort of plan to accomplish the same goals by other means.
The Agile Manifesto calls for favoring individuals and interactions over processes and tools. No methodology should be followed to the letter without thought, but most methodologies have important, specific reasons for every practice they prescribe. The only way we can favor people over processes and still deliver working software is if we understand the “why” of our processes so we can intelligently mold them to fit our people.
