At the turning point of the year, it’s time for the interviews in companies. Favorite review of last year’s work and proposal of new goals. Plus, their KPI. Key Performance Indicators.

At the given time, it was a topic of the week for me. I saw interesting KPI:

  1. Your goal is to make an annual interview with the subordinates next year as well. Huh? Well, obviously, I am the team leader, aren’t I?
  2. Your requirements must be 100% ready. Huh? What about research topics, bugs, strategic product development?
  3. You have to deliver what you promised at the start of the sprint. That’s why you do Scrum. Huh? And what if the client wants a change during the sprint?
  4. Your velocity needs to grow. Huh? What about stabilization in order to plan better and promise what we are actually able to do?
  5. Your velocity needs to be 46 story points at least. Huh???
  6. You have to use the team’s capacity to 100%. Huh? Do you know what a highway filled to 100% looks like?
  7. You have to fulfill the goals of the product, which means to earn more. Huh? But I’m a developer, not a retailer.
  8. Story points are fine, but we sell.
  9. Specify the estimation.
  10. You get 100% payment when you try. Huh? So, I’m going to pull overtime to get what I was promised? Maybe working on 80% is enough, I have enough. I don’t care. At least I will have time for different things.
  11. QA, you do not have to let go of anything in the first round. Certainly not so many errors (I love that!).
  12. QA you have to find errors! (I love that even much more!)

So instead of motivating KPI to achieve a functional result, you teach people to trick the statistics.

Because velocity can be increased by simply multiplying story points by 2. Simple 200% achievement.

Because requirements are passed by the team, that’s mad FOR YOU at the system that PO won’t help YOU to prepare them properly. And readiness is suddenly green.

Because if you don’t care about velocity, you’ll get hours. Forget about predictability and cooperation, though.

100% capacity? Ok, but not even one spirit is going to be finished. Because it’s usually Velocity < Capacity. It’s better to finish less and deliver more than to elaborate a lot and transfer it in between sprints.

Refine estimates? Aha, story points are not accurate enough, that’s why you should use hours. That’s why you should have long meetings for estimation. And therefore, that’s a loss of a part of your life.

Do you have to find errors? There is always something to be found on the edge of the gorge. Even though the error won’t be found in the reality, why test it? And so, the team repairs unnecessary things.

Define your proper goals with the help of Objectives and Key Results

Ideally, everything in the company should lead towards a common vision. The vision needs to be broken down into several smaller and achievable goals. But how do we know that goals are achieved? Then it might be good to identify the expected results.

Once we have goals and expected key results, we can think about activities leading to our goals. Then plan them, execute them and measure their impact.

That is what OKR (Objectives and Key Results) method is about and why it might be helpful.

objectives and key results okr goals

Identify the real causes of the problems, not the symptoms

Root Cause Analysis is the tool that’s going to help you. There are several methods for RCA, such as Five Why, Pareto Diagram, or Casual Loops Diagram.

The example below is a simple illustration of brainstorming, during which we tried to find the deeper meaning of clients’ dissatisfaction and possible causes.

root cause analysis rca casual loops diagram scrumdesk tool

Another example of analyzing poor quality.

root cause analysis rca casual loops diagram scrumdesk tool

The diagrams were made in ScrumDesk RCA Desk.

How to set up KPI?

Activities should link goals with problems and people. KPIs should, therefore, measure the rigidity of the connection between people, products, and businesses.

Maybe that’s why it makes more sense:

  1. Identify problems and their root causes. Set KPI to measure their removal.
  2. Fix the goals of the company
  3. Then, clean the product targets to support the company’s goals.
  4. Set team goals so they support the goals of the product, teamwork, care, and support of the team members and communication.
  5. Work on features that are not a waste.
  6. Measure the output of a unit, not the team member.
  7. The result has to fulfill the agreements. Measure how agreements have been adhered to.
  8. Don’t forget about How are the improvements continually collected, evaluated, and implemented?
  9. What is important? Throughput, time to market, or added value?
  10. Bring the KPI team to the rating of a product by clients or users (e.g. using Net Promoter Score).
  11. QA must match the same parameters as the team. Hmm, actually, in Agile QA department should not even exist, because they are part of the team. Or?
  12. The Product Owner is a part of the team. He can’t push the other way because of his own KPI.
  13. The same goes for stakeholders. They cannot fight with each other because of their own personal goals. They have to contribute to the company’s results. Otherwise, the team will be torn apart in small wars.
  14. Quality first. Remove waste!
  15. Evaluate the troubleshooting identified in the root cause analysis.
  16. Support education and communication in the team.
  17. Set the goals of team members so they become an interdisciplinary team.
  18. Set goals so the team won’t keep it to themselves, but they care about the delivery of the entire solution even in the case, more teams were necessary for delivery.
  19. The frequency of deliveries. Because often means faster, automated, tested and continuously accepted.