4 ms·

The agile community is currently an amorphous blob of people connected by words like "Agile!", "Scrum", "TDD" and so on. Agile was stolen from its creators and

by blub 8y ago

The agile community is currently an amorphous blob of people connected by words like "Agile!", "Scrum", "TDD" and so on. Agile was stolen from its creators and mutated into a corporate version - which I have to say I find pretty darn funny. Point is, that info is certainly not included in any of the Agile resources I've seen. The only one that handles some of this is Ambler's D.A.D, but I didn't bother reading that for a simple reason: after seeing various Agile methods (mostly Scrum) fail so much, I've come to the conclusion that Agile development processes do not represent a real-world solution. There's always an excuse why Scrum fails in practice, but in the end it requires such a paradigm shift from our typical development approaches in order to succeed, that it's about as useful as a diet plan that only works on super-athletes. XP is in zombie mode for a decade, Scrum is only good for mobile apps and small websites, Kanban is not even a way of making software. What are we left with? Scaled Agile, LeSS, which even the original Agile people bitterly complain about? These won't work either, but I know some consultants make a crapton of money selling them to corps.

dajohnson89 8y ago
just curious -- what do you recommend?
- blub 8y ago
  I find the whole idea of one size fits all processes dubious. I don't have a solution for this and I haven't seen any such process work reliably in large scale projects. Scrum quite clearly can't tolerate the peculiarities and pressures of a large scale mixed HW-SW projects for instance. Those will turn the whole sprint / PO / independent SW team arrangement into mush. A long time ago I did some waterfall-RUP mix which didn't feel worse compared to the Scrum I did recently, but it did result in better documentation and traceability. If I had the chance I would take bits and pieces from several processes and experiment to see which work for a particular company and department, perhaps even at project level. Things that come to mind: Kanban-like task management, regular retrospectives, an exploratory design phase at the beginning, documentation (FFS!), history-based estimation + careful team-private time tracking, a project manager that doesn't also manage the team and doesn't have too much power, regular customer-feedback cycles, CI/CD pipeline, etc.
shandor 8y ago
> I've come to the conclusion that Agile development processes do not represent a real-world solution. I think one of the problems regarding this whole discussion, whenever it stirs up, is that Agile (as defined in the original manifesto) is explicitly not about any particular processes, but still most of the critique against Agile seems to actually be against different kinds of "agile processes". The manifesto explicitly states "Individuals and interactions over processes and tools". In real world, one of course needs actual processes, and all kinds of consults are trying to ride the wave to lucrative contracts. But since the Agile Manifesto is about values, not processes, you cannot steal it from its creators. You can pervert the meaning and utilize some braindead processes in your company and call them "agile", but that doesn't lessen the worth of the original values. I know that that's a highly unsatisfactory answer, a kind of a cop-out, but I think applying more to Agile than it's meant to be is part of the problems surrounding it today. Edit: those "you"s are meant for passive voice. No personal offense or commentary meant.
- blub 8y ago
  The road from Agile values to having something that can be used to ship quality software is way too long. "Eat well and do sports" is correct, yet ineffectual advice, since many countries still have a big problem with obesity, diabetes and other modern diseases. There are two things undermining "the values" in practice: 1) The economic and social environment doesn't encourage an engineering/scientific approach to SW development. Nor does it encourage eating well or having an active lifestyle. 2) People need a lot of help to implement those fuzzy, high-level values and will always reach for some process / diet / plan. All things considered, it's probably better to be agile, but how do you actually deliver a quality, successful SW project? Let's talk about that instead of fuzzy old Agile.
  - shandor 8y ago
    I agree with your conclusion fully. Also your link to "eat well and do sports" is kind of exactly what I was after. I mean no one is saying that eating well is bad for your health, right? What I was trying to convey is that I think similarly of the Agile Manifesto itself. Because we shouldn't infer that eating well is bad because a lot of people try to eat well and are still obese, we shouldn't infer that Agile as in the Manifesto is bad because lots of companies get burned by Scrum. We should be coming to conclusions like "hey, maybe this Scrum thing we tried is shit, let's try some other process that seems to align with these fuzzy agile values we believe in". The problem I have with the current discourse around the matter is that as long as we keep bashing "The Agile Values" when we mean "agile processes as implemented in framework ZZZ", we are not having the discussion of "hey, which process would align better with these values while letting us ship quality software rapidly".

by blub 8y ago

dajohnson89 8y ago

just curious -- what do you recommend?

blub 8y ago
I find the whole idea of one size fits all processes dubious. I don't have a solution for this and I haven't seen any such process work reliably in large scale projects. Scrum quite clearly can't tolerate the peculiarities and pressures of a large scale mixed HW-SW projects for instance. Those will turn the whole sprint / PO / independent SW team arrangement into mush. A long time ago I did some waterfall-RUP mix which didn't feel worse compared to the Scrum I did recently, but it did result in better documentation and traceability. If I had the chance I would take bits and pieces from several processes and experiment to see which work for a particular company and department, perhaps even at project level. Things that come to mind: Kanban-like task management, regular retrospectives, an exploratory design phase at the beginning, documentation (FFS!), history-based estimation + careful team-private time tracking, a project manager that doesn't also manage the team and doesn't have too much power, regular customer-feedback cycles, CI/CD pipeline, etc.

shandor 8y ago

> I've come to the conclusion that Agile development processes do not represent a real-world solution. I think one of the problems regarding this whole discussion, whenever it stirs up, is that Agile (as defined in the original manifesto) is explicitly not about any particular processes, but still most of the critique against Agile seems to actually be against different kinds of "agile processes". The manifesto explicitly states "Individuals and interactions over processes and tools". In real world, one of course needs actual processes, and all kinds of consults are trying to ride the wave to lucrative contracts. But since the Agile Manifesto is about values, not processes, you cannot steal it from its creators. You can pervert the meaning and utilize some braindead processes in your company and call them "agile", but that doesn't lessen the worth of the original values. I know that that's a highly unsatisfactory answer, a kind of a cop-out, but I think applying more to Agile than it's meant to be is part of the problems surrounding it today. Edit: those "you"s are meant for passive voice. No personal offense or commentary meant.

blub 8y ago
The road from Agile values to having something that can be used to ship quality software is way too long. "Eat well and do sports" is correct, yet ineffectual advice, since many countries still have a big problem with obesity, diabetes and other modern diseases. There are two things undermining "the values" in practice: 1) The economic and social environment doesn't encourage an engineering/scientific approach to SW development. Nor does it encourage eating well or having an active lifestyle. 2) People need a lot of help to implement those fuzzy, high-level values and will always reach for some process / diet / plan. All things considered, it's probably better to be agile, but how do you actually deliver a quality, successful SW project? Let's talk about that instead of fuzzy old Agile.
- shandor 8y ago
  I agree with your conclusion fully. Also your link to "eat well and do sports" is kind of exactly what I was after. I mean no one is saying that eating well is bad for your health, right? What I was trying to convey is that I think similarly of the Agile Manifesto itself. Because we shouldn't infer that eating well is bad because a lot of people try to eat well and are still obese, we shouldn't infer that Agile as in the Manifesto is bad because lots of companies get burned by Scrum. We should be coming to conclusions like "hey, maybe this Scrum thing we tried is shit, let's try some other process that seems to align with these fuzzy agile values we believe in". The problem I have with the current discourse around the matter is that as long as we keep bashing "The Agile Values" when we mean "agile processes as implemented in framework ZZZ", we are not having the discussion of "hey, which process would align better with these values while letting us ship quality software rapidly".