After Agile

The Agile project method was developed as an alternative (one might say, a rebuttal) of Waterfall. Waterfall was first, aside from the proto-process of "do whatever we want" that was used prior to Waterfall. Waterfall had a revolutionary idea: Let's think about what we will do before we do it.

Waterfall can work with small and large projects, and small and large project teams. If offers fixed cost, fixed schedule, and fixed features. Once started, a project plan can be modified, but only with change control, a bureaucratic process to limit changes in addition to broadcasting proposed changes to the entire team.

Agile, its initial incarnation, was for small teams and projects with flexible schedules. Schedule may be fixed, or may be variable; you can deliver a working product at any time. (Although you cannot know in advance which features will be in the delivered product.)

Agile has no no change control process -- or rather, Agile is all about change control, allowing revisions to features at any time. Each iteration (or "sprint", or "cycle") starts with a conversation that involved stakeholders who decide on the next set of features. Waterfall's idea of "think, talk, and agree before we act" is part of Agile.

So we have two methods for managing development projects. But two is an unreasonable number. In the universe, there are rarely two (and only two) of things. Some things, such as electrons and stars and apples, exist in large quantities. Some things, such as the Hope Diamond and our planet's atmosphere, exist as singletons. (A few things do exist in pairs. But the vast majority of objects are either singles or multitudes.)

If software management methods exist as a multitude (for they are clearly not a singleton) then we can expect a third method after Waterfall and Agile. (And a fourth, and a fifth...)

What are the attributes of this new methods? I don't know -- yet. But I have some ideas.

We need a management process for distributed teams, where the participants cannot meet in the same room. This issue is mostly about communication, and it includes differences in time zones.

We need a management process for large systems composed of multiple applications, or "systems of systems". Agile cannot handle projects of this size; waterfall has flaws with it.

Here are some techniques that I think will be in new management methods:

• Automated testing
• Automated deployment with automated roll-back
• Automated evaluation of source code (lint, Robocop, etc.)
• Automated recording (and transcribing) of meetings and conversations

It is possible that new methods will use other terms and avoid the "Agile" term. I tend to doubt that. We humans like to name things, and we prefer familiar names. "Agile" was called "Agile" and not "Express Waterfall" because the founders wanted to emphasize the difference from the even-then reviled Waterfall method.

The Waterfall brand was tarnished -- and still is. Few folks want to admit to using Waterfall; they prefer to claim Agile methods. So I'm not expecting a "new Waterfall" method.

Agile's brand is strong; developers want to work on Agile projects and managers want to lead Agile projects. Whatever methods we devise, we will probably call them "Agile". We will use "Distributed Agile" for distributed teams, "Large Agile" for large teams, and maybe "Layered Agile" for systems of systems.

Or maybe we will use other terms. If Agile falls out of favor, then we will pick a different term, such as "Coordinated".

Regardless of the names, I'm looking forward to new project management methods.