How to make DevOps a critical enabler in the era of Digital Transformation
ATOS in Slovakia held their 2017 ‘Technology Forum’ in Jasná j, a Ski resort nestled amongst the snow laden Tatry mountains. The Forum kicked off looking at how digital solutions are transforming the way work is being done. The first case was an example of using Virtual Reality for Industrial training. A safe way to prepare people for working with dangerous machinery or in dangerous environments.
The second case was an example of using DNA and genome crunching software to develop personalized medical care. Powerful images of small children and babies attached to medical equipment and whose lives have been saved brings home to you the power of software and the responsibilities this places on IT professionals.
The pace and speed of technology developments is matched by the business demand for speed of adoption and deployment.
Ivo Kovačič, Head of Technology in Business & Platform Solutions finished off the plenary sessions looking at the Myths and Realities of DevOps and relating these to the worries of CEO’s facing Digital transformation. On the one side they are looking for a ‘faster time to market’ and realization of value. On the other side they are looking for ‘Safe, Secure, and Reliable’ solutions that don’t threaten or damage the business. This places a strain on IT developers and IT operations, one side looking for speed, the other looking to protect.
This is a balance that can only be realized with effective Governance, which means that the business must play a critical role in DevOps, shifting the emphasis to BizDevOps.
The promise of DevOps, if fulfilled, represents a critical business capability in getting new business solutions to market. But to dispel one popular myth, DevOps isn’t all about automation and continuous deployment. As stated in Forrester research findings “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organization. As any leader knows, changing institutionalized behavior is the toughest of all management challenges and CIOs are understandably skeptical of new trends.
Despite this, CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative, and CIOs must engender a culture of collaboration and learning and enable their people with the right tools”
DevOps in action – The Phoenix project simulation
Continuing on from DevOps keynote, GamingWorks together with Ivo Kovačič conducted a Phoenix Project DevOps simulation workshop. The goals of the workshop were to explore how a simulation game can support CIO’s in fostering a culture of collaboration, and at the same time support teams in learning to apply DevOps practices – translating theory into PRACTICE.
The Phoenix Project business simulation is a dynamic, classroom based, business game based upon the book ‘The Phoenix Project’. The simulation is based upon ‘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.
“……We are in the financial pages again!” explained the CEO in the simulation. “Website plagued by outages and supplier data issues. This will impact share price and may damage revenue growth. Did you know this?” Questioned the CEO to the Retail Director and VP Ops….both were unaware.
That is what happened in the first game round. The business directors were happy, both of their new ‘business features’ were deployed, but there were insufficient resources assigned to the ‘issues’ or ‘technical debt’!
The team performed a retrospective on what had happened, using the 3 ways of DevOps to explore:
- The business had too little insight into the status of their projects and had no visibility of the issues impacting customers and suppliers.
- VP Ops had no insight into what people were working on, nor how these activities related to business initiatives.
- Although the team recognized a skills constraint, training was bumped for short term business features. This would impact the delivery of the future portfolio of critical features.
- The tester was unaware of what needed testing, testing was incomplete.
- Security had no insight into the issues relating to potential customer and supplier data leaks
- The teams of specialists had no priority mechanism. They did not know the link between the workload and business value, but were blamed when work wasn’t done.
- Application Development was continually waiting for feedback and for ops to get systems ready. Ops were involved too late or some areas of expertise not at all.
- There was no smooth flow of work, there was a lot of ping-ponging, waiting for information and continually going back up stream to ask questions.
- Mistakes were made and unnecessary work done which would require rework.
The team all agreed this represents reality for many in their working environments, with the increasing dependency on IT and the increasing growth in demand for digital this is unacceptable.
The team experimented with DevOps principles and practices. They built a visual management system to address the issues they had experienced and agreed the flow of work.
They agreed to experiment with single piece flow and would time it. They would look for ‘waiting’ times caused by confusion of responsibilities, waiting for the right information, waiting for notification, waiting for corrections. They also started applying the following behaviors:
- When anybody saw that the flow was stopping they called ‘stop’ and the team swarmed to try and resolve the problem.
- They applied small iterative improvements to the ‘information content and flow’, and the visual management board.
- They used WIP (Work-In-Progress) and WIP limits, reserving time for training.
- The Tester was involved up front and would communicate needs and status.
- The team had identified the information and the product that needed to flow through development, change, technology operations, IT support and the business. They had also identified where testing needed to be done throughout, rather than at the end.
Once the team had started achieving a smooth flow and the ability to reflect and improve end-to-end working they realized that NOW they would be able to look at tools. Tools to support and enable the flow of ‘code to production’, and to facilitate the flow of information that was needed to enable decision making. They were also able to pinpoint areas where testing should be integrated and automated.
The team reflected on this discovery about the tools. ‘Could they have been able to select a suite of end to end tools and have them integrated and aligned if they had not first learnt to map the flow and start performing continual learning and iterative improvements?’
‘It would probably have been chaos and we would all have been pointing blame at each other’ said one delegate.
A Fool with a Tool is still a Fool!
Yet this is what many organizations do. They want to ‘Do DevOps’ so they invest in various tool suites used by different teams and then realize they have not yet learnt to effectively communicate and collaborate. Tools are without doubt a crucial, critical enabler to realize the full potential of DevOps, but only as part of an integrated approach to ‘People, Process and Technology’.
Key actionable takeaways
At the end of session delegates were asked ‘What will you now take-away and try to apply in your organization?’
- Map the flow (Value Stream) together (end-to-end) and identify waiting, bottlenecks, disruptions and defects.
- Experiment with single piece flow.
- Agree priority mechanisms with business & IT to balance new features with risk (removing technical debt – IT must show impact in business terms).
- Start working with WIP (Work in progress) and WIP limits – this needs to be aligned with the priority agreements.
- Get together end-to-end and explore making a visual management system, couple this with the value stream mapping of flow.
- Testing needs to be actively engaged up front and should work with all teams to define and agree testing and where possible automate testing.
- 1:3, 3:1. Build multi-functional capabilities to reduce constraints of scarce skills (1 person should be able to do 3 different team tasks, 3 people in a team should be able to do the same task).
- Practice effective communication, asking people upstream and downstream ‘what do you need from me’, giving feedback, daring to ask for help.
- Take ownership for the flow and improving the flow.
- Optimize process, measure results and make continuous small improvements.
DevOps – Not a framework, an ‘evolving journey’.
It is interesting to observe that DevOps means different things to different individuals, teams and organizations which makes it a difficult concept to adopt for organizations wanting to ‘implement the latest best practice’. DevOps is more a journey taken together with the whole organization.
One delegate said his key take-away was ‚….visualizing somehow, with business, value realized…to help continually learn & improve business cases ‚. …another said „We can start using this immediately without having to do #DevOps„(His pre-conception was ‚continual delivery‘ and ‚automation of everything‘) his take away experience in the simulation was ‚continual learning, experimenting & improving together with end-to-end stakeholders‚.
Ivo, in his keynote had mentioned the State of DevOps reports, it seems appropriate looking at the last 2 takeaways to end this article with a finding from one of the reports:
“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”.