Maybe Van Halen lead singer David Lee Roth missed his real calling as a product leader. The world would have missed out on a lot of great music, but I actually think about Van Halen a lot when it comes to software process. You see, they came up with the “brown M&M test.” In the fine print of the rider for his contract, Van Halen stipulated that at every venue where they played, the venue must have a bowl of M&Ms in the green room with all of the brown variety removed. 

‍

Roth understood that adherence to a process predicts the output of the process. 

For a long time, this rider was assumed to be the epitome of “rock-star excess,” a wonderful example of prima donnas and their unreasonable demands. That’s where the genius came in. Rather than being an ego trip, the brown M&M demand served as a check on the thoughtfulness of the setup crew. Van Halen knew that if a particular venue cut corners on the agreed upon process (removing the brown M&Ms), they may have taken similar shortcuts with the wiring, pyrotechnics, or other dangerous features of the show putting the band or audience at risk. Because of this, finding a brown M&M would trigger the band’s crew to re-check all the work that had been done.

‍

By ensuring compliance on something that was easy to observe, they came with an easy way to predict their safety in a venue. They knew that the only way to predict the output of a process (ensuring the band’s safety) was to observe compliance with the process (made visible by the brown M&Ms.)

It’s not just Van Halen, though. In most places where the process output is critical or life threatening, process adherence is rigorously enforced. A pilot has a defined process before takeoff or landing that must be strictly followed or the pilot risks termination.

Similarly, surgeons have a very specific process by which they ensure cleanliness and sanitary conditions before operating. Deviation can lead to termination or even malpractice lawsuits. In these business processes, garbage in - garbage out is literally a matter of life and death.

It wasn’t always so. There were times in the past when plane crashes or death from infectious diseases were far more common. Because these are matters of life and death as a society we instituted controls and penalties for what happens when compliance doesn’t take place. We don’t enforce those controls because we particularly care about the process adherence per se. No one actually cares what order the pilot checks their gauges or a surgeon aligns their tools. We do this because we care very deeply about the outcome of the process and we know that the only way to ensure predictability of the output is to enforce compliance in the process.

Software development is a different animal, but like any other process, the outcome is predicted by compliance.

In the software development industry we have broadly coalesced around a number of tenets of software development. Generally speaking, we think that work should be done incrementally and iteratively (in sprints) and that the units of work (tasks) should be discrete, well defined, testable, and value creating often with an estimated amount of work or complexity (points.)

Like any business process, the first step to ensuring that your software development process creates software predictably is ensuring that your team understands and follows it. There is no such thing as an efficient and predictable process that isn’t being followed. 

The good news is that in software development, it’s particularly easy to understand whether a modern development process is being used, and actually being executed. Most software development is tracked inside a project management system (like Jira or Azure Devops.) Almost by definition, what happens in modern computerized business processes is equivalent to what takes place inside the system of record for that process. This is a big part of why process mining is so valuable, it allows you to see what’s actually happening inside the business process. It’s an easy way to find the brown M&Ms that signal other shortcuts that likely create issues.

By comparing the reality of what’s happening in the process (as defined by mining the events inside the system of record) with the expectations, you can easily identify and isolate process deviations that lead to reductions in predictability, efficiency or quality.

Let’s talk about this in the real world. I sometimes talk to software leaders who are skeptical that process mining will be useful on their data set “because there’s a garbage in, garbage out problem.” Their development teams cut lots of corners around documenting requirements, developing test cases or estimating the amount of work that will be needed to complete a task. Inevitably, the teams that skip the work around planning or testing in the name of speed end up with the work taking longer or with unexpected delays.

A team that isn’t keeping track of its work certainly makes it harder to calculate advanced analytics like velocity or cycle time. But, if there’s a “garbage in, garbage out” problem analyzing the process, the most important first step is making sure there’s a plan to remove the garbage.

The first step to improving the output of a process is to make sure that the process is followed.

A few really simple checks can give me a good high-level overview of the health of your process. 

• Are sprints started and stopped on a consistent basis with discrete and non-overlapping dates?
• Are tasks defined for a specific team?
• Do sprints contain tasks, and are all tasks associated with a single sprint?
• Are the requirements of a task and falsifiable tests of the task well understood?
• Do tasks spend reasonably predictable amounts of time in each stage of the process?
• Do tasks remain reasonably consistent once they are brought into a sprint and not subject to radical changes in scope or effort?

These sorts of questions can be easily spot-checked in a system of record at any point in time, and like the brown M&Ms can give you an easily visible heuristic to tell you whether your process is being followed and identify areas for further inspection. 

My inspiration for founding Bloomfilter came from observing the human impact of poor process adherence. Modern process mining platforms like Bloomfilter can observe not just what’s happening inside the process (how much output did we generate last week) but also the health of the process itself and the adherence to it.

Teams that follow processes consistently have far greater predictability and efficiency than those that wing it. You wouldn’t trust a pilot who wasn’t running their checklist. You wouldn’t trust a surgeon didn’t have a well-documented routine. Van Halen wouldn’t go onstage if the band found brown M&Ms backstage. Similarly, the first (and arguably most important) step to professionalizing the business process of software development is making sure that the agreed upon process is followed.