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.)