MoveIT 2019

People and culture were front, left, and center at the recent CTG moveIT event in Belgium. CTG recognizes that many organizations are embarking upon Agile transformation journeys and encountering barriers that prevent them from realizing the desired value. The event was designed to explore these challenges, share experiences, and discover tips for success.

In this article, I share some of my takeaways from the sessions I attended.

Where Is My Job?

In the opening session, “Where Is My Job?,” Michael Pilaeten explored new job titles and skills required in this new era of digital transformation. He answered questions such as, “What does it take to be a valuable team member nowadays?,” “Which skills and techniques are expected in your IT toolbox?,” and “What competencies are organizations looking for?” It was clear that there is a strong focus on technology skills and not enough on soft skills such as collaboration, communication, and problem-solving. Michael presented various tools to assess some of these soft skills, such as the Myers–Briggs Type Indicator, the Belbin team model, and, more specifically, the DevOps Agile Skills Association (DASA) Competence model that focuses on both hard and soft skills and required knowledge. The session explored how this can help assess and build the appropriate individual and team skills, particularly “Courage,” “Team Building,” “DevOps Leadership,” and “Continuous Improvement.” Michael also suggested ways to cultivate these skills, including experiential learning such as business simulations, which allow teams to develop collaboration skills.

Mind the Gap!

Stefan De Cap and Tijs Hillewart gave an entertaining session, presenting and acting in their theme of “Agile—Mind the Gap!” to show how brilliant implementation ideas are often met with confusion, frustration, anxiety, and resistance—a gap between idea and execution which is often not seen or adequately addressed. They demonstrated that there is a clear need for effective leadership and management of change skills. I explored some thinking around this in a recent blog on DevOps.com: DevOps: Assessing Behavior Flows Through an Organization.

From Sheep to Red Monkeys

Jef Staes, in a controversial presentation, exposed “sheep” behaviors—blindly following old ways of thinking and behaving—in many organizations; the scam of existing training initiatives that don’t foster continual learning and experimentation; and the need to shift from continual improvement of existing business models to “disruptive innovation.” This represents a significant mindset and behavior change at all levels within an enterprise, a shift from “sheep” to “red monkeys,” but it can be a step too far for many organizations. The session was certainly was food for thought, but the issue presented is not easy to swallow and will cause heartburn for many. It was a very inspirational, thought-provoking session.

Theory to Behavior

I conducted a walk-through of the Phoenix Project simulation, showing how simulation can be used to foster skills such as communication, collaboration, continual learning, and improvement, as well as some hard skills such as Kanban, stand-ups, retrospectives, and the three ways of DevOps.

In the simulation walk-through, participating teams identified challenges they currently recognize, challenges that are barriers to success. At the end of the session, after exploring DevOps principles and DASA competence skills, they captured concrete takeaways.

What were the challenges that the teams recognized?

• The business role in the simulation, after watching the end-to-end ping-ponging of work and lack of prioritization based on business needs. “Outsource!” they said, recognizing that IT was not responsive or effective enough for the business.
• No clear flow of work and the fact that it entered at different places within IT. Business owners put work through the system, causing ping-ponging, escalations, and waiting for decisions.
• Business made requests without sharing strategic goals and or governance mechanisms for prioritization when demand is too high and resources scarce.
• Unclear roles and decision-making authorities, mistakes made, assumptions made, and delays and waiting.
• Not enough insight into all of the changes and how they relate to business projects, and more importantly, strategic business initiatives and goals.
• The Test team was engaged too late and did not have enough insight into what had changed and what had not changed but should have.
• The CISO did not have enough insight into the business initiatives and what had changed or not changed in terms of protecting critical information.
• The teams of specialists were overwhelmed with work and had no insight into how the work related to business goals. Also, they were not given time to allocate for improving or creating multi-functional teams.
• Lack of insight into the pipeline of strategic initiatives made it difficult to pinpoint the scarce skills (constraints) and the need for creating multi-functional teams.
• Lack of IT governance from the business.
• IT blames the business and the business blames IT for not understanding enough about the business and the business goals. Read chapters 25 and 26 of The Phoenix Project book!

What were the key takeaways?

After exploring the three ways of DevOps and topics such as “flow,” “visualization,” “never pass a defect downstream,” “feedback’, and “continual improvement,” the teams then captured their key takeaways from this workshop. Considering the challenges they already recognized, which learning points would they take away to “experiment” with?

• Shift left. Build quality in and foster a culture of “never pass a defect downstream” in terms of product, as well as information and behaviors (walk the talk).
• Improve the ability to make Work-In-Progress (WIP) estimates and identify waste and bottlenecks (How long does something take?, Is there a need for training?, How long do we wait between activities, What is stopping flow and is a form of waste)?
• End-to-end value stream mapping. Not just DevOps and “code-to-deploy,” but “idea-to-value,” which also requires business engagement and effort.
• Foster a culture of feedback. Create an environment of trust and no blame, and agree with what effective collaboration is. Feedback is a critical part.
• The need for developing multi-functional capabilities and making a business case for this. Reserving time for continual learning and improvement and sharing.
• Visualize the business portfolio of initiatives and goals so that teams can relate what they are working on to business value and prioritize effectively.
• Start to discuss, explore, and apply the three ways of thinking tomorrow. You don’t need Continuous Integration/Continuous Deployment (CI/CD) pipelines and tools to start a DevOps journey.
• DevOps is NOT an IT thing.
• The importance of continual learning and improvement, visualizing improvements and prioritizing these with a view on end-to-end flow and value, not on local, siloed improvements.