itSMF Slovakia organized their 11th annual conference. The theme being ‘007 – ITSM never dies’.
An interesting analogy that reflected the content of the event. ITSM is not dead! It is evolving and maturing. The focus has shifted from ITIL® to include new practices such as Lean, DevOps, BRM and IT4IT.
GamingWorks was asked to conduct DevOps workshop using The Phoenix Project business simulation game. My 007 theme was ‘Never say never again’. DevOps!? You cannot ignore it and say ‘Never’ – as a Wall street journal article declared ‘Enterprises are not ready for DevOps but will not survive without it’.
Many DevOps initiatives will fail unless…..
However adopting DevOps means embarking upon an organizational transformation for many. As Gartner stated “Cultural resistance will create significant failure rates when starting with DevOps”, and an article on CIO.com revealed “Organizational change issues are far more challenging” than the technology adoption for DevOps.
The simulation workshop was to allow delegates to experience what DevOps is and what it may mean to their organization. At the same time explore some DevOps tools & practices and the challenges organizations may face when adopting DevOps.
DevOps in action – The Phoenix project simulation
The Phoenix Project business simulation is a dynamic, classroom based, business game based focused on ‘learning-by-doing’ or ‘experiential learning’. A team of players are assigned roles and responsibilities and placed in a realistic environment in which they must effectively communicate and collaborate and apply DevOps best practices in order to succeed.
In this workshop we ran a simulation of one business project ‘flowing’ from ‘idea’ to ‘delivery’. As we walked through this scenario I suggested that the team capture ‘CSI’ (Continual Service Improvement) items as they occurred.
I asked who is responsible for this?
‘The IT manager’ was the answer.
I said ‘No. A key concept of DevOps is continual learning and improvement’ and quoted to them Mike Orzan ‘Even more important than daily work is the improvement of work’. I suggested it was everybody’s job to identify areas for improvement as they experienced them. This is the first of many ‘attitude, behavior and cultural’ changes required to make DevOps work. As the ‘State of Devops 2016 survey’ concluded:
“Improving quality is everyone’s job. High-performing organizations spend 22 percent less time on unplanned work and rework. As a result, they are able to spend 29 percent more time on new work, such as new features or code.…The DevOps mantra of continuous improvement is both exciting and real, pushing companies to be their best, and leaving behind those who do not improve”.
These were the items the team captured as we simulated the project moving through Dev & Ops, Items that many also recognized in their daily work:
Communicating & Collaborating to make improvements
The team then explored the three ways of DevOps, and agreed some improvements before the next simulated project.
BUS-Dev-Ops!
A question that arose when making the Visual Management System was ‘When is work done’?
We looked at Typical measures used for DevOps performance, these being: ‘Deployment frequency’, Lead time for changes’, ‘Mean time to recover (MTTR)’and ‘Change failure rate.
Does this mean that work is ‘Done’ when it has been ‘successfully deployed without errors’. Half of the team agreed with this, the other half said work is done when it ‘delivers the expected outcomes’. I personally agree with the latter. Which is why we prefer the term BusDevOps. Why is this?
CNBC published results of a survey stating that ‘70% of everything spent on IT doesn’t meet the functional goals – that means that up to $394 billion – a staggering number – is now being spent on efforts that deliver insufficient ROI’!……The 2016 Standish report figures reveal that only 29% of software projects were successful, stating significant reasons for failure were related to ‘Executive sponsorship’ , ‘Emotional maturity’ and ‘User involvement’. This to me sounds like a significant enough reason to want business at the front and end of the delivery pipeline and at the end to measure that that ROI IS being realized….
Otherwise there is a risk that DevOps will simply mean ‘a much faster, error free ability for 70% of IT spend to deliver insufficient ROI’.
Including the Measurement of business outcomes helps provide a feedback loop to continually learn and improve how business cases are made for software development and how effective the organization is on realizing the benefits.
What were the key learning points and take-aways?
At the end of the day we reflected on key learning points and take-aways: