Bob Warfield

I started doing daily meetings and most of the rest of what resulted in the Quattro methodology after attending a talk by Stu Feldman while at Rice University (1979–1983).

Feldman had invented Make, the UNIX build automation tool, in 1976 at Bell Labs. At the time, he presented a surprising viewpoint on what Make really was: a way to enable more developers to work together efficiently. His thesis was that we had no idea how to get more than seven plus or minus two developers to work well together. As you may know, phone numbers have seven digits because that’s the average capacity of human short-term memory. Good menu design suggests no more than seven entries, lest we forget the first entry by the time we read the last. As Feldman saw software development as primarily a communications problem, he applied that same sort of thinking to how many developers could work together.

I was reminded of Feldman’s issue of communication as the bottleneck when I began a small startup that had to move quickly. There was no opportunity to write voluminous specs and documentation. We didn’t have the manpower, and we faced some moving targets. The goal was to stay fluid, highly reactive, and highly data driven and not be driven by historical, hazy visions created in the beginning. It drove us toward combating the communication issue head on. We had to check in with all developers on a daily basis.

We called them standing meetings because nobody had to plan or schedule them or even put them on their calendar. They were always on, not because anyone actually had to stand.

Our standing meetings served as quick, informal code reviews, where we asked questions about one another’s systems and why certain design choices were made. We paid specific attention to whether anyone’s code had to communicate with other developers’ code. It helped us greatly in avoiding premature optimizations or selecting under-par architectural decisions. The discussions allowed us to learn more about the design and refine it while also figuring out what to test and how best to test it.

Looking back, we intuitively applied group wisdom to hard problems. All were open about the trouble we were having so we could help one another out while learning from it. It helped us to identify hot spots and challenges to meeting our goals quickly and to jump on them early, before they became too big a problem.

Regardless of what they are called, the Daily is a developer’s meeting—not a place for marketers to try to hold developers accountable. Allowing the latter scenario has been one of the main ways I have seen Agile go wrong over time.