The Corruption of Agile
drdobbs.com
drdobbs.com
Agile works fine. Software engineering methodologies don't kill projects, managers kill projects.
Rather, people kill projects.
We've all seen plenty of projects that were brought down by others than just managers, incl. developers.
People, and usually these are managers, are what kill projects ultimately. But the methodologies, or lack thereof, are the weapon the people use to kill projects.
It's the very consultants that are now blamed for corrupting Agile that made Agile popular. Agile wouldn't be a thing without the feedback loop of the industry it spawned.
Everyone believed, and one day they stopped believing. It's as if perfect "Agile" was nothing but a figment of people's collective imagination.
I've always had a skeptical eye about all this. Some useful things, nothing new, just a fresh coat of fancy buzzwords used to re-invent common sense.
Because it's time to start to invent new Bullshit™ marketing terms.
Anyone remember XP? You can find more of them here
http://en.wikipedia.org/wiki/Software_development_methodolog...
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs."[1]
[1] http://www.drdobbs.com/architecture-and-design/interview-wit...
Frankly half the references to people in the interview requires learning about hypertext from an academic perspective. Still fun to read.
Not surprised Agile was developed in Utah, the home of the best MLM schemes.
And unlike others have said in this thread it has not been around for 10 years. It has been around for almost 20.
Why "Agile is what it is" is because no one could stomach the proper way to do these individual methodologies, so they just dropped process altogher and called it Agile. Then on the other side you've had loons for several years now selling certifications.
Don't diss on Agile. There is no Agile. There are remarkable methodologies called XP, Scrum, Kanban, Lean, etc. and great people and histories behind them. Read and learn about them.
I think XP's original stories and tasks on note cards in planning meetings were a better way to shorten tasks than Scrum leaving that open though- time estimation can be a problem in Scrum without proper planning.
How's this for an alternative experience: I was coaching a Scrum team once (note I'm not an agile consultant, I just happened to be in the wrong place at the wrong time) and it led to fewer meetings. The rule was there was one fifteen-meeting standup meeting daily, and otherwise all team members were freed from meetings - they worked on delivering software 80% of the time.
Most communications were short impromptu discussions in the product room related to the current sprint, where devs could talk to the product owner, or the business analysts, or the testers, (who were all living in that room too), or the come-and-go liasons that were protecting the core team from meetings with the outside organization, etc.
Sometimes the impromptu discussions led to longer design or requirements discussions as the product owner/biz analysts taught the solution domain to the developers, or the developers explored the constraints or opportunities to rework parts of their architecture to the product owner. These were focused primarily on the current sprint needs with an eye on the overall backlog to detect if big features were coming, or there was a need for a major refactoring or architectural change. I wouldn't call these "meetings": these really were "design sessions", probably the most integral part of building working software.
After each two-week sprint there were 3 meetings: on Friday, a one-hour demo for outside executives to see progress, a one-hour post-mortem ("how would do do things better, what technical debt did we accumulate, etc.") , and on Monday, a two-hour planning session for the next sprint (which replaced the usual standup).
That's 8 hours of "management meetings" in an 80 hour period, or 10%. Not bad, in my experience. The other 10% would be for personal stuff that happens (doctor's appointments, everyone gets distracted by a YouTube video, mandatory town halls, etc.)
So, combine the above with a bunch of stickies on the wall to track progress, a backlog of features, and (most importantly) a product owner with authority to make decisions... that's Scrum, in my experience. There's really not a lot to it.
I don't think this is what you likely experienced. What did you experience that you hated? The hardest part is having a product owner take responsibility for the priorities & trade-offs, that also has enough clout or political protection in the broader organization to make (potentially wrong) decisions. If you're missing that, you get meeting explosion, as people point fingers and spin their wheels.
I've been involved in half a dozen projects that adopted varying sorts of that process, from small teams to massive juggernauts, and never once have I seen it not result in people tripping over each other or railing against the process.
Were those the result of poor implementation? To varying degrees, absolutely. But these and similar experiences from many people I know, coupled with the alarming degree of "if it's going poorly they're doing it wrong" from proponents, leave me with the firm conviction that this isn't just a constantly-abused practice. It's a set of tenets that apparently worked in principle for someone at some point but simply are not suited for the projects and environments I've encountered or discussed with colleagues.
People will dismiss that, which is fine (anecdotes are anecdotes, even in quantity), but I'd call such a range of practical failure pretty damning for something that's supposed to be so enabling.
Of course you'll never hear a consultant talk about that, because there is no shortcut to good craft. So they'll usually resolve to violate the root principle of Agile upfront and focus on tools and processes rather than on individuals and interactions.
To me this would suggest a good design in the first place, rather than a load of automated tests. Maybe waterfall is more agile than agile...
This kind of change is, experience has shown, a major source of the "requirements problem" which was noted as far back as the 1970s.
Waterfall methods (except, perhaps, the small unit of work iterated waterfall approach that is sometimes seen as a way of being agile and often criticized by practitioners of, particularly, Scrum as not-agile) aren't equipped to deal with this kind of change.
But Agile isn't a set of methods, it's an approach to selecting methods. So, it's possible -- though perhaps unlikely -- that for certain teams in certain circumstances Waterfall is more Agile than, say, Scrum or XP.
There is a difference between agile (i.e. the root of agility) and Capital-A Agile. Keeping in mind the key tenants of agile (little a) software development, it states `Individuals and interactions over Processes and tools`. This is the key difference between agile and Agile and the author is writing about. Yes, TDD is generally viewed as favourable, but itself is just a process and a set a tools (or methodology, whatever name you want to attach to it).
All agile is about is making working software and responding to change in the development process (and making changes quick/often). Has "agile" been corrupted? Yes (into the marketed "Agile".) Is little-a agile it a bad thing? No. I don't think anyone is saying that.
This whole "little-a vs big-A" is just another way for people to keep pushing the same thing they've been pushing to make money rather than admitting it's time to move on and admit Agile didn't work. Same as the "Scrum-but vs. Scrum" people and the evolving manifestos the Agile guys produce:
http://agilemanifesto.org/ http://jchyip.blogspot.com/2010/06/kent-becks-evolution-of-a... http://manifesto.softwarecraftsmanship.org/
Just people trying to keep their agile consultancies afloat after screwing people over for years.
Signed,
As the sibling comment states--Dave Thomas and topic article are making the distinction--they're advocating for agile, not money-making Agile as you vocally disapprove of.
p.s. I find it a little amusing (ironic, even) that your site was built by a company who apparently uses the things you do not approve of. Interesting choice, to be certain.
The truth is that most engineers are aware of what Agile is. It's a series of principles used to run a software development project. Agile isn't a set of tools or a movement or a methodology. It's only people who are selling tools or books or a viewpoint that talk like this.
From the trenches, I have never worked in Agile. I've worked with "agile" and I've worked in teams organized using agile principles. But, the orthodoxy has come from consultants, who were quickly shown the door.
from the article (my emphasis):
> Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.
And as for these old systems for airlines etc (which took many thousands of man days to produce), I wouldn't be shouting about them as great shining examples. Anybody who has had to integrate with these systems will be aware that they tend to be junk under the hood and they tend to fall apart if you throw internet levels of traffic at them.
From this article, I have to wonder when the writer last coded if ever. (I do however agree with the point that the 'agile' industry is a mess and that scrum in particular is often nearer waterfall than agile.)
As someone who's had a little bit of exposure to 20th century code, I'm not terribly impressed with it. It's neat that they managed to get anything at all done on such primitive hardware, but incredible feats of performance hackery isn't the same thing as software quality as we know it.
Someone explain to me the lost methodology of these programmer-Titans who made this "truly excellent, reliable code"?
p.s. Since when was the Internet a software product?
I've been on teams that have done "agile" and teams that didn't have any sort of named methodology at all, and I can't really find any correlation between that and the quality of their output. Frankly, it seems like it mostly comes down to how good the team members are, how good the managers are, and if they work in a good environment.
(And the internet is definitely a software product: TCP/IP, BGP, routers, DNS, etc. etc. Compared to all that, running a few cables is nothing.)
Yes; the references in the Wikipedia article on the Waterfall model [1] are good place to look.
That overstates what the Wikipedia article claims, which itself misrepresents the sources the article cites (e.g., the article it cites as the first use of "waterfall" does not use it in negative sense; it uses it descriptively -- while it does discuss the existence of a quality-of-requirements problem in software development (investigation of whether that perceived problem was real is the point of the paper), it doesn't place the blame for it on the waterfall model.
Anyhow, my point upthread was that the sources cited in the article themselves are good if you want to understand the model of the time. (From those, it also looks like another good source would be MIL-STD 490 and/or MIL-STD 483, but I haven't had any luck finding them, the closest I've been able to find is MIL-STD 490A, which replaced 490 in 1985.)
It's like a religion. Some folks like guidelines, some folks like rules. :)
> It's like a religion.
Is it any wonder that consultants have turned it into something that they need to show you how to do?
I'd argue that Lean as a metamethodoloy is probably the best concrete approach to realizing Agile principles (even though it didn't grow out of those principles, exactly, though it comes from a conceptually closely related place), including the avoidance of getting locked into a methodology, since Lean includes continuous review and improvement of process.
Having to use a term like: "metamethodology" is crazy.
Check out http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ for a reality check about Agile from one of its inventors. I quote:
"However, since the Snowbird meeting, I haven’t participated in any Agile events,1 I haven’t affiliated with the Agile Alliance, and I haven’t done any “agile” consultancy. I didn’t attend the 10th anniversary celebrations.
Why? Because I didn’t think that any of these things were in the spirit of the manifesto we produced. Having conferences about agility is not too far removed from having conferences about ballet dancing, and forming an industry group around the four values always struck me as creating a trade union for people who breathe.
And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
So I think it is time to retire the word “Agile.”