5 ms·

Based on my experience (primarily enterprise level data development) Agile can work if the product is ideally suited to it. By that I mean a reasonable number o

Based on my experience (primarily enterprise level data development) Agile can work if the product is ideally suited to it. By that I mean a reasonable number of stakeholders, and documentation and the product are in a state that can support rapid iteration. When management complexity and product complexity increase I begin to lust for the dreaded waterfall, because it can become onerous just defining requirements in an environment that is particularly chaotic or troublesome.

flash42 9y ago
What do you mean by "chaotic" and "troublesome" environment. Also I would be interested in how waterfall is helpful in those cases.
- w0m 9y ago
  Not OP, but I read that as the codebase is compartmentalized poorly. Agile works best when you can dip in, fix something small, and move on. If you need to change half the codebase to do a small thing; it may make sense to combine multiple small changes together. "While you're in there...". I do consider that an environmental 'code smell' though.
NittLion78 9y ago
For large efforts, I've always subscribed to "define waterfall, build agile". If you don't really hammer away up-front on all the possible avenues stakeholders want to explore in an end product and get those fully listed out and vetted before even the first line of code is written, then the "agile" portion should be simply changing directions on which of those things are considered most critical to delivering a minimum viable product based on where you currently are in the overall effort. Too often real work begins to get something concrete for stakeholders to react to (the general point of Scrum & Agile) while losing sight of the ultimate goal because it was never really defined very well to begin with. That just means more rework. Some rework is unavoidable, but so much of it is. You can control which mountain you want to climb and you can and should select which face of the mountain makes most sense to use as your path up it, but have a way to move laterally to a safer path up if the weather goes south.
- bahmboo 9y ago
  Product owner says build feature x this iteration by way of showing progress. Customer has explicitly said they are only interested in y. Whole team knows that x will have to be completely tossed out when building y. That's when agile fails. If you know what you are building it's a good idea to take that into account.
  - NittLion78 9y ago
    Agreed. That's the sort of rework that I think can be avoided by a good partnership between the PO and the stakeholders in the nascent stages before physical work begins. I guess the reason why this happens is this weird psychological block in people's minds that software is totally mutable and flexible and therefore can change to whatever you want it to be, even after the fact. You'd never go into that mindset when building a physical structure, but the amount of re-architecture required to enact such changes in software can be just that monumental.
    - bahmboo 9y ago
      I was able to break the impasse and build trust by getting PO to agree to architectural deliverables in a sprint. He was skeptical but with some sort of defined behavior for acceptance he was OK with it. Saying "ima go build a framework for this, back in a couple months" is usually a non-starter. Also from reading this thread I am still convinced that you cannot jam process down people's throats and there is no single solution. What you can do is create a tone deaf hated ass-backwards process that make people quit the company.

flash42 9y ago

What do you mean by "chaotic" and "troublesome" environment. Also I would be interested in how waterfall is helpful in those cases.

w0m 9y ago
Not OP, but I read that as the codebase is compartmentalized poorly. Agile works best when you can dip in, fix something small, and move on. If you need to change half the codebase to do a small thing; it may make sense to combine multiple small changes together. "While you're in there...". I do consider that an environmental 'code smell' though.

NittLion78 9y ago

For large efforts, I've always subscribed to "define waterfall, build agile". If you don't really hammer away up-front on all the possible avenues stakeholders want to explore in an end product and get those fully listed out and vetted before even the first line of code is written, then the "agile" portion should be simply changing directions on which of those things are considered most critical to delivering a minimum viable product based on where you currently are in the overall effort. Too often real work begins to get something concrete for stakeholders to react to (the general point of Scrum & Agile) while losing sight of the ultimate goal because it was never really defined very well to begin with. That just means more rework. Some rework is unavoidable, but so much of it is. You can control which mountain you want to climb and you can and should select which face of the mountain makes most sense to use as your path up it, but have a way to move laterally to a safer path up if the weather goes south.

bahmboo 9y ago
Product owner says build feature x this iteration by way of showing progress. Customer has explicitly said they are only interested in y. Whole team knows that x will have to be completely tossed out when building y. That's when agile fails. If you know what you are building it's a good idea to take that into account.
- NittLion78 9y ago
  Agreed. That's the sort of rework that I think can be avoided by a good partnership between the PO and the stakeholders in the nascent stages before physical work begins. I guess the reason why this happens is this weird psychological block in people's minds that software is totally mutable and flexible and therefore can change to whatever you want it to be, even after the fact. You'd never go into that mindset when building a physical structure, but the amount of re-architecture required to enact such changes in software can be just that monumental.
  - bahmboo 9y ago
    I was able to break the impasse and build trust by getting PO to agree to architectural deliverables in a sprint. He was skeptical but with some sort of defined behavior for acceptance he was OK with it. Saying "ima go build a framework for this, back in a couple months" is usually a non-starter. Also from reading this thread I am still convinced that you cannot jam process down people's throats and there is no single solution. What you can do is create a tone deaf hated ass-backwards process that make people quit the company.