From Silo’d individuals to a High Performing DevOps team in 4 hours!

If your organization is embarking upon a DevOps initiative, or is struggling to address the Cultural aspects of creating DevOps teams hopefully this title got your attention! Read on and find out how the team achieved this!

At a DASA meetup sponsored by the DevOps Agile Skills Association, ITPreneurs, TechnoLava and GamingWorks, a team of delegates got together to explore DevOps success.

Deborah Burton from DASA shared the latest trends and drivers relating to the global adoption of DevOps, emphasizing that there is no doubt that DevOps can deliver significant improvements and is starting to become mainstream, however a 2017 Gartner survey found that ‘Team Culture was among the top 3 attributes that have greatest impact on an organization’s ability to scale DevOps’. Deborah positioned the DASA competence framework as an instrument for both addressing these cultural challenges and for developing skills to create high performing teams.

From Theory to Practice!

Brad Utterback from TechnoLava supported by Paul Wilkinson of GamingWorks facilitated two rounds of the Phoenix Project simulation. The aim was to explore DevOps in action and to experience both success and fail factors relating to DevOps adoption.

The business simulation, based upon The Phoenix Project book, is a dynamic, classroom-based, interactive workshop. A team of players are assigned roles and responsibilities and placed in a realistic environment in which they must effectively communicate and collaborate applying DevOps practices and principles in order to succeed. The simulation is played in a number of rounds. At the end of each round the team must demonstrate performance improvements in terms of number of deployments, successful deployments, resolution effectiveness and business value realized. Between simulation rounds the team learns to reflect and apply continual improvements.

What happened?

At the end of the first simulation round the team declared that it was ‘chaos’.
What were the Key factors for this chaos? And how do these relate to real life observations?

Communication was poor.

• People talking through each other, interrupting half answered questions; ping-ponging ideas & comments; assumptions were being made; unclear decisions.
• Little active listening; summarizing; establishing team wide agreements on communication discipline. Lack of confirmation of agreements; lack of actively asking for clarification or help.

Team Working

• People operating in a ‘Silo’d Task mode’ without any understanding nor agreement of an overall flow of work through the system, and more importantly flow of information so that people could do their work without having to go back and ask more questions, creating even more disruptions and stopping the smooth flow of work.
• Roles and working practices unclear causing frustration and resistance. People building new procedure and KanBan boards failing to engage with the rest of the team who promptly ignore or circumvent the new way of working – ‘Not invented here’.

Leadership

• Informal leadership, such as trying to take ownership to organize a stand-up often not accepted or respected by the rest of the team.
• Leadership is more than telling people what they need to do, leadership skills need to be developed to manage organizational change and foster a culture of ownership and collaboration.
• ‘We need to respect who is leading a stand-up as ‘orchestrating’ the discussion and activities’.

Courage

• Some people trying to take ownership to organize the team.
• People calling ‘Stop’ in an attempt to resolve the chaos. Although people stop there is no focus on agreeing iterative improvements, or capturing impediments and improvement needs.
• It takes courage for managers to let the teams experiment and explore new ways of self-empowered working.

Continuous improvement

• Although individuals recognize that things are not working there is no team effort to stop and make improvements. ‘There is no time to improve!’ – which often reflects reality – not taking time out to reflect and improve.

After the first round we related the team discoveries to the DASA skill sets ‘Courage, Leadership, Team building & Continuous improvement’. The team recognized that these are skill areas that are critical for shaping the right culture. In the second round the team consciously adopted and applied these skill areas as well as practicing the 3 ways of DevOps – these being ‘Flow, Feedback and Continual learning and experimentation’.

BizDevOps

In the second round the team timed flow and applied small iterative improvements, they agreed a communication discipline. They agreed an end-to-end flow of work and built a Visual management board. One key area they recognized as a real-life issue at the start of the day was prioritization. Prioritizing business projects vs support work. In the second round the team mapped the strategic business goals onto their Kanban board and prioritized based upon the DASA knowledge area ‘Business Value optimization’ balancing resources for ‘new benefits and features’ (value creation) vs ‘Technical debt and downtime’ – which impacts customer loyalty, share price, revenue, image & reputation (value leakage) recognizing that the real value of DevOps comes from a BizDevOps mindset and engagement.

Takeaways?

What were some of the key takeaways at the end of the simulation exercise? The team recognized that:

• It takes ‘courage’ to agree that all in the team are equal (including the business) and can give feedback to ALL team members without ‘blame’ and ‘hierarchical leadership models’ stifling ideas and experimentation.
• Building the visual management board together helps foster the team working, exploring together what the team and each member needs as information and decision making from the visual management system – it needs to be designed by the team, for the team, to support their way of working. It takes experimentation and discipline before the board contains what the team needs to manage the flow of work.
• It is important to hold 20-minute retrospectives to capture impediments and add these onto the backlog of work.
• It takes ‘courage’ to experiment with single piece flow. ‘You need to slow down so we can speed up’ said one.
• It was important to time each flow and explore where flow is slowing down, stopping or going back upstream because of lack of, or incorrect information, and the courage to call ‘stop’ and then ‘swarm’ and solve issues as a team.
• Teams have different levels of maturity which means it may take longer for some teams to improve. Some teams will need more coaching.
• It is important to measure for each team the % of planned vs unplanned work and to focus effort on reducing unplanned work by shifting left and building quality in.
• It is important to create multifunctional teams, adopting a 1:3 (1 person in a team should be able to perform 3 tasks) & 3:1 (3 people in a team should be able to perform the same task)
• It is important to assess team maturity and team skill composition and allocate suitable WIP for continual learning and improvement.

In less than 4 hours the team had agreed their own rules for communication and collaboration, they had agreed as a Biz-Dev-Ops team their own cultural values – ‘respect’ ,’no blame’, ‘seek help and understanding’, ‘calling stop and all helping solve issues as an end-to-end team’, ‘reserve WIP for learning & improvement’, ‘celebrating business success resulting from deployments’ and ‘balancing features & technical debt based upon business value optimization’.

Not bad for a 4 hour exercise to foster team working and shaping the right DevOps culture!