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?
There is not much to argue about in the Manifesto. Pretty much truisms. My only criticism is: 'Management won't get it, will only see the parts they like. If they got it, they wouldn't need it. If they need it, they won't get it.'
IMHO the key part of the manifesto was 'hire competent enthusiastic individuals'...which can be used to validate claims of agility. Those people DON"T work for industry average. If an organization is paying industry average, it _cannot_ be agile. Most likely it's 'agility' amounts to management's ability to maintain a bidirectional circle jerk.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.
"First they came for the slanderers and i said nothing."
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
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."
> And all of those external groups are set up to work waterfall.
Or, in my experience, they are often set to work only through a manager. Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced of the priority and feasibility before a question can even be asked about the available tools. Attempting to do "agile" in this kind of structure is disastrous, because even if a team accomplishes its designated tasks, nothing else is ready. And by the time the other teams are ready, the original work is no longer relevant.
I've no overall solution for this. I and my colleagues have, on occassion, been able to coordinate multi-department work under the guise of "external consultants", and been applauded for helping.
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.
Does this remind anyone of the "No True Scotsman" falacy? https://en.wikipedia.org/wiki/No_true_Scotsman
No true implementation of Agile fails. ... but my organization's implementation of Agile is failing
Then your organization is not doing a true implementation of Agile.
(Personally I find agile, even when done well, is much better than any alternative I've worked with so far... I just found the logical fallacy interesting.)
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.
I've never gotten Agile.
Our company doesn't use Agile anything. Strictly speaking, it's waterfall - we get a project from a customer, and we (engineers, sales and customer) work hard figuring out a list of requirements (we have to know what we're building, after all). This can take a little while - often engineering will scrap a list of requirements, step back, and ask the customer "what are you REALLY wanting here?"
As in, the customer gave us a list of stuff, but we stepped back, asked what they really wanted in the end (i.e., we go from the detailed view to the 10,000 foot view) This makes it possible to see if there is a better way to accomplish what the customer actually wants.
Then once we have requirements, we start building. Weekly, we'd meet with the customer and provide status updates, and the customer can redirect our efforts - perhaps a priority changed, or it turns out the customer doesn't want something anymore, and we work on new stuff. When something is complete, or a milestone reached, we cut a release and give the customer time to play with it and redirect our efforts again. Lather rinse repeat.
We have no "sprints" or tasks to do in a sprint - we have a list of what the customer wants done, and for the most part, those tasks take far longer than most sprints. (We have had many customers who do Agile and asked about what we'd do in the sprint, and we'd have to explain that the feature they want can't be broken down into one week work periods - it's a task that will take 3 weeks. We could break it into meaningless subtasks but that makes a huge assumption that you can work on a subtask alone - most of the work in a task is closely related so you may work on subtask A, switch to subtask B because A needs a modification in B, then go back to A, switch to C, etc.).
'
For the most part, it works - customers are generally quite happy, they know where the sore points are and we fix them immediately, and it's happened that many projects start out as a tiny little one that grew into a huge multi-year thing as customers want to try us out, are satisfied and impressed with our work and then give us more bits and pieces to do.
And no, our releases are on the order of once a month or so - the systems are complex enough that builds can take a day or so (often customers get source code, but some parts they can't because it requires licensing they don't have, so we have to make partial binary builds. And yes, we test to make sure those actually build). And there's also a QA process too to ensure no regressions. Customers cannot skip QA (builds often signify milestones), but they can get "early releases" which mean they get builds as soon as they hit QA with the caveat that some things may be broken And it does mean sometimes we've halted the release because of a showstopper and take time to fix it and re-release.