I'm amused at how the whole Agile community is nothing but a hive mind. For 10 years they're all obsessed with how good Agile is. Then starting two weeks ago, they all think it's terrible.
Myself and others that have been writing on this recently aren't bashing the original values and principles that are in the Agile Manifesto. We are bashing how far we have all fallen from what matters and the industry of crap that has sprung up around it. These days, declaring you are Agile usually means you are a cowboy, but it sure sounds good to say anyway!
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 interesting how the community explanation is that some set of perfect ideals was "corrupted" by consultants. That actually happened fairly early in the process.
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.
It's interesting how Kay's "error-free internet" quote was truncated in this article. Here's a bit more of the quote:
"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]
Some of the better quotes are on page 2 of that interview: "One of the ways of looking at it is the reason that WYSIWYG is slowly showing up in the browser is that it's a better way of interacting with the computer than the way they first did it. So of course they're going to reinvent it. I like to say that in the old days, if you reinvented the wheel, you would get your wrist slapped for not reading. But nowadays people are reinventing the flat tire. I'd personally be happy if they reinvented the wheel, because at least we'd be moving forward. If they reinvented what Engelbart, did we'd be way ahead of where we are now."
Frankly half the references to people in the interview requires learning about hypertext from an academic perspective. Still fun to read.
Maybe we should just use Iterative and Incremental Development. Quietly being practised since the 1950s. Definitely not new or shiny enough to be commandeered by the hype merchants.
I really thought Agile was cool. Then I endured pointless meetings, meaningless planning estimation and observed how people make a career around preaching Agile. I quickly observed the real goal of agile is not to produce software, but rather to get people to use agile. Agile is about selling the cult membership, not actually doing anything interesting.
Not surprised Agile was developed in Utah, the home of the best MLM schemes.
Ok. First off, there is no "Agile". There was XP. There was Scrum. There was Kanban. etc. No Agile. Agile originally meant "more dynamic than Waterfall" and had a connotation of being able to handle change. If you've never worked on a large Waterfall project, which many of you haven't, you just don't understand how bad it was.
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.
Doing things in a list which allows reorder, choosing which items in that list will get done per time period, and communicating that in short time periods. That is a methodology of management which embraces change, not micromanagement. Scrum doesn't micromanage, managers do. If you are being micromanaged, quantify the overhead of meetings and planning vs. the amount of time being derailed or working on things that wouldn't have been prioritized. You may get more done without management, but is what you are getting done what needs to be done? That is what Scrum is about.
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.
And yet some have had great success with Scrum as their process.
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.
So much of the rhetoric surrounding 'Agile' is, as stated in the article, 'Waterfall'-bashing. But I don't subscribe to the idea that the actual original intentions behind it are somehow infallible or even necessarily helpful the way the article and so many proponents do.
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.
If Agile is the ability to respond to change then it's obviously a matter of good craft because software has never been made pliable with a magic methodology wand.
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.
"If Agile is the ability to respond to change then it's obviously a matter of good craft because software has never been made pliable with a magic methodology wand".
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...
A major motivation of agile is the ability to respond to change in requirements occurring during the time between project initiation and 1.0 release.
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.
What this suggests to me is that you'll be able to respond to change if the pieces of code you write can be reorganized. This happens when separation of concerns is properly handled, among other things. Change will not happen if you don't. Whatever the methodology. Waterfall can be great if the problem space is already well defined and understood, as implementing a protocol by spec. The specs will not change, and if they are well understood you can plan and estimate a good deal.
I think it's important to realize that this isn't saying that agile is bad, which is definitely the tone I get from some of these comments.
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.
I'm sorry but every time I hear someone go "[a]gile is SOOOO diferent from [A]gile" I also hear that same person pushing the same agendas and doing following the same practices based on zero evidence for their efficacy.
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:
FWIW this article and the Dave Thomas one are actually making that distinction and promoting the manifesto. Agile delivery (by which I mean the 4 line manifesto and not Scrum etc) has always worked brilliantly for me and the teams I've worked with.
I'm confused--are you against the agile manifesto?
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.
"error-free Internet" is a fair description. Given suitable hardware and a connection, you can reliably send email, access Web servers, run Web services, regardless of distance. The errors, if they occur, tend not to be a the software level.
i don't know if this helps anyone, but it's vaguely related to the article. if you're read taleb's "antifragile" then you can think of agile development as "antifragile development". and if you do that, and understand the difference between antifragile and merely robust, you can see what "parts" of agile make most sense.
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.
Talking of ignorance of the history of development practises, I can never believe it when I see people promoting 'waterfall' as if it were somehow a legitimate practise and hadn't been coined as a pejorative term to describe what was wrong with software development. The fundamentals of agile have been around for a long time and the manifesto was an attempt to formalise what had worked well.
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.)
Are there serious descriptions of these good-old-days software methodologies that the kids these days with their agile and their hippety-hop are corrupting? The story I've always been told is that 'Waterfall' is a pejorative invented by software methodology pitchmen to describe the ad-hoc process you get when you ask an MBA to build a software shop.
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?
Who says you need a methodology to create a good software product? (Answer: people selling methodologies).
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.)
> Are there serious descriptions of these good-old-days software methodologies that the kids these days with their agile and their hippety-hop are corrupting?
Yes; the references in the Wikipedia article on the Waterfall model [1] are good place to look.
Per the Wikipedia article, the term "waterfall" has always been pejorative. It was first described in 1970 as "this is a software development model which doesn't work". Everyone that has ever sold a commercial software development methodology has sold it as "not waterfall".
> Per the Wikipedia article, the term "waterfall" has always been pejorative.
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.)
There are so few things in life that are hard-and-fast rules. Agile is a bunch of guidelines that should be adapted, and the core Agile Principles say this themselves.
It's like a religion. Some folks like guidelines, some folks like rules. :)
Love that Alan Kay quote. I've used it in almost every presentation I've given. History is a wonderful thing because it teaches us humility, as it makes us realize the giants on whose shoulders we stand, and together with that it teaches us what not to do.
Lean is more concrete (there is a high-level metamethodology that you can be doing or not doing), while Agile is more abstract principles (although it often gets confused with specific low-level methodologies).
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.
"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.
Agile works fine. Software engineering methodologies don't kill projects, managers kill projects.