The ultimate management sin is to waste people’s time, Tom DeMarco and Timothy Lister told us in their famous book Peopleware [1]. This includes having pointless meetings that prevent people from actually doing anything useful. Nevertheless, some meetings are considered a necessary evil and therefore the so-called “agile movement” in software development has come up with an efficient way of dealing with this: the Stand-up Meeting in 15 Minutes. For those who have just woken up from ten years of hibernation, or having emerged from a cave that had no Internet access, I will explain this briefly.
A stand-up meeting is a daily meeting where people remain standing up to keep the duration of the meeting under 15 minutes. Teams use these meetings to answer three simple questions:
- What did we do yesterday?
- What will we do today?
- Are there any obstacles?
The daily stand-up meeting ranks as one of the most popular and most effective best practices in software development, despite the fact that the standing-up part and the 15-minute limit are illogical adaptations to an otherwise sound idea.
Self-organization
In one of the best articles on stand-up meetings Jason Yip [2] explained that self-organization is the underlying theme in this practice, which enables team members to better communicate and coordinate their efforts for the rest of the day. For stand-up meetings to succeed a few rules are imposed, like the restriction to the three questions, the strict time limit, a fixed time and place for the meeting to occur, and some restrictions on participation from outsiders. It seems contradictory to impose rules on an initiative that is supposed to be about self-organization. Shouldn’t the participants themselves be allowed to self-organize and decide which rules to apply to the gathering? Of course they should. In fact, in his article Jason Yip has described many variations on the main theme. However, complexity theory shows us that internal rules are needed for a system to be effective [3]. We can see something very similar in the flocking of birds, which can be modeled on computers by using just three simple rules to describe the behavior of the individual birds [4]:
- Alignment: steer direction towards the average goal of the other birds
- Cohesion: steer towards the average position of the closest birds
- Separation: prevent collision with any of the other birds
These are the only rules needed to simulate the complexity of birds communicating and coordinating their efforts while flying together. In this case evolution is the adaptive mechanism that has selected the best rules for an optimal effect. Ignoring the neighboring birds, steering in an opposite direction or flying with eyes closed may have been tried out by some birds, but natural selection must have weeded out such alternative genetic routes. Therefore, an adaptive system like a software project must also be able to try out different rules in order to see which ones work best. It is essential that team members try out different patterns, modify them to local circumstances and evaluate the results. But once a good set of rules has been found the agents participating in the system are required to stick to these rules to achieve optimal results for everyone involved. If some team members follow their own rules of flocking, complexity will turn into chaos, resulting in angry squeals, painful collisions and ruffled or lost feathers.
Evolution makes sure that birds adhere to the rules because the rules are programmed into their genes. But how do we program people? It is not sufficient to expect all of them to be responsible team members and to let social control keep colleagues in line with the rest of the team. There should be at least one person in the group who is willing to assume the role of Mother Nature, programming the rules and making sure that everyone sticks to them. If there are several of such experienced people in the group, then self-organization will simply take place on an additional but higher level (process improvement), selecting and discarding the best rules to apply for self-organization on the lower level (project development) to be successful. However, simply putting together a bunch of people and expecting them to magically self-organize is an illusion.
Synchronization
Decisions build on information and on each other, but information becomes outdated quickly and assumptions can lead to errors. People communicate to keep information fresh so that they can make better decisions. Hallway chatter, emails, forums and wikis are helpful, but only to a certain degree. Some people may prefer to communicate with some specific team members, while not particularly enjoying the vicinity of others. Some people share intensive and frequent communication simply because they sit next to each other. Some people hate email, others dislike chatting near the coffee machine. These lines of communication and information flow all have a tendency to follow their own rules of self-organization, which may or may not be in the interest of the entire team. Therefore we must apply the concept of a regular broadcast of crucial information among all team members. It enables them to align their daily work, to reaffirm the common goal and to steer out of each others way when necessary.
Having people get together once every day is an example of synchronization, which is a phenomenon common in many complex systems. Occasional but regular full connectivity among participants in such a system will make sure that all efforts remain synchronized. Examples in other sciences are abundant. Cardiac pacemaker cells in the human heart synchronize with each other to achieve a steady heartbeat of around 70 beats per minute in an adult human [5]. Electrical engineers have devised a way for clocking and synchronizing computer circuits efficiently by mimicking the synchronization of fireflies [6]. For most of the year, female horseshoe bats live in a colony separate from the males, which generally live off on their own. But once every year they all get together for a wild mating frenzy, where one male may be shared by several generations of females. [7] It is obvious that examples such as these can teach us a lot about synchronization and communication, and a little about incestuous polygamy.
Getting together and communicating at fixed intervals is an efficient way of broadcasting and receiving information without incurring the overhead of having to venture out to find all the others. Of course, there is always the danger of either too little or too much, so the effort of this synchronization should be adjusted to find some optimal frequency or time interval. However, bats are not good at getting together using an interval of 1.26 years, even if that turned out to be the optimal value given energy consumption levels and return on investment. It is easier for everyone involved just to stick to a nice one-year cycle, even if that frequency is not the precise optimum. Most people’s biological clocks work on a 25-hour cycle rather than a 24-hour one. But daylight and other daily patterns shift our biological cycle to the 24-hours cycle of the earth’s rotation [8]. So it turns out that most of us go to sleep just a little too often.
But do we care? (I certainly don’t.)
Likewise, the optimal interval for daily meetings may be anywhere between 0.5 and 1.5 days. But reconvening every day at the same time in the morning feels a lot more natural for everyone, even though it might seem like a little too much sometimes. Note that, if the optimal value is somewhere between 4 and 10 days a team should obviously organize not a daily but a weekly meeting. And for any optimal values between 1.5 and 4 days people might be comfortable enough with meeting every other day. The costs of synchronizing a little too often or a little too seldom are small compared to the costs of working against daily and weekly rhythms in the environment.
Memes
As a meme (a word invented by Richard Dawkins [9] explaining the spreading of cultural ideas) the stand-up meeting is quite successful in copying itself from mind to mind, not in the least because of its catchy name. The idea to keep meetings short by requiring people to remain standing up is, in my opinion, a fallacy. Following this logic an even more effective approach would be to require everyone to hang up-side down. I am quite sure not many people would be able to keep that up (of down) for 15 minutes straight. I claim that the idea to stand up is a parasite meme that has attached itself to the meme of organizing a daily meeting. Standing up might help to keep the meeting short, but so does setting an egg timer or having a leader keeping an eye on the time. I call the idea a parasite because it actually hurts the original best practice by associating something good (meeting daily) with something unpleasant (standing up). This defies the aim of people having positive feelings about it. Daily meetings have existed in other fields long before methodologies like Scrum and XP adopted them. But, interestingly enough, it seems that adding this parasitic idea of doing them standing up has actually helped to spread this best practice in our field of software development. After all, a bit of controversy is often an excellent way of marketing an idea.
Something similar applies to the 15-minute limit that gets mentioned in numerous articles. The number 15 sounds good. I think Andy Warhol was smart in not picking 10 or 20 minutes, which would have had much less of an impact than his famous “15 minutes of fame”. These 15 minutes are, of course, completely irrelevant. Why would a three-person team commit itself to the same 15-minute time span as a team consisting of 12 members? Smart people will understand that the daily meetings should last something in the order of one or two minutes per person, no matter whether that turns out to be five or twenty minutes in total.
Conclusion
The catchy number 15 and the silly idea of standing up may have helped spreading this best practice in our field of software development, and I’m not one for complaining about that. According to Alistair Cockburn the practice of a daily short meeting is compatible with just about any other methodology [10]. This significantly boosts its chance of being adopted in many projects. It improves communication and coordination among team members by synchronizing all work using a simple daily routine. And I am very much in favor of that. So, let us continue to broadcast this idea of the 15-minute stand-up meeting, with a hint for people not to take this too literally.
Sources and References
[1] DeMarco, T. and Lister, T. (1999) Peopleware: Productive Projects and Teams (Second Edition). New York: Dorset House
[2] Yip, J. “It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings” URL: http://martinfowler.com/articles/itsNotJustStandingUp.html
[3] Holland, J.H. (1995) Hidden Order: How Adaptation Builds Complexity. New York: Basic Books.
[4] Reynolds, C. “Boids: Background and Update” URL: http://www.red3d.com/cwr/boids/
[5] “Cardiac pacemaker” URL: http://en.wikipedia.org/wiki/Cardiac_pacemaker
[6] Strogatz, S. (2003) Sync: The Emerging Science of Spontaneous Order. New York: Hyperion Books.
[7] Carey, B. (2005) “Kinky Female Bats Share Mates With Their Mothers, Avoid Incest” URL: http://www.livescience.com/animals/050914_bat_sex.html
[8] “Circadian rhythm” URL: http://en.wikipedia.org/wiki/Circadian_rhythm
[9] Dawkins, R. (1976) The Selfish Gene. New York: Oxford University Press
[10] Cockburn, A. (2005) Crystal Clear: A Human-Powered Methodology for Small Teams. Upper Saddle River: Pearson Education
Author: Jurgen Appelo is CIO at ISM eCompany, recently rated as the #1 fastest growing technology company in The Netherlands. He leads a horde of 50 software developers, development managers, project managers and consultants. You can enjoy more of his writing on his blog: www.noop.nl