0Coaching: Agile; Agile: Coaching

We've been doing quite a lot of coaching here at Black Pepper over recent months, mostly as part of our ongoing commitment to continuous improvement, but also because coaching is a fun and rewarding exercise in it's own right, once you get your head around it. A lot of current coaching theory evolves from the work of W. Timothy Gallwey in his seminal book The Inner Game of Tennis, first published in 1974. Gallwey's core insight was that to be a better tennis player, you need to focus on the right things and avoid distractions: Your inner mental state is key to peak performance. If you start to let small issues interfere with your thought processes - the little voice in your head saying "I have to win this point... I wonder where he's going to serve next?... don't play to my backhand..." - you'll succumb to fear and doubt and ultimately have a bad game.

Gallwey observed that the enemies of peak performance were distractions or interference from:

  • Fear
  • Lack of self-confidence
  • Trying too hard
  • Boredom
  • Anger and frustration

and advised coaching as a way of providing focus from these interfering thought, in order to facilitate the learning and development of others.

Many coaches advocate a non-directive and questioning approach to getting the most out of people. So rather than telling a tennis player what to do to improve - "hit the ball over the net, stupid" - you engage with the player to see what they notice when striking the ball, what they could do differently, how they think they can improve, so the person being coached becomes more focused on their mental state of playing a good game rather than worrying about following instructions. Coaching shouldn't be about telling someone what to do, it should help that person become better.

It struck me that there's a huge parallel between this coaching approach to helping personal development and the agile methodologies we hold dear. The old world of software development was fairly prescriptive - gather requirements, do a design, build some code then test it - whereas an agile approach fosters an environment of focus, reflection and iterative improvement. By design, agile practices encourage better performance, both of the development team and the project as a whole.

If we look at the five sources of interference above in a software project setting:

  • Fear - of not delivering on time, to budget, or to the quality expected. Mitigated by estimation of requirements into story points and burn up charts to show progress against plan from day 1.
  • Lack of self-confidence - in the ability to produce a working solution. Mitigated by test-driven development to show the system will work once the code is complete.
  • Trying too hard - or overpromising in requirements and timescales. Mitigated by better estimation and limited work in progress during iterative development.
  • Boredom - or the death march of a project with milestones too far ahead. Mitigated by working on smaller requirements captured as stories and played through shorter iterations, bringing success frequent and often.
  • Anger and frustration - at lack of progress or visibility of the end of the project, or loss of control. Mitigated by prioritisation of stories by an active product owner and a card wall to make the work and workflow constantly visible.

Ok, so some of these may be a little contrived, but in all the time I've been coaching on agile I hadn't thought of the parallels between coaching techniques and the better practices of software engineering. With that bit of reflection under my belt, I hope to be a better coach and a better agile practitioner.

With thanks to the guys at Space2Think for creating the space to think about this one!

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.