Tag Archives: coaching

Telling Vs Coaching

Posted on by
2
Reading time ~ 4 minutes

Before I start, a thanks to @fatherjack for being the first person to request a topic from the backlog. If any of you want more of the same, just shout!

The Story

Up to a certain point in my career, my success was defined largely due to my ability to find creative and often tangential solutions to difficult problems. For anyone that’s completed a Belbin assessment in the past, I’m mostly classified as a “plant“. My major strength has changed very little in 15 years although my complementary strengths and views have all shifted a lot (I might discuss this in more depth another time).

With this strength in mind, I found that when working with others I often jumped past a lot of the detail and rapidly offered solutions and alternatives. The sheer volume of options I can provide means many did stick and work. However, using this approach risked those seeking support or assistance becoming dependent on my problem-solving rather than developing knowledge and learning to solve problems themselves.

When I became responsible for other staff I recognised that many of the strengths that got me to that point were not appropriate to leading or coaching others.

I spent a little time learning basic coaching skills, the GROW model, coaching through questioning and other simple tips. Pat Kua also steered me toward the Dreyfus model of skill acquisition (which in hindsight for me is an important missing link for coaching) but I found that my instinct to solve and help often overrode my learned coaching practices. Coaching others is hard! (or at least it is when you’re normally a problem solver)

Having led a number of teams, managed a full spectrum of technical staff, implemented organizational change programs and most recently being responsible for a company-wide community of practitioners, my coaching skills have become more and more critical to my role. Coaching Dojos have helped significantly – using coaching tools repeatedly as a deliberate practice but there’s still something not quite right. I still have those problem-solving skills going to waste, there must be something I can do with them.

The Lesson

So here’s the thing. Just because you’re coaching doesn’t mean you should only ask questions, it doesn’t mean you shouldn’t direct or tell and it doesn’t mean you shouldn’t get to have the fun of solving problems for (or with) others. You just need to understand more clearly when it’s appropriate to do so and when it’s not.

Learn to spot when you’re “telling” when you should be “coaching” and vice-versa. This can be really tricky to achieve when you have all the answers and ideas.

Fortunately for me, my current employer really invests in their staff. All managers are trained and encouraged in doing just this…

The Tools

The coaching and leadership model we use is “Situational Leadership” – in particular “SLII”. (here’s the explanation of  why it’s II)

I can’t cover the full depth of the model in a blog but here’s the basic conceptual framework – this should be plenty to help you recognise when to coach and when to “tell”.

There’s a direct correlation between the style of leadership you (as a coach/leader/mentor/manager/team member/person) use and the development level of the coachee/seeker/mentee/staff/team member/person/team.

Important note – this applies just as much when leading or coaching teams, not just individuals.

We model this as four “Development” levels (D1-D4) and 4 corresponding “Styles” (S1-S4) This might seem a bit jargon-y but putting this into practice really does work (see the diagram below).

The suggested style to use is based on a composite of the motivation of the individual and their competency level.

As an analogy, consider learning to drive a car. Most new drivers are really keen, think this is going to be easy and can’t wait to be out under their own steam (Level D1). As an instructor, you need to let this play out, give them the space to try and succeed (or more often fail) but you do need to be quite prescriptive in what they do for their own safety (and that of others) (Style S1). When things get hard and motivation wanes (Level D2), you continue to tell them what to do but in a coaching style (S2). As competency develops, the trainee becomes more competent (D3) and your style will need to follow. Eventually they will (hopefully) become self-sufficient (D4).

Our regular trainer actually talks us through a lot more than the textbook model. The diagram below is my interpretation of the model with the additional tips we’ve learned.

SLII on a page

Extended representation of Situational Leadership II

There’s a few really important points that help us use this as a thinking tool.

  1. The model applies to each specific task. If a person has never performed that specific task before, re-assess their development level. Some complementary skills may apply but don’t assume competence in one area translates directly to the task at hand.
  2. Watch for transitions in motivation as a guide to levels of support to offer. When individual motivation is low, the coach/leader must be more supportive – more guiding and questioning. When motivation is high, less support is needed.
  3. When individual competency in the specific task is low, the coach/leader should be making the decisions on the course of action (even if leading through questioning). When individual competency is high, the coachee makes the decisions but may still occasionally want to validate these with the coach.
  4. A mismatch between leadership style and development level can be harmful. The further apart the difference, the more dissonant the leadership style will be.

Extensions:

There are a couple of important extensions to the model that need consideration.

In many work environments, there are times when a person may have high expertise in an area but not be motivated to actually work in it. Similarly, someone who reached a high level of competence in an area but is ignored may lose motivation. In these instances, they have actually regressed around the model (from D4 to D3). Your leadership style needs to change!

In other situations, you may have someone with little or no motivation to work on a new task and little or no competency. Rather than starting at development level 1 (D1), you’re actually starting at D2. You need to work with the other person to build motivation and competence. At this point they either develop to “D3” or first to “D1” and then back through the cycle.

And Finally

Like all frameworks, this is a tool only. Use with caution. The more you understand how to use this, the better you’ll manage with it. If you’re interested, get trained properly, don’t just rely on what I’ve presented here.

 

Rapunzel’s Ivory Tower

Posted on by
Reply
Reading time ~ 3 minutes

“If the problem exists on the shopfloor then it needs to be understood and solved at the shopfloor” – Wikipedia

Some years ago I took on an agile coaching role at a very large corporation. Like many stereotypical large corporations, they were seen as data-driven, process and documentation-heavy. Management culture was perceived as measurement-focused, command & control and low-trust.

They had a very well established set of Lean practices and managers promoted strong values around empowerment. Despite Lean training for all staff, there was still a very limited “Go See” culture.  Above a certain level it was still traditional management-by-numbers and standardization – mostly by apparent necessity through scale.

James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view)

At the start of the transformation the leaders wanted to know “who’s agile and who isn’t”.

Disturbing as the thought might seem, their motivation was sound. We’d all put our careers on the line to “go agile” in order to turn around a struggling group. The last thing needed was a disaster project with “Agile” being labelled as the cause of failure.

(Nearly 2 years further down the line, we managed to have at least one project fail early and be recognised as saving over a million dollars).

We developed an extensive “agility assessment” in order to teach all those involved that “being agile” wasn’t a binary question and wasn’t just about Scrum practices.

The measurement system for the assessment acknowledged that whilst there may be “good” answers, there are no “right” answers or “best practices” – teams could actually beat the system. (If there were “one true way” of developing software, the industry would be very dull).

Beyond measurement, the big challenge I and my team faced was the pressure to “operationalize” agile. To develop common standards, procedures, work instructions, measurements and tools worldwide. The Quality Management System (QMS) culture from our manufacturing background meant that interpretation of ISO accreditation needs was incredibly stringent and was required in order to do business with many customers.

Ironically that requirement kept us almost entirely away from the teams delivering software!

Operationalization was what our managers were asking for and it was very difficult to say “no”. Traditional corporate culture defined this as the way things should be.

So from stepping into a role where we expected the gloves to come off, where we could get out of the management bubble and start making a real difference with teams; within a few months my entire team found themselves unwittingly captive in an ivory tower.

We saw it coming and felt powerless to stop it but as permanent employees fresh into our very high-profile roles, those painful home-truths could not be comfortably raised.

I and my team spent that first period doing what was asked of us and helping teams out for the odd few days at a time wherever we could.

Fortunately all was not lost. At the same time, we invested in a highly experienced external group to engage on each of our sites and drive some of the changes we needed to achieve from within the teams.

Was the value I’d hoped to add in my role lost? – Actually no.

The managers got what they wanted – heavily seeded with a our own more balanced agile/lean understanding and experience.

We weren’t perfect but made a significant series of improvements. The teams actually delivering products had far more experienced consultants supporting them, who as contractors could take the right risks that permanent staff could not have done at the time.

This 2-tier approach actually gave the delivery teams more air-cover to find their own way whilst we worked on coaching the management.

The teams still had a long way to go but were heading in the right direction and getting progressively better. At the same time, the management team learned that Agile isn’t simply a case of running 2 days Scrum Master training, developing a set of procedural documentation and expecting that everything will show 1,000% improvement.

After the initial bedding in period, I and my team were able to build up sufficient trust with our leaders that we could set future direction ourselves.  The kick-start needed on change within the teams had already been made. (far more effectively than we could have achieved alone). 

With our leadership trust established, after being holed up in a tower for too long, our coaching team were able to reach the real world again. This time it was entirely within our own control, with the management support we needed and enough credibility remaining with the teams we had interacted with to move forward.

We were free, able to step in, learn more, tune, help out and spend months at a time properly embedded on teams taking them forward – reaching that point of empowerment for our team was a coaching journey in itself.

If you’re in the fortunate position to be an agile coach or in a similar role in a very large or more traditional organization, make sure you recognize that your coaching efforts will often be as much (if not more) necessary in coaching your leaders first.

Breaking The Seal (Part 2)

Posted on by
Reply
Reading time ~ 2 minutes

In my first article on “breaking the seal” I described how this pattern applies to managing WIP on teams. There’s also a work/social concept that fits the same name with a different pattern…

Name: “Breaking the Seal”, “The Lid is Off” etc.

Analogy: When you open a new pack of good coffee there’s that great smell that comes out – suddenly everyone wants a brew.

Concept: Socially, many people are unwilling to speak up in a crowd or be the exception either in positive or negative situations. Fortunately for experienced agile teams, the social norm of staying silent has often become disrupted but you’ll need to break it back open once in a while and as a coach you’ll need to find ways to introduce it.

Being the first to speak up triggers team inertia; suddenly others’ voices will also be found.

How many times have you sat in a meeting where someone uses a term or concept you have no idea what they mean but you don’t speak up? How many other people in the room also have no clue but stay silent? This might be inertia, it might be fear or just an unwillingness to appear stupid. Particularly with technical teams where your career goal may be “technical guru” – being seen as wrong or not clued up may be a sign of weakness. Having a “wise fool” on the team breaks the seal on this but needs some caution applied.

In some organizational cultures it may not be socially acceptable to question more senior staff. This really gets to me. In fact, I’ll write another post dedicated to this.

Occasionally speaking up might be risky, particularly if there’s obvious management issues. (Nobody likes to speak about the elephant in the room when the elephant is in the room) In these cases arrange with a few like-thinking peers to take it in turns to be the one to raise issues so it’s not always you. This will also ensure that you’re not speaking alone with others relying on you to take the risks up every time.

On the more positive side, the “red cards” tool relies on this same concept for group self-facilitation. Where once it becomes socially acceptable to halt a problem or challenge others the team’s self-organizing capability steps up another notch.

Practice this in your own teams – challenge yourself and your peers to ask a dumb question or plug a rat-hole at least once a week.

Red Cards

Posted on by
Reply
Reading time ~ 3 minutes

One of the best facilitation tools I own. How to get a group out of a rat-hole & back on track without personal confrontation and minimal effort.

Name: The Red Card

Concept: When a group is in discussion on a particular topic they can often disappear down “rat holes” or off onto tangents. Every member of an agile team is empowered to “red card” a conversation that they feel is going off track. The group as a whole typically rapidly decide whether the red card is warranted or not.

Usage: I ensure that plenty of of small (playing card sized) red cards are available in the team rooms. To introduce them to a team that haven’t used them before, I will usually take a large session such as release planning and introduce the concept of red cards as part of the facilitation tools and ground rules at the start of a session. What I tell the teams is:

“Whilst I’m facilitating, I tend to get drawn into the conversations and need hauling out, especially if I start ranting. Therefore the red cards are required primarily to shut me up – although feel free to use them on each other too!”

Once a member of the team first uses a red card, that’s it – the lid is off. Expect use of cards to take off rapidly. (see “breaking the seal – part 2“).

Background: Chances are this has been used before me elsewhere in the world, but this is a tool I introduced to my teams after returning from Agile 2009. During one of the evening sessions there was a panel discussion. Questions were submitted in advance and each panelist had 2 minutes to discuss. After the whole panel had their say, the audience were given an opportunity to vote. On every seat was a large red and green paddle. If we wanted the discussion to continue we voted green. If we wanted to stop and move on, we voted red.

When I got back to Cambridge I introduced it during some training I was running. I “borrowed” my eldest daughter’s red & green art straws. There were a few “hot spots” on the course where 1 or 2 attendees would lose track. We had a great team who immediately raised a red straw. They enjoyed calling each other out so much that we had red straw warfare at one point!

After using the same in a couple more sessions it became clear the green straws weren’t needed. The red ones were getting tatty so I raided the stationary cupboard for some red card instead, cut this into pieces about the right size to hold up visibly and planted a few in the team rooms. These are now the social norm for facilitators on many teams worldwide but probably not well-known outside the company I’m at right now.

Impact: Of all the tools I’ve used over the last 2 years this one seems to have had one of the greatest impacts on teams and the most viral spread within the organization I work with. Even the management team now red card each other and they don’t even have the cards in the room. Like all good verbal anchors, everyone now knows what “red card” means during discussions. Better still – even on difficult teams I’ve not yet seen anyone use red cards in a socially unacceptable way.

Try red cards out on your next big retrospective – you might want a stooge to break the seal first of all and chances are you’ll need to set yourself up as the first target but once the team have been through this once, facilitating meetings will become more of a team sport than a job for you.

What’s on Your Radar?

Posted on by
Reply
Reading time ~ 2 minutes

This is a great tool that I first saw used by Thoughtworks for showing changes in technology trends over time…  http://www.thoughtworks.com/radar/ (I don’t know who invented it). The TW example is very busy – there’s a mountain of new & changing technology trends out there!

But. This is a fantastic simple tool for tracking changes in your own domain or environment. And it doesn’t have to just be technology, this could be customers, prospects, types of work, focus areas, anything.

Here’s a sample I’ve put together for agile coaching . The Arrows show a change in focus since the last review (typically quarterly).  This is deliberately not an exhaustive sample but gives an idea of the what you can achieve.  It’s a great clarifying tool for both your coaching teams and your stakeholders.

Detail on the numbered items in this example:

1: TDD – Introduce, train & coach TDD practices. Ensure teams have the tools available to do so and the space in their schedules to do a decent job. Performance will turn the corner after an initial productivity dip so this needs a lot of care & attention.

2: Code Smells – Train teams on identifying code smells and when to act. We need to back this up with being polite & positive – perhaps some collaborative walk-throughs.

3: Refactoring – With TDD & Code smells, teach the “right” level of refactoring. There’s the natural refactoring needed during development and then there’s the open heart surgery of bad legacy code. We could refactor entire products and move nowhere (@see Netscape). Need to make sure this pragmatically taught.

4: Embedded coaching – with the major increase in XP and technical practices over scrum, we greater technical embedded coaching capacity.

5: No new code without tests – Make it socially unacceptable to check-in without tests unless there’s a real reason. (“It’s not testable” is usually an excuse, not a reason)

6: Shared code ownership – It might have been your baby once but it’s time for others to see how ugly it is and help you pretty it up. Nobody “owns” code any more, no matter how much of their creative heart & soul is invested.

7: Zero defects – We still have a crazy defect backlog. Let’s stop the bleeding this year and get it under control. Longer term we’re looking to get down to a stable level of entitlement.

8: Feature Teams – we’re working as product delivery teams and communities of practice right now which is ok but we need to get to a point where we can deliver fully working features through the product suite as a cohesive team without handovers.

9: Scrum – teams are all now using scrum as their overall operating framework, observing the “rituals” etc. We still need to watch & adjust but the main effort is over, this is now normal operation for the teams.

10: Agile Metrics – We’ve taught the teams and managers how to understand the new data they’re seeing, use it to their advantage, to make reasonable forecasts and highlight problems early. Again this will stay just over the horizon, it’s not going away but not something we plan to revisit for a while.