If you've been in software development for a while, you've probably seen projects with one or more of these problems:

• A lot of long hours just before, and just after, a "go live".
• Last minute changes, introducing quality problems and personnel stress.
• Developers and business people are discouraged from talking with each other.
• Software is delivered according to specs, but it doesn't meet the actual business need.
• A few key developers are swamped, while more junior developers have very little to do.
• Features that go unused.
• And the bottom line: significant overruns of time and/or application cost.

Unfortunately, these problems are the norm in many environments, and they're only becoming more prevalent as businesses have to move faster to be competitive.  What can be done?

In the 1990s, a group of software scientists introduced the concept of running "Agile" projects, and they set down their principles in The Agile Manifesto.  The main concepts are simple:

• Changing requirements are normal, and should be encouraged.
• Small, short delivery cycles are more likely to produce business value sooner.

It's much easier for a business user to comment on what he needs if he has a prototype to work with.  It's much easier for a programmer to change code that took a week to write, than code that took a year to write.  Not only from the standpoint of technical difficulty, but also emotionally.

"Scrum" is one of the popular Agile methodologies, championed by Ken Schwaber.  I'll explain it by going through its vocabulary.

Product Backlog - This is a complete list of desired features for the Product, maintained by the "Scrum Master" (Project Manager) and the Business Process Owners (can be Business Analysts, departmental managers, etc.).  The Scrum Master and his team assign estimates to the features, and the Business people prioritize them.

A Sprint is a short period of time, typically two to four weeks with a solid deadline, during which the Scrum team works on a group of Product Backlog items.  The team commits to specific high-priority items that can be finished in that timeframe.  The team then starts work, and the Scrum Master keeps the team focused on these items only.  If new items are added to the Product Backlog, they will be addressed in future Sprints.

A Sprint Backlog is a more detailed breakdown of the Product Backlog items that are selected for the Sprint.  Typically, one Product Backlog item corresponds to several Sprint Backlog items.  Where possible, a Sprint Backlog item is assigned to only one person.

Scrum works best with in-person (not virtual) teams, and common working hours.  In this environment, there is a meeting each morning called the Daily Stand-Up, so-called because people are not allowed to sit down.  A standing-up meeting, along with a good agenda, keeps it brief.  Status, new issues, distractions and roadblocks are discussed, and then the meeting breaks up.  The Scrum Master goes to the business and IT people outside of the team to get the issues resolved for the next day.  And then... Scrum succeeds or fails based on the skill of the Scrum Master and the organization's commitment to an agile process.  I can't over-emphasize this point.

In the Scrum team's area, there are a number of lists and charts prominently displayed.  The Sprint Backlog may be a big piece of paper with sticky notes.  People move the sticky notes to different areas (task 4.2 is now in "Testing") to give updates in real-time.  Some teams do this with software, but the idea is that status is always highly visible.

A Burndown Chart is a graph with dates along the bottom and effort remaining (total hours in Sprint Backlog) on the Y-axis.  This usually goes down from day X to day X+1, but occasionally new requirements are uncovered and it goes the other way.  Visually, the chart shows an easily understandable answer to the question "how are we doing?"

In my next column, I'll show how to write a simple ASP.Net graphing program to generate the Burndown Chart.