Scrum Methodology: Coordinating Teams to Produce Quality Products

Written by:  • Edited by: Michele McDonough
Updated Jul 4, 2011

Scrum Methodology can effectively increase the efficiency of and communication between teams to produce a quality, on-time product. Learn how this management process can improve your company's efficiency.

Scrum Methodology

The Scrum Methodology is based on the Rugby term for individual groups collaborating together to form a powerful whole. Scrum in project management is an agile management process to coordinate teams of approximately six or seven people who can be located anywhere in the world. The Scrum Methodology brings a cohesiveness into what otherwise would be many disparate groups. Initially, the Scrum Methodology was intended for the management of software development projects. Its use has now been extended to running software maintenance teams, or as a program management approach.

The scrums (teams) are made up of the Product Owner, the Scrum Master and the team members. The Product Owner is responsible for representing the interest of the client for whom the product is being made. The Scrum Master is the liaison between the team and the Product Owner. The team itself is comprised of a cross-functional mix of personnel, which can include software engineers, programmers, Q/A specialists and the like. While the Scrum Master is responsible for facilitating the team, the team has total control over how they will perform their work.

Scrum Process

The first step in the Scrum process starts with the Product Backlog, which is a prioritized list of software requirements for the product. While anyone can add items to the Product Backlog, the Product Owner has the final say on the Product Backlog.

The next step in process is the Sprint, a 15-30 day period during which the team creates an increment of potential priorities. Each team chooses from the list of priorities and decides on their Sprint Backlog. The Sprint Backlog is a list of tasks that the team believes they can finish during the Sprint. During the Sprint, tasks are broken down into specific chunks of time. Each day, the time remaining on each task is updated. When the time remaining on the Sprint reaches zero, the team will provide a demonstration of the software to all involved.

Scrum Daily Meetings

During the course of the Scrum, a daily meeting will take place to update everyone on each team’s progress. A summary will be given of accomplishments since the last meeting, future plans and reasons why something was not accomplished. This allows the Scrum Master to see where each team is and possibly offer help, if required.

These daily meetings should be a fixed amount of time, usually 15 to 20 minutes maximum. An agenda made prior to the meeting and distributed to all parties will help keep the meetings on track and within time constraints. To ensure that there are no delays, Scrum meetings should be held at the same time and use the same method of communication. If the teams are international, a compromise time should be made. This way no one feels that they always have to go out of their way to accommodate everyone else.

During the meeting, each team member answers three questions:

  • What have you done since yesterday?
  • What are you planning to do by tomorrow?
  • Do you have any problems preventing you from accomplishing your goal?

To show how much time is left on a particular task, a Burndown Chart is used. This helps determine the amount of time still needed to complete a project. While the goal is to consistently decrease this number, the estimates will toggle up and down as new work is added or completed. The Burndown Chart can also assist in Release Planning. A release date can be estimated based on time information from the Burndown chart.

There are many advantages to using the Scrum Methodology:

  • Communication can improve across all the teams.
  • It provides for an open forum, where everyone knows who is responsible for which item.
  • Scrum can increase team efficiency by as much as 20 percent.
  • Problems are more transparent.

Disadvantages of Scrum

While a whole project can be intimidating, using the Scrum Methodology helps break it into smaller, manageable parts. Above all, Scrum gives the project stakeholder, who is paying for the product, the advantage of seeing the progress being made every day. They are able to build a relationship with the people involved and they get constant feedback from the Scrum Team.

A few drawbacks to the Scrum Methodology are:

  • Decision-making is entirely in the hands of the teams.
  • There has to be constant, hands-on management.

While Scrum is not perfect, it is definitely a way to maximize efficiency, improve communication between teams and provide for an open approach to tackling a project.

Figure One is courtesy of http://www.controlchaos.com/about/burndown.php.

Figure Two is courtesy of http://www.mountaingoatsoftware.com/sprint_backlog.

Images

Source: http://www.controlchaos.com/about/burndown.phpSource: http://www.mountaingoatsoftware.com/sprint_backlog

Comments

Showing all 6 comments
 
sprint training Jan 7, 2012 10:08 AM
RE: Scrum Methodology: Coordinating Teams to Produce Quality Products
Speed is the quickness of movement of a limb, whether this is the legs of a runner or the arm of the shot putter. Speed is an integral part of every sport and can be expressed as any one of, or combination of, the following: maximum speed, elastic strength (power) and speed endurance.<br><br>
Abdullah Apr 7, 2010 6:21 AM
Limitation agile Team
In Agile Scrum all Team members empowerd,then all are self organize but few problems will with teams like ,Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.
Abdullah Raza Lakhan Apr 4, 2010 7:28 AM
Small Team
Agile Scrum Team are Restricted in size for several reasons:
The team has to self oragnize,implying an efficient order emerging from temprory chos.obviuosly this process would too large for larger teams.
Team member have to able to communicate spotaneously with each other and with other stakeholder (i.e without setting up meeting , send email etc)
this is too big limitation , individual team member has power for entire decision making , it should not ,only scum master can do such type of decision.so entire decision making should be improve in current agile scrum software development process
Abdullah Raza Lakhan Apr 4, 2010 5:17 AM
Small Team
Agile Scrum Cant work Well with Large Team, because of every team member is so expert , that we call self oragnization , means agile scrum can not manage with large team. I apply this is strategy in my oragnization but i will fail for support large that is 30 folks
abdullah Mar 28, 2010 1:50 AM
Scrum Limitation
Im appericiate Roy Phillips , for wrote the article on drawback of scrum , but im lit bit opposit Roy Phillips because entire decision is done by teams that is good because in general meeting every body know every activities so entire decision makes teams no issue , and select sprint backlog on base of prirorities that is wrong , this should be change
Roy Phillips Sep 3, 2009 8:28 AM
Drawbacks to the Scrum Methodology
This is a good, balanced article that I would certainly recommend to people approaching Scrum for the first time, right up until the end, where the statement "A few drawbacks to the Scrum Methodology" is thrown in, but left completely unexplained or justified:

"Decision-making is entirely in the hands of the teams"
Whilst tactical, daily decision making is indeed the responsibility of the teams - those best placed and qualified to make such decisions - overall decision making is driven by the two-level planning process of Scrum, under the control of the Product Owner. Even development of technical infrastructure ahead of business functionality requires the Product Owner’s agreement. Decisions made by the team are exposed and evaluated at least every month, as the work product is closely examined in Sprint reviews. The decision making as to what is built and when is certainly not in the hands of the teams, and many of the how’s are also given, both as "architectural runway" backlog items and agreed coding standards -- the organisation’s definition of "done".

"There has to be constant, hands-on management"
Management involvement in Scrum is mainly at the release planning level. A PM responsible for product/project delivery process works with the Product Owner to determine the features to be developed, and when. Within this overall schedule, the Product Owner and the teams produce the near-term plan, setting the schedule for the next few weeks – the statement “Each team chooses from the list of priorities and decides on their Sprint Backlog” is incorrect. The next main interface point for management is the Sprint review, where the work is demonstrated and reviewed. At this point, the PM can ask the Product Owner and Customers if what is required is being delivered, correcting the long-term plan if necessary and possibly highlighting new near-term targets.
So the "hands-on management" requirement is monthly, and hardly "constant".
 
blog comments powered by Disqus
Email to a friend