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.
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
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.
At every place I've worked, including the company I now own, the developers haven't been the ones that decided on the development process. The fact that they haven't decided has either been because no one actively decided, and management provided a default choice, or because management actively made a decision regarding the development process (either due to business needs, or basically arbitrarily.)
So, I believe the question of whether or not developers should abandon Agile is based on the false pretense that developers typically are able to make a decision. I don't believe that they are able to decide which development methodology they subscribe to, in general.
Agile doesn't deliver what the business wants which is to turn coding into non-creative work where you know almost exactly how long it takes to get from A to B and exceptions have explanations like traffic accidents or construction work. Nothing ever will but it won't stop them from trying so the best Agile can do is shield the developers from impossible tasks and meaningless meetings so they can spend time on actually doing development.
The first shield is the product owner, a ton of people want things and they'll go through all sorts of channels with competing priorities and sneaking in pet features. Shut them down, make that one channel in and one non-developer resource they can talk to if they're not happy with what they're getting. And no, there's no point in re-prioritizing things daily once every two weeks is fine for everything but hair-on-fire emergencies. The second shield is the scrum master, I'm currently one and my main job the way I see it is to maximize the number of hours my team members actually get work done on the things they're supposed to be working on. Particularly all fuzzy meetings called to discuss things where I say "You figure out what you want first from a business perspective, then let's talk solutions" or that are more or less status/re-planning meetings where I say "The quickest way to get it done is to let the ones working on it work on it."
It's not particularly Agile-specific, reality it's about two simple things, what should I be working on and let me be so I can do my f*cking job. Whether it actually works better for planning than iterative waterfall, meh... I've always said you should try to think and explain as far ahead as reasonable, like is this part of the functionality/structure you'd like to have in the end. You don't build a skyscraper by building a one-story building and then building one more story on top, if you know it's going to need to support 50 stories then tell us now.
Live today, because you never know what tomorrow brings
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).
Beyond the headline, here's what he says:
1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.
2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)
3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.
Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."
"First they came for the slanderers and i said nothing."
Ideally, yes. My first 20 or so years as a dev I worked in environments where we were "self-organizing" but we weren't delivering small increments. Instead we have fairly long term goals (usually for a yearly release) and then each dev or small group of devs figured out how to get it done. And amazingly enough the work got done and the product was coherent.
Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed. And this is at 3 separate companies.
Agile (whether Scrum, Extreme Programming, whatever) just seems to be one of those things that sounds good, that has some good ideas, but ultimately comes with its own set of problems. As Fred Brooks said, there's no silver bullet.
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.
Agile is a good concept - I've included the Agile Manifesto in my courses for years. The problem is: Agile is no better than the people implementing it.
I've just witnessed this (again) in a recent project. The PM had just gotten a promotion, but he had to finish this project. He used Agile as an excuse to basically abdicate (or maybe he was always a lousy PM), and he let the developers and the customer talk together directly. The customer thought this meant that all of their ideas were flowing into the project every two weeks. The developers thought the customer was changing requirements every two weeks. The result was inevitable: a project that is 3/4 finished everywhere, totally finished nowhere, and is now likely to land both companies in court.
Crappy management is not saved by Agile. Given good management and a good development team, any methodology can work - pick the one best suited to the project and the people.
Enjoy life! This is not a dress rehearsal.
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.
Developers will write some unittests, but just enough to test some new functions here and there in different components.
Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.
As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.
The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.
The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.
The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.
Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.
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.