Comments on: Why Your Senior Managers Like Serial Lifecycles

By: Why Your Senior Managers Like Serial Lifecycles - PM Hut

Why Your Senior Managers Like Serial Lifecycles - PM Hut — Thu, 14 Jan 2010 22:45:20 +0000

[...] The original article can be found at: http://jrothman.com/blog/mpd/2009/01/why-your-senior-managers-like-serial-lifecycles.html [...]

By: Ken Katz

Ken Katz — Mon, 23 Feb 2009 01:12:59 +0000

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.

By: Matt McKnight

Matt McKnight — Wed, 21 Jan 2009 17:29:41 +0000

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.

By: Glen B. Alleman

Glen B. Alleman — Wed, 21 Jan 2009 04:54:07 +0000

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.

By: gvb

gvb — Mon, 19 Jan 2009 02:04:44 +0000

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.

By: George Dinwiddie’s blog » Agility and Predictability

George Dinwiddie’s blog » Agility and Predictability — Sat, 17 Jan 2009 03:37:24 +0000

[...] was reading the latest post on Johanna Rothman’s Managing Product Development blog. In it she says, Serial lifecycles [...]

By: Pawel Brodzinski

Pawel Brodzinski — Fri, 16 Jan 2009 17:16:37 +0000

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.

By: Dwayne Phillips

Dwayne Phillips — Fri, 16 Jan 2009 12:10:45 +0000

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.