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:
- Unclear how work enters the system (one business unit went straight to the lead engineer to get work done, one went to the application team, another went to VP operations. All accepting the work and saying it would be done.
- Unclear how work moves through the system. Work was ‘ping-ponging’ between roles and teams causing delays, wasting time.
- Recognized need to remove waste – too many hand-offs and work passing back upstream.
- Need to prioritize work across the business units.
- No relationship between all the activities taking place and the projects or work in the system.
- Unclear how much work was in the system.
- Too many assumptions. Need to improve communication.
- Business needs to be involved at the beginning and at the end. Bus-Dev-Ops-Bus.
Communicating & Collaborating to make improvements
The team then explored the three ways of DevOps, and agreed some improvements before the next simulated project.
- They built a Visual Management System using sticky tape and post-its to specifically address the issues they face: Insight into all the work, including the backlog of work; insight into the priority of work; insight into the end-to-end flow of work; insight into work at each person, including WIP (Work-in-progress) limits; insight into dependencies; insight into progress of work flowing from left to right.
- The team documented the flow of value adding activities versus non-value adding activities.
- The team organized a stand-up around the board to ensure understanding and agreement and to prevent ‘assumptions’.
- The team used the board to enter into a dialogue with the CEO about strategic priorities in relation to ‘Value’, ‘Outcomes’, ‘Costs’, ‘Risks’ – gaining more business intelligence about business drivers and strategic choices.
- The team mapped the work to be done against these ‘strategic choices’.
- The team recognized that the flip-over containing ‘improvement actions relating to the DevOps practices’ was also part of their Visual Management System.
- A final improvement action was suggested: “Use the sticky tape we used to make the Kanban board to tape up the mouth of the CEO” declared the team as I, playing CEO applied a priority mechanism based on ‘who shouts the loudest gets the priority’, rather than on agreed strategic initiatives.
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:
- Communication end-to-end about priority, and asking ‘what do you need from to get your work done’. ‘Asking when you don’t know or need help’, ‘confirming agreements and expectations and avoiding assumptions’, ‘Giving and receiving feedback’.
- Clear decision making around priorities, taking ‘ownership’ for collaboration and cooperation.
- Understanding the ‘Big Picture’ – the complete system and the ‘Why’ question. The Business must communicate the ‘Why’.
- No ‘Silos’. Think and act outside of borders ‘Dev’ and ‘Ops’ and ‘Business’. The end to end ‘Chain’ is as strong as the weakest link or where the constraints are; Avoid making localized improvements, focus on a global approach (end-to-end) problem solving of the ‘flow of work’.
- Shift from ‘Blame’ culture to ‘Trust’ culture. Focus on the right behaviors to create Trust ‘Do the right things’, ‘do things right’, ’demonstrate ability and admit learning needs’, ‘ownership for understanding the why and giving feedback’, ‘contributing to improving work’, ‘No more blame but exploring together how to avoid waste and mistakes’
- Set and agree expectations – avoid ‘assumptions’.
- The importance of making a Visual Management System together to support information and decision making needs.
- Continual learning and improvements with everybody taking ‘ownership’ for improvements.
- Senior managers must understanding it is about Bus-Dev-Ops and must be committed to the leadership and cultural changes required – helping to foster a ‘no blame’, ‘open’ culture.