[Update: in response to some of the comments here and on HN, I thought it might be worth updating with a note on my personal experience with Agile, which appears at the bottom of the post.]
Agile (with a big 'A') has become so mainstream now that it has started to become the problem. An alarming number of people who espouse the virtues of Agile, and who quote the Agile Manifesto believe that Agile is a project management methodology, and that Agile really means SCRUM, XP, Kanban, and that it is embodied in the daily stand-up, whiteboards or writing requirements on post-it notes. I was once told by an Agile Trainer (LOL) that the correct way to phrase the requirement "we need advertising placeholders on the site, and some way to manage which ads appear where" was "As a User, I wish to be marketed to." Needless to say his company lost a $m project on the back of such BS.
As a result of all this, Agile (big 'A' again) has become a bit of an albatross - it doesn't really work, it doesn't deliver the benefits it promised, and it inevitably involves a lot of arguing amongst the team about who should be doing what, and when.
All of which distracts from the fact that agility (small 'a' this time) is a wonderful thing, that can be achieved, that does provide enormous benefits, and that should be encouraged in everything we (as an industry) do. Agile (small 'a') refers to team dynamics, delivery processes, the software itself (how easy is it to change), and operations. Everyone should aim to be agile.
So, a few lessons I've learned along the (hard) way:
- The best way to achieve your goal is to start with the right people
- If you've found the right people, let them get on with the job you're paying them for
- The people with the best ability to plan the delivery are the people doing the work
- A small team with a manageable backlog needs very little Project Management
- Everyone on the team “needs to know”.
A few things that help this happen on a practical level:
- Try and avoid building towards a pre-determined marketing / launch date
- If you do have a fixed time, then scope is variable
- Never try messing around with team sizes to massage delivery
- Automate everything in sight - builds, deployments, testing, progress reporting, tea-making
- Measure as much as you can - no feedback == no direction
And finally some other things that will prevent you from getting there:
- If you have to have everything on your requirements list, you can't be agile
- If you need to plan beyond the next sprint with any degree of accuracy, you're not agile
- If you think you can "fix" an iteration by adding more people, you're not agile
- If you are prepared to change the end date of an iteration to "fit something in", you're not agile
- If you have to give a fixed date for delivery - it's very, very difficult to be agile.
Postscript: my personal experience with Agile.
I worked for several years at a company that was at the forefront of the Agile movement in the UK, and I believe that at one point they had more registered SCRUM Master practitioners than anyone else in the country. (I think Sensai Schwaber visited in person at one point, although I’d left by then.) They were generally acknowledged to be the leaders in the field.
The incident in the post occurred when I returned to the company as a client, parachuted into a large project that they were running with the full SCRUM toolkit (“Agile Coach” included), that was running into trouble, principally the fact that it was not agile. The project was rescued by hiring a team of people with the right combination of aptitude & attitude.
As I say in the post – agility is a great goal, and everyone should aim for it – but don’t make the mistake of thinking that Agile is the means to achieve it.