Three Org Changes to Encourage DevOps

[#encouragedevops] In the talks and break-out sessions at DevOpsDays London, in conversations at London Continuous Delivery meetup group, in numerous blog posts and articles talking about introducing a DevOps culture (e.g., and based on my own experience of organisations I have worked within, it is clear there are three key practical steps which an organisation can take in order to encourage a DevOps culture of collaborative, cross-functional, product-focused working which leads to more effective delivery of software-based services.

(I’ll be blogging about each one of these steps over the next few weeks with the tag #encouragedevops)

Continue reading Three Org Changes to Encourage DevOps

GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well

I recently went to a Devs in the ‘Ditch meetup at 7digital to hear Chris O’Dell (@ChrisAnnODell) explain 7digital’s journey to Continuous Delivery and Steve Freeman (@sf105) speak on GOOS and system testing. We had some useful discussions on dependency injection and how to use logging well, and Steve’s perspectives on ‘code shapes’ and the purpose of tests were revealing.

Continue reading GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well

Icebreaker for Agile Retrospectives – Empathy Snap

I was invited by one of our London dev teams to facilitate their retrospective yesterday. I’m far from an expert in facilitating retros, although I enjoy it, and I find that I learn a huge amount from doing so.

Anyhow, I decided to try out my retro ice-breaker exercise which I call Empathy Snap, the aim of which is not only to discover the important features (‘big hitters’) of the last iteration for each team member, but also to see how well team members are aware of the big hitters of their fellow team members. In this way, aspects of the team dynamic can be explored, and dialogue is opened up in a way which immediately requires consideration of others – a useful starting point for a retrospective.

Empathy Snap works like this:

  1. Each team member gets two index cards and a marker pen.
  2. On the first card they write their name at the top and place this card on the table or hand it to the facilitator.
  3. On the second card, hidden from the others, they write the ‘big hitter’ (good or bad) for them from the last iteration, and keep this hidden from view for the time being.
  4. Once all team members have written their ‘big hitter’, each team member takes a name card from the pile, ensuring they do not have their own name card.
  5. On this card, they write what they think is the ‘big hitter’ for the person whose name is on the card, and keep the card. Essentially, they try to guess what that person has written on their hidden card.
  6. Once all the ‘name cards’ have been completed with a ‘big hitter’, a team member reads out the name of the team member written on the card and their guess at the ‘big hitter’ for that person.
  7. The named person then reads out what their big hitter actually was.
  8. If there is a match, then SNAP!
  9. The exercise continues until all team members have read out their guess and have responded with their actual big hitter

We had one SNAP out of the team of 8 (the red asterisks), but the mismatches also provide very useful insights into the team dynamic:

Empathy-Snap-SNAP  Empathy-Snap-mismatch

The team found it useful, so I think we’ll try it next time too. A variation of the exercise can use separate cards for ‘good’ and ‘bad’ big hitters, so doubling the number of cards, and requiring each team member to decide on a good and a bad thing for the person they are considering.

Update: a version of Empathy Snap is featured in the book Fun Retrospectives by @paulocaroli and @caetano_tc

Update 2: Steve Carter used Empathy Snap while expanding a team:

Update 3: Guillaume Charmetant evolved the ‘SNAP’ with a ‘high five’:

Update 4: 2017-05-17 – edited the order of the cards to be Name then Big Hitter following feedback at an agile coaching weekend. This made the exercise clearer for people taking part.

Update 5: the Empathy Snap exercise is included in an academic paper from 2015 (!). See Jovanovic, Milos, Antoni-Lluís Mesquida, and Antònia Mas. 2015. ‘Process Improvement with Retrospective Gaming in Agile Software Development’. In Systems, Software and Services Process Improvement, 287–94. Springer, Cham. doi:10.1007/978-3-319-24647-5_23.

Update 6: in the UK, ‘Snap’ is a children’s card game where you try to match pairs of cards. When you get a match, you shout “SNAP!”.

Continuous Delivery in London – recent events and new Meetup group

The last few months in London have seen a surge in interest in Continuous Delivery by companies wanting to speed up delivery of their web-based software systems. See below for a summary of the events I have been fortunate to be involved with (I know there are many more); if you’re interested in Continuous Delivery and you’re in or close to London, then join the London Continuous Delivery meetup group (#londoncd) and let’s share our experience.

London Continuous Delivery logo - @DaveNolan (logo by @DaveNolan!)

James Betteley: Continuous Delivery using Maven

James Betteley gave a useful talk at BCS on how he used Maven in a Continuous Delivery context alongside Artifactory, Nexus and Sonar. James blogged about using Maven for Continuous Delivery back in February 2012: well worth a read, even if you’re not using the Java+Maven stack.


In July, Christopher Marsh of AKQA talked about his company’s success with Continuous Delivery on a London-based project for a large client organisation. They used GO from ThoughtWorks Studios for implementing the deployment pipeline.


I went to the London offices 7digital for a Devs In The ‘Ditch session last week, where Chris O’Dell explained how they have moved from painful, irregular releases with tightly-coupled code to frequent small releases and a service-oriented approach. The transformation took two years, and they now restrict deployable units to about a day’s worth of work to make deployment easier. GOOS co-author Steve Freeman also gave a useful talk on full-system testing, which is crucial to get right in a Continuous Delivery context.

ThoughtWorks Studios GO 12.3

The ThoughtWorks Studios product team have changed the pricing model with the 12.3 version of their agile release management tool GO: the free Community edition how has feature parity with the pay-for editions, including previously enterprise-y only features such as LDAP and Environments. This means that small teams can make full use of the excellent deployment pipeline features of GO without the price tag. I was always a bit reluctant to recommend using GO before now because the free version was feature-limited, but with all features now available in all editions, I have to say that for modelling and implementing deployment pipelines, there is other no tool which comes close to GO.

WebPerfDays EU 2012

I was fortunate to be able to present at WebPerfDays EU 2012 on how build and deployment shapes software architecture at [slides] along with Andie and Oddur from CCPGames. Three of the many really excellent discussions that came up were:

  1. Why you should design your pipelines up front [more on this from me soon…]
  2. How to get real ownership of software (e.g. service/product teams, devs on call, etc.)
  3. Jenkins vs TravisCI vs TW GO for deployment pipeline automation

Slides: How build and deployment shapes software architecture at

In the end, we had to be ‘evicted’ from the room; we could have gone on discussing for another hour! Apparently, one major UK publisher had nearly 10 staff in the session, and rated it the best session in WebPerfDays. It was so great to be among such brilliant minds and conversions, which led me to…

A London Continuous Delivery meetup group

Based on conversations and discussions at At WebPerfDays it was clear that a London-based meetup group centered on Continuous Delivery would be interesting for quite a few people and organisations.

A few of us agreed to get things off the ground, and we’re now on at London Continuous Delivery ( and on Twitter with #londoncd. Any help, donations, perks, etc. are very welcome.

Avoiding Legacy with Deployment Automation and Infrastructure-as-Code

Learning from ‘Working Effectively with Legacy Code’ by Michael C. Feathers

Working Effectively with Legacy Code by Michael C. Feathers is a classic software development text. Not only is it still completely relevant when working with code, seven years after it was published, but also the approaches it advocates at the source code level are becoming essential to apply at the component and system integration levels too as our software systems become more complicated and polyglot, and we learn to fully automate our deployments and treat our infrastructure as code.

Book cover: Working Effectively with Legacy Code

For an overview of the book itself, read my review of ‘Legacy Code’ on I describe the different sections and how each is useful in a particular context. The rest of this article will focus on other aspects of Legacy Code, particularly the ‘why’ of changing code, and the implications for Continuous Delivery, infrastructure-as-code, and deployment automation.

Continue reading Avoiding Legacy with Deployment Automation and Infrastructure-as-Code