Scrum is a leading agile software development process. In coordination with the recently published Scrum RefCard, DZone had the opportunity to chat with Michael James, a software process mentor, team coach, and Scrum trainer, about Scrum and some of it's benefits.
DZone: What is Scrum?
Michael: From the business perspective, Scrum is an agreement with the development team to build a potentially-shippable product every iteration, so high-value features can be ready for customer use first. It's a simple framework for risky, complex work, particularly new product development.
From the developer perspective, Scrum is an opportunity for a more rewarding job, working on a small, cross-functional, self organizing team without being micromanaged by people who don't understand our craft.
Spend a couple minutes with the RefCard for a more thorough definition.
DZone: You mention that Scrum's management practices are similar to XP, but that Scrum doesn not prescribe specific engineering practices. Does this mean Scrum is primarily a project management process framework?
Michael: Yes. Scrum is agnostic about the type of product. It wouldn't even have to be software, though it usually has been so far.
DZone: Is it useful to leverage Scrum's management practices in conjunction with XP's engineering practices?
Michael: Yes. Getting good at Scrum for software development usually requires learning new engineering practices. Scrum's retrospective mechanism and ever increasing definition of "done" provide a force for incremental process improvement. This has been used to introduce XP engineering practices.
DZone: The Daily Scrum is held daily, but it's only 15 minutes. When and how should the team deal with complex issues that arise out of this daily discussion?
Michael: An underlying purpose of the daily Scrum is to get the team in the habit of being accountable to itself each day, breaking down psychological barriers that might impede self organization. It's not intended to be the *only* time we talk to each other.
DZone: A Scrum iteration is called a Sprint. How long would a typical Sprint last?
Michael: Ken Schwaber's first books suggested 30 days, which is now considered a maximum length. In most cases I prefer two weeks. At the end of two weeks, we stop and take measurements so we make more informed decisions about the next two weeks.
DZone: Are shorter Sprints necessarily better than longer Sprints? Or does it not matter?
Michael: There's a few theories about why two weeks works better for many teams: reduced waste, ability for the business to respond faster, lower probability the Sprint will be interrupted. Based on my experience, it just seems to "fit" better. The important thing is to keep it constant so the team gets into a rhythm.
DZone: Do Scrum's cross-functional feature teams discourage technical excellence?
Michael: The best way I know to encourage technical excellence is to lead by example, closely collaborating with people I'm mentoring using techniques such as pair programming. Scrum shifts the emphasis from individual performance to team performance. People who are technically strong have more reasons to act as mentors in this environment.
DZone: The Refcard doesn't discuss metrics. What measurements and metrics do Scrum teams find valuable?
Michael: Instead of traditional metrics and milestones, Scrum teams use tools like the Sprint burndown chart (for their internal self organization) and the converging release burndown chart for keeping release expectations aligned with empirical measurements. These are summarized in the "Artifacts" section of the RefCard. More details are available in a short paper I wrote called "Macromeasurements." And Mike Cohn wrote a whole book called _Agile Estimation and Planning_.
DZone: Can you describe how Scrum might scale for large development teams?
Michael: Large scale product development has become very interesting to me because most organizations do it so badly almost any change would be an improvement. Large projects fail even more often than software projects in general. It's interesting to walk into a building that has hundreds of very busy people, yet can't get *any* product out the door. Typically only a few of those people are working on the high-value features at any given moment, and they are hampered by some combination of bureaucracy and anarchy.
Scrum scales best when we turn the traditional silos sideways, so each team spans disciplines, or even hardware components. See the RefCard for specifics based on what I've seen work and not work. There's a few books about this now, but the one I recommend is _Scaling Lean & Agile Development_ by Craig Larman and Bas Vodde.
DZone: The value of technical certifications have been under fire recently. What are your thoughts on ScrumMaster certification?
Michael: This has been controversial in the agile world also. The first level of Scrum certification, the CSM, does not prove any kind of proficiency at
Scrum, only that one was trained by someone who's been vetted by Ken Schwaber or the Scrum Alliance.
This month we had to clean up messes at two different clients made by unqualified trainers who also happened to not be certified by the Scrum Alliance. So while I'd like the Scrum Alliance to beef up its process for certifying trainers, I think it does add some value by screening out the totally incompetent ones like this.
The CSM class itself is the best way I know to learn about Scrum, saving our clients a lot of time and money stumbling over common misconceptions. People looking for a more meaningful certificate can use the CSM as a stepping stone toward Certified Scrum Practitioner (CSP), an indication of at least one year of experience doing Scrum.
DZone: Thank you, Michael, for taking the time to chat today.
Michael: Thanks for giving me the chance to answer these questions.