Ranger4 DevOps Blog

It's a game, it's fun, it's playing, it's my favourite thing to do! It's not work then, is it? I mean, how can playing be serious and useful and result in a practical improvement? Here's how:

Simon Sinek's Golden Circle is a key tool we use when we are helping people understand DevOps principles. For people that are coming from a place where DevOps is about automation this can be a little perplexing, but this is a core cultural asset, and DevOps is as much about culture as it is about automation. I love Chris Little's quote from the DevOps Handbook: "DevOps is about automation, as astronomy is about telescopes."

The DevOps Institute (DOI) will be releasing V2.0 of their DevOps Leader course imminently. As an instructor, it's my favourite course to deliver and I've thoroughly enjoyed participating in the update along with many other global DOI REPs and instructors - it's been receiving fantastic feedback. Some have described the new version as 'dense' or 'meaty' but I like to think of it as rich. The course is designed for people who are leading DevOps evolutions or transformations - either within their own organisations or acting as coaches or consultants for their client organisations.

One of the DevOps myths I frequently have to address is that DevOps is all about automation and tools. Whilst they are an essential element to attain the DevOps goal of optimising the flow from idea to value realisation in order to deliver better value outcomes faster and more safely, early on in the evolution of DevOps, Damon Edwards and John Willis came up with the CALMS acronym to help explain the lenses of DevOps concern and the C taught us that Culture is also an essential element. This thinking is supported by this Gartner article that shows in their research that 50% of people asked say that people issues (as opposed to process, technology and information issues) present by far the biggest inhibitor to the adoption of DevOps principles and practices - and also my own observations with my clients who tell me culture is the most difficult challenge they face today.

Happy New Year one and all! Whilst time, or at least the Gregorian calendar, may be a human construct, I do enjoy the annual opportunity for navel gazing and setting intentions for a new dozen of months. I’ll be working with Zen koans daily in 2019 as part of my evolving interests in meditation and the brain. This however, represents my thoughts about the world of DevOps in the coming year, and is also a reflection on my thoughts on the same a year ago.

Our wonderful friends at Sonatype just released the results of their annual DevSecOps survey. For the full results you can download the report. I wrote this article for an ebook where it's collated with a number of other articles from other practitioners - you can download the ebook here.

In 2017, 57% of all participants in the DevSecOps Community survey confirmed that, yes, they did have an open source policy. In 2018 this has risen to 64% - but 35% say they ignore it.

Breaking that down further: in 2018, 58% of those with no DevOps practices and 77% of those with mature DevOps practices reported having an open source policy. 46% of the former and 24% of the latter reported ignoring it. Effectively, that’s then just 12% of organisations with no DevOps practices actually using an open source policy, while 53% with mature practices are following internal regulations. Having, and using, an open source policy is then an indicator of mature DevOps practices.

It's that time of year again! I hope everyone has happy holidays. I've been staring into my crystal ball and thinking about what's been happening in 2017 and these are my thoughts on what the big themes in DevOps are going to be in the year ahead:

1) BizIT: Whilst we are working with many organisations who are facing the classic DevOps challenge of getting development and IT operations to work better together (particularly where new digital transformation departments are accelerating agile adoption), there are many that are achieving the target state of OneIT and the friction they are feeling is more about the business' acceptance of what agile and DevOps really mean in terms of their commitment and involvement in the processes and feedback loops. As we move towards working in value streams, the lines will continue to blur between IT and the business and we'll go from align, past integrate and into 'IT is the business' and beyond where there is no separation. See what the CTO at Hiscox, Jonathan Fletcher, had to say in his talk at the DevOps Enterprise Summit in London this year.

We spend a lot of time talking about change at Ranger4, as you may well imagine, in the context of DevOps. We talk about:

• Increasing throughput and quality simultaneously as a key DevOps goal
• Where Change Approval Boards are a key bottleneck (The Theory of Constraints and The First Way: Flow) - particularly when we are Value Stream Mapping
• What DevOps Target Operating Models look like and how peer-review change works, and what Change Management roles look like

I've been sharing this article, Change Goes Away, a lot in the DevOps Foundation courses we have been delivering in recent months. I love it partly because it's so crisply written but mainly because it's by Rob England, a self-styled IT Skeptic, and who has a primarily IT Operations background. This last part is particularly important since it's often the dev people who want to do away with change, and the IT ops people who want to retain the governance that change management policies and procedures bring - so to have an IT ops person to be such a strong proponent of change changing (!) like this really supports what DevOps is doing here. And gives solid advice on how to manage this potential conflict, together.

Our partner, Sonatype, recently released their latest annual State of the Software Supply Chain report and in it provided new evidence that DevOps practices deliver measurable improvements. It also kickstarted another conversation between us.

One of the things we offer organisations is a free scan of their software to identify a bill of materials (of the open source components within an application) and a summary of the security vulnerabilities and licence risks that exist therein. Applications these days are decreasingly coded and increasingly composed from open source components available in online artifact repositories. It's not difficult to understand why developers would take this approach, as Sonatype's Derek Weeks says:

Yesterday we ran a public version of The Phoenix Project Game to give a bunch of people a feel for how it works and the kind of outcomes they could expect when they run the game with their own teams. If you missed this one but it sounds like something you want to do, we have another one in October; you can register yourself on it here but be warned - the last one booked out super-quick!