Whenever I hear a company say "We follow an agile development process", the corners of my mouth unconsciously turn up in a wry smile. Agile methodology is something of an oxymoron. Oh, the core ideas of it were (are) excellent, but somewhere along the way it turned into a bunch of codified management processes, and became exactly the sort of thing the Agile Manifesto was trying to eliminate. As soon as the management folk came along and tried to formalize agile philosophy into a methodology, it stopped being agile.
Now one of the original authors of the Agile Manifesto has come out with a piece, originally titled "Time to Kill Agile", in which he makes this point. Dave Thomas has been hugely influential in the software development field. Aside from being one of the authors of the agile manifesto, he's written a lot of other stuff, and he's the guy who coined the phrases "code kata" and "DRY" (Don't Repeat Yourself - the maxim developers follow to effectively organize their code). Evidently, Dave considered that "Agile" was probably already dead and renamed the piece "Agile Is Dead (Long Live Agility)!"
The problem with being a critic of Agile, or anything else that's become ingrained in a big software development organization, is that you'll come up against folks who've been drinking the kool-aid for long enough that if you call into question the value of Agile (or Oracle, or Java, or whatever) you'll be immediately labelled as a fool.
So this - having one of the original authors of the Agile Manifesto come out and make the same kind of criticism of "Agile" methodology that I've been skeptical of for years - is gold.
It all boils down to people over processes. Agile software development cannot be implemented as a set of methodologies, and the managers, consultants and companies that have turned it into a set of rules, processes and formalities, have demonstrated that they totally don't get what the authors of the Agile Manifesto intended in the first place. In my humble opinion.
Dave Thomas has some good advice for teams that want to develop software with agility. He advocates an iterative approach to development, and choosing options that enable future change. He recommends thinking of "agile" in the form of an adverb (agilely, or "with agility"). Programming with agility. Teams that execute with agility.
I've found that when it comes to managing a project, simple is usually better. What's worked best in my experience is, in a nutshell, to simply encourage communication. Make sure everyone understands the overall objective, how they can contribute to it, what progress has been made and what challenges remain, and importantly, give everyone the opportunity to have their work fully recognized and appreciated on a regular basis. Given the opportunity to work on a challenging project and the chance to have their contributions seen and appreciated by colleagues, most developers will bend over backwards to do their best work.
There's no right or wrong way to do this, but one technique I found effective was a brief (set-a-timer with a hard cut-off) meeting at the beginning of the week where we laid out the objectives for the week ahead, a quick information-gathering hike around the office at the end of the week, and an email re-cap on Friday afternoon highlighting the teams progress. Showing the percentage-towards-completion of major tasks was also a big motivator, as developers began to take pride in seeing their areas of responsibility make steady, visible progress towards completion. We didn't formalize or get locked into one way of doing it, so when our company got acquired and our management structure changed, we adapted pretty easily.
- People over processes.
- Working software over documentation.
- Collaboration over contracts.
- Adaptability over planning.