“From taking once a year to release a packaged software in 2015,

to having deployment to production 82K times a day in 2019,

HOW DID THAT HAPPEN!?”

We were sitting with a group of CxOs from Germany at the Redmond Executive Briefing Center in February 2019, an Azure engineering lead started to explain the history of our own DevOps transformation.

“The definition of Microsoft’s DevOps may seem obvious, but this journey actually includes many different products and teams at Microsoft with their own challenges, struggles and histories. Different teams used to have different tools and different processes. Those individual teams had large ongoing investments in these different tools and processes which was frankly costly and burdensome. Under Satya, we’ve acknowledged the need for modern DevOps practices and tools for all Microsoft products and services.”

The engineering lead continued, “There was a strategic decision made by Satya and leadership that enabled aligned autonomy. Here is Satya’s quote:”

After a three-hour-long conversation with executives, the engineering lead concluded, “Now Microsoft Windows, Office, Bing and many other Microsoft properties are built using a consistent set of tools that we call “One Engineering System” or 1ES. We’re a long way on the journey, and still have a lot to learn. But here are lessons that we’ve learned so far. Customer focussed, Team Autonomy and Shifting Left are basically second decade agile. DevOps brings Product First Mindset and Infrastructure as a Flexible Resource into play. We’ve got to where we are now over a long time, and it’s been a very iterative process. But we’re not done – we still have a lot to learn.”

There was a long pause, then the CIO said, “Fascinating! Just in case you have not realized this. You are more like us – large enterprise companies. Unlike Google or Amazon, which was born in the cloud, you started from a large enterprise software business, now you are a cloud company. Your lessons and your experience are much more relevant to us. How can you help us?”

They all turned around and looked at us, “Services can help!”

DevOps in Services

If you are in the business of IT Services, you will understand the differences between Products and Services:

• Selling hardware is about selling transactions.
• Selling software is about selling experiences.
• Selling services is about selling promises.
• Selling promises is about building trust.
• Building trust requires competency and character.

Trust at the personal and professional level is all about people believing in your competency and your character. Missing either will prevent the establishment of trust.

So, the million-dollar question was how could we package competency and character to demonstrate trust for such a complex topic in a highly dynamic enterprise landscape?

Furthermore, the engineering maturity level, the culture/org structure, and the funding model of the Microsoft Product Groups (PGs) are quite different from most of the enterprise customers. Even if our Microsoft PG model could serve as a north star, it could not be completely replicated without careful redesign and fine tailoring within the customers’ context. It requires Services to put a structural approach in place where people can experience, learn, and grow through the proper management of change.

DevOps at Microsoft Services

Before we can address “Trust” in the DevOps space, we must have a common understanding of what DevOps really is. Since the birth of DevOps in 2009/2010, there have been many definitions depending on who you talk to. People mixed various terms such as Agile, DevOps, Secure DevOps, DevSecOps, MLOps, and BizDevSecOps interchangeably into their vocabulary.

In Microsoft Services, we also had a long debate among the most brilliant, opinionated, and passionate DevOps Practitioners on what DevOps really means for Services organizations. We eventually adopted Gartner’s definition (Gartner Predicts 2020: Agile and DevOps Are Key to Digital Transformation) “In the future, we will no longer have a divided conversation between agile, DevOps and project teams. It will be a product-centric value stream conversation with a singular focus on customer value.”

Once we were settled with the scope of DevOps at Services, the next step was to make it simple and structural. But how can we make it simple and understandable for such a complex topic with such a diverse group of stakeholders? As Steve Jobs said: “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

The MECE principle has helped us to really understand DevOps. The MECE principle, pronounced “ME-see”, is a grouping principle for separating a set of items into subsets that are mutually exclusive (ME) and collectively exhaustive (CE). It was developed in the late 1960s by Barbara Minto at McKinsey & Company and it underlies her Minto Pyramid Principle and is based on ideas going back as far as Aristotle.

This is our DevOps MECE. Notice that people, culture, mindset, and org structure consist of 50% of the challenges in the DevOps transformation. Equally important to understand is that people involved in the DevOps transformation is beyond just IT organizations.

Now with a greater appreciation of what DevOps really is in our Services business, and with a clearer understanding of the importance of people, mindset, culture, org/teams’ structure, process, and architecture in the DevOps transformation, we have defined our DevOps Taxonomy as modular, capability-based, and human-centric. This aligned autonomy helped us develop a common vocabulary and structure while also encouraging the teams’ autonomy to continuously experiment and innovate.

If we only stay with this definition, it will just be a piece of paper and will never fulfill its full potential and purpose. With a joint effort between our Product Groups and Services, we kicked off an internal initiative called the DevOps Dojo.

Why use Dojo for DevOps

Why did we choose Dojo? Dojo is the philosophy and virtue we strive to practice and amplify every day.

The Dojo martial artist, who is dedicated to a true martial arts system, is a person with values and morals. The martial arts Dojo was designed for preserving peace, respect, and harmony while having the ability to overcome difficulties. This mindset will help martial artists develop a strong sense of passion for what they believe in.

Martial arts training is a way of developing the mind, body, and spirit of a peaceful warrior who is one that only engages in combat for good reasons. As the attitude and strength of one’s character will win the battle before it even begins. It takes years of relentless training and personal introspection to attain this goal. Character building is so important because you will face many moral decisions in life.

Dojo is more than just skill building, it is character building which requires a mindset change.

1. Dojo: Integrate learning though practice <=> DevOps: Culture of experimentation
2. Dojo: Strive for good moral character <=> DevOps: Culture of accountability
3. Dojo: Maintain honesty and sincerity <=> DevOps: Culture of psychologic safety
4. Dojo: Preserve peace and harmony <=> DevOps: Culture of collaboration
5. Dojo: The art of conflict prevention <=> DevOps: Culture of open minds
6. Dojo: Develop a respectful attitude <=> DevOps: Culture of diversity
7. Dojo: Ask questions freely of the master <=> DevOps: Culture of customer-savviness
8. Dojo: Cultivate perseverance through a will for striving <=> DevOps: Culture of commitment
9. Dojo: Restrain physical aggression through spiritual attainment <=> DevOps: Culture of teams
10. Dojo: Move from easy to difficult, simple to complicated <=> DevOps: Culture of discovery

We develop Dojo as a Lean Product which requires an inspiring vision, clear mission, focused strategy, human-centric design, and committed execution. Since the birth of Dojo, we have not changed our vision and mission instead we persevered and pivoted our strategies.

Our Vision: the future we are trying to create.

• DevOps becomes a Standard Software Delivery method at Microsoft Services.
• Microsoft empowers worldwide customers to innovate at the speed of business.

Our Mission: Why we exist.

• Solve the hardest DevOps problems.
• Accelerate DevOps Culture.
• Make DevOps Real.

Our Strategy: what we do and what don’t do.

• Strong Partnership with PG/GitHub to learn from the best.
• Business & IT & Human-centric Design interdisciplinary area
• Community of Practice with Innersourcing & Open Source.

Our Design: User-centricity and empathy.

• Design with three parts: theory and concept, discussion and design, and hands-on labs.
• Design for various personas in Business, IT and Users in the DevOps Transformation.
• Design that is tool-agnostic while enabling multiple technical reference implementations.
• Design to support three types of learning: self-learning, expert-led learning, and peer learning.

What is the DevOps Dojo at Microsoft?

Today, DevOps Dojo is a community of practice at Microsoft. It started from the Services organization, then expanded to Customer Success, Digital Advisory, Product Groups, and other organizations. It is a community where cross-functional teams practice agile, continuous collaboration and automation principles of DevOps to find the best path to delivering software from idea to production with quality.

First let’s talk about the Dojo belts system. Currently we have 4 Belts:

Dojo White Belt: Standardized DevOps

The White Belt is designed to cover the standardized DevOps practices that are best for a single or small number of teams. We begin to introduce OKR, which is an effective tool for team alignment. Objectives and Key Results (OKR) is a popular and proven technique for setting and communicating goals and results. The OKR system helps teams identify the optimal result and creates clarity around what real success looks like. For more info on OKR, we recommend the book “Measure What Matters” by John Doerr.

Dojo Orange Belt: Scaled DevOps

The Orange Belt is designed to cover scaling DevOps in enterprise at the team level, program level, and portfolio level. Scaled DevOps includes how to scale organization (aligned autonomy), process (lean product management), architecture (data and process integrity), and knowledge (experiential learning).

Dojo Green Belts: Lensed DevOps

The Green Belts are designed to cover DevOps practices from various lenses to address special needs from different industries. For example, we are designing lensed Dojos for UX/Accessibility, SRE, Secure DevOps, Data/AI, as well as other industries. We welcome “Co-Create” with our customers to address their unique needs. For example, we partnered with an Asia customer to add GDPR into the Dojo Belt to launch their products in Europe.

Dojo Black Belt: Intelligent-driven DevOps

The Black Belt is designed to focus on Data-driven DevOps. Currently we are doing innersource in all Belts in GitHub. We created various dashboards to show contribution data, pull request data, usage data, location data, and top ten most used topics. The data gives us a great deal of insight on how we are doing and where we should improve in our own DevOps journey.

Besides skillset building, Dojo is an agent for mindset change. We are looking for Black Belt coaches with the following attributes outlined in Gartner’s recommendation: – Lean Thinker – Agile Mindset – Strong Listener – Development Experience – Hands-on DevOps Experience – Easily Builds Trusting Relations – Focused on Continual Improvement – Charismatic, Strong Leadership Traits – High Level of Emotional Intelligence – Experience with Organizational Change Management

The master class is designed to be immersive: Tell me and I forget. Teach me and I remember. Involve me and I learn. For every single capability in Dojo master classes, we have three learning components: theory and concept, discussion and design, and hands-on labs.

One of the most important missions in Dojo is to make DevOps Real. This is even reflected in our technical labs which include the storyline, various apps within a solution, diverse technologies, and process integrity.

The first reference implementation uses Azure DevOps.

The second reference implementation uses GitHub.

Our Journey

Hopefully by now you have a good understanding of where we are coming from and where we are headed. Here is a video of our amazing journey.

We have evolved so much since the birth of DevOps Dojo. Today, Dojo has become an ecosystem at Microsoft. It is a community of practice where Dojos solve the hardest DevOps problems, build incredible innovations, and deliver products to customers by applying proven DevOps best practices. Our belief is that we eat our own food so that we know the taste before sharing the best food with others. We show our vulnerabilities, setbacks, and failures in the process, while we continuously improve and learn.

Now we can say that we have learned a great deal by bringing the best practices from Product Group to Services. This is our third year on this journey, and it has honestly been quite bumpy. We had a lot of struggles, disappointments, and setbacks, but at the same time, we had much joy, satisfaction, and growth. This is the road least travelled, but it made all difference for those who have been in this journey.

Let’s loop back to the customer CxOs’ inquiries from Germany. We have created the Dojo program internally to respond to customers’ request to help them transform. We have started to help our customers transform their organizations by showing them the way we work, the way we learn, and the way we experiment. Through Dojo, we have built trust with our customers because we strived to demonstrate competency, as well as character.

How to Dojo

In the coming weeks and months, we will share the lessons we learned in our journey. It is not all smooth and rosy, but we believe in the gifts of struggle. Dojo made us better humans, better professionals, and better global citizens. The blogs are NOT about showing how great we are, they are about sharing what we have learned and where we have stumbled for the benefit of your DevOps transformation. Sharing is caring.

Our future topic candidates:

1. Dojo – People & Teams
2. Dojo – Experiential Learning
3. Dojo – Customers & Trust
4. Dojo – Culture & Mindset
5. Dojo – Product Centric Model – Part 1
6. Dojo – Product Centric Model – Part 2
7. Dojo – Product Centric Model – Part 3
8. Dojo – OKRs (Objectives and Key Results)
9. Dojo – InnerSourcing
10. Dojo – UX/Accessibility
11. Dojo – Architecture
12. Dojo – Technology
13. Dojo – Secure DevOps
14. Dojo – SRE

We would like to end this blog post with a quote:

“If you want to bring a fundamental change in people’s belief and behavior…you need to create a community around them, where those new beliefs can be practiced and expressed and nurtured.”

-Malcolm Gladwell, The Tipping Point: How Little Things Can Make a Big Difference

Special Dedication

A community of practice (CoP) is a group of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly. DevOps Dojo CoP is a global, and diverse community of contributors from Microsoft to solve the hardest problems in DevOps, to accelerate DevOps Culture, and to make DevOps Real. The Dojo embraces a set of shared goals and establish a community based on mutual trust. All three factors (enough interested people, shared goals, and trust) are required. Open collaboration is about engineering economics, everyone benefits!

Reviewed By

• Steven Murawski Steven.Murawski@microsoft.com
• Zachary Deptawa zdeptawa@microsoft.com
• Kitty Chiu Kitty.Chiu@microsoft.com
• Dave McKinstry dmckinstry@github.com
• Dave Burnison daveburnisonms@github.com
• Harleen Kaur Harleen.Kaur@microsoft.com