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. Don’t miss it : Subscribe !

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.

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

Large scale agile transformations are often painful, stressful and … failed ! Mixing the Improvement Kata and the Mikado Method can make them more successful.

A drawing of entangled mikado sticks

The Mikado Method is a programming technique to reduce the risks of large code changes. Let’s see how to apply it to organization changes.

“If it’s not broke, don’t touch it !”

A lot of programmers have learned this maxim the hard way. Here is how it goes.

It all starts with a shitty piece of code that gets into everyone’s way as soon as they have to deal with it. It’s badly written, difficult to understand, and very difficult to change. One day, a brave programmer suggests to rewrite or revamp it so that it gets easy to work with. This is not a small task, but after some discussion and negotiation, he gets a ‘go’ from his team.

A few hours in this refactoring, he discovers that he needs to adapt other pieces of the code before he moves on. He leaves his work in progress as it is, and starts to change these pre-requisites. Unfortunately, these too have pre-requisite. Little by little, he builds up work in progress(WIP) on different parts of the code. He still has nothing working though ! He’s beginning to have troubles keeping track of all his WIP. On top of that, he’s wasting time integrating the work done by his colleagues with his WIP. As days pass by with nothing to show, his team begins to doubt that he’ll be able to bring this to its end ! The situation as a whole accumulates an awful lot of stress on the developer. In the end, it is pretty likely that the team will abandon the whole thing.

πŸ’‘ By never changing the code, programmers make it even harder to change

The problem with this maxim is that by never changing the code, programmers make it even harder to change. In the end, this makes new features too expensive to build, which is pretty bad for the business.

Let’s see how this related to large organization changes.

The typical large scale agile transformation

It all starts when a leader decides that Agile is the way to go. It could be because everyone is doing it or that he got convinced by someone. It could also be because consultants sold him a 10% productivity increase. The reason does not matter. What matters is that in a few months, all the company should switch to an Agile method. Large groups of people will have to switch to Scrum of Scrum, LeSS, SAFe or any other framework. Even if the transformation is split in product teams, these will still be big.

One great thing about these frameworks is that they show problems. After a few sprints people discover that they have troubles delivering incrementally. After analysis, they understand another deeper problem. Examples : bad management, legacy code, outdated tooling, bad underlying processes … As Agile is the new Golden Hammer, the teams responsible of these problems in turn jump to Agile X method. Unfortunately, these too might fall into deeper problems … and the pattern repeats itself. Meanwhile, the top down transformation team sticks its own objectives. It continues to onboard new product teams to Agile, fueling the mess that is spreading.

A golden hammer

At any moment, a very large proportion of the people in the company are in a state of transformation. This is pretty bad for productivity. What is even worse is that they are all facing the same root problems. They are all blocked in a sub-optimal state, impeded by the root problems. Following agile principles, they all start similar initiatives to workaround these issues ! They then need to coordinate with other teams, to avoid duplicate efforts. On top of that, as agile newbies, all these teams need coaches to help them at the same time.

πŸ’‘ Large scale Agile transformations are too often stressful for everyone …

Needless to say that this situation is pretty stressful for everyone. It costs a lot, in productivity and consulting, for results yet to come. Despite reassurance that things will get better, the leader’s trust is eroding.

The story ends bad when it goes on for too long. When the leader loses faith in the initiative, he cancels it, and goes back to the old ways. That’s what we call the Agile hangover : “We tried it, but it was a mess. It does not work for us.”

To be continued

As you can see, the two situations have a lot in common. Programmers have invented the Mikado Method to deal with large scale code changes. This was the first post of a series about the Mikado Method and large scale organization changes. In next post, we’ll detail this technique, and see how to apply it on organization changes.

Why Agile Transformations Usually Don’t Work - Part 4 - Transparency

This is the fourth and last post in a series about making large organizations more agile. I encourage you to start with the beginning.

In the previous posts, I presented why large scale “Agile” transformation usually fail. Part of the solution is about giving people the time to learn and a safe environment. That’s not enough though.

A squirrel with a helmet

Provide the data

I explained how Management by Objectives harms experimentation. I presented alternatives like Salary Formula, Badge Based Compensation and Merit Money.

An interesting commonality between these compensation practices is that they are transparent. When all this is public, people know what to do if they want to increase their income. For example : get a badge by learning something new, or collaborate with others to get monkey money. That’s great, but they should also know how to increase the profits to get a bigger cake for everyone !

Management By Objectives is not only about compensation. It also cascades business objectives all the way down to everyone in the company. If we get rid of MBO, people still need to know what is important.

Let me introduce Objectives and Key Results, aka OKRs. Intel invented OKRs. Nowadays, among many other companies, Google is famous for using them.

A visual comparision of MBO and OKRs

πŸ’‘ OKRs have nothing to do with compensation !

OKRs match this experimentation mindset. OKR objectives should be ambitious, with room for overachievement. OKRs also provide Key Results, which let people measure how well they are doing ! As OKRs are public, teams get a full understanding of the context of their actions.

To max out the value of OKRs, we should make as much data public as possible. Financial figures can really help teams to know if they are doing a good job.

The end result is that teams can take informed decisions. They can measure the impact of their work at their scale, but also on the full organization.

Compelling mission

A last good point of OKRs is that they make very good higher level backlog items. Both Team Epics and full products can be OKRs. Even the company’s mission can be an OKR. Check Toyota’s mission, for example, “Better cars for more people”. This provides invaluable guidance for everyone to take day to day decisions.

In fact, a clear and motivating company mission statement is not only good but mandatory. Without it, people will go in all direction, resulting in very slow progress. It’s an absolute pre-requisite for self organization to work. This is particularly a challenge for business-to-business companies. One symptom is when developers succumb to Resume Driven Development.

πŸ’‘ Self organization does not work without a clear and compelling mission.

To summarize

Organization’s initiatives to become agile fast are doomed. They can at best expect small productivity and visibility improvements.

The benefits of being agile include lasting continuous improvement and business resiliency. Unfortunately, this cannot happen in a day. The road starts with the following :

  • Creating a safe environment by getting the compensation issues out of the picture
  • Providing a clear goal and all the data people need to take informed decisions
  • Finally, leave the time for the people to learn

I discovered another fun fact while looking for references. People from lean manufacturing have been arguing the same thing for decade ! The good news though, is that we ripe improvements all along the way !

This was the last post of a series about making large organizations more agile. Next week, I’ll present an idea to apply the Mikado Method to refactor organizations one step at a time !

Why Agile Transformations Usually Don’t Work - Part 3 - What to Do

This is the third post in a series about making large organizations more agile. I encourage you to start with the beginning.

Let’s summarize the previous posts. Large scale “Agile” transformation programs usually fall short of their promise. One reason is that leaders forget to provide a safe context to learn.

A kid trying to drive a donkey with a carrot and a stick

What should we do ?

First, we should take the time ! Rome wasn’t built in a day. The road to an agile organization is a never ending path. We should also remember what we are after :

  • Super fast adaptation to business changes through massive decentralization
  • Low process overhead thanks to people’s buy-in
  • Continuous innovation in both products and organization, relying on everyone’s creativity

This is far more ambitious than a mere 5% productivity increase !

Be patient for people to learn

The goal is for people to be able to take bigger decisions on the spot. No one can learn this in a few hours. All over the company, people will have to improve their problem solving skills. They might also need to learn how to do root cause analysis. They’ll need to take into account the point of views of other people in the organization. Some will need to beef up their communication skills as well. All will need to master new collaboration practices to stay up to date with what is going on.

πŸ’‘ An organization cannot be agile if all decisions have to go up and down the management ladder.

That’s a lot, and it takes time. The visible part of the iceberg, the collaboration practices, can be setup in a few weeks. But it won’t yield much until the people are bold enough to take decisions by themselves.

First, I need to have a word about the workload in this section. If people are Busy to Death, They won’t have the time to learn. They won’t even have the mood to think. Again, lasting productivity goes through sustainable pace. Slack time or a 20% policy are very good investments here !

Communication skills alone take months or years to improve. A communication training campaign can help to make the company ready to be more agile. In a previous team, new joiners used to attend a Non-Violent Communication training. Being transparent a constructive is a foundation of an agile organization.

Pyramid of the 5 dysfunctions of a team book"

Finally, root cause analysis and problem solving skills take practice to get around. Some organizations, used to carrots and sticks, have been avoiding this for years ! Good coaches can teach this to teams. People first need to learn that it’s OK to look into problems and to experiment solutions though. That’s where a safe environment helps.

The Safe environment enhancer

If people remain afraid to fail, they won’t do enough experiments. As a result, they’ll learn slower. They’ll also keep delegating more decisions ! The organization won’t become very agile. Sure, leaders will get small productivity and predictability improvements. Unfortunately, exclusive focus on these puts innovation in danger.

People should have the means to experiment. By far the greatest experimentation killer is carrots and stick management. If people live in fear of losing their job, we have no chance of becoming more agile.

πŸ’‘ Encouraging experimentation while sticking to compensation by objectives is schizophrenic.

The situation is only slightly better with management by objectives. One of the reason is that as people start to expect their bonus, they also start to fear not having it next year ! We’re back at the fear problem. There’s a more direct issue with MBO though. A good experiment should be ambitious and have a high likelihood of failure. Unfortunately, people will negotiate unambitious objectives, to secure their bonus. In the end, people do far too few bold experiments and don’t raise problems to safeguard their bonuses. Eventually, both people and the organization fail to learn.

Cover of the book "Punished by rewards"

Instead of using MBO, we need to find a different way to deal with compensation. The management 3.0 literature has plenty of ideas for that. For example :

After disclosing employee salaries, Buffer was inundated with resumes

  • Badge-based compensation. Holocracy describes how to take valuable skills into account in a salary formula. To get a badge on a topic, you need to be recognized by the people who already own this badge. Examples of badges can be “UX Expert” or “Senior Software Engineer”.
  • Merit money. Company profits redistribution to employees should be both motivating and fair. Instead of typical yearly bonuses, merit money is a crowd-sourced money allocation scheme. Everyone regularly receives a fixed amount of monkey money. You should give some back to a colleague who helped you. You could also give some to acknowledge someone else’s great job. Every month a lottery is played to know if employees should receive their share of profits. If so, everyone gets his share in proportion with the monkey money they received. Otherwise, profits accumulate until the next lottery.

We could worry that dropping MBO will drop people’s motivation as well. It turns out it’s the exact opposite ! Check out this talk by Daniel Pinks to understand how bonuses kill motivation.

To be continued

This was part 3 of a series of posts on making large organizations more agile. We’re almost at the end. The last post will dig into how to provide the data to everyone.

Why Agile Transformations Usually Don’t Work - Part 2 - the Problem

This is the second post in a series about making large organizations more agile. I encourage you to start with the beginning.

Let’s summarize the previous post. I illustrated the typical disappointment with large scale “Agile” transformations. At best they bring a small short term productivity improvement. At worst, they turn into micro-management.

Why doesn’t it work ?

An organization is agile if it is able to respond and take advantage of changes fast. An organization where decisions need to go up and down the ladder will be slow. To thrive in this complex world, everyone needs to be able to take faster and bigger decisions. To do so, people need the good data, but also the right to fail, and the chance to learn new ways of working.

A sign post with 2 directions : a convoluted 'centralized decision making' road, and a simpler 'agile decision making' road

People with the right authority could make data available fast enough. Learning new habits and convincing every one of their right to fail takes time though.

A safe environment

In “Turn the shop around” Navy captain David Marquet explains how he empowered his crew. They would take decisions and inform him with “I intend to …”. Doing that, he also took on him the responsibility of his subordinates errors !

Cover of the book "Turn the ship around"

There are always people who put the organization’s interests before theirs. They will try new experiments, even if could backfire in their faces, because it’s the right thing to do. Unfortunately, these people are pretty rare. The vast majority will not try things that would get them troubles. They need a safe environment to unleash autonomy.

The typical adoption technique is to “fake it until you make it”. Apply the practices until the principles and values soak in everyone’s mind. There’s a catch though ! People need great models. People buy-in values, not actions. Think of Apple and other technology brands. People buy Apple hardware because they “Think Different” not for the products ! (Though I admit I love their products too :–))

Although people buy-in values, they measure them through actions. Leaders need to walk their talk for people to trust them.

πŸ’‘ People buy-in values, but they measure them through actions.

Very often, leaders stick to actions that communicate that it is not ok to fail. Like compensation by objectives for example. Or highlighting the commitment of sprints. Praising overwork is another one !

Place to learn

Real learning comes from experimentation.

πŸ’‘ β€œNever help a child with a task at which he feels he can succeed.” Maria Montessori

Photograph of educator Maria Montessori

This is still true for adults at work. Every time management pushes top-down incentives to speed up change, general understanding suffers. There is a limit to what an organization can withstand before it falls prey to cargo cult.

Leaders must provide a safe environment. They must also provide the conditions for the teams to learn and improve their unique way of working.

Too often, leaders are in a hurry. “Why should we waste our time rediscovering what others have already understood ? Let’s apply Scrum (or SAFe or LeSS) !”

Did you ever learn something by copying the results of others ?

Let’s look at SAFe for example. It’s a collection of proven best practices. That’s only half of the story though. What’s not clear is how a practice is proven to work ? By definition, a team had success with it before adding it to SAFe. It can only be the result of experimentation and learning, as it was not yet part of SAFe !

In the end

Many leaders embark their organization in an Agile transformation for some business benefits. Unfortunately, people often perceive that “It’s just the latest way to squeeze a bit more out of us all !”.

It does not have to be that way. What if they followed massive decentralization of power. What if they made more data available ? What if they adapted the compensation scheme to encourage risk taking. What if they gave authority to their teams to experiment and learn from their own problems. Would people still feel it’s just another re-org ? As a reference, see how unions have been fighting lean manufacturing for decades.

That’s what we’ll look into the next posts. This was part 2 of a series of posts on making large organizations more agile. Further posts will propose what to do.

Why Agile Transformations Usually Don’t Work - Part 1 - the Situation

In Aesop’s famous tale, a farmer kills his goose that lays a golden egg every day to get all the eggs at once. He finds no eggs, lost his goose, and remains poor ever after.

I’ve seen the same pattern happen many times in the software industry. A team decides to become more agile. After a few years of continuous improvement, it shows largely above average performances. Managers start to notice and ask how the team got there, to replicate this success. Unfortunately, they don’t want to wait a few years for the other teams to find their own way. As a result, an “Agile” process is copy printed to all teams. Follows only ephemeral improvement, at the same time that the initial team gets drowned in a company “Scaled Agile” initiative …

Drawing of a street tag 'Let's all do this Agile thing !"


In the 60’s, Toyota was innovating new ways to build cars. Other car manufacturers used to visit the Toyota plants to understand how they did it. Toyota was welcoming them with open arms ! (You can still visit Toyota plants today) Fortunately for Toyota, none of the visitors managed to copy their results.

πŸ’‘ Competitors managed to copy Toyota’s practices, but not their results !

Let’s think of other agile companies like Google, Apple or Spotify. Did they copy an existing Agile framework or recipe ? No, they rather learned to embrace change in their own way. The HP LaserJet team did not become more agile by sticking to best practices either, they also did it their own way.

The cover of "A Practical Approach to Large-Scale Agile Development. How HP Transformed LaserJet FutureSmart Firmware"

Thinking about it, I never read a single story of how a team succeeded by sticking to method X, Y or Z.

It’s just not possible to be agile by strict adherence to a method. Unfortunately, that’s what most companies do. Have a look at the job posts, everyone is looking for agile devs, but do these companies look agile once you are in ?

What are the actual results ?

With a move to “Agile”, management usually envisions some of the following benefits :

  • better quality
  • increased productivity through waste reduction
  • more innovation

People who want these changes fast don’t understand what they are doing. If they were, they would not expect this to be fast. It’s all too easy to see “Agile” as a method, or a process.

Following the traditional “machine” organization metaphor, processes are to be applied ! Deploying the new “Agile” process, leaves little room for self-organization and empowerment. People throughout the organization perceive it as yet another reorganization. People still feel like cogs in the machine. Cogs don’t show a lot of autonomy and motivation ! That’s when the vicious circle kicks in. To fix the lack of drive, management adds more top-down process !

Long story short, these transformations bring very little improvements. At the beginning, when everyone is keeping a close look at the process, things will go a bit better. A few month later, things will get back to where they were.

A specific danger of “Agile” is that it can serve micro-management. Short iterations, code reviews and other feedback practices puts everyone under the radar. This makes decision makers feel more in control, at the cost of motivation and innovation. As an example, check this post from a pair programming sceptic.

πŸ’‘ “Agile” can easily slip into micro-management

Next Week’s post

This was part 1 of a series of posts on making large organizations more agile. Next post will dig into why the traditional approach described above does not work. Further posts will propose what to do.