Our coaching philosophy is to make the learning experience as immersive as possible. Below, I’ll explain what I mean -- and why immersive learning is so critically important.
Types of Product Team Dojos
Before I talk about the importance of making Dojos an immersive experience, I’ll first introduce you to different types of Dojos. Typical Dojo offerings include the following:
Challenges, immersive, 6-week Dojo/DevOps experiences where teams participate in a broad scope of activities and work on their products.
FlashBuilds, short-term, immersive experiences focused on specific outcomes.
Leadership, short-term experiences that help leaders learn about Dojos.
Workshops, learning opportunities attended by individual team members.
These immersive, 6-week Dojo experiences result in a foundational and holistic transformation of a team’s practices and ways of working. A full-stack team enters the Dojo with their own backlog. The entire team should participate, including the product owner, engineers, scrum masters, and designers (if the product is customer facing). As part of these extended-duration activities, the team runs in hyper sprints (typically two and a half days each). At the end of the challenge, the team, including the team’s broader leadership and stakeholder group, celebrates what they accomplished during their Dojo experience.
FlashBuilds are designed for teams trying to solve a very specific technical practice problem, such as establishing a CI/CD pipeline, applying a development or testing framework, improving code quality, or configuring cloud or container-based services. FlashBuilds typically last anywhere from two days to two weeks. Expert coaches work alongside dedicated teams to co-create the solution, transferring knowledge throughout the process. Given the short duration, the Dojo is focused less on holistic and cultural change than on sharing ongoing practices for how teams should work on specific new technologies.
These immersive experiences typically last no more than a couple days, blending lightweight, hands-on experiences with lectures on the core concepts and practices that the leaders’ teams are adopting. In these sessions, leaders don’t build full-stack products; instead, the sessions are designed to help leaders understand what happens in a Dojo, to demonstrate why leaders should encourage their teams to participate in a Dojo and how to support their success.
Educational workshops are designed to offer education and exposure to select engineers on specific practices and tools and typically last a few hours to 2 days. Examples include events focused on running in the cloud efficiently, leveraging Kubernetes, fortifying code, developing test-driven code, etc.
Now let’s talk about what an immersive Dojo experience looks like and why it’s so important.
For starters, “immersive” is an experiential style of engaging the team at as many levels as possible to facilitate DevOps learning. These levels include the following: visual, verbal, physical (kinesthetic), logical, and social.
In an immersive Dojo environment, solitary work is discouraged, team collaboration increases, and distractions are limited. Learning retention and the overall success of a Dojo increase when the experience incorporates work on relevant, real-world products.
The best learning and growth happen only when people apply new skills to their product backlog and are able to break past existing organizational constraints.
One or more coaches are completely embedded with the team in the Dojo in order to provide support and sometimes show the team how the work should be done. Coaches should lead from behind, as well as lead by example wherever necessary.
Daily coach sync occurs prior to the Dojo start each day. During each coach sync, coaches plan out the team’s activities using sprint planning and standups to ensure content and activities are delivering on outcomes. Coaches are “at the table,” meaning that they encourage the team to share, listen to the team, ask strategic questions about why/how/what they coded or tested, observe activities, learn each team member’s strengths and weaknesses from ideation to releases, and provide ongoing support. Coaches also support all product activities, holding 1:1s with the scrum master/product owner to learn more about team challenges, morale, and other team dynamics that will aid in delivering outcomes.
Product Team Dojos - Coaching Strategies
Coaches are for all intents and purposes members of the team. It’s their job to teach the team strategies for solving their problems, help them build skills that they can apply outside of the Dojo, and help them recognize their wins, both big and small. In addition, coaches join in sprints, retros (where multiple teams come together to share developments, learning, and improvement opportunities), ceremonies, and demos and offer timely, helpful advice and encouragement to motivate the team to transform their habits and think in a way that accelerates and improves their development of quality code.
Furthermore, coaches keep records of team goals and outcomes, a daily log of observations, team photos, and team artifacts that can be shared with other coaches to help them achieve similar outcomes.
Key Factors That Contribute to the Success of Product Team Dojos
Coaches often need support from platform engineers and also need to help to solve technical challenges that the team is working on to move code, or a product forward. Coaches often split their time, with one coach remaining with the Dojo team at all times and the other coach helping to clear obstacles and prepare the team for success. We highly recommend that the coach partner with the platform teams to work on identified platform issues. Doing so helps Dojo coaches learn the process and work involved in achieving specific outcomes, as well as helps Dojo coaches gain a deeper knowledge of DevOps tools and processes and learn strategies for engaging the DevOps community.
Chartering helps the team align on Dojo goals, outcomes, and expectations regarding working norms. It also deepens the team’s understanding of their product and application architecture. With the help of Dojo coaches, the team first develops goals, outcomes, and expectations and then focuses on accomplishing those outcomes while working on their real-world product/services in the Dojo.
Chartering sessions usually take 3-5 hours and are done prior to entering the Dojo. (Look for a future post on Chartering and other pre-work needed for the Dojo.)
Space planning involves organizing the Dojo space to facilitate desired outcomes for the day or week. As teams transition in and out of the Dojo, it is imperative for teams to learn how to use their current and planned future spaces to continue to collaborate and foster teamwork at all times. Since teams often go back to distributed spaces that are not like the Dojo, it is important to provide guidance and practice on how they can stay connected and achieve project goals while working in different locations and dev spaces.
Immersive Product Team Dojos Build Highly Effective Teams
The 6 weeks that a product team spends in a Challenge Dojo are laced with rich interactions and experiences, including chartering, unlearning, and relearning foundational principles like Agile, development practices, testing paradigms, automation-first delivery patterns, and ownership of the product from ideation to production. An immersive team environment is key.
In future posts, we’ll share more details about how Dojos work and how to make sure they set DevOps teams up for success. Until then, reach out if you’d like to learn more!
Liatrio is a collaborative, end-to-end Enterprise Delivery Acceleration consulting firm that helps enterprises transform the way they work. We work as boots-on-the-ground change agents, helping our clients improve their development practices, react more quickly to market shifts, and get better at delivering value from conception to deployment.
Ready to Accelerate Delivery and Transform Your Organization?