DevOps simulation game: It’s a People thing!

Published on Tuesday 15 March 2016 by in Blog with 2 comments

GamingWorks applied DevOps principles to develop our latest DevOps game – that is building direct feedback loops into the game design and experimenting and improving.

We played a PILOT with Sogeti, one of our strategic partners, and their experts to gain some feedback for improvement….see their discoveries at the end of this article!

Why a DevOps game? Many organizations are leaping onto the band-wagon. Business demands for agility and time to market new IT solutions are driving the need. It is no longer a question of ‘What is DevOps’?, or ‘Should we be investing in DevOps’? The questions organizations should now be asking are:  ‘How should we deploy DevOps’? ‘What does it mean for our organization’? DevOps is still an emerging capability, best practices are being developed by…..well…practicing.  Which is what our game is designed to do, translate theory into practice, and allow teams to experiment, explore and capture shared insights.

As Dave van Herpen of Sogeti explains ‘This game is an excellent starting point for all organizations with a desire to explore the do’s and don’ts of working in a DevOps way. It can also accelerate the adoption by all layers in the organization, including the teams and senior leadership. A “must do” in every DevOps journey’!

Crudely put DevOps puts a strong emphasis on getting software into production as fast as possible without the barriers and delays typically imposed by operations. Operations organizations are still concerned that DevOps is a license for developers to display a Cowboy mentality of throwing things over the wall…..only faster than before!

Gene Kim, co-author of the Phoenix project book, describes DevOps: ‘The term ‘DevOps’ typically refers to the emerging professional movement that advocates a collaborative working relationhip between Development and IT Operations, resulting in the fast flow of planned work (i.e. high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment

However as Jan pointed out in the game in his role as CEO ‘from my point It should really be seen as BusDevOps. Getting from idea to production as fast as needed preferably without placing unwanted risk on the organization. Show me how you will now ‘effectively collaborate to make this happen!’

screeshot

 

 

 

 

 

 

 

At the start of the game the CEO shows the current situation and insists on increased sales and share value!

Our DevOps business simulation is called The Phoenix project and is based upon the book with the same name. The game can be used to bring end-to-end delegates together to learn:

  • The essence of DevOps
  • Understand the cultural and behavioral aspects of adopting and deploying DevOps practices
  • Discover how DevOps can help your teams become more effective and efficient

In the simulation delegate play the roles of the ‘Parts Unlimited’ organization. At the start of the game financial performance is poor, the share price is low. They are getting beaten by their competitors. Survival is at Stake! The business initiates an ambitious IT enabled turn around program – ‘The Phoenix project’ – however the current IT capabilities also present a significant business risk.

In the simulation Jan played the CEO and immediately put the business directors and VP IT operations under pressure to perform.

At the start of the game the business directors launched some new business projects that needed to be executed.  The team planned the workload and was suddenly confronted by the HR director insisting upon a Tax related upgrade, 2 incidents occurred, one relating to a critical payroll systems outage….so much for planning! At the end of the game round the teams made a number of important discoveries:

  • The need for insight and an overview of the workload – a visible management system was suggested.
  • People were operating in SILOS – there was no overview of the value chain and how the end-to-end system operated from business demand to deployment.
  • Capacity was underutilized….
  • Unclear priorities meant delays in decision making and the wrong work getting done
  • Unclear business or ‘product owner’ role
  • Poor insight into the ‘backlog’ of work in progress
  • No lead or ownership for the end-to-end alignment

After the critical reflection it was time to improve….. Want to know what happens next?

Play the game!

gameplay

 

 

 

 

 

The frustrated business unit manager…..visible workload management

 

 

 

Share this article

2 comments

Leave a Reply

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