A while ago I started working with a team that had stopped having “standup” meetings altogether. Initially, the team started with the typical daily team meetings. After a little while they moved from having daily meetings to having them only three times a week. Subsequently they went to just once a week. When I asked why they had decreased the frequency of their meetings, and then ultimately stopped having them altogether, I was told that no one thought they were very useful and some of the team members had already stopped attending.
At one level, I applauded this team – they had taken one of the Lean Principles to heart, that of “Eliminating Waste.” Their attempts at having daily standup meetings weren’t providing any value, so they just stopped having them. However, at another level, I faulted this team. They held daily standup meetings because that’s what they thought they were supposed to do since they were now calling themselves “agile.” In essence, they had adopted a practice without understanding why they were adopting it, nor did they understand what benefit the practice was meant to provide.
What I have found in my years of coaching teams is that when teams reduce the frequency of the daily team meetings (or eliminate them altogether) it’s usually because the meeting has become just a status meeting. And, seriously, who wants to spend time every day reporting status as well as listening to others report status…? What you typically hear in such meetings are things like, “I’m doing the same thing today as I did yesterday,” “I’m still working on my code,” “I’m still finding defects,” and so on. Ugghhhh – what a waste.
So, if it’s not to report status, then what’s the purpose of the daily standup meeting? It’s meant to be a coordination and communication meeting for the team. And this type of meeting is very important. However, there are a couple of other things to cover first before I can show how the daily standup will be valuable – instead of daily waste of time.
Leslie and I recommend that, as much as possible, a team should be working together on one user story at a time. Additionally, the work items that team members tackle as part of implementing a user story (typically called “tasks”) should be small in size (a day or two at most). This means that small amounts of needed design, coding, testing, user documentation, automation, and so forth are being completed on a daily basis. For example, a developer could complete a coding task and, as soon as the build finishes, a tester can start running tests against that code. Thus there is a lot of “parallelization” taking place every day within the team. Perhaps you can now begin to see how important regular (daily) team communication is in such an environment. Conversely, you can see how the daily team meeting devolves quickly into a status meeting if everyone is working on their own thing and there’s no shared goal for the team.
By working together on one user story at a time, and using small tasks to accomplish work, the daily team meeting becomes a meeting that you don’t want to miss because you’ll likely miss something critical to the work the team is focused on.