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.

Related posts:

1. Top 10 tips for coaches This is another talk from Agile 2009 – by Liz...
2. Ways to start with Agile – books, training, or coaching? I wrote this to help explain to the different types...
3. I am presenting at Agile 2010 I am really excited to have two sessions accepted...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. Agile Kick Start and Agile Games Day – Announcing Two Workshops October 19th and 21st As one of the organizers of Agile Tour Toronto I...
2. Use Value Stream Mapping for Current State Assessment This post is about how I run a value stream...
3. Agile 2010 Keynote by Dave Thomas Dave Thomas talked about a lot stuff so I pulled...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. I am presenting at Agile 2010 I am really excited to have two sessions accepted...
2. XPToronto Talk – Understanding and Dealing with Technical Debt by Amr Elssamadisy Tonight Amr Elssamadisy from GembaSystems presented at the XPToronto/Agile User...
3. Strategies for Effectively Managing Legacy Systems Derek Longmuir presented ThoughtWorks QTB on working with legacy systems....

Related posts brought to you by Yet Another Related Posts Plugin.

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…

Related posts:

1. Coaching Self-Organizing Teams Joseph Pelrine gave a really interesting session on “Coaching Self-Organizing...
2. Agile 2010 Keynote by Dave Thomas Dave Thomas talked about a lot stuff so I pulled...
3. Rapid reliable releases I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. Agile Tour Toronto Presentation #2 – Agile Executive Briefing Below are the slides from my first presentation at AgileTourToronto. This is...
2. Agile Tour Toronto 2009 Blasts off! Agile Tour Toronto 2009 is over and it was an...
3. Ways to start with Agile – books, training, or coaching? I wrote this to help explain to the different types...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Here it is:

You may wish to check out the other lightning talks.

Related posts:

1. Kanban is a Gateway Drug For years I have preferred Scrum as a starting place...
2. Kanban for Video Game Production Clinton Keith gave an insightful session around designing and configuration...
3. Scrum or Kanban? YES! Alternate Title: A model for understanding Scrum and Kanban (Cool...

Related posts brought to you by Yet Another Related Posts Plugin.

Triangle Model

Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.

We explain three different perspectives: Company, Customer, Team.

Team Perspective

The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.

Theme Scoring & Screening - Relative or numerical weighting based on criteria (Mike Cohn)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.

Kano Analysys - Structured Questionaire to determine feature relevance: Mandatory, Linear, Exciter

• See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening

Innovation Games® - 12 Games to better understand your product and what’s important (Luke Hohmann)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.

Company and Stakeholder Strategy

• Aligning and Balancing Your Backlog
• Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work

Business Value Game – Simulation to illustrate how organizations can define their own business value model.

• Game instructions

Allocation Model - helpful to balance priorities with divergent or competing interests

• See example by Alisson Vale: Slides 40-49

Where to go from here?

The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”

These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.

Slides

Related posts:

1. Aligning and Balancing your Backlog This is a review of Luke Hohmann’s excellent blog series...
2. Strategies for Effectively Managing Legacy Systems Derek Longmuir presented ThoughtWorks QTB on working with legacy systems....
3. The Backlog is in the Eye of the Beholder Subtitle: How we created and played a brand new game...

Related posts brought to you by Yet Another Related Posts Plugin.

The purpose of this post is to share my key learnings from the book: the goal of reading and how to skim. No effort to represent the whole book.

The Goal of Reading

Adler argues that the goal of reading is to learn and that there are 4 elements that need to be satisfied. Consider the diagram below.

In order to decide what parts of the book you believe, you need to understand what it is suggesting and how that information is supported. As I write, I think about confirmation bias and that we need to challenge ourselves to keep our minds open.

Perhaps the most intriguing part is to explicitly think about is: what impact does the book have one you? What are you going to do differently as a result of reading the book?

How to Scan a Book Quickly

It takes time and energy to read and learn from a book. Adler introduces an approach called inspectional reading (systematic skimming or pre-reading) to provide a mechanism to decide if the book is worth reading. The diagram below outlines which bits of a book to focus on.

In 20 or 30 minutes, you can get an idea of what the book is about and what its parts are. Even if you think you are going to read the whole book cover to cover, this is still very valuable in understand the book as a whole.

Happy reading!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Value Stream Map’s are very useful for understanding how your current process works. My initial understanding came via Mary Poppendieck (books and training). Later I learned the details from the book Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA by Mike Rother and John Shook; it’s all about manufacturing but the principles hold.

Workshop is ~10 people x 3 hours

For this meeting, I ask for a cross-functional group that can define the steps involved with going from concept to cash. This group may be in the 5 to 15 person range depending on the organization. Depending on how many people you have you may want to split them into multiple groups. Groups can do the same or different processes. My rule is to get to as small a group as you can and still have enough knowledge of the process.

With regard to time – 2 hours may be enough for a small company while a large bank may require the full 3 hours.

Slides used to Introduce Value Stream Mapping

Below are the slides I use to introduce the workshop. Mostly you’ll just see pictures that I use to introduce the concepts, so you gotta know this stuff well. In addition to value stream mapping, I talk about Muri, Mura, Muda and have them think about the 7 types of waste.

View more presentations from Michael Sahota.

Explain how to create a Map

Before starting the exercise, I run through creating a value stream map with them so they get a feel for how it works and agree on conventions.

As people indicate what the steps in the value stream map are, I write up each step and create the legend shown on the left. It doesn’t really matter what process you use – the point of this part is to give them a feel for identifying each of the parts. Go through a few steps until you can see they are getting the hang of it. Remember to write the time on value added and waste stickies (missing in legend).

Size matters. Queue size, that is. It is important to show how much WIP (work-in-process) there is at each step. People often know things like: we have a product roadmap with 200 features in it or 9 features waiting for development.

Some teams may not feel comfortable identifying any activities as waste. That’s OK. They may not be ready for that yet.

Mapping Exercise

It helps to pick a concrete project that is typical for the organization. Something like an average feature, typical client request or urgent defect fix. This helps people move away from a conceptual process to talk about what actually happens in real life.

It is a good idea to warn people that they may be surprised with how things actually work. Taiichi Ohno, one of the founders of Toyota Production System, joked that it is good to have a poor starting place so there are easy opportunities to show process improvement.

During the exercise, I float between the groups to answer questions and make sure things are on track. After about 20 minutes the teams are usually cooking and can proceed on their own.

Once everyone is finished, each team presents it’s value stream map to the large group. Sometimes there are minor corrections, but these are usually fine details that don’t change the big picture.

Example Value Stream Map

Below is an example (click for a large image) of a completed value stream map for funded development at a 50 person product company. In this particular case, the company noticed that 5 days of planned work actually took 15 days (with rework) plus another 10 days of waste due to communication overhead.

Special enhancements:

• Along the top we have communication waste – this is the extra time needed to manage a project in a dysfunctional process that spans 9 months.
• Below the main flow we have rework arrows. Each arrow indicates the % chance that the work item needs to return to an earlier step. As can be seen, there are multiple return trips after reaching production.

Debrief with management

At the start, I explain the overall activity and its purpose. Together with some of the original authors of the map, we walk through the steps. I stick to explaining the Value Stream Map concepts and let others explain the content. Managers are usually surprised at how long it takes to complete work.

It is especially important to clarify that we are talking about the Lean concept of system efficiency - defined as time working on product/elapsed time. This will be unrelated to other measures of efficiency at the company.

The usual follow-up on this workshop is one to specify the desired future state. Of course, all of this is a great candidate for using the A3 technique.

Related posts:

1. Stuck in Ha (Ron Jeffries on state of Agile) Ron Jeffries and Chet Hendrickson gave a closing plenary session...
2. Serious Problems? Use A3 Technique to Nail ‘em! This post shows the A3 technique and how it is...
3. Agile Assessment Kickoff Presentation Yesterday, Gerry Kirk and I kicked off a 4 day...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. Go Faster with Root Cause Analysis One of the workshops I run is to help team...
2. Use Value Stream Mapping for Current State Assessment This post is about how I run a value stream...
3. Approaches to Organizational Change Mary Poppendieck gave her usual well-researched and convincing tour-de-force presenation...

Related posts brought to you by Yet Another Related Posts Plugin.