Scrum—not Shrek

Last week, I mentioned that Scrum has worked well for our application developers—so much so that our requirements team is now working to adopt Scrum. If you thought Scrum was a coding methodology, you are now scratching your head. That's okay, before becoming a certified master of the thing, I was equally as confused.

Scrum is a project management methodology that can be applied to any business process that requires a team of people to work together to deliver something tangible.

At Decade, Scrum is used to manage product development using iterative, incremental practices. However, Scrum does not dictate which engineering practices must be used.

The confusion comes from the fact that so many Agile shops have adopted Scrum, and this is because Scrum is built upon many of the same values supported by the Agile software processes, such as:

• Individuals and interactions are valued over processes and tools.
• Working software is valued over comprehensive documentation.
• Customer collaboration is valued over contract negotiation.
• Responding to change is valued over following a plan.

Likewise, many Scrum principles are embraced by the Agile Community:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Scrum processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

Scrum also has some unique characteristics and practices:

• Three basic roles: Product Owner, ScrumMaster, and Project Team
• Product Backlog
• Sprint Backlog
• Sprint Planning Meeting
• Daily Scrum Meeting
• Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration
• Sprint Reviews
• Retrospectives

First and foremost, Scrum uses an adaptive, empirical process—meaning that the approach demands flexibility and adaptability. Each project is different; that is why this approach must adapt to each project’s needs and provide for increased productivity and reduced time to market.

For more information, visit the team at Controlled Chaos. Now matter what you have to deliver, I highly recommend you consider adopting at least some of these proven principals. You'll wish you had done so sooner.