Continuing the discussion from Flow, Decoupling Cadences, and Fixed-Length Sprints:
Can I measure the performance of a (cross-functional) product team?
On the first sight it seems to be easy to measure the progress, throughput, issues and incidents from the plans and the systems we are running. Drawback: we are relying on predictions and take assumptions, that the systems we are working with are stable (no side effects, no disruptions, no trends, no changes in setups).
On the second sight it turns out that product development is not an engineering task only, but requires a lot of thinking, experimenting, creativity, and collaboration. This brings with it the idea of measuring how well a team is doing - a health check.
There are many ways to do health checks within a team. From my point of view the daily check-in is already a start, but it does not have any metrics.
@andycleff provides a great summary of various team health and morale checks in his blog post, which gives a great start.
Anyhow, what is it? How do you perform health checks and above of all, what are you looking for? What is the purpose?
I for myself have developed a team health check a while ago with the purpose of helping teams to find topics for the retrospectives. It worked pretty well, but is nothing which could have been tracked. It is moreover an exercise to encourage reflection within a complete team:
I for myself do hard in measuring teams today, as I fear being too narrow in what I am looking at. I want my teams to find out for themselves how good they are doing their job and how they can become better. I can support in measuring, but not measure to support.
How do you think about it?