David Norton, Executive Director, CISQ

Note: This blog first appeared on Dave's LinkedIn on May 16, 2019 in a longer, more wittier form

The following comes with a warning! I am about to suggest something that many in the agile world will hate. Even as I type, I can already imagine friends in the agile community shouting, “Dave, what are you doing, we thought you were one of us?” I can also imagine people who are anti-agile taking the following as some sort of vindication of the failings of agile. Well, they would both be wrong. I am still an agile evangelist, and I am not defending anything – but I am a realist, and we do have a problem with agile when it comes to productivity measurement.  

Agile uses a Wide Band Delph technique for sizing, which is based on gaining consensus around a set of requirements, normally user stories, which are relative to each other. Humans are naturally good at relative sizing, for example, who is taller, which piece of cake is larger, etc. We are poor at absolute sizing, i.e., tell me how tall that person is in feet and inches, or how many grams is that carrot cake. 

The issue of agile sizing comes up when application managers are dealing with distributed development centres where agile is scaled using frameworks. It is also a major issue when vendor and sourcing management have to assess suppliers regarding productivity.

Currently, organizations are using a mix of strategy to deal with this challenge. Some, a small few, have changed their attitude at the Cx level in regards internal teams and with suppliers and stopped asking for absolute productivity measures, electing to focus on outcomes instead. A number of organizations have developed their own story-based absolute sizing frameworks, but these miss the point of the benefit of relative sizing to the teams. Sadly, most organisations are fudging agile productivity metrics.

But what if there was a way to have our cake, relatively-sized, and eat it, too? It is time we introduce the villain of the piece and my old foe – Function Points Analysis (FPA).   

FPA and I have had this love-hate relationship until I joined CISQ, where at last, I could see how to rehabilitate function points, making it less boring, less of an overhead – by not doing it! Well, to be more precise, making function points invisible, automated, and part of the tool chain. To have our absolute-sized FPA cake and eat it. 

This is where the new Object Management Group® ISO standard, developed and published by the Consortium for IT Software Quality™, comes in ─ “ISO/IEC 19515:2019 Information technology -- Object Management Group Automated Function Points (AFP), 1.0.”

It’s feasible to embed ISO 19515 into the teams’ or portfolio tools allowing automated function points to be collected in the background based on the source code - freeing teams to focus on value. Teams could use relative story-point sizing correctly to help plan and work with the product owner. Functional size productivity data can be collected in a fair and consistent way across the enterprise – without manual function point counting. We can use a hybrid of relative and absolute methods.

This would not be duplication as the approaches would be aimed at two different goals with real benefits to the team and management;

• Teams can use story points correctly; for sizing their backlog and planning their sprint without having to normalize or fudge the story point process to allow management to compare across teams. 
• Teams can stop story sizing altogether if they want to, if they feel there is no value in it, for example when the story size has coalesced. But productivity data can still be collected.
• It can help see the big picture for example defect density across the domain and multiple teams, or average release effort of the DevOps tool chain. 
• Gives CoP/Guilds common datum for improvement and experimentation they can use to form part of a business case for new tools, skills training, etc.
• Allows teams to compare maturity using a common and consistent datum, for example, the percentage AFP that were tested automatically or the AFP through-put.
• 3^rd party sourcing teams can focus on value without having to provide endless metrics to the bid team on productivity to win a contract.  

Management can, and some will use the AFP to pressure teams for greater productivity; however, they likely do it anyway.  But it’s harder to do when the measurement is automated and based on a standard. 

We, in the agile and DevOps community, should take ownership of the problem rather than have a non-agile approach pushed onto us. Going to the PMO or production function and saying we have solution that is consistent, automated, and fair puts us in the driving seat – and that’s the best place to be on your agile journey.