In many organisations’ transformation to Agile, hiring an Agile Coach is an early step on the journey. What should you expect from your coach, and how do you measure success? Should coaches have ‘skin in the game’ and be responsible for software outcomes? And when the pressure is on, should a coach prioritise delivery?
Three Agile coaches share their views in a series of three blog posts.
BERND SCHIFFER is an Agile Coach, trainer, and consultant. He founded his own Agile company Bold Mover, and has been practising Agile and Lean for 12 years.
An Agile coach has skin in the game, but in a different game to the one the development team plays.
An Agile coach is not part of the dev team. The dev team owns the delivery process and is responsible for it, and the Agile coach helps them continuously improve the process. He mainly helps in letting the dev team make informed decisions by showing them or letting them discover the consequences of their doing. He never decides for the team, because that would mean taking over the responsibility for this decision. The Agile coach has no skin in the dev team’s game.
The Agile coach’s performance should be judged by the dev team regarding his quality of coaching, mentoring, facilitation, advice, consultation, expertise, and leadership. That is where he has skin in the game.
Every coaching engagement should have success criteria. How else would you know that you’re done as a coach? How else would you know what value the coaching brought to you as a client? Success criteria should be established before or at the beginning of the coaching. Typical measures are frequent delivery of working software, increased delivery frequency, decreased lead-time, higher customer and employee happiness, increased ratio between feature work and business as usual, and decreased number of bugs in production.
One of the core values of Agile is ‘working software’, and one of the Agile principles states that ‘working software is the primary measure of progress’. To deliver means satisfying the customer’s need with working software. My clients ask me as an Agile coach to help them deliver working software with Agile methods and If I don’t achieve helping my clients to deliver working software in their organisation, then clearly Agile is not the way for them. Typically, these clients are not dealing with complex markets and frequently-changing requirements. They value compliance to processes higher than being adaptable in a given situation. They shouldn’t use Agile, because Agile would be a bad fit for their culture. When I coach these clients, I recommend they stop trying to be Agile. On the other hand, if I do succeed in helping my clients to deliver working software in their organisation, of course it makes no sense for them to stop being Agile to deliver. Either be Agile, or not. And the other way around (stop delivering to just be Agile) makes no sense either.
Stopping Agile is killing the messenger – problems won’t go away if you stop listening to bad news.
Stopping Agile to get things done is a syndrome. Figuring out the underlying root cause is extremely rewarding. Once the root cause is revealed and counter-measures are in place, both productivity and mood rise. Stopping Agile is killing the messenger – problems won’t go away if you stop listening to bad news.
This post was originally published in AgileTODAY, a free publication featuring real Australian case-studies of Agile in the enterprise, and the latest hot topics in the Agile community. Find out more.