Recently, I have been deconstructing with curiosity my role as an Agile Coach.
Let me begin by saying how committed I am personally and professionally to the deeper understanding of Agile and Lean. Putting these values and principles into practice over the past few years has given my work meaning in so many ways.
That being said, I have failed to appreciate the importance of how the organization views these skills…
I believe that a good Agile coach acts almost imperceptibly. Building courage, simplicity, communication, feedback and respect… all that a coach does in order to build a stronger and more effective team might not be obvious. Indeed, as coaches, we can become so focused on the success of the team that we may risk neglecting looking after our interests within the organization.
That is to say, there may not be clear evidence of the coach’s value to the organization. So while executives may recognize the improved effectiveness of the team, they mistakenly begin to assume that the coach’s skills have been captured by the team itself. They then conclude that this process can be reproduced (rubber stamp like) to other teams. To borrow Dave Snowden’s analogy… they believe that “having a good recipe” is the same as “having a good chef”.
As practitioners of evidence based learning and progress, how do Agile coaches provide evidence of their value to an organization? Is this even skillful or necessary to do so? I look forward, dear readers, to your feedback…
3 thoughts on “Seeking Feedback: Value of the Agile Coach”
I think internal agile coaches have a tough time of it since it is easy to become pickled. Meaning that eventually you stop having the difficult conversations and become part of the system. It is quite hard to fight that urge after being there day in and day out.
As for measuring and communicating progress, for that I use a technique called Change Strategy Mapping. It is something like a blend of Future Reality Tree and a Mind Map. In the middle you put your Goal, which is hopefully some type of business outcome. Then surround it with the needed Capabilities to support that Goal. Then surround the Capabilities with Tasks that support the Capabilities.
For example your companies “Goal” may be “To Deliver Products Faster that Customers Need”. The Capabilities needed to support such a Goal may be things like “Continuous Delivery” “Customer Empathy” “Rapid Experimentation”.
The Tasks for supporting those Capabilities can be quite numerous. For example, Tasks needed for “Continuous Delivery” could be “Automated Unit Testing” “Automated Functional Testing” “Continuous Integration” etc.
Once you visualize all of that, it is overwhelming to try it all at once but you can use it as a Strategy Tool for orienting yourself and the initiative. I also recommend putting measurements around each Capability. You can measure Continuous Delivery with Cycle Time / Lead Time, etc.
It isn’t a perfect approach, but it is a simple way to illustrate strategy and progress. You can always pull the tasks off and run them through some type of Kanban board for your change initiative.
Hope this helps some.
Thanks for taking the time to share your experience and strategy for demonstrating progress. I like the idea of establishing goals, capabilities and then tasks. Thank you especially for the idea of “capabilities”… this allows the team to bring forth more nuanced ideas and then attach them to tasks (allowing values and principles to come forth more explicitly in a project). The mind map also helps to drive home the idea that it’s a living thing… every bit as context dependent as the team and the project.
As we have just started the Agile coaching program at our company, we are trying to figure out how to evaluate our own department’s work. I like David Bland’s proposal. I have been planning to help the teams develop a set of goals for themselves. While the point is primarily to allow the teams to build their own culture with some intention, I think that what he suggests could be used to evaluate progress, which the teams themselves want to measure.
We’ve also been considering a broadly distributed set of evaluation points, sort of along the line of what Daniel Pink suggests in his book “Drive”. My attempt at paraphrase: the goal is to avoid easily-gamed metrics in favor of multi-faceted assessments that observe progress without twisting it. This seems particularly important for Agile coaches, where so little is concrete. Given a single hard metric, we might be tempted toward its clarity and away from the hazier but truer range of goals under the umbrella of fostering good Agile practices and continual team improvement.
What might this set include? Haven’t gotten that far, but it seems to me that it must be designed around the Agile principles somehow. My thoughts are surveys to assess various areas. The team could feed back on their sense of their own progress; on their view of the coach’s level of support; on the sustainability of pace. The business could reflect on the level of focus on true user value generated as opposed to simple quantity of work produced; on the ability of the team to respond to change, to innovate. It would be tricky, but I think that with rubrics to eliminate some of the subjectivity, it would be possible to develop a meaningful array of measures.
I hope this is useful, and I hope others post some ideas on this very tricky topic!