We have changed our methodology from stand-up meetings where we tick off lines of the spec, to the more formalized daily scrum meeting. We ask the questions:

What did you do in the last 24 hours?
What are you going to do in the next 24 hours?
Anything blocking you achieving that task?
Are you on target to achieve this weeks milestone? (*)

The stand-up meetings were mainly to tick off lines in the specification document. QA writes test cases directly from each line in the spec, so it becomes an easy empirical comparison to see where we are in the project as to how many pages of the spec can be retired as done and how many lines remain.

The difference was we did weekly meetings until the feature complete date neared and then we moved to the daily stand-up meetings. As we found who was being squeezed we would shuffle work around as necessary. It worked well in the last project.

With the daily scrum meeting we are adding more discipline in that approach, the downside is that there are more developers in this project so running through the verbal delivery of the questions takes longer (I type it out as it is being said and post to our internal wiki afterwards).

Already people are becoming bored with it, and trying to skip it by seeing me before the meeting with their tasks, or emailing their answers to the questions. Consequently I read with interest the article on skipping the daily scrum.

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.

We end up with a lot of unplanned work popping up each day. We are juggling a new product project alongside existing products that are in production. My day yesterday encompassed approximately 50% of unplanned work. Which is why the meeting needs to be a team one, rather than a series of IM's, emails and one on ones.

Ultimately the project is the teams and it is impossible for the team to self-organize to unexpected surprises, and hiccups unless the entire team is part of the process and absorbing the issues each developer faces in achieving the milestone.

A quick visual introduction to scrum and burn down charts.

Most software shops have some variation of these methodologies in place. It is rare that a surviving shop does not, as many of these mechanisms are the bare minimum of project and quality management. Once these become formalized they require discipline to adhere to exactly, whether crystal, scrum, SDLC, etc; and that usually requires coercion of process by the project manager which removes the self-organization aspects to a degree.

I saw this appear on Slashdot;

Furthermore, the ScrumMasters either cannot or do not separate their roles as Team Leads with those of ScrumMastery and -- worse -- seem to be completely unaware that this poor implementation of Agile development is harmful to our velocity.

At the previous place I was employed I was the Technical Lead and the Scrum Master. One did not impact the other, if anything they were mutually compatible. The team comprised of eleven developers in Phoenix and San Francisco and rarely did a scrum meeting go beyond seven minutes.They were fast and snappy. They were also long enough and gave enough feedback that it was obvious which parts of the project were badly scoped and which were being done on time with high quality.