“Courage” seemed to be a common theme at the Conlea ‘DevOps Knowledge Day’ event co-sponsored by the DevOps Agile Skills Association (DASA). Courage to deal with suspicious boards (doubt, having heard all the ‘best practice’ promises before), courage to deal with managers (fear of the change to span of control and new leadership styles) and courage to deal with teams and individuals (uncertainty about what it will mean to them, and resistance to new ways of working).
‘Fear, Uncertainty and doubt’ seem to characterize many organizations embarking upon Agile and DevOps ways of working, requiring organizational change management skills to ensure a successful adoption.
These were some of the topics covered by the speakers at the Knowledge day. Below are some of the key findings from the sessions I attended.
Tomasz Pajak, our newest DASA Ambassador, in his session ‘DevOps Transformation Starts with You’ prescribed how leadership style is shifting from ‘command and control’ to one of ‘delegation and transformation.’ These transformational skills can make or break in order to make organizations ‘Fit-for-the-Future’, yet many leadership teams do not have them! A crucial reason why DASA is developing a new Leadership certification track.
Waldemar Sadkowski in his session ‘Beyond the Tools and Processes’ suggested holding a ‘Scrum’ with business and IT to identify and prioritize a backlog of pain points in order to gain trust with the doubting business. Waldemar also stressed that ‘leadership’ isn’t just for managers, look for ‘influencers’ with peer groups respected to help champion the change. He presented some interesting learning points from Sun Tsu, the author of the Art of War. “If words of command are not clear and distinct if orders are not thoroughly understood then the general is to blame…”…but if orders are clear and soldiers disobey it is the fault of the officers.” Clear responsibilities here for management to set the vision, answer the ‘why’ question and manage organizational behavior change.
Sam Rosbergen is his session ‘DevOps Culture and Operational Responsibilities’ took it even further than managers and influencers, suggesting that ‘DevOps culture starts with everyone,’ however, leaders must create a safe, blame-free culture so that people can experiment with new ways of working. He also suggested that managers will need to do ‘Gemba’ walks – talk to people, sees and understand issues and conflicts and help remove impediments. Not only is it about ‘Minimum Viable product’ for code, but leaders need to adopt an approach of ‘minimum viable people, process and tooling’ for their transformation – an iterative approach to growing maturity over time and to fit a team’s ability to change.
In my opening presentation: ‘DevOps will fail…Unless’ I revealed findings from more than 400 teams who have taken part in the Phoenix Project simulation and gave three critical success factors.
- A Shift from DevOps thinking to BizDevOps, or more importantly, a shift from ‘code to deploy’ to ‘idea to value’ requiring an increased engagement with the business and a changing role of the Product Owner.
- Define, agree, foster and enable ‘desirable behaviors for ‘communication‘ and ‘collaboration‘, and
- Ensure that ‘continual learning & improvement’ is a core capability with time reserved for improving, from Day 1 of your DevOps journey.
Another key theme from speakers was that there is no ‘one size fits all’. DevOps is not a framework like ITIL. You need to answer the questions ‘Is DevOps right for our organization? Why? What do we need to achieve with it’? Then scope what this will mean. Otherwise ‘If you don’t know where you are going then any road will get you there’!
The Phoenix Project Simulation
Tomasz Pajak and I conducted two ‘Walkthrough’ sessions of ‘The Phoenix Project’ simulation to identify challenges and pain points delegates currently experience, and to explore how DevOps principles and practices, such as the 3 ways of DevOps, can help address these pain points.
During the ‘Walk-through’ of a business project through the end-to-end organization, this was where the pain points were discovered. The team then confirmed that these are pain points they recognized in their own organizations:
- No view of how work flows through the system. There is a ‘Ping-ponging’ of information back and forward causing disruptions and wasted time and effort as well as creating frustration.
- No visibility of work in progress (business projects, It projects, issues or changes) nor who is working on what.
- Business does not share strategic goals or priorities. Business assumes IT ‘should know’. No checking of assumptions from either Business or IT.
- IT does not know or ask for strategic goals or priorities.
- Change calendar – a weak link between changes and business projects.
- Unclear escalation mechanism on resource conflicts and no clear prioritization mechanisms linked to business impact or value.
- Business poorly notified of decisions to drop work – as there was no link between work planned and the business projects.
- Testers had no insight into what’s changed, or not done, and not even involved until the end.
- Continual disruption from multiple stakeholders asking for status and insights and trying to find out who had changed things (or not) when tests failed.
- CISO had no insight into what had been changed or left undone.
- Hiding behind RFC’s and bureaucracy to do work.
- No relationship between CISO and testing.
- No project manager to ‘force’ people to work!
- No stand-up meeting with end-to-end stakeholders to discuss status or agree on end-to-end responsibilities.
- ‘Unconsciously incompetent’ business and IT.
- Business did not ensure business readiness (Training) for deployed solutions.
- Lack of testing did not pick up on mistakes and work deliberately left undone
- Unclear what kept business awake $, share price, image, and reputation, customer satisfaction, as such difficult deciding priorities.
The team then explored the (3) ways of DevOps and designed a visual management board to address many of the challenges above. How to gain visibility into the strategic portfolio as well as the immediate backlog of business work, insight into priorities, insight into the different types of work (projects, features, debts, defects, risks), insight into WIP limits, insight into who is working on what, insight into the status and progress of work.
A key discovery and success factor was seen as designing the board together with the end-to-end stakeholders. This fostered effective communication and collaboration.
At the end of the mini ‘walk-through’, we asked the team ‘what is your key learning points? What will you now take away and try to apply in your own organization’?
- Create transparency. ‘Visibility’ into work and who does what, end-to-end. Show wait times.
- Improve business understanding. ‘What keeps business awake at night’? Key goals, portfolio planning. What is coming down the pipeline? Also the business impact of defects and debt.
- Foster knowledge sharing and the concept of 1:3 (1 person should be able to perform 3 team tasks) 3:1 (3 people in a team should be able to perform a specific team task).
- Improve priority mechanisms (projects, changes, defects, debt) together with the business, related to impact on business value.
- Improve communication and education. Improve language use between Biz/IT. Also, improve listening skills, answer the ‘why’ question).
- Start trying to visualize and manage WIP limits. Including reserving time to share knowledge and to make improvements.
- Visualize and understand end-to-end flow with all stakeholders and document pain points.
- Visualize improvements, such as a CSI (Continual Service Improvement) register and prioritize the together with end-to-end stakeholders.
- Agree team roles, responsibilities, focus on being proactive. Giving feedback, asking questions, getting the information you need from relevant roles.
- Suggest ‘Test Driven Development’ or certainly involving testers earlier throughout stream to agree on tests between hand-offs. Focus on ‘never pass a defect downstream’.
- Focus on communication to foster understanding and buy-in.
In Tomasz’s session, a key discovery was ‘visualization’. Without it, it is not possible to do any other improvements. As Tomasz added ‘Somehow there is this natural resistance to introduce transparency and visibility. DevOps is inspired by Lean Manufacturing which originated in factories where most of the things are immediately visible (eg. overproduction as waste, people not contributing to value stream, etc.). However, in DevOps, we deal mostly with invisible (abstract) things. That is why visualization is a foundation for any changes’.
I asked how many of you will now go away and apply these practices and then come back next year to present YOUR story? A number of hands went up. We will have to wait until next year to see if people take ownership to make change happen. As Sam stated ‘DevOps culture starts with everyone’, don’t wait for managers to start the ball rolling.
DASA DevOps Fundamentals
Provides an extensive introduction to the core agile DevOps principles covering the essential knowledge and skill competences that have been defined by DASA.
