Category Archives: DevOps

B.F Skinner on #DevOps (circa 1985)

I came across this interview with one of the founding father’s of behavioural psychology, B. F Skinner, the other day and was immediately struck by the phrase below:

What’s needed is to give satisfaction back to people. It’s the difference, he said, between a craftsman who makes a complete chair and a person on an assembly line who makes only the legs. The craftsman’s work, Skinner said, is constantly reinforced by the process of seeing the chair take form, and finally of producing the finished chair. But the assembly-line worker sees only chair leg after chair leg — never the completed product.

Skinner is not advocating elimination of important modern advances, such as the assembly line. But he would like to see industrial engineers and psychologists continue to team up and produce better workplaces and better ways of working that will offer modern employees the psychological lift that the craftsman once felt.” B.F. Skinner interview

To me, this neatly encapsulates one of the central tenets of the DevOps movement – we want to “team up and produce better workplaces and better ways of working” that deliver simultaneously better value (faster) for our organisations AND  improve the morale and job satisfaction of Developers & Operations staff. 

We need to CARE about the “completed product” because we’re following the “First Way” of Devops and using systems thinking models to look beyond our silos and relentlessly focus on the big picture. 


“is your organisational culture ready for #DevOps?”

“What would you say are the primary indicators that your organisational culture is ready for DevOps?” was a question Sean Ferigan (@ferigan) posed at the recent Rackspace DevOps Breakfast Briefing.

This short (48s!) answer was filmed after the panel to try and give a (very) quick answer.

So basically you’re in fertile ground for DevOps if you’re seeing a “push/pull” model

  • “push” from below where technical staff are keen to try DevOps tools & technology (going to DevOpsDays, doing “skunk works” DevOps projects etc) and
  • “pull” from the Business to deliver business value via technology faster & faster (time-to-market acceleration)

I’d particularly say that if you’re seeing high levels of Shadow IT then you’ve got a great “pull” signal that you have to start doing things differently before you become irrelevant to your organisation.

@DevOpsGuys in the press, talkin’ #DevOps

Lots of great press coverage of DevOpsGuys this week courtesy of the Rackspace, #DevOps breakfast briefing. 5 separate articles so far!


Great to see some mainstream IT publications talking about DevOps! 


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 –