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.

Related Posts

Mar 5, 2015
2 minutes

Don't Be a Dunce, Save Your Orders

There are some gotchas that you think that you will always see coming. One such gotcha is the need to save an object to the datastore to persist any changes you may have made to that object.

While it seems like a reasonable concept at the base level, there are times that the need to save an object completely escapes your mind. It seems that for many non-developers, this occurs when they have been working a long time on a file, typically a Microsoft Word document, shortly before their computer blue screens, losing all of their work.

Aug 21, 2014
4 minutes

Google Chrome Makes Web Developers Lazy

This post may make me sound ancient in the world of web development, but here it comes anyway.

Like Microsoft, Google has decided to implement functionality in their dominant browser that is incompatible with the other major competing browsers.

When I first started developing websites professionally, ensuring a website worked for 99% of the site’s visitors was easy, relatively, as you only needed to make sure the site worked in Internet Explorer 6. Obviously, there were a ton of random hacks and tricks required to deal with the quirks of this browser, but you were fairly safe knowing you had developed your site to be tailored to the browser of choice for your visitors. However, the dominance of Internet Explorer 6 was bound to come to an end and it ushered in an era of multiple popular browsers including Firefox and Chrome. With no single browser having a massive advantage in terms of users in all areas, web developers had to make sure that thorough testing of their sites was completed in each of the major browsers.

Jan 8, 2015
3 minutes

Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.