Creating our own puzzles

In Agile tech circles, we often talk about "slowing down to speed up". For years, I've had a good gut instinct that this is true, but I’ve never untangled that paradox properly. Because slowing down makes you go slower, by definition. What is it about slowing down that paradoxically allows us to go faster?

Yesterday, me and my team did an Escape Room together. We did it all together, and solved the problems collaboratively. It struck me that it would be a good learning opportunity to reflect on whether it was faster to work collectively, or if we'd have been faster if we worked individually, but in parallel.

But something about the analogy with software development didn't feel right. And then it hit me. There's a missing feedback loop with Escape Rooms. The way we solve the puzzles now has absolutely no effect on the difficulty of the next puzzles, or the puzzles that we'll face next time we do an Escape Room.

But in software development, the solutions we write today ARE tomorrow’s puzzles. There’s a feedback loop there. If I solve a puzzle today in a complicated, convoluted way, then tomorrow's puzzle will be complicated and convoluted. If I solve a puzzle today with only partial understanding, then the instructions for tomorrow's puzzle will be incoherent. 

The faster we go today, the higher the difficulty level will be tomorrow. 

But if, instead, we go slowly and carefully today, then tomorrow’s puzzles will be easy. And easy puzzles don't take long to solve. So we will move faster.

If we take time today to collaborate, to share our understanding, to write clean, easy-to-understand code, with clear abstractions and boundaries, then we will face nice simple problems tomorrow.

And this is why the XP practices are so powerful. Pairing, mobbing, TDD, continuous refactoring etc might look like they slow you down. They probably DO. 

But they creates better software, with simpler puzzles for tomorrow. And that allows us to go faster.

Slowing down allows us to go faster. 

Comments

Post a Comment

Popular posts from this blog

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B
Read more

Mobodoro

On our mob, we have started using the “ Mobodoro ” technique, which I picked up from Willem Larsen at Hunter.  The idea is based on the “ Pomodoro ” technique, where you do 25 minutes of solid work, then take a five minute break. And repeat.  But with Mobodoro, we have a couple of minutes to plan, then we do repeat mob rotations of 2 or three minutes, adding up to 25 minutes. Then we do a quick retrospective on the previous 25 minutes, have a quick break, and then repeat.  And for the break, we have a rule that we have to leave the mobbing area. Even if we just walk a few feet and back.  The retrospectives have been great. Often we have nothing. Because we’re only retrospecting on the previous half hour. But quite often we find something small we can change: a better way of using our whiteboard; a new chair; changing the mob rotation time; buying some Lego to keep track of our work.  The day seems to go much more smoothly, and at a much more sustainable pace. Two or three minutes brea
Read more

Gilded Rose Katas

Image
Introduction Last Summer, I had the pleasure of bringing Amitai Schleier into my company for a few days, as part of his coding tour . One thing that really inspired me was his emphasis on a Learning Hour each day, and on using katas.  Katas are a short set-piece practices. The word “kata” comes from the Japanese martial arts tradition (形 - literally, "form") and is used to describe a regular repetitive, choreographed practice. Wikipedia gives a good description here  https://en.m.wikipedia.org/wiki/Kata . In software, there is a good collection of these set-pieces. Implementing FizzBuzz in a new language is a good example.  So, after Amitai’s visit, I started running katas every day. It took us a while to establish them, because we don’t have set starting or finishing times. But we now do half an hour of katas every day after lunch. We have used the time to look at TDD, TCR , Haskell, and we have used several well-known katas.  But the one we spent the lo
Read more