The CEO rubs his throbbing temples. Digital disruption is giving him a headache. All this talk about digital transformation and how competitors are stealing business away with their new ‘DevOps’ ways of working – whatever that ‘DevOps’ means.
Never mind all of this transformation stuff, he’d be happy if IT could start delivering what we have been promising for months in terms of new IT products to the market.
And now it is even worse with teams working at home and still having to deliver.
The CEO sees a poster of the ‘DASA DevOps principles’ on the office wall. He reads them. ‘Are these just more slogans and buzzwords on the wall or do these represent values that drive behavior?’ he asked himself.
The CEO invited himself to listen in to a remote Phoenix Project online simulation session to see how the teams performed. It was something about ‘Go to Gemba’ – go and see the actual process. He looked at the principles text and matched this with what he was hearing and what he was seeing.
Principle 1: Customer-Centric-Action
“….It is imperative nowadays to have short feedback loops with real customers and end-users, and that all activity in building IT products and services centers around these clients. To be able to meet these customers’ requirements, DevOps organizations require the guts to act as lean startups that innovate continuously, pivot when an individual strategy is not (or no longer) working, and constantly invests in products and services that will receive a maximum level of customer delight….”
‘Customer delight!’ Hurrumphed the CEO. That would make a change from the complaints he usually hears about delayed releases and things not working.
What he sees: He hears the Product owner and business managers insisting that the latest ‘customer’ feature is deployed. ‘Is that really what the market wants?’ He asks himself. He sees some ‘technical debt’ on the visual backlog that is going to be ignored – ‘again’ according to one team member. ‘If I was a customer I wouldn’t be too happy about that’ said the CEO to himself, wondering how much time and effort the Product owner and team actually spent gaining feedback. He could hear an awful lot of assumptions being made as well as ‘we don’t have time for that’! (Talking about gathering feedback). The CEO considered that this principle also mentioned ‘pivoting’ if a strategy isn’t working. He wondered if the team knew what the strategy was?
Reflection: The CEO was delighted to see at the end of the simulation workshop that the team had made some discoveries and captured some actions to take away, actions to translate the principles into behaviors:
- Engage with the customers and users regularly to identify what the real NEEDS are. In terms of new innovation as well as what they are currently using. – Capture and visualize NEEDS and use these to prioritize.
- Understand how the strategy enables the realization of customer needs, and how changing customer needs impact strategy decisions – Visualize strategic goals, visualize goal achievement.
- Ensure prioritization and decision making mechanisms are aligned to these strategic goals.
Principle 2: Create with the End in Mind
“….Organizations need to let go of waterfall and process-oriented models where each unit or individual works only for a particular role/function, without overseeing the complete picture. They need to act as product organizations that explicitly focus on building working products sold to real customers, and all employees need to share the engineering mindset that is required actually to envision and realize those products….”
What he sees: The CEO watched the team filling the online backlog of ‘work to do’ on their virtual board. They were talking about optimizing the ‘flow’ in their ‘value stream’ to realize the products. It looked to the CEO that they were talking a lot about ‘getting the feature deployed’ and a ‘build to deploy’ rather than ‘Idea to value’ stream.
The CEO was starting to see a picture of types of work and types of value in his head. There was value creating work like ‘features’, there was value leakage work like ‘defects’ and ‘technical debt’, there was improvement work such as ‘impediments’ and ‘waste’. But he couldn’t see all this visualized by the team. He could see on the board their metrics — ‘numbers of releases’ and ‘time to release’, he could see how many features had been released, which technical debt had been resolved — or ignored!. He looked at the growing backlog of work and wondered if, and how this all related back to the business goals and to business value optimization. He was missing the complete picture on this board. ‘This doesn’t give me situational awareness or help me make the right decisions to prioritize all this work’ he thought. Perhaps the business doesn’t have any place in this — after all it’s called DevOps, not BizDevOps. This made him think again about Principle 1 and being able to pivot if the strategy wasn’t working. ‘If there isn’t a fit between the work and the strategy, then how will we know when to pivot’ he thought?…..
Reflection: Once again the CEO was pleased to see at the end of the simulation that the team had made some discoveries and captured some actions to take away, actions to translate the principles into behaviors:
- Understanding end-to-end value streams, optimizing the flow and removing barriers and waste – Map value streams and prioritize removing waste and barriers
- Understanding the types of work that needs to flow and how these contribute towards value creation (e.g. new features), as well as value leakage (e.g. technical debt, defects) and work that enables us to be agile and to be able to Pivot (e.g. Improvements) – Cluster types of work in the backlog. Check against strategic goals and goals achievement so far.
Principle 3: End-To-End Responsibility
“….Where traditional organizations develop IT solutions and then hand them over to Operations to deploy and maintain these solutions, in a DevOps environment teams are vertically organized such that they are fully accountable from concept to grave. IT products or services created and delivered by these teams remain under the responsibility of these stable groups. These teams also provide performance support, until they become end-of-life, which greatly enhances the level of responsibility felt and the quality of the products engineered.
What he sees: The CEO noticed a ‘Them and Us’ culture. The Product owner and dev teams were focused on the ‘Features’ (Customer centric) and getting products built (with too little feedback). They were giving lower priority to the ‘working of the products’ and were not prioritizing ‘technical debt’, ‘defects’ and removal of ‘impediments’. Ops were talking about the ‘working of the products’, outages and the SLA. The CEO noticed it was still SILOd thinking with each SILO having their own KPI’s to defend. They were not creating with the ‘End-in- mind’.
Reflection: Once again the CEO was pleased to see at the end of the simulation that the team had made some discoveries and captured some actions to take away:
- Collaboration requires understanding ‘shared goals’ (e.g. strategic goals), as well as SILOed goals (e.g. when resources are shared and hands-offs occur to teams with other goals) – Visualize goals, shared, team and sprint goals to identify conflicts.
- Balancing prioritization of types of work – Agree using visualization of goals and current goal achievement. Ensure clear decision making and escalation authorities to deal with conflicts.
- Ensuring prioritization flows end-to-end and there is accurate, complete visualization of information to enable effective decision making – Ensure prioritization is clear in end to end tools as work flows downstream and clear visualization of choices that need to be made.
Principle 4: Cross-Functional Autonomous Teams
“…In product organizations with vertical, fully responsible teams, these teams need to be entirely independent throughout the whole lifecycle. That requires a balanced set of skills and also highlights the need for team members with T-shaped all-round profiles instead of old-school IT specialists who are only knowledgeable or skilled in for example testing, requirements analysis or coding. These teams become a hotbed of personal development and growth….”
What he sees: The CEO noticed the team struggling with the amount of work. He could see constraints caused by impediments and bottlenecks, one of these was related to skills and hand-offs. But reserving what the team referred to as WIP or Work-in-Progress seemed to be focused on reducing the growing backlog of features to achieve the short term goals of customer centricity and not on the longer term goals (End-in-mind). ‘We will be continually struggling to keep up if we don’t create cross-functional teams to reduce hand-offs’ thought the CEO, ‘and if we don’t focus on the impediments, the waste and the technical debt and its impact will keep growing’! It seemed like the team did not have the autonomy to choose how to spend their WIP. Together with the product owner they thought they were doing the right thing maximizing feature throughput. It was NOT a hotbed of development and growth with an ‘End-in-mind’.
Balanced set of skills. Never mind the mix of technical skills. The CEO could also see teams struggling with the new end-to-end ways of working. Working in end-to-end value streams, being autonomous, applying continual learning and improving, effectively communicating and collaborating wasn’t easy. They were not giving each other feedback or helping each other improve. Not all teams could learn and mature at the same speed. Nobody seemed to be coaching the teams to help them develop and grow and embed the new ways of behaving.
Reflection: Once again the CEO was pleased to see at the end of the simulation that the team had made some discoveries and captured some actions to take away:
- Understand the balance of team skills and bottlenecks. – Do a self assessment on maturity on the required knowledge and skill areas (e.g. using DASA’s Quick Scan), and reserve time for continuous learning and improving.
- Learning new ways of working takes practice and experimentation. – Coach teams to help them improve. Develop coaching skills.
- We need to be open for feedback and feel safe experimenting and giving feedback – Practice giving feedback and use for learning and improving, remove blame!
- Ensuring that product owners balance types of work, and support the team culture of learning and improving – Change role and responsibilities of Product owner and look at DASA Product owner training.
- Ensure that managers understand their role in empowering autonomous teams and for fostering a culture of feedback, learning and improving. This requires a shift in leadership styles and behaviors – Look at DASA Leadership training and OBM (Organizational Behavior management).
Principle 5: Continuous Improvement
“…End-to-end responsibility also means that organizations need to adapt continuously in the light of changing circumstances (e.g. customer needs, changes in legislation, new technology becomes available). In a DevOps culture, a strong focus is put on continuous improvement to minimize waste, optimize for speed, costs, and ease of delivery, and to continuously improve the products/services offered. Experimentation is therefore an important activity to embed and develop a way of learning from failures is essential. A good rule to live by in that respect is if it hurts, do it more often…”
What he sees: The CEO watched the team reflect. There was a clear recognition of the need to improve – to remove waste, to gather more feedback, to cross-train. He was delighted that the team was discovering this for themselves. Yet there was little WIP time reserved to make the improvements. There was little time being spent on coaching the team to practice, experiment and improve. Once again ‘features’, a false sense of ‘customer centricity’ or rather ‘customer immediacy’ and business imposed KPI’s were stimulating the wrong behaviors. Frustration, a feeling of blame, lack of time for improvement were damaging trust in leadership and stifling the will to experiment. If there was a need to ‘Pivot’, if the ‘strategy was not working’ then the ability to make improvements would be critical.
Reflection: Once again the CEO was pleased to see at the end of the simulation that the team had made some discoveries and captured some actions to take away:
- Ensure end-to-end reflection, discussion and improvement –Reserve time to capture and visualize improvement needs with end-to-end stakeholders. Reserve time to work on these.
- Identify impediments and waste in the end-to-end value stream – Map value streams and waste.
- Foster a culture of continual learning, experimenting and improving, in a blame free environment – Product owners and Managers to stress the importance and empower teams with time and resources to improve.
Principle 6: Automate Everything You Can
‘…To adopt a continuous improvement culture with high cycle rates and to create an IT organization that receives instant feedback from end users or customers, many organizations have quite some waste to eliminate. Fortunately, in the past years, enormous gains in IT development and operations can be made in that respect. Think of automation of not only the software development process (continuous delivery, including continuous integration and continuous deployment) but also of the whole infrastructure landscape by building next-gen container-based cloud platforms that allow infrastructure to be versioned and treated as code as well. Automation is synonymous with the drive to renew the way in which the team delivers its services.’
The CEO had already seen that a lack of investment in continual learning and improvement, as well as lack of feedback wasn’t helping to identify or eliminate waste. This was also a risk for them to be able to Pivot quickly. The CEO saw that the team had many ideas but these were not on their backlog of work. He heard suggestions for CICD, Value streams, Infrastructure as code, automated testing – ways to use automation to improve speed and reduce waste. But the team were unable to map these to the bigger picture and make the business case. Again Product features and KPI’s to achieve Revenue, CSAT and quarterly goals were driving prioritization. If we really meant to operate with The ‘Énd-in-mind’ this would mean that some value would have to be sacrificed in the short terms for the value in the longer term.
- A lot of time is wasted with ‘Toil’ – repetitive, manual tasks and rework from mistakes – Visualize the amount of wasted time – look at ways to automate to reduce wasted time AND avoid mistakes (e.g. automated testing, infrastructure as code, CICD).
- There is a heavy investment in point solutions as teams invest in tools to solve individual team needs – Use end-to-end value stream and identified impediments to explore areas to automate and map tools to support and enable the value stream.
- Many good ideas are lost or ignored – Add to the backlog of impediments improvements that can be enabled by automation.
- Look at end-to-end tools that support each step in the value stream and agree where hand-offs can be automated
- Often work stops or goes back upstream to gather missing information – Agree upstream and downstream information needs and engineer these into end-to-end technology solutions. Look at IT4IT as an enabler.
It was clear to the CEO that having a list of Principles on a poster was not going to transform his teams. These needed to be translated into ‘observable, desired behaviors’ and these needed to be embedded in a culture of feedback, learning and improving. It was clear that the real value of DevOps could only be realized when he and the leadership team were committed to empowering the teams to make the change. Supporting them with the right leadership and coaching.
There was a powerful list of takeaways from the online simulation workshop. Would we go back to aiming for the short term goals or would we act with the ‘End-in-mind’ – a sudden chilling realization dawned on the CEO, do we all have the same strategic vision of what the ‘End-in-mind’ looks like?
DASA DevOps Coach
This three-day course is for individuals aspiring to guide teams and organizations through the complexities of DevOps transformations.
