Releasing with balls of steel

11.30
Product Owner: Henri, can you check your email? I forwarded you an email where people are discussing about the address issue.
Me: Sure.

I read the emails and see that the one known address related issues is actually causing bigger problems than expected. Good news is that we have already fixed the problem, it just hasn't been released yet.

11.33
Me: So, sounds like we could still do the release today, after all.

1.5 hours ago in our daily standup I had just concluded the obvious thing. If it is was a normal day, we could do a production release today but today is not a normal day. Today is the single most important day for the whole corporation because of what happens in the evening. So no releases today. And besides, it's Friday, Fridays are never the best days to release anything.

But now the situation has changed. If we don't release, there will be certain customers whose purchases will cause lot of extra work to the customer support because the address data won't be saved correctly.

11.35
Me: Hey, let's go to the lunch now. When we come back, we start preparing the release. If it looks like it's not going to happen, then we won't do the release. But if everything goes fine, then this release would be pretty valuable. But I want to emphasise one thing: we have to be extra disciplined today.

12.15
Product Owner: While you were at lunch, I tested the address fix and it works. But it seems that we have another address related problem. The street address validation isn't very optimal.
Me: Well, that should be a very small thing to fix. I wonder if that thing actually explains the yesterday's complaints about how some people weren't able to purchase successfully?
Product Owner: Could be so.
Me: It seems to me that we should definitely take this fix to the release as well. It's quite bad if the customers want to buy but aren't able to do that.
Product Owner: I agree.
Me: Ok, let's split the work here. Can you Developer fix this second address issue?
Developer: Yes, I can do that.
Me: And I continue looking at this login change related thing.
Product Owner: I continue testing the other new features.

12.45
Me: I have found a possible solution for the login issue. It would fix the problem but then cause another problem, which maybe isn't not that big thing. Hmm... Or, actually it ruins the whole idea of what this login feature is all about because... Ok, I have to think a bit more.

13.15
Developer: I have the address fix done.
Me: Good, let's review it right away.

13.20
Me: This looks good. I wonder if you could next check what is wrong with this one end-to-end test. I first thought that it's a random failure in the APIs but this has failed quite many times recently. I'd say it's quite important to check so that we get the tests green before the release.
Developer: Yes, I can look at that.

13.45
Me: This new login feature is a bit more complicated than expected. I suggest that we don't include it to this release since the risks are too high and the possible benefit would be close to zero, I mean what comes to the evening.
Product Owner: Sounds good to me.

14.00
Developer: I found the reason for the test failure. It seems that this particular XHR call has quite short timeout.  If the API responds a bit slowly, as it seems to be doing quite often, the user sees the error message.
Me: Makes sense. Well spotted! And I have now reverted the login changes. We can continue finishing the feature on Monday. Let's review your change and then start making the release together.
Developer: Ok.

Our build process in CI is annoyingly slow. I add a ticket to our board that we have to do something for it in the near future. On the other hand, this is good time to think if there's something special that has to be taken into account in this release. Besides the special day, there isn't. It's actually quite the opposite. It's important to do the release exactly the same way as any other release.

14.15
Me: The latest version is now in the dev environment. You can test the address fix and we will see how the end-to-end tests will pass.
Product Owner: Ok.

14.25
Product Owner: Yes, the address works well now. On my behalf you can do the staging release.
Me: We also checked the tests and they are good too. I will start the staging release.

14.35
Me: The staging release is now done. I will run the load tests next.
Developer: I can check the staging end-to-end tests as they finish.
Product Owner: And I will once more check the new features in the staging environment.

14.45
Developer: The tests are ok.
Me: And so are the load tests, nothing special there.

14.55
Product Owner: Ok, I have moved all the cards to the "Ready for prod" column. Will you do the production release next?
Me: Yes. And I will inform the stakeholders.

15.00 (chat)
Me: Hi @DBDev, @EveningBusinessOwner and @EveningDev. We just did a staging release and the prod release is ongoing. This release fixes the address validation and address saving problems.
DBDev: Ok
EveningDev: Friday 15.00. You have balls of steel.
EveningDevelopmentManager1: Did you do it "jacket on and compile"?
APIDev: same thoughts...
Me: :)

15.05
Me: The production release is done now. I clicked through the main paths and everything ok so far.

15.05 (chat)
Me: Release done.
EveningServiceManager: We have today "pretty" important day!
Me: And now we are a bit more ready for that
EveningBusinessOwner: Tested?
Me: In many ways. Unit tests, code review, end-to-end tests (in dev and staging environments), Product Owner's tests (in dev and staging environments), load tests. We also went through the new features critically and left one risky feature out of this release.

15.09 (chat)
EveningBusinessOwner: Redirect isn't working
Me: What redirect? I just tested your login and it worked fine.
EveningServiceManager: How about registration and purchasing?

Feels a bit cold. We don't know what he meant about that redirect and we are just waiting for some additional information. I'm thinking what we have released and can't figure out anything that could have broken their part of the system. Calm down, I'm saying to myself. We have done this as well as we can and so many times before. If there is an issue, it must be something that has been there also before.

15.13 (chat)
EveningBusinessOwner: It works in buying. Not in registration but this is actually on our side, we have never implemented that.
Me: Ok
EveningDevelopmentManager2: I'm bit worried about this release at this point when there has been so much other things too during the week.
Me: I understand that but we did this release exactly to support you.
EveningDevelopmentManager2: I think I'm gonna have a relaxing beer. Let's hope that everything works. We expect plenty of orders today and tomorrow.

15.22 (chat)
APIDev: Registration has already started, it seems.

15.30 (chat)
APIDev: There seems to be quite many errors in regisration
Me: What kind of errors?
...

We figure out that the errors are caused because our registration flow is not technically optimal. We could avoid those errors by making an additional API call before posting the registration data. For the user this has no effect. In both implementations she would see exactly the same error message.

Little by little the situation calms down. The big night has started and we follow the production charts. We can see a nice spike in the usage data but a boring, flat response time graph.

A couple of hours later we wish everyone good night. Everything has gone really well, at least technically. At this stage we don't have any business numbers available.

Epilogue

When is a good time to release new features and fixes? If you face the question one-sided only, the answer is pretty simple: whenever the release makes the system better. On that Friday there were two identified issues with clear solutions and from that point of view we definitely wanted to release.

But everything is (at least) two-sided. The other side in releasing is about the risk. What if the intended changes we have made will cause some unintended changes?

In the traditional software development there are two ways to approach this dilemma. The other one is to admit that the risks are too high and not to release. The other one is to quickly hack solutions, deploy them, and then probably quickly hack the fix to the problem that was caused by the initial fix. What is common for both is fear.

However, software development of 2010s is not fear driven. It is based on agile and extremely disciplined process. It is based on code written with great quality, on automated tests with good coverage and quality, on automated build and release processes, and on highly professional people working as a real team.

"Software development of 2010s is not fear driven."

I am very proud of how our team was able to do the release on that Friday and I want to emphasise that - this may disappoint some of you - it wasn't about cowboys doing heroic actions. It was rather people following the process that has been tuned along the way and is still improved all the time. Also it was about certain amount of humility when admitting that the feature that does not work well enough is excluded from the release.

What is also important to understand is that this wasn't only about what we did on that day. 99% of this was what we had done before, in previous commits, in previous code reviews, in previous releases, and so on. In a situation like that you cannot fix your process. But if you have done your work well earlier, you can have great possibilities to react to the changed situation. Which I guess is what Agile is all about.

Failure lessons in Rome

This summer I was a week in Rome with my 13-year old godson. While seeing the eternal city, for some reason we talked a lot about failing. I wanted to share with you the things we talked about.

Experiments' delta

We flew to Rome from Helsinki. In the airplane my godson mentioned failure and I wanted to give him some different thoughts about it. It is something I remember seeing for the first time in a Håkan Forss' presentation about lean (and legos of course, if you know him). In his presentation he talked about making an experiment with an expected result. In case the the result was something else than expected, that wasn't called as failure but as learning. In mathematics the difference between the expected result and the real result is called delta. This delta is not failing, it's learning.

What I find important here is that when you do something, make an expectation based on the theory you have. If the thing you try doesn't work out as expected, be kind to yourself. Instead of judging yourself, celebrate that you just learned something.

Exhausted but still learning

We arrived at Rome in the middle of the day, so we had plenty of time to do something in the city also on the first day. We decided to take a walk in order to find a nice restaurant and some geocaches. We found some pizza, pasta, and also caches but our walk during that afternoon became quite long and it was really hot (almost 35°C).

Basilica di San Giovanni in Laterano, a church visit on the first day

When we came back to the hotel, we were really exhausted. In order to avoid that on the next day, we decided that we need to have water bottles always with us. This became our second lesson about failing and learning. It wasn't the best possible first day but we learned an important lesson that gave a chance to have better time on the following days.

Leonardo's scientific attitude

The next day was really nice for us. Amongst other things we were in Vatican and even saw the Pope himself! During the day we also accidentally at Leonardo da Vinci's museum. We decided to step in. The museum was filled with machines designed by the master himself. One of them caught my attention. It was da Vinci's experimentation related building a machine that can fly. He wanted to see if "beating wings would raise a heavy load".

What was really interesting was his notes about the wing:

"... but be sure that the force is rapid and if the above effect is not obtained, waste no more time on it."

Leonardo da Vinci's wing expirement

I think this was really amazing. While our current culture is so much worried about failing, 500 years ago there was a man who had really good approach on it. If da Vinci wasn't able to get the result he wanted, he was ok with that and was able to focus on other things.

Failure or needs that aren't met?

In the evening we wanted to find a good restaurant where we could sit outside and eat tasty Italian food. Unfortunately we both had rather lousy meals. The lamb was actually really bad. :(

While realising that we had chosen a wrong restaurant, I wanted to give yet another aspect on failures, one that I have learnt from nonviolent communication. The idea is that instead of failures there are just needs that aren't being met. So instead of thinking that we failed on choosing the restaurant or the chef failed on cooking delicious meal for us, we can focus on the needs we had. In this case we wanted to enjoy warm Roman evening outside having good food with decent price. What happened was something that didn't fulfill those needs.

You may wonder what is the big difference here. I have found out that when you look at the failures (and the reactions they cause) by looking at the needs behind them, the failures become more human. In other words this is about bringing empathy to failures.

Navigation failure

The next day it was time to rent a car. We drove to the amusement park called Rainbow Magicland. We had really good time there - expect my 20 seconds in the crazy roller coaster. Ok, it was fun, in a way...

Ranbow Magicland and its wild roller coaster

Our plan was that after the park visit we drive to Castel Gandolfo, to the Pope's summer residence. My godson used the navigator and I was driving. When we had driven about 30 minutes and seemed to be getting closer to the Rome center instead of Castel Gandolfo, I started wondering where we were actually heading at. When checking the situation, we found out that we were actually navigating to Via Castel Gandolfo (Castel Gandolfo Street, couple of km from Rome center) instead of the castle that was located ab 30 km from Rome to south.

Navigation failure you can say but I rather say so what. Instead of worrying that we weren't able to follow our plan, we started looking at new opportunities. Our primary goal for the next day was to swim in the Mediterranean. By looking at the map it made perfect sense to drive first to Castel Gandolfo, where we actually found a really lovely lake to swim, and after that to the west coast where we enjoyed the warm water of the Mediterranean.

Lago Albano - lake next to Castel Gandolfo, great place to swim

In this case it was of course relevant that our plan wasn't that critical. But if you think about it, how often the inability to follow a plan - even with more important cases - really matters? How often it actually brings us new opportunities instead?

Scale matters

On our second last morning in Rome we wanted to try the toast machine at the hotel breakfast. We put four slices of bread to the machine but when eating we realised that the bread wasn't warm enough. It was time to share the last lessons about failures with my godson. While this "failure" was really small-scale in the first place, there was a scale-related lesson hidden in it.

Toaster that didn't heat up breads

The thing is that when you try something new - like new toaster - try it first with small scale. In this case we could have used two slices of bread first and see how the machine behaves. When realising that one round in the machine is not enough, we could have put two more slices and heat them up with two rounds.

This is something that is used a lot in the product development, including software development. It's better to fail on the development phase because the failures are typically more small-scale failures and their cost is smaller compared to the production where failing is usually much more expensive.

Attitude of life

We had super great time in Rome but besides all the sightseeings, comic stores, and warm weather I hope that my godson also remembers something what we talked during the week. Failing is not something you have to fear because failing is full of learning opportunities. Basically it's all about how you see your life. When something negative happens, do you focus on worrying about it or do you take the opportunity to learn for the next time?

Nonviolent communication with development team

Nonviolent communication (NVC) has been a really important topic for me during the past three years. I have told many people how the book Nonviolent Communication - A Language of Life (Marshall B. Rosenberg) has changed my life. In the beginning of this year I read the book for the second time, which has even more increased the meaning of it to me.

About a month ago I was lucky to take part of Agile Finland's coaching camp (#accfi). It was a truly magnificent weekend with amazing people and interesting open space sessions. My main input during the weekend was to share NVC with the other participants. I was really happy to see how many got interested in it and said that they want to learn more about it when they go home. Also quite many of them said that NVC was the most important thing they got from the open space sessions.

Agile Finland Coaching Camp was held in amazing place called Herrankukkaro

When I got back to the work after the coaching camp, I wanted to continue sharing thoughts about nonviolent communication. I suggested my team that we could have a 2-3 hours session where we would talk about the topic. Again, I was happy to hear that everyone in the team were interested.

The session was really successful in my opinion and I wanted to write this blog post about it. This is for those who are interested in NVC and maybe even wonder if it is something to talk with your colleagues.

Briefly about NVC

Nonviolent communication (sometimes called compassionate communication) is based on the four basic elements. While we can apply it also on positive situations, NVC matters most when we face something negative. This can happen anywhere in our lives, at home, at work, in public places, or for example when reading internet forums.

The basic idea is that when something negative happens, we would not rush into judgments and conclusions too fast but instead proceed with the following steps. The first step is to make observations, to think and clarify what really happened. The second step is to focus on the feelings that are present or existed during the situation. After that comes the crucial third step. Instead of concluding that the feeling was caused by the thing that happened, Rosenberg suggests that all of our feelings are caused by the needs that are either met (positive) or not met (negative). So the third step is to try to understand what met or unmet needs caused the feelings. The fourth step is then to make a request that would help us to meet the needs and that way enrich our lives.

The basic elements of nonviolent communication

You can apply the four steps in two ways. Especially if you are having strong feelings yourself, you can focus on your own feelings, needs, and requests. The other option is to focus on the other people's feelings, needs, and requests. These two approaches differ greatly from what we too often tend to do, judge either other people or ourselves.

To me there is one thing in NVC that has helped the most. While I may have not always remembered the four steps, I have tried to remember one thing. The core of NVC, in my opinion, is empathy. When I have empathy present in my daily life, I can get so much more good things out of it and help others to have good things too.

Introducing NVC for the team

I started our session by going through the four basic elements of NVC. In order to have some more concreteness I asked if anyone of my team members (*) had recently faced any negative situations in their lives. One of them told us how in the morning she had felt bad when meeting a colleague in the cafeteria but not wanting to chat with her because of the hurry to do some important work. This was a nice example to start with.

First we talked about what had happened in that situation. In this case it was rather easy to make the observation. Two people meet each other in the morning, the other one doesn't want to have a chat, other than saying good morning.

The next thing was to name the feeling my team member had. This isn't always so easy thing to do. There are so many different names for different feelings but remembering them and finding the correct one can be truly challenging. I don't remember exactly what feelings we identified for this case but probably we talked about being distressed and in a hurry.

List of negative feelings by Center for Nonviolent Communication
(https://www.cnvc.org/Training/feelings-inventory)

As a third step we tried to name what needs of my colleague were not met and that way caused the aforementioned feelings. This again can be sometimes really difficult phase. Even though the needs affect to everything we do, we are not always very informed about them. What comes to the example case, we concluded that my colleague both had a need of connection and at the same time need of effectiveness in her work. The contradiction between these two caused the negative feelings.

The last step in NVC is to make a request that would help us to meet our needs. When taking account the need to do the work, the request could have been for example asking if they can have a chat the next time they meet because of the work that my team member wanted to do.

While this was a very simple example, it was a good start for the session. From here we proceeded towards more difficult cases. What was important to me was that we would use as much our work related cases as possible.

"Henri had a really good way of leading the session; softer start and then to more difficult real life cases."

Feelings created by customer feedback

A week earlier there had been a customer survey on our website. The customers had been asked how successful they had been in doing whatever they wanted to do on the site and then give a free comment related to it. This gave good material for our session.

First we went through some negative feedback and feelings that it caused. To my surprise none of the feedback created such feelings that I had expected, or due to such reasons that I had assumed. Intuitively I would expect that when someone harshly criticises the system you have built yourself, you feel for example annoyed or disappointed. At least that was how I typically used to feel before I read about NVC. I either used to judge the user (incompetent user) or myself (bad at building web sites).

However, in our team the feelings were maybe disappointed but for different reasons. Our team members felt sorry for the users because the users were not able to accomplish what they had wanted. The team members were disappointed also because they were aware of those issues but couldn't do much about them. In other words, they knew the problems users have, they knew possible solutions, but they didn't have management support to implement those solutions. This led our discussion into two things. First we talked what kind of requests we could make for the management to enable us solving the customer needs and feel accomplishment in our own work. The second thing was to change the point of view.

Like I wrote above, we can focus either on our own feelings and needs or other people's feelings and needs. In this case the other people were not only the users of the system but also the management. We talked what kind of needs the management had and what kind of reasoning had been behind certain prioritisation decisions. I think this was a really valuable aspect, to have empathy towards the management. What I observed during this discussion that first there was a bit higher stress level when our colleagues told about their disappointment towards the missing management support. Then when some empathy was added to the discussion, the stress level lowered. This is something that I have witnessed happening many times in myself when applying NVC.

"When you honestly try to understand other person's point of view and needs behind that, it takes you closer to the 'from human to human' attitude and problem solving. It's not actually anything special, it's just not that easy when you are in a hurry in your daily work."

Positive feedback and NVC

Like I mentioned above, you can apply NVC also in positive situations. The customer feedback was again a great case for that. While there were plenty of negative feedback, there was also a lot of positive feedback.

I did the same thing as with the negative feedback, I read aloud some of the users' comments and asked how our team felt about it. Obviously our team members were happy that they had been able to create such a system that makes (at least) some people satisfied. But more interesting was what different kind of positive feedback gave for us.

Some of the feedback was very short like "works really well" or just simply a smiley. While this surely felt nice, that kind of feedback didn't really help us to understand how we had been able to help the customer. Instead, when there was feedback like "the service was very easy and fast to use", it helped us to better see in what way we had succeeded. This led to the discussion how we ourselves can give feedback for other people. Do we in a way judge them by saying that they are good or they do good work? Or do we tell them how their work has helped us to meet our needs? Everyone agreed how the latter way is clearly more valuable for the feedback receiver.

List of positive feelings by Center of Nonviolent Communication
(https://www.cnvc.org/Training/feelings-inventory)

More challenging cases

We further continued to more challenging cases. One of our team members had had quite a lot of negative feelings related to co-operation (or lack of it) with another team in the same organisation. Her reactions and conclusions had been mainly how the actions of the others had created the negative feelings for her. So this clearly was a great opportunity to take a different point of view.

First we went through some of the situations there had been, without jumping into the conclusions and judgments. Then we tried to identify the feelings there were. Like in many other cases during the session, this wasn't as easy as it sounds. Many times during the session I asked someone about his or her feelings but the reply went very quickly to what the other person had done in the situation. I think that this is probably the most challenging part of NVC. Naming feelings is really difficult, identifying needs maybe even more. But especially difficult is to listen ourselves and our feelings and needs, instead of focusing on the other people's actions.

"I really started to think my behaviour and reactions related to certain persons / topics (even though unfortunately I note that it requires plenty of effort in my busy daily life)."

When we had talked enough about the feelings and needs that the team member had regarding to this case, and also practiced in making requests for the other party, we took the other party's point of view. To me it looked like that this helped my colleague even more, to focus on the other person's feelings and needs. I don't think I can overemphasise the value of empathy.

During the session I noticed how difficult it was to name the needs we have. Since I kind of anticipated this, I had printed the list of different needs before the session. We used that list and saw how in so many cases the needs we have in our work are related to the need of connection, the specific needs being like appreciation, cooperaton, and respect. I wonder what would happen in organisations if people would better understand how important needs these are for the employees, for human beings.

List of needs by Center of Nonviolent Communication
(https://www.cnvc.org/Training/needs-inventory)

NVC inside the team

As the last case we talked about a situation that happened inside our own team. I found this very interesting case since the actions of some people caused positive feelings (like excited) for some team members and negative feelings (like worried) for others. This demonstrates very well why we need to take responsibility of our own feelings. When our needs are met, we may feel excited. When our needs are not met, we may feel worried. It's the needs that cause feelings, not the actions of other people.

"To me it was really an eye-opener when you reminded how the same action can create different reactions for different people, depending on their motives and needs. I think this helps to understand the other person's point of view."

Again we talked about the feelings and needs related to this case. What I observed this time was how there was a rush to jump into the solutions without first clearly understanding the needs. This is yet another challenge with NVC in my experience.

I felt really proud that our team was able to talk about difficult cases like this. I also believe that this increased the trust inside of the team and made our team stronger than before. For this particular case it gave us tools how to behave differently next time if there is a similar situation.

"I believe that NVC adds trust in the work community and respect towards the other people's thinking and behaviour."

There are no wrong feelings

One major thing during the session was to see how sometimes people felt ashamed of their feelings. Like in the first case our colleague felt that she wouldn't have had the right to feel as she did. Same happened a couple of other times during the session as well. What I wanted to emphasise was that we have a right to have the feelings we have; there are no wrong kind of feelings. When we understand the needs that cause the feelings, it is much easier for us to accept ourselves.

After the session

I think we had a really good and valuable session about nonviolent communication. During the weeks after it we haven't talked much about NVC but I have seen a couple of cases where the session clearly had a positive effect. In one case one of the team members said to me what negative feelings he had had during the daily standup, and why, when I had judged his idea very quickly. I apologised my action but also happily thanked him for saying his feelings aloud since it helped me to see how I had acted in a non-constructive way.

Another team member has also told me how she has even more went through the case regarding the other team in the organisation. She has also talked about NVC with her family members in order to give them some ideas how to handle certain difficult situations.

"Interesting how NVC can be useful with people in all areas of my life: work (workmates and bosses), boyfriend, family members, friends, and all the people I meet in my life."

Summary

NVC has enriched my life a lot and that way created me a need to share it with people near me. Since I spend a lot of time for almost every day with my workmates, I find it very valuable that they have at least the basic idea of nonviolent communication. The session we had created a valuable basis for that and further improved our high-performing team into the next level. Even though this was just a beginning, I'm confident that there is a lot more waiting ahead of us.

"I hope that I find time & energy to learn more / read the book. Maybe during my summer holiday."

"NVC - this model is really worth of getting known. The session gave me good basics to use the model already now but also left an exciting feeling to learn more."

(*) I use the word team member a lot in this blog post. A team member can here mean a programmer, Product Owner, Project Manager or something else. I have chosen to use the more generic term since I kind of think that setting roles for the people can be violent and unnecessary categorises people. Since we are a software development team, I rather think that we are all developers with different special skills.

The best code review tool ever: discussion

Code review as team performance indicator

Sometimes people wonder what is a good way to measure software development team performance. While the obvious approach is to focus on the results, the outcome, I suggest that code reviews is another thing you should pay attention to. Personally I have seen that in the best teams code reviews work naturally, bringing a lot of benefits that enable creating valuable outcomes. In the less performing teams code reviews are skipped or they are somehow forced.

Code reviews can bring at least the following benefits. They increase the quality of the code. They act as a gate both for internal and external quality. They spread information inside of the team and that way support shared code ownership. They amplify learning. For the new team members they are one way to get along with the features of the product and the way of working in the team.

So if there are so many benefits for doing code reviews, why aren't all teams doing them? Here we come to the point why they measure the team performance. In the best teams, in my personal experience, people understand the benefits and they are willing to review others' code. They appreciate their own and others' learning. They want to have truly shared codebase instead of functional or component coding silos. They see how code reviews increase the quality of their work. If I summarise this into one sentence - they care. A team cannot perform very well if the team members don't care about these kinds of things.

The problem with pull requests

Since the very beginning my current team has done all the code reviews face-to-face; the author explains commit by commit what he has done and why. However, a couple of months ago we got new team members that are not located in Helsinki. This led us to the situation where we started using pull requests. When a remote team member finishes something, he creates a pull request and someone from the Helsinki site reviews it. We are using Stash where you can leave comments to any code row and have a conversation there if needed. Works nicely, kind of...

Little by little I got annoyed when I realised how much time it takes from me to do a code review. First of all, when there was just me reading the commits, it felt really inefficient. I had to make guesses what the author had meant and since I wanted a confirmation, I needed to write a comment. This led to another inefficiency, conversation around commits. Then there usually was another round of commits based on the feedback and sometimes similar problems also on this round. If my initial feedback was misunderstood, the new commits created even more waste to the process.

Of course in some cases I took the conversation off from the tool and we used a chat. But all in all, even though we had a nice tool, this wasn't working well. From the lead time perspective, because of all the delays in the process, it was really slow. From my personal perspective, it was frustrating and took time from other things.

However, we didn't change anything for a while. Maybe all of this wasn't so clear to me at that time. Maybe I was too busy to hop on the bike.

Then at some stage the remote team members suggested that the Helsinki programmers should start doing pull requests as well. That way they could learn from us and understand better what we are doing. And I think that there was also an equality aspect between the sites. My intuition was against this idea but I couldn't reason it at that time. I remember mentioning something about the pull request tool and one of the remote team members replying: "it's a great tool". And yes, it is a great tool, it is just solving the problem in the wrong way.

Because it would have not been fair to judge the suggestion beforehand, we tried it. One of the Helsinki team members created a pull request for the remote team. They reviewed it, gave some nice feedback and he did the modifications based on that. So in a way it worked pretty ok. Expect that also in this case there was a bit of the delay issue but still.

Get rid of pull requests, start talking to each other!

The most valuable feedback from this experiment was that it made me think. I felt that despite of the good intentions, we are going to the wrong way. It's not that Helsinki people should start doing pull requests but the remote people should stop doing them. Or at least we should change the way how we go through the pull requests.

When I started doing yet another code review and during the first two commits I already had a couple of questions, I just decided to stop there. We went to Google Hangouts and did the code review just like we had been doing with the co-located team members: the programmer goes through the commits one-by-one and explains what he has done and why. And most of all, we discuss!

It's probably not difficult to guess how it went. I got immediate answers to my questions. We got some short discussions about other commits too. I was able to give some feedback so that I was confident that he understood it. Code review was quickly done and we both felt it was exactly how we should do them also after this.

And this is how we have continued after that. There have been some small code reviews done without talking but most of them we have done by discussing. The benefits I just mentioned have realised pretty much every time and besides them there have been other ones too. Sometimes code reviews have generated discussion about future plans or ideas how to improve our code in general. In some cases the good discussion has saved us time because we have concluded for not doing something. And of course there is the rubber duck effect; quite often it's not the reviewer who realises something but the author himself. This is something that could not happen without people talking to each other.

Summary

Programmers tend to be people who enjoy using technical tools. From that point of view it's easy to understand why a well-built pull request tool may sound like a great way to do code reviews. However, by doing code reviews by discussing you get so many more benefits compared to code reviews where the reviewer just reads the code. No matter how good your tool is, it cannot replace people talking live. Whether it is face-to-face, by phone, with a video tool, or some other way.

I don't care what you did yesterday

I have worked in different Agile teams for several years. Some of them have been Scrum teams, some Agile teams in other ways. No matter what methodology the team has used, one practice has been pretty much always there, the daily standups.

During that time I have searched the best way to have daily standups. I'm well aware that there are no best practices, just good practices in different contexts, but still I feel that finally I have found (so far) the optimum way to have daily standups.

Let me show you the path I've walked. The starting point shouldn't be a big surprise for anyone.

The 3 questions

What did you do yesterday? What are you going to do today? Is there anything blocking you? These are the questions that probably most of the Scrum teams all over the world ask every working day from every team member. I find this a very effective way to focus on every day work compared to for example weekly meetings.

However, there is one problem here. Scrum should be team work. If the most often repeated ritual focuses on individuals so heavily, something has to be missing there.

Runners and baton

Some years ago I found a blog post (*) that described different approaches to the daily scrums. One of them was user story focused daily standup. The idea is that we shouldn't "focus on the runners but on the baton". Runners obviously refer to team members and baton to the tasks they do. In other words, if the team is supposed to develop user stories, let's see how the stories have progressed, how we plan to advance them today, and if there is something that prevents us from developing them.

The idea resonated a lot to me and I have tried it at least with three different teams, one of them being my current team. The problem is that it never felt natural for the team members in any of those teams. It was quite hard for people to follow what task we were talking about right now and what next. To make this work in practice, there had to be someone who facilitates the meeting. But if you need someone to do that for this simple 15 minutes standup, there must be again something wrong with the method.

What eventually happened in the teams was that we returned back to the basic individual-focused method. I just had to accept that because I didn't have anything better to offer. However, I still felt that there must be something better, I just didn't know what that was.

Making our goals explicit

A couple of months ago I was thinking that it would help our team if we wrote our goals to our board. There were two reasons for this. First of all, when you write something down, you are making implicit explicit. It wasn't always so obvious for us what the team's goals actually were, so this forced us and especially our Product Owner to think about them. Second, when everybody sees the goals all the time, they become stronger. It's much easier to try to reach the goals when they are just in front of your eyes all the time.

Goal-based daily standups

When the goals had been in the board for a couple of days, I finally got it. Even though we hadn't yet even tried, I was convinced that this was the missing thing to make really good daily standups. So I asked our team that could we run the standups so that we just forget the individuals and focus on goals. The basic idea was that we go the goals through one by one and whoever has anything to say to the goal we are talking about can say whatever she wants to say. After all goals had been walked through, people could bring up all the other relevant things that hadn't been mentioned yet.

At this point it may be relevant to notice that we are typically having 4-5 goals at the same time. In the most optimum situation there would be only one goal at a time, and our team would try to get there as fast as possible. However, our work is such that for example the first goal is to help some other teams to reach their own goals. In practice this means that whenever they have new needs that we can fulfil, we do that with the highest priority. Otherwise that goal just hangs out there and we can skip it in the standup. There can be also upcoming goals typically in the position #4 or #5 to tell us what will come next. Even though there may not be programming tasks going on related to these goals, there may be e.g. planning happening and someone in the team can share with others how it is progressing.


Our current goals. #1 is about helping the other teams. #2 and #4 are active in some level. #3 and #5 are new goals that were added today and will become more active when e.g. #2 gets done.

The new setup has worked really well for us. We use the most of the 15 minutes for the things that matter most for us. There is always something else but that stays on minority. I could say that typically it takes about 10 minutes to check the status of the goals and 2-5 minutes for the other things.

You could say that the things we talk about on goal-based standups are mostly the same that we would talk on individual-based standups. However, I find that there is a very important difference on the perspective. It really doesn't matter what you did yesterday or what you are going to do today. What truly matters is what we together have done for the goals and what we together are going to do them today.

Revealing problem with our focus

Some time ago the goal-based daily standups revealed a problem we had. I realised that even though we talked about only 5 minutes about the goals, our standups could easily take 20-25 minutes. This meant that most of our focus was in the work that wasn't actually our highest priority. (And besides that, we weren't very efficient when talking about it.) In other words, our goals were listed but the tasks we were working with were mostly related to something else. After realising this we had a good discussion with the team and we were able to solve the problem. Since then the situation has been much better.

In order to emphasise this we have a small sticker next to each goal (see the photo above). Each task then has the same sticker on the whiteboard. This helps us to see that the majority of the tasks either in progress or coming next are related to the goals.

Summary

Very typically agile teams benefit from having a short standup meeting every day. However, the traditional daily scrum format is very individual-focused and can easily forget the team and goal aspects. Instead of that, write your current goals down and put them visible for everyone (e.g. on whiteboard). Then on daily standups do not go through each team member but go through each goal.



(*) I was not able to find the original blog post anymore but the content of this one looks very similar to me, even though this one is dated to 2016: http://martinfowler.com/articles/itsNotJustStandingUp.html

#NoEstimates - not for Big companies

I was having a #NoEstimates presentation about two weeks ago in Agilia 2015, Brno. Really nice conference, lot of interesting discussions. A week ago I got feedback from my talk, collected by the organizers. It was mainly really positive, like this one: "great content, this is what I remember the most from this conference".

One feedback comment however was very interesting:

Very valuable presentation. One thing that I didn't like were the examples, that safely ignored challenges of big organizations and big projects. Henri seems to be working in an environment where #NE seems to be simple. Good luck in trying that in 1k+ employees company.

I'm writing this post since I definitely wanted to reply to the feedback. But before that, let's go back in time a bit.

Agile - not for Big companies

When I heard about Agile software development for the first time, there seemed to be some kind of consensus that Agile is not for big companies or for big projects. The more I read about Agile, the more this confused me. Why wouldn't big companies benefit from things like: faster feedback, ability to respond to the inevitable change, better collaboration between stakeholders, emphasis on working software, focus on the value, attention to continuous improvement, etc?

I never got good answer to this, so I never accepted the "fact" that Agile is not for big companies. And look at the big ones now: everybody wants to do Agile, everybody wants to be agile.

#NoEstimates - only for small?

So let's get back to #NoEstimates and to the feedback. First, if we look at the Woody Zuill's definition (see also this blog post), #NoEstimates is about exploring alternatives to estimates in software development. What this means is that people interested in this topic are thinking critically whether we need estimates in the cases where we use them now, and thinking how we could face the same situations more effectively. Again, I don't see how the big companies couldn't do the same?

Second, I am not doing this in small companies only. When I experimented with #NoEstimates ideas for the first time (then without the hashtag), it was in a small university project. But after that the next company was a very big one, currently having ab. 27 000 employees. My current client has ab. 7 600 employees. Not small ones, right? In between I've worked also for much smaller companies.

Of course not all of the employees in those companies work in the same project. But my work history also contains a company that had over thousand employees working for the same product. There I saw teams that were applying many ideas from #NoEstimates thinking. I saw teams that were using story points without any real need for that. I saw teams that stopped needless estimation. I also saw a huge project that surely had had many kinds of estimates along the way but quite questionable benefits from them.

Seems to be simple

As the last point I would like to thank the feedback giver for the great compliment. He or she said: "Henri seems to be working in an environment where #NE seems to be simple". I say it's a great compliment because when something complex seems to be simple, you have succeeded in something. Either by making difficult things simple or by being able to present them clearly.

The truth is that things haven't been simple, my very first blog post tells one story about it. It took about 1.5 years for the team to get to the point where estimates became irrelevant. And that journey was far from simple and easy.

Along the way I have spent lot of time for thinking about the concepts I have presented in conferences like Agilia 2015. For me many of the things really feel simple, and of course there are still many things that I struggle with. Anyway, it's good to remember that simple does not mean easy. The current project I work in is a good example of that. I may write more about it some day.

#NoEstimates - Alternative to Estimate-Driven Software Development

Free software development magazine Methods & Tools has published my #NoEstimates article in its Spring 2015 Magazine.

The title of the article is: #NoEstimates - Alternative to Estimate-Driven Software Development.

Comments

If you would like to comment the article, you can do it here in this blog post.

Other posts

If you liked the article, you may want to read my #NoEstimates blog posts.

95 excuses

1. A software developer wasn't happy about the work he was doing. To be precise he wasn't happy about the system he was working in. He knew the concept of a system since he had read books from great minds like William Edwards Deming. Especially the developer remembered how it's 95% about the system and 5% about himself. For that reason he felt that he is forced to continue working in this dummy system where his company as a vendor makes stupid promises for customers in order to get deals. So reluctantly he continued doing his work as before.

2. At the same time the sales person of the same company was feeling miserable. She was going to contract negotiations with a new customer. And she was miserable because she felt that the both companies were doing it really wrong, in a way that doesn't benefit either of them. But the sales person had also read Deming and thus remembered how there's probably not much to do since it's 95% about the system.

3. The person responsible for ICT sourcing from the customer's company was also thinking about the upcoming contract negotiations. He didn't like the idea that he should aim for the lowest possible price instead of focusing on more important things in the vendor selection. But of course he wanted to think about the possible bonus he might get if the deal was well-negotiated. And besides, why to bother trying anything else since it's 95% of the system anyway. That's what Deming was saying in his famous quote.

4. The CIO of the company was worried how the big software project that was about to start would go. He didn't have very good experiences about the previous ones and felt that the company needed a radical change in how software projects were to be managed. But at the same time he kind of knew that he couldn't make much a difference because the company culture was supporting the old way. He was thinking what Deming had said and felt being just a small man in this big system. So while walking to the next meeting he thought that maybe it's just better to continue doing job as before.

5. The company's CTO was sitting in her room and felt disappointed. She wanted to change the company into better but it was so difficult. And when she remembered what Deming had said about 95/5, the change felt even more difficult. She saw so many problems in the system her company was part of, starting from the university education. According to her experience the education system wasn't producing such graduates that the real business world needs.

6. At the same time a professor in the university was angry. She was angry because she had to spend too much time on bureaucracy instead of sharing her precious knowledge for the students. While watching the Deming's quote that she had printed to the wall of her room, she knew that it's just better to keep filling the papers because she couldn't change the system anyway.

7. ...

...

95. ... and because of the 95/5 rule the junior football team coach felt that there's not much he can do.


"No, no, no! This is not what I meant!" Deming couldn't believe his eyes while he was watching this miserable play. "How did this happen?" he was wondering. "Please, let me go back there. There's still so much work for me to do!"

No software development standards

Yesterday I had a day-long discussion about standards on Twitter. It all started with Riina's worrying tweet, following with some jokes:

Obviously behind all that was skepticism towards standardizing certain things. But then we moved from joking to more serious discussion when Ari Tanninen commented that "ISO standard for user-centered design isn't half-bad". He gave a link to a presentation that provides more info about BS EN ISO 9241-210:2010. I was still skeptical. I felt that you shouldn't try to standardize software development.

Good software standards

The discussion moved on. When I criticized standardizing software development, I was mentioned about things like SQL and HTTP - and this:

But my point wasn't that. I see a lot of value in software standards. As a web developer I get big benefits myself when browser vendors follow the HTML and CSS standards. Globally speaking, those benefits are gigantic. So yes, IE6(-8) is a sad story and shows what happens when standards are not followed.

However, I'm not against software standards, I'm questioning the need for software development standards.

Let's make Scrum as an ISO standard?

So what if Scrum would become an ISO standard? Companies doing software development would be forced to use it in case they wanted to get certain contracts. Or companies following the standard would have an advantage in competition because they could say how their software development departments are following the standards, which "prove" that they are doing great work.

Well, I like Scrum and I think that it has brought a lot of good to the software development industry. On the other hand, it's about 18 months since I was last time using it. And this doesn't mean that I'd been in a vacation or unemployed the last 18 months. It means that I've been in contexts where doing software in some other way makes more sense.

You probably already picked one keyword from the text, context. Software development is always very context-dependent, which is one important reason why standardizing it is not so good idea. The same argument works also with the proposed testing standard, ISO 29119. Software testing, as part of software development, is also very context-dependent and creating one standard for it is very questionable.

Unfortunately I'm not able to see the testing standard text but for example the contents of the Test Documentation part just scares me. I have worked with big companies and can imagine some horrible scenarios if they would jump into using such a standard.

Why is software development different?

So why some standards, even software standards, bring major benefits (cost savings, increased market share, even environmental benefits) but I'm against them in software development? I already mentioned context as one important reason. But there is more.

Basically I would say that if the aforementioned benefits can be reached by reducing variation, then a standard makes sense. I mean that's what standards are all about, doing a certain thing in a certain way instead of one hundred different ways.

However, in software development the goal is not to reduce variation, like it is for example in manufacturing. Instead, due to the asymmetric economic payoff-funtion, variability gives us a possibility to exploit opportunities. If on the other hand the development is standardized, we miss those opportunities. (Read Donald Reinertsen's book to understand more.)

So please, be very careful when you try to standardize software development. It can be that you haven't understood the very core nature of it.


PS1. A lot has been written about the proposed testing standard ISO 29119. If you are interested to learn more, read for example Stop 29119 by Iain McCowatt, any of these, or this post written in Finnish by Maaret Pyhäjärvi.

PS2. Standards are not my specialty. If you think I've understood something wrong about them, I'm more than happy to receive your feedback.

Cost of delay and artificial deadlines

This is my second cost of delay post, you may want to read Unquantified cost of delay in prioritization first.

How to recognize an artificial deadline using cost of delay?

Business world is full of deadlines. Sometimes they cause unnecessary stress for the employees and for the organization, sometimes they contain a really important message how something cannot be late. So how to know when a deadline is reasonable and when it is artificial?

My claim is simply the following:

If the form of the cost of delay curve does not change near the deadline, the deadline is artificial.

Examples

Let's take a couple of examples.

In this case the deadline is reasonable. If the company misses it, I will lose a big amount of money.

In this case the deadline is questionable. Yes, in the future the company may lose a big amount of money but why is the deadline so early? If the deadline is met, the ready product/feature/etc is waiting in an inventory for a long time. Another possible problem is that the solution is implemented without using the latest available information. This means that in the worst case the solution can be outdated when the real deadline hits.

In this case the deadline is artificial. You can ask why that particular date was selected? Why not week later or week earlier? It is hard to see the reasoning for this deadline. If there are no bigger cost of delay items waiting to be done, this should be just done as soon as possible. If there are, this task is a wrong one to do.

Also in this case the deadline is artificial. Yes, the company is losing money all the time but why not just focus on fixing the problem as soon as possible?

What to do with an artificial deadline?

If I hear a deadline that seems to be artificial, I always ask how the date was decided? It may well be that I'm missing some important information that I didn't know earlier. In that case the deadline isn't artificial and I just learned something relevant. On the other hand if it appears that the date was "just selected", it gives me an opportunity to have a discussion about the concept of cost of delay.

If you can figure out a situation where the cost of delay curve does not change format but deadline still makes sense, I would be interested to hear.

Unquantified cost of delay in prioritization

Cost of delay (CoD) is an old financial tool for evaluating the cost that is assumed to happen when something is delayed. Its importance in (software) development work probably increased remarkably after Donald G. Reinertsen published The Principles of Product Development Flow (at least from my point of view). In his book Reinertsen explains very thoroughly why CoD is a really important metrics and why it can be a valuable tool to be used in prioritization. His principle E3 says:

The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay (p. 31).

What comes to the prioritization, Reinertsen offers for example this simple advice related to CoD:

I'll just give you two simple heuristics: high cost of delay before low cost of delay, and short jobs before long jobs (p. 70).

So basically it's quite a simple thing. Just calculate the CoD like Reinertsen does and decide. But is it really that simple in practice?

Cost of delay without numbers?

As a development team member I'm making many prioritization decisions every week. Obviously I try to make good decisions together with other team members and stakeholders. In theory CoD is almost all I need but in practice there's a big challenge how to quantify it. Either the numbers aren't available or it is not cost effective to get them. I suppose that Antti is facing the same problem and for that reason doesn't know how to utilize CoD in his work.

Fortunately it is still possible to use CoD in prioritization even though we wouldn't have numbers available. The key is to understand the different types of CoDs.

Example

This is quite a recent example and related to the original tweet. We had to decide whether to implement feature A or feature B first.

The company was about to start a print marketing campaign. The question was: should they include the feature A to the marketing material or not? Obviously if they mention about it, the feature has to be ready when the campaign is out. If they do not mention it, there's no hurry with building the feature but then they miss an opportunity to sell the feature for the potential customers during the campaign.

The feature B on the other hand was more of a "regular" feature. There was no marketing campaign related to it, nor any seasonal specialties.

Without having any numbers available, I was immediately thinking how the CoD curves would look like in each case:

 

Cost of Delay - Feature A

 

Cost of Delay - Feature B

The feature A has a cost of delay that is clearly related to the marketing campaign. The cost here is the lost additional sales that the campaign would probably bring to the company. The feature B has no such attribute. The lost sales (or satisfaction of the current customers or some other value) increases steadily among the time. Based on this we decided to prioritize so that we build feature A before B so that the company would not lose the opportunity window that would be open during the campaign.

Is shape enough, don't absolute numbers matter?

There is a reasonable question flying in the air. Are you sure that the curve for the feature A is above the other curve? In other words, how can you be sure that when combined, the curves don't look like this?

 

Possible cost of delays

My answer is that we cannot know for sure. But we have some hints that we can look at. The implementation of both features has been delayed already for quite a long time. If the CoD curve of the feature B would be very steep, the feature would have been probably implemented a long time ago. We can reasonably assume that since both features have been approximately at the same height in the backlog, their business value is pretty much the same. Now it just happens to be so that feature A fits very well for the marketing campaign that is about to be started. And the campaign starts no matter whether this particular feature is ready or not.

Classes of services

Another person who has popularized CoD in software development is David J. Anderson with his Kanban: Successful Evolutionary Change for Your Technology Business book. (Btw, check who has written the foreword for the book.) Anderson talks about classes of services - expedite, fixed date, standard, and intangible - and relates them to the different kind of CoD curves.

I'm not going to talk about more of them in this post, you could read e.g. Andy Carmichael's excellent blog post Selecting Backlog Items By Cost of Delay. Another post worth to mention is Mike Burrows' Kanban prioritisation and scheduling with classes of service. Nevertheless, I think that understanding those classes helps you in using CoD in your daily work, even without quantifying the cost.

Summary

I would like to emphasize that I'm not trying to understate the importance of quantifying CoD. And I really like how Reinertsen highlights that our decisions should be based on quantifiable economics instead of e.g. gut feelings. However, in real life the available data is very often insufficient and getting better data isn't necessarily cost effective. Still you need to make decisions and you try to do them as well as possible. In those cases it helps if you understand the principles of CoD, even when you decide not to quantify it.

Another point of view is that in agile software development we try to make many small decisions over the time instead of few big ones in the beginning. Then it doesn't matter so much if the decisions made are wrong because we can usually fix them rather quickly. In that kind of world using too much time on getting exact information isn't necessarily justified.

Obviously the bigger the impact of the decision is going to be, the more you should invest in making better analysis of the situation and actually quantify the CoD. And you can always think how you could improve your system so that relevant data could be available for the smaller decisions as well.

Experiences from programming with kids

I was kind of scared beforehand but afterwards I felt just great. Couple of hours ago I was teaching 1st to 6th graders programming and it was so much fun! Let me share with you my experiences so that you can do the same thing somewhere else.

Background

Keinutien ala-aste (elementary school, grades 1-6) in Helsinki decided to organize a special school day on Saturday 27th September, 2014. The theme of the day was the popup school. The idea is that anyone (kids, parents) can teach anything and the kids can decide what sessions to participate in. So I volunteered and decided to teach kids how to program. I wouldn't have done that unless there had been so much fuzz about code schools in Finland during the past year. Without that there probably wouldn't have been ready-made material available either so thanks to Juha Paananen et al. for making the koodikoulu.fi and Turtle Roy available for anyone!

Preparing

Because I wasn't sure what to expect when working with children I wanted to test it. First I tried my ideas with my 6 year old son who goes to the first grade next year. Since that went so well, taking into account his age, I was encouraged. Especially I got convinced how to start each session (I'll tell you more about that later). Next I tried the same things with my 8 year old son and his friend. I felt that I was pretty much ready for the show.

Couple of days before the school day I asked the organisers to check that our coding environment, Turtle Roy works as expected. The local IT teacher found out that it works with Chrome but not with IE. He tested moving and turning but unfortunately not sequences...

Right before the sessions

I was told that there are going to be 4 sessions with 20, 10, 7, and 16 students. Usually in code schools here in Finland each kid has a parent along and they work together in the same computer. In this case there were going to be even twenty kids and only one adult besides me! So I was a bit frightened if it's going to be just one big mess. One thing that I noticed when practicing the code school was that 8 years old kids need lot of support with the keyboard. So how on earth is it going to work if there are 20 children needing the support?! Well, luckily most of the kids were older than 8.

When I went to the computer room, I checked that everything works nicely. Oh shit, I wasn't able to type square brackets meaning that I couldn't write this important piece of code: s [fd 50, lt 90]. The brackets worked elsewhere but not in the command line of Turtle Roy. So we had to figure out a quick workaround, which was to write bracket somewhere else and copy it from there to the command line. (The square bracket issue has been fixed.)

Content of one session

Let me next describe the basic structure of each session. I decided to follow the steps described in the Turtle Roy Github page. Besides that I added one important step to the beginning, right after the introduction.

Introduction

First I introduced myself and told that I'm like a professional football player: some people pay me money for doing something that I feel is my hobby; I'm a programmer. Next I asked who has used some computer program this week. After only some of the kids raised their hands I asked another question: who has used a mobile phone or played any computer games this week? Now when everybody had raised their hands I explained them that the games are programs as well and someone has programmed them. I explained them that programming means that someone tells the computer how to behave and today the kids are going to do exactly that.

I had asked them to form pairs. One reason for this was that it halved the amount of helping we had to give for the kids. Another reason, which I told them, was that programming quite often is pair or team work. So these kids started their career by pair programming. :)

Practicing without (real) computers

Inspired by the experiences from ICT-portti I decided to start without computers first. I told the kids that I'm a computer now and they need to program me using the commands: "move forwards", "turn left", "turn right". Their task was to transfer me from my current location to the other side of the room. I emphasised that I won't understand any other commands. So for example if someone said "jump", "move" or "go left", I replied: "I don't understand the command".

The students got the idea quite nicely and every group managed to get me to the goal. Also in each group I got wrong commands. This helped me when getting to the next stage. Let's start programming with the real computers but remember kids, you have to be very specific when giving commands for the computer!

Moving and turning

We started the Turtle Roy programming with the simplest command that I had written to the whiteboard: fd 50 (move forward). This was trivial for most of the kids but even here some of the youngest needed a bit of help. The next commands were naturally about turning: lt 90, and rt 90.

When everybody got their turtles moving and turning, I encouraged them to try what happens if they write e.g. fd 100 instead of fd 50. This was actually one of my key thoughts: the kids should try and see what happens because that is actually quite an essential part of programming many times. In other words, there are no mistakes or wrong solutions. The only mistake you can make is not to try.

Since by trying (obviously they try what happens with the command fd 1000000) they got quite a mess for their boards, I told them about the fourth command: clear.

I also explained what the number 90 means in the turning commands by drawing it to the whiteboard. Basically, if you want to turn a bit less, try e.g. lt 30. If you want to turn a bit more, try e.g. lt 120.

For the older students who already are learning English I told how the commands come from English. fd means forward, lt is left turn and rt is right turn.

The square challenge

Then I gave the kids a challenge: they should try to draw a square. I helped them by asking how they should command me if I was a computer again. The kids started typing: fd 100, lt 90,...

This was the place when the first ones got really excited when they realised how they can draw something more meaningful.

When the squares were ready, I asked the kids that wouldn't it be nice if they could make a square with only one command? In order to get there I asked if they saw any repeating pattern in the square commands I had written to the whiteboard: fd 50, rt 90, fd 50, rt 90, fd 50, rt 90, fd 50, rt 90. This was a nice step to the next phase.

Sequences

The sequence was the most difficult thing during our session because of the bracket issue. So we had to help the kids a lot so that they were able to write the sequence command: s [fd 50, rt 90]. I felt that some of them had to give extra focus so that they don't get frustrated. But on the other hand when we got the command ready together, they got excited again.

Here I also advised them how to use the arrow keys so that they don't need to rewrite the same command again. So very quickly after the initial troubles the kids were able to draw a square by repeating the sequence command four times.

Repeating

The natural follow-up question for the kids was that wouldn't they like to do the whole square with a single command instead of four commands? After all, computers are really good at repeating things that human beings find boring. So it was time to introduce the repeat command: r 4 (s [fd 50, rt 90]).

I remember how some kids responded with bigger eyes and smile when they run that command. Now they managed to do the whole square with just one command! And more was coming...

Let's play!

My last advices were that now it's time to play. Change the numbers in the latest command using the arrow keys. Don't repeat just 4 times, repeat for example 40 times. Don't turn 90 degrees, turn e.g. 50 degrees. And for some I also said that they can add more commands to the sequence. Anyway, the most important message I wanted to give them was that try things out, play with the turtle, and have fun! It's actually quite amazing what kinds of beautiful flowers, stars, or gearwheels you can get with that simple command when modified.

I also promised that the pair that draws the best picture gets a reward (lollypops). My tip for that was: those who are willing to try out different things are going to be the best ones.

This was again one of those moments that were full of wows and smiles. It was really rewarding for myself to get all the way here and see how the kids had learned so fast.

What not

I was prepared to teach them how to play sounds (e.g. play [c, d, e]), how to make the turtle speak (say "hello world"), or writing (print "hello world") in case there was any time left. But as I had guessed, the 40 minutes went so quickly that we didn't do these in any of the sessions. So neither had we time to see any "real world" code. Maybe that was just a good thing because I had some Java code open in my laptop at that time...

If there would have been another session with the same kids, we would have probably tried to write some functions as well. It would have been really interesting to see if they get it or not.

Afterwards

Like I said in the beginning, I had really good feeling about the sessions afterwards. I had some fears that mostly did not come true. Instead I saw many moments where kids learned fast, where they "just got it", and where they smiled when they succeeded.

The only thing that I was a bit disappointed was that none of the pairs helped the other pairs. I had hoped that I would see more advanced students giving help for the less advanced without asking it. But that didn't happen. I wonder if it has something to do with our school system or was it just how our setup was in the sessions.

One of the best things was when my assistant teacher, the local IT teacher, said that he is going to start using Turtle Roy in his own IT classes with 4th graders. He was convinced that this is a good method and it will be valuable for them. This teacher is btw going to be ahead of his time since programming will be part of the official curriculum in Finnish schools 2016.

Lastly I want to say my special thanks for all the kids who attended my code school. I had really good time there, thanks to you!