4 ms·

I get the criticisms of "waterfall" style development, but lack of any careful thought or specification spanning a whole project leads to really terrible contra

I get the criticisms of "waterfall" style development, but lack of any careful thought or specification spanning a whole project leads to really terrible contracts and projects as some people (especially Enterprise) use "agile" == "nimble" == "license to rug-pull project scope" when there is significant inertia, and occasionally sunk cost, in these scope changes. Case in point, I'm working in an engineering capacity with a "Big Mean Secret" pharma company on a contract that is essentially "Client will work with Vendor in an agile manner to <do something vague which could encompass everything or nothing>". The company I work for is nominally a "product" company, not a "services" company, and the contract specifies fixed payment terms and timeframe. This morning, one of my teams finished implementing some stuff that was a good amount of effort, several moving parts, etc. It was explicitly called out as top priority, and its progress has been tracked by both parties over the past weeks in a shared Jira board. A few hours later in a biweekly update meeting with said client, we mentioned having finished the feature. The client's project manager responded that actually the person who cared about that feature left the company, so it is no longer in scope. Then they erased it from the project tracking record, and in the same breath complained that so little progress had been made against the other objectives. And a million other little papercuts like that. It seems that "agile" style process is best confined to small / internal teams re: the "how", but the high level "what" requires comprehensive elucidation from the beginning.

michael1999 4y ago
How would an upfront contract have changed that outcome? Wouldn't that now-absent person have demanded the same work in the up-front plan? Or is your concern being able to bill for that work?
- xkcd-sucks 4y ago
  Yes, broadly speaking the concern is about being able to bill for that work. I realize that this is more an issue of terribly worded contracts, but "agile" expectations seem to encourage these.
  - michael1999 4y ago
    Letting the client fix all three sides of the iron triangle is trouble no matter what your process, and squarely on your management. In practice, agile contracts should be time+materials, or the vender needs to be a stakeholder in defining the scope. You almost always need a sketch of the total solution up front, and a light-weight change-management process. It's been years since I was in that business, but people have been working on this problem. You're not the first.
oxfordmale 4y ago
Waterfall as criticised by Agile followers is mostly a myth. It is a mythical monster designed to instill fear and guide developers along the righteous path of Agile. Of course enlightenment can only be reached with expensive Agile training consultants as you are doomed to fail if you walk alone in the valley of the shadow of project failure. https://loufranco.com/blog/waterfall-is-a-myth https://loufranco.com/blog/waterfall-is-a-myth
yibers 4y ago
> A few hours later in a biweekly update meeting with said client, we mentioned having finished the feature. The client's project manager responded that actually the person who cared about that feature left the company, so it is no longer in scope. Then they erased it from the project tracking record, and in the same breath complained that so little progress had been made against the other objectives. Actually, I don't see here an issue with doing "agile" or "waterfall". It's a communications issue. Either someone at "Big Mean Secret" company did not manage communications with the client properly, or the client didn't bother to communicate properly when given the opportunity. Either way, using a "waterfall" methodology would not have helped here. It can be said that maybe "agile" "done right" would have solved this issue, but when is "agile" ever "done right"? (The last sentence was an over generalization of course)

michael1999 4y ago

How would an upfront contract have changed that outcome? Wouldn't that now-absent person have demanded the same work in the up-front plan? Or is your concern being able to bill for that work?

xkcd-sucks 4y ago
Yes, broadly speaking the concern is about being able to bill for that work. I realize that this is more an issue of terribly worded contracts, but "agile" expectations seem to encourage these.
- michael1999 4y ago
  Letting the client fix all three sides of the iron triangle is trouble no matter what your process, and squarely on your management. In practice, agile contracts should be time+materials, or the vender needs to be a stakeholder in defining the scope. You almost always need a sketch of the total solution up front, and a light-weight change-management process. It's been years since I was in that business, but people have been working on this problem. You're not the first.

oxfordmale 4y ago

Waterfall as criticised by Agile followers is mostly a myth. It is a mythical monster designed to instill fear and guide developers along the righteous path of Agile. Of course enlightenment can only be reached with expensive Agile training consultants as you are doomed to fail if you walk alone in the valley of the shadow of project failure. https://loufranco.com/blog/waterfall-is-a-myth https://loufranco.com/blog/waterfall-is-a-myth

yibers 4y ago

> A few hours later in a biweekly update meeting with said client, we mentioned having finished the feature. The client's project manager responded that actually the person who cared about that feature left the company, so it is no longer in scope. Then they erased it from the project tracking record, and in the same breath complained that so little progress had been made against the other objectives. Actually, I don't see here an issue with doing "agile" or "waterfall". It's a communications issue. Either someone at "Big Mean Secret" company did not manage communications with the client properly, or the client didn't bother to communicate properly when given the opportunity. Either way, using a "waterfall" methodology would not have helped here. It can be said that maybe "agile" "done right" would have solved this issue, but when is "agile" ever "done right"? (The last sentence was an over generalization of course)