Agile Coaching

How does an Agile Coach differ from a ScrumMaster?

This year there's an increasing interest in Agile Coaching. Sessions about the role of Coach have been popping up in agile conference programs around the globe. Agile2009 even dedicated a stage to sessions on Coaching. Our book on "Agile Coaching" is the first book dedicated to explaining how coaches work with Agile teams. Meanwhile, Lyssa Adkins is also working on a book, "Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches and Project Managers in Transition", which should be out in the summer of 2010.

Yet, despite the burgeoning Agile Coaching movement, there's not much written about how the role of Coach fits into the Scrum framework. It's easy to see why people are curious. There's no Coach role in Scrum reference books, such as the Scrum Alliance Scrum Guide---although if you do some digging you'll see Coach was included in the original SCRUM pattern language. Yet what's puzzling is that Scrum Alliance's certification program includes Certified Scrum Coach, as an advanced level qualification on  your "journey to mastery". To qualify, you have to demonstrate significant coaching experience with client references. But how is a Scrum Coach different from a ScrumMaster?

In our "Agile Coaching" book, we focus on how to coach a team in a vanilla flavor of Agile rather than getting sucked into the specifics of the Scrum framework. So you may be surprised to learn that I often coach Scrum teams and ScrumMasters. Last month, Christoph Mathis invited me to share my experiences on "Being a Scrum Coach" at the Scrum Gathering in Munich. I was delighted to find there was a whole track dedicated to "Coaching & Continuous Improvement". This panel session was the first time I was put on the spot and asked "What's the difference between a ScrumMaster and a Scrum Coach?" that's when the seed for this blog post was sown.

Last week, the same question came up in an OpenSpace session for Agile Coaches and that gave me the extra nudge I needed to write up my thoughts. I've posted a photo that shows some points in our discussion here.

I'm sure you'll agree that a ScrumMaster needs coaching skills to perform their role well. I'd add that you don't need to be a ScrumMaster to be a Scrum Coach! Coaching skills are like good fertilizer. In my experience, it makes sense for you to spread these skills around the team. The ScrumMaster is not the only person who needs to absorb them. My goal, as a coach, is to encourage the team to become self-coaching rather than continuing to rely on any one team member to be the coach. So for me, a coach is a transitional role until the team grows their own coaching capability.

When you take this perspective on board, your next question is "Does an experienced Scrum Team continue to need a ScrumMaster?" Surely, once they've got experience under their belts in applying Scrum, the need for a ScrumMaster disappears. Let's revisit to the responsibilities of the ScrumMaster. Are there any important aspects that can't be absorbed by the team?

Naturally, Scrum continues to evolve and over the years the role of ScrumMaster has been described in different ways. Ken Schwaber compares the ScrumMaster to a "sheepdog" who guards the team from interruptions, they're often the first point of contact for anyone outside the team. A ScrumMaster also focuses on removing impediments. Maybe it's down to personal coaching style, I'd never do either of these activities as a coach. My rule as an external coach is never to do any tasks for the team. I want to avoid creating any dependency on me. Instead, I teach the team to notice and respond to impediments and interruptions themselves.

As Mike Cohn reminds us there is no end state when transitioning to agile. Adopting Scrum is just a beginning to your team's Agile journey and a team doing "Scrum by the book" is not the end that ScrumMasters or Scrum Coaches are working toward.

Interview on Agile Coaching

We were excited to meet Mike Swaine from Pragmatic Bookshelf when he interviewed us for November's PragPub e-zine. This was a great opportunity to answer some questions about our "Agile Coaching" book and we really enjoyed our chat with him.

Download your free copy of PragPub from http://www.pragprog.com/magazines

Other topics covered this month are:

• The Pompatus of Pomodoro
• Bonjour, iPhone
• Stretching Stripes
• Interrupt Mood

Budding writers might also be interested in PragProWriMo

Kanban Coaching Insights

Every year, I invest in my personal development by taking classes and participating in conferences to grow my skills (see "Growing You" chapter in my Agile Coaching book). I chose David Anderson's  "Kanban Coaching Skills" workshop because I appreciate that Kanban is more than limiting Work-In-Progress (WIP) with colored cards on a board. As an agile coach, I want to understand more about the human aspect and how to introduce a team to Kanban.

David emphasizes that Kanban makes it easy for a team to get started. His mantra is "Always say 'Yes' we can do something." This can-do mentality is reflected in the "Yes We Kanban" strap line on the limitedwipsociety.org T-shirts.

He explains that the prime directive for getting started with Kanban is "Optimize existing processes through changes introduced with minimal resistance." When you bring in a Kanban system, it's important to avoid changes that affect self-esteem and social capital. That's why, when you introduce Kanban, roles, responsibilities, and job titles remain the same. The work that people do also remains the same, you don't question the competence of the team. Instead, you start Kanban by gaining agreement from all stakeholders to make the existing workflow transparent and set a WIP limit.

 Unlike other Agile approaches, there's no training period where the team must slow down to learn "best practice" and take on new roles. When Kanban is introduced, nothing is taken away. The only changes are additive. Some minimal new activities are introduced, such as a visual board with WIP limits. Also some working agreements are introduced to establish the stand-up meeting and setup a pull system.

Here's a change curve, that David drew in the class, showing a situation that he aims to avoid. You can see that when a lot of change is introduced in one go, the dip in performance can be too much for the organization to tolerate. Pressure mounts to drop the change and fire the change agents before any performance improvement is seen.

I've seen situations like this myself. When an organization wants to go Agile fast, a significant outlay in training and coaching is often required. Signing off on the costs for this shows the level of commitment to change. However, if the pressure to deliver, during this learning period, becomes too much and they take their foot off the accelerator and hit the brakes. It seems only those organizations who have a burning need for change (and believe that they can't go back) keep going long enough to reap the benefits.

Anderson emphasizes Kanban is different because it initiates a series of mini-changes, each backed up by empirical data. Here the change curve looks more like the next photo, a series of ripples, each making a small improvement to performance. When a team evolves their workflow and surrounding working practice themselves, changes tend to stick. This promotes a learning organization culture rather than attempting to institutionalize best practice. Kanban is a catalyst here towards becoming Lean.

 When I was taught SCRUM by Ken Schwaber, back in 2003, the emphasis was the same. Keep the existing interface and reporting mechanisms to management then "Inspect and Adapt."

Nowadays, more practices are often bundled in with the Scrum framework and it requires a bigger appetite for change. Being spoonfed practices that are known to work elsewhere and forcefully retrained as in "shock therapy" brings with it a risk that the team adheres rigidly to the new practices but doesn't feel empowered to adapt them. Scrumbut implementations and "cargo cult" agile are becoming more common.

I remember these approaches to change were contrasted by Kent Beck at XP2001 conference (although suspect the slides are lost in the mists of time). Back then, there was much talk about how important it was to do the all XP practices because the practices worked as a reinforcing system. Kent used the analogy of a roller-coaster and suggested that introducing change in a piecemeal fashion would increase stress on the team, as each change entailed a dip. At the same conference, Ron Jeffries decoupled XP practices in his circles diagram which helped teams looking for an incremental adoption to see the inner circle of "technical practices" as a place to start.

I believe that much of the worry about how "extreme" to be when starting with XP arose because there's no clear constraint to help balance the system. You must simply place your trust in the values, principles, and practices. You only qualify to tinker with them after you've fully assimilated XP---by which time you've absorbed some habits that are uncomfortable to let go of. No wonder Kent decided not to include Retrospectives in "XP Explained" 2nd edition (I did ask him but he wasn't convinced in the benefits).

Anyway, I don't want to get into a "named cloud" debate. There are many situations where XP or Scrum will be helpful. However, I see many situations where it's more practical to follow a gradual path to Agile. Where teams struggle is that if they're only attempting small changes then they often don't see how much they're improving. The beauty of a Kanban system is that it makes flow visible and tangible to all stakeholders, and helps the team maintain momentum in improving it.

David explains that a Kanban approach to change is like water, the work flows around the rocks in the river. It brings data to the surface that helps us work out how to improve without mandating a process. You can start with simple policies and adapt them as you go. There's no need to be like a chess player thinking too many moves ahead. Make a start with tactical fixes and trust that progress on root-causes will come in time.

How to Create a Diagram of Effects

Here's a technique that we didn't have room to include in our Agile Coaching book---How to Create a Diagram of Effects.

Software projects have complex dynamics, there’s a lot going on and sometimes it's hard to see the forest for the trees. When coaching, you often want to encourage the team to see connections between the activities they spend their time on and the effects. What I like to do is create a Diagram of Effects with the team to explore the factors at play in a situation. These diagrams are from Systems Thinking which you can read more about in by Peter Senge's book "The Fifth Discipline" and also several books by Jerry Weinberg.

I was introduced to a technique for creating these diagrams by Marc Evers and Willem van den Ende at OT2003 conference. What I really like about their approach is that you can engage a group of people to create the diagram. You can also use it by yourself, for personal reflection about a situation you are currently facing.

All you need to get started is some sticky notes and markers. Now pick a problem to explore.

1. Start by brainstorming all the measurable factors in the situation. For
instance, # unit tests, # hours spent testing, # defects found, # hours spent fixing defects. Write each factor on a separate note.
 
2. Now lay out the notes on a whiteboard or a sheet of flipchart paper and look for relationships between the data. Review whether as one factor increases or decreases another factor changes? For example, # defects found has an effect on # hours spent fixing defects.

3. Move the notes that appear be related closer together so that connecting arrows can be drawn between them to showing the apparent influence effect. These arrows should show the direction of influence so the arrow between #defects found and #hours spent fixing defects points toward  #hours spent fixing defects. Tip: you can also draw arrows on sticky notes as it makes them easier to move around.
 
4. Consider whether the effect is a positive or negative effect. For example, as the # unit tests goes up the # hours spent testing might decrease, this is a negative effect. Draw a minus sign next to the arrow to show this. Annotate positive effects with plus signs.
 
5. The finished result should be a diagram that helps you see the big picture. Look for any reinforcing loops. Are there any interventions that you could make to change the effects?

I've included a sample diagram below.

This is a simple diagram of some effects that influence hours I spend at my computer. The reinforcing loops (marked with a snowball rolling downhill sign) show me some places that I could attempt to gain more balance in this system. For instance, I could switch to drinking decaf or herbal tea. However, there are many more factors that I could add to try and see the bigger picture. For example, if I didn't read emails I would miss out on business opportunities and that in turn could impact by ability to buy things, such as coffee!

Watch out when using these diagrams. People have a tendency to think that when there’s a relationship between two factors that it is a linear one and they can also be blind to effects that manifest after a time-delay. For instance, a common misconception is that adding developers to a project will bring the date in by an equal amount per person—this is often reinforced by planning software. Of course, this cannot be true, adding a couple of top-notch developers might improve the speed the team go at but adding a dozen mediocre developers is likely to slow the project down. Increasing team size impacts communication within team and time spent on learning how the system works needs to be factored in.

Finally, as Bas Vodde and Craig Larman remind us in their first book "Scaling Lean and Agile Development", the First Law of Diagramming is "The primary value in diagrams is in the discussion while diagramming---we model to have a conversation."

Is Assigning Roles the Best Way to get Agile Teams Started?

I am often brought in to coach teams who are new to agile software development. Frequently, I find they want to map new Agile ways of working onto their old work paradigm. They want to understand who's in charge of what under the new order, who has authority, and how they will be ranked against each other. I try to resist being dragged into naming which role should be in charge. Here's why I dig my heels in.

When we look at work to be done from the perspective of which role should pick up the task, we miss one of the fundamental principles of Agile development, self-organization. Focusing in on standard roles from a methodology distracts our team from thinking about what we need to do in the unique situation we face. If all the work to be done is neatly divided up into his job or her job then we start to lose sight of our shared goal and teamwork suffers.

The hard part is that it feels natural for us to specialize, to get good at one skill and for others to rely on our special abilities (and to rely on them to do their special thing too). Specializing comes at a high price. We have less need to talk to each other, as we each work away in our own separate worlds. But this approach soon starts to falter when we attempt to deliver software every few weeks. Unless, the balance of work remains steady, bottlenecks soon appear, where some team members are overloaded and others are waiting for them. To break this cycle, the team needs to reflect how they approach the work. Encourage team members slow down and learn how to take on a wider range of tasks and rethink them. They'll need to get creative to work this out.

When we have a person on the team whose job it is to do certain stuff, the rest of the team only notices how important doing that stuff is when they can't keep up. That's often the hardest time to slow down and rethink things because work is piling up and it's difficult to get people to think rationally when they're under pressure. So if specializing causes bottlenecks then defining a fixed set of roles on the team can suffer from the same problems? Well, maybe so. I notice that where a team starts with strict role definitions, it takes longer to break out of those roles later on. If a team insists they must have roles then I encourage them to work through the responsibilities of these roles as a group so they are understood by everyone on the team. And, ideally, more than one person on the team knows how to play that role.

Now we get to why presenting a team with an agile "person in charge" role bugs me. Setting up an agile as a system that depends on a "leader" role clashes with the principle of self-organization. Every team member needs to engage with decisions rather than deferring them to management and passively becoming dependent on the leader.

I first heard from George Dinwiddie that "self-organizing" can be broken out into self-managing and self-directing behaviors. However I'd like to see team members become comfortable to do both. To manage their own work and also to contribute to product vision and direction. It's wonderful to see team members get truly engaged, dreaming up new product features and selling them to their customers.

I believe that all team members need to grow their capability for leadership rather than working under a single leader. This does take time and coaching rather than leadership. I now believe that the job of leaders is to establish the conditions for teams to flourish. They place fireworks in a sandbox, light the blue touch paper and then step well back.

Distributed Agile in a Virtual World

The most thought-provoking session, I attended at Agile2009 was on the Distributed Agile stage entitled "Using Virtual Worlds for Distributed Agile".

Now, I'm not normally a fan of distributed working because communication between team members deteriorates with distance. Alistair Cockburn came up with the neat metaphor of erg-seconds as a way of captures the cost in both labor and time to get a question answered. These erg-seconds (and argh-minutes) are often a hidden cost when a distributed team attempts to apply Agile. However, sometimes you just can't avoid distributed working and I've certainly done my share of skype calls. In fact, when Liz and I wrote our book on "Agile Coaching" months would go by where we didn't meet and instead collaborated via Google Docs and Skype.

Most distributed teams need to brush up on their facilitation skills to make meetings via teleconference bearable (see earlier post). However, at State Farm Insurance, teams have been experimenting with virtual worlds. At Agile2009, Keith Voos and Ami Hileman demonstrated a virtual world used by an agile team to collaborate with team members in multiple locations. I was impressed by their findings; for example, conversations in the virtual world were better quality than a conference call and internet access was lower bandwidth than for webcams.

Keith and Ami showed us a virtual team room that a team has been using for activities like:

• Creating stories
• Estimating tasks
• Radiating information
• Tracking work
• Daily Scrum meetings
• Retrospectives

The space looks very much like a physical team room with colored sticky notes posted up to create a virtual story tracking wall. The developers have also used the virtual world for remote pair programming. There are typical team artifacts: a whiteboard, a burn-chart, a lava lamp showing build status, a calendar, a clock, even some Dilbert cartoons! I've pasted some photos below.

It hasn't been all roses, they have had experience of accidentally deleting walls and also removing avatar clothing. And, of course, virtual worlds don't solve timezone differences. However, the team finds this way of working is fun. On Fridays afternoons, they also play a bubble-shooting game in the virtual world which has helped team building.

I was impressed by the amazing potential of virtual worlds for distributed agile teams, so many people who work in software industry are gamers, it seems blindingly obvious that this is the way ahead for more teams. The tools shown were Qwaq and SecondLife but there are many others out there. And who knows, you may find the cost of these tools cancels out some of those dreaded erg-seconds.