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 🙂
- What do you feel are the benefits of adopting Continuous Delivery?
- How do you feel adopting Continuous Delivery has affected your development cycle?
- Do you think Continuous Delivery is an important approach for a company to pick up, If so Why?
- How do you think Agile compares to more traditional models like Waterfall?
- What is the biggest change you’ve noticed since adopting Agile?
- 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:
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:
There were several specific points made by Pete that were interesting for me:
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.
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:
- Using appropriate terminology
- Recognising the huge technology shift which has occurred over the last few years
- Emphasising the importance of operability in our software systems
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.
[#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 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.