QTB: Agile Adoption - How to stuff it up
Date: 2009-06-24 23:58:38

I attended the most recent http://www.thoughtworks.com/what-we-say/events/tech-briefing_au.html[ThoughtWorks Quarterly Technology briefing] on Tuesday which was titled 'http://www.thoughtworks.com/pdfs/aus-qtb-june09.pdf[Agile Adoption - How to stuff it up]' and presented by my colleagues Andy Marks and Martin Fowler.

There seems to be quite a few books out at the moment about how to introduce a more agile approach into your organisation - I've been reading http://www.amazon.co.uk/Lean-Agile-Software-Development-Enterprise-Objectives/dp/0321532899/ref=sr_1_5?ie=UTF8&s=books&qid=1245767478&sr=8-5[Lean-Agile Software Development] and http://www.amazon.co.uk/Becoming-Agile-imperfect-Imperfect/dp/1933988258/ref=sr_1_1?ie=UTF8&s=books&qid=1245767583&sr=8-1[Becoming Agile] and there is also a book called http://www.amazon.co.uk/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_1?ie=UTF8&s=books&qid=1245767478&sr=8-1[Scaling Lean and Agile Development] - so I was intrigued to see whether the messages from this talk would be similar to those in these books.

== What did I learn?

* I often find when listening to Martin Fowler speak that although what he says is quite similar each time when speaking about agile there always seems to be something different that stands out for me each time. This time what stood out was his mention of the *Dreyfus model with regards to people's level of skill when it comes to agile* - when you first start out as a novice it's quite hard to keep the principles in mind so you spend a lot of time focusing on the practices and getting better at these but if you want to keep improving then at some stage you need to move up to a level where the principles do become more predominant.
* Andy made an interesting point that *IT and in particular software development is pretty much made for people who want to learn new things* and he also pointed out the myth that 'learning finishes at school'. I never really considered this before but for me it definitely applies - the process of learning new ideas appeals far more to me than the results and outcomes of projects so it was interesting to hear this coming from someone else.
* *Transparency with regards to bad news* was something else which was pointed out as being fairly important and it's certainly http://www.markhneedham.com/blog/2008/08/26/the-transparency-of-agile/[an area where we often run into trouble] - often organisations aren't used to bad news being delivered to them early and they get the impression that if it's going badly now then it's going to keep on going badly, rather than seeing that it's quite good to get bad news early because then you have time to fix it.
* Martin described the '*pilot project anti pattern*' which he has come across where organisations make use of agile on a project which noone really cares about and use it as a training ground. It was suggested that this is not an effective way of introducing an an agile approach as it doesn't matter to anyone so there's no incentive to work out whether the new approach is really beneficial or not.
* I liked the question that Andy posed about success and failure. He first of all asked anyone in the room who had seen an email from their CEO talking about a really successful project and congratulating the team to put their hands up. Pretty much the whole room did. He then asked who had received an email from their CEO talking about a failure and the lessons learned from that and only one person's hand went up! Andy is definitely right when he suggests that "*if you're not failing you're not learning anything*" and this is something which I've also come across from Andy Hunt in http://www.markhneedham.com/blog/2008/10/06/pragmatic-learning-and-thinking-book-review/[Pragmatic Learning and Thinking] and more recently I'm trying to get into the 'improvement ravine' with regards to learning F# as I'm still writing object oriented F# which I think is missing the point a bit. http://blogs.msdn.com/wesdyer/archive/2007/01/15/thinking-functionally.aspx[Thinking in a more functional way] is the key for me there.
* A question was raised about how agile can fit in with fixed price projects at the end where it was pointed out that if the price and the time are fixed then the *scope has to be variable* - it can be infinitely flexible. It's actually often the case that a lot of value can be delivered with reduced scope even though it doesn't seem that way when you're told that all three of them are fixed!