The transformational power of Continuous Delivery

Posted on by Matthew Skelton (@matthewskelton)

I was recently asked to answer some questions about Continuous Delivery for someone’s undergraduate university research. The questions were interesting, so here are my answers 🙂

  1. What do you feel are the benefits of adopting Continuous Delivery?
  2. How do you feel adopting Continuous Delivery has affected your development cycle?
  3. Do you think Continuous Delivery is an important approach for a company to pick up, If so Why?
  4. How do you think Agile compares to more traditional models like Waterfall?
  5. What is the biggest change you’ve noticed since adopting Agile?
  6. What do you foresee in the future for these models in the industry?

1. What do you feel are the benefits of adopting Continuous Delivery?

The benefits of Continuous Delivery are huge:

  • Greater focus on finishing and shipping.
  • Increased awareness of need for setting up the work to enable feedback and learning.
  • Sense of ‘flow’ within teams.
  • Decisions made using actual data rather than opinions alone.
  • Higher quality software.
  • More joy in work.

(Can I stop yet?)

2. How do you feel adopting Continuous Delivery has affected your development cycle?

(Answering on behalf of our clients) Continuous Delivery has helped us to increase the ownership over software and focus on the value-add things that our organisation produces, rather than ceremonies around testing and releasing.

3. Do you think Continuous Delivery is an important approach for a company to pick up, If so Why?

Yes: adopting CD properly can be truly transformative for the organisation as a whole. IT becomes a means to receive rapid feedback on product/marketing/service offerings, allowing the business to invest more wisely and do more with less risk and lower costs.

4. How do you think Agile compares to more traditional models like Waterfall?

Agile is woefully misunderstood (as was Waterfall) so in that regard, they are similar (!). Truly agile organisations are rare because agility challenges entrenched, comfortable positions within an organisation. Agile done well really makes the nature of an organisation transparent.

5. What is the biggest change you’ve noticed since adopting Agile?

(Answering for our clients) We’re able to improve the software delivery part of the process, but this has highlighted the lack of clarity and vision in the Business.

6. What do you foresee in the future for these models in the industry?

We’re starting to see a backlash against Agile and DevOps already, because people misunderstand or misrepresent what’s going on. Things like SAFe seem to be rebranded PRINCE2 which is a shame. Essentially, many organisations are going to fail because their management does not see the need to change.

At Skelton Thatcher Consulting we have put together a handy Continuous Delivery checklist template (on Trello) to help you assess the things you need to address within your organisation:

2017-03-20--cdchecklist.info

See cdchecklist.info 

 

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

Posted on by Matthew Skelton (@matthewskelton)

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 Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

What Team Structure is Right for DevOps to Flourish?

Posted on by Matthew Skelton (@matthewskelton)

Update (2022): my company Conflux now offers consulting and training around DevOps topologies and related practices like Team Topologies.

Update (2019): I have co-authored a book – Team Topologies – that adds brand new material to these (original) DevOps Topologies patterns. In the book we cover dynamic organization evolution, team interaction patterns, the strategic use of Conway’s Law, monolith decomposition, and many more topics.

See teamtopologies.com and follow us on Twitter at @TeamTopologies for updates. The book is published by IT Revolution Press (Sept 2019).

Team Topologies: organizing business and technology teams for fast flow
Matthew Skelton and Manuel Pais
IT Revolution Press, Sept 2019

Update (2016): A new version of these DevOps team topologies is now here: devopstopologies.com

DevOpsTopologies-screenshot
Find more DevOps team topologies at 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.

Butterflies in a Museum
Photo by James Emery: http://www.flickr.com/photos/emeryjl/3535989711/

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 What Team Structure is Right for DevOps to Flourish?

The Business Case for DevOps

Posted on by Matthew Skelton (@matthewskelton)

[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 The Business Case for DevOps

Questions to ask when applying for DevOps jobs

Posted on by Matthew Skelton (@matthewskelton)

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 Questions to ask when applying for DevOps jobs