Careless Mocking Considered Harmful

πŸ’‘ Mock hell : when excessive use of test mocks makes refactoring extremely slow or difficult.

A few years ago, I managed to get a side project out of mock hell. Since then, I’ve been using what I learned to avoid mocks in all the projects I’ve worked on. This is the start of a series of posts about my mock-avoiding techniques.

A tag "Mocks don't rock !"

Escape from Mock Hell

Between 2010 and 2014, I was working on a side project I called Which actually means “my house shopping” in English. I wanted people to be able to do their house shopping in 5 minutes, by using a better UI for online groceries. I was using Ruby, and I had just read Growing Object Oriented Software Guided by Tests. I got a bit too excited with mocking, and was using it way too much.

I’d been practicing Test Driven Development for more than 5 years and I was expecting great results with a language like Ruby. After a few months though, I could feel that something was not going as well as it should. The test initialization code was getting longer and longer, as it included a lot of mock setup. This made the tests more complex and less readable. It also made them unreliable, as it was not rare for all my unit tests to pass while the system was not working. I was taking the habit of running my end to end test more and more often. I was also losing a lot of time maintaining the mock setup code in line with the real classes. Mocks also tricked me into the bad practice of keeping a 1 to 1 mapping between code and test files. That again increased my maintenance burden when moving code from one file to another.

It reached a point where I could not take it anymore. All these problems were pointing at mocks, so I tried to remove them from a test file. Here are the techniques I ended up using to remove them mocks :Β 

The end result was beyond my hopes, as my problems almost magically disappeared. The code got simpler, I became a lot more confident about my unit tests, and they got easier to maintain. As an illustration, here is an excerpts from the diff of a rails controller test file which went through this mock diet.

A screen capture of a Github diff showing a test file going on a mock diet

What’s the long term risk ?

Basically, excessive mocking arms the maintainability of the tests. Here is what would have happened if I’d done nothing. Tests would have become so painful to maintain that I would have started to ignore or delete them. As coverage would decrease, more and more code would become untested. That’s exactly Michael Feathers’ definition of Legacy Code :

Legacy Code is code without tests. Michael Feathers

To summarize, excessive use of mocks leads to legacy code ! As most of us have learned the hard way, the further a system drifts into legacy, the lower the productivity.

πŸ’‘ Excessive use of mocks leads to legacy code

Next posts

Others already spoke about the dangers of mocks :

In this series of posts, I’ll go through the details of the different techniques I used to remove mocks. Here is my plan :

  1. Careless Mocking considered Harmful
  2. How Immutable Value Objects fight mocks
  3. Immutable Value Objects vs Mocks : Fizz Buzz
  4. Other small scale techniques to avoid mocks : Data Builders and Test Matchers
  5. Large scale techniques to avoid mocks
  6. Mocking in special contexts like legacy and dynamically or statically typed languages

Stay tuned !

Frequently Asked Questions About the 20 Hours of Code Katas

In my previous posts, I explained how to use the 20 hours of Code Katas technique to learn new languages. If you did not read these yet, start by the beginning.

A drawing of FAQ in a lightbulb

To close this series, here are a few tips and suggestions presented as questions and answers.

What if you don’t know TDD yet ?

The few Parisian guys who invented the Coding Dojo wanted to teach and spread TDD ! You should have no problem to use it to learn TDD yourself !

πŸ’‘ The coding dojo was invented to teach and spread TDD

Pick your favorite language, and schedule a kata plan to practice TDD. Watch one or two videos to see how gurus are doing it. At first, you’ll have to be very careful to stick to baby steps and the red-green-refactor loop. If you need help, check for local coding dojos where you’ll find help.

Can I apply this technique to learn something else than a new language ?

As you might have noticed, I used it to refresh my Javascript. I went on to learn different flavors of JS, but also different test libraries. I’ve used in to learn more advanced parts of other languages in the past.

Katas also work well to learn programming techniques like refactoring or DDD. Some nice people shared refactoring katas on the web. To practice DDD, we could repeat katas with the constraint of using Entities and Value Objects only.

You can even use the technique to learn other things like frameworks or tools, but you’ll need to tune it. As I explained before, you need an exercice for deliberate practice and a fast feedback loop. We typically use a Code Katas and TDD for that, but that’s not the only options. Whenever you can find a way to deliberately practice with a fast feedback loop, you’re ready to go ! These days, we should look for docker images with frameworks and tools pre-installed. Going through tutorials without looking at the solutions is deliberate practice. A small live environment can give us fast enough feedback.

πŸ’‘ Find Deliberate Practice exercices and a fast feedback loop for efficient learning

What if I don’t find any kata ?

Build one yourself ! I’m not joking, building a kata, especially one where you start from scratch is not too difficult. Inspiration comes from anything you happen to do in your daily work. Trim down a programming challenge you had to work, and you might have a kata ! Went to a programming interview ? The question you had to answer might do a nice kata.

"Make things happen" written on a blackboard

Once you’ve created and tested your kata, share it ! There are online kata repositories where you could get a chance to publish it.

One last thing

I just remembered I did not finish my story about my Javascript kata plan. For those wondering, here is the end of story. In the end I did not join this team to do Javascript coaching. After thinking through it for a while, I decided to stop the katas there, and move to something else. I was only 6 hours in, and what was the point to study Javascript not to use it straight away ? The day I’ll need it, I’m likely to have forgotten 80% of it and some of it will be outdated. The knowledge is only another 20 hours away anyway !

That’s what we could call “Just In Time Learning” ! We are drowning in knowledge nowadays. It’s better to have a fast and effective way to learn anything than trying to know everything.

Why 20 Hours of Code Kata Are So Effective for Learning New Languages

In my previous post, I described how I’ve been using 20 hours of Code Katas to learn new languages. If you did not read it yet, have a look at it first. Let’s now look at why it works so well.

In The First 20 Hours Josh Kaufman explains how he learned Ruby in 20 hours. He did not become a Ruby expert, but he was able to build and maintain a static website generator. For my part, I have succeeded to learn a bit of machine learning using the 20 hours technique.

The effectiveness of the 20 hours of Code Katas relies a few key points.

Drawing of "Why ?" mixed up with the inside of a clock


Time-boxing has 2 main benefits. First, it forces us to stick to what is the most important for us to learn. There is no time to waste slacking around in only 20 hours. Plus it’s a lot easier to focus for 20 hours than over a very long period of time.

There’s a second great thing about time-boxing. The further you go, the less remains to do, and the less likely you are to drop the effort ! We are a lot less likely to abandon when we know we only need a few hours to finish the goal we had set to ourselves.

πŸ’‘ Time-boxing creates focus

A plan

Again, the plan helps us to focus. We’ll need to choose what gets in a 20 hours plan. Building the plan itself forces us to get a grasp of the learning space. This will help to pick the good stuff to practice.


Routine is a magic trick to get things done. Once we have a routine in place, we don’t have to think or do extra efforts to find time to learn. The time is already there, we just have to use it !

Deliberate practice

Some exemples from “The first 20 hours” highlight the benefits of deliberate practice. When learning the Colemak keyboard, the author went through typing exercices. When studying the game of Go, he did practices specific situation puzzles. In both cases, deliberate practice made him learn faster. Code katas are typical deliberate practice exercices for programmers.

Picture of a golfer deliberately practicing

Test Driven Development

Coding Dojos are the programmers’ deliberate practice. Coding Dojos traditionally rely on TDD. TDD sets up a fast feedback loop that is key to efficient learning. Think of all the time saved by not having to run and debug a full program every time ! Even dabbling around in the REPL cannot beat running 20 or so test cases every few seconds.

We are already programmers

One last and obvious little detail : we don’t have to learn it all ! When the author learned Ruby in 20 hours, he was starting from scratch ! Unlike us, who already know how to program, but want to extend our knowledge to a few more topics. Most of the times, we don’t need to relearn everything, but to transpose what we know in a new context.

For example, if we already know an object oriented language, learning a new one will be easier. It’s a bit like with foreign languages, the more you know, and the easier it is to learn the next one. In fact, the more languages, frameworks, patterns and paradigms you know, the more the 20 hours code katas will work for you.

πŸ’‘ The more you know about software, the easier it will be to learn your next programming language.

You might have a look at this post for advices about evergreen concepts to learn.

Next part

This was the second post on this series about the 20 hours of Code Katas technique. The next, and last, post will be compilation of answers to frequently asked questions.

How to Learn a Programming Language in Just 20 Hours

We should not panic when asked to work with a new language. We should be bold enough to answer to job openings requiring technologies we are not used to. In one word, we should not be afraid of new techs. Here is why : by scheduling 20 hours of Code Kata routine sessions, we can get a decent level of mastery on most topics.

A book with built-in clock

How I learned some Haskell

Quite a few years ago, we used to do weekly Coding Dojos at Murex. Arnaud Bailly was among us, and as he is an Haskell fan, we ended up doing quite a lot of katas with Haskell. To my astonishment, after a few sessions, I understood of the fundamentals of the language. Without ever studying it !

πŸ’‘ I learned a lot of Haskell by just going to Coding Dojos !

Many times afterwards, I learned new languages quickly by practicing them in the Dojo.

How I set out to refresh my javascript

Fast forward to the end of last year. Someone asked me if I could work at coaching a team doing some Javascript. I’ve done some Javascript in the past, but my skills definitely needed a serious update. I decided to use Code Katas to refresh my Javascript. To try to make this even more effective, I decided to mix in a bit of the “First 20 hours” technique.

The cover of the book "The first 20 hours"

I started by defining a plan of 10 sessions of 2 hours long code katas :

  1. Roman NumeralMocha – JS 5
  2. Game of LifeMocha – JS 5
  3. Mars RoverMocha – JS 5
  4. Bowling ScoreMocha – JS 5
  5. Median of a list of lists – MochaES 6
  6. LCD NumbersJasmineES 6
  7. Kata PotterJasmineES 6
  8. T9 – Jasmine – Typescript
  9. Poker handJasmineTypescript
  10. Egg cooker with ReactJasmineTypescript

The plan felt pretty ambitious at the beginning. The first session was a bit hectic as I struggled to find a quick setup I could use to code my kata in. After only 3 sessions though, I could feel I’d already made a lot of progress. I had become confident I would get most of the plan done in 20 hours.

How to start ?

A good thing about the 20 hours technique is that it’s pretty easy to start with ! There’s a catch though ! At the start, it’s puzzling to be on your own with no clear track on how to tackle the topic. Here is the fix : start anyway, stick through, and you’ll work it out 99% of the time.

Here is, in more details, how to use code kata with the 20 hours technique :

  1. Start by setting up a routine. It could be 2 hours at lunch time, 1 hour in the morning or 3 hours at night. Do whatever is best for you. It should be enough to finish in a few days or weeks.
  2. Use the first hours of your 20 hours to setup a code kata plan. It might be very fast if you already have an idea of your learning space. It will take longer if you are a complete newbie. Skim through the literature for the main concepts until you have a plan. Try to keep this phase under 6 hours, otherwise you won’t have any time left for actual learning.
  3. Test Driven Development plays a key role in fast learning ! Next step is to setup a development environment with TDD to use in your Code Kata sessions.
  4. Finally, do you code kata sessions. Time-box them for something less than 2 hours and run a mini-retrospective at the end of every session. Don’t hesitate to adapt your plan if it makes sense.
  5. When you reach 20 hours of learning, stop your sessions. It will be time to think a bit about what you accomplished.

πŸ’‘ TDD plays a key role in fast learning.

If all went well, you should have learned quite a lot in only 20 hours. At that point, it’s up to you to decide what to do next. You can either decide to dig deeper. In this case, setup a new run of 20 hours of code katas ! It could also be a good time to read a bit of theory about what you just learned. Casting a different light on the topic will make it stick and deepen your understanding. Otherwise, you could stop there and start whatever is on your mind. I don’t recommend continuing on the same topic without rethinking a new plan though. That would kill your focus and be a less efficient use of your time.

To be continued

This was the first post in a series about applying the 20 hours technique and Code Katas to learn new programming languages. Here is the what to expect in the coming posts.

  1. How to learn a programming languages in just 20 hours
  2. Why 20 hours of code kata are so effective for learning new languages
  3. Frequently asked questions about the 20 hours of Code Katas

How to Get the Max Out of Your Team Coding Dojo ?

If you’ve read my previous posts about Team Randori Coding Dojos, you should know why and how to run a successful one.

Did you manage to setup the team Randori coding dojo as a recurring event ? Congratulations ! Your team is on the road to continuous learning and improvement. To close this series of posts, here are battle tested tricks for greatest impact. Let’s boost your teamwork, your production code and a few other things.

Yoda doing the Fizz Buzz kata

Boost your teamwork

I stated before that the team Randori is a perfect occasion to improve your teamwork. By itself, just doing it will already take you a long way towards better collaboration. As instigator of the coding dojo though, you can push the topic faster and further.

Coding and Design Conventions

Whenever you see the opportunity during the dojo, raise design discussions. It’s a good way to share best practices. It often ends up in new coding conventions for the team.

Also don’t forget to use the retrospective. It’s the perfect time to agree on best practices for the dojo and for production code. Push people to dig into what they are mentioning. Ask them if they are willing to adhere to a particular practice. You can use thumb vote to get a quick agreement. Once the team agrees on something, record it somewhere and make sure it is visible to everyone.

Egoless Programming

Egoless Programming makes collaboration a lot easier within a team. In the dojo, demonstrate Egoless Programming yourself. In particular if you already enjoy good peer recognition, adopt a “low attitude”. Don’t hesitate to encourage others to delete your code when they have a better idea. Yourself, don’t hesitate to delete code if it makes sense, but don’t make a fuss about it.

πŸ’‘ Be a champion of Egoless Programming in Coding Dojo to bring this practice in your team.

Be careful if your workplace is too competitive or if your reputation is not yet strong enough. I’d go slow on this aspect in such situations.

During the dojo, you might notice people who have difficulties with egoless programming. In this case, remind its principes to everyone and that you are here to learn and practice. You can also mention that this is a TDD exercice and that deleting and changing code is the way to go.

The cover of "The psychology of computer programming"

Going further

After enough successful sessions, you’ll want to push further and experiment new things. Absolutely do it ! There’s a lot more to discover about the coding dojos.


You can try new formats like the Prepared Kata or Randori in Pairs. You can learn a new language by redoing your favorite problems in this language. You can add constraints like “No If”, “Always Compiles” or even exotic things like “No Heap Allocation”. You might also give Emily Bache’s book a read for tons of others ideas.

Production code

If you continue long enough, your team will get particularly good at Randoris. At that point, you might wonder how you could apply this to production code ? It turns you can !

One way I found, which I wrote about in my first post, is to try to fix a local smell or static analysis issue in the code. Get all the team to do a Randori to fix that, discuss the design and conventions, and commit at the end of the session.

Particularly difficult legacy code refactorings are also pretty good candidates for Randoris.Β 

πŸ’‘ Given enough eyeballs, all bugs are shallow. Linus’s Law

Once you are there, you might altogether jump into mob programming ! Randoris are by nature, like timeboxed mobs. Replace the Randori rule “Driver decides what to code” with Strong Style pairing (Make the driver code your idea) and that’s it, you are a mob !

Spread the word

One last thing before closing this series on team coding dojos. If the practice is useful to your team, spread it. Chances are that there are other development teams working next to you. Invite members of other teams to your dojo. This will build up their envy for their own team coding dojo. Propose your help to boot their first session !

In the long run, the improved practices of this team might benefit you ! For example, if your teams start collaborating. Or perhaps you’ll join this team some day !

Whatever happens, I wish you a lot of fun in your teams Coding Dojos. Happy Coding !

Coding Dojo Troubleshooting

In my last 2 blog posts, I’ve detailed why and how to start a team Randori Coding Dojo. That’s the easy part. As soon as you start your first dojo, you’ll face trickier issues, especially people issues.

A martial artist with a tool belt

What if my team (or my boss) does not want to ?

Very often some of your team mates won’t see the value of the coding dojo upfront and will prefer to work on other tasks. It can also be your boss, who thinks you should be delivering features instead. Here are a few tricks you can do to make it work.

  • Try to find another time slot. Ask people for their preferred moment. If you can negotiate food sponsorship with your boss, you might get everyone happy. He won’t feel you’re not delivering features, you’ll have a free lunch and you’ll improve your skills.
  • If your boss or colleague doesn’t want to spend 2 full hours on a dojo. Get them to start with smaller problems and a shorter time slot.
  • Your colleagues might have doubts about the value of the dojo. Get them to try it once or a few times before committing to a recurring event.
  • As a general rule of thumb, the more you manage to involve people in the preparation, the more they’ll adhere.
  • If you have 1 or 2 inveterate laggards, do it without them anyway. With time, they’ll understand what they are missing !

πŸ’‘ If you cannot get people to adopt a new practice, get them to try it once. You’ll be more than halfway there.

Dealing with TDD complaints

A gorilla with a skeptic look

As you’ll start your first Randori, you’ll have some complaints about Test Driven Development. Whether they come from newbies or skeptics, they usually look like :

  • Why do we stick to TDD ? We’d go so much faster if we coded this straight away.
  • We don’t need TDD for such a simple problem.
  • We don’t need such small baby steps on this simple problem.

My answer is more or less always the same. I try to re-frame everyone in the context of a learning exercice of deliberate practice. It could sound something like :

Yes, sure. I know you are professional developers and that you could easily solve this little problem. Keep in mind that we are here to deliberately practice TDD and friends. Solving the problem is only a side effect.

We are going to apply TDD by the book, for the sake of learning. It’s a lot easier to learn to swim in 1 meter of water than in the middle of the sea. Once we’ll master it in the safe dojo environment, you’ll know how to adapt it to your production code.

Please, play by the rules here !

As you can see, I don’t try to convince them. The last thing I want is to get into a pro vs cons of TDD. 95% of the time, this answer is enough to get people over their skepticism and try it for the time of the dojo. Unfortunately, the last 5% might result in a difficult session. There’s no single way to deal with these 5%. You can try to discuss with them in private, or run next session without them.

πŸ’‘ Reframe the coding dojo as a learning exercice relying on TDD to go beyond skepticism.

How to avoid getting bogged down in details

One last advice, especially for your first sessions. It’s a common rookie mistake to waste 80% of the coding time on error handling. The key is to focus on what you want to learn. You are not writing production code, so don’t hesitate to omit certain aspects. For example, assume that correct arguments are provided to skip error handling. This will save you time, be more fun and increase what you learn.

What’s next ?

This was part 3 of this series on team coding dojo. In the next post, I’ll write how to maximize the benefits we can get out of coding dojos.

How to Start a Team Coding Dojo Randori Today

In my previous post, I explained why you should start a team coding dojo Randori as soon as you can. Here is a step by step guide to set one up today.

A white belt


This the most important, and most easy, part !

A Time Slot

For a regular team coding dojo, practice showed that 2 hours every 2 weeks works great. Most teams I’ve worked with had 2 weeks sprints, which made this rhythm natural.

Try to find a day and a slot that fits your own constraints. It could on the first, last or mid day of the sprint. It could be in the morning where people are usually fresh. People might have a bit less energy in the afternoon. Don’t put it in the middle of the afternoon, or you’ll ruin the programmers’ focus. Some teams use the lunch break, and bring food in to make the coding dojo even more fun.

Once you’ve found the perfect slot, book a recurring meeting with all your team. It’s now official, you are going to have your first team coding dojo !

Material Stuff

You now need only 4 other things :

  • a room
  • a laptop with a programming environment
  • a large visible screen to display the laptop
  • a timer

It used to need a bit of preparation to get all these, but nowadays, it should be easy.

Your first session

The good thing about the Randori is that it is almost preparation-free. Here is the typical agenda for a Randori session :

  1. Introduction (0:05)
  2. Problem Selection (0:05)
  3. Coding (1:40)
  4. Retrospective (0:10)


Start by reviewing last session’s retrospective. This will bring good resolutions back to everyone’s minds. Obviously, you cannot do that at the first session. Present the rules of the Randori instead (as stated by Emily Bache in her book):

  1. If you have the keyboard, you get to decide what to type
  2. If you have the keyboard and you don’t know what to type, ask for help
  3. If you are asked for help, kindly respond to the best of your ability
  4. If you are not asked, but you see an opportunity for improvement or learning, choose an appropriate moment to mention it. This may involve waiting until the next time all the tests pass (for design improvement suggestions) or until the retrospective.

Don’t hesitate to repeat the rules when you have a newcomer or when you see fit.

The introduction is also a moment where participants can share things together. Just make sure it does not eat on coding time.

Problem Selection

There is a ton of coding dojo subjects out there. For the first session, pick in 1 or 2 problems for the team to choose from. After a few sessions, let people bring in problems and dot vote on their favorite subjects.

As a first problem, I like the Roman Numerals kata. It’s not too difficult and has some interesting YAGNI and “Do the simplest thing that could work” properties. That’s only a personal preference though. Here some resources where to find kata problems :

The Coding Dojo Handbook cover

Whatever the topic you chose for your first session, make sure it is not too difficult.

πŸ’‘ As a first team Randori coding dojo problem, I like Roman Numerals kata.


That’s why we are here ! The Randori is a dojo format where everyone works together, on the same problem, through the same computer. Start the timer for 5 minutes as the first pair works on the problem. When the timer rings, the co-pilot takes the keyboard, and someone new becomes the co-pilot. Start the timer again, and repeat after 5 more minutes. If you did not already, have a look at my previous post for more details.

You should be using Test Driven Development during the Randori. Even if you are not (yet) using it on your production code. Here is why :

  • It provides a fast feedback loop which enables the fast paced 5 minutes round robin
  • It teaches how to design testable code, which is always useful
  • It teaches how to do baby steps refactorings
  • 🎁 Bonus : it demonstrates agile principles in practice (focus on outcome, incremental delivery, YAGNI …)

I’ve written a lot about TDD, have a look at my posts for more. Applying TDD means sticking to the Red-Green-Refactor loop. During first sessions, be particularly careful that people don’t refactor on red tests.

πŸ’‘ Team Randori coding dojo demonstrates agile principles in practice (focus on outcome, incremental delivery, YAGNI …)


Stop coding 10 minutes before the end of the session. It might be difficult, but remind everyone that you are here to learn and that you can resume on next session. Use these 10 minutes to think about how it went. As the facilitator, take the keyboard, write these 4 questions in a text document :

  • What did we do ?
  • What did we learn ?
  • What still puzzles us ?
  • What did we decide ?

Ask everyone for their answers and write them down. You’ll use this at the beginning of next session.

Next Post

I thought 2 posts would be enough to cover coding dojos, but it seems I have more to say ! My next post will be about tricks and advices to make your dojos a success.

Why You Should Start a Team Coding Dojo Randori Right Now

Coding Dojos are easy to start and have a high return on investment. They will improve everyone’s technical skills. That’s only the start though. Practiced as a team Randori, they will also be a tremendous boost to team work.

An AΓ―kidoka holding a keyboard instead of a boken

My own story

Coming up with team coding conventions is always a challenge. A few years ago, I remember organizing a meeting to discuss this with my team mates. In about 1 hour, we managed to agree on the standard C# code style, but not much more. Important points like the usage of singletons were still far from any agreement. I was disappointed. At least I learned that this is not the good way to build coding conventions.

A few years later, in another team, the coding conventions topic came up again. I did not want to repeat my previous failure. I created a wiki page where we could suggest, comment and vote for conventions. It was a lot better than my previous attempt, but it was slow. It turned out that we had also been doing team coding dojos for a while. A colleague suggested to try to fix a Sonar issue from our production code during a Randori session. It took us 2 hours to fix not one but a bunch of errors and to agree on 3 or 4 coding conventions. That was far more effective than my wiki page ! Looking back at the past few months, I realized what other topics the Randoris had helped the team with.

πŸ’‘ Team Coding Dojo Randori are great at defining coding conventions.

Classic Team Problems

Coding conventions is only one of the team work problems that Randoris help to solve. Here is a non-exhaustive list :

  • People waste time by ignoring how to use their tools as best as they could.
  • People lack skills that they could easily learn from one of their colleagues.
  • Team mates don’t agree on the same design principles. This harms collective code ownership as the design goes 1 step in a direction and then 2 in the opposite.
  • People don’t know how to work in baby steps and, as a result, perform large commits. This makes code reviews difficult and breaks the Continuous Integration more often.
  • Because they are not at ease to give and receive feedback, people don’t pair. Reviews suffer from this as well, either not going in the depth of things, or ending bad !
  • Some team members might have difficulties explaining what they are doing to others.

Believe it of not, Randoris can help you with all these issues.

What is a Randori ?

A Coding dojo

A coding dojo is a meeting where programmers deliberately practice their skills. To be effective, the coding dojo should be regular, and safe. Created to spread TDD (Test Driven Development), it’s an effective way to teach other skills as well. Whatever the goal, it should use TDD. TDD sets up the fast feedback loop necessary to collaboration and effective learning. The dojo should end with a short retrospective : everyone stops what they are doing to discuss how it went.

People have invented many formats to the coding dojo, but there were only 2 at the origin. The Kata, where someone live codes a prepared solution to a problem using TDD. The Randori which I’ll detail right away.

A Randori

In a Randori, you’ll be using a single machine, a wide screen and a timer. Pairs of programmers round-rob at the keyboard every 5 minutes or so. Particularly here, we should stick to TDD for collaboration and fast feedback loop. When the timer rings, the co-pilot gets the keyboard, and a new co-pilot comes in.

5 minutes are very short, and force people to use real baby steps. If they try to do something too big, they will not reach a stable state before the end of their turn. If their change is too complex, others will get lost, and remove the code. The pair needs to collaborate a lot for others to understand and continue in the same direction. They have to explain what they are doing, and take feedback into account as much as they write code.

Programmers doing a randori

Your team

A team Randori is a Randori with your team. It improves all the problems I listed above.

  • People will share coding conventions and design best practices. They are likely to agree on something for the sake of progress in a 2 hours session. The opportunity to see how the convention works with dojo code often leads to a production code agreement.
  • People will share IDE shortcuts and tricks.
  • The constant feedback will make people accustomed to it.
  • On top of that, people will refactor or have their code refactored from time to time. This is a great lesson in egoless programming.

πŸ’‘ Coding Dojo Randoris are a great lesson in Egoless Programming

I hope I convinced you that you should start team coding dojo Randoris. In my next post, I’ll go into more details about how to setup and run your first Randori.

Reducing the Risks of Large Organization Changes With the Mikado Method - Part 3

In the previous posts, I presented how to use the Mikado Method to large organization changes. Drawn from the programming world, this technique keeps a low transformation WIP. In theory, this should reduce risk and the time to see return on investment. Let’s see the pros and cons in more detail.

A weighting machine comparing big bang and midado

An experiment culture

A first interesting point is the “Try – Revert” attitude. No one is signing with his blood that the change will have to succeed ! It’s liberating for everyone to have to try its best instead of having to succeed at all costs. In fact, it’s an opportunity to show a “right to fail” mindset. (You can read more about the topic here). It’s a clear message that leaders are proponents of experiments.

πŸ’‘ Transforming large organization with the Mikado Method shows a “right to fail” mindset.

The flip side of that, is that people might not like to try Scrum 7 times before adopting it definitely. Plus switching process every month will not be very productive. Here is what we can do about these problems.Β 

As I read in Freedom, Inc. “It’s not that people don’t like to change, its that they don’t like to be changed !”. If a transformation teams manages all the change initiative top down, people will hate it. Hopefully, the mikado graph is a unique collaboration tool. Start by presenting the method and sharing a blank graph. Ask everyone to build it together. Then let the teams handle their own part of the graph. Here is an example. Suppose a team needs to be able to integrate every hour. Add this goal to the mikado, and hand the responsibility to get there to this team. As Daniel Pink said, autonomy and mastery are key motivators.

We should also pay special attention to how we name mikado (sub) goals. If the general goal is to adopt LeSS, jumping in and out of LeSS will be very painful ! Instead of “How” goals, we should use specific “What” goals. For example, we could replace “Adopting LeSS” with “All teams integrate in less than 10 minutes”. It is a lot easier (and faster) to try to integrate in 10 minutes for a day. In one day, we should know if it works, and if not, what’s blocking. In this case, experiments will be standard improvement items in the backlogs of teams. Teams could try to integrate every 10 minutes by hand for example !

The Management 3.0 celebration grid poster

Original Poster By Jurgen Appelo

Reduced WIP

In fact, it lets people work on smaller changes, one at a time. I can think of two direct advantages of small changes. First, it does not disrupt the rest of the organization, letting it deliver as it used to. Second, it’s a lot less stressful for the people, who then have more energy to focus on the experiment.

Another point is that less things are being changed at the same time. After reverting previous attempts, less parts of the organization are being changed. There’ll be no teams halfway in the change waiting for fixes to their impediments. As usual, reducing WIP brings many advantages :

  • It requires less coaches, as they will only concentrate on areas where they can drive the change to its end.
  • It removes the synchronization overhead of different teams working on the same problem.

What about speed ?

I can hear you think “But that’s going to take forever !” It is quite the opposite. Here is why :

  • The first completed changes will be root problems. Focusing on these will bring general improvement to all the organization. The state of the rest of the organization does not matter. The path you used to discover this root problem does not matter either. Fixing this root problem is likely to bring improvement to all the teams !
  • As the graph unravels, we can use it to start independent change initiatives in parallel ! This is a classic way to speed up code refactoring that transposes to organizations. The graph gives you a clear map of which problems are independent. Perform changes that won’t conflict in parallel.
  • There are quick wins also. You don’t need to be dogmatic about reverting. Suppose you tried something that brought improvement, but that uncovers a deeper problem. If the people felt an improvement and prefer to continue the new way, let them !

πŸ’‘ Transforming large organization with the Mikado Method helps to parallelize work.

Granted, if the goal is just to move to “Agile”, then it might be slower than switching all teams to “Agile method X”. This is only faster on paper though. If you want more details about why becoming agile takes time, I encourage you to read these other blog posts. Plus, as I said above we should prefer “What” goals.

Continuous improvement

One final advantage I see with this technique is that it’s sustainable. As it’s a lot less stressful than a typical large re-org, it is possible to keep it going all the time ! It’s a gateway to continuous improvement. It’s no wonder Toyota (see Toyota Kata) people say that the improvement kata is their main management tool !

The cover of the 'Mikado Method' book

Closing thought

It’s funny how two practices like the Mikado Method and the Improvement Kata are the same idea ! I also noticed similarities with thefirst “Be Proactive” practice of Stephen R. Covey’s 7 habits of highly effective people. Could it be the same idea again ?

Reducing the Risks of Large Organization Changes With the Mikado Method - Part 2

In the previous post, I presented both large scale code and organization changes. I highlighted how they face similar difficulties of huge Work In Progress. Let’s see how programmers deal with these problems.

A drawing of a wipe, with the text "Mind your WIP"

The mikado method algorithm

The mikado method is a programming technique to perform large code refactoring one step at a time. It fixes the problematic situation we raised at the beginning of these posts. It enables developers to integrate their work with their teammates’ continuously. It allows to build features and do the refactoring in parallel. Developers can also pause a mikado refactoring for a while if needed. On top of all this, it makes it easier for the full team to collaborate on the same refactoring.

πŸ’‘ Developers can pause a Mikado Method refactoring for a while if needed.

Here is how it goes, but you can get a more detailed (and technical) description here.

  1. Try to do the change you want
  2. If it the tests pass, great, you’re done
  3. Otherwise, add a node for the change you wanted to do in your mikado graph
  4. Write down the errors you faced
  5. Revert your change
  6. Recurse from 1 for every error
  7. Draw a dependency arrow from the nodes of errors to the node of your initial change

The catch is that developers should revert the work they could not finish to move on !

How to apply it to an organization change

In some way, the Mikado Method is very similar to the improvement kata. The flow of the Improvement kata goes on like that :

  1. Determine a target condition
  2. Try to work with the target condition in place
  3. If it works, you’re done
  4. Otherwise, understand the main impediment, and revert to the old way of doing things
  5. Work to remove the impediment
  6. Start again from step 2

Have a look at these blog posts for a more practical presentation of the improvement kata.

πŸ’‘ The Mikado Method and the Improvement Kata are more than similar.

Granted, the Mikado method and the improvement kata look similar. They are in fact more than similar. The improvement kata does not prescribe how you should fix your impediments. What’s not explicit is that we can use it recursively to fix impediments ! That makes it almost identical to the Mikado Method, but for organization instead of code. It won’t be a surprise to know that some companies have used the improvement kata for that. For example, HP used it to drive its Laser Jet team transformation. Others have already used the Mikado Method for organization transformation.

Extract of the orga mikado graph used by the Sandy Mamoli

Original Post by Sandy Mamoli

Suppose your organization wants to move to full Continuous Integration(TODO). It could start by trying to integrate all their devs in 10 minutes on a small group of teams. If it works, fine, other large teams can try it as well. Let’s see what to do if it fails though. Thanks to a retrospective teams understand that they need to master CI themselves first. In this case, they could revert large scale CI, and have one of the teams try to do continuous integration. If it works, fine, another team can try it too. If it does not, they’ll do a post-mortem of some sort to understand the root issue, and work on it. For example, here the main impediment could be a coupled architecture. The fun thing would be to apply the Mikado Method to do this refactoring πŸ˜‰.

As with the Mikado Method, it is possible to draw an organization change Mikado graph along the way :

The mikado graph for the story above

The graph is a living artifact. As we try and revert new experiments, we should expand and collapse the graph. This creates a global and shared view of the state of the change. Needless to say that this is great for collaboration.

To be continued (again)

This was part 2 of a series on applying the Mikado Method to organization changes. I’ll end this series up with next post, where I’ll go through the pros and cons of the approach.