What Makes an Effective Build and Deployment Radiator Screen?

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.

Continue reading What Makes an Effective Build and Deployment Radiator Screen?

How HTTPbis changes HTTP caching, and why CDNs are not always the answer

HTTP caching is a key part of what makes the web usable, and draft standards like HTTPbis add further refinements to the existing HTTP/1.1 caching features. At WebPerfDays 2012, Mark Nottingham (@mnot) and Josh Bixby (@joshuabixby) gave some useful tips on how we can tune our web applications to take advantage of the existing and forthcoming HTTP cache features.

Continue reading How HTTPbis changes HTTP caching, and why CDNs are not always the answer

London Continuous Delivery meetup with Opscode Chef

The London Continuous Delivery meetup group had its first session of 2013 on 17 Jan. We were fortunate to be able to use the offices of [my employer] thetrainline.com in central London, and doubly fortunate to be joined by Andy Hawkins from Opscode, who ran what turned out to be a brave demo showing how Chef can work with CI tools to provision EC2 instances.

Continue reading London Continuous Delivery meetup with Opscode Chef

Festive Graphite Line Art for the Masses

You have an installation of Graphite, a desire to learn more Ruby, and some festive spirit – what emerges?

An xmas tree drawn using proper metrics via the Ruby graphite gem, of course!

Xmas tree plotted using Graphite

The magic happens with the Graphite::Logger class, because we can log metrics at specific points in time:

logger.log(when,{"Branches1" => 3})

I calculated the points to plot on paper, and found decent Graphite rendering settings by experimentation:

Planning the Graphite Xmas tree

The code is on Github here: https://github.com/matthewskelton/GraphiteGreetings – fork away!

I’d love to hear or see any suggestions for improvements to the script. Candles? Snowflakes? Reindeer?! Also, as my Ruby-fu is limited, if there are better ways of interacting with Graphite, I’d love the hear about them (I tried and failed to get activesupport to work on my machine, for example).

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_tchttps://leanpub.com/funretrospectives

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

https://twitter.com/sweavo/status/524224399420174336

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!”.