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

Take a seat!

Small things

It's in the little things where you don't realize you affect the people who are trying to communicate. In fact, everything you do has affect on your surrounding environment, and even affects a whole lot more, most of the time it's not a big deal, but let's start with being aware with a small example.

Take a seat!

When I'm on the bus, sitting at a two seat and I'm sitting at the windows side, everyone who comes into the bus can take the seat next to me. But, when I'm placing my bag next to me, I create a threshold, a barrier. People do now need to ask me to sit next to me, before they can take their seat. But, if I have my bag beside me and I keep my eyes closed and pretend I'm asleep, I'm creating a small wall around me. People who want to sit next to me are having trouble or difficulties to claim this seat. They first have to wake me and waking someone is not polite. Then they have to ask me to sit next to me.

Back to business.

So, it's in small things you just don't realize what kind of emotional effect you have on people, without being aware of it. Now back to business and ask yourself: what kind of effect do I have on people when they want to ask me a question, or are in need?

You may come with arguments like: when I'm busy, I don't want to be disturbed. I need to finish what I'm doing and then I can answer some questions. You probably don't realize that your reaction can make it harder for someone to ask you a question again. And if you continue to do that, those persons will never ask you any questions anymore. And then you can say: well, it won't come this far with me. I'm nice enough and I'm helping people a lot! Yes, you're probably, hopefully right! And there are some times that you need to be undisturbed. In that case isolate yourself. But at all times: you have to try to take your bag off the seat!

Agility by Robin Williams (Need for feedback)

 

Are you aware that you're being bombarded with lessons? The picture shows a lesson of Robin Williams (1951-2014), but that's not the lesson I want to talk about in this blog post.

Wisdom through TV?

Couple of months ago, on a lazy evening I was watching television. The greatest comic in history, I think, died due a depression. It was Robin Willams at an age of 64 years. Though he seems to have had a happy life from the outside, he obviously didn't in his personal life. I guess he was more trying to make the crowd happy rather than himself.
The show babbles along while friends and colleagues tell about him being a great actor, father, comic, that he was flabbergasting and astonishing, and he was the greatest man on earth. You know how that sort of documentaries come along with that kind of hail and hallelujah. Of course he was a great man, but if I had to learn one thing from him, it's not one of the great phrases he said, or good things he did, but it is this comment that he made about thinking up his stand-up comedian shows.

Audience

Here's what he said: 'You have things in the back of your mind that you think yeah, these ideas, yeah this might work. Mmmmmaybe, yeah, mmm. Here's the core vision that makes it all work; it's the audience! Well, you can think of these things alone and a lot of times you are, and then you take it out in front of the people and this works or this doesn't work. It's a combination of okay, this might be the wrong audience for this routine, or this is the perfect group to do it for.' (link: 31:55)

Actually he's trying to explain that, no mater what you think of 'for' the audience, the success of it depends on the 'kind of' audience you're dealing with. This conclusion is coming from a great stand-up comedian, but is of course applicable to the not so humoristic world of software development. But then of course you can make it more fun by changing your style of developing, but that's an other story. Maybe I write a post on that subject as well.
But to get to the point of this blog post: It's absolutely mandatory to let the audience play with your software for a while and make sure you study their behavior at best! (This is the strongest sentence I could came up with. Hope I convince you.)
You have to find out if your ideas are good ones. Try to tweak your ideas, UI and back-end to the needs of the customer. Even throw away your features if the customers don't like it and come up with new ones. That last one by the way, may be the hardest thing to do.

Need for feedback

Always, and I mean every always, consult your customer on everything! You cannot successfully do it on your own, no matter how smart you think you are (think of Robin Williams, he was a genius and he couldn't do it on his own). It's the 'need for feedback'.

To win some or to learn some!

This morning I was singing while biking to the train station. I am someone who constantly looks around to see if no one is in the neighborhood to hear me. But in some cases I'm singing up load while someone is passing me by and I didn't notice. Hmmm, maybe I'm getting into detail a little bit here.

Take your chance.

Well, what I wanted to say is that I sung a song of Jason Mraz. Not that I am a fan, but it's a nice song to sing and the most important thing is: I know some of the lyrics. One of the sentences is: 'I reckon, it's again my turn to win some or learn some.' And while I'm singing it for quite a long time I never realized that this phrase is actually a good point.

I imagine that Jason Mraz was trying to be cool to win a girls heart, but the beauty of her was actually too much for him to keep being cool. And because he wants to approach her, he realizes that now is the time for him to act to get close to her. He won't get a second chance.

Never loose!

'To win some or learn some' is the phrase that got me writing this post. And though the song is an ephemera for Jason and it's dandling away in the long line of easy listening music and small pop songs, I like mr. Mraz's attitude! Because the opposite of winning is of course loosing. But if you look at it that way, it's kind of sad.
And then I totally agree with Jason Mraz, that when you are not winning, you at least have learned something. Most of the time you even learned a lot. You just have to look at it that way and you'll never loose again in your life. You're always a winner!


PS. I know this last line is kind of pathetic, it reminds me of children competition games on television. None of the children have lost the game, everyone is a winner. I'm also truly sorry for this postscript by the way.

Faster documentation? Catch up!

This is a memo which I just send to the stakeholder who asked me to try and find a way of dealing with documentation. He finds it not necessary having the documentation run far behind the release of the functionality it belongs to. And I think he's got a point.

Memo:

Customer documentation

Since we want to continuous deliver software, we must also continuous deliver the documentation for it. If the user manual constantly is being delivered far behind the functionalities, than the customer has software and no idea how to deal with it. This by the way is alarming already.

Introduction

I have a hard time to always be confronted on the fact that my recommendations are structurally too much for a company. In fact, I think that every individual has a hard time having that, because a company is mostly depending on more than one person who makes decisions. So in short, this memo might be at first glance too blunt to deal with. That being said, this memo could be a real good sketch to have more success.

Current status

The only thing we do now is add release notes to the user story, that’s part of the definition of done. Other documentation is only technical and is been kept in the user story. This documentation is mostly information on how the user story is meant to be and is how it is evolving during the implementation. All implementations are incremental, that means that full functionality is at the end of all implemented incremental stories. And each incremental story is a stripped version or working part of the full functionality. Each time we deliver or finish a story, the user has something to work with.

The developers have gotten knowledge of the user story by having refinement, creating the user stories with their product owner and by collaborating within the team during the implementation. That means that, if there is information on the subject, it is in a minimum amount. This is just enough to do the implementation well. That is the general idea right now.

After publishing the functionality, a team picks up the new features and blend it in the existing documentation, create ‘How to’ videos and produces manuals.

Future possibilities

If I think of adding documentation to the user story, which tells the user how to deal with the new functionality, I foresee a constant changing documentation with adding new functionality. That’s because we implement incrementally. Also, when we have delivered a piece of software in former sprints which is implemented and documented months ago, it’s hard for a developer to change this documentation, because the source code isn’t hooked on to the documentation. The source code and the documentation (user manual) are two separate things.

Suggestions

To continue after these explanations, I would suggest three things. These things are each responsible for reducing work and reducing documentation changes. Also these things are agents to get a better understanding of the functionality and therefore better produced code. Let’s take a look at them:

·       Let a key user frequently or constantly spend time on a development team. This ensures that we make exactly the software the customer needs. And therefore the minimum amount of time will be spend on documentation. (Cause we don’t have to change it much)

·       Also let someone who is responsible for user documentation spend an hour a day or more on the development team. He is at that moment in the middle of the change so everything is fresh by understanding the functionality.

·       Let a user experience (UX) colleague frequently spend time on the team and work together. Not as we do now separately. Currently it’s like this: the development team thinks they don’t need a user experience guy much and the user experience guy thinks the same about the development team. But this tight collaboration ensures us that we make the software so intuitive that we have to document less. And that leads us to spend less time on writing or altering one, in definitely.

The people who are drawn to the team will give us good and quality documentation. On the other hand there is a synergy step here. The development team gets better at writing functionality, the key user gets better quality software, the documentation is written due one on one collaboration with the developer (a tester is a developer as well) and the user experience guy (or woman) is working both with the key user and the development team all by working together on the job. And that brings us very good quality software!

Summed up

And though we only wanted better documentation, we end up with:

·       a better process,

·       better understanding of the program,

·       better functionality, which becomes more intuitive,

·       no delay due documentation written afterwards and

·       of course what this has initiated in the first place: good and fast documentation!

Postscript

I know I’m speeding up too fast in contrast to the company and I want more than I probably can get or accomplish, but this is the ideal picture of a good running software development. This is how we get a good product and good documentation for the customer (you may also read: good collaboration with the customer).

And finally I really must point out that the more you spend on caring for development, the more intuitive the software gets and the less the customer needs to learn and read about it. We also need less courses to give to the customer. And if the software is more intuitive the threshold becomes flattened for people who aren’t specialized in, but want to have bookkeeping software.

Simple Continuous Delivery

Continuous Delivery is a very simple process. This is how it could be:

1. Always deploy on the customer environment.
2. Make use of small feature branches.
3. Make sure you have always very small features. Try to spend no more than two hours on it.
4. Do Test Driven Development!
5. Create some integration tests, let it run while you are about to deploy.
6. Create end-to-end tests when needed and run all just once a day.
7. Have very, very short feedback's from the customer! Make use of on site customers or key users.
8. Spread functionality as much as you can over the different teams, so that merging isn't going to be a problem.
9. Don't be afraid of making mistakes!
10. Don't make deals that result in a deadline!

That's it! No problem.

Daily stand-up

Oh oh.

I fell into a trap. You know that kind of traps you know of, but don't realize you're right in the middle of it? Well, I think it happened to me right now. 

I'm always aware, or at least I thought I always was, that a scrum master is a coach and not a lead. Well here's my confession (Hmm it sounds like  a catholic confessional), I always take the lead in the stand-up. Oh oh.

What is a stand-up?

Let's take a look at what the stand-up really is. In real basics it's this:

1. Awareness about the sprint and especially what's not been done yet,
2. A small planning, only for one whole day, about how to be as effective as possible on the user stories left.
3. (not a goal, but an outcome: be transparent to the product owner and stakeholders on the status)

So basically, as a developer (remember that a developer is a member of the scrum team, so testers included) you need to tell what the progress is on the user story you've been working on and need to know the progress others have been working on. You need to know, as a team, how to be as smart as possible on finishing the user stories left on top of the remaining sprint backlog.

In short you have to do these things, according to the user story you are working on:

1. Talk with your fellow developers what the status is of 'your' user story.
2. Find out what needs to be done to finish 'your' user story. (short comment: this can only be done when you have small user stories. If you got large ones, it makes no sense discussing the whole thing)
3. Set a clear goal on 'your' user story and create an efficient plan how to work together to get things done.

Take the lead!

As a developer working on 'your' user story, take the lead in discussing it! Because you're kind of an expert on it, since you're the one working on it. The ones working on the user story are kind of first responsible. Discuss how you feel about the user story, what you need from outside the team, who can help you most, or what do you think will happen. Be aware of your job!

Be ready for the future!

So, here we are, on a normal day, staring once again at legacy code and wondering how to wrap a new feature around it. I know you've been there, because I have. And I'm surely not unique. And if you haven't, you'll turn out to stare the same way to the code as I did.
That's when the questions come and they come naturally, because it is not the first time you encountered such a mess. How on earth could a developer implement this software into our application? Look at the dependencies, look at the design!
And the memories of former similar projects unintended pop up into your head, giving you the scrupulous feeling of a dejá vu. And that's not all. It makes the hair stand up on the back of your neck. You know what is going to happen and you live with it, because there is nothing you can do about it. You just have to go with the flow, like you always did and everybody does.

Johnny Raw

Now that's the problem you have, right there. When someone comes up to you and says 'Hi, let's do continues delivery!' Al those memories and feelings about the code, gluing, aftermath, struggling, wrapping, trying to make the best out of it, the bugs which eventually will come because you unavoidably broke something, all those feelings are coming back. Especially when someone who's been at the company for a very short period says it!

Biases

And then the discussion comes on how 'we' should become a company with fully integrated continues delivery. And what are you doing then? You are trying to disapprove or refute every suggestion he or she is making. It's not your intention, I know. But it will happen. Why? Because, the common feelings of trying implementing something beautiful which always end up in a disaster, are embedded into you head. And they are easy to trigger. In fact, there are the watermark of your thinking, you cannot think without it. They become one with you. Inseparably. They are called 'preconceived biases'.

Stuck?

Well, that's splendid! Stuck with legacy code and your own legacy thoughts. What do we do now? Can you free yourself from your subconsciousness?
If you are ever willing to free yourself from this you must avoid these things during a conversation,

• rationalizing, 
• being constructive,
• thinking relative,
• justify your feelings about possible solutions that come into you head or come from others,
• bring upcoming thoughts or comments into perspective.

The moment you get negative feelings about something, you have to ignore it. This way you can free your mind. Especially if you are in a group, with everyone speaking their thoughts up loud and with someone who interrupts a conversation when things are getting negative and guides the group towards solutions again. If you allow rationalizing, justification and perspective, you will never get to good ideas. Don't let those negative thoughts control your group. They will come eventually by themselves after the meeting, or when you're trying to define actions. All comes later! And, if you try to do those sessions more often, you get used to it and it becomes more natural. 

Good luck doing so!

Ultra High Definition

(Here's is a metaphor for you. Especially when you company want to just continue making great new things and not wants to spend time on refactoring and continuous delivery)
See your company as you as a father. And imagine the software as your child. I intentionally chosen the father by the way, because of his characteristics, you will see during the story.

Shopping

You and your child are going shopping. You're walking along fine, but your boy needs to go to the bathroom and you're in trouble. So, as a good parent, we take it by its hand, go search for the nearest toilet and make sure it's clean though, otherwise you got other problems. And finally you can continue shopping.

But, we all know, we are not good parents when it comes to shopping, are we? Because we need to go to the store and buy us a new television. With Ultra High definition, because we need to be ready for the future. Think of all the possibilities that may come with that. Just high definition is not good enough.

So, we take the boy by the hand and go to the next store to compare some. You buy your child an ice-scream, because otherwise it wouldn't go to the next store. Go sit for a cup of coffee and a hot chocolate and then... there you have it. You end up with... Right! A pee or a big Winnie the Poo(h) between his legs. And now you are in real trouble. Cause, even when you've got a spare of trousers, it is from when he was one and a half years old.

Recap

So you start thinking about what you could have done... You could have taken him to that nice hospitable cafe just around the corner, where you, when you where young, had a good laugh with your friends and where you even met your wife.

Now, what you're plans may be and what great things you want to buy, you first got to do something else! You know that in the near future the shit will hit the fan when you continue doing what you are doing. And again, we are not a good parent, and maybe it's because this child is only a piece of software, but we can start now being a good parent!

Little trick to become better? (or do you not dare to?)

One thought for the mind. See for yourself what you do with it.

What is the risk of having it all? And what if you can get all that you want? You probably thinking the same as I do: you get lazy. And when you do, you don't have to think more than you need. And do you get any better then? Nope. Not much.

Reunion

Last weekend I had a family reunion. There were a lot of kids. To contribute to the entertainment my wife made a goblins hat for every child and we went through the forests to find the route of the goblin to end up at a table of goblin cookies. At the table I was sitting to sing some songs with the kids. The kids seem to love it, so what do you want more? 

We also thought of making soap bubbles. And not just soap bubbles, but really big ones. You need 2 sticks for it and a rope through ringlets. To screw the ringlets into the sticks I took a pair of tongs. Nothing special about that you think.

But that was until my oldest son came around and of course he could join me build one of these bubble sticks. I gave him my tongs, the sun was shining and I had no intention to go to the shack to get me an other pair of tongs. So I tried it with my bare hands, but it was quite a bit painful. I didn't realize at that point I was ending up pretty primitive by the lack of tools. So what I did is look around if anything within reach could help me get that ringlet onto my stick. Especially within reach! Because again, I didn't had any intention to go anywhere but my garden seat and get out of the beautiful sun and ruin this lazy morning I had. If I must, I just finished the things by hands while torturing myself. 

Then I saw a little crack in my garden furniture I was sitting on. That gave me the idea to screw the ringlet just a little bit into my stick and then place it into the crack and screw the wooden stick on to the ringlet, instead of screwing the ringlet onto the stick as I did before.

Conslusion

The screwing of the stick onto the ringlet turned out to be much easier and faster while my son was still struggling with the tongs. And with this stupid example, I realized that when you miss something, for example: tools, you are effectively finding a solution for something you didn't realize you need any solution for! So there may be tools, that you think you need, or got familiar with, which turn out to be not the most effective tools to create the things you want. So maybe you need to let go of a tool once in a while and find out for yourself. Do you know already which tool you're gonna ditch? Do you dare to loose some tools?

Time for an other subject now

It seems I got a subject favor... I think it has something to do with agility. And on this post I'm really off subject. Really, really off. This post is about time.
I saw some YouTube videos on general relativity and quantum meganics. Thé interesting thing in these subject is of course time. Time dilation, slices in space-time, observers point of view and that everybody experiences time differently. Maybe I put some urls at the end of this post and you can enjoy these videos as much as I did.

Inevitable

One of the conclusions of these videos is that the past is not gone and the future already exists. And that's what struck me and got me thinking. If everything is inevitable, what is the meaning of life and do I have a choice of how to decorate my life then? First I thought, well that's nice. Everything I do and everything I think, everything I want to change already exists, so what's the point of changing anything? On second thought, I think we do not have to worry if the future is written or not, because: think for yourself, if I want to change the way I live tomorrow, I can, right? If I choose to take a plane and go the south Africa, I can do that, whether I'm bound to do that or not. I am still in control.
A few years back there was a pilot series, I believe it was called 'flash forward'. It only lasted for a year, so season one is the only season that ever came out. But the subject was interesting. Everybody on the planet had a vision of 3 minutes of there own life in the near future. I think the time period was the begin of the year, let's say January. And the flash forward was during the countdown of the end of the year, noon new years eve. (the ones who didn't got the flash forward, well you know what's going to happen to them...) But the funny thing is that everyone who didn't like there sight of their future tried to change it. But how hard they tried to, they where destined to end up exactly how they where shown. Everything felt in place. But (un)fortunately, that was fiction. The story told us though that you can't escape time, because it was already written.

Static Assets

I came up with a theory or an explanation of time of my own. I searched for it on the internet, but it seems like no one thinks about it this way or it seems that I cannot properly search the internet. So the theory is this: time and the whole universe is static. It is made (how it is made or it evolved is not the question here) and it's staying the same. Time is static because if you think about it, time is different to everyone because time is relative, so I can imagine a perspective from a point or dimension that has no concept of time, time is just an other dimension added to the dimensions we know. So I think that you cannot say that 13.7 billion years ago the big bang happened, because time is a thing we humans experience.

An other point I find very interesting is teleporting and entanglement. It looks like it proofs the existing of more dimensions. In a two dimensional world, two points can't be at the same position at the same time. But when you fold this two dimensional world, (and while you're doing that, you are adding a new dimension), you can bring those two points at the same position at the same time and you have some sort of entanglement. So if you could do this from a two dimensional world to a three dimensional world, you can do the same from a three dimensional world to a four of five dimensional world. If you read about quantum mechanics, you know that electrons and other particles can be at different places at the same time and jump without spending any time on it to an other place in the atom. So that concludes there could be (and probably are) more dimensions then we experience in our world.

Further more I think or can imagine that we humans and every living thing is having the conception of time. But in fact (or in fiction) we are gliding along on some kind of wave through the life we live. We are moving through our life and through the world. And we experience time because we can measure it and we got confident with it. It feels real. It feels so real because it looks like we are allies with it. We are dragged along and cannot seem to go backwards on it. We are trapped.

Rephrase

This may sound like a gloomy perspective, but I think it's not. It seems to me that we humans are enlightened to know what we are and how this universe works. I find that some kind of victory to the human kind. And from my religious perspective I find it confident that I am part of the universe God made for us. And I think that if I wasn't a Christian, this whole idea troubled me a lot.

Things that we can think about thoroughly is: what are black holes then, since time completely stops there? Is it some kind of exit from space time? And wormholes may be a location through an other dimension back to our dimensions?

What a post...

I hope that scientists can figure out what's more in this universe than we can see, feel, smell, taste or hear. Let's find out in what beautiful universe we live in.
This is really the weirdest post I ever blogged and it has clearly nothing to do with agility, but I felt the urge to do so. I apologize for that.

(note: I don't think the static time theory is mine alone. There must be a lot of people out there who think the same. I was just having a great time blogging this ;-)

Don't worry about acceptance criteria!

What? What did you say? Don't worry? If I got no acceptance criteria, how should I be able to test it then? And what about the developers? How can they build something without knowing exactly what they should build?

Hold your horses.

I said, don't worry. Really, there is nothing to worry about. Why? Because you took your time to refine well. You know what to build. You spoke about it and asked questions about it. You even gave a suggestion to do it a little bit different and while doing so, the customer would be better served. You developers have investigated the code by getting a resource. Someone who knows how the current situation is. He gave you anchors where to begin and how the architecture was build up and why decisions where made.
The product owner has explained what the customer wants and why he or she wants it. You know the benefits of the solution. You all together created some scenarios, just to get a good feeling about it. And those scenarios helped you to find a direction to go to and which way you should not. You triggered someone to say something no one had thought about. You eliminated the questions and a whole lot of uncertainties.

Exploration

So why worry for somewhat incomplete acceptance criteria? If developer and tester, keep up together on the user story, the acceptance criteria will grow by itself. And in stead of having them written in stone, you'll find a much nicer way to define your story. You explore during development what the possibilities are. You make sure you get constant feedback from the product owner or the key user. You find out all together what you're really going to create!

Be happy

And when the story is implemented, you are very, very sure that you have all the acceptance criteria you want! So, don't worry about the acceptance criteria, and enjoy the exploration during your implementation. It's going to be fun, mark my words!

Woohoo: chunks in real life!

Yes, we've had our third refinement in which we tried to create chunks of our user stories. What I expected to happen is becoming true. It's very simple. When we create chunks we do it by three different ways.

1. Just talking,
2. Think of scenarios, we can group them later,
3. Using functional diagrams.

By talking (and writing down), you distinguish patterns which can lead to chunks. If you create scenarios you can see patterns as well by grouping different kind of scenarios. Each group can be a chunk. If you take the effort to draw a flow diagram with some decision paths, it becomes very easy to turn one path, or a group into one chunk.

This looks nice in theory, but it actually works! And the best part I didn't mention is the following. We did an estimation on all of the chunks one by one. I hoped it turned out that the chunks are estimated mostly the same size. And guess what? They were! Some are four and some are 2 story points, but the most chunks we estimated are 3 points. And given the fact that the average is 3 points, voilà, there is no need to estimate them ever again!
That's a relief but it also saves a lot of time! Woohoo!

Maybe the near future?

So, you’re the new trainee, Welcome I’m Vincent, I’m a developer and I’m also the Scrum Master of the team. This is Tim, he is tester. This is Eric he is developer as well. And this is Marc. He is the product owner. And if you take a look at the display then you can wave to Galyna. She is sitting right there. She is a tester as well. Oleg C is sitting there and in front of him Oleg S, and next to Oleg you see Andrii. All three are developers. Well, this is your desk, but I wonder how much time you’re gonna spend behind it while you’re here.

(The trainee is looking at his desk.) I think you’re wondering why I said that, right? Well, we do a lot of pair programming here. What we also do is think as a team. That means whatever you think of, during the sprint, you share with others, so that your ideas and your comments will be heard and trigger maybe greater ideas because you discuss them. See it like this: we all have our bandwidth of thoughts. This bandwidth evolved because we’ve had our life, our experience and our relationships with people and things. It looks like I’m going to make a fuzzy statement here, but hear me out.  Let’s say you have you’re bandwidth from 50 to 200 on the scale of thoughts. Let’s pretend that mine is a little bit smaller like 100 to 200. Eric’s bandwidth is from 120 to 280. If you have a thought about something that’s located somewhere in the 90’s, both of me and Eric didn’t think about it. The point is: we can have lots of thoughts and ideas on our own, and we can create beautiful things, but as a team we have an extended range of thoughts. As a team the bandwidth is now from 50 to 260. You can even go further than that. If you tell your thought or idea, the bandwidth of others will start to shake. The way we are used to think is now changing. We make connections to other parts in our memory than we’re used to. And all because you said something. Isn’t that weird and awesome at the same time? Whole new ideas come alive because different people are communicating and reacting on each other. So, don’t keep quit and don’t keep thoughts to yourself, even when you think they are the stupidest things you’ve ever came up with.

Tim, could you show us what you’re busy with? Yeah, I can show you. Come and sit next to me. Or do you want a cup of coffee first? I’ll show you the canteen. This morning I thought about our user story we’re working on since yesterday afternoon. I sat down with Oleg C and we came up with some good scenarios. But there was something missing. This morning I found out what that was and I will discuss it with him in a minute. It’s a counter scenario we didn’t think of. I think we can make some variations on it as well. We always sit down with two or three people together and discuss the user stories and come up with scenarios. Everybody is contributing in its own way and we get the most diverse scenarios. It’s pretty cool actually. Okay, let’s call Oleg, he is sitting at his desk right now. You can wave at him if you like. Hi Oleg, how are you doing? Right next to me is the trainee we talked about, Peter. Listen, I came up with an adding on the scenarios we created. Shall I send it to you, so we could have a look at it? Okay, here it is. It looks good right? Can you add it to the test suite so I can run it? I want to show Peter how we work here. In about five minutes he has pushed it to the server and we can run the new test I created. We can run it and see if it fails or not. Actually I know it’s going to fail, because we didn’t think about it at first. And it’s not bad that we didn’t think about it because we’re only humans, right? Maybe we should have discussed these scenarios with more members, but that’s maybe one for the retrospective. In the beginning we had trouble collaborating efficiently, but somewhere along the way, it kind of turned and we got familiar with each other more than ever. The best thing is, when we want to talk to someone, we go ahead and do so. Ah, Oleg calls. Okay, Oleg says that indeed the test fails and the push has been made to the server and it’s building right now. It takes up to 3 minutes and then we can check it ourselves. Oleg is now in a conference call with Eric. They have been working in pairs yesterday on this story so they probably continue doing that right now as well.

Let’s ask Eric.Yes, Oleg told me about the scenario and he discussed it already with Marc for validation and Marc thinks it’s a good thing to test as well. I’m now pair programming to fix the test. Do you know anything about TDD? We first create a unit test for scenarios we didn’t implemented yet in the software and run it. Most of the times it fails and then we can do some additions in the code and run it until the test passes. Since we have one new scenario, we know exactly where and what to fix. And we’ve been through the code yesterday, so we know what we can expect. Tim usually is trying to create some bugs by exploratory or some other fancy way of testing, while we’re trying to fix the new added scenario. We are so good at coding right now; he hardly finds something. And when he does, he writes a new scenario for it, so we can do this cycle again. If you want to join us in the conference call, just pick up your headset and you will find out how developers collaborate with each other in this team. It comes down to: one is coding and the other is paying attention and keeps the overview. Right now Oleg is coding and I am not paying attention, because I’m talking to you right now… He is now making an overload to implement the variation that came with the scenario. I think in five, maybe ten minutes we have what we want and we push it again to the server, so Tim or Galyna can run the test again. If you want to take control, you’re free to do so, just ask.

So, are you getting familiar with the way we develop here? Everyone is doing something here. That’s because of the small user stories. They make our job much easier. We get those stories by doing a bit of an effort. We call it breaking and molding. You know what we mean with that? We first get an idea of Marc while he is translating the wishes of the stakeholders and the customers. It’s one big chunk of everything together, because they don’t know what they want exactly. It’s up to us to split it into smaller chunks. If one chunk is too large and another too small, we try to break off a part of the big one and mold this part to the smaller one. That’s how we get all chunks the same size and know exactly what we’re supposed to do with it. At the same time we try to think of the most common scenarios and the chunks are ready to load into the sprint. In the sprint we evaluate the chunks and sit down with two or three members together, mostly with a tester and a developer, and we discuss the scenarios some more and think of variations on it. Ones we did that, the scenarios are placed in the test suite on the server and developers create adapters for it so we can run them against the code. I think the rest you’ve already heard, right?

The ultimate goal so far: Chunks

So the title is set. Let's find out why I set the goal to chunks and what do I mean with chunks. Well, chunks are of course bits of pieces kind of glued together. They represent a new definition of amount coming from a bigger piece. See it like this: when you need to remember a phone number, the best way to remember it is divide it into... right chunks. Let me first lead you to a similar situation.

Some history first

In the earlier days, there where no books in the world except one in a library in for example Egypt. Now days when people need a book they buy it and put it on the shelve. You now have a piece of knowledge standing in your own house. And when you want to access it, you just pick it up from the shelve, search by index and find what you're looking for. In the beginning of our era, when you wanted knowledge, you had to go the a library (and traveled hundreds of miles for it) and memorize a book. For that you needed some tools to place information into your brain. When you did, you had a book standing on a shelve in your memory. And when you wanted to access it, you just picked it up from you memory, searched it by index (and believe me, you can) and find what you're looking for.
At that time you did not have calculators like we have and people where trying to find ways to memorize the best way. There are good ways to memorize information from a book, but also for storing constants. Here is where I want to get to the chunks part.

Chopping for fun

Now days, people are trying to memorize numbers for fun. You probably all seen a show on television where some dude or girl tries to numerate the number Pi. We are all surprised to see how many digits someone can memorize, but they have a system for it! They try to think in patterns and most of all, they do that in chunks of numbers. Here is an explanation of how you could memorize Pi: http://www.michael-hogg.co.uk/pi.php. You see Michael Hogg has divided the digits into chunks of four, five or pairs of three. Like a phone number, it's hard to memorize it from the whole line with ten characters. For example it's hard to memorize 0659526465 if you leave it in one piece. But if you split it up and find a pattern then you can remember it much easier: 06 595 264 65 or 06 59 52 646 5. You see, it becomes easier to remember? And I believe this way of chunking is useful for our epic and user stories.

Getting started?

Maybe you are eager to get started with chop your user stories into bits of pieces, but first hear me out. There are a few questions we need to answer first:

• Why do you even want to have chunks at all? 
• Does these chunks of work help me in my sprint?
• Should these chunks all be the same size?

Lets pretend that we have only chunks in our backlog. All these chunks are the same size. They are small and well defined. They have patterns and testable value. Because the size is small, we know exactly what to do with it and they bring no confusions. That's because we defined them ourselves before we take them into the sprint. And there are some things you might want to consider.

• If you already got the scenarios first for your user story which you wanna split up, you could look for different patterns. There is maybe a test scenario to check whether the button should be enabled and when it is, there are scenarios to check what happens when the button is clicked. Maybe there are keyboard shortcuts as well, who knows. You see, you have three different kind of scenarios focusing on three different aspects of one user story.
• If you don't got the scenarios first, consider creating some within the refinement.
• I know that we're trying to deliver a user story that provides user functionality, but you can split this previous button scenario up into three chunks. The first one is just to enable the button by authorization on user level. The second is to see if the button responses to keyboard shortcuts. And the third one completes the former user story and checks the functionality. 

And no, the user cannot do anything with a button which he or she can click on and does nothing. But the tester can almost sit next to the programmer changing this small change in the code and test it right away. You then have minimal technical debt, cause everyone knows exactly what to do and what the tester should test and you have minor code changes in one chunk. And most of all, you get closer to continuous delivery!

I think if the product owner sees the advantages, he agrees having such poor functionality. At the end of the day when you implemented 5 or 6 chunks, 2 or three of those will have full functionality.

Trip to become the best!

Measure collaboration?

What can you do with a distributed team? How do you control collaboration? What if you can get your whole team together for a few weeks. It surely will bring collaboration a real good push or boost. 
First of all, it’s very hard to measure progression in collaboration.

Let’s start with explaining what we are trying to achieve. The first thing you need is some kind of baseline. The baseline here is:

1. We are a new team and we begin from scratch and are trying to find out how to work best,
2. We don’t know each other (we all have a way we’d like to be treated),
3. The half of the team in the Netherlands know quite a bit of the software, the other half in Kiev doesn't,
4. We have no bond with each other.

These points need to be improved, so that we eventually act like one good oiled machine. The faster we can act like one team, the faster we can accelerate this machine and the faster we improve. So the first question is: how can we measure each point. Well, that’s quite difficult. How do you measure a bond between people and how do you know someone feels good with the way he/she is being treated? How do you know that the knowledge of the program is actually increased, should we make an exam for it?

The second question is: Why can’t we just stay at our current location and improve from there? Let me explain something here. When you know nothing, it costs a lot of time to get even a little bit better, because you got no grip or something you can hold on to. For example: when you don’t know how to talk, making yourself understandable is really hard. If no one teaches you how to talk, then the road to the level you can do almost anything can be very long. It blocks you for a lifetime from exponentially growing. But if someone teaches you how to talk, the time is kept short and you have more than enough time for growth after that.

Conclusion

In other words: we need to communicate best to improve as a team and we need to communicate best as fast as we can. Therefore we need to focus on how to collaborate the best we can. And we can do that best together in one location.