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.

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

This is the second post of a series about the #ZeroBugs policy. In the previous post, I detailed what a #ZeroBugs policy is and how we tried to apply it. I encourage you start there.

Here is a quick summary of where we stood. We had tried to apply a #ZeroBugs policy with exploratory testing. We had discovered a lot of bugs, and we had agreed to tackle them little by little. We hoped to finish in a few months.

The Bug Panic game

The final bug rules

At about the same time, we started an improvement kata to increase our productivity. I wrote in details about the full story, but to make it short, here is what we discovered :

  • It would take us years, not months to fix all our bugs
  • Our definition for bugs was part of the problem

After some experimentation, here is the bug definition we came up with :

  • It corrupts data
  • It returns wrong results
  • It crashes with an unexpected error message

It stopped scope creep by removing the subjective “it used to work” rule. This rule also sped up bug fixing a lot. We closed many bugs with descriptive error messages.

Consequences

Within 2 sprints, we reached a #ZeroBugs state. Backlog ‘management’ was simpler as it did not contain bugs anymore. We were also spending less time fixing bugs and more building stories. Even as we resumed our intense exploratory testing sessions, our bug backlog did not grow.

After a while, we discovered other benefits to the #ZeroBugs policy.

Spending less time on bugs made our velocity more stable. Our product owner was happier to see us deliver new features more reliably. In the end, this improved our relationship with him.Β 

πŸ’‘ #ZeroBugs policy makes developers happier

It also made the team happier. First, because we had a lot less of stressful emergencies to answer to. Second, because programming new features is more interesting than fixing bugs.

A relaxed developer

It also made the other teams happier and more productive ! They encountered a lot less bugs when using our product. When they had problems, they usually got a clear error message. They would fix it on their side, or suggest us a new feature.

A #ZeroBugs policy and exploratory testing also have a side effect on technical debt ! Bugs tend to appear in the more brittle parts of the code. When fixing bugs, you took the opportunity to refactor technical debt at the same time.

πŸ’‘ #ZeroBugs policy reduces technical debt

Finally, having a definition for bugs was very helpful. It allowed decentralized prioritization of bugs. The alternative to that is to have a domain expert available to sort bugs from stories. A decentralized rule prevents all sort of coordination and people issues. Our system was rather technical, which made it easy to define what a bug is. In other cases, it might be worth spending some time with the domain expert to define similar rules.

“Use decision rules to decentralize economic control.” From Principles of Product Development Flow by Donald G. Reinertsen

To summarize, sticking to #ZeroBugs is a win-win and sustainable situation for all.

Next week

This was part 2 of a series of posts about the #ZeroBugs policy. In next week’s post, I’ll provide a step by step guide about how to inject a #ZeroBugs policy in your team.

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

Some teams spend 95% of their development time fixing bugs … An entrepreneur I worked with reported an even scarier story. He went bankrupt because bugs were taking all the development time. He had no time left for new features !

At the other end of the spectrum, some eXtreme Programming teams reported bug rates as low as 1.5 per month !

πŸ’‘ Some XP teams reported bug rates as low as 1.5 per month !

Wouldn’t it be great for everyone if we had less bugs to fix ? Programmers would do more interesting work. Business people would get more valuable features. People would do less overtime. All this while users get a better product !

A bug in a viewfinder

Last year, in my team, we reached and maintained a #ZeroBugs state. Here is how we did it.

What’s the #ZeroBugs policy

Before we jump into our story, let’s take a second to understand what this is all about.

Bugs waste time. They waste the time of users, who can’t do what they need. They waste everyone’s time with interruptions from unhappy user. They steal time from new features development. If you have a large number of known bugs, you’ll also waste some time organizing them : eliminating duplicates, prioritizing them, ignoring others …

A #ZeroBugs policy is the convention of having no bugs in your backlog. This means that when someone finds a defect, it should be immediately :

  • fixed before any other feature
  • prioritized as a new story
  • or ignored (for the moment)

Obviously, the less bug you create the easier this will be.

Our journey to a #ZeroBugs policy

Context

We were an R&D team, building a data management system. Our product was moving outside of pure research and development. Other teams were starting to use it and often reported bugs back to us.

We’d first read about #ZeroBugs in The Art of Agile Software Development. Given enough automated testing, XP teams could almost stop doing bug fixing !

Cover of the book "The Art of Agile Software Development"

As we had very solid automated testing in place, we decided to take the extra steps to save time on bug fixing.

First attempt

There is a straightforward way to install a #ZeroBugs policy. Make sure to have a customer or a Product Owner to prioritize defects as soon as they appear (check this story for an example).

Unfortunately, this would not work for us. Our Product Owner was great at providing us with a long term vision. He could not be available for day to day bug prioritization though.

Our first try was to propose a definition for bugs that we could use ourselves to classify them. We decided that something was a bug if either of the following was true :

  • It corrupts data.
  • It returns wrong results. As we were building a data management system, this was rather easy to verify.
  • It used to work but is now broken

Whenever we found an issue meeting any of these points, we would start working on it straightaway.

πŸ’‘ Exploratory testing goes hand in hand with #ZeroBugs policy

To speed up downstream integration of our product by other teams, we also started Exploratory Testing. Exploratory testing is a practice that goes hand in hand with a #ZeroBugs policy.

Unearthing a bug debt

During the first exploratory testing session, we found more than 10 bugs. We thought that with a bit of focus we could fix all lingering bugs in a few weeks max … After 2 other sessions and more than one sprint of intense bug fixing, we had even unearthed more bugs. We were wrong, this would take a lot more than a few weeks.

If we kept on our 1 hour exploratory testing sessions every sprint, we would fill our backlog with bugs. We would also be fixing bugs for a few months before we could tackle any new feature !

We agreed on the following strategy to fix all these bugs little by little :

  • stop these intense exploratory testing sessions
  • do shorter exploratory testing sessions at the end of every story
  • fix 5 to 6 bugs every sprint

We hoped to fix all our bugs in a few months.

Next week

That was the first part of a series of posts about #ZeroBugs policy. In the next post, I’ll explain how we dealt with this bug debt and dig into the consequences it had on our work.

Sustainable Productivity in eXtreme Programming

eXtreme programming will not improve your short term productivity. But it will drastically improve your long term productivity.

My last post detailed how prioritization and Work In Progress limits are the keys to less work and higher productivity.

XP is an experiment in answer to the question, “How would you program if you had enough time?” Kent Beck

Cost of changes over time, for traditional and XP ways of building software

The best jam is made in old jars

As I was writing the post, I could not stop thinking :

Once again, XP has been addressing these WIP and prioritization issues for 20 years now !

Let’s see exactly how.

WIP limitation

XP has a drastic way to reduce WIP by 2 : pair programming. Instead of 6 developers taking on 6 stories at the same time, they only tackle 3. I won’t dive into the ton of other advantages to pair programming here. If you want to learn more, these blog posts might help.

Although it is now seen as a Scrum practice, Planning Game was part of original XP. Sticking to a basic planning game will give room for slack at the end of iterations. The trick is to leave the infamous focus factor away.

πŸ’‘ A simple planning game will give room for slack.

Suppose a team member takes vacations for a sprint. The team should deliver less user stories that sprint. They’ll have less story points to schedule on next sprint. This leaves room for slack and long term improvements such as refactoring, learning … If half the team goes on holiday, that’s a different story, adapt your schedule with gut feeling.

A funny aspect of this is that XP teams are now the most likely to switch to the more extreme #NoEstimates.

Priorities

XP’s on-site customer is a straightforward way to work only on the most valuable features. Who better than an end user would be able to make this estimation ?

The YAGNI (You Ain’t Gonna Need It) and simple design principles avoid building unnecessary features. TDD’s strict point of not writing code before a failing test prevents over-engineering.

Modern XP

In this wonderful talk from Rachel C. Davies, she presents how her team has been improving XP for 15 years. She explains how they organize as 2 mobs and 1 solo. At any moment, one mob is working on stories. The other mob works on important long term technical improvements. The solo does some learning. This is an even greater WIP reduction technique than pair programming.

Having a dev doing learning all the time is a form of continuous slack. If the team feels that they cannot deliver something by an important date, he can join the mob to help them.

There’s even more to this learning. It can be about anything. Developers work on their technical skills, but they also learn about the domain. Little by little this turns them into domain experts. Guess what : domain experts are great at optimizing value !

πŸ’‘ With time and efforts, developers can become domain experts !

Afterthoughts

Unfortunately, there is no easy way to prove the long term productivity of XP. We cannot split the world to run the same project with and without XP. Another difficulty is that after a years of XP, work remains smooth and sustainable. Nothing like crunch mode. People used to the hero culture are hard to convince that they can be more productive by doing less.

Hopefully, lean theory and gut feeling of programmers who have switched to XP can back up my claims.