When I listen to people talking about agile coaching, it’s nearly always in the guise of transformational and business coaches. I’ve only ever once seen coaching of technical people by technical people, and the difference it made to the quality of engineering was visible to anyone who cared to watch the team work. I didn’t even need to look in the codebase to know that it was understandable by all in the team.
I’ve recognised for a long time that there are few technical agile coaches, and I have even raised the need for such coaching when talking with leadership teams in my last few engagements. When I raised the idea in various agile circles I’m part of, people disputed there is a need for coaching Tech. One coach even told me that devs don’t need coaching because they have senior developers and architects. As though product people don’t have a hierarchy too… If we agile people are to poke our noses into how Product does their work, we should do the same with how Tech does their work. If we are here to introduce and improve an organisation’s agility, we need to care about agility throughout the whole system, not just the easy bits.
I work with Product to ensure the problems they want developers to solve are clear, well understood, and defined so that we can be confident when the problem has been solved. I do this so the developers can quickly solve these problems without any misunderstanding or conflict occurring. This is business agility. However, there's not much point in having business agility if we don't also have technical agility. A codebase needs to be well written as much as a user story needs to be. Anyone working on a team needs to be able to drop into a completely new code file and understand what is happening as quickly and as easily as possible so that they can start and finish solving the problem. We also need redundancy in understanding and knowledge about the codebase within the team so that when someone is away or permanently leaves the team, we don’t lose the knowledge as well as the person. Not having access to that knowledge for any reason slows development, after all.
(A thought to be explored another day, but is the rise of consultancies something to do with this? After all, anyone can talk business speak; one actually has to be skilful in order to write code.)
I wonder if we have missed some piece of the agile puzzle by not supporting software developers working in agile environments to become agile software developers to the same extent we support product people to become agile product owners. How many software developers do we hear on the Internet complaining about agile happening to them? In the last dev team I worked on as a dev, a colleague told me he didn’t like working in Scrum. He was surprised when I told him we weren’t really doing Scrum. So surprised that he asked the opinion of the Product Owner, Scrum Master, and Agile Coach working with our team. They all agreed with me. Had “developer me” not known better and disputed that we were doing Scrum, my colleague would have continued through life as a software developer who hated having agile done to him.
When I left software development to pursue a coaching career, I was largely motivated by wanting to protect future software developers going through the kinds of things I had gone through in my career. To date, I’ve supported hundreds of developers indirectly through direct intervention with Product. I’d really like to have a go at supporting them directly through direct intervention with Tech.
So, with this at the front of my mind, I do what I always do when I want to progress an idea and hit my bookshelves! As a result, there are now half a dozen agile software development books on my desk that I plan to revisit to create a coaching plan for software developers.
I think I may be about to become technical again…
Wow! "One coach even told me that devs don’t need coaching..." That's shocking. I've often engaged XP/Clean Code coaches for organisations I've consulted with. I agree, the difference is tangible very quickly. So many developers have been poorly taught that code-coaching is actually essential if Scrum (or actually every single other way of working) is to be successful.