I’ve worked on many software projects over many years. A few of them went on to become billion dollar businesses and some of them never shipped. Some of them shipped after a great deal of pain and suffering. I learned a few things about software development processes that work and don’t.
Scrum doesn’t work.
I’m sure the Certified Scrum Masters will be quick to point out that I must have done Scrum incorrectly or somehow did not follow through with the methodology, and I’ll say that’s exactly why it doesn’t work: A whole industry of people who walk around to talk your ear off about Scrum and why it’s the best thing since the silicon wafer.
Here’s what I know to work:
- Generate a strong product vision.
- Hire the most talented software engineers.
- Make sure they understand #1 and let them build it.
Scrum aims to provide a safety net in case you fail to do any or all those 3 steps. Here’s the problem: you will not be successful unless you succeed at all 3 steps.
Scrum states that we can change the goals and vision based on lessons learned during the iteration. In practice, this leads to leaders with no vested interest in achieving audacious goals. “Oh, it didn’t work. Let’s try something else.” How are we going to get Teleportation with that attitude?
Scrum assumes that you can calculate your team’s velocity based on historical data and therefore predict your ability to deliver. This assumes that any slug that grows arms can write so many lines of code in an “ideal day.” It marginalizes talented software developers who don’t need to be forced to determine how many “story points” there are in their work. How many story points do you think transporting a kilogram of carbon across an ethernet cable would be worth? How many story points to do it wireless?
Scrum lets you review the work completed during an iteration and choose to continue pursuing missed goals or decide to pull something else off the backlog. Sounds great, right? In practice, this just hides incompetence and frustrates strong engineers. The lame engineers will come with lame backlog items and burn down to zero every time. The strong engineers will aim for the moon, and sometimes fail, and get shafted because they did not achieve the stated goals for the iteration. They’ll eventually leave.
I’d like to hear your thoughts on this, as I’ve seen Scrum spread throughout Silicon Valley like a locust plague. If you’ve adopted Scrum in your team, I’d like to hear about it:
- Was the product any good?
- Was it worse/better before you started Scrum?
- Did you ship on time?
- Was your team happy doing it?
