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

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

We are new to Agile methodology. We have planned for 4 sprints for the completion of our project. We are currently in the 3rd sprint. Currently our customer wants us to implement a small sprint of 10 days at the end of 3rd sprint in which we can solve the bugs that arises from the previous sprint. Please let me know if this approach is right or wrong ?

But if we introduce a small sprint for solving bugs, etc. the subsequent sprint dates get extended. Is that okay in the agile methodology.

It's a good idea to not be rigid with agile (that is obviously contrary to "agile"). If it extends date, then should be understood by the client. Technically, all you need to do is factor in the bug fix sprints in the scheduling.

“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!

I am a programmer working at a company that uses scrum. I have worked here for 10 months now but I still do not understand some of the rules of scrum. I wonder if anyone here could answer my questions.

Q1: During every sprint we are supposed to deliver a fully implemented and QA-d features. In theory it means that during the last 3 days of a sprint a developer cannot work because his work would not be tested. Also, during the beginning of a sprint in theory QA does not do anything, before the first new feature is implemented since everything was perfect at the end of the previous sprint. Of course in practice things happen differently, but this is my understanding of what we try to achieve. What is the resolution?

Q2: Our team is organized around a feature, not around technology, and we have a several layers application built on completely different technologies. Therefore in our team we have an SQL expert, some ASP.NET programmers, some C++ guys, a driver developer and some qa people (we have 11 members). We also have external dependecies, because we implement an add-on into a platform, so of course we depend on everything in the platform. Now when it comes to estimates, you can give 1 estimate (story point) to each PBI. But since we take on work based on priorities, it can happen that from 70 story points, which is our average velocity, 55 would have to be be implemented by the single SQL guy and e.g. the C++ guys do not do anything. In this situation, is there a problem with how the teams are organized, or should the PBIs be separated into "horizontal slices"? Or where is the mistake?

Q3: What is the usual way to manage team dependencies? As I have said, we are developing an add-on into a large platform. Is it something usual that every team changes code until the last minute and then there is a hardening sprint and that's it for testing? Or is it usual that we turn to dependencies/gantt charts: PBIxxx has to be implemented before PBIyyy can be picked up. In this case of course PBIxxx and PBIyyy are not vertical slices.

Hi there,
I work in a small IT company. We have taken on some larger projects recently and have had trouble doing accurate quotes on these larger projects. We have had 3 main programmers working in different locations (from home), and found that just didn't work as there was no collaboration. So in doing some research I came across your article here on SCRUM and it sounds like just what we need. So we have convinced all team members to work from the one location. Now we just need to work out how to quote more accurately, on the larger projects, which we have found difficult mainly because we are doing things we have never done before, using new technologies etc.

SCRUM seems to deal with the pace of development and effective use of team knowledge, but can you offer any suggestions on how to quote more accurately.

If I knew that, I'd make millions on a book and as a consultant helping people do just that.

As a consultant, I usually just charge an hourly rate. Still, the companies want some sort of an estimate, and what I do then, even with small projects (because small projects can sound small but be really difficult) is to break the project up into milestones, and sometimes the milestones are very small (one week increments, in some cases). It's pretty safe to be able to estimate the first few steps of a project when I break it down into milestones, and it gets increasingly fuzzier as I go down the timeline.

What I do therefore is give my customers a firm estimate on the initial two or three milestones and then require a joint review of the work, reviewing what has been accomplished, what new information has been added to the knowledge about the project, a review of whether any course changes are needed based on new information, and of course, firmer estimates on the next two or three milestones.

I've found my clients really like this approach because it gives them the feeling (quite rightly) that they are involved in the development process and the decision making process, they feel they are more in control of their budget (which they are), they can see progress being made, and the iterative review cycle always (and I emphasize always) results in undiscovered but vital knowledge being suddenly discovered--business rules, workflow, real world requirements vs. someone's idea of how it should work, so on.

If a client doesn't want to work that way with me, then I don't want to work with them, because the result will most likely be terrible.

So, what I would suggest is, it's not an issue of more accurate quotes, but rather how you work with your customer to succeed in delivering what the customer really needs.

Mark,
Thank you for the reply. What you say is the way to go from a development point of view definitely. But generally we find clients won't commit to a project unless they get a "ball park figure", eg, it won't go over $X amount of dollars. Otherwise their perception is the project can go on indefinitely and never stop costing them money. Therefore they can not work out if the investment will be worth return, when the investment is unknown.

clients won't commit to a project unless they get a "ball park figure",

Good point. To get a ballpark figure, there are a variety (but I don't use them, so I don't have any links, sorry) of estimating tools out there. What they do is, given the requirements (screen, controls on the each screen, tables, fields in each table, and so forth) they estimate the complexity of the project (and therefore the manpower and cost) based on "industry standard" historical data. This includes testing, documentation, design, so forth.

One of my clients paid $10,000 for a company to work up such an estimate. The result was interesting, but what we all realized was, the resulting estimate was high by a factor of 10 because it couldn't consider the automation tools we were using.

But it's a baseline, which is really all the customer wants. You can adjust it based on your own in house expertise and tools.

Thanks guys. The guy two levels up from me in the food chain is a mechanical-engineer-turned-MBA who has been positively frothing over with buzzwords: "lean practices", "process", "takh[sp?] time" etc. . In self-defense, I need to start researching software management methodologies, so I can dissuade him from the notion that software development can be transformed into a 'turn-the-crank' process.

Be sure to emphasize that software is not, and at present, cannot, be a mass-production thing. It's still a craft, and will be for some time. Where the big money comes in is selling lots of copies of the product, and you're generally not going to get good money from a product that's poor-quality because it was rushed and under-funded.

"Blessed are the peacemakers, for they shall be called sons of God." - Jesus

"You must be the change you wish to see in the world." - Mahatma Gandhi