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!

Why Scrum?

When you ask an IT company: 'Why do you work with Scrum?'. Most likely you will get an comparison with an older variant developing process like Waterfall. Then I say: 'What will that help you, if you don't know what waterfall exactly is?' So I'll try to explain why we work with Scrum in a different way.

Value

Let's assume that you, as a customer, like to have a valuable product. That means that you don’t want a website of application just for fun! You want the best out of your money. With other words: you obviously want the most value. And we agree on that completely! But that leaves us the question: what exactly is value?

Say you want to have 3 different features and also you have given them these priorities:

• Feature 1: most important
• Feature 2: second important
• Feature 3: would be nice, but lowest priority

The team who will work on those features brainstormed about these features and come with the following striking conclusions:

• Feature 1: is difficult to implement and so it’s tricky
• Feature 2: quite easy to implement
• Feature 3: can be implemented without any problems, but leaves the customer with good advantages, from which the company will benefit immediately!

So, if you think about priorities now, you’ll see that you can twist them around. If you agree on developing the third feature, the team maybe discovers a neat extra feature which will give you even more value. That brings us to feature 4. And what is the rank of feature 4?

Be realistic and embrace chances

This scenario is not odd. On the contrary, this is always reality, let's not be mysterious or unfair about it. Prioritising values is a living process! So, if you sign a contract and pinned down the features and specs, most likely you burn your fingers. Therefore you should acknowledge the fact that we find it unfortunate that we cannot be flexible when we have to.

Capturing your wishes in an early stage of the process and have them written in stone sounds like firmness and trust, but is fact a lie. It’s often seen in old, large companies. Project leaders get a budget from their superior and therefore have to account for it. And it can be very hard justifying yourself with saying: ‘Well, in general we know what to build, but we don’t know for sure exactly what it will become at the end of the track...’

Plus, if you do have pointed out exactly what the application will look like and we find out during the process that the goal is not achievable, we will rush; we will rush like a rabbit despite everything, whether the features have value or not. And when we push ourselves because of the pressure, everyone is getting Inflammable and irritated. First of all, this results in a lack of concentration, so more bugs will be introduced, secondly and most importantly, we get a decrease of creativity. That is why we find it most important to create a healthy environment by having a full collaboration, so that we can respond to the opportunities and uncertainties that spontaneously arise (because they always appear, no matter what!).

Unpredictability

And that is the main reason why we do Scrum. This methodology offers the opportunity to respond to opportunities and uncertainties. Maybe you think: ‘You have years of experience, how can you have such a lot uncertainties?

For a couple of hundred years you died in about the same environment as you were born. But if you were born in the 70’s, almost nobody had a personal computer, compared to now, it’s almost unthinkable. For a decade ago, it was not common to have a smartphone. In other words, the world of technology is changing exponentially and we are obligated to keep up with it. That means, we have to renew constantly. And renewing comes with uncertainties, but most of all it offers many, many chances!

Treat chances as business as usual. Better to embrace uncertainties than to stupidly ignore them.

Enthusiastic about Scrum

That’s why we are enthusiastic about Scrum. We are building the application together. Together we have to step aside continuously and evaluate upcoming chances on the way. Know for sure that developers want to create the best they can! So please, let them do it the best they think they can!

Look out for Agility!

I don't know where to begin, so I'll start to tell you that it is for a fact that Scrum Masters often are pulling their hair out. Why is my team slowing down? Why is there a decrease in velocity? What happened? Is scrum failing? Is Agility failing? Am I failing?

We have been told that agility is about making a move and then look back if this move was a correct one. If not, take another step and try again. Everybody knows that this move is not just a random move, because we think things through. What if I told you that's not enough? You might end up in some situation you don't want to be in...

So, how come that I tell you that agility is not the way to work?

It's pretty obvious. If you don't take the long term into account, you can easily walk into a trap. Let me explain with a common scenario. A team is working on a software product. They are delivering feature by feature. But what they don't think of is creating automated tests. Also they don't think of architecture. Did you heard about the S.O.L.I.D. principles? The Scrum Master is not familiar with that and he thinks that testing and clean code is overrated. And in the beginning it's going nice and steady, nothing to worry about! But after a few months some bugs appear and functionality comes with different business rules. It's not a rare scenario that your product is going to fail because of changes made in future sprints. Expanding features is harder than everyone thought it would be. So, there you go! Velocity is going down.

What I want to explain is that Agility is about short term decisions and learning from them. But what you really need is a long term vision next to Agility and use them side by side. Be sure that you deliver with such quality that you are absolutely sure that your architecture is ready for extension. Only then you succeed in Agility and Scrum!

Reference wall pitfall

Let's summon some things up from the previous post on the reference wall. When you finished a user story, you put this on the reference wall confirm the story points it has taken you to finish completely. When you miss estimated the story, you estimate again and place it at the right spot. So far so good.

Killing

Now, it's rather easy to estimate new stories this way. When you agree that the story is kind of similar to one of the stories on your reference wall, you can estimate the new story real fast. But... There is a downside.

You probably didn't think about the fact that your creativity isn't triggered this way. I mean, if you recognize the reference stories as building blocks, you become less challenged. Let me elaborate on this.

At a certain point, almost all of the features customers ever requested, are on that wall. That means that every story becomes business as usual. You have entered a common way of working. In other words, your process is fixed and you are killing creativity.

What to do about it?

I don't know what to do about it, so that leaves you an inconclusive blog post. (I wonder if I have ever been inconclusive... I think not)

Reference Wall

Last month, I've seen something remarkable. These are the moments, things occur to me, which are so obvious, that I could not have missed that, but I did! It's how the magic happens in teams.

What am I talking about? 

You know planning poker, do you? If you don't, it's giving an estimation on how much effort you think you have to put into one user story to deliver it properly.
This team, this post is based on, is so determined to Scrum, that they swore, they never go back to 'the old way' of working. Some background to it: this company was putting people to projects and now it's the other way around. They say: 'If management thinks Scrum is failing and they want to back to the former way of working, I'll be off to an other company, I swear!'

This team is so enthusiastic, that it is inevitable that it comes up with beautiful things. And of course, I make good use of it, to feed my blog and share it with you. It's called a Reference Wall.

If you take a look at it, it's full of user stories which are formally estimated. They put all of the done user stories from out the sprint, right onto this wall, but only if these stories appeal enough to ones imagination. And the most wonderful thing about this wall is that it helps estimation a new user story a lot! Refinements are an easy way of working now.
Thanks guys!

Good practices for Agile Scrum (additions)

Summary

We know what scrum really is now. And we found out that it’s not about only stick to the rules. It’s about bending the rules to fit to the team. In the last years we learned that the scrum rules don’t work when you just apply them without considering the meaning of them. You have to get a grip on them and learn how to use them in a good way.

This document contains the procedures how the Defenders (current team I'm working on) evolved from the scrum methodology. It’s not said that this is the best approach, because teams differ from each other a lot, but the main thing is we have evolved through experimenting and you should too! It’s not only fun, but it’s leading you to your best practices and it’s making you strong!

Don’t get me wrong. You need to work strict on the rules of scrum for a while before you make any additions or changes to it. The goal is to find out what scrum means and what the rules are for.

Scrum encloses force.

Let me explain what I mean with ‘scrum encloses force’. If you are obligated to fulfill the goal of the sprint (and I’m talking about finishing what you’ve estimated), because of scrum, you are forced to cooperate in such a way that you eventually can comply to that goal. We all know that the first sprint isn’t going well and estimates are far off. In other words, you have to get used to the fact that you’re planning and estimating.

Standup

Legacy

We started out with the common stand-up, but it didn’t work out for us. I’m talking about the three questions stand-up: what did I do yesterday, what am I going to do today and am I expecting impediments or difficulties? So everyone summed up there thing like: ‘I was working on MTN-345, I’m working on it again today and I’m not experiencing any problems.’ It didn’t help us to get things done the right way. Most of the time, all of the user stories were in progress, because we didn’t collaborate well enough.

What we’ve learned.

Let’s make one thing clear. The product owner did order the sprint for a reason (, hopefully together with the team). So the first item needs to be finished first. The second secondly etcetera. All looks very obvious, but how are you able to do that? That’s when a good stand-up is coming in. Therefore the questions at the stand-up should be: how are we going to finish the first user story? Who is going to collaborate with whom? And what progress can we make today? What is the best approach to finish this user story the best way?

So you go, user story by user story and find out what you have to do to finish it nice and smooth and have an estimation on the progress. It’s like a small (daily) planning.

Refinement

Legacy

For a long time we tried to do refinement the normal way. We were letting the product owner show what the customer needs and we were trying to comprehend what that might look like in Twinfield. There were not many questions, because it was a one way direction more or less. So the implementation led to a lot of misconceptions and bugs. The tester found things the developer didn’t think about and the developer touched code he thought wasn’t worth to mention to the tester. So bugs sprout out from production.

I think the reason was because we didn’t talk about the feature enough. Most of all, we didn’t talk about it at all, because in our own heads it seemed clear enough.

What we did is let the product owner create the user stories and the acceptance criteria. He was spending a lot of time on that and at the end, the team changed a lot about them during the sprint.

What we’ve learned

Now we are creating user stories together with the product owner and help him out on that. That’s purely because as developers we know the domain and the code best and we know more and are smarter as a team than the product owner is by himself.

To understand the user story correctly, you have to go through three phases. And if you don’t want to have the tester falling behind a lot, you need to make sure your user stories are very small. And that ladies and gentlemen, may be the best part of being part of a development team. Try to puzzle your way out to have the best minimal viable product and implement it the smartest way. That is the cherry on the cake, especially for a developer.

For this three phases we created a Trello board for the user stories which we need to refine. Every user story has a checklist for all of the three phases, like: ‘The title of the user story reflects the actual fix’, or ‘The team has figured out and talked about different scenario paths’. The full list will be at the bottom of this document.

Also, you need to have everyone to talk about the subject a lot! If you think you got a silly question, don’t hesitate to ask. Speak your mind and you will see that stupid questions can lead to different thoughts and perspectives and might even lead to better solutions. At least, the one who asked a stupid question, knows more about the user story now. Keep asking questions!

One thing worth mentioning: you don’t need to talk about the solution at this point. There is no need for that. It will come in the sprint itself. (In practice, you’ll find out that each one of you is secretly thinking about a solution, so don’t worry about that)

Phase 1: Use cases.

Try to figure out the original goal of the feature. You could ask yourself a few simple questions. Like aren’t we dealing with a solution or a question? Aren’t we making a workaround for a deep underlying problem? Maybe the customer thinks he/she wants the feature, but is going to use it the wrong way. So the most important question here is: what does the customer needs the feature for? As a .., I want to …, in order to …

Phase 2: Scenarios.

The team gets to know the behavior best when scenarios are made for the feature. Given …, when …, then ... It looks kind of silly, but you’ll see that this is the best way to get familiar with the feature. Try to smell the feature. Try to taste it.

You might come to the conclusion that the feature can be splitted, or is hooked into other functionalities. You come up with additions and deviations. Finally you end up with perfect acceptance criteria, because you got the most important scenarios. And the most important thing is that you’re all on the same page! There are no misconceptions at all. Everybody knows what to expect and everybody knows what the impact is of the features functionally.

Phase 3: Consequences and Risks.

Up till now, you cannot estimate, because you don’t know the current situation of the code. What does the code look like? Is it rigid or fragile? Is it rotten or deteriorating? Are there unit, integration or end-to-end tests. In short: how is the current condition of the code and what is the technical debt to overcome?

Estimating

Now you got a good picture of what your situation is and the team can estimate. It knows quite exactly what they are up against.

But keep in mind that you are still not actively looking for a solution for the feature or problem. That’s a thing you need to do within the sprint. You also don’t need to fully understand the ins and outs of the user stories, it’s only to get really familiar with them.

The trick at estimating is to create yourselves a reference. You should define a reference point on a common and well known feature, for example a feature toggle. This is a real easy feature and you have a good feeling about what needs to be done and what not. You can mark this down as 1 story point. From that perspective you can value other features and estimate based on the feature toggle. You will become good and accurate on that in time. You come to a point and ask the team, how is this feature more or less difficult than the previous one.

Planning

During the refinement you have estimated a lot. And if you have done enough estimation sessions, you have enough user stories to fill the planning. So the planning will be a formality. A session in which you seek for transparency between the product owner and the development team and have a confirmation of what you agree to do.

As Defenders we create ourselves an image of how the sprint may look like up front and place user stories in it which we think we can do. During all the refinements we tweak that image. (In Jira, you can create a new sprint and fill it with a bunch of user stories from the top of the backlog)

Retrospective

Legacy

We started off with the questions who are available in Jira about preparation, added value, sprint product, self-organization and teamwork.

That became boring and eventually nothing interesting came out of it to improve ourself. It was the same old song, over and over again.

What we’ve learned

We tried out a lot of different retrospectives. That contributes on having a fresh mind and seeing things from many different perspectives. The most important thing is: improving. There are a lot of different retrospectives you can do like: the 4L’s, the 5 whys, speed boat, 6 thinking hats (mostly used for problem solving), and lots more of them.

Retro suggestion number 1

1. If you look at the work you did, try to sum up the facts.
2. Where was the collaboration?
3. What was impeding you?

How would you redo the implementation if you could do it all over again? Where are the tweaks in your process?

I know it’s difficult, but with the right questions, you will come far.

Retro suggestion number 2

Let the team realize that everybody is thinking in an other way.

Let everyone draw a picture of a castle with clouds and landscape. You will see that everybody has a different view.

Try to have a developer draw one picture together with a tester by drawing one line at the time swapping between the both of them. So first the tester draws one line and then the developer one in addition to the previous one. You will see that the line the tester made is meant differently than the developer thought it would be for.

Retro suggestion number 3

Show the teams emotions in a graphical way: http://tastycupcakes.org/2013/07/moodgraph/ It reflects what let you feel good. How do you prefer to work? What made you feel good. It’s quite obvious that when you feel good, you implement best!

Conclusion

Differ a lot and it will benefit you! Maybe you are thinking: this is really stupid and childish, I’m not going to do any of this. I can imagine that, but I advise you to just try some things out. You are going to have fun for sure!

Overall conclusion

Experiment a lot! Try out new things like TDD, BDD, extreme programming. Find out what’s best for your team. What benefits the team and what brings it down? Bring in the fun! Move out the worries! If you stick to these ‘rules’ you will improve a lot!

Remember that to have trust in what will come and what you do, makes the team enjoyable to work in.

Checklist Refinement phases

Use cases

The team knows what is going on,

The title of the user story reflects the actual fix,

The team knows what the fix is for, or why the customer needs the feature,

The team knows how to reproduce the bug, or how the new feature must work,

The team has created (some) use cases.

Scenarios

The team has figured out and talked about different scenario paths,

The product owner is satisfied with the scenarios,

The team has filled the scope and knows what is out of scope,

The team is sure it can demo the user story self-explanatory at the review.

Consequences and Risks

The developers have a general idea on how to implement it,

The testers know which tests are already there and which ones they should add or alter,

The developers know which unit tests and integration tests already exists,

The risk analysis is filled in.