Its already over again – the annual get together of the brightest DevOps minds (well the brightest who could make it to Vegas). And in this instance I want to make sure that what happens in Vegas, does not stay in Vegas by sharing my highlights with all of you. It was a great event with a slightly higher focus on operations than last time.

The four trends that I picked up on:

• Self service operations are considered an good answer to the “DevOps Team” problem
• The prevalence of Dunning Kruger (Link) when it comes to self-assessments -> We are “DevOps”, we use the “cloud”,…
• Minimum Viable Compliance as a new term
• DevOps for AI – I did not see much AI for DevOps yet, perhaps next time

This year the conference focused much more on operations which is great, for next year I hope that we bring in some of the end-to-end business stories. How have we used DevOps practices to drive business – thinks like instrumentalization of software features to understand the business impact.

The top 3 talks

Andrew Clay Shafer

Andrew spoke in his typical eccentric style (with tie on his head) about Digital Transformations and doing DevOps. He made it clear that there is no real end to this transformation and compared it with getting fit (something he took on successfully since the beginning of the year). All the external help you can get will not make you fit, it’s the work you put in yourself. The same is true for this DevOps/Digital transformation. He also made a good point that some message can be dangerous if they are given before the recipients are ready.

J Paul Reed

I admit that I went into “5 dirty words about CI” expecting a talk about Continuous Integration like many others , something John humorously took on in the beginning. The talk focused on Continuous Improvement instead and stood out for me. Key learnings:

• Root causes are a social construct for the point where we stop looking further, more appropriately we should call those “proximate causes”
• A great story from Amazon, who used an outage caused by “human error” to look for the weaknesses in the systems rather than finding fault with the person who made a mistake
• That incidents are not deterministic – there are many parallel universes where the incident might not have happened in the same circumstances, our systems are too complex to be deterministic. The Swiss Cheese model to analyse incidents was a great take away for me.
• Human error is not the cause, it’s the effect. It’s the start of the investigation.

Damon Edwards

Okay, okay he usually is in my top list of talks because I like his style and approach. This time he told a great case study of how all the new fancy technologies and techniques did not prevent the opps problems. Which was a) funny and b) educational to move us away from all the techno-optimism. He then described the self-service operations model which I prefer myself as well, so this was good to see discussed, which is also called out in the latest puppet state of DevOps report.

 

Some other nuggets from other talks

Courtney Kissler

• First mention of “Minimum Viable Compliance”
• I loved the phrases “Geriatric stack” and “PTSD caused by legacy apps”
• Great story on how compliance can calculate negative ROI to justify investment

Scott Prugh

• Great case study where he showed the results over the years
• Showing how Agile and DevOps work together to achieve huge results
• Aligning teams to Value streams not projects and even using the platform as a product with product owner
• Some interesting aspects on lean portfolio management that is run through several “tanks” like sharktank
• I loved the metric – “% of things releases outside of release cycle”

Jeffrey Snover

• Super inspiring to hear from someone who stood up for what he believed in and that careers can be a bit like snakes and ladders (it took him 5 years to come back from a demotion)
• Insightful to hear about organisations and/or leaders having a list of people who are moving the company forward and of course those are the people that get well rewarded
• How transitions transformations can push your career – introducing the terms stair job vs elevator jobs
• Loved the point that when you are really good at something that doesn’t matter anymore that it will be bad for you (either as organisation or in your career) – great example from DEC which was excellent at something that didn’t matter anymore a and missed the move from vertical integrated to horizontal systems
• He made a point that he believes the pendelum is swinging back to vertical integrated (like Azure and AWS)
• “Build what differentiates you, buy what doesn’t”

Thorsten Volk

• Reiterated the point I have heard a few times now that AI is still similar to the 90s just more accessible and powerful
• Understand what AI and human understanding is good for and when to use what
• Start with a narrow problem and extend it once you have a useful answer
• Treat AI as code – Parameters, training set, data transformation pipeline, etc
• Use public data – there is heaps that you can use to teach your algorithms
• AI is a virtual reality as you can only see what is in the data and that data can be biased

Mik Kersten

• He introduced his new framework to help with the transition from project to product which is described in his new book, which was available at the conference for the first time (I will review it in a blog post in due course)

Rob England

• How some of the new material in the DevOps world has forgotten the old and sometimes is even reinventing it
• Interesting anecdote that the SRE book comes to the conclusion that key metric is unplanned downtime – something the ITSM community has already know
• How DevOps has not covered everything that ITSM covered like user training/Desktop management,… – there is some benefit in review the more rigorous material from ITIL
• Gave us hope that ITIL 4 will be more relevant and easier to consume vs ITIL 3 being a bit of mixed bag

Jez Humble, Nicole Forsgren

• Only 22% of people who say that they use the cloud are following the 5 characteristics of NIST – most hands went down at “OnDemand Self Service”

Cornelia Davies

• Difference between functional and imperative programming
• Why functional programming allows us to do get systems to do more for us and are less error prone because there is no state embedded
• The term “Repave environments” – refreshing every part of the environment which we should do regularly
• Introduced the concept of “Sidecars” – a container next to another container in a Kubernetes pod that deals with cross cutting concerns like security

 

Another brilliant conference is over and I am already looking forward to next year.

As Agilists we keep using the Agile manifesto and are pretty much beyond questioning the exact words on the page. One key one is:

Working Software over comprehensive documentation

And over the years we had the arguments that this does not mean that there is no documentation, what exactly the definition of working software is and many other aspects of this. Yet I failed to pick up on a very important nuance for all those years.

The other day I was running an Agile training and someone with less of an IT background called out to me that she disagrees with the statement “working software over comprehensive documentation”. I was shocked initially until she explained that working software means terribly little when no one uses it (for example due to poor documentation or change communication) or if the software does not solve a business problem.

Wow – how had I not noticed this clear miss before. Of course, we are not about just building software and the Agile manifesto came from people who were thinking about creating software in a better way. But more than decade after I started to run Agile trainings, why had I never noticed this clear gap in the manifesto for our modern context.

A few weeks earlier I was at an Agile conference in Germany and someone spoke about Agility rather than Agile and pointed out how much of the language in the Agile principles behind the manifest are software specific (e.g. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”) How have we not updated this material to be more relevant by changing all the wording to be inclusive of business and other parts of the organisation that need to enable success? See below for references to software development in more than half of the principles.

Of course, the manifesto has its relevance as historic document, but whenever we talk about it, it is worthwhile calling out that we do have a broader understanding of this now which goes way beyond IT and software development. I for one will call this out more clearly whenever I run training going forward. We are using Agile to solve business problems and creating better software is only a small part of the solution. Thank you Jane for calling out a blind spot that I have had for years!

UPDATE: Thanks to Phil i found this tweet which discusses a solution: