At refactr
we believe in the value of connection, the
utility of agile processes, and the power of great ideas.
We are creating the next generation of software for
people who expect more from their web applications.
« The hardest part of being an Agile Project Manager | Subversion for source control »
More on daily meetings
Jon discusses why he and his team abandoned daily team meetings - a standard practice for many agile teams, particularly those using Scrum or XP. I can definitely sympathize with a couple of his reasons because I’ve had some of the same struggles from time to time. For instance, he’s right that keeping the meetings short and on-task requires discipline - not just staying away from what happened over the weekend, but also keeping the meetings at the right level of detail.
For example, in the daily meeting I don’t need to explain the full detail about an algorithm I implemented yesterday, just the fact that I did it. I can discuss all the details and rationale with the interested parties after the fact - this is an important point to keep in mind, especially on mixed-discipline teams that may include designers and testers. Many of them won’t care how or why I used a Factory pattern within my Bayesian text classifier.
What makes the most sense to me is that his team is typically spread across multiple projects. I agree with his position that the usefulness of daily team meetings decreases when everyone is not on the same project. The “3 questions” discussed during the meeting won’t typically impact someone not on the same project.
I disagree, though, with Jon’s thought that “Daily meetings might make sense if a team is using strict Scrum project management ….”
I’ve had daily team meetings on nearly all the projects I’ve been on for years and have found them beneficial whether I was a team member or “leading” the team. However, in all cases, the team was working on the same project. Coming back to that point, having been in both situations before, I believe that team communication means something different to a project team than it does to a team working on different projects.
This entry was posted by Scott Vlaminck on Monday, April 9th, 2007 at 11:39 am and is filed under Agile Processes. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Subscribe to weblog
I also wonder if there is a point of diminishing returns based on team size. For example, when the team consists of three or four people, two of which are pairing all day long, it is very hard to justify a stand-up when you are effectively collaborating all day long. ...on April 10th, 2007 at 8:09 pm
That’s an interesting thought. With a smaller team (down to 2 developers), a daily meeting might still be helpful for any outside people (testers, designers, mgmt). In that case, I would hope you could keep the meeting to 3 minutes or so - the challenge being still to keep the discussion at the right level.
Scaling up to larger teams, I would imagine that you would want to break the application into components to keep the meeting size smaller - but then be much more vigilant about swapping pairs, etc.
Casey, you’ve had more experience than I have on larger teams. How have you handled larger teams in the past? And what are your thoughts on how that worked for the team?
...on April 11th, 2007 at 8:25 amI stand by my comment about the smaller ‘contained’ team not needing a stand-up. Consider, the team with outside testers, designers and management actually have more than two members (2 developers, 1 tester, 1 designer, and 1+ management) and anytime there are external actors involved the stand-up becomes much more valuable.
On larger teams, obviously the scrum of scrums is one technique but another option is one big stand-up with all 30 people in the room (standing up) but the questions are changed — in this meeting you don’t answer the standard three questions, rather, the scrum master goes around the room and gives each team member the opportunity to enlighten the group on anything that they feel is important. It could be what they did yesterday, it could be what is happening upstream, it could be some new library that was added to the code base. The key is not everyone shares something which keeps the meeting moving.
...on April 11th, 2007 at 10:43 am