We are seeing many organizations starting to adopt DevOps. The majority having already deployed Agile but not getting the hoped for benefits because of…….dare I say it….’Ops’. Developers see Ops as the people that say ‘NO’ to everything or the D e l a y I n g factor slowing everything down. As a result of this disappointing discovery the word DevOps seems to be thrown around a lot more, providing a new word to be ticked off on the ‘buzzword bingo’ card. Ops see it as yet another attempt at forcing through poorly controlled changes and then blaming Ops when things go wrong.
A clear, well thought out, well defined, senior level business mandate is then formulated:
‘Do something with DevOps’!
This mandate trickles its way down towards the IT alchemists…er sorry ‘architects’ who look into their glass ball and sagely declare ‘We need some DevOps tools’. It trickles its way down into the bowels of application development and gets translated as ‘NoOps’. Somebody in Ops says the word ‘ITIL’ and gets thrown out of the room. Somebody else says ‘Culture’ and the answer is ‘give them a DevOps certificate’! The business hears the word DevOps and statistics like ‘2000 deployments a day’ and begins to salivate and ask for it to be installed next week. Of course this all takes place as part of an end-to-end strategic plan… then the User stories end up being fairy tales – what started out being described as a prince on a white horse turns into an ugly frog with warts, as the promised business value ends up next to the pot of gold at the end of the rainbow….pardon my mixed, fairy tale metaphor’s, must be something to do with all these DevOps Unicorns I keep hearing about.
From DevOps to DevOooops
So we put some DevOps metrics in place to help us measure the value we are getting. However because it’s called Dev-Ops we measure success in terms of internally focused Dev and Ops metrics such as:
- Faster time to market;
- Lower failure rate of new releases;
- Shortened lead time between fixes;
- Faster mean time to recovery (in the event of a new release crashing or otherwise disabling the current system…..what? never heard of THAT before!).
……Not a lot of metrics about ‘Business value realized’
‘…..who’?
‘I said Business value realized’?
‘….Which code feature was that’?
By focusing too much on DevOps as opposed to BusDevOps it means we can turn white horses into frogs much faster, more often and generally have the frog alive at the end of the process.
The fact that the princess doesn’t want to be carried off by a frog with warts isn’t our problem, the princess should have thought about that before asking for 3 wishes.
I looked at the source of all wisdom in the universe – ‘Wikipedia’ and found this little nugget to support my observation ‘… a study released in January 2017 by F5 of almost 2,200 IT executives and industry professionals found that only one in five surveyed think DevOps had a strategic impact on their organization despite rise in usage’. Which seems hardly surprising if the metrics above are the key metrics.
And so the business lived happily ever after in its blissful ignorance until somebody goes and ruins it all by saying ‘…but he isn’t wearing any clothes’!…for those of you not up to speed with fairy tales this is about the ‘Emperor’s new clothes’, the weavers promised a new suit of clothes that they say is invisible to those who are unfit for their positions, stupid, or incompetent….back to DevOps….somebody goes and ruins it all by asking ‘What is DevOps’? or more commonly ‘Where is the DevOps magic recipe book or implementation guide’?….There isn’t one. DevOps you get to make up as you go along.
So how do we stop this fairy tale from ending up as a nightmare?
Enough about fairy tales……..Play a game!
What has a game got to do with all this?
We played a Phoenix Project DevOps business simulation game with a team of internal organizational consultants who were to advise their organization about DevOps. There were already initiatives underway for a technology solution. Ops had heard rumors. The team wanted to know what was all this DevOps stuff about? After all if they were to advise the business then they should know something about it….very strange I thought! This hasn’t stopped consultants in the past J
They were disappointed when I said there was no fixed standard for DevOps like there was with ITIL. ‘You will have to make it up as you go along’ I suggested.
“If you don’t know where you’re going, any road will get you there” – Lewis Carroll.
So the question is ‘Where do we want to go with DevOps’? We decided to play the game to explore and identify some key DevOps ‘principles’ that they wanted to capture and make part of the high level discussion document. We had a flip-over in the corner of the room and each time during the game the team discovered an important principle they added it to the flip-over.
These were their captured principles:
- BusDevOps – not DevOps – to ensure that the business realizes the commitment it also needs to make in terms of product manager involvement to help ensure business value is achieved.
- Focus on Value creation and value leakage (including technical debt) – The business must realize it’s not JUST about NEW features as fast as possible.
- Integrated, automated testing with test driven development (Testing engaged up front – not at the end) – first we need to understand and adopt this end-to-end concept before we start rolling out a whole suite of automated tools.
- Needs to be a consultant/coach in all new DevOps teams to help them learn to self-organize, to be able to reflect and capture iterative improvements and organize stand-ups, to be able to organize and use a visual management capability – Self organizing teams don’t happen because you simply press the ‘install self organizing teams’ button!
- Teams need to reserve time for reflection and improving their work. DevOps doesn’t happen overnight. It will require trial, error, experimentation, learning and improvement. “Improving your work is just as important as doing your work”.
- A culture for sharing knowledge, daring to say ‘I don’t know’, investing in creating new skills and cross functional teams. No more ‘hero’ culture.
- T shape skills not just technology skills. 3:1, 1:3. This includes 3 people who can run a stand-up and a reflection session. This can be anybody in a team. It doesn’t have to be a manager. A manager ‘telling’ can kill ‘open feedback and exploration and experimentation’.
- Metrics that matter. Value realization is an important metric to also validate the maturity of the business case, not just ‘I am the business and I want this feature now’!
- Everybody has the right to say stop! Either flow isn’t working or communication isn’t clear or help is needed. The team then swarms the issue until it is solved, if needed an improvement item is added to the visual continual improvement board.
- No blame. Failure is an option. So long as we learn from it and can prevent it happening again. Blame kills the open, learning culture.
- Communications discipline. No assumptions. Listening, letting people have their say. Confirming
- Make the priorities and the ‘why’ clearly visible at a stand-up to speed up decision making and create a shared sense of purpose.
- Work is done when the business value is realized, not when the code it deployed.
- You make it you manage it. Ensure manageability is built in. Same team fixes failures after go-live. Knowledge shared and transferred into Incident management capabilities.
- Visual management should also contain visualization of improvements to be made in the way of working, not just visualization of work to be done.
- Single piece flow. Don’t do too many things at the same time, mistakes occur and people get frustrated.
- Service management needs to be included. E.g, Problem management can enable feedback and help build quality in up front to prevent unplanned work. Defining and approving standard changes to make change management flow more smoothly.
A game is just a fun way of learning. Right?
The team found it a valuable exercise to explore and discuss what DevOps is and isn’t. It is an exercise that needs to be repeated with key decision makers to create a shared understanding and commitment said one delegate. Another suggested it was a valuable exercise for DevOps teams, bringing Dev, Ops and Business people together, in a safe environment, to explore and learn what it will mean, what new behaviors need to be developed and to learn how to effectively communicate and collaborate.
Summary:
BusDevOps
We are seeing many organizations starting to adopt DevOps. The majority having already deployed Agile but not getting the hoped for benefits because of…….dare I say it….’Ops’. Developers see Ops as the people that say ‘NO’ to everything or the D e l a y I n g factor slowing everything down. As a result of this disappointing discovery the word DevOps seems to be thrown around a lot more, providing a new word to be ticked off on the ‘buzzword bingo’ card. Ops see it as yet another attempt at forcing through poorly controlled changes and then blaming Ops when things go wrong. By focusing too much on DevOps as opposed to BusDevOps it means we can turn white horses into frogs much faster, more often and generally have the frog alive at the end of the process.
