Category Archives: DevOps

3 more #DevOps litmus tests…

We wrote back in August about 3 “litmus test” questions about #DevOps in your organisation. We’d like to add 3 more questions that focus on the more operational aspects of DevOps.

(1) Does Ops attend your Scrums?

Not every organisation can easily restructure to a DevOps model of having Dev&Ops fully integrated into cross-functional teams (or at least not at first).

But one thing we can do to build a bridge between Dev & Ops is to participate in the Agile/scrum development process.

So does Ops have representation at your daily standups? Are they participating in your sprint planning and retrospectives?

If they aren’t then you fail this DevOps litmus test!

(2) Where’s your Ops repo?

One of the key tenets of the DevOps CALMS model is A for Automation. Automation generally implies code, and code should be in source control.

We generally find that most Ops teams moving towards a DevOps model and investing in automation have their own source code repository to store their code. Some people might argue that automation code related to a specific application or service should actually be in the repo with the application code, which is also a valid pattern.

Either way – the litmus test is “where’s your Ops repo?”. If the answer is “we don’t have one”… you’re doing scripting, but you’re not doing DevOps!

(3) What’s your github username?

Ok, I know that not everyone uses Github (or Git as their DVCS) but you tend to find that most DevOps people have a github account so they can contribute back to the community by sharing their work, contributing to open source projects, creating their own projects or forks etc. I’d argue that having a basic working knowledge of git is just about a “must have” skill for modern DevOps people.

The generic form of the question for Ops people is “what’s your login details and how do you access your ops repo (from question #2 above?”. If the answer is “I don’t have one” or “only the people in the DevOps team have access” you might have created a DevOps silo that might become a barrier to wider DevOps adoption across your organisation.


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!