Data-driven, Metric-driven

Some say they are the same – metrics are computed on data. So, I must be data driven if I am already metric driven.

I claim that they are different. Agile combines them together in a nice way.

You would be metrics-driven to achieve a goal. Goal coaches insist that goals should be SMART (Specific, Measurable, Attainable, Realistic/Relevant, and Time bound). E.g., I want to be an millionaire in one year is a SMART goal, that can be measured along the way (lead metrics) and once an year has elapsed (lag metrics). The lead metrics tell you whether you are on the right path to achieve the goal, while the lag metrics tells you whether you have achieved or how well you have achieved the goal.

You would be data-driven when you have to deal with ambiguities. Data coaches insist that good quality data must be captured continuously to seek insights that can be converted to knowledge and actions. E.g., I want to drive academic excellence for my child this year. This statement does not tick all the boxes of SMART. It does not say that my child should score A+ in mathematics. There is inherent ambiguity in the statement and choice of words (“excellence”). In such situations, you collect data from tests, teachers feedback, and your own observations. Based on the data, you get insights – the child is great at arts, excellent at mathematics, and needs improvement in language. You then focus on sustaining the strengths (arts, mathematics), and focus on development needs to improve academic excellence. Being data-driven is all about seeking actionable insights. You may make a decision to not take any action to improve language skills and let the child excel in her strengths, but that’s still a data-driven decision.

Agile helps with the cone of uncertainty with the levels of agility. E.g., In a software development context, the team may look at lead metrics like flow velocity and team happiness to determine whether we are on the right track to reach the outcome measured by the lag metrics. However, the team will also look at data (new features, technical debt, customer feedback) to derive whether a change of course is required. So, you get the benefit of both being iterative. Being iterative, and taking small chunks of work to do (stories with 8 story points), you can be metric-driven (SMART) to measure say/do as a lag-metric. Also, grooming the product backlog with insights from data, you will be data-driven.