About Scrum

The Argument for Scrum

Monday, December 22 2008 - scrum, project-management, agile

Successful project management is easy. Successfully executed projects have at least these 3 common elements:

1. Somebody (or everybody) maintains a list of everything that needs to get done, broken down into manageable chunks, with time estimates for completing each chunk;
2. Every team member has a prioritized list of those chunks, which they are responsible for completing;
3. There's at least one person who monitors the progress to make sure things are on track.

Perform the above 3 tasks, and your project will have the highest probability of success. Sounds simple, almost too good to be true, but it really is that simple! Even if you did the above 3 tasks on paper, without the use of any fancy tools, your chances of succeeding would be greatly enhanced. Project management is not rocket science, but rocket scientists performed the above 3 tasks to land a man on the moon in 1969 with less collective computing power than the iPhone strapped to my belt.

Over time, however, best practices for how exactly to perform the above 3 tasks have emerged into hundreds (if not thousands) of project management books. Numerous methodologies have emerged, many from NASA. Most of these process-driven methodologies detail exactly how teams should perform every nitty-gritty task. Yet, with all these awesome project management methods and years and years of experience, NASA, perhaps the icon of organized project management, cancels or delivers more late and over-budget projects than it did back in the 60s.

Why is that? Why is it that NASA, with all of its project management wisdom, couldn't dream of doing what a few engineers did with the leadership of Burt Rutan: building a spaceship for under $30 million and winning the X-Prize? Rutan and his team built a rocket that can carry 3 people into space and an airplane that carries the rocket to launch to a high launch altitude. They successfully launched it into space twice in two weeks to win the X-Prize.

The world is full of examples where "regular" amateurs with far fewer resources and a lot less project management structure end up beating out larger, well-established companies that have relatively unlmited budget and their process methodology down to a science.

What all of these amateurs have in common is that none of them use a heavyweight, well established process to manage their projects. There are no examples I know of where a new company or team used a six-sigma process to unseat a leader in the field, but there are plenty of examples of a couple of 20-year old kids who worked using the "fly by the seat of your pants" methodology to build a new computer, search engine, operating system, web site or some other gadget that ended up changing the world.

Corporate America is also taking note. Some companies have recognized that the biggest risk to their well-established business is the "fly by the seat of your pants" methodology and they've decided to embrace it, although most are doing so reluctantly, without enough urgency, and half-heartedly.

Adoption of agile software development techniques, such as Scrum, are rapidly growing as a result of the flexibility they provide in managing projects the way a team sees fit.  Google is a great example of a company who has whole-heartedly embraced the fly by the seat of your pants, entrepreneurial techniques. They have built their success as a company who employs little process, manages through chaos and has little structure in anything they do. The result is a company that is nimble, quick and surprises the industry and competitors with both its hits and misses.

In a recent survey of customers, Axosoft found that more than 60% of its customers don't use any particular software development methodology.  However, of those who do, Scrum, which is a relatively new agile development technique, is the one that's gaining the most popularity. That's no accident.

A Quick Look at Scrum

Scrum's popularity is rooted in its back-to-basics philosophy, its simplicity and flexibility in execution. If you are new to Scrum, start with the Scrum in 10 Minutes video to get a quick overview.

The basic execution of Scrum can be summarized as follows:

1. Projects have a list of things that need to be accomplished. Since these items are not yet done, we'll call this list the "Product Backlog". It contains everything we'd like to have in the product.
2. To keep things manageable, we'll select a handful of items from the product backlog, assign them to team members and focus on getting just those items to a ship-ready state. We'll call this the "Sprint." We'll keep sprints relatively short so that in a particular product release, we have at least several sprints. The shorter our product release cycle, the shorter the sprint duration.
3. To keep track of where things are, we'll add up all the estimated hours of work currently remaining and compare the total to previous days to make sure it is consistently going down at a rate that is in line with our expectations and will meet our goals. We'll call this the "Burn Down." Charting the burn down information is an effective way to visualize the progress.

With just the above 3 concepts, any team can successfully implement Scrum and benefit from the low-hanging fruit of an efficient software development process. After implementing the above techniques, the next set of processes you'll want to add are the following:

• Stay in constant communication through frequent (usually daily) meetings. To keep the meetings short, conduct the meetings with everyone standing rather than sitting. That way nobody will waste time. These meetings are called Daily Scrums and help the team stay on track and identify obstacles.
• Maintain a defect backlog that is similar to your features backlog but focuses on bugs rather than features. For each release of your product, have at least one or two sprints that are dedicated to addressing the top items in your defect backlog.

Flexibility is the key to success with Scrum. Some teams, especially those who come from a high process-oriented background expect Scrum to have definitive bounds for everything and to explicitly define every detail. A sprint is exactly 30 days (it's not!). A must-have stand-up meeting that's precisely 10 minutes long (ridiculous). Estimation in points rather than hours or days. You get the idea. But Scrum is about allowing teams to define the ideal practices for their situation based on team size, project type, size, release cycles, etc. A 2-man team working in the same room on a new web product might have weekly release cycles and no need for meetings, while a 100-person team working on a 10-year old, mature accounting package will have vastly different needs. Scrum's flexibility is what allows it to work for both teams.