? 08, 2008
Scaling ScrumMeeting real-world development needsScott W. Ambler
Scrum
is an agile methodology that focuses on a subset of project management
and requirements management. But some organizations are finding it can
be a challenge to scale Scrum to meet the complexities of their
real-world environments.
Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www./scottAmbler.html.
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 (www.scrumalliance.org). Although there is a lot of material available online and in books about Scrum, my favorite resource is Mike Vizdos‘s 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 cottage industry grow up around Scrum but even an alliance of said consultants. I‘ve found that 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.
[Click image to view at full size]
|
|