Responding to a junior developer who asked “Why developers at Google consider Agile to be nonsense?”
I said, because in practice, “agile” is code for sloppy thinking & lack of design. Code first, think later. It’s also great for giving managers metrics they can report against that sound good (e.g, “tickets closed”), while not having to show real results – like sales, or lawsuits avoided.
Ok, let’s start with the four principles from the Agile Manifesto. The mindset of a hacker, not an engineer. You wouldn’t even think of applying them to a construction project – buildings would be falling down all over the place (if you could get approval to start construction, without detailed plans to approve), and all involved would be spending most of their time in court.
- Individuals and interactions over processes and tools: For any complex piece of software, one needs to be very disciplined about pinning down design details (e.g., interfaces), about configuration management, about testing, etc. All of those are process intensive activities. The work can sometimes be reduced by good tools (e.g., a good version control system, automated build/test).
- Working software over comprehensive documentation: A rather poor dichotomy. What does “working software” mean, without documented specs? How does one install, use, interface to, or maintain software without comprehensive documentation? Personally, I’m a big proponent of “write the documentation first” – otherwise, you don’t know what you’re building, or buying.
- Customer collaboration over contract negotiation: Again, a poor dichotomy. In a lot of cases, contract negotiation IS collaboration, and/or defines the framework for collaboration. If you’re in business, particularly if you’re building custom software, the absolute last thing you want to do is spend a lot of time coding, only to have a customer tell you “that’s not what I meant.” Collaborate over use cases, storyboards, test & acceptance criteria, transition plans – but be damn sure to get to an agreement over what goes into a release, and how it’s going to be accepted, before starting to write code – otherwise you’re going to be out of business very, very, soon. (Might I add, that almost all companies try to insulate developers from end users. It’s kind of hard to actually get anything done if you’re spending all your time responding to support calls, or “can you just change this one thing?”)
- Responding to change over following a plan: Yes, things change. But by and large, this says “code first, think later.” That’s just sloppy. If you’re fighting a war, agility is critical (“no plan survives first contact with the enemy”), or if you’re playing basketball. But if you’re writing software, you’re a lot better advised to “plan the work, then work the plan” – and if things change, change the plan. (One might note that most of what pass for “agile methodologies” – such as scrum – are really planning processes, just ones with very short time horizons.)
By and large, “agile” is code for laziness in up-front design. Just fix the bugs & add features in future releases. Sometimes, that works – Microsoft has been very successful in shipping quickly, then fixing things later. It also works fairly well for periodic releases of mature software (fix some bugs, patch some security holes, add a few features). And, it’s absolutely necessary if you’re responding to a security attack, at the moment.
It doesn’t work as well if you’re building buildings, or mission-critical software (no, we can’t recall the spacecraft after it goes off course), or laying rail tracks from the coasts, that have to meet in the middle of the country. Or if you’re a large team, building 100s of modules that all have to fit together – you’d better get the architecture, interfaces, and databases all pinned down well before writing a single line of code. Otherwise, you’re just going to have to do lots of re-work down the line, and God help you if you want to add new features, without having well-defined hooks built in from the start.
And then there’s: