A bit more to IT

The subject of user acceptance testing is pretty crucial for agile development teams.  Its certainly an issue which we have given quite a lot of thought to in our XP team in the past few months.  There are two points I want to make in regard to this, the first concerning our overall approach to UAT.

To break it down for those people who are not aware of the debates around automated UAT in agile there are basically two schools of thought.  One says that the developers and the customers should sit down before the coding starts for a particular feature and put the tests together for it.  The rationale behind this is that this will initiate a discussion between these two parties during which a better understanding of the requirements will emerge.  This ongoing discussion between developers and customers is particularly important in agile as there is no formal requirements spec adopted by most of the main methods.

The other way of thinking suggests that the tests should not be written way before the production code is done because, in that state, they are not actually doing what they are supposed to namely documenting the code.  This view is informed by a Lean perspective which says that we should cut down on artefacts which don’t contribute to our overall goal.  In other words tests which are not documenting code are ‘inventory’ and should be cut out.  This second approach is one of the ways in which Lean thinking is influencing the day-to-day approach to agile.  I think we can expect to see more and more of this in the near future, which, as I’ve recently written is a good thing.

Whichever approach is adopted for testing it still remains crucial for agile teams.  Given the increasing popularity of agile and the importance of UAT for it one would expect there to be many different frameworks to allow automation of the process.  Not quite.  The ones we have tried in our team all have problems and while we have settled on using Selenium we often speak of it as being the ‘best of a bad bunch’ rather than ‘best of breed’.  Now ours is a very small team and it got me wondering how larger teams cope with these flaky frameworks.  Do they use them at all or are they in fact more reliant on the manual variey of UAT.  I don’t know of any studies which investigate this issue but they would make for interesting reading.

Lean thinking has long been an influence on Agile but over the last couple of years we are seeing the links being made more often and by an increasing number of people.  The fact that Scrum owes much to Lean thinking is pretty well known but I suspect that we will be hearing a lot about Lean Software Development and Kanban in the near future.  I don’t really want to discuss Kanban here save to say that I’m interested in it though I have to confess that, as yet, I don’t know very much about it.  The presentation that David J. Anderson gave to Agile Scotland at the end of 2007 about his experiences with Kanban was inspiring and marked it out in my mind as a good way forward.

While an increasing number of folks are investigating the potential of Lean for software development we don’t necessarily want to get into a situation where its Lean Vs Agile.  Martin Fowler has written that the opposition Lean Vs Agile is a non-starter because the two are actually very deeply intertwined.  In saying that, however, we shouldn’t lose sight of the fact that there is much that Agile can learn from Lean.  Perhaps the most important thing to be gained from Lean is a proper appreciation of what Kent Beck calls the “social purpose of work”.  It may be that Lean can help address the persistent criticism that “software development often seems to occur in a purely technical context devoid of business or social purpose”.

Richard Durnall, another ThoughtWorker, has suggested that there are four main contexts in which Lean can directly contribute to Agile.  All of these are interesting but its the first and last ones which really ring true for me.  His first idea is that Lean can be used as a metaphor for Agile when trying to explain the benefits to executives.  The argument goes that it is all the easier to put forward an idea when one can compare its benefits with, for instance, the Toyota Production System.  But its his final point that is most significant for my interests.  Lean has a long history of successfully introducing large scale change into organisations and this is something which, Durnall points out, we could do with in IT.  The wider and more holistic perspective which Lean brings is very often missing from Agile as it is practised by many teams, though this almost certainly doesn’t equate with what the originators of the methods or the signatories of the Agile Manifesto intended.

My main research interest has been distributed Agile and in this area we can see that a narrow focus on team and task that characterises some methods, and particularly XP,  wouldn’t be appropriate.  My research has shown how large and small teams are successfully adapting Agile practices and principles to suit their particular circumstances and levels of distribution.  However, this adaptation only works where certain guiding principles are followed but unfortunately up to now there has been little direct guidance on what these core principles actually are.  Experimentation and experience are being used to discover what these are in a process which owes a great deal to the philosopy of learning by doing.  Could it be that Lean thinking is what is required to make this quite haphazard endeavour more systematic?