I like to think of collecting team data as another feedback loop in an Agile environment. After all, the people doing the work know best! Therefore, why not collect data points from teams to identify areas for continuous improvement throughout the organization? I had some success in this area, but unfortunately this approach has not always lead to the desired outcome.
As a young and naive coach, I took an engagement with a traditional monolithic bank. The culture was one littered with process control, and command and control leadership. The organization wanted to be Agile in name only but I was too early in my journey to recognize it. Leadership and the notorious PMO needed to collect data in order to report project progress across multiple teams. After a little excel magic, I was able to craft some visuals and reports to meet the need.
It got ugly fast! My data was used to punish teams, identify poor performers, and hold Agile PMs accountable for something they could not control. I left the office every day with a sense of betrayal to the Agile community and my friends at the bank. Here I was, a so-called coach, fueling anti-patterns such as abuse, reprimand, and process control. What a mess!
Like everything else, I learned from the experience. I realized that organizations in the early stages of their journey may have leadership that has not acquired the Agile mindset. They are not focused on happier employees, delighted customers, and better business outcomes. They likely still lead with a command and control style, utilizing data to drive behaviors, and measure performance, People working in a command and control environment typically do not trust those around them, and do not feel safe. When trust and safety is absent, people will be fearful of transparency and honesty. As a result, the data is typically fabricated, gamed, and not reflective of reality. Sadly, this leads to strategic decisions made on false data, ultimately compounding the dysfunction and preventing the company from reaching its goals.
So as change agents, we need to tread carefully when we introduce data collection and analysis techniques into an environment undergoing an Agile adoption. My advice is to stall as much as possible in the early stages. Focus your energies on coaching teams and leadership to acquire the mindset so they are ready to use data in the right manner.
Sure, you will have some organizations that will require metrics from the onset. In this case, try to stay away from leading indicators such as traditional velocity and story point delivery ratio. Instead, challenge leadership to track lagging indicators that measure the business outcomes they are seeking as a result of the Agile adoption. For example Net Promoter Score (NPS) is a lagging indicator of customer satisfaction, and Feature Cycle time is one of time to market.
The measurement of lagging indicators will buy you time as a change agent to coach the teams and leadership. You are also preventing the adoption of bad behaviors that vanity metrics drive. But beware! Any good leader will inquire about leading indicators that help gauge whether the organization is on the right track. Fair ask! Stay tuned; my next post will focus on leading indicators necessary to measure the effectiveness of an agile adoption!