Agile Coaching

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.