Is the S (Sharing) in CALMS Redundant?

@MLCarey321 asked a interesting question on Twitter the other day – is the S for Sharing in the CALMS model not redundant? If you have the right culture that emphasises collaboration & “no silos” surely “sharing” flows out of that? 


My view is that from a cultural perspective he’s probably right, a DevOps Culture definitely should encompass “sharing” as a core value so why do we need the extra S? 

CALMS Model of DevOps

I think that the extra S is there to emphasise that just having “sharing” as a core value isn’t enough – you need to actively put in place mechanisms to promote, facilitate and reward sharing at multiple levels

For example here at DevOpsGuys we:

  1. Heavily use Atlassian Confluence as a wiki for documentation and documentation is seen as a “living thing” that must be kept up to date because it has value to the team every day.
  2. Use HipChat for informal communication, “What am I doing now”, “Does anyone know something about topic xyz” etc. HipChat is also integrated with JIRA, PagerDuty, CI/CD. 
  3. JIRA Kanban boards for sharing “this is what the team / individual is working on how”, plus time-tracking and work status. 
  4. All of the 3 above are also accessible by the clients – so sharing means “sharing with the customer” too, not creating an “us&them” silo. 
  5. Blogging and presenting to share with the community is strongly encouraged and we’ve started a meetup group DevOps Cardiff (in addition to London Web Performance that I’ve run for 3 years)
  6. Our GitHub repo is a bit sparse at the moment but we hope to open-source some stuff in the future, particularly some samples around Powershell DSC

As we grow and we bring on more grads & apprentices everyone will be paired with a senior mentor to ensure that skills & experience are shared across team, and we’ll start doing weekly “brown-bag” session to further share knowledge.

One area we haven’t looked at yet is explicitly promoting sharing via an incentive/bonus scheme based on “# blog posts” or “# open source commits” or “StackOverflow Reputation“, mostly because I’ve never seen it work successfully in previous organisations in which I’ve worked.

That’s not to say it can’t work… but you have to think about it very carefully or otherwise you risk incentivising the wrong behaviour. My feeling at the moment is that this will remain “ad-hoc” when someone shares “something cool” or gets accepted to speak at a conference or something.

How do you promote, facilitate and reward sharing in your organisations? 


DevOps – The 3 question #DevOps Litmus Test

Are you REALLY doing #DevOps inside your organisation?

We’ve spoken about the 8 pre-requisites for DevOps before but today we’d like to propose a very quick “litmus test” to see if you’re really aligning your organisation with key #DevOps principles and not just doing infrastructure and release automation with a DevOps whitewash.

These 3 questions have been formulated of the basis of visits to companies that say they are doing DevOps and/or conversations with people at conferences & meetups about their progress with DevOps transformation.

#1 – Have you spoken with HR yet?

DevOps is about people.

HR are the “people people”. So how can you have do an organisational transformation (even if the scope is limited to just the IT department… which it shouldn’t, but I digress…) without involving HR?

DevOps will involve new ways of working, possibly new organisational structures, new incentives, new on-call rotas etc – all of which will have a direct impact on employees terms and conditions

Regardless of whether you see HR as Change Makers or Handmaidens at some point you will need to talk to them… and I’d recommend doing it sooner rather than later!

#2 – Have you spoken with Finance yet?

In a word… Flow.

Jez Humble has presented about Flow, Gene Kim talks about Flow in the 1St Way of Devops and we’ve even blogged about flow and getting off airplanes.

So what’s flow got to do with Finance?

Well, Finance people are, by and large, are addicted to ROI, and the easiest way to measure ROI is a project-centric view of the world. You propose a fixed unit of change with some notional return on investment, get allocated a cost code, Finance tracks that cost code, allocates you more money when you overspend because the project’s running late, and then sweep it all under the carpet when the whole business case turns out to be a bunch of hot air. Or maybe that’s me being cynical?

We happen to believe that the project-centric view of the world is also a great way to DESTROY value. I’d recommend checking out Allan Kelly’s posts on #NoProjects and #BeyondProjects for some great though-provoking stuff on this topic!

In any case the project-centric view of the world is normally “lumpy” – activity is tied to the budgeting cycle, things tend to start in waves – and budget ends when the project ends and then the job of running it in Production is allocated to a different cost code (normally the BAU cost centre).

All of this impedes achieving flow, and having a product-centric view of the world. So in order to achieve a true DevOps model you need to talk to Finance about how budgets are allocated, and ideally try to move towards a product-centric budgeting model.

#3 – Who’s your senior management sponsor?

Look, we’re huge fans of grassroots DevOps initiatives where enthusiastic people are trying to bring #DevOps principles into their organisation from the bottom-up. We’ve even been known to hand out hardcopies of the Phoenix Project to key people within organisations to try and get them thinking about better ways of delivering IT :-) 

But let’s be brutally honest – that’s only going to get you so far, and to get any further you’re going to need an allocation of resources (time & money) in order to really get things done.

And the best way to get money is to have a senior management sponsor push the initiative forward, remove obstacles and generally take credit help you achieve your DevOps transformation. So if you DON’T have a senior management sponsor then at best you’re doing a #DevOps pilot project, you’re not really “doing DevOps”. Yet.

Anyway, those are 3 quick questions you can use as a DevOps litmus test – what questions would you ask?

#DevOps – The Need for Speed – The Business Value of DevOps

Here is the video from my recent talk on DevOps and “The Need for Speed” at DOX London 

Need for Speed Talk Slides


p.s. I am pretty harsh on “traditional” ITIL shops in this talk, and as the comments on our earlier article on DevOps, ITIL and anti-fragility make clear it’s not “ITIL’s fault” it’s the way it was interpreted and implemented. As I say in the talk – ITIL is guidance on things you need to do to successfully manage your IT services BUT IT’S NOT A SERIES OF JOB DESCRIPTIONS THAT YOU NEED TO HIRE AND CREATE SILOS! 

Why isn’t there a “DevOps Framework” / Manifesto?

Two things I hear often are:

(1) Why isn’t there a DevOps Manifesto like the Agile manifesto?
(2) Why isn’t there a “DevOps Framework” like ITIL or SAFe?

The DevOps manifesto issues has been discussed at length

“DevOps, a movement of people who care about developing and operating reliable, secure, high performance systems at scale, has always — intentionally — lacked a definition or manifesto” –

Although there have been some attempts ( and openspaces sessions ( on the topic but you can see from the comments that there is a “no manifesto” philosophy.

“Actually at the very first #devopsdays in Gent we agreed not to have a Manifesto .. the same discussion happened in Hamburg and again the end result was .. no manifesto …” (Kris Buytaert)

The “framework” question is more complex, however.

We’ve already seen maturity assessments (, maturity models (e.g. HP and an implementation framework (e.g. IBM that (rightly) stops short of actually being prescriptive on what DevOps “is”.

The problem with a comprehensive DevOps framework at this stage is (1) it sort of misses the whole point and (2) the challenges a 100% Cloud e-commerce website faces versus a large, heterogeneous, Enterprise and how to solve them will be very different.

When I say above that it “misses the point” I’m not trying to be flippant, elitist or trendy.

My view re DevOps is that it is about experimentation, learning, feedback, evidence-based & metrics-driven decision making etc etc all within the guidance of the CALMS model.

Just taking a prescriptive “blueprint” down off the shelf (from either a vendor or “standards” body) is almost a totally opposite mindset to the above (IMHO). If you’re not willing to experiment with different working methods, tools, org structures etc how will you find the one that works for YOUR organisation, at its stage of organisational development as opposed to a one-size-fits-all and often overly proscriptive “methodology”?

That said, I do believe that there is scope for guidance, best practices, case studies etc and hence why I am eagerly awaiting The DevOps Cookbook ( and Matt Skelton, Steve Smith et al “Build Quality In” (

Everyone needs guidance and help to get them started… and practitioner-led case studies that explain “we’re this type of company and we did these things to adopt DevOps and we had these positive and negative outcomes. Your mileage might vary” are IMHO the best way to do it.

If anyone is trying to sell you a “10 step guaranteed lose weight in 30 days“, sorry I mean, “become DevOps-y in 30 days” plan then I would be taking it with a grain of salt at this stage of the DevOps maturity and hype cycle.


p.s. a version of this was originally published on LinkedIn here – 


#DevOps – defining Devops – it’s a Recipe not a Blueprint

There have been some great posts recently regarding the difficulting in defining DevOps e.g and following on from that

My view is that some of the confusion, and the multiplicity of opinions about what DevOps is, comes about because people are using the wrong cognitive frame when looking at DevOps, and maybe a bit of re-framing is in order.

Firstly, a bit of background. In The Blind Watchmaker (1986, pp. 295-296) Richard Dawkins explains that DNA is like a recipe, not a blueprint. You can’t take a slice of cake and then pull up the “cake engineering blueprint” and point to the section that specifies that part of the cake (as opposed to comparing a car or plane part to a blueprint, for example). You have a recipe… but there isn’t a one-to-one correspondence between the recipe and the cake.

“A recipe in a cookery book is not, in any sense, a blueprint for the cake that will finally emerge from the oven…. a recipe is not a scale model, not a description of a finished cake, not in any sense a point-for-point representation. It is a set of instructions which, if obeyed in the right order, will result in a cake…

The genes, taken together, can be seen as a set of instructions for carrying out a process, just as the words of a recipe, taken together, are a set of instructions for carrying out a process.” – Richard Dawkins

DevOps is a recipe, not a blueprint. And it’s a recipe that still evolving to meet the needs of different organisations, in the same way that bread recipes have evolved to meet different cultural and personal preferences.


There are 4 basic ingredients in any bread recipe – water, flour, yeast, salt – and there are core techniques – Kneading, Fermenting, Proofing, Baking etc – but by combining these techniques, adding extra ingredients etc you can have widely different outcomes.

Ingredients Techniques
Flour Mixing
Water Fermenting
Yeast Punching
Salt Dividing
Butter Rounding
Eggs Kneading
Milk Panning
Sugar Proofing


Similarly, DevOps has some core ingredients and techniques (I’ve listed a few in the table below but I am sure you might want to add your own) but how you choose to combine them and what extra ingredients you add will determine if you end up with a crusty white cob, a baguette or a ciabatta.

Ingredients Techniques
“Infrastructure as Code” Agile
Continuous Integration Kanban
Continuous Delivery Lean
Application Performance Management Theory of Constraints
Virtual/Cloud Hosting Systems Thinking


But they are all “DevOps” in the same way that all the loaves in the image above are all bread – they share common ingredients, common techniques – but the exact recipe you follow and the end result depending on your organisational needs and preferences.



DevOps gets gamified – literally!

If you didn’t think that DevOps could reach the parts, other methodologies cannot reach – then think again.

We recently discovered Release! – a fun kickstarter project created by Alex Papadimouli – which is a card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick taking card games.

According to the beta rules, “The game is simple: manage cooperation and competition with other players across 10 hands (or “releases” as we call them) to score the most points. Each release is played the same, but the scoring rules change each time as you reveal new Tools & Methods. Your team needs to continuously respond to these strategic shifts in order to produce the best release possible.”

We love the customised practitioner cards. Release! will feature 12 practitioners who have made significant contributions to the software development community; folks like Patrick Debois, Dan North, and Jez Humble (which has to be our favourite so far!)


The kickstart project can be found at

Good luck to Alex with this project, we look forward to getting our delivery teams to battle out the best Release process over a beer and a bag of nuts!

Image showing quote from Hardvard Business Review on the need to change how businesses operatte

#DevOps – Start with WHY!

DevOpsGuys presented a short 30 min talk on the “Why” of DevOps last night at the @Magentys Enterprise DevOps event (sponsored by our good friends @Dyn).

The goal of the presentation was to give the attendees some of the reasons why the current models for product development and operations might not be suitable in a rapidly changing, cloud-hosting, mobile enabled world.

One of my favourite quotes from the talk if from a HBR article by John Kotter where he talks about how business needs to change (and not just IT!). We’ll be exploring some of Kotter’s ideas in our #DevOpsMBA series of blog articles over the coming months.

“The hierarchical structures and organizational
processes we have used for decades to run and
improve our enterprises are no longer up to the
task of winning in this faster-moving world” – John Kotter

Image showing quote from Hardvard Business Review on the need to change how businesses operatte
HBR article by John Kotter – Accelerate!

The full slide deck is available below and on Slideshare.

If anyone is interested in having this presented to your teams or management at work to help kick-start your DevOps journey we’re happy to do an “encore performance” on-site (as long as you cover the travel expenses!).


Get every new post delivered to your Inbox.

Join 1,901 other followers

%d bloggers like this: