I recently read a brilliant article on the myth that Scrum is faster and cheaper than traditional development. I highly recommend reading it, and no, I’m not affiliated with the writer or Scrum.org!
The article articulated something I feel is poorly understood. Following the ceremonies, roles and artifacts of Scrum is not a faster way of developing software. In fact, I am fairly certain that if you had two similar teams, gave them the same large specification and had one team develop to that specification using two week increments and the other using a waterfall approach, the second team would finish earlier. Why? (I’ll explain the underlining below)
First, Scrum has a lot of short term planning overhead. Daily stand ups, sprint planning, sprint reviews, refinement meetings and so on take up a lot of developers’ time. It is the most common complaint I hear from developers using Scrum. They’re fed up of the meetings, and almost every retrospective has at least one discussion about how to reduce the length or frequency of these meetings.
Second, delivering incrementally, where you have a shippable product every 2 weeks, also adds overhead. Branching, merging, building, integrating, regression testing, demonstrating and then incorporating feedback all take time. It reduces risk, but the price is more time invested throughout the project.
Third, refactoring is expected to be part of almost every story or task. Every time a developer touches a piece of code she is expected to leave it in better shape than when she found it. This is one of the pillars of Agile. It’s even been referred to as a law of Nature rather than a rule. The idea is that the best architectures are made with a small amount (relative to traditional development) of upfront planning and regular refactoring. While this results in a faster time to deliver working software and over time to better quality code, it can mean some requirements and features need additional time to develop.
So where does this misconception come from? I’ll resist the temptation to blame it on consultants and evangelists anxious to sell the potential benefits. I think it comes from the perspective most people start from when they look at Agile and Scrum.
Let’s explain what I underlined above. Those two teams I mentioned earlier would certainly deliver different solutions. If the Scrum team is allowed to self-organize and deviate from the specification based on feedback and interactions with the customers, the solution is more likely to deliver what is needed and nothing more. This is part of the efficiency of Scrum and Agile – finding “just enough” and focusing on delivering the most value. If, on the other hand, you’re measuring speed by delivering to specification, Scrum and iterative development are most likely not faster.
Headlines and titles like “Software in 30 days” and “The art of doing twice the work in half the time” may be interpreted differently by someone who has been managing projects and programs using a traditional stage-gate process for many years than someone who has experience in iterative and incremental development.
If you believe strongly that the output of your analysis and design phases is an exact definition of what the customers need, then you will read the above as “How to code my specification in 30 days,” which is not what Scrum or Agile deliver.
On the other hand, if you’re familiar with Agile and Scrum, you read the above as “How to focus on value and get a return on your investment as early as possible.” Stephanie Ockerman summarizes it as delivering value and quality, reducing waste, and providing the flexibility to change where to invest frequently.
In my mind this is the most important message Agile coaches and Scrum Masters need to communicate. Scrum and Agile are efficient when progress is measured in value delivered in the resulting software, not when measured against delivering against a specification.