I stumbled across an interesting post, Why “No Issues” Is Not An Acceptable Answer where Derick Bailey describes an "anti-pattern" in Agile team standup meetings. He observes it is a bad indicator for Agile teams when team standup meetings repeatedly result in every team member declaring "no issues." I agree that this condition is common, and less than desirable. But I disagree with Derick's proposed remedies.
Don't Be a Bean Counter in a Creative Process
The readers of this blog don't need to be reminded that software development is a unique, creative undertaking. Developers have to be writers, analysts, problem solvers, and engineers every day. Sometimes they have to be all these things in the span of an hour. That kind of journey is always going to have unexpected issues.
One aspect of Derick's recommendations is to document issues as small as 10 minutes and raise them in the daily standup meeting. I can't think of something that would render a standup more impotent. Everyone who has worked in an Agile environment has experienced the occasional marathon standup meeting. There are well known remedies for these lengthy meetings, but they all boil down to one thing: too much information! Just like you don't need to know the details of your co-worker's skin rash, you also don't need to know that Bob found a solution to his 10 minute unit testing problem. You do need to know that Bob encountered a serious bug in the ORM two days before a major release. If that type of issue is not raised during standup, then you really do have a team problem.
Sometimes in our zeal to improve a process, we pinch pennies. We think that we can squeeze another 2 hours of work out of the average developer per week if we can just get them to raise their daily 10, 20, 30 minute issues during standup meetings. In reality, we would just give that time back when we turn our attention from building software to counting beans. If you really believe you can improve software development productivity by tracking 10 minute issues, you need a different profession. This is software development, not a German train station.
Lightweight Methodologies Are Frameworks, Not Therapists
Derick also recommends, as a rule, requiring every team member to raise at least one issue during standup meetings. Do you know what that outcome will be? Every team member will report one issue during the standup meeting! So where does that get us? Well now our standup meetings are oriented toward following a prescription instead of a tool to raise awareness of real problems. We have just shifted the focus of a standup from raising awareness to process compliance.
If we have a team that is not raising issues properly, then we should not look to our methodology (Agile) to provide the solution. Methodology is a framework. It provides us the tools to do team software development. Dysfunctional teams need help with their specific dysfunction. And sometimes, we perceive a team dysfunction when there really is a team asset.
On a previous Agile project, we found ourselves in one retrospective playing a variation of the popular board game, Apples to Apples. But instead of the game's topics, we were using continuous improvement topics that we generated from our last iteration. The idea to play the game came from an Agile coach who had read about the idea in an Agile self-help book.
Our team was doing relatively well on the project. We had our troubles like any other real-world software team, but we were delivering software at a regular clip. So why were we playing a board game during our retrospective? It was perceived from the outside, that our recent retrospectives were not generating a satisfactory number of issues to discuss. We were not meeting our retrospective quota, so to speak. The board game exercise was designed to elicit more issues since it was supposed to be "fun." The result? We definitely registered more issues for that specific retrospective. Did the game help the team recognize and resolve more real issues? No.
Through the normal course of the project, the team matured and developed good working relationships. As any well-functioning and competent team, we increasingly were attacking and resolving issues as they presented themselves instead of waiting for the next scheduled retrospective. Naturally, each successive retrospective generated fewer issues. This should have been judged exactly what it was, a side effect of a maturing software team. Instead it was considered a dysfunction in need of remedy.
For me, this episode was our jumping the shark methodology moment. We forgot that a methodology like Agile is only a framework. Agile is just a tool, it is not meant to perform therapy on a team.
If you find your standup meetings are not producing value for your team, I would suggest digging a little deeper into the team dynamics. Tweaking your methodology is not the answer. I would leave standup meetings to their original purpose:
1. What did I do yesterday?
2. What will I do today?
3. What is stopping me?
