Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 543 posts at DZone. You can read more from them at their website. View Full User Profile

QTB: Agile Governance – Managing the Enterprise Issues

10.02.2009
| 2839 views |
  • submit to reddit

I went to watch the latest ThoughtWorks Australia Quarterly Technology Briefing in Sydney on Wednesday where my colleague Lindy Stephens, Suncorp's Josh Melville and Lonely Planet's Nigel Dalton presented on 'Agile Governance – Managing the Enterprise Issues'.

I was actually unsure of how interesting it would be to me as the title seemed a bit dull but it was actually quite entertaining and not at all what I expected.

These are some of the things I picked up from the presentation:

  • 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:

    So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.

  • 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.


References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)