SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:

Chaos due to changing requirements - the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.

Unrealistic estimates of time, cost, and quality of the product - the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.

Developers are forced to lie about how the project is progressing - When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.

SCRUM has been successfully employed by hundreds of different companies in many different fields, with outstanding results.

You will find many similarities between SCRUM and Extreme Programming, but one of the major differences is that SCRUM is a fairly general set of guidelines that govern the development process of a product. For this reason, it is often used as a "wrapper" for other methodologies, such as XP or CMM (Capability Maturity Model) - that is, it is used to guide the overall process of development when using these other methodologies.

The sprint cycle is an iterative cycle of about 3-4 weeks, in which the actual development of the product is done. It starts out with a Sprint Planning Meeting to decide what will be done in the current sprint. Then the development is done. A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.

The sprint cycle is repeated until the product's development is complete. The product is complete when the variables of time, quality, competition, and cost are at a balance.

The SCRUM team consists of 2 groups - the interested team, which consists of people who are interested, but who will not be doing the work, and the working team - people who are interested, and will be doing the work on the project.

A team typically has no more than 6-9 working members, although SCRUM has been successfully used with more members. If there are more members than manageable, the project should be broken into multiple sub-projects, each focusing on one, self-contained area of work (one for QA, one for documentation, etc.). There should be people to act as bridges - that is, to attend the meetings of more than one SCRUM team, and act as a communication bridge between the teams. Members of teams that are closely related/involved with each other should sit in on the other teams' SCRUM meetings.

The team's leader is called the Scrum Master. He should be one of the members of the working team - that is, he should be one of the people who is actually doing the work on the project. The SCRUM Master measures progress, removes impediments, and leads the team meetings.

The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint Planning Meeting is held to determine what features are to be implemented in that sprint. The sprint has 4 major steps:

A 15-minute SCRUM meeting is held every day. The SCRUM Master asks the three questions, and all members of the team and interested parties take part and give feedback. The meeting should be held at the same place every time, so that people know where to go.

A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration. See http://www.xprogramming.com/software.htm for a list of unit testing frameworks for different languages/platforms.

My main goal as a developer is to improve the way software is designed, and how it interacts with the user. I like designing software best, but I also like coding and documentation. I especially like to work with user interfaces and graphics.

I have extensive knowledge of the .NET Framework, and like to delve into its internals. I specialize in working with VG.net and MyXaml. I also like to work with ASP.NET, AJAX, and DHTML.

Comments and Discussions

“Have a 15 min meeting every day”. How about a 1 hour meeting every 3 days, instead? How about having a meeting whenever it makes sense to have a meeting?
Every company, project, environment are different, and you cannot apply any prefabricated rules. The success of the project depends on the talent and experience of each developer and project manager.
Some guy described his particular experience in a particular environment and all of a sudden it becomes a methodology. Have a 15 min meeting everyday - what an amazing concept!! Let’s follow it.

First of all all of theese are suggested practices, not rules.
Once said this, it happens that the daily meetings is one of the best of them because it makes the team fell part of the project by letting know everyone what's being done.
A motivated team is vital, and this practice is a way to get it because people does not feel apart.
Furthermore talking everyday about the problems you are having helps early detection of conflicts and can save time, because some other member of the team may have the needed knowledge (because he has encountered and solved it before) or because the Scrum Leader can do something to help about it.

At least that's my experience. If you think the meetings don't fit your working way just do not use them.

While I sympathize with both of you I do disagree as well. A Daily Scrum is called just that. Otherwise it would just be a Scrum. It is important to have that daily team contact. If you have concerns about the inconvenience of it all then address those inconveniences. Attendees should be on time, stay on topic and not over-run. The Scrum Master should monitor and control these aspects. This way it does not become too burdensome.

I don't agree that someone invented a daily 15 minute meeting and a framework was born. Scrum is much more than a daily meeting and I think that earlier comment was intended to annoy rather than be a genuine criticism. But I concede that there is sometimes something very obvious and common sense about it. But does that mean it should not have a name and organizations that define and support it? Also, don't criticize a framework for being simple. We are human and we need to distill complex problems in to simple solutions.

Finally, although Scrum is easy to understand, time and time again organizations are failing because team members rarely talk to each other, morale is low and by the time the product is delivered the requirements have changed and the design is no longer applicable. So if anyone wants to continue to stick to that 'framework' then good luck!

time and time again organizations are failing because team members rarely talk to each other

I'm dealing with that very issue right now. It's strange how personalities can so affect a project's success. Personalities that are "islands unto themselves" are not effective communicators and that creates a lot of risk. If anything, a daily scrum is a psychological communication tool that also has technical benefits!