Scrum.org’s Scrum Open Assessment includes a question on what would happen if an organization tries to adopt scrum processes without changing their traditional terminology. One correct answer is that management may feel less anxious. While I don’t doubt this is true, my experience suggests that the converse is also true: management will feel less anxious if they start using agile terminology but do not change their processes accordingly. This can leave the teams in limbo as to which methodology they should follow, and lead management to believe that the organization is practicing agile when it really isn’t.
I once attended a meeting with other scrum masters where we were told that management wanted us to sync up on how we were going to do estimates; e.g. whether we would all be using the Fibonacci sequence. It seemed that management wanted to be able to compare apples to apples when viewing charts for the different teams’ work. This would be a sensible request if we used absolute time units like hours or developer-days to estimate work, but story points are a relative unit of measurement with a completely arbitrary scale. The definition of what a story point represents is unique to each team, so point comparisons between teams are useless at best and misleading at worst. The managers’ request also did not take into consideration alternative sizing methods like t-shirt sizing, which are not number-based and would be an even worse idea to try to compare with another team’s story points.
This is an example of management’s trying to shoehorn the traditional way of doing things into agile terminology. Without a proper understanding of how estimates and velocity work, as was the case above, it is easy for them to think that the traditional way of generating and reading metrics, and comparing performance across teams, will continue to work in an agile environment. This reveals a gap in their understanding that we, as agile practitioners, have the responsibility to address. Even though the final decision on how to run the organization is not ours, if we do not give managers correct information on how agile processes work and why, then we become part of a problem that could lead to disillusionment with agile and make it harder for the organization to reap its benefits, thus decreasing or removing value from the organization instead of adding it. In this case, we needed to help them understand that comparing estimates across teams is an apples-to-oranges comparison, and that’s okay.
More broadly, managers need to understand that agile adoption will change not only the developers’ way of doing work, but also theirs. And they need to be at least cautiously comfortable with that. Agile development is a very different paradigm than what many companies were built upon, and it requires a correspondingly large change in managers’ mindsets for it to be executed properly. As we patiently and clearly explain agile principles to decision-makers in our organizations, we will be more likely to gain their support for the change. And even if we don’t, we will still have added value to the organization by helping them make the most informed decision they can.