If you can't measure it, stop producing it!

Eureka!
I often have that euphemistic feeling throughout my career! And when I do, I try to use every opportunity to bring up that subject in every conversation. And with every eureka feeling, I like to think eventually I will have the ultimate answer to agile development. Just like theoretical science, where scientists try to figure out the theory of everything.
I'm talking about producing Value. You probably think: 'is that all?' Well, yes and no.

You know I often talk about creating value and why you should pursue that every time. I still totally agree on that, but to accomplish that, I have an addition! I know a good practice how to produce good value. In short, the answer is: talk about value.
The problem is, you can't just think about value, or just try to talk about it, you need a reason to do so! Any idea how to create a reason? I really think I'm not thé best Scrum Master ever, but I wonder how I didn't see this revelation before, while it is so obvious.
As a team, you need to realize that the product you think is valuable to your customer, should actually be as valuable as you thought it was. The only way to do that is to measure your value after you delivered it! As simple as that!

Imperative!

So before you drag your User Stories into your sprint, you think about how to measure the value you want to produce. And a very simple rule is: if you can't think of any way to measure it, you don't produce value! On the other hand, if you are experimenting and thus don't know if you actually are producing value, you need to know if it turned out positively and you have to measure it as well. In all cases it is imperative to create a plan to measure your value.

It's up to you to think about how to measure value for every feature in specific. It could be customer experience, performance or just basically that customers can do their job, maybe in the most primitive way. For example, if a customer's work normally takes half an hour and with your change it should be reduced to half the time, you are obliged to measure that!
There are a number of ways to measure value, because there is a great variety of solutions. Challenge yourself to always let this way of thinking be part of your refinement or planning!

Last note: while developing, you probably have to tweak the way of your initial thought of measurement. Don't hesitate to do that!

Effectiveness is not efficient!

If I allow myself to, I have to spend a lot of time trying to convince people about the essence of agile developing. It's maybe impossible and inappropriate to always point out that agility in development has nothing to do with efficiency. And if I do, I have at least 5 conversations throughout the day. At the end of the day I assume I'll be recognized as a whiner.


First of all, you need to know I currently have a system (SAFE) team, put together with people from multiple sections of the company, almost by force. So everyone in my team has their own backlog for the time being and at some point, they need to work together. Further more, many of them haven't been on a scrum team before, so they are not familiar with the scrum events.
Secondly, in most cases, Scrum is introduced by management based on false pretenses. Scrum should fill the gab between supply and demand. So it looks like they will have better control over the road map, specially on the delivery aspect.

Not efficient!

This morning, at the stand-up, the attendance was downgraded from 8 to 2 people. So I asked the team what their opinion was about the importance of the daily scrum. They say: 'It's not efficient enough, because most of the time, we're not interested in someone else's story and problems. In the meantime, we could do a lot of other important things.'
Also when I tried to explain that they need to work together on single stories, they came with the same verdict: not efficient!

The most valuable drive

Dear readers, please take it from me: it's more valuable to produce a good working, fully expected and well adopted feature by your user, than steering at a good velocity! And the argument that a team prospers from a climbing line on a chart is true, but does not weigh up to experience the happiness of the ones who use your software! That is truly thé most valuable drive to have as a team. Thát will help a team far more creating a valuable product than focusing on efficiency.

Resume

So, why do I want to have the team working on one feature or one user story? And why do I need everybody present at the standup? My team is right: it's not efficient. But I don't care if it is efficient or not. I want my team to be effective! Let me get back to those examples I mentioned;
When you join the standup and hear about subjects you don't care about, know that almost every time something triggers someone. Even maybe in a way you didn't expect or recognized. It will help the team with decision making. Although you're maybe not familiar with the subjects, you are still able to ask good questions!
And working on the same story wideness your bandwidth and gives you new insights and knowledge transfer. So the solutions are getting more colorful, powerful and better founded. As a team, you get slower, but you produce better solutions. Which eventually brings you to less changes and bugs, and therefore gets you faster in the upcoming sprints.

Cheers!