3 ms·

Should developers abandon Agile?

10 points by MilnerRoute 8y ago

mindcrime 8y ago
The obvious corollary to this would be "In favor of what exactly?" For all the bad things you can say about "agile" (which isn't even a "thing" to begin with) one has to ask "what's the better alternative?" Do you want to adopt Waterfall? RUP? Most of the other well known methodologies (XP, Crystal, AUP, etc.) are "agile" methodologies anyway. If anything, I'd argue that developers need to start pushing back when brain dead managers and idiotic consultants come along and push ideas as "Agile" that are very explicitly *not" "agile" in either the "big A" or "little a" sense, and demand that management actually learn what the Agile Manifesto says and apply those principles from the top down.
mlthoughts2018 8y ago
Don’t use any named, taxonomic workflow process at all. Not Agile, not Scrum, not Kanban, not Waterfall, not RUP, nothing. Instead, organically mix and match and customize any bits or pieces of any of them, along with ad hoc, situation-specific workflows, as needed — as determined by the specific situation, deadline, requirements, personnel and preferences involved. If you’ll benefit from spending time on exact software estimates or a retro meeting, do it. Two months later if people need to take a month for a more complex prototype, rendering 2-week increments silly and wasteful in terms of overhead, then change how you work and skip those parts for a while. When process is fixed by any prescriptive method that at the heart attempts to track progress and dictate one specific cadence or manner of working and communicating about progress, it devolves to something like fractal measurements of the coast of Britain. You think your measurements are getting more and more precise, and you can come up with whatever surface area of progress to make it look like you are measuring more and more. But no matter what, it becomes about the prescribed system, and stops being about common sense, fluid, adaptable, day-by-day adjustable workflow tailored to what trusted workers are telling you they need. Creative mental labor is just not amenable to Taylorism. It just doesn’t work. Doesn’t matter which Fancy Name you give it. You have to give up the idea of any fixed, prescriptive method, and just use constantly-updateable local conventions. (Of course this assumes you are interested in productivity. Often the bureaucratic adoption of things like Agile is about creating middle management surface area for political power struggles and/or corporate surveillance. Companies agree to pay the cost of productivity lost to the workflow drag in exchange for creating Dutch books of story points or to be able to roll up what are effectively contextless time sheets to executives who believe it equates to some type of accountability. I don’t have much advice in these cases; only interested when the assumption is to optimize productivity.)
pards 8y ago
Ron Jeffries' original article can be found here. https://ronjeffries.com/articles/018-01ff/abandon-1/ https://ronjeffries.com/articles/018-01ff/abandon-1/

10 points by MilnerRoute 8y ago

The obvious corollary to this would be "In favor of what exactly?" For all the bad things you can say about "agile" (which isn't even a "thing" to begin with) one has to ask "what's the better alternative?" Do you want to adopt Waterfall? RUP? Most of the other well known methodologies (XP, Crystal, AUP, etc.) are "agile" methodologies anyway. If anything, I'd argue that developers need to start pushing back when brain dead managers and idiotic consultants come along and push ideas as "Agile" that are very explicitly *not" "agile" in either the "big A" or "little a" sense, and demand that management actually learn what the Agile Manifesto says and apply those principles from the top down.

mlthoughts2018 8y ago

Don’t use any named, taxonomic workflow process at all. Not Agile, not Scrum, not Kanban, not Waterfall, not RUP, nothing. Instead, organically mix and match and customize any bits or pieces of any of them, along with ad hoc, situation-specific workflows, as needed — as determined by the specific situation, deadline, requirements, personnel and preferences involved. If you’ll benefit from spending time on exact software estimates or a retro meeting, do it. Two months later if people need to take a month for a more complex prototype, rendering 2-week increments silly and wasteful in terms of overhead, then change how you work and skip those parts for a while. When process is fixed by any prescriptive method that at the heart attempts to track progress and dictate one specific cadence or manner of working and communicating about progress, it devolves to something like fractal measurements of the coast of Britain. You think your measurements are getting more and more precise, and you can come up with whatever surface area of progress to make it look like you are measuring more and more. But no matter what, it becomes about the prescribed system, and stops being about common sense, fluid, adaptable, day-by-day adjustable workflow tailored to what trusted workers are telling you they need. Creative mental labor is just not amenable to Taylorism. It just doesn’t work. Doesn’t matter which Fancy Name you give it. You have to give up the idea of any fixed, prescriptive method, and just use constantly-updateable local conventions. (Of course this assumes you are interested in productivity. Often the bureaucratic adoption of things like Agile is about creating middle management surface area for political power struggles and/or corporate surveillance. Companies agree to pay the cost of productivity lost to the workflow drag in exchange for creating Dutch books of story points or to be able to roll up what are effectively contextless time sheets to executives who believe it equates to some type of accountability. I don’t have much advice in these cases; only interested when the assumption is to optimize productivity.)

pards 8y ago

Ron Jeffries' original article can be found here. https://ronjeffries.com/articles/018-01ff/abandon-1/ https://ronjeffries.com/articles/018-01ff/abandon-1/