At a networking event, the conversation landed on the benefits of using Agile Scrum. One person volunteered that projects got done faster using scrum. I suppose it’s possible in certain circumstances, but I immediately labeled him as someone who doesn’t really know scrum. Terribly judgmental, aren’t I?
I would sooner say that projects fail faster using scrum. In a six month waterfall-style project, the customer sees the software demo at the end of the six months. Using scrum, the customer sees the software demo at the end of every sprint. If the product isn’t meeting requirements, better to find out after two weeks than six months.
The total elapsed time is probably still six months, but the result is better because of course corrections made every two weeks. In fact, the Scrum project might actually take longer because it allows the customer to say things like, “I know that’s what I asked for, but now that I see it, here’s what I really want.” Scrum allows the dev team to say, ” Okay, it will take two more sprints to make that change, is that an acceptable delay?”
As the conversation went on, I found myself advocating for scrum in a way that surprised me. It seems I’ve developed some passion for it! I didn’t say things entirely correctly that night, but this blog gives me an opportunity to tidy up.
In my experience, Scrum naturally does two things that I as an engineering leader very much like:
- Accountability. It brings together people from different disciplines to vet each others’ ideas, write user stories, estimate tasks, and commit to a plan each sprint. They are collaborating as a team in a way that individual accountability is implicit. If someone is struggling to pull their weight, it is very obvious very quickly.
- Predictability. It forces people to make estimates and commit to a certain number of points in each sprint. Over the course of just three sprints, a team settles into a stable velocity. Suddenly, anything that can be estimated with points (yes, some people use hours instead of points, gasp) can have a predictable finish line. Of course, the bigger the project the larger the margin of error in the estimate, but predictability is essential for proper resource planning and managing expectations.
You’ll notice that both of these things are measurable. I track the ratio of (points completed) / (points planned) to hold teams accountable. And I use velocity to validate or invalidate what can be delivered within a certain timeframe. That’s maybe a third thing I like – the measure-ability!
Alright, nothing earth shattering here. I’m sure some can quickly name 10 things I’ve neglected to mention. This is just what works for me as a manager and leader!