Tag: measurements

Focus on Value

One of the biggest shifts in the agile world is from output to outcome or in other words from being busy to achieving something meaningful. It looks simple. If we plan it well, the two are supposed to be the same, right? So, what’s the problem?

The more we deal with complex problems, the more possible solutions are available, and the harder it is to find the right one, that will bring the business value. We have so many options and it’s hard to evaluate their impact.

Let me give you an example. Imagine you’re having a gaming company. The company creates free games for mobiles which you can just download and enjoy playing. So how do they get money as a company? They make their players buy something at the game store. In a traditional environment, somebody smart has an idea to build more items for the game store to get more money. And the teams in traditional environments are done when they implement the feature that it’s up and running in the store. No bugs, it works, and they implemented it that fast, according to their estimates. That’s how success is defined in the traditional environment. We don’t question the plan, we just deliver as fast as we can.

In the Agile world, the implementation is just a prerequisite. We don’t do it so that we have it, we do it because we want to achieve a business value. Now how do we know if we achieved a business value? Well, that’s a bit tricky right? It’s much harder to measure value than to measure velocity. To be able to get a sense that we are delivering value, we need to have a good relationship with our customers and get frequent feedback to know if we are going in the right direction. As an example of value metric, the team can start measuring things like how many people bought this new item in the game store and if it’s growing, they call it a success. Value was delivered. But that might not be the real value either as you might realize people only bought it once and never again, and then it was actually a waste of your money implementing it. So you improve the metric and start measuring things like returning customers and if it grows you call it a success.

And after focusing on value metrics for some time, you realize that more features don’t necessarily bring more value. You can implement ten new items to your game store and people might even stop playing the game as they say it’s confusing. In a complex world, more doesn’t mean better. So stop focusing on speed. Stop caring about velocity. The only important thing in nowadays constantly changing complex world is to be able to inspect and adapt quickly based on the feedback. Measure value, not effort.

Measurements are dead, let’s measure

During my career as both Director of Engineering and independent Agile Coach, I’ve been hearing still the same grumble from managers: “We can’t get rid of measurements and KPI’s. How else could we know if the person is performing well, how can we compare people?” and at the same time, grouching from the team members: “We don’t like the individual based KPI’s and measurements, how are we supposed to be a good team when our managers can misuse that against any team member?” It’s surprising but no one likes individual metrics, they all admit they are useless, but they are all afraid to try anything else.

So if you have a bit of courage, you may try this: It’s based on coaching relative scale and is team oriented: 1 stands for 🙁 and 9 stands for 🙂 and it’s great if you add a reason for rating lower than 4 and higher that 6. Firstly, let the Product Owner give a team his number how he is happy with the team.

As a second input, ask Scrum Master to give a number to every team member how much he is happy with this person as a team player. Let them discuss it, but make sure the discussion is not about “why I’ve got 5 instead of 7”, but is focused on future development of that person discussion “what should I do differently so that I’ll get 7 next time”.

And last number goes from the team members. The best you can do for this part is to ask everyone to divide 100$ to all team members except himself. You may worry that they can agree with each other and rotate all the money one by one, or distribute them equally, but that’s not common in real life. The great think on this evaluation is that the team members are giving a feedback to themselves. So every team member gets an answer to the question how do you value my contribution to the team? And if you find out the other team members don’t see any value in your work, you would most likely be very much concerned about that situation and asking how can I do differently so that you value my work more.

Combining those three inputs you will learn much more than from traditional metrics, regardless the company size and culture. It’s working just awesome, but you have to have courage to give it a try.

And when this is just normal for you, you can take it one step ahead. The fully Agile companies are using such tool as the only one appraisal tool across the company. No other bonuses than those distributed by employees to the other employees. So in such company, if you feel you would like to appreciate the receptionist, give her some part of your bonus sum. The other one can be for your colleague, another part for a developer from a different team who helped you with some issue. And when you are afraid it’s too crazy for you, I would like to remind you that we are only talking about bonus distribution, not the whole salary. When you do so, you will increase team cooperation over individual heroes work, and openness and transparency over politics and gossiping. And it would be fun. If you still don’t know, start with Appreciation cards. Make them available and encourage people to give them to each other. Even by that you will learn a lot about yourself, your team and the whole organization ecosystem.