KPIs Within a Scrum Team? That's No Partnership!

When is a Scrum Team successful? Which criteria do you use to determine if a Scrum Team is doing a great job?

From my point of view, a Scrum Team is doing a great job if they deliver an increment with the highest valued features, with the best possible quality and they continuously strive for improvement. In this post, I will share my thoughts on a discussion I had with a Scrum Master recently on partnerships. I will not provide practical examples, if you are interested, take a look at Evidence-Based Management and read this. The discussion started with the following question:

Changing the Contract

“Stephan, how do we, Scrum Master and Development Team who are hired by our client, Product Owner, change the KPI’s (Key Performance Indicators) in our contract to measure if we are doing a good job?”

Without hesitation, I replied something related to the statement I made above. However, the Scrum Master did not accept my answer. He said: Listen, in our current contract we get rewarded for every time we are within our initially estimated delivery schedule and if we stay within our budget.

"How do we know, now that we have started using the Scrum Framework, that we have done a good job?"

Then I explained that by deciding as customer and supplier to start using Scrum, a lot more has changed then just doing some events and incrementally developing our solutions. By making this decision, you have mutually agreed to move from a demand-driven approach, a.k.a. doing projects, to a supply-driven approach, delivering solutions. And by using Scrum, the Scrum Team has a shared responsibility to deliver the best and most valuable solution to the customer.

With this decision you both have committed to this goal, you both have a stake in the success of the things you do. You now are a Scrum Team and yes, each role has a different angle on how to approach this shared responsibility, but you are in this together now.

In This Together

The Scrum Master looked puzzled and replied: "But we are a pay-by-the-hour company! We just deliver highly qualified people, we cannot be held responsible for the value we deliver to the users? What kind of KPI’s do we need?"

Yes, you deliver skilled people who bring in their experience and expertise to create a valuable solution. But to build the right things in the right quality in the right way they need to interact with the Product Owner (and Stakeholders) to figure out how to build the right thing. You need each other, right?

"Yes!"

You, as a Scrum Team, can only be successful if you collaborate. So you need to figure out together if the thing the Product Owners want is more valuable than the cost of the team. The client buys capacity from you as a supplier per sprint in the form of a Development Team. So as long as the benefits of the items delivered in a Sprint exceed the costs you are on the right track.

Send it Back to the Kitchen!

I always compare a Development Team to the chefs in a top-tier restaurant. They need the proper equipment to cook, but how do you judge their performance? If the food tastes good. If it doesn’t I do not blame the waiter, I send it back to the kitchen! The Development Team is responsible for delivering a high-quality product. Just like in a restaurant, we are all together responsible for delivering a great experience.

"Quality is something we are responsible for?"

Yes! Put that in your contract! But wouldn't it be great if you could create a contract that reflects the responsibilities of the entire Scrum Team?

"Now you are being naive! That is never going to happen!"

Why not? As long as you are only being judged by the quality delivered, why should you care if it adds any value? Why do you do this job? To deliver high-quality stuff that nobody ever uses? Or do you want to create something valuable, and of good quality, that people like to use? And yes, that is a rhetorical question.

Partnership

I see a lot of client/supplier relationships using Scrum. When signing the contract they both say they engage in a partnership. But the agreements they make usually have nothing to do with being partners. A contract hardly reflects that we need each other to be successful and that we both care about the goal we are trying to achieve. If that is the case, there is no shame in making money for both partners.

That is why Scrum says nothing about having KPIs between a Product Owner and Development Team, since using Scrum implies a partnership where we all contribute to achieving the same goal.

Soon I will elaborate more on partnerships and how I make my decisions when I am looking collaborations.