Scrum Sucks: Standups

Scrum is a development process; and right there it has already screwed up without having actually done anything. But we'll get to that later.

Today we're going to look at standups which are daily meetings of the development team. I don't even know where to begin. It's like fifty lengths of twenty-year old Christmas tree lights all tangled up into a single ball: where do you begin? Let's recap the purpose of a standup first (as per Wikipedia):

- What have you done since yesterday?
- What are you planning to do today?
- Do you have any problems preventing you from accomplishing your goal?

Ultimately the issue with standups is simple (ie, a waste of time), but let's state three fairly closely related yet distinct failed assumptions:

- I care what you're working on.
- I should care what you're working on.
- My time is well spent listening to you talk about what you're working on.

1. I care what you're working on. If I cared what you were working on, I'd already know what you were working on; and if it affected my work, I'd be in communication with you because (and here's the kicker): I don't suck at my job.

2. I should care what you're working on. I really shouldn't. I should care about successfully (ie, correctly) completing my work. And if we need to communicate, we should be fully capable of initiating and carrying on that communication without the teacher saying, "okay class, let's all do show-and-tell now." I mean seriously ... are we a well-oiled development team or a chaotic bunch of 2nd graders in need of lines so that we know where to draw?

3. My time is well spent listening to you talk about you what you're working on. If this is the case, then you can save a lot of money by terminating my contract because I'm obviously not contributing anything of value. And this next part is lost on so many people: productivity is strongly tied to long, uninterrupted periods of concentration. Scrum dictates that the meetings should be scheduled at the same time every day. What are the chances that each member of the team of 5 - 7 engineers is going to be winding down some piece of development and ready for a nice interruption at the same time every day? And no team of two or more ever arrives at work at the same time. And increasingly team members work remotely which makes it all the more of a joke. Productivity and the _number_ of meetings are inversely proportional. And scrum just bumped up your weekly meeting count by five. The short duration of the meeting just makes it all the more painful. It's worth breaking my concentration to take part in a meaningful three hour meeting. It pisses me off when my concentration is broken for the next hour because we just *had* to talk for a few minutes right this very moment. You want to increase productivity? Stop stopping work to talk about work and just WORK.

I mentioned at the beginning that Scrum failed just by being a development process. And here's the rub. Development is going to continue down its fixed path towards successful completion (or failure) whether or not you spend thirty hours a week estimating, prioritizing and meeting. The process of software development exists because software development occurs. What Scrum (and so many others) feebly attempt to do is articulate and define that process with specificity. Then, with that imperfect translation of the process, it attempts to push itself back onto the process. This results in garbage. Ever played "telephone" in grade school? Or done an English-Chinese-English translation of some text? Same thing. Without detrimental outside factors, the fate of a project is a function of its complexity and the competence of its engineers. That's it.

Problems occur in software development, and those problems require solutions. And this is my final point: process is not a solution. I wish I could paint that in the sky and force it onto televisions everywhere. If (assuming no other mitigating factors, like drinking-and-coding) Joe does X which causes problem Y, the correct solution is _not_ to define a process such that in doing X you tend not to cause Y, the correct solution is to train Joe. This is why you tend to pay more for those people who tout "senior" in their job titles. And this is how you avoid becoming a fifty-year old company that encourages new hires to read the three-freakin'-thousand page tome on "the software development process at company z".

So when is process a good thing? When the level of understanding of the people involved in a task is insufficient to accomplish the task. You force communication and general interaction. You define roles. You enforce responsibility for tasks. You give them lines to draw in. Your task is still going to fail, but at least it'll be an organized failure.