Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

Update: the video of Pete’s talk is here on Vimeo:

Pete Mounce video frame

There were several specific points made by Pete that were interesting for me:

Continue reading

What Team Structure is Right for DevOps to Flourish?

A new version of these DevOps team topologies is now here: devopstopologies.com

The new version has many new topologies that we’ve encountered in the wild and we’re taking pull requests on Github for additions and changes.

The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management; this means that different organisations might need different team structures in order for effective Dev and Ops collaboration to take place.

So what team structure is right for DevOps to flourish? Clearly, there is no magic conformation or team topology which will suit every organisation. However, it is useful to characterise a small number of different models for team structures, some of which suit certain organisations better than others. By exploring the strengths and weaknesses of these team structures (or ‘topologies’), we can identify the team structure which might work best for DevOps practices in our own organisations, taking into account Conway’s Law.

Continue reading

The Business Case for DevOps

[At the Unicom DevOps Summit on 23rd May 2013 in London I gave a talk on The Business Case for DevOps; here is a summary of the talk, along with the slides. Update: now with video too.]

With an increasing number of organisations turning to DevOps to try to improve their software systems, it is becoming necessary to provide the business case for introducing DevOps, especially in organisations which perceive their main focus to be something other than software systems.

For me, building the business case for DevOps has three strands:

  1. Using appropriate terminology
  2. Recognising the huge technology shift which has occurred over the last few years
  3. Emphasising the importance of operability in our software systems

Continue reading

Questions to ask when applying for DevOps jobs

Here are some criteria which should be useful when trying to cut through the tangled mess of “DevOps”  job titles in order to work out if a prospective role will actually lead to working within a DevOps culture, or whether you’ll be stuck in an old-school IT silo with a fancy “DevOps” name tag and the same crappy us-and-them mentality.

Continue reading

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. 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)

Continue reading

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

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, 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
  3. On the second card they write their name at the top and place this second card on the table or hand it to the facilitator.
  4. Once all team members have handed in their ‘name card’, 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:

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