I Was Wrong About Scrum, Again
So, I was reading the Scrum Guide the other day, since that’s the kind of guy I am. I am always on the lookout for something that I can quote, that a Scrum guru can’t explain away with magical logic. I haven’t found anything yet, but I haven’t given up.
First, I pointed out that sprints are problematic because they always repeat back-to-back. They don’t give you a break, and they stress people out. But Scrum advocates were quick to point me to the concept of “sustainable pace.” I guess if I understood that, I could do sprints forever, without a break, and never get tired. Sounds amazing. But I was left wondering why the obvious solution wasn’t acceptable: just taking breaks. Oh well. They know better than me.
Next, I pointed out that daily stand-ups are difficult because they make you feel like you have to justify your work every day, even when you happen to not make any progress. But my Scrum friends reminded me that stand-ups were never supposed to be status reports. They said that an evil elf named Yesterday-today-no-blockers McIntyre spread that lie around the industry long ago, and people have been confused ever since. I guess Mr. McIntyre was pretty influential because he seems to have gotten to every Scrum Master I’ve ever met. I wonder why he is still invited to all the Scrum conferences?
Then I told them that software estimation is problematic. No matter how hard I try, I can’t seem to figure out how long a task is going to take until I’ve gotten my hands dirty and written at least a little bit of code. But the Scrum gurus just scoffed. Scrum doesn’t do estimation; it does sizing, and you should never use time when you are doing sizing. I had no idea there was a difference! When you do sizing, you pick a barnyard animal that best describes the way you feel about your task (I always pick an ass). Then you put all those animals into the magical Jira machine and turn the crank—out pops burn-up, burn-down, (burn-it-all-down?) charts. No estimation needed. So, I was wrong again. They’ve got it all figured out.
Finally, I mentioned the issues I’ve had with giving Product Owners full control of the work. I explained that it doesn’t give developers a seat at the table or treat them like equal stakeholders. They just end up being ticket-takers. It also makes it hard to get approval for any work that doesn’t look like progress to the non-technical Product Owner: planning, refactoring, researching, training, etc. But they got me again. I am so stupid! They reminded me that no Product Owner would ever be so shortsighted. In general, Product Owners are like Santa Claus and think of developers as the children they watch over all year long. They have no other interests in mind. And if ever there was a bad egg Product Owner, the organization would fire them immediately. Because the last thing any organization would want is for developer needs to be ignored (that is why they picked Scrum in the first place! Duh!).
So, they assured me that all developers are in perfectly good hands. That’s why it’s totally OK for the Scrum Guide to give them unilateral, unchecked power over creating and prioritizing all the engineering work.
It turns out that my worry about Product Owners not being technical is not a big deal either. I was assured that everything anyone needs to know about building software is covered very thoroughly in the three-day Scrum certification training that Scrum Masters and Product Owners attend. Thank goodness.
Here, I thought I had found the four core elements of Scrum, straight from the Scrum Guide—the official document from Scrum.org—that were causing problems in the software teams I have been a part of. I thought there wasn’t any way someone could say, “you’re doing it wrong.” But, yet again, I ended up with egg on my face. Because, of course, yet again, I am doing it wrong. No matter how many times I read that guide, I just can’t seem to get its pure meaning through my thick developer skull.
But for those of you that have had the same “pretend” problems with Scrum as me, issues that you could have sworn were making life hard—even though it is just because you haven’t been able to fully internalize the glorious revelations of Sutherland and Schwaber yet—here are four articles that can help you fix the already perfect process your boss and Scrum Master are calling Scrum, that isn’t even close to the beautiful, pure, real Scrum that no one has actually managed to implement yet.
It is kind of funny that Scrum believers (let's be honest, it is kind of a religion with its ceremonies and sh*t without evidence that they work at all) defend Scrum with the typical "It is not real [put-your-cult]" logic.
No one cares what you call it, as long as you write good, well documented, testable code, collaborate with team mates, negotiate the product features with the owner, and architect and rearchitect when needed.