lessons learned from five years in the dojo - part 1

Having helped organizations with Dojos for five years, we felt it was the right time to share what we’ve learned so far. In this series of blog posts, we want to offer you our “best tips” for starting your own Dojo or for improving your existing Dojo. We’ll wrap up with our thoughts on where Dojos are going next.

Without further ado…

Dojos Need to Support a Strategy

We talk with many organizations excited about starting a Dojo. The concept of teams learning new skills while building products is enticing and practical. Excitement is great, but Dojos work best when there is an overarching strategy the Dojos serve. Without a strategy, Dojos can flounder.

For example, an organization invested in moving from a project model to a product model would leverage that desired outcome as their strategy for the Dojo to support. The strategy frames the purpose for the Dojo. The Dojo is there to help teams understand how to work in a product model and learn the skills they don’t already have required to work in that model.

Another strategy we often see is leveraging Dojos to adopt DevOps. While this is more narrow than we recommend, it is still a nice frame for what purpose the Dojo is serving. (We prefer to see Dojos address as much of the product development value stream as possible. We’ll cover this in our next post in this series.) A “DevOps Dojo” would focus on helping teams learn how to build continuous delivery pipelines and automate infrastructure setup while foregoing other skills like product discovery practices.

A third example is using a Dojo to help the organization migrate applications to the cloud. This is an interesting start, but for the Dojo to truly be effective the strategy should be clear on how teams should migrate their applications. Will teams refactor applications for the cloud, move them in a “lift and shift” model, or follow a “re-platforming” model? If it’s a combination of those approaches, what are the criteria for determining which migration model for an individual application? And what is more important - having teams leave the Dojo with deep knowledge of the cloud or getting their applications into the cloud with sufficient knowledge of how to support them? Knowing the answer to these questions is critical if you want to use your Dojo to drive toward specific outcomes.

Starting from a sound strategy is key. It provides the following benefits:

• Teams understand the value of why they should participate in the Dojo

• The skills and topics taught in the Dojo are well-defined

• Growing coaches is easier because coaches can focus on specific skills

• Measuring the success and impact of the Dojo is easier since you can  measure outcomes against the strategy

The strategy your Dojo supports should be clear and easily stated. If the strategy is nebulous or complicated, your Dojo will struggle to provide value to the rest of the organization.

What strategy is your Dojo supporting?

Be on the lookout for our next topic in this series: why Dojos need to address the entire value stream.

Reflections & Learnings from Continuous Learning Event

Last week, we co-hosted an event with Mark Graban. We had the pleasure of spending two days with forty individuals focused on looking at continuous learning and improvement.

We previously posted on why we were excited about the event. Now that the event has passed, we wanted to share our "A-ha" moments.

Seeing and Hearing the Andon Cord

The Toyota Andon Cord is famous in the lean and agile communities. The Andon cord is a cord that anyone on the manufacturing line can pull to "stop the line" to correct a production problem. Two powerful realizations surprised us about the Andon cord. First, the frequency of the pulls was much higher than we expected. Second, the sound played when somebody pulls the cord is cheerful music! We were expecting a sound more like an alarm. The cheerful sound celebrates finding and fixing an issue before it becomes costly.

I compare this to what we commonly experience in software development. When we encounter an issue we tend to focus more on keeping delivery going and not on "stopping the line." (How many of you work with teams where the whole team stops current work to address a build failure?) We want to meet deadlines and don‘t discuss small friction in real time. The easiest time to fix this friction is when it's happening. What if we celebrated discovering issues earlier as a way of fostering continual improvement? Dojos focus on this through early single piece flow.

Suppliers on Site

We imagine the numbers are public since we were on a public tour of Toyota, but it was astonishing that of the workforce at the plant we visited, over half were from suppliers. Yes, they were there supplying (manufacturing and fixing) the parts that Toyota uses. Read that again. Over half of the workforce on site were suppliers. With this setup, parts are literally arriving "Just in Time." There is no risk of shipping delays from suppliers, no need for heavyweight logistical inventory management, and no need for constant negotiations over contracts devoid of the context of work in progress. And it makes Toyota have a beautiful symphony of construction.

In our world, how possible is it to have suppliers be part of our construction? The organizations we work with have an advantage over Toyota. Most times the  "suppliers" are employees. Yet we often confuse activity for progress. Everyone is moving as fast as they can. They must stay busy! This comes at the cost of delivering value. This is an easily solvable problem. Dojos help magnify this constraint.

Experimenting, Learning, and Safety

We also visited Garrison Brothers distillery to see how they apply continuous learning and improvement. We had a wonderful conversation with their head distiller. He shared stories of how they experiment with improving their product and develop new variations (including a honey infused bourbon).

He shared one example of a bourbon he wanted to make with a certain taste profile - his experiment. Guess what? It didn’t work. He had to tell the owner that a large batch ($50K in potential sales) wasn’t up to snuff and that it would have to be set aside to evaporate. Which they did. Because it was the right thing to do. They don't release products they are not proud of.

And they continue to experiment in an environment where it's safe to be wrong. Otherwise, they know they won't get better.

A beautiful story for a small distillery.

You Can't Teach Everything...and Shouldn't

Our group also asked the head distiller what he teaches the other distillers and what kind of consistency he expects from them in the distillation process.

His answer was more profound than our words will capture, but let us share the key thoughts.

He can teach the process - the ratios, the mixes, the times, the temperatures - but he can’t teach the taste. And he doesn’t want to because everyone’s pallet is different. Some character comes from the ‘white dog’ (raw whiskey), but the majority of the flavor comes from the aging process. He learns the characteristics of how the other distillers' bourbon ages. This knowledge can help him later on if he is blending barrels. But - he isn’t looking to change anyone’s taste - or teach them his taste.

That comment tied directly into the session that we led on Thursday around tacit vs explicit knowledge. (We'll explore this topic in more depth in an upcoming post.) Dojos acknowledge both types of knowledge and coaches work to foster knowledge creation both tacitly and explicitly. 

AND MANY MORE…

Both tours were great experiences. The attendees also shared their stories and knowledge. The topics were numerous - lack of stress even with low tak time, the visible enjoyment in work, lack of visible goals while still delivering quality with volunteers, differences between volunteering to work and being "driven" to work, respect for people… and so much more. And sharing the experience with the diverse group of attendees elevated the quality of the event.

If you joined us, please share some of your key learnings. If you missed out, we are already thinking about the next event that combines experiences with sharing and learning from each other. Stay tuned!

Mark’s Thoughts On The Event

Mark Graban also shared his thoughts of the event on his blog:

https://www.leanblog.org/2018/10/highlights-from-our-lean-event-tour-at-toyota/

Six Reasons Why We Do Two-and-a-Half-Day Sprints in the Dojo

When we’re explaining the Dojo model to people who are unfamiliar with it, we often get a lot of head nods and other indicators that show people understand the model. They see how it’s different from other approaches to learning. Sadly, most of us have had experience with inadequate training programs. Many of us have worked in organizations who’ve sent hundreds of people through certification courses only to find the desired outcome doesn’t stick or never materializes in the first place. For us, the Dojo model just “makes sense”.

One aspect of the model that does raise eyebrows is the two-and-a-half-day sprints. People often question – “Why two and a half days?”, “Isn’t that too short?”, and “What are the advantages of sprints that long?” (Some even go so far as to say “That can’t possibly work.”)

Here are six reasons why two-and-a-half-day sprints are effective in the Dojo.

1. Repetition Fosters Learning

At our current client, Dojo challenges are six weeks long. Setting the sprint length to two and a half days results in teams completing twelve sprints during their challenge. If we set the sprint length to be two weeks, a common sprint length, the team would only complete three sprints during their challenge.

The two-and-a-half-day sprint format is a vehicle for us to foster learning through repetition. Teams using Scrum, for example, are getting frequent practice with the four core Scrum events (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective). We’ve found that this interval of repetition helps the practices stick. Teams get better at them than they do if they practice them less frequently.

If a team is working on learning how to improve their CD pipeline, deliver microservices, or deploy to the cloud they also have opportunities for repetitive practice resulting from the two-and-a-half-day format.

Repetitive practice helps new learning stick.

2. Practice Getting to Done

Many of the teams we work with who are presumably already “doing agile” struggle with finishing stories by the end of the sprint. Often times Sprint Planning doesn’t produce a realistic plan, teams don’t allow enough time for testing, or they’re simply too optimistic about how much they can accomplish. All of these things contribute to teams carrying stories over stories from sprint to sprint.   

Ron Jeffries advocates for shorter sprints when teams are struggling to finish stories by the end of the sprint.

If you can’t get everything “done” (see above) at your current Sprint length, consider shortening your Sprint. If it’s two weeks, try one week. If you can’t get anything done in one week, try one day.

We’ve seen significant improvements in teams’ abilities to plan and execute a set of stories within a sprint over their six-week Dojo challenges. They come in acknowledging they often don’t complete stories every sprint and leave with the ability to “get to done” on a regular cadence. Often, it takes multiple sprints in the Dojo to make this change but we’ve got twelve opportunities to improve.

3. Teams (Finally) Learn How to Break Stories Down

“Instead of how big, we should be asking is it too big?” – David Hussman.

When it comes to planning sprints in the Dojo, we think it’s more valuable to ask “Can we get this story done in two and a half days?” than it is to ask “How big is this story?”.

Our friend, David Hussman, first got us moving away from focusing on “estimating” to focusing on “sizing”. Put another way, instead of a team getting bogged down in estimation meetings, the team focuses on breaking down stories until they can be done in two and a half days. For us, learning how to do this is significantly more important than learning how to get better at estimating.

Even when teams are delivering using Kanban, or they’re advocates of “no estimates” and use other techniques for predicting delivery timelines, breaking down stories so they can be delivered incrementally is an essential skill.

(For approaches to breaking down stories see this post.)

4. Learning is Supported by a Margin of Safety

There’s a lot of buzz these days about providing safe environments for teams to fail. Modern Agile holds safety as one of its core tenets. DevOps culture teaches us that when we have a problem with our systems we shouldn’t blame individuals, but instead look at the system itself.

Too often, teams are asked to learn while delivering. The message is clear – you have to learn agile/lean methods, or new technology, or new engineering practices – but it can’t impact the delivery timeline. Sadly, this often happens while delivering important or even mission-critical products. This is hardly an environment conducive to learning.

Failure is critical for learning. We learn from our failures and the stories that get created and retold about those failures. Do you remember any stories off the top of your head about a system that was designed so well there were never any outages? You might, but we’re guessing you know a lot more stories about system failures, what caused those outages, and what you learned from them.

In the Dojo, it’s critical to have an environment where failure is not only tolerated but where failure is understood to be a natural part of the cycle of knowledge creation. Without an opportunity for failure, learning becomes stifled. As part of the onboarding process we make sure stakeholders understand that delivery will slow down somewhat to make space for small failures and to make the Dojo a safe place for learning.

Small failures are the key. The two-and-a-half-day sprints provide a safe environment for learning. Failures at any level, whether they are product or technology related, can be corrected quickly. An investment of two-and-a-half-days is usually not very costly to the team.

At the same time, we want to provide opportunities for feedback, reflection on the part of the learner, and immersion back in the work in a timely manner in an environment where the learner feels safe. Two-and-a-half-day sprints help create this feeling of safety.

5. Frequent Retrospectives Lead to the Proper Mindset

Another common problem we run into with teams is they’ve stopped doing retrospectives and as a result have stopped focusing on continuous improvement. When we ask them why we’re told the retrospectives don’t have any value because they keep repeating the same problems over and over.

In these cases, we ask the teams to resume doing retrospectives for the duration of their Dojo challenge. During the retrospective, we ask the team to pick one item to work on improving over the next two-and-a-half days. In cases where the team identifies impediments that are largely beyond their control we ask them to focus on making one improvement within their control.

Sometimes the same idea for improvement will be carried over and continues to be worked on from one sprint to the next. But our experience in the Dojo has been that teams adopt a mindset of continuous improvement more easily than when they’re working within a two-week sprint cadence. The frequency of inspection and coming up with ideas for improvement helps the principle of continuous improvement stick.

We’re not saying every team should adopt retrospectives more frequently than on two-week sprint boundaries. What we are saying is that establishing the mindset is what’s important here.

6. There are More Opportunities to Ask “What is the next best investment in learning?”

An essential skill for Dojo coaches is knowing when to play the role of teacher and when to play the role of a guide who reflects behavior and ideas back to the team. The two-and-a-half-day sprint format provides a natural cadence to move back and forth between those roles.

One question we frequently pose to teams during Sprint Planning is “What’s our next best investment in learning?” The answers vary depending on the teams’ unique challenge goals.

In some cases, teams are focused on learning design thinking and product discovery so the discussion could be about coming up with ways to test a hypothesis about our product. Or, the discussion could be about pivoting to a new product idea entirely.

Other teams might have challenges focused more on learning new technology or engineering practices. For those teams the discussion might center around what stories to complete that will foster the desired learning.

Again, the frequency of stopping to reflect on this question every two and a half days fosters a mindset of thinking about product development and learning as a series of investments.

The six reasons are related and reinforce each other. Together, they help create an environment that supports learning and knowledge creation.

If you have experience with two-and-a-half-day sprints or if you have questions about running two-and-a-half-day sprints we’d love to hear from you.

Six Dimensions for Decomposing Stories

Many teams struggle to break down stories to a size that can be completed within a sprint. Perhaps the product needs seem too large, or the technical debt is too deep. There could be a high degree of uncertainty around what the product should be. Or, the team might be new to the domain. Regardless of the reason, here are a few ways we tackle this in the dojo - and given that we generally do two-and-a-half-day sprints in the Dojo it’s critical that teams develop this skill.

Here are six dimensions to think about when decomposing stories.

CONTEXT

Many teams lack big picture understanding for products they build. Instead of having deep knowledge of the problem they are trying to solve, they are equipped only with a backlog of things to do. In these situations, it’s difficult to find meaningful decompositions of the work. Take a simple example - a need to filter a search result. Without context of how customers actually use the product, teams resort to building filtering capabilities for every element in the search result. Even if they have ideas around building filtering incrementally it’s hard for them to make decisions on what to build first without product context.

In the dojo, we focus on building product context for teams - not just around what they are building, but also why they are building it and who they are building it for. We use product chartering, personas, and story maps to ensure everyone has a shared understanding of the problem space. Teams are able to break down stories more easily when they have product context. Back to the search example – when teams have product context they’re able to say “this filter is important in the context of the search we’re implementing for this persona right now.”

COMPLEXITY

Products can be complicated to build. Some products require integrations with large datasets or other systems that have less than ideal APIs or interfaces. Or, an innovative product idea that could make a user's life better may be very complex to implement.

Development efforts like this naturally take time. They are ripe for errors when estimating the work effort because there are so many unknowns. Knowledge is created quickly in these spaces as a result of all the learning that occurs during development. It’s difficult to estimate the effort and time required for this learning.

When working with teams in the dojo on these types of problems we look for paths of increasing complexity. We start with simple, obvious cases. Sometimes teams will push back and insist we’re starting too simply. (We often hear a similar objection when teaching test-driven development and we’re giving guidance on creating the first test.) Teams often over-estimate their ability to handle complexity.

For that great search feature, we will start with a direct match before we work towards more complex criteria. Later, after we have learned more about the tech and the product, the team might graduate to working on fuzzy logic.

Teams learn as they go and move gradually into more and more complex scenarios.

EXAMPLES

Using examples is our favorite technique and quite possibly the simplest. It’s sort of “Team Test-Driven Product Development”. Teams could even call it building against test cases.

When a team encounters a large story in the dojo we have them talk about the story before trying to break it down. We ask them to come up with examples of what the product would look like if the story was completed - both positive (working) and negative (failure or error) examples. From there, the team chooses an example that is interesting to them. We encourage teams to choose an example that will help them learn something by asking open-ended questions such as - Will this example help us learn about integrations or some aspect of the technology stack? Will it help us validate a product idea? Will it help us improve the way we work (e.g., will it force us to implement new automation techniques in the testing space)?

Using examples is a nice, easy way to frame discussions that helps teams make progress on decomposing stories.

STUBS

Many teams in the dojo are building products that are dependent on outside influences - other teams, external APIs, or other products. Often these external dependencies influence teams into thinking one or more of their stories cannot be decomposed, and even worse – delivering their product is outside of their control.

When this happens, we talk about expected behaviors and contracts for tests. What do we expect the dependencies to return in each of the examples? How should the product behave? We help the team learn how to isolate their product in a way that enables testing and allows the team to make progress delivering. For legacy code, or systems where it’s difficult to drop in stubs or mock data, we have teams use tools like WireMock to provide some of this isolation and control.

But it all starts with that conversation around expectations and behaviors.

Be careful with this approach. Teams can get “isolation happy” and eventually find themselves actually deferring product integrations - which is a bad thing that can easily lead to over-accumulating work in progress.

SPIKES

Teams are sometimes working in unchartered waters. This could take on the form of new technology, unfamiliar legacy code bases, or learning something new like cloud technologies or microservices.

In these situations, teams sometimes fall into the trap of over-researching. When trying to deploy to the cloud for the first time, teams may read documentation and blogs, watch videos, and go through training materials for weeks to understand all of the options with the hope of “doing it right the first time.”

“Spiking” on stories is a common technique teams have been using for years. Again – there are traps and pitfalls. The worse being spikes with no clear end-game, even when they’re time-boxed. For example, when would a spike around “Learn how to deploy to the cloud” be finished?

In the dojo, we frame spikes contextually around answering a question. Instead of creating a spike to “learn cloud deployment” we might ask “can we move an already built jar file from Artifactory to an AWS EC2 instance?” By phrasing it as a specific question, the spike has focus and context and becomes a nice starting place for sharing learnings and demoing results.

INVESTMENT

There are times when teams try all of the above and still struggle to decompose a story to a size they can complete within a sprint. They have context, they have broken it down across a test boundary with good isolation, and so on. But the work is still “too big”.

Another approach we’ll use is to have teams talk about the investment required to complete that part of the product. We start with simple questions - How much would be too much to invest in this? How do we know? Similarly, after we have finished a story, we often ask the teams if they’ve learned anything that causes them to question the value in continuing the work. Should we keep investing in this line of product development? Should we pivot? If the overall product direction is still valid - Have we learned anything that might help us think of a different route for delivering the product?

The above approaches have worked for us, what has worked for you?