Fulfilling the Need for Continuous Improvement with DevOps Dojos

How to Adopt the “Third Way” in the Dojo’s Method to Master CD

In The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations the authors describe “The Three Ways” – the underlying principles forming the basis for all DevOps practices. 

The Third Way is about creating a culture of continuous learning and experimentation, with an emphasis on practice and repetition as the path to mastery.

The idea that organizations must focus on continuous learning is not new. Peter Senge popularized the idea of the learning organization in his book The Fifth Discipline. Ikujiro Nonaka, the author of The New New Product Development Game (a foundation for the Scrum methodology), wrote on how successful companies leverage a culture of ongoing knowledge creation to create successful products and services. And the principle of Kaizen (“good change”), an integral part of the Toyota Production System, has its roots in the philosophy of Dr. W. Edwards Deming.

The question is: How do you create this culture of continuous learning and experimentation?

Typically, organizations approach learning by offering training in the form of courses and workshops. Courses can be beneficial but generally only apply to one skill area, are targeted at individual learning, and exercises are done in sandbox environments where learners never have to contend with real-world constraints. Concepts are difficult to apply after the course is over. The learning doesn’t stick and doesn’t lead to long-lasting change.

Additionally, training is a special, planned event. Employees are often restricted to a limited number of courses each year. The majority of the time is business as usual. This doesn’t exactly add up to a culture of continuous learning and experimentation. The question remains – how can today’s organizations achieve The Third Way?

Enter The Dojo

Credited with helping Target adopt Agile and DevOps, the Dojo concept is being implemented by organizations across a variety of domains including retail, telecommunications, finance, insurance, mass media, and travel.

So – what is the Dojo?

The Dojo is a physical space where whole product teams come together to undergo an immersive learning experience. The Dojo originated with a focus on DevOps but quickly expanded to include Agile/Lean, cloud architecture, microservices, security, and product discovery. Teams improve skills in these areas while building their products. All learning is done in the context of real-world work, with real, everyday constraints.

The idea that organizations must focus on continuous learning is not new. Peter Senge popularized the idea of the learning organization in his book The Fifth Discipline. Ikujiro Nonaka, the author of The New New Product Development Game (a foundation for the Scrum methodology), wrote on how successful companies leverage a culture of ongoing knowledge creation to create successful products and services. And the principle of Kaizen (“good change”), an integral part of the Toyota Production System, has its roots in the philosophy of Dr. W. Edwards Deming.

How Does It Work?

Dojos start with a lightweight intake process. During intake we work with teams to set them up for having a successful Dojo experience by helping them create full-stack teams, working with their leaders to ensure the team has time and support for learning and aligning the team’s learning goals with the product work they want to focus on in the Dojo.

Once this frame is established, a team then starts their Dojo experience. A typical Dojo experience format is six weeks in total duration, eight hours per day, with two sprints per week. Sprints are kept intentionally short to provide these advantages:

  • The opportunity for repetition when learning new concepts
  • Teams focus on breaking work down into small increments rather than getting bogged down estimating stories
  • Teams learn to focus on finishing and validating work
  • The cost of being wrong – emotionally and financially – drops significantly. It’s easy to recover from a “failure” after a two-and-a-half-day sprint.

A Dojo coach guides the team through their experience. Initially, the coach takes on the roles of teacher and guide as the team begins to understand and apply new practices. The coach then moves into a partnering role while the team starts finding their own way. Ultimately, the coach becomes a “reflector” and supports the team’s learning and experimentation efforts.

This last shift in coaching is critical. A Dojo experience is successful when the team learns how to incorporate continuous learning and experimentation into the way they work – i.e., they adopt The Third Way. Otherwise, the experience could just become another typical training event.

Sample Learning Teams Could Experience

Another significant difference between Dojo experiences and typical training events is that the Dojo is not organized around a specific curriculum. Dojos are staffed with coaches having various skills who can meet the team where they are. A typical Dojo experience usually involves work on the team’s continuous delivery pipeline. For some teams, additional learnings might be focused on microservice and API design while other teams focus more on improving automated testing or product discovery capabilities.

In addition, teams coming into the Dojo are encouraged to look at their entire product development value stream. Some of the most powerful “a-ha” moments have come when product communities see how CD pipelines aren’t just a means of automating manual build and deploy tasks but are a tool that enables quick testing and validation of product ideas.

There’s a significant benefit to having teams learn practices together. They see how various practices feed and support each other in a way that doesn’t happen in short courses focused on one practice.

Two examples (refer to diagrams below) of what teams work on in the first two weeks of their Dojo experiences are shown above. While the learning topics are different the format and focus on learning and experimentation are the same.

Starting Your Own

You don’t have to invest in a ten-thousand-square-foot space and staffing that can handle ten teams at once to start a Dojo. You can start small. Find a space where a team can work that gets them out of their normal working environment. Start with one team and a small group of coaches. Identify the learnings you want to invest in with the team and run your own experiment. Invest in your own continuous learning and experimentation.

Joel Tosi
Joel Tosi focuses on helping organizations create learning environments where teams can create interesting products, not just features. Starting with Target and helping other organizations since, Joel has been leveraging Dojos as a way to uncover what is holding back organizations and teams. Having spent many years working deep in technology as well as coaching teams, Joel believes in the dojo approach as it has not only helped teams adopt and grow new skills but Dojos have helped organizations improve.

The Related Post

DevOps for Test Teams By Michael Hackett Now that Dev Teams have had a little time to settle into the Agile, the new wave of process optimization has arrived. DevOps. DevOps has been described as Agile on Steroids. DevOps has also been described as Agile for Operations/IT. I like both of those descriptions as well ...
…On what you need to know before making the transition to EaaS 1. What are the main differences between cloud-based environments and cloud infrastructure? An environment is a collection of infrastructure elements working in conjunction to enable an application stack to work. For example, a simple 3-tier application, with a web front-end component, a business logic ...
By Jez Humble and David Farley Continuous Delivery from Jez Humble and David Farley is an important contribution to the field of software development. It takes continuous integration to the logical conclusion and covers how to set up a continuous integration system, delving into everything from check-in to delivery to production. It doesn’t state you ...
A test team’s job is to report test results, not set or guarantee that you will meet the SLAs. In the rush to cloud services, with everything-as-a-service, you will hear people talking about SLAs. What is this about and what does it have to do with testing? A Service Level Agreement, or SLA, is a ...
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, ...
In this article, I share some of my experiences and observations on training teams, mainly in corporate settings. The operative word here is “team”, not “individual”. When training teams or groups in an organization, many of the considerations and benefits are different than those for the individual. We’ll examine those differences and I will share successful solutions. ...
Over the years we’ve provided an extensive number of articles, videos, and infographics that provide a wealth of knowledge about Continuous Delivery.
LogiGear Magazine – February 2013 – The Rapidly Changing Software Testing Landscape
Fitting QA into a modern DevOps group In a traditional software engineering organization, the QA group is often seen as separate from the Development group. Developers and testers have different roles, different responsibilities, different job descriptions, and different management. They are two distinct entities. However, for folks outside the engineering team – say in Operations ...
As a software development company, what is your goal? What is the one thing you feel you need to do to ensure you have a job at the beginning of each wonderful work week? The answer is actually quite simple; You need to deliver a quality product. Like how I used the word simple? Although the answer I ...
    Eric Minick is internationally recognized as a leading authority on continuous delivery and DevOps. Eric joined IBM four years ago with the acquisition of UrbanCode where he had worked as a developer, technical seller, and evangelist for a decade. Today, he has responsibility for leading the product management team overseeing continuous delivery solutions ...
Run your TestArchitect API and headless browser tests inside Docker containers as easy as flipping a switch Docker is a virtualization platform enabling you to create containers – mini virtual machines— which have their own predefined environment, including file system, libraries and settings. Best of all, these light-weight images eat up only a few megabytes ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe