Paul Wilkinson reports on one of the most popular interactive elements of conference.

The theme of ITSM16, the itSMF UK conference, was ‘Professionalism in ITSM’. One of the streams, ‘People make ITSM’, focused on the human elements that make ITSM successful – such as communications, leadership and people development.

Barclay Rae in his opening speech discussed the Professional Service Management Framework (PSMF), a competency model announced earlier this year for ITSM professionals. Barclay explained that ‘soft skills’ are becoming increasingly important for IT professionals. Two of the six competence areas in the framework, ‘Self-management & leadership skills’ and ‘Interpersonal/relationship skills’, clearly focus on these softer skills.

To support this focus on people and developing new competences, Jan Schilt from GamingWorks and John McDermott from HPE facilitated a ‘taster’ session of the Phoenix Project DevOps business simulation game. The simulation game is a form of ‘experiential learning’ helping delegates translate theory into practice.

The goals of the simulation session were to:

  • Explore and experience the essence of DevOps.
  • Understand the culture and behavioural aspects of working in a DevOps environment.
  • Discover how DevOps could help your teams to become more efficient and effective.
  • Experience how to ‘implement’ DevOps principles in your own organisation.
  • Explore key success factors for DevOps adoption and deployment.

Jan introduced the simulation and stepped immediately into his role of CEO of Parts Unlimited, an organisation specially devised for the simulation. Showing the delegates a press release from the morning papers, he declared, ‘Parts Unlimited’s share price is falling and there is bad publicity around the company. IT must transform its capabilities if we are to survive…” He then welcomed ‘Bill’, the delegate playing the role of VP of IT Operations (VPO). The VPO looked like a rabbit caught in the headlights.

“….and Sarah, from Retail Ops,” he continued, “will ensure that the Phoenix Project will realise the necessary business growth and profitability.”

The team played round 1. It soon became clear that things were not going well. The business was getting frustrated, so too was IT. Not all the work was being performed… mistakes were being made, requiring rework. Roles and responsibilities were unclear. At the end of the round the team reflected:

  • The business was confused. There was no clear overview of the status of their projects, or how work was being prioritised.
  • The process was unclear for the tester, who was involved too late.
  • The lead engineer spent 60% of their time doing ‘things’, with an unclear relationship to business projects.
  • The team had started with ‘visualising’ their work – however not all work was captured and there was no relationship to the business outcomes to be realised.
  • People were ‘running around’ – the process was unclear, and this led to wastage, delays and rework.
  • Work stopped ‘flowing’; nobody called ‘stop’ to find out why and where the bottleneck was.

The teams then explored some critical success factors for DevOps and applied some of the DevOps principles. Round 2 seemed much smoother. The reflection at the end of the next game round revealed:

  • There was clear visibility of all work, the flow of work through the system, and where work was being blocked or held up.
  • The tester had more clarity and delegated testing throughout the chain, preventing mistakes being passed downstream.
  • There was visualisation of the right information which helped with decision making.
  • The team had gone from ‘headless chicken’ to ‘retrospective’ and ‘experimentation’ – exploring how bottlenecks could be removed and end-to-end working improved.
  • The team recognised the need for somebody to take responsibility for facilitating the stand-up.
  • The team recognised the need for everybody to use the ‘Andon’ system and call ‘stop’ and then to ‘swarm’ to solve issues – preventing hold-ups and delays and identifying improvements.
  • In a squad or team EVERYBODY should be able to stay ‘stop’ when detecting quality issues or experiencing a barrier to smooth flow.
  • If you don’t know the answer, ask for help.

How did the team manage to create such a turn-around? The simulation is played in a number of game rounds; between rounds the team learns to run their own ‘restrospective’ – focused on continual learning and improvement. This is a critical capability.

State of DevOps finding: Improving quality is everyone’s job. High-performing organisations spend 22 per cent less time on unplanned work and rework. As a result, they are able to spend 29 per cent 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’.

Finally at the end of this intensive 1.5 hour session people were asked ‘What was the VALUE of the experience’? The conclusions:

  • Being ‘passive’ doesn’t help – need for everybody to take ownership and be pro-active.
  • Need for team working – ‘collaboration’ as opposed to ‘co-operation’. As John McDermott explained, “Co-operation is people working together, each with their own silo’d goals; collaboration is people working together collectively towards shared goals”.
  • Communication – giving feedback, sharing information, asking what others ‘need’ to do their work.
  • Transparency within the squad – which leads to improved collaboration.
  • Trust. The exercise helped create trust in the team, through collaboration and communication and working toward agreed, shared goals with the business.
  • Understanding different perspectives, which helped create a shared vision.
  • Being able to see the ‘big picture’ in one room with all the stakeholders.
  • Value of the ‘stand-up’ – using the ‘Andon’ principle. There was no ‘micro-management’; the team was ‘empowered’.
  • Transparency and honesty – daring to say “I don’t understand the new way of working” and asking for help. This represents a significant culture change. Trust is critical and a culture of open, honest feedback.
  • Stand-up – asking which blockers and barriers are stopping you.
  • The IT support role felt more engaged and empowered through seeing the projects and the impact.

As the State of DevOps finding revealed: ‘Employee engagement is not just a feel-good metric — it drives business outcomes’. The report revealed that companies with highly engaged workers more than doubled revenue growth compared to those with low engagement levels, as well as impacting share value.

State of DevOps finding (Lean product management): ‘When employees see the connection between the work they do and its positive impact on customers, they identify more strongly with the company’s purpose, which leads to better IT and organisational performance’.

Director & Owner at | Website

Paul has been involved in the IT industry for more than 25 years and has a broad background in IT operations, IT management and product innovation and development. He was project team lead in the original BITE (Business & IT Excellence) process modeling of ITIL, an ITIL V2 author and member of the ITIL V3 advisory group. He is co-owner of GamingWorks and co-developer of a range of business simulations focusing on IT Service management, Project management, Business Process management, Business and IT alignment, Alliance management and co-author and developer of the ABC of ICT products and publications.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top