It's the Ranger4 #DevOpsFriday5 series! In the chair today is Rob Vanstone - take it away Rob!
1) What's your preferred definition of DevOps?
I am actually quite tired of trying to define the term DevOps because I actually don’t believe it should exist :). When pressed I think the whole activity should be summed up with focusing all of our teams on the single act of delivering our business to our customers and doing it better than we did last time and better than our competitors. I am much more interested in the practices that contribute to achieving these goals.
2) When people 'do' DevOps, what's the most common mistake you see them make?
Ironically (for someone who is in the business of promoting and selling tooling), I think the biggest deviation (I can’t call it a mistake!) from the goal is to just assume that a bunch of tools can solve all your problems. This leads to a sub-team (or even a DevOps team in its own right) spending the majority of their time playing with the latest shiny toys and ignoring the day to day activities that still must go on in the journey to achieving the goals mentioned above. This is actually counter to what most definitions of DevOps subscribe to; breaking down those traditional silos between the development teams and the Ops teams.
3) How do you recommend an organisation new to DevOps start?
For me, to achieve those goals in the first place, the whole organisation has to buy into exactly where the pain/waste is and then put in place processes (and yes tooling) to overcome those issues. Before they can do that though, they need to measure key metrics on the journey from business idea to customer feedback – get a baseline, understand as an organisation where the pain points are and what the low hanging fruit is (actually all the fruit, some of the high stuff might be worth tackling early in some cases) - that should I think be the focus.
4) What's your prediction for what DevOps will look like in 2020?
Dev what? Seriously though, It would appear that the promise of containers as the new packaging format could bridge the gap between infrastructure and development nicely. The Operation of these will still exist as a challenge though, we will still need to understand what we have delivered, what shared services the solutions being developed depend on and how to manage new delivery into this area. We have been talking about this for many years and I expect that we will continue to do so, perhaps with a shiny new name. I think that the DevOps movement (despite my grumpy old man semantics based comments) is a force for good and I think by 2020 the surviving companies will be the ones who are very in tune with how they are delivering IT promises to their customers. There will be new challenges for sure, not least the 5 billion devices (“things”) out there among the customer base, but I think good IT organisations will at least have positioned themselves to react better…I hope we’re not still defining DevOps by then :).
5) Where do you like to go to get a DevOps hit?
I actually love attending events and interacting with customers and prospects. Events are great generally; it’s often a relaxed atmosphere, a rare few moments where you’re not under the cosh to fix an issue in production and that often brings out a lot of enthusiasm for what life could be like. Sure they have their downside; you get a lot of grass is greener type conversations, but from my perspective that all evens out as people talk to each other more.
Today's #DevOpsFriday5 is a rather special edition and technically could be referred to a #DevOpsFriday10 as Rob has not only answered the original questions but graciously offered to be the first person to answer the new updated questions - please find below these below. Thank you Rob, stay DevOpstastic!
6) How would you describe the relationship between DevOps, Agile and ITIL?
Quite honestly? I don’t. I believe that certainly DevOps and Agile fit hand in glove. I think organisations that have embraced agile development would quickly get to the point where the traditional divisions between development and operations (and for that matter other teams who have a stake in the continuous delivery of valuable software to their customers) become painfully apparent. The start of the journey here is most often an agile delivery team cranking out shippable releases of software. The DevOps definition of extending Agile Principles to Operations fits.
I am certainly not an ITIL expert, it’s been a while since I worked through the processes at a large enterprise, all of which felt (from a development perspective) to be based around restricting the change to our customers. At the time (and probably now) I was not qualified to question those organisations' interpretation of ITIL – there were centres of ITIL excellence doing that – and I think that actually highlights the problems old implementations of ITIL faced.
DevOps has actually gone through a similar learning curve. Initially there was a lot of talk of DevOps teams being formed - hopefully that anti-pattern has been quickly stamped out. DevOps (DevBizTestOps…) is applicable to everyone trying to achieve the company’s goal of staying relevant and competitive for their customers. I believe (and I should research more) that the raw idea of ITIL is a force for good, certainly in terms of its model. The devil is always in the detail and it is the interpretation of ITIL and consequential implementation that perhaps distorts its value.
7) Can you describe what DevOps looks like when it’s ‘done’?
Not easily, given it’s a fairly broad scope and different meanings to different organisations. I guess it boils down to having a number of attributes that align with the People, Process and Tools pillars cliché. I don’t think that DONE means you get everything right all of the time but probably, more realistically, it means you at least know how you did most of the time and can as a result make adjustments to improve. In that context you’re probably never done.
How do we achieve this? Well, I think we need a culture where our teams work openly together. Foster experimentation, tolerate failure and measure everything. I think teams that don’t have the concept of “It’s not my job” are good examples. Teams that can form without a silo’ed view of dev, test, business, ops but can actually fulfill all of those roles are a good measure of done.
I think, in terms of process, a good measure of DevOps is how focused and disciplined you are adopting and adhering to proven practices such as Agile, Test/Behaviour Driven development, Continuous Delivery, Lean thinking, Continuous Change, Retrospective learning, sharing knowledge and behaviour. If you can tick a lot of these areas and have well understood and passionate advocates for these ways of working then you can consider yourself good.
In respect of technology, then careful consideration should be to use tooling that helps you achieve your goals, adhere to your processes and fit your team's work style. For me that tooling should automate the drudgery and boring aspects of your peoples' roles and free them up to concentrate on the creative aspects. So test tools should do all of the donkeywork but allow those performing that role to want to create more and more relevant tests. Deployment tooling should concentrate on allowing the developers and operations to ignore the dull repetitive aspects of a deployment freeing them up to concentrate on making more efficient ways of distributing and managing their valuable software…
8) What do you think are the key metrics for DevOps?
I think they’re extensions of those used in agile development. Foremost I guess is the time it takes to get from business idea to delivered implementation. How often these “experiments” are being conducted. How often your customers are disconnected from getting at your business, how long it takes to resume that service. I think there are other softer metrics too that should flow into this. How often am I replacing my staff? How many celebrations are we having as a whole business, How many cakes we are eating because it’s Jim in Marketing’s birthday, or Mary’s in Development Team Hammer…
9) What attributes constitute a culture embracing DevOps?
I think I have covered these above, but they’re probably worth listing:
- Less fear of change
- Less fear of mistakes (Which comes from the fact that we don’t make many and the ones we do make can be fixed very quickly)
- Great communicators across many disciplines
- A lack of Heroes (or everyone’s a hero because they contribute to everyone’s learning)
- An organisation that is prepared to experiment scientifically to delight their customers and beat off the competition.
10) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
I don’t think Continuous Delivery is a goal of DevOps, I think it is a means to achieve the goals we have. We want our business in front of our customer and remaining relevant to that customer to such an extent it is chosen over and above our competitors. There are practices that can help us achieve those goals. Continuous Delivery as formulated by Messrs Humble and Farley (and many others!) is, right now, our best attempt at delivering high quality software and is based on a scientific approach. All of the “Continuouses” we can think of are aimed at making the idea-to-feedback cycle as short as possible with as little waste as possible. All of these are coherent with achieving the goals we define under the umbrella of DevOps.
About Rob: Rob Vanstone is a sales engineer and continuous delivery consultant for XebiaLabs in the UK. He has a passion for improving the state of IT within organisations and focuses primarily on the delivery pipeline from business Idea through testing and on to direct Customer feedback. A regular speaker and exhibitor of DevOps and Continuous Delivery events globally Rob likes nothing more than interacting with organisations pursuing these goals. Outside of this arena Rob loves spending time with his family, playing squash and coaching at his local rugby club.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.