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. 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 !"

Examples

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.

Why and How to Start a #ZeroBugs Policy - Part 4

This is the forth and last post of a series about the #ZeroBugs policy. In the previous posts, I detailed how we applied it in our team, what were the consequences and how you could do the same.

There’s a catch though, even if you are sure that #ZeroBugs is a good thing, people around you might not agree ! As with any kind of change, one of the trickiest thing is overcoming people’s fear about your idea. This post will be about dealing with people’s resistance.

Drawing of people arguing over the #ZeroBugs policy

A few general change advices

With time, I discovered general best practices to bring change. The first is that you are much more likely to get your ideas through if you are nice with people ! In a bit more details, this means that :

  • Try to help people, for real !
  • Listen to their concerns instead of pushing your idea
  • Don’t blame people if they don’t see the value of your idea

πŸ’‘ Change agent’s advice #1 : be nice with people

Another invaluable trick is to be patient : change takes time. Finally, if you are stuck, suggest testing your idea for a while, people are more likely to adopt it this way.

Cover of the book "Enchantment: The Art of Changing Hearts, Minds and Actions"

Winning the devs over

Back to our particular #ZeroBugs issue. In this particular case, I would Β try to convince the devs first. Reason A is that without them onboard, the practice won’t work as well as expected. Reason B is that it is more difficult for management to say ‘no’ to a full team than to a single developer.

Developers will fear spending too much time fixing bugs. Sell them long term fixes instead of dirty quick fixes. Stress that it will be a chance to refactor important, poorly designed parts of the system. Also explain that once the bug backlog is clean, they’ll spend more time on new developments.

A last argument for developers is about clarifying prioritization. Pushing bug triage to business people will save devs from feature creep. That should save them from some stress of not delivering.

Winning business people over

They’ll fear that fixing bugs will reduce the delivery of valuable features. Indeed, if done without care, this is a real danger. Highlight the value of bug fixing : it improves the product and image of the company. Fixing bugs also increases feature delivery in the long run. It does so by removing some recurring support issues and fixing technical debt.

Also point out that they’ll have more visibility and control over what is being worked on by the team. This is an opportunity for them to increase the value throughput.

They might also have concerns about the time to spend categorizing bugs. Make sure to get this as streamlined as possible. For example, if they are very busy, you could pre-categorize the issues to make it easier for them.

In this blog post, Andrew Fulton explains how he convinced his boss to adopt a #ZeroBugs policy.

Last words

πŸ’‘ #ZeroBugs policy makes work more sustainable

I’m done with this series about #ZeroBugs policy. I hope I convinced you to give it a try. The developer’s life is better without bugs ! If you do, or if you already did, I’d love to read about it. Thanks a lot for reading me so far.

Why and How to Start a #ZeroBugs Policy - Part 3

This is the third post of a series about the #ZeroBugs policy. In the first 2 posts, I detailed how we applied it in our team, and what were the consequences.

I hope that by now, I have convinced you that applying a #ZeroBugs policy is good for you and your team. I’ll surprise you by arguing that it’s a lot easier than people first think. This post will be about how to inject it in your team.

A funny formula for zero bugs

Build quality in

Obviously, you need a low bug rate for this work. If your team creates too many bugs, fixing incoming bugs only will consume all your time. You won’t be able to deliver new features and it will make everyone miserable.

If you are in this situation, I’d advice you to start investing in coding best practices such as :

With grit and time, your bug rate will get down.

New bugs

Before dealing with the old bugs, you should first put in place the target policy for new bugs. Don’t let the situation get worse !

The way to deal with new bugs is to setup a regular (at least weekly) routine to decide what to do about them :

  • If it’s causing real pain to someone and needs a fix as soon as possible, then it’s very likely to be a bug
  • If it’s something important you can still live without for a few sprints, change it to a story in the backlog.
  • If it’s not that important now, delete or archive it as “won’t fix”

From then on, the new convention is fix all bugs before working on features. This ensures that the bugs backlog will not grow anymore. If you need more details about how to categorize issues, take a look at what Sam Hatoum says about that.

Different people will provide different perspectives on issues. Business people will know their business value. Developers will know fix’s impact on technical debt. Finally, service desk people will know how much time they would save with the fix. Depending on your situation, involve the right people in the classification.

Another approach is to do as we did, and come up with clear rules that define what a bug is. This has the advantage of allowing developers to categorize issues on their own. The drawback is that it can be very tricky to come up with these rules.

πŸ’‘ Agree on rules for categorizing bugs with your users to streamline your flow

Old bugs

Ok, that was the easy part. How can we deal with the zillions bugs we all have waiting in the backlog ? Depending on the size of your bug backlog, you should adopt different strategies.

If you have a rather small bug debt, as we did, you can get away by prioritizing X bugs every sprint.

Let’s suppose you have a larger bug debt. You could do as ConceptShare did and crank out a feature team dedicated to eliminate bugs. That should work, but it will take some time. It took the ConceptShare teams 18 months to get rid of a 350 bugs backlog !

It’s a good idea to take a look at all existing bugs to re-classify some as stories and delete others. Just as you should now be doing with new bugs. This should drastically reduce the number of bugs, but it will take some time from very busy people … Again, rules to define what a bug is would make this easier.

Finally, there’s a last, very effective solution : archive all the bugs ! Some bugs must be months if not years old. Deleting them should not do much harm. Users will report important bugs again anyway. One caveat though : this won’t work if your bug rate is too high ! If quality is too low, you’ll drawn under old bug.

Going further

Cover of the book "Explore It"

It’s great to fix the bugs very fast. It’s even better if to fix them before the users see them ! Exploratory testing is the way to do that. It will also provide you a measure of how many bugs escape your development process. I encourage you to try this very interesting practice. I wrote a guide about how to start exploratory testing.

πŸ’‘ Exploratory Testing gives you a quantifiable measure of your workflow

Next week

This was part 3 of a series of posts about the #ZeroBugs policy. In next week’s post, I’ll provide arguments and advices to convince the people around you to give it a try.