The Scrum Daily Standup

One of the hallmarks of the Scrum method of agile software development is a daily meeting, or “standup”. The purpose of the Scrum Daily Standup is to make sure the Scrum team is aware of what tasks the other members of the team are working on as well as asking for and offering assistance to other members of the team as needed. The Scrum Daily Standup is NOT a meeting to gather the project’s status. In addition, this is not a planning meeting, so the discussion of implementation details is outside the scope of the meeting, and should be handled in a separate meeting, or after the conclusion of the Daily Standup. The is typically characterized by being 15 minute long at its longest, and everyone stands during the meeting. Each speaking member of the meeting will typically answer these three questions:

  1. What did you do yesterday?
  2. What are you planning on doing today?
  3. Are there any impediments preventing you from achieving your goals for the day?

When answering these questions, it is important to note that the commitments made in number 2 are not to the Scrum Master or to your manager, but they are commitments that you are making to the other members of the team. Thus, if you have something come up that qualifies under number 3, it means that the team should work to assist as appropriate.

Attendees of the meeting should include all the members of the Scrum team as well as the Scrum Master at a minimum. Additionally, it would be helpful if the product owner were a part of the meetings as well. Any other interested party can attend the Scrum Daily Standup, however, they should remain silent during the entirety of the meeting.

The Scrum Daily Standup is supposed to be a safe place for members of the team to discuss their work in progress and ask for help if they need it. This meeting is not a place to confront a developer about how they are solving the problems presented by their tasks and is not a place to question the judgement of developers. If a manager is in the meeting, and is not involved in the day-to-day activities of the team, they should not speak. If they are involved in the activities of the team, they should never use their power or position to belittle or humiliate other members of the team for their ideas, efforts, or any other aspect in front of the entire team. If you, as a manager, feel that there should be a course change or correction for a particular developer or task, discuss it in a one to one setting after the meeting.

When managers and other involved, but not committed members of the meeting hijack the Scrum Daily Standup for purposes other than what it was intended, its time that the members of the team evaluate whether Scrum is the correct development paradigm in this situation. If its not the correct development methodology for the team, change it. If it is the correct one, work to change those that don’t follow the methodology properly.

comments powered by Disqus

Related Posts

Write Software for People, Not Computers

Throughout a normal day, I end up reading a lot of information about current issues in technology, and today is no different. There was a debate raging about whether or not high-level math was required for programmers that was sparked by this article by Sarah Mei Programming is not math . While it is an interesting topic, and, surprisingly, I mostly agree with Sarah on this issue, that is not the most important portion of her post.

Read More

Compass Makes Writing CSS Fun Again

One of the things that has always annoyed me about web development is that writing CSS generally becomes a task that has a major lack of the features that you would expect in a programming language, even one as simple as JavaScript. These features that would be wonderful to have when working with CSS are the ability to use variables to define a set of basic colors that are in use across the site in one place, and then use the variable name throughout the stylesheet.

Read More

Write Your Own Compass Mixin

As a developer working with CSS, one of the things that I find a bit troubling is the amount of style definitions that I have to repeat over and over to achieve the design I desire. One of the basic tenets of software development is to utilize the DRY principle, otherwise known as Don’t Repeat Yourself. Fortunately, when you implement Compass and SASS in your project to generate your CSS, you have a way to avoid copy-paste programming.

Read More