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.

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 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!

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.