4 ms·

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project ma

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management". That's not true at all. The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on. Therefore, the classical project structure followed by grey beards does not make any sense in software development. What does make sense is to acknowledge that requirements specified by the client do and will change, and it's better to adapt to the client's needs and get everyone involved in the project. Therefore, projects are organized in small bite-size units of work that gradually contribute to implement a product based on the feedback received by all stakeholders, and that these small bite-size units of work are implemented in small time windows. These units of work are short-lived and the amount of effort invested in planning is limited to the goals set forth for that unit of work, which need to be manageable.

s73v3r_ 8y ago
"The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on." I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.
- geezerjay 8y ago
  > I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are. You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices regarding the design. None of these assumptions hold even in conventional engineering projects. The only reason why waterfall processes is used in conventional engineering projects is that it's so expensive to fix problems arising from these sources of failure that it's perfectly fine to deliver working but inadequate solutions.
  - s73v3r_ 8y ago
    "You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements" No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project. "None of these assumptions hold even in conventional engineering projects." Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want. One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.
specialist 8y ago
"...there is no well defined goal nor can one exist." Consulting is the pejorative we gray beards used for that activity. You reminded me of another pithy throwaway line: Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.
- srtjstjsj 8y ago
  So, agile improved outcomes? I'd love to have 1 big win a year and 11 cheap losses, than 5 expensive losses and then bankrupt before a big win.
- geezerjay 8y ago
  > Consulting is the pejorative we gray beards used for that activity. Those hypothetical gray beards may come up with all the pejorative terms they need, but that only hides the fact that they are entirely oblivious to the reality of running a successful software project, one which actually meets the client's requirements and delivers working products. Therefore, they spend their time coming up with pejorative terms while they insist in wasting their time and effort forcing the proverbial square peg (waterfall) in a round hole (software development projects) > Agile didn't improve outcomes, That statement is patently false. No one can make that claim with a straight face in a world where paying customers make it their point to change fundamental requirements on a weekly basis. In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a very unhappy client that may even feel that he has been played. > it just reduced the cost of failure A sequence of small failures that converge to the client's needs is a whole lot better than a single unmitigated major failure that's ensured by following Waterfall methodologies.
  - specialist 8y ago
    You and I have very different expectations. Long ago I decided to walk away from work lacking clarity. I’m a dev, not a therapist. re Outcomes, my data is old, I’d love to proven wrong. I’ve read (elsewhere) that high(est) functioning orgs like google, facebook, netflix have made great progress. But the rest of us are just banging the rocks together. PS- PMI & critical path, as I’ve done it, is the opposite of waterfall. One hard earned trick is proper ordering of the work. eg, after a project kickoff, first deliverable is the press release, second deliverable is a demo (even if its entirely faked).

s73v3r_ 8y ago

"The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on." I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

geezerjay 8y ago
> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are. You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices regarding the design. None of these assumptions hold even in conventional engineering projects. The only reason why waterfall processes is used in conventional engineering projects is that it's so expensive to fix problems arising from these sources of failure that it's perfectly fine to deliver working but inadequate solutions.
- s73v3r_ 8y ago
  "You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements" No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project. "None of these assumptions hold even in conventional engineering projects." Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want. One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.

specialist 8y ago

"...there is no well defined goal nor can one exist." Consulting is the pejorative we gray beards used for that activity. You reminded me of another pithy throwaway line: Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.

srtjstjsj 8y ago
So, agile improved outcomes? I'd love to have 1 big win a year and 11 cheap losses, than 5 expensive losses and then bankrupt before a big win.
geezerjay 8y ago
> Consulting is the pejorative we gray beards used for that activity. Those hypothetical gray beards may come up with all the pejorative terms they need, but that only hides the fact that they are entirely oblivious to the reality of running a successful software project, one which actually meets the client's requirements and delivers working products. Therefore, they spend their time coming up with pejorative terms while they insist in wasting their time and effort forcing the proverbial square peg (waterfall) in a round hole (software development projects) > Agile didn't improve outcomes, That statement is patently false. No one can make that claim with a straight face in a world where paying customers make it their point to change fundamental requirements on a weekly basis. In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a very unhappy client that may even feel that he has been played. > it just reduced the cost of failure A sequence of small failures that converge to the client's needs is a whole lot better than a single unmitigated major failure that's ensured by following Waterfall methodologies.
- specialist 8y ago
  You and I have very different expectations. Long ago I decided to walk away from work lacking clarity. I’m a dev, not a therapist. re Outcomes, my data is old, I’d love to proven wrong. I’ve read (elsewhere) that high(est) functioning orgs like google, facebook, netflix have made great progress. But the rest of us are just banging the rocks together. PS- PMI & critical path, as I’ve done it, is the opposite of waterfall. One hard earned trick is proper ordering of the work. eg, after a project kickoff, first deliverable is the press release, second deliverable is a demo (even if its entirely faked).