Houston Way Dojo #1

Why Dojo?

I had the privilege of facilitating the very first Dojo session for Houstonians. I have participated and facilitated Dojos before, so I had some thoughts what to expect. Some Dojos have gone kind of wild and some of them have been smooth and fluent. We have had long debates about TDD among other. However, a common nominator for all the Dojos has been that every participant has learned a lot. I would not change any second of them and I want more of those seconds.

“It’s for testers, scrum masters, product owners or whomever has anything to do with software in their jobs or business.”

I will not go through what a Dojo is and where it came from. If you are interested please refer e.g. to Wikipedia. Instead, I will try to answer the question, which almost everyone asks: why? The simplest and shortest answer: participate one and you will know why. Ok, I will give you some of my thoughts.

“How to solve a problem together with other people.”

I see Dojos as training sessions for people in software business. It’s not just for developers. It’s for testers, scrum masters, product owners or whomever has anything to do with software in their jobs or business. All can learn from them. That is the beauty of Dojo. It is not just focused on solving a programming problem. Solving programming problems is just a way to practice other areas of daily work: team work, collaboration, contribution, design, planning, testing, architecture, business etc. Whatever you choose as your Dojo’s subject you will always practice one essential thing: how to solve a problem together with other people. If that is not the most essential aspect in software development today what is?

The Houston Coding Dojo #1

So I knew there would be people who have never coded together and who have not participated a Dojo before. We started by having a short introduction session and I described the practices. Ten minutes of design, five minutes of pair programming per pair. After that the other one of the pair changes. The pair narrates their thoughts while coding. The audience may ask questions but they may not interrupt the flow. Time to start: “Strict TDD”, I said and presented the problem.

“The first leg resulted in couple of vague lines of code, but to be honest, nothing really sensible.”

I chose CheckOut kata – one of Code Katas by Dave Thomas as the basis. We started from scratch with a 10 minute design session. Well, I chose 10 minutes of design to give the participants freedom to discuss before getting into business. Discussion happened, but as I expected, it really did not lead the problem solving anywhere. Ten minutes went fast and it was time for the first brave pair to start coding. The first leg resulted in couple of vague lines of code, but to be honest, nothing really sensible. That was our first lesson. We learned from it and in next leg we just wrote the very first test for the very first sellable item and were able to proceed.

We continued rotating the pairs. The coding went back and forth. We had discusses and questions between switches: Was refactoring the right thing to do at that point? What do you like about the name of this method? How to name this class? Some practical hints as well as an example like: add throwing a runtime exception to you code templates when creating new methods. In between we had a 15 minute break and continued still for an hour or so. At the end we held a retrospective.

End results

Not much of code. Whole problem was not solved. That is pretty typical for first time dojoers. It takes time learn how to cooperate. We also spent a lot of time discussing around the questions presented. I remember a brave participant saying something like this: “At home we could solve this problem very quickly”. Exactly – it’s not about the skills of individuals, it’s about the skills of people working together.

“Exactly – it’s not about the skills of individuals, it’s about the skills of people working together.”

To me the first design session was one of the key takeaways from this Dojo. We did not really benefit from it at all. I personally felt it was more harmful than useful. Discussion in the upfront design tryout was first too abstract then too detailed! When Dojoers wrote the very first test, they were able to continue and get something more concrete. They started to really see how the problem could be solved. Producing value at the same time. When doing the design the Dojoers did not understand the problem they were making the design for.

“When doing the design the Dojoers did not understand the problem they were making the design for.”

What did we find out in the retro? People learned a lot and – most importantly – they had fun coding together!

I just wonder how many solved the problem back at home?

Just a peek of our results:

        @Test
        public void shouldCalculateFruitPriceForOrangeAndBananaAndApple() {
                ShoppingCart cart = new ShoppingCart();
                cart.addFruit(Fruit.ORANGE);
                cart.addFruit(Fruit.BANANA);
                cart.addFruit(Fruit.APPLE);
                assertEquals(3.5, cart.getTotal());
        }

The next dojo group will solve the same problem – eagerly waiting for the comparison,

Pasi Honkanen

Thanks to: Jouni Kröger, Ari Metso, Kari Helenius, Lauri Illukka, Heikki Leskinen, Ohto Rainio, Tomi Tuominen, Vesa Teikari, Sebastian Vuorinen

Houston Inc. 02/24/2011 #houstonway

One thought on “Houston Way Dojo #1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s