A Stand-up about Stand-ups

Today our project managers and development managers reviewed the practice of the stand-up meetings introduced by me into our organization a number of weeks ago. Naturally, we performed this review standing up! Though I'm afraid to say that the review lasted 20 minutes, which is a little too long. But I'm sure Jason Yip won't scold us for it. These are some of my conclusions, drawn from our review:

• There's often not much interaction between our team members. Though many software engineers are known to be "socially challenged", the real problem here is quite different: The eight people in a team are working on maybe five or six continuous projects at the same time, with each small project being handled by one or two people at the most. This makes it difficult to discuss problems, because the others are working on different systems. (With so many one-person-projects an interesting thought would be to let everybody organize their own private one-person stand-ups, but I'm afraid our coffee area will have trouble accommodating such a practice.)
• Our people usually handle and finish a significant number of fine-grained work items (issues and features) in a day. This makes it harder for them to remember what they did yesterday, and to explain what they will be doing today. And most problems are relatively small too, which means they are usually solved before being able to discuss them in the meeting.
• Because of the many different projects, and the rapid flow of work items, our burn charts and task board reports are not easy to handle collectively in these team meetings, and tend to be outdated as soon as we print them. (And I don't think my suggestion to decrease the amount of work and to slow down our development pace will be welcomed in our management team meeting.) Which means that our stand-ups will have to be bent to match our workflow, and not the other way around.

Standard examples and patterns for stand-up meetings assume that all team members are working on one and the same project, and that there is a slow and steady pipeline of large-grained user stories or scenarios. But in our case the team dynamics often resemble that of a support team.

Nevertheless, in our review we concluded that our stand-ups seem to offer enough value to keep them going. Our development managers and project managers simply need to solve the mismatch between the intended purposes of these meetings with our own reality. Basically, this means that, during the day, they need to keep each other informed about all those projects and all those issues, almost in real-time. I was actually glad to hear that the managers told me they usually already know everything that is told by the team members during a stand-up meeting. That's perfect!

A new article by me on the subject of stand-up meetings is now under review by Better Software magazine. I will let you know if and when it gets published.