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.

Tamagotchi

Maybe you have heard of the term 'Grooming'. It was the term I used for refining backlog user stories, but since I heard that grooming was associated with making contact with under-aged children, I prefer to use Refinement.

Nursing

Now the stage is set to talk about refinement and my little experiment with it.
If you have trouble handling user stories in your sprint and underestimate or overestimate a lot, you might want to use my approach for having control over it. If I was asked to come up with a name for this approach I called it: Nursing. In this blog I will walk you through the concept of nursing and tell you step by step what we do from-out the 'Trenches' of my scrum team.
I immediately thought about the tamagotchi toy. You have to feed it and give it attention, because it dies if you don't.

First day of the sprint

This is where it all starts to happen. We have just created a brand new sprint and we are about to start working on it. From the planning, where the current sprint is just formed and agreed, we look beyond the sprint and try to figure out what the upcoming sprint may look like. In practice, we create an other sprint on the shelve and fill it with the top of the backlog, of-course agreed with the product owner. This is the beginning of a two weeks mission to clarify the hazy and misty image we got of the next shelved sprint.

Three stages to become familiar with each user story

There is an order to get familiar with an user story the right way. Developers usually have the urge to immediately start with implementing and finding a solution for the feature. In short, all disciplines kind of lean towards another direction, which is in their interest area. In other words: we create our own image of the feature and keep it for ourselves. I'm a little bit exaggerating of course, but this is what mainly happens.
You can divide 'knowing the user stories' into three stages. (At least, that's what I came up)

Stage 1: Use cases

In stage 1, the team tries to find out what the user story is about. And the most important thing is, why does the user wants this feature? Try to get to the questions behind the questions. Questions might be: 

• Most of the time, the feature is a solution. But is the feature THE solution the customer really needs? 
• You might also consider if you are trying to create some kind of workaround? 
• Which customer needs this feature and shouldn't there be a permanent solution for this 'problem'? 

You can ask all kinds of questions here. But be alert that you stick to the use cases and not trying to create scenarios or solutions at this stage! (Maybe you can break up the feature a little bit into several user stories! Whoohoo!) (The usual format of a use case (user story) is: As a ... (persona), I want to ..., In order to ....)

Stage 2: Scenarios

So we know what the customer wants and why the customer wants it. We can now talk about scenarios. What kind of personas are relevant for the scenarios and what kind of variations or deviations can you come up with? 

I have to point out that this is not the time to get all scenarios thoroughly correct at this moment. Again, it's only to make everyone in the team aware of the situation and get a good feeling about: what is about to happen during the next sprint. You must be all on the same page. (The usual format for a scenario is: Given ..., When ..., Then ...)

Stage 3: Consequences and Risks

This is the stage where we find out what the current status of the code is and what kind of tests there are. We have to know the current situation of the implementation before we are going to work on it. The testers need to know which tests there are and need to find out what more of them need to be made. The developers trying to find out technical debt, dive into the code and see what they are up against.

Estimation time!

Now you nursed your backlog well enough, it's time to estimate. Everyone now knows what to expect from the user stories, so estimation should go smoothly.

Recommendations

• Try to not find a solution during the refinements
• try to get as familiar with the user stories as you need to, to end up with a good feeling about them and therefore create trust.
• If you do not nurse the next sprint well enough, it might become infected and therefore less controllable.
• What you can do with less people than the whole team, you might want to consider to actually do with less people. Like one tester, a developer and a product owner. For example: create scenarios. But you have to present them to the team at the next refinement.
• Before the end of a refinement, you can make tasks to be done, before the next refinement begins, like investigation tasks. Find out what you want to do together, or you want to do in sub teams.

One more thing

You maybe wondering where the solution comes in. I know for sure that everyone in the team has thought about: how are we going to implement it? When you start a user story, you can have a brainstorm about that. 

The way it looks like in the user interface is absolutely not the most important thing! You need to find out during the implementation. The most important thing is that you have implemented the feature in the most simple way. Tweaking comes later. Feedback will give you new ideas.

Mirror neurons

You know what mirror neurons are? They are things that causes you to feel what another person feels. Mirror neurons work like when you see someone eating a lemon, you kind of taste the vinegar, without eating it yourself. You are trying to experience what the other person experiences. If you hear someone scream, you immediately try to feel why the other is screaming, for example an awful scream for help. That definitely triggers something, right? It looks like these neurons work when you are seeing or hearing someone.

But i think we underestimate these neurons. I think we can activate those neurons ourselves, without any interaction with an other person. You don't have to see or hear anything to activate these things. Let me explain why I think that is. And maybe you're with me on this.

Don't you have that experience when you are working on a problem and you are kind of trapped into it? And when you ask someone to help you, you come up with the solution all by yourself, only by explaining what you are doing? I think at that moment, we kind of triggered those neurons ourselves. It must because you are unconsciously thinking about what the response will be from that other person.

I was working on the previous blog about talking magic. About having interaction with someone and how that results in more brain activity. But there is more happening than just talking. I wanted to point that out in this blog.

Maybe we can think of an science experiment to proof that this is true. If I figured out how to do that I'll come back to you on that. And of course if I'm proven wrong here, I'll delete this post.

Talking is magic

Over and over again I realize that talking has got some magic in it.

yesterday morning I was sitting in the train. There were people talking about the notify broadcasting voice saying at which station the train will stop next. I noticed for a few months now, in fact everybody who is riding this train knows, that the announcement for the next station is way too early. And the same thing happens in the opposite direction.
I don't know if you've noticed a pattern here, but for that several months I didn't. Apparently my brain stops evaluating any further. And there is no need to think of it any further, so it kind of stops combining facts. If you ask me, I think it's a good idea to stop right there. Otherwise it's maybe causing an overload.
But then the magic begins! I started to talk to these people, while they where laughing about this error and that the company should do something about that. I said that they probably know that the same thing is happening in the opposite direction. They agreed and wondered if it also happens at the following stations. Right there it came to me. From that moment I think I figured out what is going on.
There are obviously two GPS points on the route which triggers the announcements. One for back and one for forth. Presumably they switched those coordinates. The one for forth is meant for back and the one for back is meant for forth. And it would be a good guess that the whole route is switched. If it is switched back, it makes perfectly sense and the announcements are right on time.

The thing is that I was not triggered to think any further. My brains thought they had just about enough information. But when I started to talk and got some feedback, it kind of moved forward across this barrier.
So there you got the magic of talking!

Agility comes from unexpected places (f.e. Jeremy Kay)

I don't know Jeremy Kay. I don't know who he is, but I know what he does. And as the title suggests, agility is not coming from development only, how much we like to think it is. It's kind of becoming nature of our process, or some kind of instinct.
I have got all the DVD episodes 'Life' from the 'Earth' project from BBC. it was given me once for my birthday. They are talking about agility as well (see episode 5 scroll to: 10:00). So agility is just a word for the ability to change when your environment forces you to. (Ha, I always read over my sentences before I publish and I realized that Agility is pronounced almost the same as Ability. So Agility is an Ability. You have it, or you don't and hopefully you can learn it)

Jeremy Kay is a graphical designer. For unknown reasons, he figured out how to render an image without making use of some kind of rendering plugin. Now I said this, I realize it's not important for this blog I'm writing. So sorry for this background information. However, if you cannot afford a plugin in Sketchup, and you've figured out how to do it without one of those, you are apparently being agile. I suppose this should be between brackets. Darn, I'm bad at writing decently.

No, the thing I want to point out is this: Jeremy is explaining how you setup layers of a model you've created in Sketchup. Out of curiosity I was watching this video, because the mail from google was catchy and tempting enough to take me there... Anyway, while I was watching him export and import pictures into Photoshop, he explained something about customers. I didn't see that coming from just another YouTube video. This is what he said (click on the header picture and scroll to 4:30):

'Design is an iterative process with a lot of conversation between you and the client. And the more you can make the client feel like they're engaged in the design process, the better the end product is going to be. But if you show them a photo real rendering at an early stage of the process, they might feel like you're trying to show them final architecture. So our theory here in the studio is: the softer the drawing is at the early stages of the project, the better!'

Awesome, isn't it? But unfortunately, most of the companies still tend to do not so. It's a shame.

Guidelines for testing

I'm really not fond of forcing someone to do something. Make someone do something while they're not agreeing is like giving vegetables to a dog and force it to eat it. If you take a look at the picture, NASA is also testing their parachutes. They don't do that for fun! Sometimes tests are necessary.

As you can see in some of my previous posts I didn't like unit tests at all. That was 6 or 7 years ago. Back then it was no use forcing me to create unit tests, because I was constantly looking for a way to avoid them. And that worked quite some times. You can force someone to do things, but he will do it without putting his mind to it and so the result must be a pale shadow of the result you are trying to achieve! In my opinion, the only thing we can do about it is make it fun, or make it a challenge.

Guidelines for testing (from a developer perspective)

1. All the code you added or updated should have a 100% test coverage.

You can read this as: aim to get a 100% coverage on you code. Don't be too easy on the percentages! I know there is tooling that can help you with that.

1. When you are working with legacy code with lots of nested loops or if-statements, try to put some end-to-end or integration tests around it. Then try to refactor it carefully. And finally create the unit tests that cover your new mutations. They will fail if you do it TDD and you can start on the real implementation.
2. An other option is perhaps creating a class with only the functionality or business rules you need to implement and try to inject it or instantiate into the 'old' class. You can test then if it is instantiated and you can test the class all by itself.
3. If you are working in source code that is suitable for unit tests, go TDD on it. So first create your unit tests and then go ahead and make your implementation. And remember, you almost always have to refactor the original code. Get the clean class clean again!

Note: TDD is something you have to learn. It's not something you can master instantly, so experiment with it a lot!

Note: If you come across too much variety to test your unit to create a 100% coverage, then you should ask yourself if your unit is indeed one unit and not multiple ones in one.

2. Collaboration before and during the user story between testers and developers.

It's very important to make a deal between developers and testers on what the test approach will be. I think you can predict quite good what tests there will be or must be written. Try to get synergy out of it so that the tester tests not the same tests as your automation tests. Of course, if you decide to have it tested both automatically and manually, you should do so. Write down your scenarios and try to come up with deviations and variations. Talk about:

1. Unit tests. As a developer, try to make it clear to the tester what your units look like and how you think you can test them. Business rules are of course perfect examples to talk about. Try to find out what the need is for unit tests and maybe the tester can point out some unhappy paths you didn't think of.
2. Integration tests. Try to use a Gherkin tool test environment. Something like SpecFlow, Fitnesse or Cucumber. You can use only functional sentences in here, so no class names, properties or arguments! Be clear on what your new functionality does and why it's there. Use the common way where you point out who the user is, what he wants and especially why he wants it. 
3. End-to-end tests. You have at least one end-to-end test to make sure the user interface works correctly. One happy path should probably suffice.

Note:Run these tests each in a different rate! you should not overload the build server by running all of the tests always. The rate should be something like: Unit tests: always, every build. Integration tests: twice a day. End-to-end: once a day, maybe at night. There is always the possibility to consider running all of them locally of course.

3. 10-20-70

These are the percentages for these 3 kinds of tests. End-to-end: 10%, Integration: 20% and unit tests: 70%. This is a recommendation of course, but try to monitor at the end of each iteration or two what the percentages are. If you end up with 60% end-to-end tests, something's wrong. The same for extreme deviations in the other type of tests.

4. Code coverage

Code coverage will help you to see where you, as a developer, dropped one or more stitches. Keep in mind that common sense prevails! You are in charge of the tool and not the other way around. Use it to make sure you covered your code well enough. Of course in consultation with the tester.

Conclusion

Don't consider not making tests! You benefit from them too much! At first glance you think they disturb your coding process, but (this is a fact) they help you code the right way and they will give you a higher speed!

Also, read the clean code book from Robert Cecil Martin (uncle Bob) or watch his video's (they are fun to watch). They help you understand why it is inevitably to always have tests and what happens if you don't! Or you should do a test like a code kata on two groups. Let them separately work on software that constantly needs changes. You'll see what happens! 

Note: Learn from all your experiences and keep steering to the right direction!

Traffic jams

Let's talk about traffic jams. You know the rubber necking, when you are staring at the car in front and wave to the one next to you. Always curious what kind of men or women are also joining you on the highway? And you begin to wonder, why do I have to go through this almost every morning and afternoon? Does it make me glad to be on the road, or does it make me real mad? Let's ask ourselves a couple of other questions first.

First question is: what causes traffic jams?

You know that when one car reduces speed, the traffic behind that car reacts on it. So in short, if one car or more hit the breaks, even if it is a mild break, the cars behind these vehicles also hit the breaks. And most of the time they hit the break harder than the car in front, especially when they are close to each other. The smaller the distance between the cars, the greater the effect will be and the more likely there will be a traffic jam. Also when you are a not predictable vehicle, like when you're changing lanes a couple of times, you affect the other drivers as well and there it goes again.

Second question is: how can we stop the traffic jams?

The first answer is: if you, as a participant of the traffic jam, try to remain a constant speed, the traffic jam will dissolve. The second answer is a supplement of answer one: try to avoid making other car drivers nervous by not making sudden moves to the right or left. That will of course because car drivers hit the break and you start the effect all over again.

Third question is: how can we prevent traffic jams?

Sure there will be trouble on the road. There always will be! For instance, someone having a flat tire, or a bike falls off a car. Someone gets unwell.

So one truth in that is that you can never hold back the traffic jam for ever. So what do we need to do then? We can have less cars on the road, so it get's more containable or, like Google, have cars interact on each other and let the car do the driving for you. More alerting systems will help too. Drive steady and not with fluctuations. We can summarize this in one word: control! We do need more control on the road.

Why do I write a blog about traffic jams?

The first answer (just to stay in tune with the previous questions) is: it's fun! Second answer is: you probably know what I'm talking about! But let's see if you come up with the same comparison as I do.

The cars are the functionality that needs to be taken to the customer. The teams are steering the car. The stakeholder and managers are the people who want to get the drivers move faster on their project. They see gaps between the lanes next to the car and tell the driver to take that lane to speed up the project. So they are maneuvering the teams through the traffic. And if you tell the driver speed up, you are about to let him make more mistakes. The thing to do here to prevent traffic jams is to instruct the driver how to drive. Also the driver clearly has an appointment! If you need to travel more distance than you expected, or have less time then you expected then you logically have the urge to go faster. So maybe you had to schedule it for some time later, or should have hit the road much earlier. Be prepared! Take control! Just be sure you remain driving steady at your familiar speed.

So, do I feel happy on the road?

Maybe we need to ask ourselves: are we happy on the road? And furthermore, is the customer happy to have to wait for their functionality, because we didn't make it in the time we scheduled. Or if we do have it delivered in time, are they happy with a wreck then? Maybe we should also think about what the costs will be when we crash, for example the emergency services, the damage and the settlement with insurance companies. Your car can be prepared, but it will be lower in value.

Next post, coming up!

It’s so nice to talk in metaphors when you have such a vague subject to discuss about, you know! The next post I will publish will be about: how to control your projects and sprints and that one will be quite specific and not vague at all. Thanks for reading this through to the end. I hope you enjoyed it. And remember to comment beneath this post if you have any questions or submits.

By the way: in the Netherlands, the maximum speed is recently changed at some sections from 120 to 130 kilometers per hour. So keep in mind that we can change the speed, but we have to make sure we still don’t have fluctuations in speed and we have to make sure we make our goal in a well chosen time! Remember: it's all about control!

No testing? What?

Create code without unit tests? No integration tests as well? And no end-to-end tests?
Let's first start with unit tests. What kind of programmer are you when you produce no unit tests? Are you not feeling responsible for your creations?
Mmm, I think I went off the wrong foot here, maybe I shouldn't start off with accusing people. Maybe I should start just with myself, some years earlier.

When I was younger...

Man, did I hate unit tests for 6 years ago! Really, I disliked them a lot and I never created them! Boy was my code rotting back then. Maybe it was because someone figured out creating unit tests was mandatory? When it's obligatory to do something, when you are judged on it, you get an aversion on it. No one needs to tell you what to do, right? It's stupid someone needs to tell you how to develop! And I think you're right about that! Congratulations! You are the best developer ever! 

Turning point?

And at this point you suspect me to I turn this euphorically feeling about the pigheaded developer, who has enough experience to know what's good for coding, around, right? Well, I love to do that. And, most of all I can, but I won't. Not now. Just let me take you back 6 years ago, when I was working at Isala hospital. 

Fixing with great effort

I remember doing a fix at the login screen. The user wanted to let the program remember the role which he/she was logging in. Well, if you know me, I fix with great effort. I really don't like confusing classes and many nested business logic. I didn't read the clean code books or watched any video of it at that time, so I didn't know how to convert a class into clean code. Also I didn't know how to write unit tests. In fact, I did heard the words 'clean code' but didn't know what that meant.

First I was trying some things out and after a few hours I knew how to proceed. I locked myself up, set myself apart from the rest and went on. Maybe you know the feeling I felt at that time: feeling a little sneaky, knowing that you are doing something admirable, but in the mean while guilty because you do not involve anyone on purpose while you should have during a growing numbers of decisions.

And all those decisions where crucial points to be tested. I knew at that time that the number of tests or test cases grew exponentially. And still that didn't kept me from stopping my refactoring and certainly I didn't recommend the testers to watch out for more tests in that specific areas. I went on stripping and re-writing the login page and all the classes involved. (There were also classes who had responsibilities and business logic meant for other functionality, so my refactoring affected a whole lot of functionality other than logging in) 

Throughout the years I've been working at Isala, I was constantly remembered as the guy who dared to re-write that crucial part of the program. 

Good job!

Okay, I felt a little bit like being a hero. And that felt good! Or not quite? What the hell did I do? How did I dare to refactor so much code with so many crucial points in the code any many points of no return. I think it took me a whole week and no one actually knew what I was working on. No one asked me questions about what I was doing either. (During the stand up, I said I was working on it and encountered no problems) 

If I look back at that week, I am smiling now, but boy, what did I take a risk! Especially since I didn't created unit tests at all. Furthermore the code itself had no unit tests as well, so I couldn't be sure enough to determine the quality of my work.

Okay, the result was unbelievably good enough. During manual tests no issues were found. But in production one issue was found and it was corrected real quick (not by me). I was hanging by a thread, as a matter of speaking.

Or not a good job?

So, what is the problem then? I was confident enough to proceed with what I was doing. I thought I was doing good, but I was a Pigheaded stubborn developer: looking for trouble! 

1. I didn't let anyone in during refactoring. So no pair programming, so no extra pair eyes looked at what I was doing.
2. After the rigorously refactoring of a week work, I all checked in at once. So no one could really tell what I did and how I did it because of the many changes, so reviewing was impossible. The whole structure of the previous classes was completely gone.
3. I didn't create any unit tests. Unit tests can help you with weighing your classes and their responsibilities. And most of all, if someone changes the functionality, the unit tests will help you on the existing ones.
4. I didn't create end-to-end tests at first, so the functionality and the user experience wasn't being controlled.
5. I pushed it into production and prayed it worked!

So what did I learn? At that time: nothing!

Conclusion

I don't give you a solution and condemn you. You should figure it out for yourself. You should think about the development you did recently and ask yourself: did I comply to these 5 points?

Note: (There are more advantages with tests, but I only focused on these 5 things, just to point out the danger in writing code.)