I started off as a practitioner and over time, have been an Agile coach. There were a few interesting things about my journey that I thought would be good to share with the larger community. My post narrates a journey that many technologists might take – here’s hopefully to a learning or two.
What You Will Learn
- 1 “Aman, you’re the Agile coach on the next gig! You start on Monday, at the client’s office!”
- 2 “Focus on Business Agility. The client will want impact details wrapped in context.”
- 3 “Aman, what do you think of our standups? Why write a test when I’m confident of my code? How is acceptance criteria different from test scenarios?”
- 4 “Hey coach, another team needed help with unit testing. Since you weren’t around, I gave them a few suggestions. Is that okay?”
- 5 “Great job, coach! We hope to spread this success across teams.”
“Aman, you’re the Agile coach on the next gig! You start on Monday, at the client’s office!”
And with that statement, my staffing manager dashed my hopes of a (well deserved, in my opinion) vacation. I had just come off a complex client project as a developer and was looking forward to hitting the coast to unwind. But there I was, and onward I marched.
With Agile methodologies becoming a norm, organizations that want to catch up typically focus on an adoption strategy that involves hiring Agile practitioners. These new hires are expected to create and foster an Agile culture by coaching employees who may not have any prior experience with Agile.
Hiring the right people, however, is a slow process that does not match the pace of a quickly evolving business. This is where an Agile consultancy steps in. Coaches are seeded within teams to introduce gradual changes. In order to scale this approach, ‘coached’ team members don the instructor’s hat, the next time around.
I became the point man, when Tutorials.one was roped in by a client for Agile coaching. The client’s engineering teams were slow to make changes and had introduced defects in their misguided efforts to ‘do’ Agile. They were not backed by strong Agile engineering practices and were focusing only on Scrum’s management aspects.
The hope was that my ‘extreme programming’ background could save the day! Also, since I had spent many months as a coach for our comprehensive onboarding programme for new hires at Tutorials.one University, the staffing manager was confident about my accrued experience.
“Focus on Business Agility. The client will want impact details wrapped in context.”
This being my first official Agile coaching gig, I received support on various fronts. Both the Head of Consulting and the Head of Sales at Tutorials.one, shared possible focus points for my client interactions. While the former suggested highlighting Business Agility which is built on top of engineering practices, the latter encouraged me to be the expert consultant who confidently answers questions and shares informed opinions.
I took it step by step. I had learned that most coaching assignments have three stages. The first stage is Assessment, which typically lasts a week or two. This involves observing the existing processes by interviewing team members, measuring on technical and non-technical parameters and making firsthand notes. I looked up samples of process mapping exercises, baseline metrics, and assessment reports. My first week with the client was spent creating this report.
“Aman, what do you think of our standups? Why write a test when I’m confident of my code? How is acceptance criteria different from test scenarios?”
Second week onward, I focused on stage two of the assignment, Active Coaching. This stage begins by identifying near and long term goals in collaboration with the client. Techniques like retrospectives and future-spectives help in identifying practices and processes that address business and technical goals, with adequate measurement.
This week, every client team member was brimming with questions and opinions! Sometimes, their questions had me second guessing myself and I would quickly fall back on the strong network of fellow coaches at Tutorials.one to get my thoughts in order. The one mantra that lent me the confidence was that I did not need to have all the answers. I simply needed to guide the client on their path to self discovery and self learning. Encouraging brown-bag sessions, open discussions, and in-time communication is a good way to start the process.
Of course, this is easier said than done. Some people take time to adopt new practices and evolve their thinking. This can cause frustration – which meant that as a coach, I had to manage my stress levels. I read up on Agile coaching and found a mentor to guide me. As a first-time coach, one is tempted to look for early signs of positive impact in tangible metrics such as code quality metrics or test metrics. My biggest realization was that the goal of an Agile coach is to enable a gradual improvement, primarily among the people, and because of that improvements in artifacts like code base or test automation, will follow. Sometimes slowly, but it surely will follow.
I also learned to identify the quick learners and nurture them. It was they who would eventually become the team’s influencers and motivators. Key was to actively listen, empathize and motivate team members.
“Hey coach, another team needed help with unit testing. Since you weren’t around, I gave them a few suggestions. Is that okay?”
Over time the team became less dependent. I observed well facilitated retrospectives, well maintained visible charts and a green build radiator. Most user stories were completed and accepted, mid sprint. All of this without my active involvement. These were proud moments for me. People were realizing their potential.
This was also indicative of the third and final phase in the coaching assignment, Sustenance. This is where the external coach takes a step back. The ‘coached’ team becomes self reliant. Successful deliveries and happy stakeholders validate the coaching.
While I did step back, I kept checking on the team, every week. There were weeks with clear improvements. Some weeks, things remained as is. As long as the learned habits remained stable and did not wane, there was no reason for dismay. The best part were the smiling people.
“Great job, coach! We hope to spread this success across teams.”
Beyond Sustenance lies scaling the Agile adoption. Armed with new skills, the influencers and motivators within the client’s team are ready to coach others. Initially, they could be paired with an experienced coach, but eventually they will be ready to go solo.
Of course, a lot of this is dependent on personality traits. Not all great practitioners make good coaches. My advice would be to keep an eye out for individuals with potential and help them build their coaching skills. Also, remember that no one understands what it takes to transition from a practitioner to a coach better than you, since you are in the midst of making the cross over, yourself.
Summing up, a smart Agile coach is one who does not strategize from a distance, but embeds or at least sincerely attempts to embed themselves into the enterprise they are influencing. No matter the resistance, a coach’s reasoning, communication skills, logical thought process and empathy is what wins the team over.
Here is a quick snapshot of all that I had achieved in my ‘didactic’ position as an Agile coach for the project I have been referring to.
While I am sure that the content will evolve over time, the links given below cover concepts and techniques useful for a first-time coach.
- Active Coaching