Building DASA Competencies and DevOps Leadership Through Business Simulations

I recently facilitated a Phoenix Project simulation on behalf of Microsoft for the IT leaders of one of its customer organizations; in this blog you can get an idea of how simulations help organizational leadership understand the importance of the DASA DevOps core skill areas.

3 Part Blog

1. DevOps Demands a (Re)new(ed) Kind of Leadership
2. If You Want to Lead in DevOps, You Gotta Have Game
3. Building DASA Competencies and DevOps Leadership Through Business Simulations

In March 2018 Microsoft in the Netherlands organized a Leadership in DevOps workshop with GamingWorks. Twelve IT leaders from one of Microsoft’s top customers – an international parcel and e-commerce company – were invited to take part in a Phoenix Project simulation session in preparation for DevOps, which was on the strategic planning horizon for this organization. The twelve attendees came from different IT departments within the organization’s end-to-end value chain.

Why This Phoenix Project Simulation Session?

Stephanie Furum, Senior Service Delivery Manager at Microsoft explained the desire for the simulation training:

We see many of our clients adopting Agile and DevOps practices, and struggling to create buy-in and an awareness of the leadership changes this entails. Our Client had read The Phoenix Project and wanted to create awareness about the ‘Three Ways’ of DevOps within the organization. And once the client learned about the Phoenix Project simulation from GamingWorks, it was seen as an ideal way to bring all the company’s IT leaders together to create a shared view, and gain some commitment for the new way of working.

Stephanie Furum, Senior Service Delivery Manager Microsoft

The Goals of The Session:

• For people to get an understanding of what the ‘Governance & Leadership’. should be between the different teams: business/ops/dev and suppliers.
• To create a dialogue between the different teams to reach some common goals.
• To create a clear understanding what DevOps really means.

The Simulation Experience

The Phoenix Project business simulation is a dynamic, classroom-based, interactive workshop. Players on a team are assigned roles and responsibilities and placed in a realistic environment in which they must effectively communicate and collaborate, applying DevOps practices and principles to succeed. The simulation is played in a number of game rounds allowing the team the opportunity to continually experiment, reflect, learn and improve – in other words, to develop ‘Continual learning and improvement’ skills, one of the ‘Three Ways’ of DevOps.

What Happened During the Phoenix Project Simulation?

In the first simulation round the team decided to hold a ‘Stand-up’ to discuss how they would work and to plan their work. The team looked to the ‘Manager’ in the simulation to run the stand-up. The Manager started telling people what they needed to do and how they would work. People nodded ‘Yes’ but ended up doing ‘No’. The Manager ended up running around micro-managing, and flow was continually stopped, waiting for ‘management decision making’ and ‘escalation to the business owners’.

The individual teams were working in silos, not sharing information or asking upstream and downstream questions. There was a lack of insight into what everybody was working on and a lack of clear business focus on priorities; this caused even more management by ‘disruption’.

Nobody called a stop to discuss and suggest improvements.

It’s All About Learning, Reflecting, and Experimenting

After this round, the team had time for reflection, using the Three Ways of DevOps – Flow, Feedback, and Continual Experimentation & Learning – and the DASA DevOps core skill areas. The reflection focused on what happened during the simulation, and ‘how does this reflect our current real life experiences’ for the team?

What Were the Findings of this Initial Phoenix Project Gaming Session at Microsoft?

These were the findings, which also reflected what the Microsoft’s client saw happening within their teams:

• There was no clear flow; work and information was ping-ponging back and forth, causing many hand-offs and incomplete, incorrect work that had to be re-done… a wasteful approach.
• Not only was information ping-ponging ‘back and forth’, bust also ‘up and down’ through levels of management activities, which also caused flow to stop.
• The team was working in a siloed, task-driven mode without any thought to their place in the overall flow of work.
• They were not effectively communicating or collaborating. Assumptions were made which led to mistakes; defects were passed downstream, resulting in more unplanned rework.
• Testers were either not engaged, or engaged too late and had little insight into what had changed and what needed testing.
• The business roles in the simulation also ‘disrupted’ participants trying to discover what was happening, as they also had no visibility into the progress of their requests. Disruption is another form of ‘waste’, which slows down the flow of work.
• The business product owners were insisting on their features and had little focus for the issues as the impact of those issues was unclear.

Just like reality.

One of the client observations after the first simulation round.

When we examine these observations in context of the DASA core skill sets
‘Leadership & Feedback’, ‘Team building and Collaboration’, ‘Courage & Experimentation’, and ‘Continuous Improvement & Problem Solving’:

• The ‘manager’ was ‘telling people what to do’; and people were ‘waiting to be told’ or waiting for the ‘manager to decide’.
• The manager was not soliciting feedback and asking the team to experiment with a new way of working. The manager reverted to a leadership style of ‘ordering’.
• The team did not have the courage to call stop, give feedback and improve, as an end to end team.
• The manager did not stimulate ‘ownership’ or foster a team culture of continuous improvement and problem solving. ‘We could see things were not working but nobody had the courage or took ownership to say ‘stop!’- this isn’t working’ said one of the participants.
• The manager did not ‘empower the team’ by delegating decision making or clarifying priority mechanisms for choosing which work to work on first.

The team agreed upon improvements, to applying feedback mechanisms, and to improving flow. They organized a stand-up which was facilitated by the team. The business strategic goals were made visible and used to prioritize the work between new benefits and features as well as issues and technical debt.

For the manager this meant ‘hands off’. The team was not only delegated autonomy and decision making but were enabled and empowered by having clear goals and priorities, by having active engagement from the product owner and the whole delivery chain. The team was empowered by being allowed to call stop, to swarm, to reflect and learn, experiment with single piece flow, fail – learn from the failure and continually improve, without blame. The role of the manager was more one of ‘coaching’.

It is a totally different management role. I have more time to engage with the business and get a better understanding of the business goals, and am better able to proactively advise the business on the possibilities of emerging technologies to support the business – rather than to fire-fight and manage silo issues.

The manager

Translating the Learning into Action

At the end of the session we asked the team for their key takea-ways:

What did you learn? What will you take-away as key principles or actions?

The Client Took Away the Need to:

• ‘flatten bureaucratic hierarchy’;
• ‘allocate time for improvement and change’;
• ‘ensure good problem management to make the business impact of incidents and technical debt visible’;
• ‘map the whole end-to-end value stream if we want to learn to increase flow…not just dev and the agile teams’;
• ‘reserve a budget for dealing with technical debt, not just new features’;
• ‘Instill a culture of taking responsibility, of experimentation and risk taking and of continuous learning and improvement; making the improvements part of the visual management board for the teams helped focus end-to-end attention to improving’.

Guiding Principles:

These were discoveries or principles the team recorded on a flip-over during the simulation workshop.

• Team stand-ups need to include end-to-end representation. (Currently it is only the Agile development teams.)
• Teams have difficulty embracing the new ways of working. Assign a DevOps coach to teams to help instill the right behaviors such as feedback, courage, personal leadership, team working, business value focus, ownership. Managers must also play a coaching role.
• When limiting WIP in teams ensure enough is allocated to addressing ‘Technical debt’ – this may vary from team to team depending on existing levels of debt and team maturity. This needs to be normalized per application or product team.
• Ensure an appropriate budget mechanism is in place to accommodate technical debt. Often product owners have a budget and developer hours for new features, not technical debt.
• Ensure problem management uses incident information to make business cases based upon real business impact to ensure ‘technical debt’ is properly prioritized. Gaining real insights into end user feedback and impact is critical if ‘customer experience’ is a business driver.
• Ensure the right mindset ‘focused on business value’, and empower teams with decision making, priority and escalation mechanisms related to business value.
• Perform simulated try-outs and map the end-to-end value stream targeting on ‘waste’ and agreed end-to-end improvements, starting with the ‘constraints’ in the current flow. (Currently the operations flow is a black box.)
• When we have ‘empowered’ the teams’ managers they must spend more time to build relationships, gain a better business understanding, and start advising the business, becoming more of a strategic partner.

This was a powerful way of bringing the end-to-end management together to explore and experiment as to what DevOps will mean to the way of working – and also the changing role leaders need to play.

This has given us a lot of concrete ideas to take away and apply.

Leadership is crucial for making this happen and creating the right culture.

The team

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
In 2013, authors Gene Kim, Kevin Behr and George Spafford published a novel with a story recognizable for any IT manager: Bill, an IT manager at Parts Unlimited, has been tasked with taking on a project critical to the future of the business, code named Phoenix Project. But the project is massively over budget and behind schedule. The CEO demands Bill must fix the mess in ninety days or his entire department will be outsourced.

Paul Wilkinson is the CEO of GamingWorks and has aligned his Phoenix Project Simulation to the DASA Team Competence Model. Find out more about the DASA training and certification programs, starting with DASA DevOps Fundamentals.

GamingWorks is a DASA Forerunner member and Paul Wilkinson is a DASA Global Ambassador. DASA Ambassadors are charged with raising the profile and awareness of DASA, the DevOps Agile Skills Association; to this end GamingWorks has conducted a series of Phoenix Project business simulation workshops around the world, based on Gene Kim’s book The Phoenix Project to show the value of simulations in supporting the DASA Team Competence Model. GamingWorks simulations help delegates translate theory into practice, and enable DevOps teams to experiment together, developing their own DevOps skills and competences.

See the Active Learning Delivering Business Value white paper showing how the Phoenix Project simulation supports the DASA Team Competence Model.