Working the Stand-Up
The organization that employs me began to implement Daily Stand-Up Meetings a little under a year ago. So far, it hasn’t been going well at all, at least in my opinion. First, I suppose I should try to enumerate the purpose, advantages, and disadvantages of the daily stand-up before I discuss what I feel like we’re doing wrong.
What is the Daily Stand-Up?
The stand-up is an attempt to promote high-visibility and co-ownership within a team of people working on a singular project. In lieu of the more traditional status meeting approach to the problem of low-visibility, effort is made to keep have short, sweet, to-the-point, and team- (rather than manager-) lead stand-up meetings. Apparently (I’ve never had the good fortune to be actually involved in one of these atrocious things), status meetings have a tendency to descend into nothing more than low-energy wastes of time where people who shouldn’t be involved with each other drone on for an hour, reporting to the boss about this and that configuration item. Commonly, in a stand-up, the emphasis is placed on answering 3 questions with a great degree of brevity (to be clear, I’m lifting these questions directly from Shore and Warden:
- What did I do Yesterday?
- What will I do today?
- What problems are preventing me from making progress?
In order to maintain energy and to reduce the feeling of interruption, some organic pressure on keeping the meetings short is required. As The Old Boy so elegantly puts it in his excellent essay on daily stand-ups, “We stand up to keep the meeting short.” The thinking is that sore feet and legs will soon remind any gabby team members to speed things up.
A daily stand-up can also be attended by non-developer stakeholders in the product. This involvement can take the place of a typical status meeting but can also be somewhat destructive. The problem comes when the people who don’t need to be directly involved in the stand-up start to take too much attention away from the real task at hand. For instance, gasping or getting visibly angry if a team member reports that they were not able to progress far enough on a particular configuration item and thus have to push a release date back would be trouble on many fronts. First, it would reduce team members’ ability to speak freely about development issues they are having for fear of blow-back from the stakeholders. Other issues can be left to the reader to imagine. However, despite the danger, oftentimes the stand-up can be a terrific opportunity to state which stories you’re working on, how their coming, whether you think you will meet the project guess date, etc. which in a properly organized team with high customer involvement should be most if not all of what your stakeholders are interested in knowing.
To sum up, the daily stand-up is a tool for promoting visibility among a team and the relevant stakeholders working on a single product or tightly knit set of products via a low-cost daily event that helps focus the team on important issues and increases the likelihood that any problems faced by a team member will be known to the whole team quickly (at most a day late).
What isn’t a Daily Stand-Up?
A daily stand-up should not be any of the of the following.
- An opportunity to inform an entire organization of the goings on within a specific project.
- A status report meeting used by a manager to gain insight into the goings on of every project under his or her command at one time.
I’ll address each of these points one at a time. However, before I do that I’ll just point out if you didn’t already catch it that the common theme here is using the stand-up to do more-than-one-team operations. I believe this is a perversion of the stand-up concept and should be rooted out as quickly as possible. This, unfortunately, is how my organization uses the stand-up meeting, and I believe it is contributing to the relative hair-pulling nature of our practice.
First, the meetings cannot be used to inform an entire organization of the goings on within your project. This misses the whole point of the stand-up in the first place! The idea is to foster communication between interested parties and team members, not to try to report to people who have no stake in what you’re doing. Beyond missing the point, it’s impractical. In my organization, for instance, there is implicit pressure to dumb down what you are reporting on because most of the other people in the room aren’t aware enough of what you’re talking about to be able to intelligently listen (I’m at the very least speaking for myself… 3/4 of the developers at my organization are Main Framers, and I’ll be the first to tell you, I know nothing about main frame programming). Notice, please, that I’m not saying they aren’t intrinsically intelligent enough to be capable of understanding, just that they aren’t aware of the project enough to be able to listen to statements as compact as what a true stand-up calls for.
We recently began to do a stand-up meeting with just the team members of the project that I’m on (a :cringe: VB6 DB-driven Inventory Tracking System) and the difference is night and day. I feel free and encouraged to share deep technical issues that I’m dealing with because I know the people I’m talking to have knowledge about what I’m referring to. Beyond that, there isn’t as much of a need to preface everything that I’m talking about with lengthy and pedantic explanations because the people I’m talking to know the system at least as well as I do. We’re all in it together. Comparatively, in the whole-organization stand-up I take part in, I know 3/4 of the people have absolutely no stake and very little knowledge about what I’m doing. This is counter-productive and as such it’s harmful to morale and motivation. My manager has to virtually drag people to the stand-up every morning and encourage people to get started, rather than it being an organic, team-led event, I believe specifically because people know that the rest of the developers there are mostly uninformed.
Second, and related, the status-report-to-the-manager mentality has no place in a stand-up meeting. In fact, according to the best literature on the subject, a well-run stand-up meeting should eventually have no need at all of a manager. The intrinsic value of knowing what your co-team members are doing, having difficult problems that you face solved with your team members’ help, not having to attend long status meetings with every interested party etc. should eventually garner interest from the team. At my organization, this is decidedly not the case. In fact, a new rule was recently instituted that stand-ups don’t have to happen unless my manager is present. This is of course, counter to the whole idea. A manager should be present when they can be there, but in the end they should only be there as an outside observer, rather than a direct participant (unless of course the manager is specifically acting as the team lead, in which case that is the role they would be appearing under, not as the branch manager). It is this status report mentality that The Old Boy addresses in the Reporting to the Leader section of his essay. This is a surefire way that I have personally experienced of killing the stand-up. When people are not talking to each other and are instead talking to the manager, the stand-up is going to feel impersonal and worthless.
Are There Any Disadvantages to a Daily Stand-Up?
The main disadvantages talked about in the literature seem to indicate the following:
- When a stand-up is run wrong, it quickly becomes just one more unwelcome interruption to your day rather than a time for team communication.
- Even if a stand-up is run right, there is a possibility that it’s timing will distract people from getting work done because either the stand-up starts the day late, or it isn’t at a good time to set the focus for the team.
Obviously, point one is easily addressed. The remedy for a poorly run stand-up is to stop running it poorly. This might include getting some help for running your stand-up from a more experienced team or consultant firm. The Old Boy does contend that a poorly run stand-up will almost certainly not just ‘fix itself’ and if it is not helped, the likelihood that it will simply die is very high. Point two is a much more difficult problem, however it’s something of a non-starter. The challenges of finding the best time to do your stand-up are small compared to the benefits of a well-run stand-up.
So How Could We Fix the Stand-Up At My Organization?
In brief, there are two basic teams at my organization: Main Framers who program mostly in COBOL, and what has heretofore been referred to as Client/Server folks (I think we’re updating that name to Web Appers). The former comprises roughly 3/4’s of the developers. To this day (yes, even after almost a year of stand-ups), I’m still not sure I understand what the Main Framers are working on. I know that there are basically 2 products that the Web Appers are working on and an additional one that is in a state of regular maintenance. That’s our situation to the extent of my knowledge. There are several solutions that I see to the problem we’re facing at my organization, and maybe your organizations face similar issues that could be addressed in similar ways:
- Depending on how closely knit the Main Framers’ side is (I sometimes get the impression that it is very closely knit, although I know there are multiple products), the stand-up could at least be split between Main Framers and Web Appers.
- The stand-ups could be split up on a per-project basis (this would be a ‘traditional’ stand-up).
First, there is one advantage to the model that everyone participates in one stand-up. It means that no one has to attend multiple stand-ups. Unfortunately, another characteristic of my organization is that most people are assigned to multiple active-development projects. This is of course quite separate from the notion that once a project is put into maintenance mode, you go on to developing other things more actively. So, if you approach things this way one does not have to do multiple stand-ups. Wonderful… Of course this approach ignores the fact that when you include everyone in a single stand-up, they either have to report on everything that they would have reported on in their smaller per-project stand-ups (yielding the same time spent on balance, and in a much less focused way) or they have to simply not report on things the way they would have otherwise (mucking up the purpose of the stand-up to begin with). Both of the approaches above don’t directly address this problem, however they don’t necessarily have to as the goal is to have only interested parties at any given stand-up anyway so the problem of having to ‘pick and choose’ is a moot point because people will want to be at these stand-ups.
I see solution one as an incomplete but perhaps necessary solution. The problem is that some people have to be involved in multiple projects and in theory the more stand-up meetings you have, the harder the scheduling becomes. Ideally, my manager would simply travel around to the various stand-ups and listen in to get his status information. Anyone who had multiple stand-up commitments would simply have to work out a schedule with his or her various team members that works for everyone. If absolutely no solution can be found (I can’t imagine this happening, unless severe interpersonal issues were already present), then I would expect the correct solution would be the removal of the person from one of the teams for the sake of focus. However, it’s possible that on the Main Framer’s side there is really only one system that has many parts that they all work on together. It’s not the case on the Web Appers’ side, but it’s a possibility. If this is the case, then the Main Framers at least could gather as one body and this would reduce the chance of scheduling conflicts, as well as promoting chances for self-organization between the different parties. Also, this would at least keep people in their various expertise domains. This would allow people to refer to specific but widely-applicable technical issues they are facing (problems with a specific tool, issues with a particular coding construct, etc.) that the people present would be likely to be able to address.
However, the true Holy Grail here would be splitting things up into teams. Most of the teams at my organization are no more than 3 or 4 people (usually less) as far as I can tell. That would mean that a given stand-up could go into great technical detail and yet still last for maybe 5 minutes. In contrast, when the whole group gets together and things are time-boxed to 15 minutes, the emphasis on brevity and the problem of global comprehension make it difficult to communicate anything significant briefly. In this solution, people would schedule, of their own accord, stand-ups involving only the team members specifically assigned to that project and would inform the relevant stakeholders (including my manager) of that time. Allowance would have to be made for every stand-up to occur at a unique time (to give floaters the ability to attend them all) unless a situation easily allows for multiple stand-ups to be happening at once. Then, the stand-ups would occur, regardless of my manager’s or stakeholder’s presence, as a team-led effort. As the teams get better at doing these stand-ups, will to do them would also increase. I don’t see the issue of floaters as being a viable one for the reasons I stated above: They should be reporting on everything they’d say anyway, and because of the people involved in any one stand-up, they should feel encouraged to do so.
Conclusion
Well, that’s all a mouthful. It boils down to this: Stand-Ups should be brief, to the point, and single team. The challenge of involving a second uninvolved party of any kind simply increases friction and reduces energy. If your organization is doing something like mine is, consider writing something like this as a proposal for change, because the stand-up is too good of an idea to just let go because of bad implementation.
For Further Reading
I’ve linked to The Old Boy and Shore and Warden in the article, but here they are in a nice list:
- It’s Not Just Standing Up - Martin Fowler
- The Art of Agile Development - Shore and Warden
- Stand Up Anti-Patterns
For Pity’s Sake
I think I understand why my manager is doing this. The culture at my work place is distinctively non-agile. I think that approaching a very valuable practice like the stand-up in this manner is seen as a way to ease my co-workers into the practice. The problem is that the way it is being done is making people less interested in the stand-up, not more. If we really want to get this practice going, we need to do it right.
Leave a Reply