Agile requires a lot of skills. Agile Coaching demands even more.

Each individual coach has specific talents, capabilities and passions. Similarly, superheroes have their special powers, areas of strength and weaknesses.

Sure the Thing can break down a door, but Mr. Fantastic can slip his arm under and open it without damage or noise. Of course, if “It’s clobberin’ time!” then maybe the Thing is the right superhero for that situation.

Superheroes work in challenging environments and often succeed by working with a team that has complementary talents. The same is true for Agile coaches – we can achieve more in a team with other coaches.

In this post, I want to touch on the skills needed for Agile coaching and how this relates to learning and working in coaching teams.

Skills needed for Agile

The Agile Skills Project is the best reference that I know of. It breaks Agile skills into 7 competence areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. Each competence area has lots of definition (see MindMap). Phew! There’s a lot to know.

I just finished my self-assessment (see below) and probably the biggest challenge for me is around how to rate myself around areas for which I am an expert, however, not currently practising (in last 30 days). So if you want to be strict, just shrink the figure – shape won’t change much.

Overall, I am not 100% happy with this model. On the other hand there is not better.

Agile Skills for Coaches

Agile coaches are a mix of consultant, trainer, and coach. I do not know of a list of skills, so I’ll take a stab at it below. The astute reader will be aware that each of these is a profession in its own right.

Consultant

• Systems Thinking
• Root cause analysis
• Client relationship management
• Consultative Selling
• Organizational Change Management
• Navigating politics

Trainer

• Participatory training – including Agile Games, Training from the back of the room
• Speaking skills
• Presentation software such as PowerPoint. Including graphics/photos/diagrams
• Lesson and content preparation

Coach

• Listening
• Effective Questions
• Giving feedback
• Group collaboration

• Retrospectives
• Personality models such as Myers Briggs
• Psychology models such as NLP (NeuroLingusticProgramming)

To quote Socrates – “The more you know, the more you realize you know nothing.”

Every Agile coach will have some areas of skills that they have capability and vast areas with limited skills. This is why it is best to work in teams. As well, all the usual reasons for pairing apply here too.

Coaching Circle – the Fantastic Four

Gerry Kirk created a coaching circle for some of us in Ontario to meet online weekly to share ideas, provide support, debug situations and learn together. Other participants are Declan Whelan and Jason Little (photo from Agile Coach Camp Waterloo). For me the sessions have highlighted that we come from different backgrounds and have different skills and interests. When working together, it is these very differences that add value and allow the sum to be much greater than the parts.

Gerry ran an open space workshop on this at Scrum Gathering in Orlando if you would like to learn more - Agile Coaching Circles aka How to avoid feeling isolated and unsupported as a coach [Open Space]

Post Script: Selena Delesie and Susan Davis recently joined the coaching circle. Bye bye, Fantastic Four. Hello, X-Men.

Pair Coaching and Coaching Teams

In 2009, I had the fortune of pair-training with Yves Hanouille at Agile Tour Toronto. He introduced me to the concept of PairCoaching for which I am very grateful as it has profoundly influenced how I work. (For example, I had two pair-authored sessions at Agile 2010).

Earlier this year, I was on a coaching team with Alistair McKinnell and Jason Little. I learned a lot see different skills sets in action. Alistair is a world-class technical architect, consummate consultant and above all test-infected. Although he can do much more than this, he is a great technical coach -someone to sit with developers and testers to get in the trenches and show people how to do quality work. Although Jason knows some technical practices and has worked with Agile Management, he worked with team process (Scrum, Kanban) as well as team dynamics. Me? I love getting people to work together. On this engagement, I worked mostly at the team level and the organizational/inter-departmental level. We did a lot of pairing and the quality of our work was way higher.

I know some XP Coaches who think that all Agile coaches need to be developers in order to assist the team in technical practices. For me, it is more important that all relevant skills are manifested in a coaching team and not in a given coach.

So be a superhero and work in a coaching team. If you are a coach, work this in to your engagement model. If you are a client, ask for this and join the team as internal coach – you are welcome for sure.

This post shows the A3 technique and how it is an effective management tool.

The contents of this post are my summary of THE BOOK on this subject: Managing to Learn: Using the A3 Management Process to solve problems, gain agreement, mentor and lead – by John Shook. Available via Lean Enterprise Institute and Ocapt (in Canada).

Why A3?

Over the last year, I have used A3 to solve serious problems myself as well as with clients that I am coaching. I am blown away by how effective it is. I think of it as the howitzer (big gun) of problem solving and use it for complex problems.

Root cause analysis tools are very helpful, however, do not provided a context for resolving problems. A3 is a complete process. If you are not familiar with root cause analysis, see my related blog post.

What is an A3 anyway?

As shown in the middle of the diagram below, A3 is the name for a large sheet of paper (17″ x 11″). With the A3 technique, it is filled up with useful information. Space is intentionally limited to make sure only the most relevant information is shared. At Toyota, the A3 report is used to drive company decisions from shop floor to senior management.

Let’s walk through the sections:

1. Problem – What is the problem that is causing problems? Also, give attention to the title as the summary.
2. Background – How did you decide to work on this problem? What is business problem?
3. Current Conditions – Describe the current conditions with visuals and numerical data that you have analyzed.
4. Goals/Targets – What is the desired target state? This is the place to use SMART goals.
5. Root Cause Analysis – What are the underlying causes? Use ask why five times and fishbone diagram.
6. Countermeasures – How will you reach goal state? What activities can be identified that will address root causes and how were the best ones selected?
7. Plan – What is the plan for getting there? When will the countermeasures be implemented?
8. Followup – What were the results of deploying the countermeasures? Now that there is new information, it is time to revisit the A3.

You may have noticed that this is an elaborated version of PDCA – Plan Do Check Act. This is the heartbeat of a learning organization.

It takes time and effort to complete an A3. Weeks not days. Use when appropriate.

Tips: Experts strongly recommend using real paper. Yes, you will need to re-write; editing is a good thing. A wiki is great for details, but not for thinking and summarizing.

A3 to gain agreement, mentor and lead

In this section, I want to share how the A3 technique is a powerful management tool.  Consider the following diagram:

A3 is about people working together to solve problems. The Japanese word Nemawashi is about going to the roots to reach consensus and alignment in a deep way. An A3 changes the way we work and communicate with each other. When meetings start by reviewing the parts of the A3 that have been completed, there is great focus on the remaining work. I have also seen new project participants brought up to speed very rapidly.

At Toyota, the A3 is used to do work. It is used to solve problems, make (set-based) decisions and execute plans.

Lean is famous for using pull to deliver the right part at the right time at the right place. With A3, the person driving the change effort can pull authority by working with other people and demonstrating leadership. It is chilling to see this work. I was coaching a junior analyst to put together an A3 on a production problem. When the issue escalated, the VP recognized the analyst as the expert and asked him to tell people what to do to fix the problem even though he had no formal or informal leadership role.

Finally, the A3 can be used to build a learning organization. One key aspect is to celebrate mistakes. This is also common with building an innovation culture through Improv or theatre techniques. At Toyota, it is used to develop people by helping them think for themselves to solve problems. A manager’s job is to build people and mentoring people on the A3 is a great way to do it. (Like a self-organizing team, but on an individual scale.)

I wish I had a real A3 to share, but the better ones I have are client confidential.

If you want to learn more, I urge you to buy the book or check out webinar on Managing to Learn.

Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage.  See manufacturing example.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

• I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
• See complementary practice of Timeline and Marketplace for understanding other team members.

Siraj Sirajuddin shared a deeply insightful reflection on the nature of Agile/Lean coaching. Lot’s of insights for me.

Below, I have a few notes that just scratch the surface.

A big take-away for me is that every day and every meeting I need to:

1. Learn
2. Make a difference
3. Have fun

Another concept is Clean State Fridays where everyone goes home without emotional baggage so they can start fresh on the following Monday.

He also reminded me that we play a dance with courage and grace to achieve great outcomes.

Strongly suggest you check out the full presentation or find a way to see him in person.

Christopher Avery gave a very interesting talk at Agile 2009 called How to Develop Your Leadership Power Daily: An Agile Approach to Growth.  It was a very interesting talk about personal responsibility and how to grow – hence the title of this blog post.

Sidebar comment: This talk really has nothing to do with Agile so it appears that the conference program is branching out in new directions.  On the other hand, if you want to coach or build a high-performance team, then this is useful information.

The top left corner has the most important bit of information.  We are hard wired to not accept responsibility and would readily blame others.  As we are more self-aware we can progress from denial to blame to justification – all the way up to ladder to responsibility.   You can request a free poster here and there is a short description here.

The 3 keys are about how you can shift your own behaviour:

1. Intention – intend to change your behaviour so you can win!
2. Awareness – pay attention to your language and thinking.  Make a chart of how many times a day you can catch yourself not taking responsibility.  One way is to carry around change and give yourself a penny for noticing when you say something unresourceful and 10cents if you catch yourself before you say it.
3. Confront – you need be honest with yourself or you’re not going to get anywhere.

The daily practices are some additional tricks to help move towards personal responsibility.

The anxiety hierarchy is about how some words you use when talking to others can trigger defenses.  Approaching someone about a PROBLEM will result in getting their input on a consideration.

As an NLP Master Practitioner, there is a note in the corner to remind myself that it’s not that easy to shift behaviour.  We often have limiting beliefs and values conflicts that may need some shifting in order to make a persistent change.  Awareness is a good start, but in my experience often not enough.