Declan Whelan’s presentation at Agile Testing Days focused on promoting learning in software teams. “Delivering long-term value to our organisation is gated by our ability to learn”, said Whelan, presenting several great ideas how to ensure that teams keep learning and improve.

A key take-away idea from this for me was setting up a pet project for the team to try out new things. Teams can often only try out new things for real on the all-important production code. The only way you can see how it really works and how easy it is to maintain, how many bugs it has and how quickly they get solved, the experiment really has to go live. Unless it does, you can’t really tell if it is going to work or not. Sometimes things turn out to be great and you decide to keep the experiment there, sometimes they turn out to be sour and you want to take it out. For example, I was very impressed by Grails several months ago and my team decided to build a back-office web application with it. Initial development was fine but it turned out to be a complete disaster later with ORM bugs not being fixed, upgrades breaking backwards compatibility and too much hassle to maintain the application. The problem with something like this is that it takes time to show how something behaves long-term and the world doesn’t stand still while you’re doing it. At the point where you decide to take something out, the project moved on and other components depend on the one you’re now dropping. This is especially true if you want to try out a new infrastructural tool.

To solve this problem, Whelan suggested creating “practice fields” - have a code base that is set to play. This might be a pet project that the team is working on when there is slack, where they can experiment and learn new toolkits separate from the real production project. For this to work, at least in my case, the pet project should be something released into the wild so that you really feel the relief or pain that the new framework or tool bring after a few months. If it turns sour, it’s a pet project so you can afford to make it unstable for a while. Maintaining a pet project brings additional work and cost, but this should be budgeted from R&D, as it helps teams learn and doesn’t increase the risk in production.

The Learning Culture Map

Whelan focused his presentation around the Learning Culture Map, effectively key things which organisations have to do in order to promote learning. The areas on that map are Intentional, Infrastructure, Incremental and Individual Safety.

Learning has to be intentional.”Don’t expect learning to just happen”, said Whelan, “We need to set out to learn”. Teams and organisations can use retrospectives, bringing in coaches and doing research (sending people to conferences, reading blogs, mailing lists..) to promote learning. They should also promote a culture where asking questions is OK and exercising the R brain (a concept taken from Andy Hunt’s Refactor your Wetware book)

Learning also requires special infrastructure. Whelan advised setting up a workspace that promotes learning (information radiators, e-mail lists…) and creating special learning sessions (road trips, etudes, study groups). As one of tricks that help learning, Whelan suggested “do food” (taken from Linda Rising’s book Fearless Change). Another helpful idea is to integrate learning and working with pair programming, planning sessions, stand-ups and demos.

As a constant activity, learning should be incremental

Finally, Whelan said that individual safety is crucial to learning. In this context, individual safety means that people have to feel safe to expose their mental model to the world and ask questions. Part of the safety is giving people a chance to opt out of any activity that they don’t feel safe about or do not want to participate in without consequences.

Further reading

Whelan suggested quite a few books for further reading:

He also suggested Thiagi Training Games, a web site with games teams can use to improve their learning skills.