How Behavior-Driven Development (BDD) Helps You Overcome Muri, Mura and Muda

I am a huge fan of Toyota when it comes to process and lean manufacturing. They invented and brought in many of the lean production processes, which were then adopted by many other car manufacturing companies across the world. One of the key goals of the Toyota Production System (TPS) is eliminating 3 key issues: Muda, Muri, and Mura. Identifying and removing Muda, Muri, and Mura is principal to lean manufacturing—and the same philosophy can be applied to create a lean process for software development. Before going through each one in more detail, let’s look at what these Japanese words Muda, Muri and Mura stands for.

Muda (Waste). In TPS, any process or activities that don’t add value is Muda.

Mura (Unevenness) is caused when standards are nonexistent or are not followed. 

Muri (Overburden) is any processes that are overly difficult to implement, thereby overburdening the resources.

Muda, Mura and Muri in Software Development

Let’s look at Muda, Mura and Muri and how they affect software development—and what can be done to reduce or eliminate them.

Muda – Waste

Mura (Unevenness)

Muri (Overburden)

They key, of course, is to remove Muda (Waste) and Muri (Overburden) is Mura (Unevenness or Standard). So, in terms of implementation, the order should be:

1. Mura (Unevenness): First, implement an efficient standard to bring evenness, which will in turn reduce or remove Mura.
2. Muri (Overburden): An effective standard relieves some of the team’s burden.
3. Muda (Waste): When Mura and Muri are eliminated, then the team should work effectively and relentlessly to reduce waste.

Though the primary goal for any team is to reduce Muda (waste) and Muri (Overburden), it can’t be achieved without implementing a proper solution to reduce Mura (Unevenness). And Mura can be reduced by rolling out an effective standard.

When rolling out behavior-driven development (BDD) effectively, you are basically reducing or eliminating Mura (Unevenness) in the development process. With the evenness of BDD, the team will significantly reduce Mura (Overburden) and will eventually see a reduction in Muda (Waste).

Before we look at how behavior-driven development, when properly rolled out, reduces Mura, let’s look at how a poorly rolled out BDD process impacts the project.

Inefficient Behavior Driven Development

Many teams consider behavior-driven development an automation technique or tool. Though automation might reduce the overburden (Muri) of the team to an extent, not rolling out an effective BDD process will still have produce a significant amount of Muri (Overburden) and Muda (Waste).

Since the user story and the scenarios derived as part of BDD are in a ubiquitous language, it can be interpreted differently by different members of the team. And to make things worse, the understanding of this ubiquitous language will vary based on the reader’s experience, background, nationality, and their culture. Without a strong collaboration technique, it would be difficult to address this issue. Let’s look at a couple of real-world scenarios I experienced myself and how, without a standard process, BDD didn’t work as effectively as it would have.

I have worked on projects where BDD was purely used as an automation tool. Typically, in those scenarios, I found the team was always stressed, overworking, and ended up delivering projects with poor quality. The reason? The teams were simply not on the same page. The understanding of the story by the developer, QA, and the Product Owner/BA varied. Though the scenarios were derived from a given user story, when different cross-functional team members (i.e., Dev, QA and BA) completed their tasks and came together, they all had a different understanding of the scenarios. This overburdened the team, as they often had to retrofit the code at the last moment to align their differences. This also produced a lot of wasteful code/scenarios—or even sometimes unnecessary functions, which were of no use to the end user.

I have also worked on projects where the developer and QA collaborated well; however, the BA/Product Owner was not part of the collaboration process. Though the team came up with scenarios that addressed the requirements, when the team completed their implementation, the BA/Product Owner didn’t agree to the implemented solution. In other words, the key to rolling out BDD successfully is to establish a technique such that the various members of the team, mainly the three amigos, are on the same page.

To realize the true benefits of behavior-driven development, the right process must be rolled out. Let’s look at how BDD should be rolled out and a few things to consider.

Efficient Behavior Driven Development

If I had to list the top three things to consider when rolling out BDD, it would be “collaboration, collaboration, and collaboration.” Collaboration is the cornerstone of a successful software development process. Through effective and standardized collaboration techniques, the team will understand the requirements better, the scenarios that the team derives from the requirements will be relevant and effective, and most importantly, it will put the entire team—technical or non-technical members—on the same page. Collaborating effectively also improves test coverage and paves the way for stronger test automation.

So, in terms of rolling out BDD effectively, the team should consider the following in the order it is given:

1. Collaborate to derive scenarios.
2. Define scenarios and agree with the entire team (these scenarios serve as specifications the team should adhere to).
3. Automate the agreed scenarios (i.e., execute the agreed specifications).

The first two points are quite subjective. Unless a standard process gets rolled out, it would be hard to improve efficiency, as collaboration means different things to different people. I have used a technique, called OOPSI, in many projects that drastically improved the efficiency of the collaboration and unearthed several scenarios that otherwise wouldn’t have been possible. I cover this technique at a later point in this blog.

Let’s look at how BDD can be effectively rolled out to reduce Mura (Unevenness), which will result in reducing Muri (Overburden) and Muda (Waste).

Removing Mura (Unevenness)

Mura is inconsistency in business operations caused by unevenness in production and services. It is also caused when standards are nonexistent or are not followed properly. 

In software development, the lack of a standard in user story analysis leads to implementing either unwanted features or implementing a solution that doesn’t meet the requirements. In a traditional software development practice that doesn’t follow BDD, there may or may not be a process for cross-functional team members to analyze the user stories/requirements. This lack of a standard process will probably mean inconsistent practices by the team, which in turn means the team will either understand the requirements differently or fail to understand them at all.

When cross-functional team members (particularly the three amigos) don’t collaborate to understand the story, each member of the team understands the requirement differently. This usually puts the burden on the team as the team finds the issue(s) later on in the development life cycle, either during the demo or during one of the test cycles—or even worse, when the system goes live. The later in the software cycle the issues are found, the higher the cost and higher the pressure on the team to fix the issue, which usually overburdens (Muri) the team. This might also result in giving rise to unnecessary bugs or features being rolled out, giving rise to waste (Muda).

Merely implementing BDD isn’t enough without the team adopting a standard process to collaborate to derive scenarios. When implementing BDD properly, the team should start with collaboration and use collaborative techniques such as OOPSI to derive scenarios. The scenarios should be understood by both technical and non-technical members of the team. The team members involved in rolling out a solution should agree to these scenarios and should be on the same page. The operative phrase here is “In Agreement.” Techniques like OOPSI, for every user story/requirement that gets developed, offer a standard to the process. When a standard is followed by all the team members, it removes any unevenness (Mura) that otherwise might increase Muri (Overburden) and Muda (waste).

Having a structured collaboration technique like OOPSI is important to attain the benefits of rolling out behavior-driven development. I have personally used OOPSI in many projects and found it to be very effective. The following section gives a brief overview of OOPSI. You can read more about OOPSI here.

OOPSI

OOPSI was introduced by Jenny Martin and Pete Buckney. OOPSI stands for:
O – Outcome
O – Output
P – Process
S – Scenario
I – Input

When a user story or a requirement is analyzed, the team collaborates and derives an answer for each of the letters in the acronym above. By using a technique like this to derive scenarios, waste is reduced up-front: the team will understand and document what is required and what is not. Since BDD allows the team to define the requirements as real-world scenarios in a common language understood by all members of the team—technical or non-technical—it reduces any ambiguities in the requirements. This results in either reducing or removing bugs and unnecessary functionalities.

Rolling out a strong process not only reduces Mura (Unevenness)—it will also reduce Muri (Overburden) significantly. To get the maximum benefit of using BDD, always use a technique like OOPSI to roll out a structured collaboration, derive ubiquitous scenarios that are derived and agreed upon by the entire team, and then automate.

Removing Muri (Overburden)

In TPS, Muri is the result of tasks or processes that are overly difficult or ones that overburden workers. This is mostly generated when workers lack proper training, have no standards to follow, or are given the wrong tools for the job.

When it comes to resources in software development, Muri increases mainly for the following three reasons:

• Lack of standard
• Lack of collaboration
• Lack of test automation

Behavior-driven development addresses all the above when implemented correctly. Some teams implement BDD as an automation tool and might come to a conclusion that they have reduced or eliminated Muri—but this wouldn’t be the case. When the team implements a user story without collaborating with cross members of the team up front, deriving scenarios in the silo, and implementing automation test scripts, the team might end up:

1. Implementing the wrong solution
2. Implementing a solution with bugs
3. Implementing a solution with functionalities that are not required

When the above three issues are not accounted for, the team will always feel overburdened, as they have to constantly work on reimplementing their solution. These issues could be greatly reduced or avoided altogether if the team starts with a structured collaboration, derives scenarios collectively in a ubiquitous language, and agrees with the entire team.

To give a real-world example, I worked on a project in which one of the user stories had the following Acceptance Criteria:

Acceptance Criteria: When an endpoint is not available then the message should be sent to an Error Q

The endpoint is a static value and was defined in a configuration file. To test the above Acceptance Criteria, the QA involved in the project came up with a scenario to test the application when the configuration file gets deleted or the endpoint in the configuration file gets missed. It was an excellent scenario to consider; however, during our collaboration process, the BA and the architect confirmed that the scenario is unlikely to happen as the configuration was defined through a different application, and they had a separate scenario to make sure it was always available. Without a strong collaboration process, this would have never been discussed and the QA would have, rightly, spent all their time testing the scenario. With the way the application was defined, it wouldn’t have been an easy scenario to test, so lot more time would have been spent on it.

Even when a team collaborates well and collectively derives scenarios in a ubiquitous language but decides to go with manual testing instead of automation tests, the team will still be overburdened. For every user story, the team will not only testing the scenarios manually, they need to manually do all regression testing to make sure none of the previously implemented stories is impacted because of the code change. For every user story that gets implemented, the regression test (i.e., testing all the previously implemented stories) for the team will exponentially scale up, increasing Muri (Overburden).

Removing Muda (Waste) in Software Development

Rolling out a collaborative technique (like OOPSI) as part of behavior-driven development will enable a higher degree of collaboration, resulting in a product with unnecessary bugs and features (i.e., Muda). By not implementing BDDs properly and focusing only on automation, Muda builds up—in other words, the team will end up developing unnecessary functionalities or functionalities with bugs. Unnecessary functionalities, of course, have a high cost.

As we’ve seen, rolling out a strong collaboration process (i.e., Mura) is the cornerstone of rolling out a BDD process that reduces Muri (Overburden) and Mura (Waste).