Lindy started out talking a bit about the illusion of control that waterfall plans can lead us to, referencing the intial paper on waterfall written by Winston Joyce which actually criticises the idea of designing everything up front and suggests an iterative approach would work better. A recent article by Tom De Marco where he retracts the idea that you "can’t control what you don’t measure" was also referenced. The most interesting part of this article for me is where he points out that projects which provide minimal return are the ones that need the most control but perhaps we should be considering whether we should even undertake them in the first place. The idea of having software that is production ready at any time is also a very nice thing to aim for:

Traditional measurements of progress derived from a more waterfall process actually only tell us if we’re proceeding not if we’re succeeding - it’s much more useful to keep our focus on whether we are delivering value to the end user instead of just focusing on whether we have hit our targets on delivery date and promised scope. The transparency and visibility that we typically have when following a more agile approach was mentioned by a couple of the speakers - progress is much more visible throughout and we don’t suddenly have a project going from status 'green' to status 'red' right at the end. I think we need to be a little bit careful that we explain things carefully when showing this types of data to people who are new to the agile approach as it can very easily give the impression that we are totally failing when actually it’s fairly normal for initial progress on a project to be slower than it will be once we get going. Nigel Dalton described a story where even the Lonely Planet chef knew how one of his teams was doing because the information was so transparent!

Nigel also spoke about the idea of outsourcing agile and suggested that the best way to ensure success with this is to work with people in a country on the same longitude so that the timezone difference isn’t too great. He also suggested that having people from both locations going to the other works well for ensuring better communication. I went to a QTB last year where this was covered in more detail by my colleague Dharmarajan Sitaraman.

The general idea behind what Nigel presented seemed to be that the individual teams effectively provided the governance of projects and that it wasn’t necessary to have massive reports detailing progress every week. Josh Melville stressed the importance of looking at the value of all documents and getting rid of them if they don’t provide anything useful. Nigel described how they had massively simplified one of their reports after listening to Josh’s advice! Lindy pointed out that sometimes we’ll be executing projects in an agile way in environments which more traditionally follow a waterfall methodology and that in this case it might be necessary for the project manager to spend some of their time converting the data into an appropriate report. In terms of the lean approach this seems to me to just be waste, but perhaps a necessary waste.

Josh also talked about the importance of moving away from a process centric view of the world to a relationship based one when it comes to managing projects whereby problems could be talked through instead of just writing off a project as doomed because a 'checkpoint' wasn’t reached. He also suggested that considering whether we delivered features and also whether they were actually used were more useful things to look at rather than looking at budget and time.

In the questions afterwards one suggestion to the speakers was that the metaphor of software development as being similar to industrial manufacturing is not really helpful and that perhaps movie making is a better one to use because there is a level of creativity involved and the aim is to deliver something of value each day. Nigel pointed out that while traditional manufacturing didn’t have much to teach us, lean manufacturing was a different story as it helps us cope with variation rather than just cost which is quite important in software development.