Mark Campbell
Ruby Enthusiast
Winnipeg, Canada
[email protected]
I realized the other day that my daily stand-ups (no, not stand-up comedians) with my team are becoming more and more important as time goes on. The reason for this is because what we're communicating to each other is the bits of hard-won knowledge from the previous day.
When my teammate is telling me what he did yesterday, what he solved, how he solved it and what trouble he's having, it's one of the most improtant conversations of the day. The pieces of knowledge that he's extracted from his hours of work yesterday is free knowledge that I can and will probably have to use to solve problems today or tomorrow.
Within a company, there's a division of labour that arises as the company grows. We have a few teams at theScore – the first of which that comes to mind to me is the division between the writers (who write great content like this article covering Adrian Peterson's son) and the nerds (read: developers). As a developer, I do not need to know what the writers at the company are doing and vice versa.
There are further divisions within the developers (shocking, I know). We have the following teams:
Each team has their own stand-up. Generally, there isn't crossover between these teams. As a member of the Core team, my duties are significantly different from, say, the Android team. The day-to-day activities that they partake in are of little concern to me.
In contrast to that, I do need to know about what my teammates are doing. Being able to pick up on other people's work and increasing the bus factor on components of our architecture results in greater [velocity](http://en.wikipedia.org/wiki/Velocity_(software_development).
I have a few things that I like to keep in mind:
Specificity is one of the most important pieces of someone saying their stand-up bit.
Don't be too specific: I don't need to know minutiae. Being too specific means that I stop listening or that the ideas you're trying to explain will get lost in the details.
Don't be too broad: tell me the interesting, technical parts that won't be obvious later so that I can make notes of it. A side effect of this is the fact that if this information is present in your issue tracker on the specific issue, then it should probably go in there.
Standups are more than "I worked on 'foo' yesterday, going to work on 'bar' today". If I wanted to know just what you were working on, then I would consult the issue tracker for that. I want the meaty details! The more you can explain, the better I'll be able to do my job and the better you'll understand the problem itself when you have to vocalize it. Which leads into…
Each person's bit should ideally be one to two minutes long. If it takes more than that, then either the person is being too verbose or the important bits of information must be the stuff of revelations and deserves its own set of time outside of the stand-up to fully communicate it to the rest of the team.
Succinctly compiling the important information to other people on your team forces you to think critically about what you did yesterday.
Stand-ups are facetime in which you're forced to listen to other people on your team. Use this time to listen critically. The more I program, the more I realize that I have a lot to gain from my teammates.
I don't want to sound too prescriptive in this post. Use what works for you and in moderation. I can only hope that some people have benefited from this.
Mark Campbell
Ruby Enthusiast
Winnipeg, Canada
[email protected]