Dr. Dobb's Journal - May 2008 - (Page 52)

d05ambler_p5as 3/13/08 8:19 AM Page 52 The Agile Edge by Scott W. Ambler Scaling Scrum Meeting real-world development needs SCRUM IS AN AGILE methodology that focuses on a subset of project management and requirements management. 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 (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. The Full Development Picture Construction is only one part of the overall software development lifecycle. Figure 2 presents an overview diagram of the Agile lifecycle which encompasses the ideas presented in Figure 1 and extends them to address the full range of software development issues. This lifecycle explicitly includes the concept of phases because the activities that you perform do in fact change throughout the span of a project. I’ve adopted the normalized terminology described in the sidebar plus other common agile phase terminology—many agile teams refer to project initiation effort as “iteration 0” and transition as the release phase. In the Eclipse Way, the Agile process followed by the Eclipse development team, they use the terms “warm up” and “end game” respectively. In Agile and Iterative Development (Addison Wesley, 2004), Craig Larman uses the terms “pre-game” and “release” for these phases. The Open Unified Process (OpenUP) uses the terms Inception and Transition respectively. Sadly, many people consider the concept of phases to be antithetical to agility, yet in practice they seem to be a fundamental lifecycle concept. Figure 2 encompasses several critical activities to scale Scrum to meet your real-world development needs: Figure 1: The Scrum Construction Lifecycle. Deliver a potentially shippable system every 30-day sprint. 52 Dr. Dobb’s Journal l www.ddj.com l May 2008 http://www.scrumalliance.org http://www.implementingscrum.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - May 2008

Dr. Dobb's Journal - May 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Software Development Goes to the Movies Cat: A Functional Stack-Based Little Language Mojax: Mobile Ajax Framework Kernel-Mode Databases Getting Better Search Results Effective Concurrency The Agile Edge

Dr. Dobb's Journal - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.