- Coaching/Facilitation
- Consulting/Giving advice
- Mentoring/Guiding
- Training/Teaching
Some Examples
I once worked with a product owner who’s team hadn’t quite jelled. Four days before the sprint end it was apparent the sprint goal would be missed and he asked me if he should abort the sprint and start a new sprint. We talked about about the options and I asked, “What would you like to have happen for the team?” He stated he wanted the team to learn from the experience. Since we both wanted the team to learn I asked the follow on question, “Do you think they will learn more by aborting the sprint, or facing the unfinished stories at the sprint end?” We continued the conversation until the product owner decided to let the sprint continue and see how the team handled the retrospective. (Coaching/Facilitation)
“What’s the best way to keep track of impediments I’ve resolved?” asked a new ScrumMaster. “Hmmm. And why would you want to do that?” “Well” he continued, “I’d like to make sure the team knows I’ve completed the effort, and look to see if there are patterns in the impediments that get mentioned.” We discussed several different possibilities and then I asked, “What is the simplest thing that could work?” “As a PMP, I’m used to keeping track of risk summaries in a spreadsheet. I could use a spreadsheet with four columns showing the impediment, when it was mentioned, when it was resolved, and how it was resolved.” “Seems reasonable to me. Why not start there, and see how it works?” (Consulting/Giving advice)
“We can develop faster if we split the QA functions into a different sprint.” the team’s alpha developer asserted. “Is that so?” I asked. He assured me it was, so we, the ScrumMaster, he and I headed into a room where we started filling the white board with sprints, code and defects. After an hour or so making sure I understood his ideas, and then extending his example, always asking “And what happens to the defects we find here?” I finally asked, “And when can you declare the code is ‘done, done, done’?” The conversation shifted to Chinese and 30 minutes later I was informed “We’ll rotate different developers to help the QA people write their automated tests.” (Mentoring/Guiding)
“Tell me more about how you pair program.” I asked. “The pair works on the same task. One writes the test and the other writes the code. We’re doing TDD.” came back to me. “And they do this from a single keyboard?” “Oh no, each developer has his own machine where he works.” I heard. This may be some sort of co-development, but it doesn’t fit with my experience of TDD (write the failing test, then the code to make it pass) or of pair programming (two developers, one keyboard). Thus started a conversation about how teams use TDD and XP to create high quality code. (Training/Teaching)
Up and Down the Org Chart
Agile coaches work at many levels. They work with individuals, teams, and others in the software development and business functions. Some coaches tend towards technical skills. Others focus more on organizational change issues and collaborative skills. I’ve learned much about being effective at these different levels and skills over the years at the AYE Conference.
Why Would You Want an Agile Coach?
My colleague Esther Derby listed Five Reasons to Hire a Coach for Agile Teams. You should go read it. I’ll wait …
I’d like to offer three reasons in addition to Esther’s.
1. Experience – Agile coaches have been through the change process before. If you don’t think moving to an agile development method involves change don’t worry, you will know it does soon enough. The Satir Change Model graphic at the bottom of Change and Stable Systems shows how people react to change. Having someone who’s “Been there, done that” has a calming effect.
2. Energy – As Esther pointed out, you’ve got a ton of other stuff you need to be doing anyway. Having an experienced person who can coach, consult, mentor and teach reduces wear and tear on you. It also shows the team that management is serious about making the change work.
3. Enthusiasm – The agile coaches with whom I associate enjoy working with development teams and organizations that want to become more effective. We can’t imagine wanting to do anything else. To that end we’re always working on improving our skills becoming more effective helping you become more effective.
These three reasons, experience, energy and enthusiasm combine to reduce the amount of time it takes for your organization and teams to become more effective, there by increasing financial returns sooner. So with sufficient good coaching, you create a increase revenue stream and create continuous improvement, for just a one time payment.
Have other ideas on why to use an agile coach? Drop me an email.
Don, thanks for the post. Just found it this morning. I like how you describe, using examples, how you coach your clients to think for themselves, rather than just dole out guru advice. This is style of helping is much needed in the software world. Take care /Tobias
Awesome examples on how a coach can ask questions and help the client come up with options and select a solution.
Thank you!
As always, nicely stated. And, as always, you give me something to read and then some more. 🙂