EXIN DevOps Knowledge Day

Published on Friday 9 September 2016 by in News with 1 comment

exindevops

EXIN organized a series of DevOps knowledge days in Utrecht, Prague and Paris. The sessions were to launch the new EXIN DevOps Master exam. This is the latest addition in the industry wide portfolio of DevOps certification and is focused at a more advanced and practical level than current offerings in the market. Currently both DevOps Institute and DASA (DevOps Agile Skills Association) offer DevOps foundation and fundamentals respectively, covering primarily Bloom’s level 1 & 2. DASA has a roadmap that will eventually include the development of practitioner and experts modules. The EXIN Master exam is focused more at blooms level 3 and 4 ‘Application’ and ‘Analysis’.

Rita Pilon – Program Manager EXIN, explained that one of the benefits of getting the Master certificate was ‘to become an enabler for DevOps’ , going on to add that the exam is more about SKILLS and Knowledge with more ‘Practical assignments’, as opposed to theoretical understanding. This fits with the defined need described by Adam Bertram, InfoWorld ‘DevOps cannot be obtained overnight with a simple check and a little training. It is a transformational approach to core processes and it takes time, dedication and especially a team that can implement DevOps practice.”

Industry experts, including Koichiro Toda – Director of Toyota Production Systems (TPS) Certificate Institution have been involved in the development of the EXIN program. In a Video presentation Koichiro Toda explained the value of the EXIN DevOps Master program and its development,

Key messages from my perspective:

  • There is no clear definition of DevOps. It is still ‘fluid’ today.
  • It is all about Business Agility and Business Continuity.
  • Involve DevOps team in the Business Planning.
  • ITIL is useful. But ITSM needs to be less bureaucratic and must support Business Continuity.
  • Change the behavior of people.

The DevOps master body of knowledge has 4 key domains:

  • Disciplined Agile
  • Continuous Delivery
  • Light weight ITSM
  • TPS (Toyota Production System) concept (Lean)

Michael Schmidt from Automic also presented an Introduction to DevOps.
From my perspective, key points that he raised were:

  • DevOps is based on People, rather than processes and tooling.
  • There is no single kind of DevOps organization. It is an evolving practice.
  • Collaboration and working together is a pre-requisite
  • Key metrics often quoted in relation to DevOps are: ‘Release velocity’, MTTR (Mean-Time-To-Repair) and ‘Time required to approve and implement a change into production’.
  • Standish report stated one of the main causes for IT project failure is ‘51% Poor understanding of business needs’, and Stern stated ‘64% of features are not, or little used’.

At the Paris event Alex Lichtenberger from Glenfis presented ‘DevOps in Practice’.

Key messages from my perspective:

  • Dev and Ops – completely different ‘Universes’.
  • Don’t try and answer the question ‘What is DevOps’ – first seek to understand ‘Why DevOps?’ and answer the question ‘Why could DevOps be relevant to me?’ for all stakeholders.
  • DevOps is a Journey. To get there we need to ask ‘How can we increase flow – day by day’?
  • Continual learning and experimentation are required – this requires trust and a ‘no blame’ culture in which ‘failure is allowed’.
  • Embedding improvement KATA into the habits and culture ‘Where are we today, where do we need to be, how can we get there’?

GamingWork presented the Phoenix Project business simulation game. However first they set the scene for the NEED for a simulation game. All presenters referred to Gartner’s statement that in 2016 ‘DevOps will be mainstream’, however they failed to mention that the article went on to add ‘Cultural resistance ….will create significant failure rates for DevOps initiatives’. A CIO.COM article also stated ‘Organizational Change Issues are far more challenging (than technology)’. Should we worry? The Wall Street journal in an article declared ‘Enterprises are not ready for DevOps, but may not survive without it’.

The Phoenix Project business simulation game is both a learning, and an organizational change instrument. Helping to translate theory into practice, and to bring Business, Dev and Ops teams together to learn key skills in ‘communication’ and ‘collaboration’.The simulation game supports the EXIN Master program by providing scenarios for ‘practical assignments’, and helps create a buy-in and understanding for DevOps.

The simulation game is played in a number of game rounds which provides delegates multiple opportunities for the team to experiment with continual learning and improvement – practicing how to do Kaizan themselves. This ability to reflect and improve is a CORE CAPABILITY required for DevOps, especially as there is no rigid definition or guidelines, and the fact that it is a long journey.
As far as GamingWorks is concerned it should be called BusDevOps. Why? When taken in the context of the Standish and Stern findings above, If we do not also help change the Culture and behavior within the business when deploying DevOps we face the following risk:

“rapidly approve and deploy – poorly understood business needs and little used features……but at least we will have a faster mean time to then repair things”.  


devops-measures

 

 

 

 

 

 

 

 

We revealed how in the simulation we focus not just on the ‘internal metrics’ but also the associated ‘business value metrics’, represented by ‘Revenue growth’ and ‘Share price’.

We walked through a scenario in the Phoenix project simulation game.

….There were piles of work at each of the roles within the game. Representing business projects in progress as well as issues teams were working on. The Retail director introduced a new project for a new WEB PAYMENT system.

Application Development had capacity to develop the Application. Change management was a bottleneck as all changes had to go through the CAB. Application development and the business insisted change management drop some changes ‘Which one I asked’? I held up a POS SERVER CONFIG update. ‘What about this change’? does anybody know how this relates to ongoing projects’? ….there was silence.
IT support suddenly erupted at the back of the room ‘who stopped my change I am dealing with a payroll outage which is losing us money’? ‘Nobody told me about any outage’? said one of the team. None of the DevOps team had been informed by the business what ‘outcomes’ needed to be realized by deploying the projects. As a result work was delayed, needed work was not performed, a half finished deployment necessitated more unplanned work.

The Lead engineer became a bottleneck, already filled with work she was asked to update the firewall by IT Support, without knowing which project this related to, nor its relevance – this was also put off till the next period. Another missed business value opportunity.

Key learning: The team was faced with a need for insight. Which DevOps principle or practice can we apply? – a Visual Management System was decided. Which ‘work’ do we have in the system? Which ‘Projects’ and which ‘Issues’ are we currently working on, or do we have in the pipeline?

devops-kanban

 

 

 

 

 

 

 

 

 

The next learning point: The Visual management board should also be used to gain insight into the value stream or flow – ‘Who is working on, or needs to work on all this work in the system’? After the visualization it soon became clear that choices needed to be made to limit the work in progress. There were constraints and bottlenecks. The business needed to be involved The next learning point: ‘The Voice of the Customer’. The visualization needed to show the business priorities of the work in the system. This enabled ‘rapid decision making’ to prioritize the work to be pulled through the system, focusing on the projects delivering the most business outcomes (business agility), and the issues which most negatively impacted business value (business continuity).

Conclusion: DevOps is becoming a critical ‘capability’ – new skills and ways of working are required. A critical success factor is ‘people’ and managing the cultural and organizational change required. Foundation level training is a first step, however more ‘practical’ skills are required. EXIN Master clearly addresses some critical skills required in DevOps initiatives are to be successful. The business simulation game helped people translate the Foundation or Fundamental level theory into practice and provides an environment for practical assignments and for continual learning and improvement, as part of the Master program.

As one delegate who had followed a DASA fundamentals stated: “doing the game after the training adds real value. After lots of theory, exercises and discussions, the real message and value of DevOps really sinks in during the game. Most valuable!”

The simulation also helps organizations with the culture change, bringing Dev and Ops together to learn to effectively communicate and collaborate, as one customer stated: “It felt like being at work. All these things happening within the game are the same things going on in our organization…. Doing this together with your team to experiment with Lean/Agile/DevOps principles in a practical way is very effective”.

The simulation also helped change the business attitude. As one business manager stated after participating in the game: “Acting as Retail Operations in this simulation (Business role), I learned a lot about DevOps. I now see how Kanban is used, and what my role as the business should be. Very useful”.

Share this article

1 comment

Great post, most informative, didn’t realise devops were into this.

Leave a Reply

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