Coaching as a Skill

Coaching, as a role in agile, has gotten a bit watered down in my opinion. People are entering the workforce with the title of coach. Coaching is a full career path. This was never the intent!

I'm from the school of practical experience: in order to coach a thing, you must first be able to do that thing.  Effective coaches bring both knowledge and experience to their practice. They are equally confident in teaching and facilitation as they are jumping into a new team and working hands-on. 

People with experience – with success and failure stories, practical knowledge of building capability within past teams, and good pattern recognition to help them recognize what a team needs and when – have the best chance of success in a coaching engagement, dojo or otherwise.

Given these biases, I see coaching as a skillset over a role. Let’s talk dojo for a minute. Dojo coaches combine coaching chops, particularly within the constraints of the dojo, with other skills in product development, engineering, lean/agile workflow, DevOps, et al. Not only have they actually done what they're teaching and coaching, walking the walk, they know how to help others find success. Good dojo coaches are both experienced and socially capable. In this sense, a dojo coach is much like a team-oriented lead or senior staff member. They've had success in an area, and now they enjoy helping others to do the same. Spreading knowledge and capability to others is a common motivation for a dojo coach.

First: Define Coaching

I have a simple definition of coaching I use in Dojo Academy. A coach is anyone who helps a team or individual set, refine, and achieve their goals. They transmit their experience using storytelling to earn credibility and relate with the people they’re working with. They have skills and knowledge to transfer and use methods such as teaching, facilitation, and hands-on playing. Success for a coach means working your way out of a job; the team is proficient in the area you were coaching. They don’t need you anymore.

Problem: An Over-reliance on Professional Coaches from the Outside

I’ve been a part of numerous large-scale transformation initiatives, and there simply aren’t enough coaches to go around. You can’t hire 100-150 good coaches in a reasonable time period (or ever). Coaching won’t scale with a “hire all the coaches in the world” strategy. 

Most of the transformations I’ve been a part of have sourced coaches from third-party vendors, at least in part. While these individuals may (sometimes) be quick and adaptable, they usually lack knowledge around the firm’s culture, politics, systems, or other norms. A dojo helps level some of that by bringing teams to the coaches, but even the most venerable coach will be operating with a lot of ambiguity as they seek to adapt their knowledge to a team’s context.

I’m in no way arguing that coaching is a bad idea. I’ve seen coaching do a lot of good firsthand. People will lead transformation, always. That said, we can employ a few strategies when building coaching teams for our transformations and dojos.

Solution: Build Coaching Capability Internally

In their HBR article “The Leader as Coach”, Herminia Ibarra and Anne Scoular describe a trend toward building coaching skills within a company’s leadership and employees: 

“...we’ve noticed that more and more of the companies we work with are investing in training their leaders as coaches. Increasingly, coaching is becoming integral to the fabric of a learning culture—a skill that good managers at all levels need to develop and deploy.”

This is a strategy we’re employing with our more recent dojos. Rather than try and find a small army of engineering, product, and agility coaches from the outside, we find influential and talented people within the firm. We are literally growing coaches. The first step of this journey starts with our “Ready to Coach: Mentor-guided Cohort” in which we bring the coaching team together and, over the course of five weeks, cover dojo essentials and our proven playbook for guiding challenges. Candidate coaches then go into a months-long period of mentorship and support where we employ a “shadow-pair-do” model in getting coaches productive, comfortable, and running at a sustainable pace in their dojo.

Imagine a scenario where the career path of your senior engineers involved a rotation of coaching in the dojo – between 6 and 9 months. That’s a good chunk of time to develop a career-lasting set of social skills that complement an individual’s more technical or area-specific competencies.

So what about professional coaches? Do we not need them anymore? Not quite. Professional coaches – be they contractors or FTE roles in your organization – continue to have an important role in this strategy. I employ professional coach-consultants in our dojos as originators and mentors. These folks often operate as exemplar coaches and mentors for candidate coaches from within the firm, helping to define the coaching role for their area of expertise. Senior coaches also have a lot of input into the co-creation and evolution of the dojo program itself. I look at these folks as “force multipliers” – coaches who coach, well, coaches!

Coaching as aN ORGANIZATIONAL CAPABILITY

We set the expectation with our clients that dojos are 3-5 year investments. Dojos are all about building a learning culture within your organization. Unfortunately, those efforts won’t sustain when coaching isn’t an embedded skillset with leaders at all levels within an organization. If your transformation has a dependency on outside coaching, what happens when those coaches leave or costs stack up too high? Your dojo needs to guide teams in their challenge, sure, but it also needs to create a pervasive, expanding coaching skillset as the cornerstone of your burgeoning learning culture.

When I’m coaching a challenge, I seek to enroll members of the team in the coaching activity. “You know something about how continuous delivery works here. Can you show the rest of the team?” 

We can transfer the coaching skill in small ways like this, sure, but I’m arguing for a more systemic approach to building strong coaching skills in the product, technical, and workflow leads going through challenges. Mentor the promising individuals in your organization to coach challenges and teams themselves! Coaching skills embedded in these individuals travel with the team when they leave the dojo and increase the population capable of tending and growing a true learning culture.

Culture, Creativity and Collaboration

Alexandra West visits her alma mater, Emory University, as a guest on the Eagle Eye Podcast. In this episode of the Creative Spark series, Alex discusses her career in the arts, building a great team, and the importance of “just being nice.” Listen to the episode here.

Beats in the Dojo Loop: Reflect (4 of 4)

This is the final part of a series on how iterations work in a dojo challenge. See Part 1: Plan, Part 2: Do, Part 3: Share for the whole story.

We've planned, we've collaborated in doing, and we've shared our learnings. Now it's time to take stock of the last 2.5 days, our experience as a whole, and direct insight, feedback, and action toward the next iteration.

Reflections are an opinionated take on the agile retrospective. Word choice is intentional here. Reflections bounce and are changed by the service they bounce off of. We gather facts,  data, feelings, and impressions to feed forward into planning. It's a loop. Our past experience helps us pivot and refocus our future focus.

Coaches often use their favorite retrospective formats in a dojo reflection. A good starting point is the classic "Good, Meh, Bad." I like to mix up the format and purpose depending on where the team is in their challenge and what they're trying to learn.

Team Health Checks

Consider running a team health check. You can use the Spotify squad health check tool, where you gather data for a short period across a number of team health dimensions (fun, easy to release, health of codebase, delivery of value, speed, learning, etc.), or you can run it as a one-off, asking about the hyper-sprint you just completed. Interpret this data, look for trends, invite conversation, and make some changes to address the hotspots. I think one or two of these in a 6-week challenge is plenty.

Backing Off

New coaches tend to take the weight of the world on their shoulders by doing everything for the team. Facilitation Bot 3000. One small gesture is to invite a member of the team to facilitate retrospectives. Say your team has a scrum master on it, they'll likely welcome the chance to run their favorite retro format or collaborate with you on a new one!

The Product Feedback Retro

One one challenge team I was coaching we found our share events were becoming very popular. At first there were a dozen people. That doubled and then tripled. Then an oddball VP started showing up. This made sense; it was a platform team with high visibility working toward a big impact. These retros were chock full of feedback, feedback we wanted to capture and incorporate into our plan.

This retro requires a bit of planning. You have to ensure you're capturing the notes people give you because you'll need that data to process after the share, in reflection. I recommend you have a few scribes and you coach the team to not negotiate in the reflection, instead thank participants for their feedback, note it, and move on.

Processing product feedback from a share in the reflection stage of a hyper-sprint.

When you get back to your team challenge area, it's time to process the feedback. I use a grid similar to the above image. What conflicted or confirmed our plans? What confirmed a hunch or something that was speculative? Was there any feedback we found confusing, maybe something to follow up on?

Review the Skills Inventory

Toward the end of the challenge, I like to review the skills inventory we created in the team's charter. I ask people to circle or highlight the skills where they feel they've leveled up in some way.

The Charter Check-in

At the mid-point of the team’s challenge, it’s good practice to check in on the teams charter, specifically their goals and success measures. This helps align the team to their original mission or tighten focus on what they’ve discovered to actually matter as they’ve progressed on their learning journey.

Go through each goal and ask the team:

1. Is this objective still important to us? Have we discovered something that could help us refine this objective? Is there something more important to learn or do?

2. Which Key Results have we attained? Which seem unobtainable within our 4-week challenge? Is there something better we could use as a Key Result?

Be sure to update the team’s frame based on this discussion. Sometimes this discussion will yield worthwhile work for planning in the next or subsequent sprints, so be sure to capture those items.

Continous Retrospective

Reflection needn't be a scheduled activity. Any time any subset of the team wants to reflect and pivot, they should. Continuous micro-retrospectives should be encouraged. Getting metacognitive about what we're doing when we're doing it is a powerful, social learning technique.

Fun-Done-Learn - micro-retrospective after a mobbing session.

One example of this comes after a session (several rotations) of mob programming. I learned a nice format called "Fun Done Learn" from the Mob Mentality dudes, Austin Chadwick and Chris Lucian. They take a brief pause after a mobbing session to where the team takes stock on what was fun, what did we learn, and what did we get done? “That mini-experiment we did was fun, let's do more of that!” It may surprise you what your teammates learned or we discovered as a group. And completion keeps us focused on the mission at hand. It also feels nice to acknowledge our progress.

Retrospect anytime you need to. Go ahead and pull that andon cord when a retrospective seems necessary.

Beats in the Dojo Loop: Share (3 of 4)

This is part three of a series on how iterations work in a dojo challenge. See Part 1: Plan, Part 2: Do, Part 3: Share (this post), and Part 4: Reflect for the whole story.

After planning our work, spending most of the time doing our work – low and slow, metacognitively focused on how we're approaching problems in a new way – it's time to share! And we share more than just the output of our hyper-sprint, we share our learnings and direction.

Sharing is a short session, usually 30 minutes, where the dojo challenge team gathers their stakeholders – customers, financiers, leadership (technical, product, business) – to share what they've done, what they've learned, and where they are headed. If this sounds like a Scrum demo, then you're partly right. Partly.

The team will walk through "potentially shippable" or, better, already delivered functionality of their software, much as in a classic agile demo. Leaving it at this tends to create an atmosphere of "feature theater," at worst reinforcing output/scope-driven/deadline culture.

The chicken to delivery's egg is some form of light storytelling around what product theories and knowledge shook out from the current hyper-sprint's discovery activities. The best stories embed insights and artifacts in a lucid narrative. These facts may include customer journeys, research, user test results, interview results, and prototypes of various fidelity.

Storytelling is a part of the design thinking process. It helps align stakeholders to the vision held by the product team and primes more productive and advanced communication. Neil Stevenson, Executive Portfolio Director at IDEO, describes an occasion where storytelling helped collaborators and stakeholders imagine an experience:

For the last project, the client and the IDEO team created a fully immersive story-based experience. They prototyped a truck, had projections on the walls, actors reading a script, and audio effects generating a sense of weather.

This experience brought together a disparate client group of designers, engineers, and marketers and the previously siloed departments started communicating in a new way. By telling this immersive story, the team found a way to elevate the work above what was initially perceived as affecting only certain groups within the company. People would say, that’s a piece of engineering and applies to my department, or, that’s a piece of marketing and applies to their department. The story managed to raise everybody up to have a conversation about the overall experience.

Now that's a lot. Prototype a truck?! Stoping well short of pyrotechnics, we often have other things that can guide our larger product community on to a sense of the journey we're taking toward a particular product vision. We share story maps, customer/user journeys, sketches or high fidelity prototypes, which personas we're targeting, data we've analyzed... the list goes on. As a coach, I like to work with the team to embed these artifacts into that lucid narrative I mentioned earlier.

This brings up an interesting point; sharing is a venue where team members get to practice important business and social skills. You have to write the story and present it in front of a small audience after all.

We share deliveries and discoveries alike. We also share learnings around team building and the new skills its individuals are building. Don't showcase features. Do showcase the team's growth. How did you apply feedback from previous sharing events Demonstrate iteration!

When the team is done sharing, it's time to collect feedback. I am pretty insistent that the team be given the chance to present their learnings, discoveries, and output before we receive any executive notes. On the team side, I ask that they not make any commitments around scope or direction in that sharing meeting. We're trying to build fully autonomous product teams and it's important they begin shot-calling with data versus committing to single influential people higher up on the org chart.

Effective Challenge Shares

A few tips and tricks to getting the most out of this session:

1. Prepare, prepare, prepare. Prepare the team going into a sharing event. What are we presenting and in what order? Are we presenting in a natural order or are there jarring non-sequiturs in the way we're stacking the news? What might we present from discovery alongside delivery? How much time do we need to present each topic? Who should present or co-present this? Who hasn't presented in a while (or ever)?

2. Setup the etiquette of the share. When the team is gathered with its stakeholders, remind them of the "no commitments" rule I described above. I find a perfectly acceptable answer is, "thank you for your feedback." I encourage teams to only ask clarifying questions. Debate, negotiation, and unilateral commitment are to be avoided. The team has a planning session coming up in an hour or so where they can consider the feedback they were offered.

3. Take notes, relentlessly. Speaking of feedback, you need a way of collecting the comments, suggestions, praise, and questions that were raised in the sharing session. Rather than appoint a single "scribe," have everyone on the team capture the feedback that stands out to them. Chances are there will be multiple interpretations of any feedback item and those interpretations can sometimes lead to interesting conversations that end up mattering.

In my next post, I'll share how I like to reflect on this feedback and pivot our plans based this feedback. Remember: hyper-sprints are a loop. The most productive hyper-sprint creates a feedback loop that influences our decision making, behavior & choices, and clarity on our target outcomes.

Beats in the DevOps Dojo Loop: Do (2 of 4)

This is part two of a series on how iterations work in a dojo challenge. See Part 1: Plan, Part 2: Do (this post), Part 3: Share, and Part 4: Reflect for the whole story.

Planning was over and it was mercifully short and maximally productive. Now it's time to get to work. It's time to let your action bias run rampant.

When I think of a dojo challenge, I think of an action bias. Working, in the beginning, very consciously, slow and low. Why are we doing the things we're doing? Coaches that show way more than they tell. May I show you what's worked well for me in the past?

The majority of our time in a dojo challenge is spent doing real work. That is a team working to frame actual problems and solve those problems with some new tactics we're learning. Given a product team that does it all (you conceive it, you build it, you own it), that can mean a wide variety of things:

• Product stuff: Framing a new problem for innovation. Doing research on customers or competitors. Envisioning a customer's journey through an experience that involves your apps and services. Prototyping and sketching new user experiences. Mapping a proposed feature in the landscape of the user's workflow and environment.

• Software Engineering stuff: approach design in a new way, perhaps test-driven. Refactoring mercilessly, without guilt. Creating more maneuverability in heavily coupled, legacy code.

• Cloud stuff: onboarding a team to a new PaaS or set of services on AWS, Azure, Google Cloud, etc. Getting the team familiar with new cloud-friendly architectures: containerization, lambda functions, etc.

• DevOps stuff: building or evolving a CI/CD pipeline: adding automate test runs, security scans, pushing artifacts to a repository, and deploying services and apps into varying levels of environment from test all the way to production.

How a team rigs themselves to (A) acquire a few new skills on their journey to total product ownership & autonomy and (B) make progress on their product team impact of choice is a balancing act. On one hand, we want to spread the learning across team members, to enable several people on the team. On the other? We want to feel real progress! We're not learning for learning's sake. We're learning to become a more capable team.

It's Collaborating Time

There are several go-to tactics when it comes to doing collaboratively in the dojo. Each of these is it's own fractal rabbit hole of practice, so I'll lay a few out here – what they are and in which contexts they work best – with a few resources I've found to be helpful.

Mob Programming

Mob programming – everyone sitting around the same computer, focused on the same problem – is the "daily driver" of dojo collaboration. In this, we'll pick a story or technical task we want to accomplish and take turns switching roles. Someone will navigate or direct the work while another person takes a hand at the keyboard as a "smart input device," taking their cues from the navigator. Other folks in the mob can chime in, but it's ultimately the navigator's choice on where to direct the solution.

From a learning perspective, mobbing really helps level the playing field between people new to a topic and more expert practitioners. Aren't totally confident in what you're doing? Take a turn as a driver. Have a lock on it? Navigate your teammate on to an approach (navigator as teacher). Oh, and it's a great way to cultivate role empathy, mechanical sympathy, and general humility.

Mob programming is a big topic with lots of nuances and ways to bend it to your situation. At some point I'll share our defaults of how we get started with it, but, if you want to know more there's no better place to start than with Woody Zuill's excellent talks on the subject and Chris Lucian & Austin Chadwick's YouTube show, the "Mob Mentality Show".

Dual Track Discovery & Delivery

If we're building product teams as fully autonomous teams, that means they'll be accountable for product discovery and delivery simultaneously. Teams may be stacked with product manager and designer roles working alongside their counterparts from engineering. In turn, this means that at any given time you'll have discovery or refinement on the current product impact proceeding simultaneously with delivery we're more certain about. Enter dual track discovery and delivery.

The flow of a cross-functional product team engaged in dual track, as described by Marty Cagan:

The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software. [...] the work flow is not characterized by each role delivering artifacts on to the next step; rather it is collaborative – the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items.

In the dojo, we may have one team mobbing on a feature we've validated during discovery while a product manager, designer, and engineering lead are concurrently validating the next feature up, perhaps even using data from a previous delivery to make decisions. This would mean, in our dojo challenge, we'd have a WIP Limit of 2: one discovery mission happening in lockstep with one delivery mission.

Set-based Design

This oldie-but-goodie comes from the world of lean manufacturing. In set-based design, when faced with a problem with multiple solutions in which one doesn't stand out as the obvious winner, set-based design emphasizes exploring multiple options until such a time as the best candidate emerges. In short, try multiple designs until you get a winner.

I like to use this when there's disagreement in a team. "Ok. Why don't we try both ways for a day and compare notes?"

When we're doing early discovery in the dojo on a product that has a user experience component (most things), I like to facilitate the group through a design studio workshop. In this session, individuals produce a number of sketches which we then critique and review as a group, followed by converging the ideas within small groups, and so on. It's a wisdom-of-the-crowds approach to generating a lot of ideas and synthesizing a team's best ideas into a plan.

Research Spikes

Some work doesn't lend itself to synchronous collaboration. Research has been one of those things for me. Normally, given some uncertainty around feasibility, I'm going to search the internet, read some books, drain some forums, etc. How we learn novel things, I believe, is an intensely personal process. Then again, there's disciplined and pointed research and then there's wandering around in the weeds.

From a dojo perspective, when a team identifies a research need, I like to frame the research with some pointed questions. What, exactly, do we need to know from this research? Whoever takes this on, I like to work with to present findings back to the group. This becomes a chance for individuals to practice important social skills such as presentation, communication, and responding to feedback & criticism.

Enjoy the Doing

There's really no end to the collaborative forms. Some coaches will have a lot of experience and comfort facilitating some of the well-known, named methods as I mentioned above. That's great, but not entirely necessary. The more important things are that we learn while doing, that we share those learnings across the team, and we give people a chance to try things for themselves either to fortify their own, individual skill set or gain empathy for the contribution a teammate brings to the party.

As a coach, I'm paying close attention to the energy this collaboration brings. Learning, beyond being a competitive requirement in modern work, should be a thrill. Growing your capabilities is improving your team, yes, but it's also making you more valuable, a more powerful contributor. Enjoy the doing!

Beats in the DevOps Dojo Loop: Plan (1 of 4)

This is part one of a series on how iterations work in a dojo challenge. See Part 2: Do, Part 3: Share, and Part 4: Reflect for the whole story.

A dojo team challenge operates on a quick tempo of cadences the community calls "hyper-sprints." These are short iterations, usually lasting 2.5 days / 2 per week, in which we identify work and the learning we want to attach to it, go after it, share our results with stakeholders and the broader dojo community, and take the result of that sharing into the next sprint. Rinse and repeat. If you're familiar with Scrum or XP, it should feel pretty familiar (if not a bit compressed). That said, there are some important differences in the beats within this loop, differences that support the learning mission of a team.

In this series, I'll cover each of these beats: planning, doing, sharing, reflecting. I'll share some basics on timing but go deeper into each beat with some of the tips, tricks, and hacks I've found useful over the years.

Let's start with "plan."

Plan

The hyper-sprint begins with a short planning session. By short I mean anywhere from half-an-hour to a few minutes. At the start of the challenge, expect a bit longer planning session; the team is coming together with a coach and there might be some valuable discussion or even explanation as the team gets used to the pace of their challenge.

Once you get going, you might not find a need to plan. Right-sizing planning and getting to a minimal-yet-useful balance is a pretty regular learning outcome in challenges.

Finding the Work

In planning, the team identifies which items are important to pursue. These items can be typical delivery-oriented user stories that create value for customers or stakeholders, investments in the team's rig (building pipeline, say), or one-off sessions such as knowledge transfers or walkthroughs given by enablers within an organization ("this is how we provision a new environment in the cloud"). It's all on the table. If there's ongoing product discovery, I ask the team to capture all work in their backlog and plan it alongside the delivery work. No invisible work, as we say.

It's good practice to refer to the team's challenge frame, their product and learning goals, and any discovery artifacts they may have created (story maps & journeys, example maps, event storming canvases, etc.). These artifacts help the team make choices about what's next in iterating on the product they're evolving.

Creating an Iterative Feedback Loop

Another source of inspiration for planning work should come from the "Share" and "Reflect" beats in the loop. It's common to get feedback from stakeholders - clarity or new ideas - that we can take into our planning efforts.

Work-in-Progress Limits & Sizing

I'm a fan of starting with a WIP limit of 1 for small teams (5-7 people) and maybe 2 for larger teams (7+), especially in the beginning. This gives every person and role on the team a chance to see how a particular work item gets done. It also creates a single group for coaching to engage with. As the challenge progresses, increasing the WIP limit is normal.

We don't really estimate in the dojo. It's more sizing. Coaches, ask your team, "do we think this item fits within a single 2.5-day iteration? Two?" Over not too much time, you'll find this natural way of breaking things down leads to smaller, less risky stories.

The Importance of Collaborative Volunteerism

We've decided what to do and given stories enough context to move forward. Now the team decides how to divide things up, who will work on what, and how we'll rig collaboration. We always prefer volunteerism over assignment. Some teams work this way naturally, others need a little encouragement.

For example, if there's a story that leans heavily on development, why not encourage your test automation teammate to join the group working on this? They get a chance to see how development goes down and, most importantly, a chance to elevate their skills. Developers in this situation get a chance to practice valuable social skills for good teamwork – patience, teaching, and taking turns coaching one another.

Playbooks in the Dojo

For our purposes a playbook is a collection of techniques, resources, teaching aids, stock questions, or other procedures used to bring consistency to a dojo coaching practice. Dojos often have a playbook covering parts of the team challenge experience.

I have a love/hate relationship with playbooks.

At their worst, playbooks become scripts or curricula written by the thinkers on behalf of the people doing the work, reinforcing a social structure at the center of a pathological or bureaucratic culture your transformation might aspire to dismantle. An immersive learning experience is not training. We don’t follow a set curriculum. Instead, we focus on building new and usually complex skills useful in solving your real problems which is an act of dynamic and realtime adaptation. There's no scripting that.

Playbooks can help mature your dojo offering into a repeatable product. The two main benefits I've seen are (1) smoothing the onboarding of new coaches in your dojo and (2) providing a useful tool for iterating on your practice.

Leave Room for Audibles

The first play in your playbook should be the "audible." An audible is a term from American football, wherein the offense will change their play at the last minute based on new information. Coaches should absolutely reserve the right to mix up any given play should the need present itself. Senior coaches become good at reading the room and making slight adjustments or wholesale pivots. No amount of documentation can account for the complex social dynamics of teamwork. Coaches should use plays as a jumping-off point and a set of guidelines, not as scripts. H/T to my pal Ed Tilford for introducing this term and concept in one of our larger dojos.

Keep Plays Light and Flexible

Don't let plays become training curricula or rigorous standard operating procedures for teams or coaches in the dojo. Fully scripting an immersive learning experience is a terrible idea on many levels. Tacit knowledge and learning can't be scripted.  

Create New Plays Iteratively and Experimentally

The word "experiment" gets tossed around pretty casually these days. It makes us feel scientific and better or more righteous about what we're doing. When we frame our experiments as plays, we introduce some rigor in our experimentation. Write down what you're trying to do and keep a light log of iterations and pivots to that experiment. Maybe the experiment yields a repeatable play, and maybe it doesn't. An experiment that doesn't go as planned might shake out that extra bit of clarity for the next one that does.

Write and Edit Collaboratively

Don't segregate the play creators from the play doers. Writing a play together as a group of practitioners is a valuable collaboration. The play document itself is a happy side-effect of a team building a shared mental model and negotiating collective meaning.

Use a Wiki

Wikis are the ideal format for a playbook. Wikis have this democratic nature that encourages different forms of contribution. Your team grammarians can tidy while your big idea people work out their thoughts. Plays often have connections with other plays, which begs for the hypermedia format. For example, you may document a more extensive play as a collection of smaller plays. This is the case in whichever chartering or framing technique you use; chartering may consist of smaller plays such as goal setting, taking inventory of a team's skill, etc. Being able to break those plays into consumable and linked chunks provides a nice UX for your play consumers and collaborators.

Use Playbooks in Onboarding & Mentorship

Playbooks are no substitute for good mentorship, but they can help speed up the onboarding learning curve for new coaches in your team. I like to sketch out a light play with new dojo coaches as we prepare for more semi-structured sessions, going through the purpose and timings. It's a good coach-coaching practice.

After we do run a session, I like to reflect on the session and trade feedback notes. Having the original plan provides a semi-objective basis for comparison:

1. Here's what we thought we were going to do.

2. What actually happened? What audibles were called?

3. What worked well? What should change?

Plays as Constraints, Plays as Options

Curate a small set of core plays over time. A great place to start is by looking at the team experience in your immersive learning environment and asking yourself, "where do we want consistency, and where do we want options & choices?" The places where you want consistency (intake, framing, exit) tend to be evergreen, core plays – plays as constraints. The places where you want freedom (most places) tend to be options a dojo coach might offer up for a team's choice based on learning and context.

Playbooks are Never the Point

Perfecting your playbook won't ensure good team outcomes. The focus, collaboration, and alignment of the people in your dojo – coaches, leaders, sponsors, and teams – is where the real value is created. Playbooks give us a nice protocol for tuning and focusing a dojo's evolution, but people will supply the ideas, intellect, and energy that make learning outcomes possible and lasting. As with most artifacts, the complex social processes we engage in to iterate on our playbook tend to have more value than the playbook itself.

Experimentation on Trial

I've been asked twice in as many weeks whether there is evidence for mobbing and pairing efficacy. These asks came from engineering managers concerned about their team's productivity. I interpreted this as, "show me the data before I permit this team's choice."

Having to convince a gatekeeper is a bit like mistaking collaborative software development for a courtroom drama. Must we prosecute for the team's right to try something new and see if it works for them? Why, counselor, are you placing the burden of proof in the way of team experimentation?

What's the downside of "that didn't work for us?" What's the upside of a team actively engaged in finding new things?

These behaviors from management might indicate a pathological or bureaucratic culture. Commanders be commandin'. A manager supporting a generative culture encourages experimentation and team choice. These are the cultures we encourage and foster in something like the dojo.

Remember, friends, the first line of the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it.

Finding techniques that help teams perform at their peak means granting the freedom to experiment, learn, and, yes, sometimes fail. Stop using research as an obstacle to team growth. Your people are intelligent, thinking and feeling, adults. They don't need an expert to pre-validate all of their experiments. That is not how experiments work.

The defense rests.

Shifting Left to a T-shaped Team

What’s going on in this picture?

On the left, we have a developer. On the right? A tester. Witness a duo in flow.

They are working together in a mob programming session to write test automation code for a story that was “completed” downstream. The developer is getting a lesson on how test automation works within his team and the products they support from his co-creator (who happens to carry the label “SDET”). Opacity is decreasing!

What you can’t see or hear, what’s off-screen, is the rest of the team offering advice or listening attentively as their turn to drive or navigate the mob is about to come up. This is a central part of the mob programming technique where everyone crowds around a single laptop plugged into a large display and takes turns writing code and tests.

Mob programming creates an environment where skills transfer can happen. It’s something teams may do periodically or even full time. It is a weird idea. It’s counter-intuitive to the productivity-focused people (i.e. most of us). That’s OK. Just try it and you’ll probably come around to the idea that flow beats multitasking every time. I'll have more to say on this in a later post.

How did we get there?

As part of our dojo approach, we create a skills matrix for the team coming in to a 6-week challenge. We open the process by defining the term “T-shaped” and asking teams what becoming T-shaped mean to them in their context.

A T-shaped individual is often described as a “generalizing specialist.” They are someone capable of a lot of the typical duties any individual on a given team would need to perform. Full stack also works, if you want a more aspirational (or aggressive) synonym.

In the case of this team, calling themselves “Free Folk” in the dojo as the “Game of Thrones” series finale was upon us at the time, developers identified an interest in learning more about the end-to-end testing toolchain. Aside: the word “Free” comes from the team’s understanding that their dojo challenge is theirs to direct.

The red columns show you the developer stack (column one and two) and the SDET/tester stack (column three). This team has an opportunity to become more full stack. I see pairing opportunities!

In the dojo, we believe highly social and collaborative teams create T-shaped individuals. That is, the team needs to be self-sufficient and autonomous before the conditions for things like cross-training and co-coaching can really make a difference. Step one: eliminate external silos. Step two: remove internal silos.

SHIFTING LEFT BY DELETING INTERNAL QUEUES

Another term we see more and more these days is “shift left.” It originally comes from the testing world and boils down to something like “test earlier and more often in the development process.” This can be a shakeup to traditional, more waterfall testing approaches where QA sits as a kind of bottleneck to delivery at the end of a group’s pipeline waiting to inject defects as backflow in the system.

A cool thing about Free Folk: they were very transparent in sharing and explaining their current process. This is another key aspect of the dojo; you have experienced coaches to provide suggestions on subtle tweaks that could help the team accomplish their goals. In this case we suggested deleting internal handoffs and pairing through story delivery.

A cursory look at their sprint board in Jira revealed a number of wait states internal to the team:

We had a brief discussion about value streams and wait states and the waste of context switching (another post for another day) which lead to a consensus: let’s try collapsing these activities into one state within their pipeline. This means that they may end up pairing developer and SDET so every story can be worked as a vertical stack in a single pipeline that looks like this:

FOCUS AND COURAGE

Having a goal in mind is important.

"Free Folk” identified several goals to focus on in their dojo challenge, two of which lead us to the experiment of deleting wait states and trying mobbing and pairing:

1. Improving team dynamics and overall agility.

2. Become more T-shaped individuals.

David Hussman used a quote in his e-mail signature, "if you don't know where you are going, it's easy to iteratively not get there." Checking on what you're doing and experimenting with how you're doing it helps your team understand if a given practice yields an intended outcome. In this sense, the dojo model differs very much from classical teacher-student training with lectures and labs. We lead with identifying target outcomes and only then select the practices and tools we believe will help us get there.

We try not to do a lot of selling in the dojo. Challenge teams identify goals based on discussion and common understanding we help to bring to the fore. As coaches we are there to offer up suggestions for things we've had success with within the past — practices we feel comfortable teaching, coaching, and demonstrating. But it's the team's choice. The team sets its goals through a series of facilitated events that bring strengths and weaknesses into a shared light. Only then does the coaching begin.

The courage it takes to try new practices should not go unmentioned. I mentioned mob programming seems counter-intuitive at first. Propositions such as that can create friction against our internal instincts and conditioning toward personal productivity.

We propose some radical practices in the dojo, some seem bizarre at first (we ALL write this ONE piece of code) or even slightly scary (EVERYONE IS LOOKING AT ME TYPE). This is where courage comes into play. It takes time and reserved judgment to objectively decide if a practice that seems strange at first isn't for you or your situation. The courage comes in trying it before you reject it on principle alone. That's a good reason we choose longer periods of time for dojo challenges (4-8 weeks); it gives a team time to find the value in the practice for themselves, develop comfort, and adapt it to their workflow.

HERE TO HELP

Your dojo coach should always have your back. We are there to work with you side-by-side. We pre-negotiate delivery commitments and capacity down so we have the time for this kind of learning and experimentation. You will also see us suggest and fail in our own experiments and move on to the next one.

It's nice when everything lines up like this. My hunch is that these experiments, with this team, will open up new possibilities for their workflow, a workflow they're making their own. This team agency is one of the common and great meta-outcomes a dojo can help promote.

Our Remote Dojo Toolchain

We're using Mural for whiteboarding and to simulate the many artifacts we place up on a dojo challenge team's space, Zoom for audio and video, and, depending on the client, either Slack for status updates, integration, and chat to create collaborative environments for immersive learning.

A few things we've learned:

• Mural is incredibly flexible and easy to use. It rivals the in person experience and has many cool features for facilitators. It's easy to do framing/chartering, retrospectives, post up drawings and sketches, run "dotmocracy" moments, model standard work, create a plan for the day, make a team logo, and more. Best of all, it's held up to the punishment of what I imagine is a 10x growth curve. Kudos to the team at Mural; they've done a great job curating a simple set of features that just work.

• Onboarding people to Mural (or any other new tool) is a necessity. That means taking it low and slow and that 15-minute icebreaker might, necessarily, turn into a 50-minute one. I developed a short routine for showing new people the ropes. The main points I hit in a kind of "follow along with me" exercise:

  • Create, colorize, and change cards and other shapes.

  • Navigate/pan to each corner of the canvas and duplicate the card seen there.

  • Zoom out to the whole canvas. Zoom back in.

  • Follow me or another facilitator.

  • Drop a "lucky charm" icon onto a card (heart, star, rainbow, et. al.).

  • Pull up the shortcut drawer (SHIFT+?).

• Zoom breakout rooms are great for splitting into mini-mobs, pairs, and running workshops with breakout rooms. The trick in the remote era is to be prepared. Take time at the start of the day to form voluntary groups. In the case of workshops, pre-assign groups with your co-organizer on the client-side.

• Many things take a lot more preparation to be successful than they do in person. When working remotely, you can't rely as much on your ability to improvise or the group's ability to self-organize. Again: be prepared.

• Editors - 5K or ultra wide screens with 8pt font with line numbers are impossible to see. When you're pairing or mobbing or reviewing, people need to be able to drive at a distance which means they need to see what to navigate to, click on, which app to switch to, etc. If you're don't have line numbers turned on in your editor of choice, it might be time to find and enable that setting. It makes it much easier to talk people on to the line of code you're talking about — in person or remote.

The nature of client work, especially in the enterprise, is such that you usually won't be able to choose your toolchain. This accounts for the crazy assortment of file sharing and conferencing tools I have installed. One day last week I had back-to-back meetings in Skype for Business, MS Teams, Zoom, Zoom (again), and, everyone's favorite, WebEx. That said, most of our clients have been very flexible in either quickly licensing tools or getting licenses to the coaches and challenge teams that need them. If you've ever dealt with enterprise procurement, this anecdote should warm your heart a bit.

DevOps Dojos at Extreme Scale

Learn how we scaled a massive DevOps immersive learning environment at Target in 2015.

DevOps dojos are an emerging trend in companies large and small looking to create full stack teams capable of releasing software continuously. I had the good fortune to join one of the largest, earliest, and most visible efforts in this space, Target’s DevOps Dojo . Did I mention large? 12 concurrent teams, a dozen product and technical coaches, 24 learning events per week, 150+ whiteboards, and infinite stickers. So, yeah, large.

An early definition of the dojo 6-week challenge. This, along with shorter workshop formats called “Flash Builds,” was a marquee offering of the original dojo.

WHAT DO YOU MEAN BY “DOJO?”

Dojos, as a concept, have been around for quite a while now. The word dojo is a Japanese term for any formal training place, most commonly one for martial arts. Classic coder dojos are a proven approach to creating a learning environment based on deliberate practice. Developers find a place to gather, select one or more practices (e.g. test driven development, refactoring, continuous integration), and run through one or more exercises to gain hands on experience.

Exercises are called “katas.” There are many ready-made katas: score a 10-pin bowling game , Conway’s Game of Life , make a program that can’t lose a game of Tic-Tac-Toe , communicate a solution architecture for a given domain , etc. Kata’s present relatively simple problems as a canvas for exploring and leveling up on a technical practice. I continue to use katas in workshops, interviews, and as a way of building and maintaining my programming skills.

Classic dojos and katas are useful, but the Target DevOps Dojo is a different animal. The objective of Target’s style of dojo is to get teams up to speed on continuous delivery in six weeks (12 iterations) and for those teams to carry forward the work after leaving. Target called this a “dojo challenge.” We were hired to help scale this approach, which I’ll cover in a minute. First, let's unpack the anatomy of a dojo challenge at the time of our landing.

A dojo challenge centers on a product team — product manager, coach, and engineers — working together toward a goal of continuous improvement. The challenge bit comes in when we compress iterations to twice weekly, which turns up the intensity of work. During this time the team is supported by one or more expert coaches who bring skill and experience with the tools and practices required to satisfy the challenge. Technical coaches are playing coaches. They are there to pair, ask meaningful questions, provide answers, pull in other specialists when things get esoteric, and ensure skills transfer. Their job is to become redundant.

I think of the Target Dojo’s challenges as more accelerators, but I try not to get too hung up on terminology. The point of DevOps isn’t to get good at Jenkins and Git. The point of DevOps is to create tight feedback loops connecting developer to user. Continuous deployment is valuable because it speeds up learning.

PIPELINE + PRODUCT = FASTER FEEDBACk

When I landed with Joel Tosi, my partner for the gig, we noticed that most teams in the Dojo were creating CI/CD pipelines. Not that creating a pipeline isn’t a valuable goal in itself, but we suggested framing a team’s time in the dojo around the delivery of a small product impact. That is, we introduced product thinking to their already-in-progress dojo model, a subtle but important twist.

When teams base their CI/CD pipeline development on a real effort, their pipeline gets much more realistic and useful. This tactic prevents over-engineering and waste due to speculation. There’s a great side-benefit: teams start learning how to balance continuous improvement while shipping value to their customers. In our experience, the former comes at the expense of the latter, especially in large enterprises.

Moving into practice we introduced DevJam’s collaborative framing technique. During framing, we gather a prospective dojo team and ask a series of questions:

1. What’s your team name and elevator pitch?

2. What delivery and learning goals do you have?

3. How do we know we’re meeting our goals in a six-week challenge?

4. Who cares about value/usefulness/feasibility?

5. What skills are required? Can we pull this off?

6. What are our standards for workflow, quality, and availability?

7. Are you fully committed to your 6-week challenge?

Once down this path, we saw the dojo open up to different kinds of product teams. For example, we ended up working with Target’s Learning & Development team to build training and other educational resources to support their company-wide agile transformation. It was a rewarding experience: focused by a frame, the close quarters collaboration and quick feedback loops of the dojo’s twice a week iterations yielded a much better product in a shorter amount of time.

150+ WHITEBOARDS & THE POWER OF PLACE

The Target Dojo itself occupies an entire floor in one of the buildings on their main campus. The space is dedicated, intentionally designed, and cavernous.

I remember the day the whiteboards arrived. All hands on deck! A half dozen of us wheeled the assembled whiteboards across campus, from one building to the next. From a bird’s eye view, we must have appeared as ants hot on the trail to the nearest picnic.

The whiteboards served a few purposes. They created walls between many concurrent teams. We’d use a whiteboard to place the frame from the beginning of the challenge in plain view. We’d use a whiteboard to self-organize a minimal process appropriate for the work that particular team was doing. We’d use a whiteboard to sketch and refine designs. All the while remodeling and wallpapering the team room for focus and purpose. In terms of team success, moving into a new space engenders focus and opens folks to coaching. They are making time in their busy schedules, coming into the dojo with commitment, intentionally. Teams are ready to do work.

There are a few powerful effects of having a dedicated space that should not be underestimated. The sheer scale of the space sends a clear message: we are all in on the dojo approach. Their leadership bought in, engaged, and supported the effort. From my vantage point, this support wasn’t just the key, it was the keystone.

BACKED BY A SOLID TEAM

My favorite thing about this dojo approach is the close collaboration with the internal coaches and support staff at Target. Close and energizing. Energizing and effective. Experiments went into practice at a startup-like speed.

This fast pace of experimentation is unusual for large corporations like Target. We were given a lot of latitude to ideate and test rapidly, everyone throwing their hypotheses and hard work into the mix. Like all good products, success comes down to the people involved: their skills, their involvement, their collaboration, and their follow-through and commitment.

No matter where you start your scaling journey, make sure you're doing it with the backing of a solid team.