I don't think there's much value in articles such as this. This one in particular uses an incredible amount of vague language (What do you mean by "agile"?), and sets up a number of straw men (Did anyone ever claim retrospectives fix everything?).
This kind of writing always seems to me to be trying to limit discussion in some way. It pretends to criticize a certain approach by bringing up problems that don't really exist (or aren't important), but implicitly accepting the basic principles of the thing they're criticizing, thus framing the debate. On one side we have the total religious fanatics who apply Agile to everything, and on the other are the sensible agilists, who don't think that "retrospectives fix everything". Okay, that's a debate you can have but it's an extremely narrow spectrum of opinion. If you're really trying to reach people who are "agile-averse", then you ought to argue for your approach with them and demonstrate that your way has merit.
A lot of what people write about "agile" processes tend to be written keeping in mind teams/people at traditional companies. Very few of these are helpful in a "startup" environment.
So a pro tip to make sense of such articles - imagine being part of a big team at a big company while reading. They will start making a lot more sense.;)
All very good points. And I agree there seem to be a lot of misunderstandings even now.
How about, though:
2) Agile does have a good process for estimation. Estimating by relative size removes all those "unknowns". This does allow for a velocity that doesn't vary between iterations. I have three teams that have a velocity that on varies 10% between iterations. There is more to Agile than just Estimation. There is the commitment that a team makes to deliver. So, even if their estimates are off, the team is more likely willing to put in the extra time to meet the commitment. Remember, in Agile you commit to product, not points.
With regards to accurate: it isn't supposed to be accurate. It is supposed to be reliable.
4. With regards to documentation, no light design, etc. This stuff always seems so mis-understood. Agile says you do enough documentation/design to make it to the next game. But yes, not a silver bullet.
5. Agile requires any issues brought up by a retrospective to be placed in front of the backlog. I guess if management isn't willing to allow that, then they aren't following Agile. In the end, it is really all about execution which has nothing to do with Agile itself. Agile just affirms that you need to continually reflect and improve on the process itself. It doesn't explain how to manage that.
6. It is true this would be silly to say. And there is Behavior Driven Development (BDD) which requires you to test your system from end to end. There is also continual integration (CI) which allows "heavy tests" to be run periodically as opposed to continually during development.
Please note, I didn't make these "rules". I just follow them and it has worked really well for me.
Agile is such a generalization. There are many practices below Agile such as Scrum, XP, Lean, Kanban, DSDM, FDD, etc.
Agile itself is just a set of principles. The actual implementation still require some processes.
I don't think people should attack Agile as a whole, but they should focus on which practices they chose. For example: Scrum is an agile practice for Project Management. But in order for a shop to use Scrum, they must implement certain practices from XP. XP more of an agile practice for Software Developers.
There are shops which implement only SCRUM but not the XP part. That is to say that they implement the whole Sprint, Retrospectives, Backlog, Stand-up meeting, but they did not refactor bad code, they did not try their best to have an automation in place. At the end of each sprint, they never test the whole app, they only test whatever the sprint accomplished. This is even worse than the previous practice.
I wholeheartedly agree with those who have been burned by management who thinks that SCRUM or XP will make things better in a short time. I hate to say this but it takes a very long time for a company to change their culture and mindset (depending on the size of the company and what the company does: product vs service).
If your company is switching to something new, make sure they know that methodology inside out. Make sure they met the pre-requisite. Make sure they are willing to sacrifice their time and money for a while.
Otherwise, get your resume ready cause the ship will sink faster than before.
On the other hand, some people might not agree with this but when you have one of these processes in place and everything in your engineering department runs well, that doesn't mean life is good. When the company is not doing well, your senior engineers who receive a big-fat check every month might be a good candidate to be let go. The reason is because your intermediate and junior engineers have already known everything inside out (cause one of the practice in Agile is to share knowledge, cross-functional team, or whatever).
Some relatively lucid observations there. (Disclaimer: I'm an expert. I was into Agile before it got named that.)
There's one point that I starkly disagree with:
> “Hero developers” make most of the big differences made in software development.
Wait, did I say I disagree? Hero developers make a big difference all right - for the worse. Nothing breeds bad management like the one guy who pulls through when the team can't. Managers come to rely on them, and therefore on sheer blind luck, when the name of the game is to engineer success, by putting together a solid team.
It depends; sometimes, you'll see a huge pro-agile crowd, other times, not so much. This is accentuated if you s/agile/tdd/g;.
I'd wager this is largely due to how one is first exposed to agile methodologies. I'm young enough that I stumbled across agile as a way to solve problems, and so it sounds pretty good to me. However, my slightly older colleagues remember agile as the Newest Management Fad, with high priced consultants, seminars, certifications, and your boss paying lip service to change while still Not Getting It to match.
I like agile's philosophy, but I can certainly see lots of criticisms of Agile.
My first experience with Agile was a housemate describing this amazing new design system that meant he could get right into coding without any tedious planning and sort everything out later.
He created a startup for his pet project, eventually managed to get one customer for his product and then realised his idea was fundementally flawed and would never be commerically viable or even supportable.
That is still my impression of Agile - full speed ahead, buzzwords to maximum power and hope for the best.
One place I worked the project managers where very enthusiastic about using Agile techniques. When I questioned them about it, it turned out that Agile to them meant "make stuff up as you go along". To them it just meant that they could resign all sense of responsibility, didn't had to do any planning or documentation. How great is that?
My project manager is very fond of Agile - he doesn't have to interview, estimate nor understand the schedule any more - he abdicates it to a post-standup meeting where he quizzes everybody about their cards and edits them.
Result: So now I'm doing the manager's job too.
I find it a waste of time, at least when implemented this way. The single bright spot: at least no more 2-hour rambling staff meetings!
I always preemptively raise my eyebrows when I come across an article about agile because, in my experience, agile is mostly used by hit-and-run managers as an excuse to avoid making the hard decisions. Apparently, "embrace change" makes it okay to randomly interrupt people in their work to solve the urgency du jour, only to blame them when they miss their deadline. "Daily scrums" give the manager the green light to avoid one-on-one interactions with his team members.
Interestingly, the best development teams rarely display overt enthusiasm for their "methodology" and just get work done.
The problem is that "agile" doesn't mean anything.
On my team we follow an agile approach, but we also have rough ideas on product direction for the next year or so and themed releases planned out for the next few months.
For us it all comes down to an understanding that if something else comes up then some of these features are going to have to slip to get other things in. It also means not building things that we ultimately aren't going to use.
If you just think that Agile means "don't plan, just do whatever you want" (i.e. Chaos) then of course you're going to hate it. No one can work like that.
He missed one important point: Agile is an agreement between the customer and developers, it's not magic. A few years ago the customer would tell you: "I want all the features by this day, I don't care about iteration".
Even now, many customers just want the perfect product at the end of the contract.
This kind of writing always seems to me to be trying to limit discussion in some way. It pretends to criticize a certain approach by bringing up problems that don't really exist (or aren't important), but implicitly accepting the basic principles of the thing they're criticizing, thus framing the debate. On one side we have the total religious fanatics who apply Agile to everything, and on the other are the sensible agilists, who don't think that "retrospectives fix everything". Okay, that's a debate you can have but it's an extremely narrow spectrum of opinion. If you're really trying to reach people who are "agile-averse", then you ought to argue for your approach with them and demonstrate that your way has merit.