5 ms·

> but behind the facade it’s all waterfall. That is to be expected, because "waterfall" or pipeline is the general structure of work. At the very least you hav

> but behind the facade it’s all waterfall. That is to be expected, because "waterfall" or pipeline is the general structure of work. At the very least you have design, production and verification steps. Agile is not about removal of waterfall, but rather applying 1. waterfalls to small chunks of work 2. multiple "tiers" of waterfall. The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. If you start building image manipulation software you generally do not pivot to building a presentation software without redefining or scrapping the "master" waterfall. Stages of the whole project generally do have dependencies on other stages, there is no way around that. As long as you have at least some visibility into the project you are going to have stages and checkpoints and in the end a "waterfall" will surface somewhere. Waterfall is at the core a way to represent staged/checkpointed work.

vegetablepotpie 4y ago
My argument is that the things that waterfall specializes in, which is managing stages of work and dependencies between work is actually insignificant to the success of projects people care about. Waterfall is good when you are building structures. But value exclusively comes from the integration, verification, validation, and deployment of structures. With these types of tasks, the variance in estimates exceeds the mean of those estimates. Effective workers constantly probe different pathways to success and this makes your project network, with its delineated stages and strict dependencies, totally divorced from reality. The outcome of knowledge work, is knowledge. Not story points allocated, not dollars spent, not time used. The best hope of having a project management approach with valid predictive power is to track knowledge earned and not EVMS metrics satisfied.
donkeyd 4y ago
> you generally do not pivot I'm just going to grab this tiny part and focus on it. I've seen Agile fail many times for this exact reason. In start-up land, one might pivot and massively change an end goal. In corporate land that's a lot less off a thing. I've worked on some big projects in government and fortune 500, all of them pretended to be Agile and all of them had predefined scopes, deadlines and budgets. In all of those projects, Agile was more of a disturbing factor than anything else. The only flexible part was the scope of work, because of renewed insights or lack of specification while planning. This always ends with teams getting pressured to make deadlines (because those are never flexible), so they cut corners and work extra long hours. I think it would be much better for these types of projects (and the sanity of devs) not to pretend to be doing Agile, but just admit they want a more Prince2 led Waterfall approach. This won't happen though, because that puts the pressure with management in stead of the dev teams.
- nicoburns 4y ago
  I've done agile projects where the client was a big corporation. There was a fixed budget and deadline, but we specifically reserved some of that time/money for unspecified work at the start of the project. In the latter parts of the project we could then prioritise the work that was deemed most important by the client once they'd already seen the work in progress. I suspect it took quite a bit of work by our project team to convince them to work this way. But it's really great if you make it happen.
  - donkeyd 4y ago
    > I suspect it took quite a bit of work by our project team to convince them to work this way. It probably did. I've seen a couple of organizations that did this well, but the majority did not, unfortunately. In the end the sales guy will usually have received their bonus far before the project is over. I'm mostly amazed that companies like this can keep running for decades, but they do.
- chrisweekly 4y ago
  > "predefined scopes, deadlines and budgets" That's all 3 legs of the "iron triangle" (https://en.m.wikipedia.org/wiki/Project_management_triangle https://en.m.wikipedia.org/wiki/Project_management_triangle). At least one too many.
pydry 4y ago
>The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. It's much rarer than it used to be but it is far from mythical. Companies that are used to planning projects like this (e.g. construction) often have managers who apply the same mindset to software and are frequently almost incapable of considering that there is another way.

vegetablepotpie 4y ago

My argument is that the things that waterfall specializes in, which is managing stages of work and dependencies between work is actually insignificant to the success of projects people care about. Waterfall is good when you are building structures. But value exclusively comes from the integration, verification, validation, and deployment of structures. With these types of tasks, the variance in estimates exceeds the mean of those estimates. Effective workers constantly probe different pathways to success and this makes your project network, with its delineated stages and strict dependencies, totally divorced from reality. The outcome of knowledge work, is knowledge. Not story points allocated, not dollars spent, not time used. The best hope of having a project management approach with valid predictive power is to track knowledge earned and not EVMS metrics satisfied.

donkeyd 4y ago

> you generally do not pivot I'm just going to grab this tiny part and focus on it. I've seen Agile fail many times for this exact reason. In start-up land, one might pivot and massively change an end goal. In corporate land that's a lot less off a thing. I've worked on some big projects in government and fortune 500, all of them pretended to be Agile and all of them had predefined scopes, deadlines and budgets. In all of those projects, Agile was more of a disturbing factor than anything else. The only flexible part was the scope of work, because of renewed insights or lack of specification while planning. This always ends with teams getting pressured to make deadlines (because those are never flexible), so they cut corners and work extra long hours. I think it would be much better for these types of projects (and the sanity of devs) not to pretend to be doing Agile, but just admit they want a more Prince2 led Waterfall approach. This won't happen though, because that puts the pressure with management in stead of the dev teams.

nicoburns 4y ago
I've done agile projects where the client was a big corporation. There was a fixed budget and deadline, but we specifically reserved some of that time/money for unspecified work at the start of the project. In the latter parts of the project we could then prioritise the work that was deemed most important by the client once they'd already seen the work in progress. I suspect it took quite a bit of work by our project team to convince them to work this way. But it's really great if you make it happen.
- donkeyd 4y ago
  > I suspect it took quite a bit of work by our project team to convince them to work this way. It probably did. I've seen a couple of organizations that did this well, but the majority did not, unfortunately. In the end the sales guy will usually have received their bonus far before the project is over. I'm mostly amazed that companies like this can keep running for decades, but they do.
chrisweekly 4y ago
> "predefined scopes, deadlines and budgets" That's all 3 legs of the "iron triangle" (https://en.m.wikipedia.org/wiki/Project_management_triangle https://en.m.wikipedia.org/wiki/Project_management_triangle). At least one too many.

pydry 4y ago

>The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. It's much rarer than it used to be but it is far from mythical. Companies that are used to planning projects like this (e.g. construction) often have managers who apply the same mindset to software and are frequently almost incapable of considering that there is another way.