Slashdot Mirror
Should Developers Abandon Agile? (ronjeffries.com)
An anonymous reader quotes InfoQ:
Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...
"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.
But what do Slashdot's readers think? Should developers abandon Agile?
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...
"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.
But what do Slashdot's readers think? Should developers abandon Agile?
This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.
But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."
I disagree. I think it has a lot of good theory behind it. The problem is, the 'do more by doing less' concept *really* has to be embraced by the entire organization; especially those at the top. Too often it isn't. If you work in a place like this, removing Agile probably won't help much.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
It's got a manifesto.
Those who have to live with it want to escape it.
It slowly destroys organizations that use it.
Despite always failing "real Agile has never been tried right".
And yet, you can do lots and lots of stories, and in the end you have a big steaming pile, because the stories don't add up to anything. I recently worked on a product like that. There was one "feature" that I backtracked to about 8 different stories, each of which incrementally added a sub-feature that, ON ITS OWN, sounded like a good idea. But the sum total was almost impossible to understand, and I'm sure people blamed the devs, not the managers who insisted on the "stories".
I've worked in both a small shop (under 20 developers) and a decently large organization (more than 400 employees) although outside the dev shop. I had positive agile experiences in both places.
What I've found is that agile works given a few conditions:
1) The organization actually adopts agile, and embraces it.
2) The owners of the development both understand agile and have the political power to enforce it.
3) The devs understand agile and can thrive within it.
When all that happens, and I know that's not often, Agile can shine. I've seen it, and I've really appreciated it. I get how it can go terribly wrong, but it can and does work, if the environment allows it.
Velociraptor = Distiraptor / Timeraptor
Stop believing that if you could only find that one perfect methodology, your mediocre team of developers will create greatness. It has never worked in the past, and "agile" (however you define it) is no different. Project managers and business types are addicted to this fantasy, because accepting the reality would lead to extreme cognitive dissonance.
As always, there are no silver bullets. Hire smart people, give them autonomy (they will adopt their own methodologies as needed), keep teams small, and design solutions that are as simple as possible (but no simpler). Domain knowledge and close communication with the end users helps. But all that is no guarantee of success either.
Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot.
Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works.
Because most don't actually do agile.
I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall. You've got the UI designer who wants to design the whole experience up front. You've got the data modeler and DBA who both want to know exactly what data you will be using up front. You've got the architect who wants the full design documented so they can spend 10 minutes looking at it and give you an approval. You've got the project manager who wants to know exactly how long all the development is going to take. So you end up having to do big-design-up-front in order to work with all these external groups.
A lot of companies say they want developers to do agile, but they need to realize that agile requires changes throughout the organization. It's not something that developers can just do by themselves.
Poettering! Don't try to sneak away.
Have gnu, will travel.
Agile undermines ownership of the project. When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all. You feel like an underappreciated cog (and at many companies, you are!). You certainly don't care if the project succeeds or fails. You just want to get your sprint finished as quickly and easily as possible so you can go home. And, agile in practice reinforces that, because that is how management sees it. It should come as no surprise that taking your expensive developers and turning them into what feels like an H1-B code mill will reduce quality and long-term efficiency. Programmers often do the job of a programmer despite being able to do the job of the manager who cannot do their job because they love building shit. If you take that passion out from under them, you will drastically reduce their output in the long term if you ask me. It might look like great velocity, but that's just a comforting lie management tells themselves (because I've never worked for a manager who had any experience programming... which is sad in and of itself).
Developers should abandon their tendency to be cargo cultists. Don't do things just because that's the way it's always been done. Don't do things just because someone labelled them Best Practice. Don't do things just because other people have done it and it worked out for them.
The only method that works is to try it out and see where it leads, be super observant about where the pitfalls start appearing, and give yourself enough leeway to try something else if it isn't working out.
Those who do not learn from commit history are doomed to regress it.
That's it, that's it exactly! I recently retired from 30+ years in IT, doing programming in all kinds of environments and all kinds of businesses, and I retired mostly because I felt I'd had all the joy finally beaten out of me. When I started, it was fun to make things that worked, that actually made the daily working grind better for the people who used the software. By the end, it seemed like the goal was to slurp down the buzzwords of the week, rather than making things that worked!
All the passion is gone from the industry, at least the parts I worked in. No methodology will make the soul-dead zombies, that are the programmers these days, able to build good things.
Nobody I have met has ever seen agile actually work. I have personal experience of a depressingly large number of projects where it did nothing other than annoy the engineers and waste their time.
When all you have is a hammer, every problem starts to look like a thumb.
Careful reading of your post... good one. Tech management is a self propagating delusion, they want it that way, they keep getting paycheques for basically just wanking. If projects got finished all kinds of bad things would happen, like successful engineering leads getting promoted above them. It's bad enough that the engineers get paid more. God forbid they get recognized for competence as well.
When all you have is a hammer, every problem starts to look like a thumb.
What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.
"First they came for the slanderers and i said nothing."
The parent post is a great example of the "You're Not Doing It Right" fallback of Agilists. Agile is something that works in teams that would have succeeded just as well with any other methodology that isn't downright insane, and something that is pretty damn difficult to actually get to work in most real-world situations. There's always a litany of excuses of how you're not doing it right, but no Agile proponent can ever quite exactly say how to make sure you *do* get it right either.
The problem was that the manifesto was common sense and stating plainly how good teams already behaved.
The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.
They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.
Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".
The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
XML is like violence. If it doesn't solve the problem, use more.
"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time.
A problem is that some work is monolithic in nature and cannot be partially released. This is particularly true the closer you get to the hardware side of things.
Agile fails when it tries to jump a chasm in three small steps.
Attempting to divide it into even smaller pieces isn't going to solve the inherent denial that some things cannot be split.
Nor that when something can be split, it doesn't mean it should, even under pressure.
Getting certifications for N components one at a time, for example, takes longer, costs more, and at the end, should you reach it, you need to get a certification for the whole anyhow.
Or you should not split security into a separate task that risks not getting done until there's been a release without security. That's bad. And I've seen it happen more than once.