The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them?
Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more.
For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death.
[1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the United States of America and they have to be somewhere; they just shrug.
I almost said "states or territories", but DC is technically not a territory. And covering all the bases threw off the sentence. This being Hacker News, I knew I couldn't win. ;-)
I'm not expert in Agile, but from the pieces I used, and ones I read, Agile is not something you can do "perfect".
Agile is not something you can follow to the letter, like you said it's a bunch of processes that help you succeed. Which ones to apply, and more importantly, how to apply each process is highly dependent on the circumstances.
The way we got the term Agile is that a bunch of people in the '90s were experimenting with processes that were less insane that the waterfall approach that had come to predominate. DSDM, FDD, Extreme Programming, Scrum, and probably others that I'm forgetting now. All of those people got together and said, "Hey, we all have something in common. What is it?"
Agile is to an actual process what a subdivision is to a house. If you say you live in the subdivision but are not in an actual house, then you're just wandering around camping in back yards and parks.
I agree that a given process is a collection of practices, and that one can compose different practices into a process, sort of the same way a talented chef can walk into a farmer's market, see what's on offer, and compose a balanced, nutritious, and tasty menu on the fly.
However, in practice, what "doing Agile" mainly means is what happens when an energetic but unskilled 7-year-old decides to be helpful and make dinner. Maybe you get a dinner composed entirely of candy. Maybe they use the stove and make something that is a mud-pie version of a gourmet meal.
That isn't to say that people can't create a good process out of raw practices. It's just that doing it is an expert-level activity, and it requires an immense amount of dedication, experimentation, and careful thinking. That's not what I see when I ask after shops that are "doing Agile". That phrase seems to be used exclusively by people who don't want to think hard about process, and just want to cargo-cult and half-ass their way through things because they're focused on getting a project out the door and/or pleasing the HiPPOs.
> Agile is not something you can follow to the letter, like you said it's a bunch of processes that help you succeed.
Agile is not a bunch of processes. Agile is a philosphical orientation that guides how you do work, including selection and evaluation of processes in light of current team and mission.
Most people call it a framework, rather than a process. You could call it an empirical control process, which means it adjust based on previous history.
To me, there are a bunch of people who can't do Agile. They have huge legacy software projects, with low test coverage. They have customers that want (or can only cope with) traditional requirements based contracts.
In situations where agile doesn't make sense, do you think 'fake agile' can be a better way of working than 1990s waterfall?
There are actually reasonable techniques for doing Agile internally if you have clients who believe they need a traditional requirements-based contract approach. So those people should just do Extreme Programming.
For people with huge legacy projects, I think they really need to do the cost-benefit analysis. People like Michael Feathers make a persuasive case that you can slowly clean up legacy code, and that's much more economical than just suffering through expensive and risky changes.
But if somebody is deciding not to do Agile for considered cost-benefit reasons, they should just say, "Yeah, Agile doesn't make sense for us. We're going to do waterfall." Or they could choose a mini-waterfall process, or any one of the pre-Agile processes that suits them. (If those people exist, they should read McConnell's Rapid Development, which catalogs the options pretty well.)
If that's what they want, godspeed.
The people who make me crazy are the ones who don't actually have the discipline to use a real Agile process and also lack the guts to say, "Yeah, fuck that Agile stuff." I get that people would like to be all hip and Agile, but sending somebody out for a 2-day "certification" and then changing a few labels is not actually making better anything internally, and it's making my life worse.
I don't want people to be fake anything. Be real, everybody! Especially managers. Because it's only admitting where you're at that's going to let you get somewhere better.
I think most teams using agile, or developing software with some agile practices are in fact working within a hybrid process, where the requirements gathering and analysis, the writing of offers and contracts, and sometimes the delivery of the software all happen in waterfall style phases, and only the development itself is conducted in iterations and with agile technical practices. I still think this is a bit better than full on waterfall. Depending on context of course. It may not be as good as full on agile either.
Just because there is no process labelled "Agile" doesn't mean it is meaningless to talk about "doing Agile". What if doing 100% XP by the book turns out to not be ideal or doing 100% Scrum by the book turns out to not be ideal, but the team finds they can achieve good results by mixing and matching their own collection of "agile practices" and even made up practices that are in some way inspired by agile values and principles (yeah I know that sounds a bit wishy washy)? I think in this case it may make sense for the team to claim "we are using a process that doesn't have a name but is inspired by the agile manifesto and consists of a bunch of agile practices that work for us" or for short: "we are doing agile".
As far as I can tell, nobody who has actually taken their process seriously says they are "doing Agile". When you ask them what they do, they give a pretty specific answer. E.g., "Well, we started out with Scrum, but added a number of the XP technical practices and are experimenting with getting rid of iterations for a flow-based approach." Literally every time I have asked follow-up questions of somebody "doing Agile" it has been some variety of horseshit with Agile words thrown in to make it sound trendy.
As an aside, I don't know any serious Agile person who thinks that doing 100% anything by the book is a good idea. I think it was Ron Jeffries, one of XP's inventors, who said something like : "By the book XP is a good place to start, but it probably isn't where you'll end up." Agile processes all have an inspect-and-adapt component. E.g., the weekly retrospectives and continuous tinkering of XP.
More often than not it seems that 'doing' Agile just means that people are supposed to have the false impression that they are working with a team... without being a team outside of meetings.
Exactly. For me, a lot of the pseudo-Agile failure turns on not having actual teams. Teams are groups of people that win and lose together. But so often, companies are structured so that individuals win and lose separately. Or the design "team" can win while the programming "team" loses. It seems like such a simple thing, but I have a very hard time getting people to notice it.
The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them?
Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more.
For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death.
[1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the United States of America and they have to be somewhere; they just shrug.