Product Health Check
Team Health Checks are commonly used by the agile community to help teams assess their strengths and weaknesses and to take action to improve. As we move towards Product Thinking the context expands to include far more than a single team and many more activities too. The Product Health Check is designed to accommodate this broader range of concerns. It does not replace the Team Health Check, but is designed to supplement it so that the teams, together, gain a more holistic view of the health of their working context.
In A Nutshell
The Product Health Check allows everyone involved in developing the features and in delivering the services of a systems product to participate in evaluating the status of their product. Once the strengths and weaknesses are understood, action can be taken to reinforce strengths and to resolve weaknesses.
The Health Check is structured in four sections reflecting the major streams of work needed to make a product successful:
Create Product - building the features of the product
Transition Product - deploying new features into production
Operate Product - operating the services of the product
Improve Product - improving the quality of the product and performance of its services
Each section contains a number of Indicators that describe a valuable characteristic of the teams, the product and the way of working. Each indicator also gives guidance on how the product should be assessed, giving three levels. The levels are labelled “green”, “amber” and “red”.
As with any health check, the teams involved must think about how to apply the results. Any scoring framework is contextual and contingent. A product may be evaluated as “red” for a given indicator - this doesn’t mean that immediate action needs to be taken. If, in the context of the product, the “red” indicator is considered less important, then acting on an indicator evaluated as “amber” may provide better value more quickly.
Product Work Streams
Create Product includes all work to understand, implement and test the product. It embraces the work that must occur before features can be developed. Work that enables the whole product community - customers, owners, developers, operators - to realise a shared view of the intent and direction of the product.
To provide new and improved services to our customers, the features we create must be transitioned into production. Unless we apply the right rigours and disciplines, transition represents a real risk of service disruption for our customers. Small batch sizes are inherently less risky, but we must be able to deploy frequently in order to keep batch size small. Automated testing and deployment serves to reduce the risks associated with frequent, small deployments.
Our product only starts to give value to our customers when they are able to access its services. We operate the product so that we deliver the services with the Quality of Service that has been agreed. We monitor the value provided to our customers in order to confirm we are meeting the customers need. This will influence the priority of the product within the product portfolio.
We seek to improve the product by using metrics data and feedback received. Improvement applies to the quality of the product, the quality of service provided to customers and the ways of working of the team. Improvement means seeking to reinforce and repeat good qualities and behaviours as well as seeking to eliminate bad qualities and behaviours.
The increasing popularity of Product thinking and DevOps requires teams to take on more responsibilities than would traditionally have been the case. The Product Health Check focuses our concern not only on team health, but also on the health of the product context. Only by ensuring healthy teams and healthy product contexts can we sustain effective delivery.