The week before last I spent the week teaching at Oxford University. I teach a course on Agile Engineering Practices as part of the Software Engineering Programme. This is a part-time MSc programme for people who are currently working in the industry to develop a more formal academic training in computer science and software engineering. One of the great things about the programme is that the students bring a lot of experience from their everyday work to share and discuss with the class.

Although the course is called Agile Engineering Practices, and is rooted in the XP Practices, we use the Continuous Delivery book by Jez Humble and Dave Farley as the course textbook. We don’t follow the textbook chapter by chapter, but this was the book that I found put all the concepts and practices together in a big picture, including the more recent focus on release management, devops etc.

One of my models for constructing a course, is a diamond, similar to some of the creative processes described in Creativity Today by Ramon Vullings and Igor Byttebier. In the first half of the course we have a diverging phase, where we see lots of different tools and techniques, and different problems that they solve. At Oxford I ask each of the students to present a short example of some tool that they use in their work for testing, release management, CI, build, project management, etc etc. We also discuss and do exercises related to unit testing, specification by example, refactoring, build automation, CI, working with legacy code, and more.

Once we get into the second half of the course, we enter the convergent phase, where we draw things back together so that they (hopefully) make sense and we can see the overarching structure of how all the different pieces fit together. In this course, it is really setting up the continuous delivery pipeline that does this. Setting up some infrastructure and trying some exercises that go end-to-end from idea to release, iterating quickly, really seems to solidify everything, and point out the value and contribution of each section of the chain.

We cover a lot of different tools and techniques during the week, and it was interesting to talk to the students about their learning experiences, and how things tied together in their minds. At the end of the second day, when we’d been struggling through trying to get some particulary messy legacy code under test, people’s minds were definitely being stretched. But talking to them again a couple of days later, they described getting “over the hump” as things started to crystallise in their minds and being to make sense.

It’s difficult to simulate the feeling of delivery outside of a project environment, and exercises can often feel artificial or trivial, but I hope that constructing the whole pipeline and putting techniques together helps to pull everything into place. Once the process and infrastructure and is set up, we are free to concentrate on building the right features, rather than on getting them approved for release - that part hopefully becomes automatic and fades into the background.

Continuous Delivery Course

I’m running a public two-day Continuous Delivery Kickstart workshop with Seb Rose in Paris in March. Why not come along to learn, practise and discuss?