Maybe the worst name in project management history besides “levelsetting” but, maybe the best Aglie process around. Dr Dobb’s journal posted an excellent article summarizing Agile process in Scrum terms. Read full article online.

Scrum is an agile methodology that focuses on a subset of project management and requirements. Scrum has become popular in the past few years with the rise of agile software development, and is often used to round out Extreme Programming (XP); or perhaps XP is used to fill out Scrum, I guess it depends on your point of view. Scrum is particularly suited for “agile in the small” projects due to its simplicity, but as many organizations are finding, it can be a challenge to scale Scrum to meet the complexities of their real-world environments. The good news is that over the past few decades various people have identified a wealth of techniques which we can adopt and adapt to address these challenges.

Scrum was developed by Jeff Sutherland, John Scumniotales, and Jeff McKenna in 1993 during their work at Easel Corporation. It was then popularized through the efforts of Ken Schwaber and more recently by the Scrum Alliance (http://www.scrumalliance.org/). Although there is a lot of material available online and in books about Scrum, my favorite resource is Mike Vizdos’s http://www.implementingscrum.com/ site because it not only provides real-world advice for making Scrum work in practice, it does so in a light-hearted manner through the use of cartoons.

Figure 1 depicts the Scrum Construction lifecycle, modified from the lifecycle diagram presented by Jim Highsmith in Agile Software Development Ecosystems (Pearson Education, 2002) showing the fundamentals of the methodology. Scrum teams work from a product backlog, a prioritized stack of requirements maintained by the “product owner” who is responsible for working closely with the team to represent the overall stakeholder community. At the beginning of each “sprint”, a timebox which is suggested to be 30 calendar days but can be any length in practice, the team identifies the requirements that they will implement during that sprint and plans out how they’ll do it. At the beginning of each day throughout the sprint the team gets together for a 15-minute “scrum meeting” where each person indicates what they did yesterday, what they think that they’ll do that day, and whether anything is blocking their progress. At the end of the sprint, the team should have produced a potentially deployable version of the system that they’re developing which now implements the requirements that the team committed to at the beginning of the sprint. A demo is held with relevant stakeholders to obtain feedback and commitment to fund the next sprint. Many Scrum teams, as is the norm with agile teams in general, will hold a retrospective to identify potential improvements to the process that the team is following.

The lifecycle of Figure 1 is reasonable from a high-level point of view, but it leaves out a lot of detail. Scrum doesn’t provide any advice for how to go about actual implementation; that’s a detail that’s left up to you. Nor does the lifecycle indicate how to initiate a project, or deploy your system into production at the end of the lifecycle. Recently Scrum has been touted as a process framework, but as you’ll see a more accurate way to think about it is to view it as one part of the overall process picture. It is definitely a process framework from a consultantware point of view, and we’ve not only seen a consulting industry grow up around Scrum but even an alliance of said consultants. To scale Scrum to meet the real-world needs of IT departments, you must consider the full development lifecycle and consider the full range of IT concerns.