Why Your Senior Managers Like Serial Lifecycles

I gave a talk last night at the Software Quality Group of New England about schedule games. During the talk, I explained how serial lifecycles don’t manage technical, schedule, or cost risk, that they increase the duration of the project, that they don’t provide feedback early enough for the project team. One of the attendees asked, “If waterfall or phase-gate lifecycles are so bad, why do senior managers like them?”

Because the serial lifecycles are a simplification of what we do. They make more sense for a product with a physical component, because you do have to do some testing (certainly not all), once the product is built. But, especially for software, where we don’t have to wait until the end to get feedback–and should not wait until the end of the project to get feedback!–serial lifecycles make sense only under certain circumstances. My general rule of thumb is to consider a serial lifecycle only if you have two or three people for no more than 1 month of work. Otherwise, I use a different lifecycle.

But there’s an another, more insidious reason: serial lifecycles work for simple projects. The projects your senior managers worked on were much simpler than the products you’re working on now. With determined, dedicated people, your managers made those projects work. The lifecycle may not have helped them, but they managed to make the project work anyway. But your projects are not the same as your senior managers’ projects back when they were individual contributors or even project managers. Your projects are more complex.

Possible the most seductive reason of all: Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction hat’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.

If you’ve been struggling with how to explain to your managers, first understand your managers’ context. Then, maybe you can have a conversation.

BTW, I offer workshops aimed at people who are struggling with their transition to agile, for teams and project managers, and other folks across the organization.

8 Replies to “Why Your Senior Managers Like Serial Lifecycles”

  1. Yes! Senior managers work with high-level concepts: cost and schedule in big round numbers. Step-by-step progression.

    “Tell me in ten seconds what you have accomplished!”

    They only have ten seconds to listen to you. That is because they are mis-managing their own time and work. They need you to help them by giving simple answers.

    Give them a simple answer, “We will have 75% of the features done at the end of this month.”

    Try not to explain agile methods to them and how each iteration reduces blah blah blah. They aren’t interested.

    They aren’t stupid, just ignorant and lacking the time to learn.

  2. About predictability I’d say it doesn’t have to be false. Waterfall project which was properly planned and is properly managed should end around deadline and should deliver functionalities specified in requirements. Of course another question is whether requirements defined the best possible solution (most likely not) but that’s another discussion.

    There’s one more reason for managers being reluctant to resign from serial lyfecycles – being afraid of change. These methods have been here for some time already. All this “agile thing” sounds fresh but hey, we’d like to learn how to use it and that’s oh so hard… It’s easier to stick with what they know.

    The whole thing with moving into more flexible methods is to convince reluctant managers that they want changes. With no support from stakeholders, especially on the client side, effectiveness of agile is rather low.

  3. I think the siren song of the waterfall model is that it is a logical model and thus “makes sense.”

    The problem is that PHBs inappropriately try to use it as a time sequence model.

    Wikipedia: The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term “waterfall” in this article. Ironically, Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).

    I’ve been in the software industry over 25 years. Myself and my coworkers have been subjected to innumerable training sessions and methodologies on how to write requirements, yet we still fail to get the requirements right on every project we work on (OTOH, wrong requirements are handy to shift the blame ;-).

    To quote Steve Yegge,
    “If a process is potentially good, but 90+% of the time smart and well-intentioned people screw it up, then it’s a bad process. So they can only say it’s the team’s fault so many times before it’s not really the team’s fault.”

    We’ve been trying to solve the requirements problem for over 30 years (reference Brook’s The Mythical Man-Month) and failing year after year. The obvious conclusion is that creating perfect requirements and communicating them perfectly up and down the hierarchy is an intractable problem.

    I think “agile” has it right – if perfect knowledge up front is an intractable problem, work to solve what you know while working to clarify and identify the unknown.

  4. The key to understanding here is the granularity of the “serial” activities. There is an old XP diagram, which I’ve now lost, where Kent shows large grained serial activities being successfully subdivided until you get the XP cycles.
    It is not, I repeat not the presence of a serial process, but the granularity of each step in the process. Ranging from months (and I’ve seen a year) to two week, to even a day. A top notch XP shop here in Denver had twice a day iterations for ERP roll outs.
    The whole notion of “waterfall” versus agile fails to recognize the problem is the sample time between corrections. This is a process control issue and any process control person (and I am one), will affirm that long sample time means poor corrective actions.
    At the same time sampling too often creates “hunting” controls loops when the change command chases the sample signal.

  5. You speak the truth! What we’ve been seeing in the government contracting world is that agile planning takes away this concept of someone walking around with a Gantt chart asking if widget A is still scheduled to be complete on Friday and getting to hold it over you when it’s not. Agile estimation techniques (in fact most estimation techniques that take uncertainty into account) are far more sophisticated and don’t let the project overseers perform their traditional role as easily. On the other hand, the agile reporting mechanisms are vastly superior in terms of conveying real information, it’s just that the whole concept of estimation by proxy doesn’t quite make sense to them. (Partially because I could cheat by claiming that certain things are really hard.) It forces them to do more thinking, and, frankly, a lot of people don’t want to do that.

  6. I’m giving a class this summer at the Better Software Conference and Expo called “In Defense of Waterfall”. I certainly recognize that agile has its benefits and waterfall has its problems, but I will also show that waterfall has its time and place, and some of its problems can be corrected.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.