DevLogs: Our Stand-in for Stand-ups

Stand-up Meetings - efficient or not?

Many software teams use the Stand-up Meeting (or some variation of it) as part of the team's communication process. The benefits are obvious. You encourage (force?) introverted engineers to communicate, surface opportunities for cooperation, and bring project managers up-to-speed; all within a small window of time. Stand-ups can definitely succeed as a tool to help maintain the balance between maker and manager schedules. Team information flow is always welcome.

Stand-up meetings do have some limitations however. They interrupt your day just as regular meetings do. You still have the condition that only one person can communicate at a time. Most of the group status updates are only relevant to a small subset of the group at any given time; minutes and workflow are being wasted for everyone else. The discussion frequently gets off track, even if just momentarily, and even in the most well-intentioned groups.

There are a lot of opinions and even detailed guides available about what procedural elements or rules lead to the most effective stand-up meeting. It seems a lot of energy is spent trying to structure the protocol and enforce certain modes of conduct, but delivering information in this manner doesn't match how we naturally share information in groups. Imagine a family or group of friends sitting down at a meal together. People talk at different times, share more or less details as appropriate, and side discussions happen. At the end, everyone is up-to-date. With stand-up meetings it feels like we're working against our natural communication rhythms. Why fight human nature?

Can we do better?

Can we improve the process by preserving the fundamental goal of stand-ups - share your status with the team - with an even lighter-weight approach? Let everyone provide their status update at a time most convenient to them. Our test was whether a rolling window of updates is adequate for most arrangements. For example, within a 24 hour window everyone will leave at least one update, at their discretion. No more hassle of finding a specific time everyday, getting everyone together, and interrupting workflows. Team members who need to track each other's progress more frequently than that will use other modes of communication to work together directly.

An experiment

Ginger is a natural fit for this style of communication. We created a Ginger team called DevLogs that serves loosely as a daily task journal. Each day, someone starts a new discussion. As a team we each leave short updates or summaries, similar to what one would offer during their turn in a stand-up. We started with these two simple rules:

• Participation is optional.
• Your summary format is whatever you want it to be.

The first Dev Log was started with an opening inspirational quote and it has become tradition for the discussion author to share one ever since. For example:

Over the last few months we've provided each other with an eclectic mix of philosophical, timely, classic and non-sequitur gems. Everyone else is encouraged (but not required) to leave regular brief updates when convenient. The format is casual and people use different styles. Here are some examples.

Simple bulleted list:

Add notes about quality of day:

Strikeout items for sense of accomplishment:

Occasionally people share interesting personal updates:

Usually this sort of personal information wouldn't be appropriate in the context of a stand-up meeting, but it doesn't feel obtrusive in this setting and it provides an easy way to build team camaraderie. Finally, the DevLogs serves as a natural and easily referenced historical record - like a journal:

We haven't seen a convincing reason to revert back to structured update meetings.

So far the following benefits have surfaced:

• Information flow amongst the team on par with regular stand-ups
• Everyone updates on their own time.
• Updating the team can take as little as one minute.
• Seeing what everyone else is doing can take as little as one minute.
• Discussions can spring forth from people's updates without distracting everyone else.
• People tend to feel more comfortable sharing frustrations or concerns in this format. Problems can be recognized and addressed way before someone reaches a boiling point.
• People frequently acknowledge their teammates' achievements.
• Personal achievements and family updates are more freely shared. Camaraderie increases.

This all sprouted up with just the two simple starting rules: Optional participation, Open format. Nobody is managing this process; we all contribute together.

Optional Participation? Really?

No doubt the notion of optional participation has set off alarm bells for some readers. This was a parameter I set at the beginning of the experiment. I'd like to believe that it helped lead to the success of the experiment; more likely it was due to the quality of my teammates. In the first couple weeks, about half of the team contributed regularly with status updates or daily goals. After a few weeks, the rest were contributing as well. At no time have we ever declared as a team that participation is mandatory, it seems to go along fine naturally. Maybe this sounds silly, but I believe that with this arrangement helped foster optimal communications. When you're doing something "voluntarily" and at your leisure, you're in a different mindset than when you're just conforming to a process. The likelihood that you'll share pertinent and honest information should increase.

Having this channel for our team has had a visible impact on our ability to react to company and project needs. The asynchronous protocol improves communication efficiency.. The updates are crisp and distilled down the appropriate granularity for the group. No more rambling. This is one of many ways Ginger lets us organize and operate with lightweight business processes.

There are comments