I just recently completed a three-day SCRUM training class, and I have to say that I quite enjoyed it. Normally, the thought of sitting in a chair listening to a corporate trainer for several days in a row fills me with dread, regardless of the quality of cookies and snacks provided; the little participatory exercises feel entirely contrived and artificial. Frankly, I went into the class somewhat skeptical of Scrum ...
But this class turned out to be very high quality and valuable. The presenter, Kenny Rubin of Innolution, a certified Scrum Trainer of the Scrum Alliance, was knowledgeable, informative and interesting; most important, he has enough experience with software development practices and teams to be able to give it a real-world flavor.
That is, the dogma of "the Scrum way" was tempered by the realities of professional software development. (Those of you working on a real-life software development project day to day, or managing software developers, know what I mean - my 20+ years of industry experience have taught me that most software projects are understaffed, have too many requirements, ultra-aggressive deadlines, and repeated requirements changes; it's a wonder we deliver anything at all!)
SDLC: New and Improved with Scrum!SDLC - the Software Development LifeCycle - is not a new concept. I was first introduced to the concept during my graduate software engineering class at UCSB during the late 80s - by Prof. Richard Kemmerer, he of the red hair and temper to match. (The UCSB of the time was one of the many hotbeds of a radical new movement called the "Free Software Foundation", but that's another story!). The good Professor had lots of industry experience and tried to explain to us the myriad challenges of building and maintaining large-scale software in teams, so very different from the limited computer science coding assignments which we could simply turn in and forget.
A key exercise in the class was to compare the then-prevalent Waterfall model of software development, with Barry Boehm's new Spiral model; the latter was clearly superior in terms of dealing with the uncertainty of changing requirements. This was in the late 80s; since then, I've seen countless new software processes and programming models come and go: Structured, Functional, Object-oriented, Booch, Rumbaugh, Jacobson, Coad, Yourdon, followed in the 90s by UML, Pair Programming, XP, and then in the 2000s, Lean, Agile, and so on. After seeing so many "great new thing" theories come and go, it's hard to take the flavor du jour too seriously.
After looking at the Scrum process though, I'm optimistic that it is likely to have greater staying power than some of the earlier short-lived fads. Scrum seems to recognize reality a bit more than some of the other recent processes that have generated buzz [e.g. putting two developers on creating a single piece of code when only one will do - is that model going to take over the world? Really?]; Scrum attempts to include this reality into the flow rather than trying to bend it to an artificial process.
Another advantage is that Scrum tries to take out-sourcing and off-shoring into account - relatively recent trends that are likely to continue to grow. Finally, Scrum borrows heavily from the models and processes that came before: not just Lean and Agile, but even earlier. The iterative sprints approach of Scrum is conceptually remarkably similar to Boehm's spiral model, isn't it?
At the same time, there are some glaring deficiencies in the Scrum model that will need to be addressed.
Scrum Process: Key Points
Having been through the official Scrum training, I will highlight the key points of the Scrum process in this section.
The overall Scrum process definition is broken into Activities, Roles and Artifacts. (A canonical place for definitions is Mike Kohn's Mountain Goat Software web site: Introduction to Scrum. )
Scrum is an agile process that relies heavily on specific, prescribed activities. Since development is organized as a series of sprints, scrum specifies a set of activities that are repeated for each one.
Sprint Planning Meeting: Figuring out which of the high-priority product backlog items can fit into the next sprint.
Daily Scrum Meeting: A quick daily meeting during which team members share their activities for the past day, planned activities for that day, and identify any impediments to progress.
Sprint Review: Conducted at the end of a sprint, this meeting provides an opportunity to demonstrate the functionality added during the sprint, displaying it to product owners, users and stakeholders.
Sprint Retrospective: The whole team participates in this meeting, which is an opportunity to reflect on a sprint that is ending and opportunities to improve for the next sprint.
Overview Image: (c) Mountain Goat software
Different members of the team are assigned specific roles in a Scrum process; these roles prescribe specific behaviors and tasks for the team members.
Scrum Master: The Scrum master is the team's coach, and is essentially a facilitator rather than a project manager or line manager. The main role of the scrum master is to remove project impediments that affect the team, and provide coaching about the process, enabling the individual sprints and meetings to go smoothly.
Product Owner: The product owner comes up with a vision for the product, and translates it into a prioritized set of features required in the product (the product backlog, in Scrum parlance). The product owner answers questions about the requirements and helps the team make trade-offs between different options.
The team: The team as a whole is the central player in the Scrum process. Each person contributes in whichever way they can to complete the work of each sprint.
Scrum defines various artifacts that are used at different stages in the process.
Product Backlog: The product backlog is a prioritized list of "user stories" that, taken together, define the functionality that remains to be added to the product.
Sprint Backlog: The sprint backlog is much more limited in scope than the product backlog; it's a list of tasks the team needs to perform in order to deliver the functionality committed to for that sprint.
Release Burndown Chart: This chart shows the amount of work remaining in the release. Similarly, a sprint burndown chart shows the amount of work remaining in the sprint. These charts provide a visual indication of progress towards completion of the project.
One of the key takeaways for Scrum, is the focus on a unified, cross-functional, empowered Scrum Team. This team includes software developers, testers and web designers, as well as the product owner and scrum master; in short, everyone required to specify, build and test the product. And this team is both empowered to make decisions with regard to scope, schedule, features and resources, as well as held responsible for the results. An interesting concept!
And what of those shortcomings of Scrum that I alluded to earlier? Those will follow in a future post. Stay tuned ...
[Note: some of the material for the training class referenced above was licensed from Mike Cohn of Moutain Goat Software.]