As a principal agile coach, my focus is to energize and inspire developers to adopt and follow through on the agile frameworks across our teams. Initially, I failed, as I didn’t really understand the mindset of teams that have been working in an open source ecosystem. My assumption was that since agile and open source values align so closely, the barrier for adopting agile frameworks would be low and our people would take to it like fish to water.

In the beginning, it was easy. There was very little resistance, except from a few who had really bad experiences in the past or believed that agile is not cut out for open source development efforts. Since most of the team members were on board, we went ahead and adopted scrum for most of our teams.

Three months into our agile adoption, we noticed that a few teams were performing well while others were struggling, so we felt it was time to start collecting metrics to objectively measure performance and to identify issues that led to success or struggle. We actively worked with two of our teams to start assigning story points to user stories so that we could determine each team’s velocity. It worked well, and, working with the teams, we were able to identify barriers and start fixing them.

Short-lived success

In my enthusiasm (which didn’t last long), I sent out an email to all my teams asking them to follow the same process. I wanted each team to start assigning story points to user stories so that we could measure their performance and take corrective actions at the end of the sprint.

What followed was a vociferous barrage of email replies from some of the best and brightest people about why this was not a good idea and why it would end badly. Responding by instinct, I started replying to the thread, arguing why this will help us and giving various analogies. The more I tried to defend my plan, the more resistance I encountered.

Pretty soon I gave up, as winning this battle by enforcing process would only make things worse, and I realized I would lose all the goodwill that I initially gained. I thought I’d pick it up later when the team grew comfortable and gained maturity with respect to agile processes and techniques.

My mentors, long-time Red Hatters, had been observing this unfold from the background. They helped me look at it from a different angle. The leaders in our organization were interested in finding the positive impact of adopting agile frameworks in a holistic sense; it wasn’t just about the performance of the teams. They wanted to know things like:

• How agile is our organization?
• In which areas do we need to improve?
• Is there a way to visualize progress?
• What metrics are being used to track our agile transformation?

Unfortunately, most of the available tools and techniques track the productivity of teams or how well the processes are implemented, rather than getting into the heart of the problem.

Instead of relying on velocity or adherence to processes, we measured the teams’ true agility by assessing their growth and capability, not just productivity. We felt this could be done by reflecting how closely their behaviors, actions, and decisions aligned to the core agile principles.

We introduced a radically new approach to tracking our journey of agile transformation. We started by creating an environment where these four behaviors were actively encouraged across the teams in the context of their agile journey:

• Experiment: Let us keep it fresh
• Share: Let us start with what we know
• Listen: Let us observe and reflect
• Learn: Let us develop ideas and understanding

When teams were given the freedom to experiment and develop their own flavor of agile, there was a lot less resistance and a lot more enthusiasm for continuous improvement. Since the teams were actively sharing, we started cross-pollinating the ideas and information into other teams. The teams were now mature, and self-correction started to happen whenever something didn’t work out as expected.

A new approach: Agile Reflection Deck

We developed the Agile Reflection Deck, where we divided the 12 agile principles into three templates consisting of four principles each. After each iteration, the team would reflect on how aligned they were with each of the principles and rate themselves on a scale of 1 to 10.

As the 12 agile principles are universal and generic, the teams had to engage in a lively discussion to gain a consensus on what each principle meant for their team. Then they had to average the team members’ ratings and plot that number on the axis where the agile principle was listed.

As we were a highly distributed team, we used online survey tools to capture the ratings during video conference sessions and then displayed them on the Agile Reflection Deck. Once we had the four ratings mapped onto each axis, we connected the dots to form a quadrilateral. Over time, the shape and size of this quadrilateral gave us a clear picture of the teams’ agile mindsets.

By allowing the teams to self-reflect and analyze how closely they were aligned to the agile principles, we were able to unlock the potential and ability for the teams to improve and grow with each iteration or checkpoint. We had truly empowered the teams to map their journeys and make self-corrections to chart their course to agility.