While I was working at Intuit, a developer asked me what was next, after Scrum. He related that Intuit had built its own waterfall methodology. Then Inuit bought a commercial methodology. Then it moved to RUP. Then it built its own Agile process. Inuit was now using Scrum. What did I think that Intuit would use next? I pointed out that what Intuit used next did not matter. The point of Scrum was to become a world-class engineering organization, not a consumer of methodologies and processes. If Intuit didn’t improve its software development practices, it actually didn’t matter what methodology it used next.
I’ve noticed that many developers and managers view Scrum as the next methodology to endure. While enduring Scrum, they continue doing the same things they always have done, just to get the job done.
People often don’t view Scrum as a tool they can use to become Agile. They view Scrum as another methodology that they have to layer over their real, unchanging work. Getting a release out the door is all that counts. This approach is simple, because no real change is required. Unfortunately, none of the anticipated benefits accrue.
I’ve gathered some examples of how people try to layer a new process over their old way of working.
Example 1: I attended a retrospective. The room was dark. The Scrum Master was projecting the “retrospective” form from Version One on the front wall. Team members called out things they liked or didn’t like from the last Sprint. The Scrum Master typed them into the form. When enough entries had been made, the meeting ended. I asked why they were recording the likes and dislikes. The Scrum Master said that Version One had a form for this, so it must be important.
Example 2: I attended a Sprint Planning meeting. It was abbreviated to one hour. The previous week, the Scrum Master assigned Product Backlog items to each Team. Each Team member decomposed his or her Product Backlog items into tasks. The Sprint Planning meeting consisted of the Team playing planning poker to estimate the tasks. They were then uploaded into Jira as the Sprint Backlog. This fascinated me. I knew the entire Scrum Team would estimate Product Backlog items. However, the idea that everyone else on the Team would estimate how long it would take for you to do your task was inappropriate.
Example 3: At another Sprint Planning meeting, the Product Owner reviewed the releases’ remaining Product Backlog. She and the Team then calculated the number of Product Backlog items (PBIs) remaining. The Team would have to complete that many each Sprint to be done by the release date. The Team then committed to do that many PBIs for the upcoming Sprint. Since the number of PBIs was greater than what the Team could fully complete in a Sprint, the Team planned to reduce the definition of “done.” This allowed them to finish all the required PBIs. No one discussed when the “undone” work from each Sprint would be done.
Culture persists. We’ve spent years developing habits that allow us to cope with waterfall. We are now using the same habits to cope with Scrum.