Coaching

In 2001, a number of leaders from the software industry came together to discuss the best ways they’d found for creating software. They came up with the Agile Manifesto. This part of it has long been my favourite:

We are uncovering better ways of developing software by doing it and helping others do it.

As a developer, I do it. As an Agile coach, I help. A coach’s job is not to deliver software, or even to uncover better ways of delivering software. Instead, I help individuals, teams and companies to make these discoveries themselves, by providing tools, creating a safe environment in which learning and innovation can flourish, and helping to identify resources to support improvement going forward.

My role as a coach is less about developing software than it is about developing people. As such, I value:

  • playing to strengths over addressing weaknesses
  • trying things out over following processes
  • learning from experience over avoiding risk
  • creating pleasant surprises over meeting expectations

That is, while there is value in the items on the right, I find more value in the items on the left.

When I coach, I use the aims of my client – usually delivering software, or having a team which can follow Agile practices successfully – as a driver to pass on these values to the people I’m coaching. It also outlines my own approach to coaching.

Agile Values

Methodologies like Scrum, XP or Kanban have various strengths and weaknesses.

Scrum’s scope involves managing projects and analysis, and it does not include the technical practices necessary for consistent planning using sprints. XP’s technical practices are rigorous, and can be difficult to adopt and requires a rigid adherence to the practices, at least in the early days while teams are understanding them. Kanban can build on existing strengths and adapting existing processes, and often works best with other, more disruptive processes to enable quick movements from broken practices to something new and different.

Regardless of which methodology we choose, each of them leverages a set of underlying personal values which must be present in order for them to succeed. These values, vaguely aligned with being a “good person”, can be defined, measured and used as a target in a way which is hard to game.

By adopting certain values alongside practices, and encouraging teams to do the same, we can provide a safe place for learning and innovation, while drawing the practices into a form which efficiently leverages the values. This makes Lean and Agile adoptions more likely to succeed, makes individuals feel less like they’re part of a meat-grinder change, and provides a solid foundation for teams to adapt their processes going forwards.

The values I like to use are:

  • respect – the belief that other people are valuable, able to teach you something and amaze you, able to succeed given experience and support, interested in others’ well-being and success, and motivated by the desire to make the world a better place; and that any behaviour to the contrary is caused by external pressures or ordinary, forgivable human frailty
  • courage – willingness to try new things which might not work, to accept personal risk for professional gain, to make oneself vulnerable in order to learn, and to lead others to do the same
  • communication – the art of making oneself clearly understood, understanding others and feeding back any lack of understanding so that it can be corrected, listening and imagining, being aware of the impact of communications (verbal and otherwise), and finding other ways to communicate when required
  • simplicity – the ability and desire to to start, where it’s possible to start, without worrying about how or where it will end, while keeping options open so that we can react to what we dicover
  • feedback – knowing that our perception of our world and the ways in which we model it may be inaccurate, actively seeking out those inaccuracies (which may require courage!), trusting any existing mechanisms which can inform us of those inaccuracies, and listening to them when they do.

The values are from Kent Beck’s XP methodology; definitions are my own.

Read my blog post on Cargo Cults and Agile Values, or contact me, if you’d like to know more.