An interesting read. It sounds like he’s definitely on a team where “Scrum” actually means “Daily Status Meeting” and if so, then I totally sympathize. Lots of scrum meetings I’ve been involved with turn into glorified status meetings and they suck. No one wants to stand up in front of your peers and say “yesterday, I spent 8 hours trying to figure out why we have serialization problems involving WCF RESTful web services and mobile technology clients. Oh and I’ll probably do it for 8 more hours today because I can’t really say when I’m going to be done.” That’s frustrating. But in reality, things like that happen all the time on projects. In fact, they should probably be expected.
If you have a good team, scrum should basically boil down to “do you have any blocks?” When management starts using the daily scrum to micromanage progress, the benefits have been lost. When scrum is a painful task to be completed each day, nothing good comes out of it. The problem is, the benefits of scrum are rarely described and elucidated to the team. Scrum should be a way to make sure nothing stands in the way of progress but it definitely should not be daily proof that progress has happened in the last 24 hours. Progress in software is much like punctuated equilibrium in evolution, i.e. there are large periods where nothing is happening followed by times of extreme productivity. If management expects the same steady constant progress throughout a sprint, I think they are confused about how software gets done. Of course, if we’re talking about management and not Scrumasters or Product Owners or Users, chances are the environment is such that the process is already broken long before daily scrum kicks off.
The Daily Palliative: Lucky To Be A Programmer