Scrum, The Good Bits: An Introduction

This is a series of articles discussing the best pieces of Scrum. The pieces you – as a developer or Project Manager – can steal and start using independently of a wider Scrum implementation. We’ll discuss which bits of Scrum you can rip-off without drinking any of the Certified Agile Consultant Kool-Aid – in short, we’ll be looking at how to do Scrum for small teams and startups.

Why Developers hate Scrum

Scrum is a business process, and like any business process, it sits between you and the work you need to get done. If it doesn’t help you get that work done more effectively it’s a big waste of time. Good developers, like everyone else, hate having their time wasted.

Scrum is often implemented by someone who went on a Scrum Master Certification (NOW 90% MORE AGILE™) once, and is attempting to implement it as a set of cargo-cult rituals in the wild hope it’ll make everything better, and more Agile or something. Sometimes this’ll be a Project Manager, and sometimes this’ll be someone billing their consulting time as a Scrum Expert.  Planning sessions become elaborate Arts and Crafts sessions with Post-Its and Sharpies, the Product Backlog becomes time sheets by any other name, and Velocity gets used as a personal productivity measure.

In short, in the wrong hands, Scrum becomes a tool for wasting developer time, and neatly tracking, graphing, and reporting the resulting drop-off in productivity.

Why Developers should love Scrum

This is a huge shame, because done right, Scrum protects and empowers developers. It pushes commercial and business considerations back in to the hands of the business and the customers, while placing implementation decisions back with the developers where it belongs.

Implemented well, it allows developers to track the progress they’re making, helps them to estimate correctly, and to signal upcoming impediments and risks. It gives them a rock-solid answer to “Why isn’t this done yet?” when the answer is “Because we’ve spent the last two weeks fire-fighting” or “Because the CTO came over and told us to redo the UI in Cornflower Blue”.

And most importantly, it gives them the confidence and freedom to know what they’re working on right now is the most important thing they can be working on, and that any open loops – any hidden requirements – have been accurately and adequately captured.

Steal Early, Steal Often

Scrum isn’t all or nothing. It’s a series of interrelated concepts and practices that happen to work well in collaboration. Over the next few weeks, I’ll be looking at specific aspects of Scrum, and looking at how to get the biggest return for the smallest amount of additional process. I’ll be trying to answer the question: What’s the Minimum Viable Scrum Implementation? How can you implement the best bits of Scrum, while avoiding the common pitfalls?

Table of Contents

We start with the Introduction, which you’ve just read, and Daily Standups, linked to below. I’ll be trying to update this every few days – the whole thing started as a gigantic monolithic article which was just getting far too long… If you want to make sure you’ll get the whole thing, you can subscribe using RSS, or via email, using the side-bar to your right.

• An Introduction (this page)
• Daily Standups
• Product Owners, and Customer Collaboration
• Backlogs
• Retrospectives
• Sprints
• Estimation (see: How to Estimate like an Adult – A Developer’s Guide and Estimating like an Adult – What to Steal from Agile…)