Deadlines, But No Tempo

I have only recently started to present the idea I comment upon below when I teach classes and otherwise discuss development work with people. I’m not sure why it took me so long to recognize this comparison between the traditional phased-sequential (i.e., waterfall) and Agile approaches to development. But it seems an important point.

Traditional phased-sequential approaches to development have many deadlines/milestones as targets for work, but specify no expected tempo for getting work done between those milestones. Agile methods show considerable concern for establishing a work tempo which replaces most of the date-driven milestones in traditional approaches.

To me, the focus on milestones is less desirable than a predictable tempo because distance between milestones will vary from project to project based on the overall size of the work to be done by the final project delivery milestone. Agile’s main milestone is the iteration which is always (supposed to be) the same length. So teams get used to producing some defined result, regularly, at this tempo.

In traditional milestone-driven projects, the weekly/bi-weekly status meeting might be viewed as establishing some sort of tempo, but what is expected to be done between such events is not a delivery of value/product. So I do not view status meetings as having the same tempo impact as iterations.

A predictable tempo seems to me to encourage more of a team approach to work. Milestones allow more individual work expectations using milestones as coordination points. Of course, the time between such coordination points allows a lot of work to be done before coordination occurs and, as noted above, the time between such points will not necessarily be consistent within or between projects. I believe the inconsistency, extended time periods, and individual task focus work against effective coordination.

At least, it places greater burden on individuals to establish coordination behavior ad hoc. On the one hand, coordination is expected to occur. On the other, individuals view any work tempo to be personal. Coordination efforts in this context seem more difficult because they are not collaboration within an agreed upon tempo, but negotiation between individually accustomed to tempos. In such negotiation, some people are almost guaranteed to feel they have “lost”. (And, truthfully, this may be why some people find moving to an Agile approach problematic. The tempo of an iteration is not their natural one and, though it is not the other team members who have imposed the iteration concept on them, someone has.)

This leads me to believe that some talk about individual work styles and tempos is an important part of the “forming” stage for a team. Everyone much fit into the iteration length’s tempo. Discussing how to support and help one another do that, then, seems to me to be an important aspect of team-building in an Agile context.

I don’t hear people talk about this much, but I do believe I see consequences of it in daily work discussions, ability to deliver on commitments, etc. Because there are consequences for not overtly recognizing this, I think it should be discussed when teams are getting started. And certainly think the concept of milestones vs tempo is important for an organization to discuss when deciding to embark on an Agile approach to their development.