Agile Coaching

Honing your Skills as an Agile Coach

Being an Agile Coach is challenging in many ways. You have to balance many things (see Olaf Lewitz recent post Spotting the Balance) as you work with different teams and stay true to your own values. You are a catalyst for change, helping the teams you work with see how they can work differently and supporting them on their agile journey. To do this you will need a solid understanding of agile principles and plenty of experience in how to put them into practice.

When Liz and I wrote our book on "Agile Coaching" we filled it with stories and examples of how to help teams implement agile practices that seem simple but have many common pitfalls that teams fall into. But you need more than this practical know-how to fulfil the role of a coach. Since writing the book I've developed a workshop style course on to help new coaches expand their skills. The surprising thing is that this course doesn't cover agile practices at all - it's all about the other skills you need to be an effective agile coach.

So what skills are important to build for agile coaches? Well, I think these fall into roughly three categories:-

• Working with people: listening, giving feedback, asking questions, building trust and rapport
• Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure
• Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals

Interested in developing your skills in these areas then come along to my Agile Coaching Skills class. Next one is running in London on 25-26 August at Skills Matter and after that in Bucharest on 19-20 September at MosaicWorks.

But training is only part of honing your skills. Practice in a safe environment helps. I introduced the Coaches Dojo as a format for a way for agile coaches to support their ongoing learning without relying on trainers. It's pretty simple to run one of these for agile coaches in your area so I hope more people get these started.

I'm always looking to expand my toolkit and find fresh ideas to experiment with. Later today I'm heading over to the Agile Coaches Gathering and looking forward to learning from other coaches in the open space. Look out for an open space or Agile Coach camp near you.

Keep honing your skills as an agile coach in whatever ways you can, there's always more to learn!

When To Write Story Tests

Thanks to Paul Grenyer for asking me (and Allan Kelly) about when to write story tests. He's not the first person to ask me about this so thought I'd share my advice with you here.

I believe that part of the confusion about when to write tests for user stories comes because people tend to jump into talking about "tests" too quickly. There's a subtle difference between Acceptance Criteria and Acceptance Tests but often these terms are bandied about as meaning the same thing.

Liz Keogh has an excellent blog post on Acceptance Criteria vs. Scenarios where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived. In his book "Agile Estimating and Planning", Mike Cohn calls these rules "Conditions of Satisfaction", you can simply list these as bullet points on the back of story cards. As Liz points out, you can uncover acceptance criteria by having conversations with your stakeholders about example scenarios. So acceptance criteria and example scenarios are a bit like the chicken and the egg - it's not always clear which comes first so iterate!

In contrast, acceptance tests are basically scripts - manual or automated - that detail specific steps to check a feature behaves as expected. You don't need to write out all of these tests in order to plan the next iteration. Instead, you can use acceptance criteria to clarify the scope of each user story, so the team understands just enough detail to agree on what to work on in next iteration. You can also use acceptance criteria to split "epic" stories - optional or nice-to-have acceptance criteria may be bundled into later stories.

So when do we write the acceptance criteria? Well, the whole team can get together, to flesh out the user stories with acceptance criteria, as part of iteration planning but this can take a while. Larger or distributed teams may prefer to do this activity before the planning meeting - a trio of customer, developer, and tester is usually all you need.  If you work this way, remember to review the acceptance criteria with the whole team before committing to delivering a story in the next iteration.

Now we get to when to write the tests. Acceptance test scripts can be written in the same iteration as the code, before or in parallel with developing the code. If you're lucky your customer has time to sit down to do this with you or perhaps a developer and tester paired together can do this. Remember to check with your customer that you've captured the intent of the user story before going ahead and implementing the code.

Of course, I'm not suggesting that you write all of the acceptance tests for all the stories at the beginning of the iteration. Just that when work starts on a story, the first thing to do is to get really clear about what tests should pass - following an Acceptance Test-Driven Development approach - this can be done by writing one acceptance test at a time or the whole set for the story.

Summing up, explore acceptance criteria and example scenarios as part of planning and write the tests close to when you write the code. Please do post any further questions and suggestions as comments.

Summer Events for Agile Coaches

Summer is here at last with blasts of rain and sunshine. Here some upcoming events that might be of interest to you as agile coaches in the UK.

The first one that I'd like to bring to your attention is the Agile Coaches Gathering at historic Bletchley Park. This event is put together by volunteers (yours truly and Manav Mehan). The event starts on Friday with an Open Space gathering to create a lively program of conversations and simulations relevant to agile coaches. In the evening we venture into Bletchley for dinner at the local chinese and indian restaurants and beers in the pub. The sessions run throughout the day on Saturday. The past two years we've had sunny weather and many sessions outside on the lawn. As I write, we already have 40 people registered for the event and just 20 places left, sign up here to get yours.

 
I'm also excited to announce that I'll be running my Agile Coaching Skills training course in London on 25-26th August. This workshop style class has been extremely popular, past attendees include Jon Jagger and John McFadyen. Unlike a Certified Scrum Master class, we assume that you have some agile experience and our focus is on skills that you need to coach agile teams, such as the art of facilitation and System Thinking.

 

 

If those dates don't work for you then why not venture along to eXtreme Tuesday Club? Everyone is welcome just sign up on the wiki no registration required. It's on every Tuesday, just pop in after work on a sunny evening. You'll get a chance to chat to an eclectic mix of agile practitioners and luminaries like Steve Freeman, Liz Keogh, Tom Gilb often come along. Follow @extremetuesday on Twitter for announcements.

If you're not close to London then maybe one of the upcoming regional events might work for you:

• Agile on the Beach on 15-16th September with keynotes: Mary Poppendieck and Kevlin Henney.
• Agile Cambridge on 29-30th September with keynotes: David Anderson and Jurgen Appelo.
• Agile Yorkshire and Agile Scotland also have regular meetings.

Please post a comment if I've missed any crucial summer events. Hope to see you at some of the above!

Embrace A Skeptic

As an agile coach, you're bound to encounter a few skeptics in the teams and organisations you work with. Although sometimes it seems that skeptics are doomsayers bringing a cloud of negativity to the team and it's tough to see ideas shot down before they've been given a chance. In my experience, skeptics are to be embraced.

I've been coaching agile teams for a few years and had plenty of exposure to naysayers and cynics. What has surprised me is how many of former skeptics are now agile advocates. I started my own agile jouney as a skeptic about XP but I was curious enough to give it a try. I remember also when I first worked with Monica, she was a program manager who seemed determined to stop her team get even a toe-hold to try agile practices like Test-driven Development. Since then she's brought me in to coach her teams in two different media organisations and she now works for an agile consultancy. I have a bunch of similar stories about former agile skeptics so I thought I'd write up what I do when I meet an agile skeptic.

The first thing to remember about a skeptic is that they are at least giving your proposals some serious consideration. They are thinking about whatever is being put forward otherwise they wouldn't be able to come up with any arguments against change. Try to accept that most skeptics care about many of the same things as you do. They want to be able to do a quality job and not to waste time. However, they have to yet to be persuaded that being "agile" helps and likely fear that change will make things worse.

Moreover, they're likely to have real experience to share that underpins their position. To get a skeptic on your side, you have to listen to them and hear their concerns. You are likely to learn something useful by working through the obstacles they see. You can work with them to improve your approach. There may be simple tweaks you can make to avoid the pitfalls that they raise and allay their fears.

In their book, "Fearless Change: Patterns for Introducing New Ideas", Linda Rising and Mary Lynn Manns include the Champion Skeptic pattern. They advise that you actively seek a skeptic to help sharpen your thinking because skeptics can help you find weak parts of your change message.

So next time you find yourself worrying that a skeptic on the team is out to burst your agile bubble, pause and take time to listen to their concerns. You might learn something!

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.