Agile Coaching

Just Say No

A good craftsman needs to take care of his tools, to keep them oiled and sharp. As an Agile Coach, you don't have any obvious physical tools apart from your trusty notebook and pen (and perhaps some super sticky notes, index cards and markers in your bag). You are the diagnostic instrument that both senses and perturbs in coaching situations. You use your eyes and ears to notice what's happening. You trawl through your pool of past experiences to help identify underlying issues. You rely on your heart to empathise with people you work with and reflect your values in the actions you take.

What can you do to stay sharp and true? In a nutshell, you must take care of yourself. You need to take time to rest and stay healthy in both mind and body. You have a lot more to offer a team that you are coaching if you are alert and centred. Bringing energy to your work is difficult if you are running yourself into the ground by taking on a heavy burden of commitments. Remember a burnt out coach is no use to an agile team.

In our Agile Coaching book, Liz advises "Be Kind to Yourself." I wish that I'd added one from me on "Sustainable Pace."

Sustainable Pace is a guiding principle in agile software development. Many agile coaches forget to apply fundamental principles like this to themselves. I know that it's tempting to try and help with every request that comes to you for coaching. But take a moment to look into your heart and consider whether you can really take on all this work. Each new request is likely to increase the context-switching you'll have to keep up with and most requests expand, as you explore beyond the tip of the iceberg. A practical first step in getting some control of this is to list out all the parallel streams of activity that you are involved with including community commitments, such as reviewing sessions for agile conferences, going along to agile user groups, and contributing to online agile discussion forums. You may be surprised just how many things are on that list!

Now what? Consider trimming that list. You'll find some commitments that you simply have to see through, others you may be able to put on hold. Now consider how to avoid becoming overstretched in future. Become more aware of the choice you have when a new request for your time comes in. Sometimes saying "No" is better than trying to squeeze the extra work in and doing a half-assed job. Giving a considered "No" can build your reputation as someone who only accepts work that they can take on. Keeping your workload sustainable helps you to leave enough time in your life for important things that help keep your energy up. When you spend time with your loved ones and have fun, your become stronger and more able to cope when things get tough.

However much you love coaching agile teams, don't become an addict! Practice saying "No" so you have space in your life to say "Yes!" to the things that matter. Hopefully, one of those things that matter is your own work as an agile coach. By saying "No" more often, you'll be able to be more present and effective for the teams that you say "Yes" to.

Adapting Your Agile Coaching Style

One of the questions we explore in my "Agile Coaching Skills" training course is when to adapt your coaching style. I draw an arrow running from Directive to Non-Directive, like the middle arrow in the sketch below, to represent one important aspect of coaching style. I explain that the coaching style you adopt depends on the experience of the team members (topmost arrow) and your own experience (bottom arrow).

 

A heavily directive approach would be one where people are firmly told to follow a specific set of agile practices, as in Shock Therapy popularised by Jeff Sutherland. There's no choice being made by the team, they rely totally on the expertise of the agile coach to determine an approach suitable for their situation. The reason that they are willing to do this is that they recognise that they are new to agile and don't have the skills to decide what's appropriate. The agile coach acts as their guide and mentor enabling them to enter a new world of agile software development. Many coaches would consider this directive coaching style to be more consulting or teaching than coaching.

A totally non-directive approach would be where a coach relies purely on asking thought-provoking questions and sharing their observations to help a team identify alternative ways of working. In theory, this coach need not have any subject matter expertise in applying agile practices, they leave the choice of where to go upto the team. This approach works in situations where the team has built up enough knowledge in basic agile practices to apply them. However, the team is still struggling to overcome mental blocks about what is allowed within their organisation and see how they might improve. The coach's questions helps this team break through obstacles in their way and reveal choices open to them. A team that is new to agile, and is still grappling with building basic skills, may find this coaching style frustrating because people want definitive answers while they're learning and don't feel confident to experiment yet.

As agile coaches, we work with teams with a variety of experiences and so we need to remember to adapt our coaching style accordingly. Some teams are just embarking on their agile journey, others are already partway down the agile road, teams may also contain a mixture of new and experienced team members. We need to recognise where the team is at and adapt our coaching style to match the needs of the team. So when the team is new, we need to be prepared to act as teacher. As the team gains confidence, we need to recognise that it's time to step back and help them build a sense of autonomy, enabling the team members to choose where to go next rather than supplying all the answers. To take the team on this journey, it helps to have some experience of applying agile to draw on so you can support the team with directive style guidance when they get stuck.

Remember also that a team's agile journey is not usually a straightforward one where they load up with new agile practices at the beginning and simply perfect their application of those initial practices as they go. The road most teams travel has many twists and turns. Depending on the terrain the team encounters, it may be appropriate to learn new practices and drop or unlearn old habits along the way. As agile coaches, we need to see when to step in with guidance and direction to help the team learn a new skill and when to step back into non-directive style coaching. Be prepared to switch in and out of these styles throughout your time with the team.

Defining What Done Means

Often I get called in to coach teams who have been trying to implement Scrum and are struggling to deliver on their commitments by the end of the sprint.They agree what features should be possible to get done but somehow things don't go to plan. It looks like the problem is testing but there's more to it than that. Well-known agile expert Jeff Patton illustrates the underlying reality using the following picture. He used this sketch in support of arguments people use for going to a Kanban style approach ( which also focuses teams on what Done means).

One source of the pain is that team members lack a shared agreement on what quality level they're aiming for. Some programmers may be writing automated unit tests, others may delivering code without checking it works. Some testers may talk to programmers as soon as they find problems, others may spend a lot of time filing length defect reports. Soon a blame game starts.

Instead, if we establish a shared "Definition of Done", we have a better chance of understanding what needs to happen during the sprint to get the features properly ready ("Done-Done").

That sounds fine and dandy but just how do we go about creating a such a definition of Done in our team? Here's some simple steps that you can try:

1. Surface the current practice (Always, Sometimes, Not Yet)
2. Discuss what Definition of Done what feels practical for the team
3. Resolve any puzzles and concerns before putting into action
4. After a couple of weeks, repeat from step 1.

I've posted some pictures below from a conversation with five developers in a small non-profit organisation to show you what this looks like.

Step one is to invite everyone in the team to write sticky notes about what they do now. Expect to get some duplicates. You'll also find that there is some discussion about which category the notes should go in. Most often these debates are resolved by putting the notes into the Sometimes category (if it really is Always or Not Doing then why the debate?). 

It's now clear to the team that they have a pretty minimal test strategy and also that people on the team have different assumptions on what needs to be done. No wonder there's confusion. Now it's time to turn the conversation to working out a basic definition of Done that they can start using starting tomorrow. Help the team get clear what each proposal means to them and whether they are really ready to do this yet? It best not to be too ambitious, remind them that they can improve it over time.

The team decided to explore this basic proposal for a new definition of Done.

Then we explored what this would actually mean for the team. We needed this become a shared working agreement that every team member was happy to implement. So you may be surprised to hear that we didn't vote on it. Instead, we worked towards consensus by checking for concerns.The pink notes represent each element of Done. The green notes are questions and concerns from the team. We put these in two columns "What we do.." elaborating detail about what this means (who/what/when) and "How we check it's being done" about making this activity visible.

Don't forget that step 4 is to review how the new definition of Done worked for the team. Agree a date when this will happen by, a natural point is the next retrospective but the team may prefer to wait longer to allow the new approach time to bed in.

Hopefully, you find these tips useful. Please do add your own suggestions for other ways of how to do this as blog comments below. And, yes, I know that there's more to a test strategy than establishing a definition of done :-)

Building a Transition Backlog

When we start work with a new team, we bring a fresh pair of eyes. We see many things that we'd like to improve and many problems to be addressed. Part of our job, as an agile coach, is to help the team to bring these opportunities and challenges into focus. Now we can work with the team to implement solutions that mesh well with the organization / context they find themselves in. In this blog, I want to share a technique that I use with teams to surface driving forces and barriers to an agile transition so together we can work out the most effective place to put our energy.

The basic technique is called "Force Field Analysis" and is derived from the work of social psychologist, Kurt Lewin. Though I learned about this technique from Esther Derby and Diana Larsen's book, "Agile Retrospectives." Where I've added a twist is that I use the information from a force-field chart mapped out with the team to generate an initial Transition Backlog of work items supporting an agile transition that coaches and teams can work through iteratively. Mike Cohn gives some excellent advice on how to work with Transition Backlogs in his new book "Succeeding with Agile" (see his blog for some basic pointers).

Mapping out a Force Field

Let's see how to assemble an force-field analysis chart with your team. To start, find a big surface to draw the chart upon such as a whiteboard or flipchart. Bring along plenty of markers and sticky notes so you can get the whole team involved in building the picture of forces in play.

As we encourage teams to tune up their practices, we understand that being Agile is usually not the real goal. Often there's an underlying improvement focus within the organisation that has lead the team to adopt an agile approach. Whilst we value the attitude of reflection on current practice and continuous improvement elements of agile approaches, we don't want to lose sight of the desired improvement.

Step one of drawing a force-field analysis chart is to identify the desired improvement and draw a big arrow at the top (from left to right) that represents the change from current state to desired state. Although this could be "Go Agile" it may be better framed as "Deliver Software More Frequently" or "Reduce Time Spent on Defects".

Now, divide the chart into two equal sized columns. The left-hand column is used to list out the driving forces for the change summarized in the big arrow at the top. For example, "Management support" or "Budget for training". The right-hand column is used to list out the restraining forces. For example, "Company hiring policy" and "Teams are too busy".

Encourage the team to contribute their ideas for forces at work on sticky notes. For each force identified, draw an arrow pointing to the dividing line between the columns. Use line thickness to indicate the strength of the force (see example from a training class below).

Generating a Transition Backlog

When the team is happy that the force-field chart adequately represents the forces in play, it's time to consider how you can amplify the driving forces and reduce the restraining forces. Each action that you can identify is a candidate for a "transition backlog" that the coach and the team can use to focus their efforts on changes that will move them toward their desired end state.

You can now use the chart to ratify your current coaching strategy by walking through it with key stakeholders and getting their take on the priorities of the items in your initial transition backlog. Senior stakeholders may add additional forces to the chart. Their buy-in is often crucial as you may need their support to help escalate impediments to the agile transition. 

Slicing and Dicing Epic User Stories

Today I ran a workshop ideas to explore how to slice epic-sized user stories at Redgate in Cambridge. I'm going to share some of what we covered with you in this blog.

In my work as an agile coach, I find many teams applying Scrum are puzzled about user stories. I guess one reason is that this technique is from XP and so these teams may be missing some of the background. In "Planning Extreme Programming" by Kent Beck and Martin Fowler stories are defined simply as,

"We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration."

So there's no perfect size for a user story, it depends on the length of your iteration, the speed at which you can get software built and tested, and what your customer considers valuable. It often takes a few iterations for a team starting on a new project to work some of these factors out. But it should be possible. When I hear teams claiming that they cannot identify any slices that can be built and tested in a couple weeks, I suspect that they may not be challenging assumptions about how stories can be sliced and diced. Although sometimes teams do experience this where they are working on a very fragile codebase.

In the workshop, we split into groups of three people (which works well for conversations about use stories) and all worked through a prepared example with the aid of a cheat sheet I put together.

Rachel's Cheat Sheet for Splitting Epics

Remember you are looking to develop slices of the problem that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”)

Consider the following approaches:

What are the different ways that you can handle input/output data ?
•    You can make a story per input screen.
•    You can make a story per enabled elements of an input screen.
•    You can make a simple (not pretty) UI.
•    You can make a command line interface.

What scenarios are in scope for acceptance criteria?
•    You can work with a subset of the input data.
•    You can defer conditional steps to other stories.
•    You can defer data validation.
•    You can defer error handling.

What architecture decisions can be deferred?
•    You can defer optimisation of performance.
•    You can defer internationalisation
•    You can defer handling large volumes of data.
•    You can hard-code data rather than getting from the real source.
•    You can stub out components.

This is not an exhaustive list! Be creative in your story splitting approach.

More Slicing Ideas

In the workshop, we also added the following ideas for slicing (see photo).

I hope that some of you find these ideas useful. Please comment on this blog with alternative ideas for slicing and dicing epic stories.

Agile Coaches Dojo Experiments

Many people are now moving into agile coach roles and looking for ways to improve their skills.  In response to this demand, I've developed an Agile Coaching Skills workshop aimed at practicing agile coaches, to compliment my "Agile Coaching" book. If you're interested, the next public workshops are in London on September 15th and Belgium on 17th.

Training can give us a boost but there are still gaps to be filled as we grow into a new role. We need a way for agile coaches to support their ongoing learning without relying on trainers (who are few and far between). Agile Coach Camps and Gatherings provide another great opportunity for agile coaches to get together on a weekend to explore ways to improve their practice and network with other agile coaches but these events tend to be months apart.

Over the years, I've got a lot of help from London's eXtreme Tuesday Club  so I know that there's great value in talking through the problems I face as a coach with other coaches more frequently. However, getting together for an evening pub chat is often a bit hit and miss. We need to create a safe place to practice coaching that exposes budding coaches to different coaching styles.

So I've been experimenting with a new format that can be used by groups of agile coaches to support learning from their peers. It's inspired by the popular Coding Dojo format used by coders.

What's a Coding Dojo?

A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in deliberate practice in order to improve their skills, by coding in front of others. You can find out lots more at, http://codingdojo.org/

There are coding dojos run all around the world rather like local user groups. The coding dojo format has also been adopted within companies for groups of interested developers to learn together.

I've seen coding dojos particularly useful where the team is not using Java or C# and can't get off-the-shelf training in agile practices like Test-Driven Development and Refactoring.

How might this translate to an Agile Coaches Dojo?

Agile coaches work with people rather than computers. So unlike a coding dojo, we don't need to setup laptop computers or a projector to run an agile coaches dojo. A coding dojo simply needs a circle of chairs for the participants.

I tried out my first Agile Coaches Dojo at Agile Open Holland - here's a photo of one of the groups so you can see the setup we used. Basically, splitting the group into circles of 4-6 people.

The other big difference is that coding dojos require participants to prepare for a "kata" on a programming challenge. Here's an example: Write a program that solves word chain puzzles (cat -> cot -> dot -> dog). You can find more example kata at pragmatic Dave Thomas's Code Kata and the Kata Catalogue maintained by Emily Bache.

Coding dojos focus on the pattern of choreographed steps you take towards creating an elegant solution. Coaching dojos would focus on the same thing. The "how" aspects of what we do as coaches, such as what questions we ask and how we work with the person to help them solve the problem.

What would a kata look like for an agile coach? Well, part of the art of agile coaching is to explore a problem domain with a person (rather than a computer). I could probably create a catalog of canned challenges based on my own experience that might be used as coaching katas. Where I would struggle is how to share enough context for a coach to work on those challenges. So in the Agile Coaches Dojos I've run, we have based the coaching kata on real challenges that the participants had experienced. This enables us to explore live situations with the person who needs coaching help. Here's an example of a challenge faced by an agile coach in her own words.

For Agile2010 conference, I added a demo round where I presented a challenge and two experienced coaches took turns to coach me towards finding a solution. Thanks to David Hussman and Dave Rooney for helping me out with this. 

Although I've seen a number of conference sessions for agile coaches based on triads of coach/coachee/observer. I deliberately wanted to break out of this grouping so that people in the circle could see different coaching styles demonstrated (as in a coding dojo). I also prefer to call the person who presents a coaching challenge a Seeker rather than coachee. There's something about the word coachee that bothers me, seems to me like a passive recipient of coaching rather than an active player in the situation. You can download my Agile 2010 slides for some more detailed instructions on the timings we used.

The Agile2010 session got very positive feedback and lots of ideas on how to improve the format. More time would have allowed us to try multiple rounds and also to rotate roles. Some structured sheets for things that observers could look for might also be useful.

Some of my favorite comments from the feedback forms:

• "I was a guinea pig and I liked it."
• "It gave me very concrete ideas for organizing similar dojos in my area. I want to do this more!"
• "excellent session I want to bring it back home."
• "You did teach people to listen. Thanks for that."

Closing Thoughts

My only worry about the idea of an Agile Coaches Dojo is that using Japanese nomenclature will obfuscate the intent of the agile coaches dojo, which is: to create a safe place for agile coaches to practice and be exposed to different coaching styles.

I want to encourage people to experiment with the format (like programmers have done with coding dojos) and so I will be interested in hearing what's worked for you. So please post comments about that, when you've tried an Agile Coaches Dojo in your area.