8 ways not to suck as a coach

Wow, how is that for being controversial? But hear me out…

Ever since I became involved in helping others agile for their software and business needs, I have seen articles published on “What does a coach actually do?” It seems obvious to me that many of the people who author these articles (and I am sorry if I offend anyone here) has little or no experience actually coaching. Maybe training, maybe mentoring, maybe even implementing agile practices, but little experience actually coaching.

I did say sorry…

So here is my opinion on what coaching is all about – and these opinions have been formed over several decades of being coached in both business and sports venues, and coaching others in soccer, rugby union, curling, as well as agile and other business disciplines. My coaching style is greatly influenced by advice I received years ago when I first started coaching soccer. In many ways, what you’re coaching is secondary to how you coach, because coaching is ultimately about helping individuals be their best – it doesn’t matter at what.

Below (in no particular order) are 8 key tenets that help me be a better coach.

1. Fundamentals First

If you cannot teach the basics of the game (or approach) to the very people you expect to participate, you are doing them a huge disservice. This usually focuses on the outcome of the game, the goal, the way to win, and less on the techniques involved. As a coach you should be able to clearly articulate the fundamentals. Until the coachee follows you and understands explicitly what the fundamentals are, without necessarily understanding how to apply them, you’ll be wasting time trying to accomplish anything more advanced.

2. Draw From Personal Experience

In sports, you do not have to be a superstar at the game itself to be a great coach. Indeed most of the top managers and coaches in most (all?) sports were not top players during their careers. But they did “get it”, often learning from failure. As a result, they know how to minimize the chances of failure in those they now coach. That’s because these sports managers and coaches once played the game themselves, and have tons of experience to draw from as they coach their teams. To be an effective coach, you have to dig into your personal experiences and help communicate how they affected you and helped you see a different perspective or stop making the same mistake over and over again. When you coach the team, for example on how to plan, how to pair, how to be effective during their daily stand-up, remember your own experiences (however painful) and be frank about them. What false assumptions did you make? What bad habits inhibited your own growth and stymied team progress? Chances are, your coachee is experiencing challenges similar to those you faced starting out.

Personal experience is great, obviously, but don’t teach only the techniques you are personally familiar with; expand your world too, learning skills outside your comfort zone to the point where you can teach these to your team as well.

Key learning (and sorry again for the sensitive readers): if you have never delivered projects as part of a team using an agile approach, stop trying to coach others on how. The least effective coach is the one who knows the textbook but doesn’t have any experience to draw from.

3. Stay Positive

This is especially true when communicating with the team and others in the organization(s) you are coaching. Do not “run down” others, but use their failings to explain what you want the team to do, and why you want them to do it. Be positive in the face of failure, focusing more on the learning from the failure than the result of the failure itself. And insist the rest of the team maintain the same air of positivity – it becomes infectious!

4. Provide a Safe Environment

The team consists of people – and we need to encourage these people to express themselves and their beliefs. This is especially true when sharing bad news.

As a coach, we need to work with individuals to allow them to tell others on the team what they think and feel, but in a positive way. Telling a developer “your code sucks” doesn’t provide any actionable feedback on what to change to make the code suck less. There is no indication in this statement about what or how to improve. Instead, use examples of poor coding practices and provide constructive feedback. For example: “I see you cut-and-pasted the same lines of code four times here. Would it help to write a method instead?. Maybe I can help you with that?”

5. Provide Direction During Sprints

I don’t especially like to direct people – I much prefer to enable people to do what they think is most appropriate. But during the first few Sprints, it is important that we bring some structure to the development effort and put in place consistent practices for the team to use. Once people understand these approaches, the coach can (and should) back off, creating a safe place for the team to assume responsibility for their actions. Coaching is as much about knowing when to shut up and watch as it is about, leading, so practice only providing input where necessary.

6. Focus on Character Development

Once the team understands the basics, the rules, and the practices, you need to switch your approach to helping them develop personal responsibility for delivery. Some people are naturally gregarious, others may be shy. You need to find a way to allow these people to communicate and work together as equals, by developing their inner confidence, and allowing their innate character to shine through.

Introverts have it harder than extroverts, but the software world is full of introverts who, through sheer force of passion for continuously improving software systems, provide key talents and skills, even if they aren’t the type to prattle on about what they do or how. Part of creating a safe place is ensuring individuals with different personalities aren’t inadvertently neglected in a room full of extroverts. Character development doesn’t mean that everyone assumes the “best” character type (e.g., extrovert, introvert, shy, gregarious, etc.); it means that the actual characters in the room are able to contribute to the work without feeling disenfranchised. And it’s your job as a coach to help the team strike that balance.

7. Grow Some Thick Skin

As a coach, you are changing the work rules, not just for your team(s), but for everybody around them. For that reason you will hear lots of negatives, and experience people trying to stop what you are doing both actively and using their best passive-aggressive approach. If you give in to this negativity and let it affect how you work, the entire team will also let it limit them. If you do not have the ability to be positive in the face of these obstacles, your success will similarly be limited.

Growing thick skin doesn’t mean abandoning your values or being cold-hearted; it does mean that sometimes you’ll be the only one who believes that what you’re doing is right. With perseverance and dedication, powered by data and clear objectives, over time you can transform the jeers into cheers and turn opponents to change into proponents. You know it (whatever “it” is) works because you’ve experienced it before. Your opponents most likely haven’t seen it work before, so they doubt. But you shouldn’t let yourself – and above all your team – give into that doubt. Be the example of belief that acts as a beacon in the dark of uncertainty.

And the best way to shut doubters up is by producing results.

8. KISS Me

The US Navy have a saying: “Keep it simple, stupid.” It’s called the KISS principle now. I rather like Sir Alex Ferguson’s viewpoint on this matter:

“You see those training sessions where the coach is talking all the time and the message is lost – the words get lost in the wind. Talking too much is a big danger for a coach.”

A large part of a coach’s work is communication, true – but learn when to shut up!

Perhaps the best piece of advice was one I was given at the start of my working career a long (long…) time ago, which I’ll leave you with here:

You are there to get people to communicate with one another

This simple statement holds true no matter what type of team I am coaching, as no matter their individual skills, they cannot work together unless they communicate. If you do nothing else, get people talking to one another, learning from each other, helping each other. And once you get them rolling, get out of the way…

Changing the game – reducing the odds of project failure

In my previous post, I looked at the most common causes of IT project failure. So how can me reduce the effects of these issues, and maximize our chances for success? Well, let us learn from others – especially those in the agile software development community – who have been dealing with these issues for decades. Read more

The Trend of Failing Projects

Sadly, the biggest trend with large IT projects these days is that they’re often ending in failure rather than success. The larger the project is, the more likely it is to fail. According to a 2012 study by McKinsey; 17% of projects valued at 15 million or higher actually go over so poorly that they put the company’s existence in question. Of these high value IT projects, over 40% will fail. Bloch, Blumberg, and Laartz (2012) Read more

Process over results…

I seem to be stuck in a run of “process over results” – that is, organizations that are far more interested in getting the practices and techniques right without understanding what results these techniques are designed to deliver.

Let me give you an example. I was recently working with an established team who had a fairly poor history of delivering working software. Their iteration planning meetings run on-time and with the right people, their standups never go over 14 minutes, their stories are in the classic “as a….I want….so that….” format, and they have retrospectives at the end of each iteration.Yet they constantly fail to deliver software. Hmmm…. Read more

Job title inflation?

I like to keep contact with the people I have worked with, and the easiest way is, of course, LinkedIn. Lately, I have been seeing a lot of my contacts being “promoted” into new positions – but are they really?

Here are some of the job titles I have seen my friends being given… Read more

The Mediterranean Diet as a lifestyle…just like agile?

I recently spent some time in Valencia, Spain, and loved it! Whenever my wife and I travel together, we like to rent apartments instead of staying in hotels, as this makes us integrate a tiny bit more – we can buy and cook our own food, stay in or go our as we like, and adopt a little of the local approach to life.

Read more

My first webinar experience – and how it relates to your remote teams

I put on a webinar for ThoughtWorks in the UK 2 weeks ago, and it was a most interesting experience. My topic was “How do you accelerate your enterprise agility”, using 2 examples – eliminating all the wasteful practices we put in the way of our development teams, and how to choose the most suitable tools to enable your development. I will (probably) blog about these at a later date (if I have not done so already!).

What was most interesting to me was the lack of feedback from the attendees – silence, no physical clues, nothing. I was on one end of an internet connection, and my audience was on the other end. They could communicate by sending me written questions during the webinar, but no other way.

Read more

Deliver value – but how do we know?

We talk a lot in the agile world about “delivering value”. It is the focus of almost every agile workshop I have attended, is a catchphrase in the agile world, and is the focus of agile projects. But how do we know if we are delivering value, if we are doing the right thing?

When we plan an agile project, one of the things we do is assign point estimates (tee-shirt sizing, team estimating, etc.) to provide a framework to understand the relative complexity of getting a story to “done”. We also prioritize these stories so that we work on the “most important” story first, leaving the least important stories until later in the project. But we need to go further.

One technique I use is to assign “value points”, which, like estimating points, are relative measures of the value returned by each story. But what do these points mean?

All projects should have a financial aspect to them, be it increased revenue, cost of entry into a new market, regulatory exposure, or something similar. This financial benefit should, of course, outweigh the cost of the project, yet I see projects dragging on and on, eating more of the potential profit from each project. How, then, do we know when to stop spending?

Read more

Stop wasting your time…

Do it fast, do it now, do it well. We all want that, right? So why do we spend so much time writing – specifications, wire frames, technical design documents, and on and on and on…

Let me be controversial right away:

If you spend 3 months writing a document, and it needs more time spent on it to be relevant and understandable to the next group, you just wasted 3 months of your life!

Wow – anybody hurting now?

Read more

Agile Cobol on a mainframe? Who would have guessed?

Earlier this week I was at a large client that is designing a new, very complex, system that crosses every platform in their enterprise. They are taking an agile approach to this, and so far being very successful with experimentation to determine how all their divers systems and technologies can work together. Great stuff.

I was asked a couple of weeks ago to come and work with one of their “more traditional” Read more