#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 http://blog.dataloop.io/2014/07/29/doxlon-devops-exchange-july14-continuous-delivery/ 

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” – http://www.thoughtworks.com/insights/blog/state-devops

Although there have been some attempts (http://theagileadmin.com/2010/10/15/a-devops-manifesto/) and openspaces sessions (https://sites.google.com/a/jezhumble.net/devops-manifesto/) 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 (http://www.ranger4.com/devops-maturity-assessment/), maturity models (e.g. HP http://h30499.www3.hp.com/t5/Business-Service-Management-BAC/DevOps-and-OpsDev-How-Maturity-Model-Works/ba-p/6042901) and an implementation framework (e.g. IBM http://www.ibm.com/developerworks/library/d-adoption-paths/index.html?ca=dat-) 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 (http://www.realgenekim.me/devops-cookbook/) and Matt Skelton, Steve Smith et al “Build Quality In” (http://blog.matthewskelton.net/2014/06/01/experience-reports-book-on-continuous-delivery-and-devops-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 – https://www.linkedin.com/groupItem?view=&gid=2825397&type=member&item=5897489450300100610&commentID=5899824653999837184&report%2Esuccess=8ULbKyXO6NDvmoK7o030UNOYGZKrvdhBhypZ_w8EpQrrQI-BBjkmxwkEOwBjLE28YyDIxcyEO7_TA_giuRN#commentID_5899824653999837184 


#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 https://www.jumpcloud.com/what-is-devops-blog/ and following on from that http://www.scriptrock.com/blog/the-problem-with-defining-devops.

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!).

The word flow made out of pebbles

5 useful #Devops lessons about flow you can learn while getting off a plane.

One of our favourite books here at DevOpsGuys is Donald Reinertsen’s “Principles of Product Development Flow”. It’s a compelling argument about the importance of “flow” – small batch sizes, frequent releases, rapid feedback, all the key tenets of continuous delivery and DevOps.

It is, sadly, not the sort of easily consumed management book that might appeal to your ADD-afflicted manager (should you be able to tear his/her attention away from his/her iPhone or iPad).

@TheDevMgr and myself (@TheOpsMgr) were discussing this last week as we landed at Munich airport to attend the @Jetbrains partner conference (we’re huge fans of TeamCity for continuous integration).

As we went thru the process of disembarking from the flight we realised we were in the middle of a real-world analogy for benefits of flow – an analogy that might be readily understandable to those senior managers we mentioned earlier.

Let’s walk thru it.

The plane lands and reaches the stand. Immediately everyone in the aisles seats un-clicks and stands up, congesting the aisle. Once the aisle is congested (=high utilisation) the ability of people to collect luggage from the overhead lockers is significantly reduced – everything becomes less efficient.

At high rates of utilisation of any resource waiting times, thrashing between tasks and the potential for disruption are likely to go up. So that’s Useful lesson #1.

All this activity and jamming of the aisle is, ultimately, futile because no-one is going anywhere until the stairs get there and the cabin doors are opened. This is the next constraint in the pipeline.

Useful lesson #2 – until you understand the constraints you might be just rushing headlong at the next bottleneck.

Eventually they arrive and we all start shuffling off like sheep (or zombies) and walk down the stairs… to the waiting buses on the tarmac.

Useful lesson #3 – if you’re trying to optimise flow you need to look beyond the immediate constraint.

In this, case the cabin door & stairs, and look at the entire system (this is the essential message of systems thinking and the “1st way of DevOps”).

The buses were fairly large and held about 60+ people each (=large batch size), and everyone tries to cram onto the first bus… which then waits until the second bus is full before both buses head across the tarmac. When we reach the terminal the buses park up… and the second bus is actually closer to the door we need to enter.

Useful lesson #4 – don’t assume that the batch size is what you think it is (i.e. 1 bus load). It might be more (2 buses!). Also, just because something looks FIFO doesn’t mean it is…

Once we enter the terminal we then hit another constraint – clearing Immigration control. Luckily we were able to go thru the EU Resident’s queue, which flowed at a fairly constant rate due to the minimal border control. But looking at the non-EU Residents queue that the flow was turbulent – some passengers went thru quickly but others took much longer to process due to their different nationality, visa requirements or whatever had caught the Border Control officer’s attention. Unfortunately, the people who could have been processed faster were stuck in the queue behind the “complex” processing.

Useful lesson #5 – If you can break your “unit of work” down to a relatively standard size the overall flow through the system is likely to improve. This is why most Scrum teams insist that a given user story shouldn’t’ take more than 2-3 days to complete, and if it would it then it should be split up into separate stories until it does.

Luckily we avoided the queue for checked luggage as we only had carry-on and we were able to get in the queue for the taxis instead… so that’s the end of our analogy for now.

So let’s think of some theoretical optimisations to improve the flow.

Firstly, why not only let the people on ONE side of the aisle stand to collect their overhead luggage and prepare to disembark, thereby avoiding the congestion in the aisle? You can then alternate sides until everyone’s off.

Secondly, why not see if you can get a second set of stairs so you can disembark from the forward AND rear cabin doors, and alleviate that bottleneck?

Thirdly, why not have smaller buses, and dispatch them immediately they are full, and thereby reduce the batch size that arrives at Immigration?

Fourthly, why not have more agents at Border Control to alleviate that bottleneck, or create different queue classes to try to optimise flow e.g. EU Residents, “Other countries we vaguely trust and generally wave through” and “countries we generally give a hard time to”. You could even have a special queue for “dodgy looking people from whatever nationality that are about to spend some quality time with a rubber glove”. Or why not create totally new categories like “those we hand luggage” versus “those with checked luggage who are only going to have to wait at the luggage carousel anyway so you might as well wait here anyway”.

These proposed optimisations might be simplistic. For example the reason the two buses leave together is probably because ground traffic at airports is strictly controlled (in fact there is a “ground traffic controller” just the same as an “air traffic controller”). So there are often constraints we might not be aware of until we do more investigation BUT the goal of any DevOps organisation should be to try and identify the constraints, and experiment with different ways to alleviate that constraint. Try something, learn from it, iterate around again.

Hopefully by using a common, real-world analogy for product development flow you’ll be able to convince your Boss to let you apply these principles to your DevOps delivery pipeline and improve flow within your organisation!
Photo credit: aselundblad / Foter / Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

DevOpsGuy delivers the Awesome

DevOps Cardiff kicks off with a bang!

Awesome turnout and great community involvement at our first DevOps Cardiff meetup on Wednesday night!

The pizza and beers immediately after went down very well… as did the next few rounds at the excellent Urban Tap House (well, when I say a few, we headed back to the hotel, via Wok to Walk, at about 1am. I think).

people watching a presentation
@TheDevMgr leads off!

We’re super-excited that a number of people from the Cardiff DevOps community have already put their hand up to talk at future events and if you’ve got something you want to talk about, whether its a 5 min lightning demo to a full 50 min presentation, please contact us.

Thanks also to Dyn for sponsoring and FoundersHub for hosting!

The slides from the night are on Slideshare and embedded below.


Get every new post delivered to your Inbox.

Join 1,850 other followers

%d bloggers like this: