Diary entry, CEO of Parts Unlimited:
12 Feb 2020. 8.00. At least the crisp blue sky surrounding the BT Tower in London did something to raise my spirits. The latest financial figures painted a picture of grey skies and stormy weather ahead.
I was on my way to meet my business and IT team to hear about their latest attempts at deploying the Phoenix Project. They wanted to tell me how this DevOps stuff was some kind of magic bullet that will solve all of my problems. I’m sure I heard IT tell me this years ago about something called ‘ITIL’.
12 Feb 2020. 09:30. Just over half the team had turned up for the meeting, the rest didn’t bother calling or saying why they were not there! Is this the new culture they are talking about with this DevOps stuff!? I hope not, otherwise we will be talking outsourcing today!
End of diary entry.
The scene was set. The CEO was already in a bad mood. He was hoping for great things today but expecting excuses. Welcome to the Phoenix Project simulation workshop, featuring a team of delegates who attended the itSMF UK DevOps Masterclass. At the start of the day they were asked what they wanted to discover. The learning objectives fell into three categories:
- Understanding: a better understanding of what DevOps is, what it means and where it fits in with ITSM.
- Relationship: how to improve the engagement and relationship with Dev from an Ops perspective. ‘Wild Wild West of DevOps’ was mentioned, as too was the ’relevance’ of ITIL.
- Practice: gain some practical tips for ‘starting’ with or ‘improving’ DevOps
Only one delegate, playing the Lead Engineer role in the simulation, mentioned a desire to learn ‘How to use DevOps to take a business idea through to market and business value’.
‘Finally!’ exclaimed the CEO of parts Unlimited, the organisation in the simulation. ‘At least one person is concerned about business outcomes rather than DevOps!’
The learning points above represent the way we perceive DevOps in the market, most people having a strong focus on DevOps as the goal or ‘framework’, rather than what DevOps can mean for business value. Perhaps a reason to start thinking more in terms of BizDevOps rather than DevOps – let’s put the business first!
The Phoenix Project simulation workshop employs a form of ‘experiential learning’ that has been used around the globe to help teams and organisations learn to translate DevOps theory into practice, create buy-in for DevOps, assess and improve teams’ collaboration and communication skills, and capture concrete end-to-end actions to take away and apply.
In three game rounds the team learned to apply the three ways of DevOps and apply continual learning and improvement skills – a core capability for IT organisations, yet one that is poorly adopted and embedded in the way teams work and the way that WIP (Work In Progress) limits are filled with features, issues, defects and technical debt.
As usual the first two rounds are characterised by chaos as teams learn to ‘form, storm and normalise’ the way they work as a team. Chaos ensues as teams shift from a siloed approach to an end-to-end collaborative process and more chaos as teams struggle to translate theory into sustainable behaviours.
At the end of the day we reviewed the team scores: how applying continual learning and improving and DevOps practices had continually improved DevOps metrics (the number and volume of successful deployments, reduction in outages and rework) as well as business value metrics (revenue, share price, customer loyalty…)
We then explored ‘what we need to take away and start applying tomorrow’. Take a look below and see if any of these takeaways NEED to be applied as part of YOUR DevOps journey!
- Start talking ‘BizDevOps’ to shift mindsets and focus on value.
- Go out and understand ‘business value needs’ and see how this flows from idea to value through our value chains.
- Start using ‘STOP’ as a feedback and improvement mechanism, whenever a defect (product or behavioural) is passed downstream.
- Start practising ‘active listening’ and stimulate a shared discipline in the way we communicate and respect each person’s input and what they have to contribute.
- Measure the reduction in ‘yes buts’.
- Start trying to create some end-to-end visualisation of flow – not just flow within silos.
- Develop a priority mechanism linked to value, business impact and risk. First we need to understand this from a business perspective.
- Start building a better business-IT relationship, looking at our BRM (Business Relationship Management) capability.
- Start fostering a ‘one team’ culture: one business and IT team, one-team thinking between Dev and Ops, as we are all striving for the same shared goals. We need to learn to collaborate!
- Understand constraints: how to remove them and ensure that they are working on the right priorities.
- Experiment with new ways of working, reviewing, improving – what works for this team? If need be provide coaching for teams, as different teams mature at different speeds.
- Understand what drives business needs – what keeps them awake at night?
- Focus on removing ‘Yes but’.
- Show the value of training.
- Look for small iterative improvements.
- Create trust: stick to agreements, explain in business terms, feedback culture, no blame, show that you listen and understand.
Many of these takeaways are ‘common sense’ or ‘things we already knew’ but as is often the case too little time is reserved to embed these good ideas into sustainable end-to-end behaviours.
Having taken on the role of CEO for the day, it was so refreshing when the team stopped talking about code, applications, servers, fast deployment, release velocity, release frequency and mean time to recover and started talking about revenue, share price, CSAT, image, reputation, growth and customer loyalty.
What language do YOU use when you talk DevOps to YOUR business?
What metrics show the BUSINESS value of DevOps?