The daily standup, long one of Agile’s trademark ceremonies, seems to have been coming under fire lately.
Erik Meijer, in his provocative presentation at Reaktor Dev Day 2014, declared: “enough of the standup meetings—just write code.” Now, if the daily standup were a cornerstone of product development teams, we would vigorously leap to its defense; but we’re not talking about our right to free speech here. What’s being attacked is just a small ceremony, viewed as iconic only by those who don’t understand it.
The Canary in the Coal Mine
The daily standup can be a very useful tool for those who work closely together (most Agile teams fall into this category.) A successful standup can align teams around a shared purpose, uncover problems proactively, and promote shared learning. However, like a canary in a coal mine, the daily standup can be an early sign of hazardous conditions.
Let's assume there’s no such thing as best practices—only good practices in context. In that case, if a daily standup is wasteful, then the team should stop doing it. That said, if developers aren't interested in each other and checking alignment against shared goals is this really a team? If spending 15 minutes at the start of the day to speak to each other is seen as a terrible interruption, then haven’t we self-organized ourselves into the trap of measuring the workers, rather than the work product?
As a coach I observe a lot of daily standups. Yet it was a standup to which I wasn't invited that left the strongest impression on me.
I was the first patient of the day in my doctor's office, on a day when I was scheduled to have minor surgery. I was feeling nervous, thinking about entrusting my health to people I barely knew. As I sat in the waiting room, then, it was a surprise (and a relief) to see the doctors and nurses on the team begin their day with a brief standup.
The Fundamental Attribution Error
Erik Meijer tells us that Agile is a cancer, and that we should leave developers alone so they can get their work done.
I started my career as a developer, working on some very large and challenging systems. For some years I worked on compiler development; later I progressed to developing air traffic control systems. Air traffic control systems are very complex: there are a lot of interrelated subsystems that need to be integrated, and as you can imagine, quality is imperative. Brian was one of our subsytem leads and nobody would say his job was trivial. However, his biggest problem wasn't technical; his biggest problem was Tim.
Brian’s subsystem depended on components being delivered by Tim. Tim was a gifted programmer, but he wasn't a great teammate. All his variable names were two characters. Nobody but Tim could understand his code and fix it—especially not Brian, a big problem as fixing Tim's code was exactly what Brian needed to do when none of that code met requirements. (Tim knew the requirements: he just felt he knew better than our product owner, Gary, what the customer needed.) In making this assumption, Tim was making a fundamental attribution error: he was assuming that our users were like him, when in fact they were not.
Brian was behind with his deliverables, and was coming under increased pressure. Our program manager asked me to help remove the impediment. I’d like to say that I was able to turn Tim into a better teammate to Brian, but that’s a footnote for another story. Removing the impediment meant moving Tim to another project and completely rewriting his subsystem code.
As I listened to Erik Meijer rail against Agile, I couldn't help but be reminded of Tim. Erik is not the first person to criticize Agile, and he certainly won’t be the last. But to call Agile a cancer makes the fundamental attribution error of assuming that everyone has the same problems he does.
Stop Searching Under Streetlamps
One of the popular games we use in our Lean training is The Penny Game. The main learning objective of the game is for participants to experience the benefits of batch-size reduction. This game also surfaces the importance of systems thinking, as the real benefits are realised through looking at the whole rather than optimising the parts.
Traditional cause-and-effect approaches to improvement would seek to find best practices, and then to send all the developers to training to improve their productivity. After playing the Penny Game we can dismiss this approach as myopic, yet in the real world this flawed thinking prevails. Like the story of the drunk who looks for the lost keys under the streetlamp, we often focus where the light is shining—not where where we actually let things drop.
Agile isn't a cancer but a magnifying glass that brings focus to our work. Before you quit doing standups, you might want to try looking for your keys where you dropped them.