One of my students recently asked me:
Is Scrum actually useful? Many developers I’ve heard from have had negative experiences with it, and I’m curious about whether it’s more effective in theory than in practice.
My response was long enough that I thought I’d eidt it a bit and share it here.
In order to hear the good news that scrum can save you, you first need to understand the bad news of what it saves you from. That means understanding what work was like “back in the day.” Prior to Jira and other work tracking systems, programmers would just have a list of projects they were working on. Requirements might be on a shared drive somewhere; exactly what projects you were on was kept in your head — likely somewhere from four to ten projects. Most of the time, most of those projects would be blocked needing requirements, blocked needing clarifications, blocked waiting for testing, blocked waiting for operations to give you some permission on a database or something, blocked waiting for someone else to do their piece, and so one. Once a week you’d go to a one-hour meeting per project, which was a “status meeting”, which was really about the status of the manager. That is, ten hours a week in meetings, plus maybe five of travel and prep time. During the meeting you’d tune out, listening to everyone else give their excuses, waiting for the chance to give yours. That is, give your excuse why you didn’t get anything done this week. Hopefully, one of the ten projects you were working on was not actually blocked, and you could make some progress. As you would guess (because math) projects took 10-100 times as long as they conceptually should have and you had a lot of waiting … so managers gave you more work … and projects took longer …
Enter Scrum and Extreme Programming
Scrum and XP asked: Hey there, what if we had an integrated product team that was all actually working on the same thing? If you were blocked, you could just talk to people and get unblocked. You’d lose some efficiency in losing the one hour waiting for operations to grant you access, but you’d get work out 10-100 times faster. Instead of 10 hours of meetings a week, you’d have five standups (1.5 hours), maybe a kickoff for the sprint, a demo and retro – and actually build something every couple of weeks.
Yet Scrum and Extreme Programming actually solved two very different problems. Scrum, at EaselCorp, was created because priorities from management shifted so often. The team made one day of progress only to have an executive pop in and as for something else. At one point, the VP of Software Development went to a quarterly leadership meeting and said that he did not have any progress to report. At all. Sprints were designed to be long enough the team could actually build something.
Extreme Programming, which started at Chrysler, aimed to solve a different problem. At Chrysler at the time, management might order a one-year feasibility study which leading to two years of requirement gathering. After that the software architects would declare the requirements were junk and had to be redone. Two years later the architects might declare design done, ready for code. Somewhere during code, senior management would cancel the project. At that point, the business value delivered would be nothing at all.
In XP, the sprint was called an “iteration”, it left with potentially shippable software, with an expectation of being moved to production (where it could be used by users) at least every three or four iterations. Thus, one of the secret plans of was: We will get our code into production before you can cancel our funding.
Benefits of Scrum
Scrum is a structure that allows the team to self-organize and improve their own velocity – that’s what the standup is for. Unless the team is actually collaborating, the Standup will devolve into just another status meeting. And who needs a status meeting when you can just look at the board of work items? Instead, during the daily scrum (or “standup”), the idea was team members would actually help each other, saying “oh, you are struggling with the SquareCalc module? I worked in it last week, I can help you.” The Daily Scrum should accelerate the sprint, and so should retro.
In my experience, most of the people who dislike Scrum aren’t getting the value out of standup and retro, and haven’t been around enough to understand the Bad Old Days that came before.