Scrum

So, I've used Agile/Scrum in the past, but always in a development shop that had been on that methodology for awhile. My current team is adopting it mid-project, and the results are both promising and a learning experience.

Basically, there are a few key principles:

• Change is inevitable; accept that things will change, and that other things will have to.
  
• Communication is as important as documentation. 

Every project has a product owner; someone who makes decisions on what the product should do.  It might be the head of operations, maybe the head of sales, or maybe someone more general.

The business owner creates and keeps a project backlog - a roughly prioritized list of what's being added to the application next.  All potential tasks for developers go into the backlog.  The backlog has a rough estimate on developer effort to build something, and also a rough estimate at a value to the business of having the new functionality.

The developers sit down and determine what they can deliver off the top of the backlog in the next two or three weeks, in a sprint planning meeting; those tasks move to a sprint backlog.  This meeting should include product owners, shouldn't take more than a day in total, and requires final high level requirements.  All tasks in the sprint backlog have an estimate on how long they'll take; the estimate has both management and developer approval as reasonable.  No task on the backlog has more than one day budgeted; any tasks longer than one day are broken into multiple tasks.

After this point, requirements freeze on everything in the sprint backlog, and a sprint begins.

A sprint is a short duration development cycle of fixed length.  Testable functionality should come out of the end of it.  Each day begins with a standup meeting.  The standup meeting is categorized by a few interesting quirks:

• Everyone literally stands up.  This helps keep the meeting short; it should be fifteen minutes or less.
• Anyone's welcome to attend, but the only people welcome to speak are those who are committed to the sprint.  "Committed", in this case, means that they'd be in trouble if they didn't do something *and* the sprint fails.
• Each person speaking quickly reviews what they did yesterday, what they plan to do today, and if they have any blocks in their way.
• The meeting is always in the same place, at the same time, every day.  It begins on-time, whether or not everyone's there.  And anyone late owes $1 towards donuts, or some other mutually agreed penalty.

Blocks are what they sound like; anything in the developer's way of getting the job done.  The standup meeting (and the sprint!) are run by a team member given the title of Scrum Master; it's their job to organize this, collect the dollars for donuts, and most importantly, work on removing blocks.

Two other meetings follow when a sprint ends, and they're both capped at two-to-four hours.

A sprint review (or demo) is a meeting of the team and the product owner, so that the team can show what has been completed.  Changes to the screens go into the product backlog, and if necessary, can move immediately into the next sprint backlog.  Incomplete work isn't demonstrated; it automatically is pushed forward into the next sprint.

The final meeting of the cycle is a retrospective; it's something like Toyota's kaizen, where everyone is asked to talk about what worked and what didn't in the sprint, so that the process can be improved and tweaked whereever possible.  Did some meetings have to happen earlier?  Was there a persistent block that's likely to come up again?  Does someone owe the team donuts?


Our biggest unsolved piece - the process improvement of the week - is trying to pin down which group is the most efficient at pushing out more requirements.  We've had some luck with a requirements team providing a high level document, but pinning down details requires reserving quite a few resources that are already short on hours; requirements happen when product owners have extra time, not necessarily as hand-in-hand with the developers as agile methodologies would like.


One other note of importance.  While agile, at least for us, lets good developers produce code more efficiently, past experience has demonstrated in spades that it also amplifies bad developers; it's no magic bullet, but another useful tool in the box.