When agile goes bad, slides and pointers

I’ve given that talk quite a few times now, and always forget to give the full material. So here goes.

A couple of references that I mention in my talk.

Father of crystal, Alistair Cockburn (that I somehow always call Ian, shame on me) http://alistair.cockburn.us/
For Lean Software Development, one cannot ignore the Poppendiecks: http://www.poppendieck.com/
Extreme Programming, http://en.wikipedia.org/wiki/Extreme_Programming
BDD from Dan North
Continuous Integration, of which TeamCity, Cruise, CruiseControl (and CruiseControl.net) are the most commonly deployed.

A couple of points I hammer constantly, so let me repeat them once again:

Becoming agile is a journey, not a goal.
The goal is to adapt to change, and deliver value
Change cannot happen smoothly if quality is not at the core of your development practice
Becoming agile takes months (some say years), not weeks.
Don’t start adapting an agile methodology before you have a thorough understanding of it. Otherwise, you’ll adopt the easy bits (daily stand-up, wall) and ignore the hard bits necessary for your project to succeed (continuous integration, regular deliveries, short feedback cycle)
Get yourself a proper coach for enough time, at the beginning three days won’t get you much at all (notable exceptions are putting in place CI / builds and helping organize workshops). If you adopt a new methodology while starting a new project, you’re doubling the risks of failure. Do it with inexperienced people (and this includes freshly certified scrum masters) and you triple your risk.
Done is not done until the task is complete and doesn’t need to be changed. At all. Ever. That includes testing, code reviewing, documenting, etc etc.
Delivering at the end of the iteration means delivering to your customer, not to testers.
Your testing should be done per-story, tested in real-time. If you have a UAT phase, you have a problem.
Each feature gets deployed as it becomes Done. Not at the end of an iteration.

And to answer a question that was asked in Cork, where do you start when you have none of the agile practices, I’d do it in the following order:

Source control! If you don’t store your code (and this includes database schemas and everything else) in source control, you’re putting your company at risk.
Start with OOP, practices, BDD (then TDD if you’re so inclined), continuous integration, code analysis (coverage and dependency analysis), a couple of necessary concepts to produce well-factored maintainable code (Dependency Inversion principle, Inversion of Control, dependency injection).
Once you’re comfortable with the principles (which you should after an intense couple of weeks of trying hard), start a project with a simple methodology. I’d recommend adopting Extreme Programming and Scrum at the same time, because they fit together fairly well. Focus on writing your user stories and your tasks, and tracking them down in burn down charts. Get customer involvement from day 1, buy trust by sticking to regular time-boxed deliveries.
if you get there, you’ll have enough opinions about the process of delivering great software to decide on the next move yourself.