6 ms·

Such negativity. It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agi

Such negativity. It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. Yes, it provides for measurement and close management oversight, but it also does not impose impossible schedules with locked requirements. Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. But where agile really shines is when the problem is poorly understood and the solution not well defined. In these cases agile can provide for project successes that would have led to certain failure in a waterfall world. It's likely not an overstatement that agile and iterative development has been the recipe behind web 2.0 and so much else in recent years.

clumsysmurf 5y ago
Projects were doing iterative development in the 50s, way before scrum or agile. “All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury) I think many of the agile principles remain largely unpalatable to your typical command & control org structure. One of the main premises of Agile, is letting people closest to the work decide how they want to work. Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull). At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.
rramadass 5y ago
Oh, Jeez; not this again. See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.
watwut 5y ago
I lived before agile came around. And bad the old days of waterfall are to large extend carricature. Maybe it existed in the horrible form agile advocates pretend, but I have no seen that. And for me, work was in fact more motivating before agile. Agile turned the work I really liked a lot into something you do for money. Agile at it best is tolerable. > Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.
- rramadass 5y ago
  >And the bad old days of waterfall are to a large extent caricature Very right! They were never true; mere blame-game when they screwed up something else. >It is micromanagement ritualized and it somehow leaves both customer and workers unhappy Well Said! Even stronger : A Ego/Power trip for people who can cut it as neither Developers nor actual Managers :-)
- rchaves 5y ago
  I'm really curious, could you expand on why do you think it was more motivating? Were there less micromanagement before agile?
  - rramadass 5y ago
    The book Why We Do What We Do: Understanding Self-Motivation by Edward Deci may give you some answers. The key thing a "Knowledge Worker" needs/demands is Autonomy over his own Work/Decisions (within the context of the larger problem). In the old days, we had the Freedom along with the Accountability. What Agile/Scrum has done is taken away our Freedom but by micromanaging our day-to-day activities has increased our Accountability. This is completely unjustifiable and unacceptable. PS: An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only - Bjarne Stroustrup.
  - watwut 5y ago
    I think it comes back to "autonomy, mastery, accountability". You was responsible for bigger chunks of work. You had more autonomy within that chunk - you could make at least some decisions independently. Whether they were bad or good, it was clear they were yours. You could also have some sense of control over your work - you could use own brain to plan and prioritize within that chunk. Consequently, you felt like you have done and achieved something. You also could create something coherent. Also, over time you became better and better at the thing you was doing. You was thinking about module or project as a whole. With agile, I feel mostly like cross between factory worker middle management politician. Every little detail has to be negotiated with multiple people and half success is guessing what is on their minds. You work on tiny tasks. You dont get sense of achievement, you just use your hammer to put in nail here, then paint a bit over there.
almeria 5y ago
It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. Probably because for most of us they never existed - and yes, of course I mean "pre-agile". This whole "before Agile it was all waterfall and no one could conceive of anything differently and oh my brothers, let me tell you what a nightmare it was" cant is just that - a cant, something people like to repeat without thinking about whether it has any actual validity in, you know, actual reality. In other words, a myth. There have always been good shops and bad shops; but like the sibling commenter said, (in the better shops) people have been working iteratively for decades and decades before the Agile Manifesto descended to earth on a ray of light, accompanied by angels. But where agile really shines is when the problem is poorly understood and the solution not well defined. Which problems people, again, had already been solving for decades and decades before the AM. Such negativity "Negativity" is not only an appropriate, but a healthy and necessary response to the never-ending stream of cargo-cult tripe and talking point nonsense that is Agile.
g051051 5y ago
> It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. I did. Scrum and "agile" are far, far worse, based on what I've seen and experienced. Those "bad old days" were heaven compared to the bizarre approach currently in vogue. I will be very happy when this fad passes as well. > But where agile really shines is when the problem is poorly understood and the solution not well defined. That's the problem...people think that you can just use "agile" and not worry about understanding the problem and developing a solid solution. You just start slamming out code and checking back with the customer, wasting huge amounts of time and effort.
Zigurd 5y ago
Waterfall planning + critical path analysis was too brittle for software projects. The choices were: 1. Frequent replanning, every 2-6 weeks 2. Stop replanning and try to meet an unrealistic schedule Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway. If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood. Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal. Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.

clumsysmurf 5y ago

Projects were doing iterative development in the 50s, way before scrum or agile. “All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury) I think many of the agile principles remain largely unpalatable to your typical command & control org structure. One of the main premises of Agile, is letting people closest to the work decide how they want to work. Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull). At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.

rramadass 5y ago

Oh, Jeez; not this again. See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.

watwut 5y ago

I lived before agile came around. And bad the old days of waterfall are to large extend carricature. Maybe it existed in the horrible form agile advocates pretend, but I have no seen that. And for me, work was in fact more motivating before agile. Agile turned the work I really liked a lot into something you do for money. Agile at it best is tolerable. > Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.

rramadass 5y ago
>And the bad old days of waterfall are to a large extent caricature Very right! They were never true; mere blame-game when they screwed up something else. >It is micromanagement ritualized and it somehow leaves both customer and workers unhappy Well Said! Even stronger : A Ego/Power trip for people who can cut it as neither Developers nor actual Managers :-)
rchaves 5y ago
I'm really curious, could you expand on why do you think it was more motivating? Were there less micromanagement before agile?
- rramadass 5y ago
  The book Why We Do What We Do: Understanding Self-Motivation by Edward Deci may give you some answers. The key thing a "Knowledge Worker" needs/demands is Autonomy over his own Work/Decisions (within the context of the larger problem). In the old days, we had the Freedom along with the Accountability. What Agile/Scrum has done is taken away our Freedom but by micromanaging our day-to-day activities has increased our Accountability. This is completely unjustifiable and unacceptable. PS: An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only - Bjarne Stroustrup.
- watwut 5y ago
  I think it comes back to "autonomy, mastery, accountability". You was responsible for bigger chunks of work. You had more autonomy within that chunk - you could make at least some decisions independently. Whether they were bad or good, it was clear they were yours. You could also have some sense of control over your work - you could use own brain to plan and prioritize within that chunk. Consequently, you felt like you have done and achieved something. You also could create something coherent. Also, over time you became better and better at the thing you was doing. You was thinking about module or project as a whole. With agile, I feel mostly like cross between factory worker middle management politician. Every little detail has to be negotiated with multiple people and half success is guessing what is on their minds. You work on tiny tasks. You dont get sense of achievement, you just use your hammer to put in nail here, then paint a bit over there.

almeria 5y ago

It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. Probably because for most of us they never existed - and yes, of course I mean "pre-agile". This whole "before Agile it was all waterfall and no one could conceive of anything differently and oh my brothers, let me tell you what a nightmare it was" cant is just that - a cant, something people like to repeat without thinking about whether it has any actual validity in, you know, actual reality. In other words, a myth. There have always been good shops and bad shops; but like the sibling commenter said, (in the better shops) people have been working iteratively for decades and decades before the Agile Manifesto descended to earth on a ray of light, accompanied by angels. But where agile really shines is when the problem is poorly understood and the solution not well defined. Which problems people, again, had already been solving for decades and decades before the AM. Such negativity "Negativity" is not only an appropriate, but a healthy and necessary response to the never-ending stream of cargo-cult tripe and talking point nonsense that is Agile.

g051051 5y ago

> It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. I did. Scrum and "agile" are far, far worse, based on what I've seen and experienced. Those "bad old days" were heaven compared to the bizarre approach currently in vogue. I will be very happy when this fad passes as well. > But where agile really shines is when the problem is poorly understood and the solution not well defined. That's the problem...people think that you can just use "agile" and not worry about understanding the problem and developing a solid solution. You just start slamming out code and checking back with the customer, wasting huge amounts of time and effort.

Zigurd 5y ago

Waterfall planning + critical path analysis was too brittle for software projects. The choices were: 1. Frequent replanning, every 2-6 weeks 2. Stop replanning and try to meet an unrealistic schedule Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway. If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood. Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal. Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.