Here is a video interview I gave summarizing some of the main themes and discussions which came out of the DevOps Summit on May 23rd in London: a shared goal for development and operations; anti-fragility as a way for DevOps and ITIL to complement each other; surface the quality of the software for all to see; tools can produce a step change in behavior for the better; and use the theory of constraints to focus improvements.
[#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. http://devopsnet.com/, http://www.stephen-smith.co.uk/), 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)
I have published a set of workshop notes on Github called Build Your Own Website – A Beginner’s Guide, covering the basics of HTML and WordPress-driven websites. I gave the workshop at a recent Engineering Day event at thetrainline.com, where the audience was largely non-engineers from marketing/finance/HR etc., and it was interesting and useful to return to the first principles of HTML in ways accessible to novices.
Build screens (or build monitors, or information radiators) are an important tool in helping to achieve Continuous Integration and in trapping errors early. When the number of build jobs becomes large, it can be tempting to hide ‘successful’ jobs to save space, but we found this to cause problems. I realised that people need to know the context for the red jobs if they are to take prompt action to fix failing builds, so it’s important to represent the full state of all builds by showing green jobs too.
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:
- Each team member gets two index cards and a marker pen.
- On the first card they write their name at the top and place this card on the table or hand it to the facilitator.
- 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.
- 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.
- 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.
- 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.
- The named person then reads out what their big hitter actually was.
- If there is a match, then SNAP!
- 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:
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: https://leanpub.com/funretrospectives
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!”.