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.
CRAIG SMITH has been active in the IT industry for over 15 years and an Agile practitioner for over 10 years. As an Agile Coach he has worked on a number of high-profile technical and business projects.
Early on my Agile Coaching journey, I was fortunate to sit in a talk by Johanna Rothman, author of some excellent Agile books including ‘Manage It’. Her advice when helping an Agile team was to always set an end date for the engagement and to ensure that you that you do not put yourself in a position where you get relied upon. That early advice set the scene for my coaching engagements going forward.
Being an advocate for TDD (even in relation to non-software development tasks), I have always been a strong advocate for ensuring that I set acceptance criteria for my coaching engagements. This is particularly important because often it is not easy to see improvements or attribute them to the Agile Coach. As I often tell new coaches, the role can be lonely as success is often standing back and watching the team celebrate success or the fact that they have improved their way of working.
Measuring return on investment is difficult. I often like to set up a coaching wall that visualises the teams I work with and the progress that is being made. Maturity assessments can also be used for this purpose, as long as they are fit for purpose. Measuring against tangible dollar benefits can be difficult, but acceptance criteria can always be found in my experience.
Inside an organisation, Agile Coaches have a strong responsibility for cultural change, and as such have ‘skin in the game’ at that level. Ultimately teams are responsible for software outcomes, however if a coach is assisting a team in improving their approach (either in process or technical practices), then they should share some of the responsibility with the entire team. However, in teams that are new on their journey or are trying to tackle significant software quality issues, it is often difficult to address where exactly to direct your attention, as you always want to look for opportunities to help the team improve and not simply fight spot fires.
There is nothing wrong with rolling up your sleeves to assist the team, and I always try to lead by example where I have the expertise. However, I believe an Agile Coach role is there to guide and mentor the team with an aim to leaving in the future. If you want to stick with the team long term, you need to deliver value, and therefore coaching should be a secondary part of your role. This should definitely be the case for roles such as Scrum Masters and Iteration Managers.
…our goal is to deliver great solutions, not great Agile, as it is really just the means to an end.
As I always mention when educating people new to Agile, our goal is to deliver great solutions, not great Agile, as it is really just the means to an end. I am a strong believer in always being pragmatic. The issue often arises when training or coaching individuals and teams is that they believe their existing approach is the only approach, and you can sometimes be blamed for trying to push ‘Agile’. Therefore coaching is a big toolkit that I am always adding too, and coaching teams means diving into the toolkit to find an approach that will help them improve delivery.
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.