Is my engineering team strong? Using the VFQ(H) framework to assess agile team performance
I’m grateful to Emergn for educating me on the Value Flow Quality framework. I’ve found it incredibly useful as a means to structure conversations with teams and individuals about performance. I’ve just made one modification, which is to add the fourth quality Health. As you’ll see from their website, there is a wealth of material on this, but here I will focus on it as a way to review agile development teams and in a separate post you’ll see the same framework used for Product Owners.

Evaluating a technical team is fundamentally challenging. Lines of code? Number of tickets? Increase in points velocity? None of these really tell you that much about a team. I have not found any magic number that can quantify the quality of a team, but I’ve found a conversation centered around VFQH scores teaches me a lot. The principle is to sit down with the full squad, and discuss each of these items. At the end, you’ll pick up a lot about how well the team is working and what they can further do to improve.

Specifically I have them individually put a numerical score of 0 (don’t agree) to 10 (totally agree) to the statements below. Somehow the act of giving a score is much easier (at least for engineers!) than speaking what they think. Putting it all together gives you a sense of the overall strength of the team, and where to direct your energies for improvement.

Value

We know our customers and what they value

We know how we contribute financially to the business

Our team is delivering value to customers and to the business

We appropriately balance value delivery with technical debt

Here we are exploring the main thing the team is there for: the creation of enduring value for someone else. For bonus points ask them to list what was delivered to customers. Sadly, this can sometimes take some time to establish. Teams focus on technical tasks and tickets. Or they’re dependent on another team deploying the software, or driving customers to it.

A good team thinks in terms of customer impact and will be able to rapidly identify what they did. They will also have good answers to what more they could have done. A poor team will not be in touch with this. If you have the latter, you need a strong PO that will not only identify value, but help embed a philosophy of value delivery into each team member.

How technical debt is prioritized is an important topic in its own right. See how they assess this. Ultimately paying down debt is a down payment on future productivity. Can they express what this productivity gain is expected to be, for whom, and how it will be leveraged for future customer value? Are we seeing the benefits this year from last year’s debt work?

Flow

We know what to work on next

Tickets move rapidly through the pipeline

Meetings are efficient

We resolve issues quickly, we’re good at taking decisions

Here we explore the basic operational efficiency of the team. Do they know how to get work done?

A good team writes clear tickets that are well sliced into chunks that can get done in a few days. They know how to run effective meetings, and how to identify and resolve issues quickly. It’s surprising how many people struggle with these things. If this is a tough one, you probably want to bring in a scrum master or coach to teach techniques on basic blocking and tackling.

Quality

Our software is stable in production

We can rapidly detect, diagnose and resolve production problems

The software features we deliver are fit for purpose, and our customers are satisfied with them

These questions tap into important development practices. What is their philosophy around testing and test coverage? When problems happen how long do they take to detect, diagnose and resolve? These are three separate metrics worth assessing that speak to monitoring, logging and expertise. Do they monitor customer satisfaction?

A good team has a strong understanding of processes that drive the development of quality software, and how to ensure high uptime in production. If they lack this, you need to bring in a consulting architect to develop best practices in this area.

Health

We work as a team, not as individuals

We can speak freely about our concerns with no fear of reprisal

We communicate key information regularly to each other

We can resolve disagreements amicably

We communicate regularly with our customers and stakeholders and are respected by them

We are individually happy at work

It doesn’t matter how clever your engineers are, if they don’t have a good team dynamic not much will get done. This is a critical thing to track (and to ensure the team themselves are tracking). This can be the most delicate part of the discussion in teams that have problems so make sure you have a skilled facilitator managing the conversation. An open and frank conversation on the above topics nonetheless will pay off richly in team trust and productivity.
['Patrick Mclean']
['Engineering Mangement', 'Team Health Check', 'Agile Teams']