The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


Standing Room Only

Posted by admin under Scrum Discussion

I just ran across this post ( called “How Many Chickens Are Too Many?” on InfoQ, in which Vikas Hazrati reports on a rather lively discussion that occurred recently on the Scrum Development group. The discussion in question was triggered when one user posted that as many as four to five “chickens” attend his team’s daily standup. Given that his team only consists of five or six individuals, the ratio of mangers to developers is nearly 1:1.

Now, most Scrum literature clearly advocates that if a manager—or “chicken” as Scrum practitioners are fond of referring to them as—wants to attend the daily standup, he or she may do so as a silent observer. The daily standup is a meeting designed for inter-team communication. That is, it’s an opportunity for the team to speak with one another frankly about how the sprint is going. When managers are present, teams may skew the reality of their progress to present a rosier picture of development for them. Or worse yet, the manager may simply usurp the daily standup, using it as a time to micromanage the team. When this happens, Scrum’s emphasis on self-organization—that is, the team’s ability to choose how it will accomplish its sprint goals—is effectively undermined and management reverts back to a traditional, command-and-control approach. In my mind, the issue is clear. A manager should probably not attend the team’s daily standup meetings, but, if it’s essential, he or she should do so as an observer only.

Interestingly, many of the Scrum users who weighed in on the conversation claimed that this is not exactly a black-and-white scenario. Several explained that it depends on the particular culture of the organization. That is, if management is supportive of its developers and empowers them to make decisions (even if they’re occasionally the wrong ones), then there’s no harm in them attending this meeting. Of course, few of us have had the good luck to write software in such an environment. It’s far more likely that your manager or Product Owner is not exactly hands-off.

What do you think? Obviously, Scrum is designed to be flexible so that it can adapt to the needs of specific organizations. But should something as fundamental as this really be up for interpretation? I’m curious to hear your thoughts on this one.

Tags: , , , ,


Scrum Meetings

Posted by admin under Scrum Basics

Sprint Planning Meeting

In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversation between the Product Owner and the team. That is, it’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward.

When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog. If a team uses an agile tooling solution, this might be represented in a number of ways. A tool my company uses, ScrumWorks® Pro, has a two-paned view of a project, in which the product backlog appears on the right and the sprint backlog on the left. Using an intuitive, drag-and-drop interface, the Product Owner can easily add stories to the sprint.

At this point, the Product Owner may choose to leave while the team decomposes the sprint backlog items into tasks, though he or she is still expected to be available to answer questions, clarify Product Backlog Items, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day’s time.

Now that sprint goals are defined, the team is ready to get to work. Of course, other meetings also happen during the sprint, which I’ll discuss.

Watch an example Sprint Planning Meeting.

The Daily Standup

The heart of the Scrum process is the daily standup meeting, also known as the daily Scrum. This meeting helps ensure that the entire development team is always on the same page. Every day, the Scrum team gathers together, usually in a team room or private office—to report on the progress made since the last meeting, goals for the next one, and any impediments blocking their path. These reports are often phrased as responses to the following three questions:

  • What have I done since the last Scrum meeting (yesterday)?
  • What will I do before the next Scrum meeting (tomorrow)?
  • What prevents me from performing my work as well as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, it is recommended they attend a “sidebar” meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.

When the daily Scrum meeting is held is for the team and Product Owner to decide, but most Scrum literature encourages teams to hold the meeting as soon as all the team members arrive in the morning.

Watch an example Daily Scrum Meeting.


Sprint Review and Retrospective Meetings

When the sprint ends, it’s time for the team to present its work to the Product Owner. This is known as the sprint review meeting. At this time, the Product Owner asks the team to demonstrate a potentially shippable product increment. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”

After the sprint review meeting, the team and the ScrumMaster get together for the retrospective meeting. During this meeting, the team considers what went well, what didn’t, and what improvements could be made in the next sprint. Team members should be able to speak frankly about the sprint’s successes and failures. It’s an especially important opportunity for the team to focus on its effectiveness and identify strategies to improve its processes. Moreover, it allows the ScrumMaster to observe common impediments that impact the team and then work to resolve them.

Watch an example Sprint Review Meeting and an example Sprint Retrospective Meeting.


Tags: , , , , , , , ,