High Performance Teams

Henrik Kniberg is a prominent thought leader in the software community and runs a software consultancy in Europe. If you haven't had the opportunity to enjoy any of Henrik Kniberg's postings, you should check them out, you'll be glad you did. One of his blog posts is captured in a wonderful YouTube video that is a must see. It's written especially for Product Owners, but its wisdom is applicable for all High Performance Teams (HPTs).

Toward the end of the piece, he shows us how HPTs balance the differing tensions in our craft. He shows us this cool Venn diagram that has three intersecting circles: one that represents focusing on building the right things (the correct scope), another that focuses on building things right (quality), and lastly, building things fast (delivering quickly).

We know, that if we balance building the right things with building things right and building things fast, we'll delight our customers and at the same time, we get better at doing what we're paid to do while practicing our craft.

It got me thinking, that this easy to understand Venn diagram gives us a simple set of recipes for helping software teams to become more performant; and that spending more time improving each value separately, while keeping them all balanced is a good thing.

Getting better at building the right things

building the right things takes skill at the whole team level. It takes considerable focus by the Product Owner to work with customers and stakeholders to pull out exactly the most critical features that will bring the most value. Being careful not to build too much before we have feedback from real customers is a classic failure. HPTs push their PO to sharpen the product backlog to include only the most critical features and then wait for feedback before modifying or improving what they've built.

There are a number of ways to improve feedback from customers and stakeholders. In our shop, we hold bi-weekly demos for stakeholders so that they have many opportunities to give us feedback. But feedback needn't stop there. Another way is to build in metrics that tell the team what features are being used and how they are being used. That sort of feedback is more strategic and helps the team with the PO to modify their approach so we can improve the product over time.

Getting better at building things right

This is also a whole team activity. Making money for the company, means not only building quality products that meet customers needs, but relentlessly squeezing waste out of our development process.

At the development level HPTs understand that quality means the absence of waste. Every bit of waste in our development process means slower delivery cycles and lost revenue for the company we work for.

At the product level, HPTs realize that they will touch product code many times. Code that is flexible, readable and clean is code that is easy to modify. Code that is easier to modify is a product that is flexible to change and will have a greater opportunity to delight the customer.

Getting better at building things fast, or using a sense of urgency as a tool

HPTs understand that going fast while maintaining effectiveness at the other two measures is ideal. Going fast is working without waste. Going faster is delivering product to our customers faster. What's not to like?

Committing to faster delivery

Going fast means getting as good as we can at committing to work; and then learning how to get a set amount of work done even quicker without robbing value from either building things right or building right things. We develop "a sense of urgency" as a spur to improvement. Being able to commit to completing stories, starts with better estimation. Getting better at estimation, improves the teams capacity to commit to getting work done and is part of keeping the team velocity high while keeping the pace consistent. Getting better at estimation is an opportunity to get to a higher performance level.

Going fast means improving the team's skills; skill at development, constant improvement to go faster, committing to less waste in our development infrastructure and skill at creating and using a tool like sense of urgency to grow and constantly improve.

Robbing Paul to pay Peter?

If you're in a position to adopt these ideas and your shop resists them; you might explore whether the resistance is coming from the idea that going faster will mean diminishing either building the right thing or building the thing right. Tell 'em it ain't necessarily so!

Bottom line: use each dimension of the improvement graph. Learn to use the tools of feedback to Build the Right Things. Learn to eliminate waste and build higher quality into every part of your process and your code to Build the Thing Right AND find a way to use a sense of urgency to drive your team to improve on delivery speed. And if your team sees the need to deliver on time as robbing them of either quality or building the right things, then your team is missing an opportunity to use urgency as a spur to improvement.