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 Hanoulle 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.

Ron Jeffries and Chet Hendrickson gave a closing plenary session at Agile 2010 in the form of a dialog with lots of few cute photos thrown in for fun.

Ha refers to the Shu-Ha-Ri model of Beginner-Practitioner-Master from Martial arts. Stuck in Ha means that as a community we are practicing and unfortunately a lot of what is going is not that great.

Ron and Chet were courageous in touching on the sensitive topic of certification (a controversial subject in the community).

Training is the start, not the end

Consider the road of life-long learning in the diagram (top right corner) below. If our goal is mastery and learning, then courses and certification such as CSM (Certified ScrumMaster), CSD (Certified Scrum Developer) just start us on this road.

Need to map the territory

In order to plan where we want to go, it is helpful to have a map. Right now, we only have part of the map identified – maybe a few states. Initiatives such Agile Skills Project, ICAgile and Scrum Alliance Registered Education provider are ways the community is seeking to build the map. Once we build the map, we can share this with individuals and companies to help them travel the road of learning.

The Joy of Agile is about shipping software

A fundamental tenet of NLP is that the map is not the territory. The map only guides us. The real territory is something different and much richer. Education and certification is a means to an end.  Agile is about shipping quality software and delivering value. We can only find that in the real world and not in certification and credentials.

Dave Thomas talked about a lot stuff so I pulled out the bits that resonated with me and bear emphasis.

Starting with the top right and going clockwise, I’ll make a few comments…

There is no Agile toothfairy to make all the problems go away. A lot of companies only look to Agile when things are really broken. It took your company a long time to create the mess that it is in and it is going to take a while to get out of it. Agile will help and provides a direction and it is going to take hard work. Sorry.

When you have no automated tests in place, acceptance tests add much more value than unit tests. So, consider starting here before learning about JUnit, refactoring and working with Legacy Code.

TDD (Test Driven Design) is a huge technical contribution to the community that stands independent of Agile. It is an amazingly powerful design practice.

We were reminded that a flat org structure with a technical career ladder is essential in a well-functioning organization. It is important to keep your top technical people in technical roles.

Dave has seen the rise of what he calls blue collar programming. So many environments are filled with legacy code. Programmers have to sweat out meaningless design-dead code just to make things work.

I attended Israel Gat‘s session with this title at Agile 2010. I was already familiar with some of the concepts based on a private seminar given to my coaching circle by Michael Spayd.

For me organizational change is a hot topic since I keep running into it when adopting Agile practices.

Schneider Model for understanding Culture

Israel introduced the Schneider model for understanding company culture. The idea is to use survey questions to categorize the dominant culture into one of four categories (see below).

Many companies we work with are a control culture while Agile is all about Collaboration and Cultivation and (sadly) to a lesser extent about Competence.

You Can’t Change Culture

“Culture is singularly persistent” – Drucker. It is estimated that it can take 10 years for the culture to change in a large company.

Consider the chart in the middle of the diagram below. If we want to be successful in adopting Agile (or anything else) it is essential to focus on harmony with the existing culture. Pushing for different culture will lead to conflict.

Agile adoption leads to conflict

This is an observation rather than a pejorative. With the best intentions Agile will accidentally lead to conflict within the organization. The example given was of different cultural biases within different departments.

For example, Competence in Engineering and Control in Operations. In addition to differing departmental objectives, us vs. them thinking will also create tension. Israel talked about the Outmodel that describes perceptual bias that we create when we have limited information about a situation. The idea being that by design of our organization, there will be conflict between the groups and Agile adoption only makes this worse by perturbing the system.

One idea proposed by Israel is to create a boundary object between different groups. In the case of Development (Engineering) and Operations, one could use Technical debt as a way of measuring the quality of the code to satisfy ops that the code was production worthy. So a  boundary object that has a quantitative measure is very helpful. IMHO, there is much more than this required to ensure that code is production-worthy, but that’s another story.

What I learned about myself

In one exercise we broke into the four groups to explore the different cultures. I went to Control because I have struggled with a few organizations with this culture. What I discovered is that I personally have strong control tendencies. I also discovered that control can save a lot of time by decisive action. The trick is knowing when to apply it. I experimented with my workshop later in the conference and was happy to see that very strong direction around group logistics and exercise structure can make a session more coherent and valuable.

And now for something completely different

Clarke Ching shared a great 6 min animated video on organizational change by Eli Goldratt. It is related so, I’ll throw it in here…

About a year ago I gave this presentation at Agile Tour Toronto 2009 – Agile Executive Briefing – Situational Assessment and 50,000ft view of Agile. DZone finally posted it.

It is interesting to watch oneself after some time has passed. I would definitely keep the energy and the passion. For sure I would speak S L O W E R (Man, I was like a gerbil on speed). I would also drop most of the text as you can see in my more recent zen-like presentations. A lot of the message is very good – I reminded myself of a few things. Enjoy.

At Agile Coach Camp North Carolina, I had the opportunity to give a lightning talk on Kanban on my posts:

• Scrum or Kanban? YES! and
• Kanban is a Gateway Drug

Here it is:

You may wish to check out the other lightning talks.