I have recently worked on a project that used the Scrum model of software development, and here are some of my observations and thoughts about it.

From the Scrum website: “Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices.”

Scrum advocates short iterations (“Sprints” in Scrum terminology) and short daily 15 minutes meetings (“Scrum Meetings”). Scrum also uses a Burn-down chart to keep track of outstanding tasks for each Sprint, each release and the product/project as a whole. The idea is to be able to easily and accurately determine the status of development.

In the beginning of each Sprint, the team comes together and helps estimate outstanding tasks. The estimate is not to be “padded”. Once enough tasks are estimated (usually when estimates are adding up up to the total man hours available in the Sprint), initial workload is divided. Through out the Sprint, each developer is responsible for updating their own task and the actual time spent on each task.

During the rest of the Sprint, a 15-minute team meeting is held each day and team members talk briefly about what they have done in the past day, what they will be working on that day and any obstacles they faced. The goal of each Sprint is to burn down all hours estimated for the Sprint (all tasks complete). Any outstanding tasks at the end of the Sprint is moved to the next Sprint and explained in the weekly report.

The team’s development effort can easily be tracked by the number of hours which got burnt off from the original estimate and the updated estimates of remaining tasks.

However, in my particular situation, the daily 15 often turns into 30 or longer, wasting valuable time. The time it took to estimate the tasks during the first day of the Sprint often take longer than it should. In addition to other meetings scheduled for the development team, the team often loses the first day of Sprint to meetings. Of course these are not Scrum’s problem per se, rather flaws in execution.
 
In general, Scrum gives each team member and management a very transparent view of the development progress with quantitative details. Obstacles are reported to management in the weekly report. These all assist management to determine the best course of action and possibly enlist extra help for the team as needed. Each team member also gains experience with task estimation (a very important skill).