Mura
inconsistency and unevenness
The English concepts of unevenness, irregularity, inconsistency, inequality and lack of uniformity all somehow fit in the Japanese concept of Mura. Fostering a cross-functional team is an aspirational practice intended to mitigate the kind of Mura that results when work is siloed by skill specialty. The ability to more evenly distribute the work improves throughput and team cohesion.
Cross Functional Teams
There was a time when the term full stack developer meant someone who knew everything about building a website. Now it’s just one of those things people say because it sounds good, but the stack has become too complex for one person to master it all. Specialization is needed for efficient realization of compound designs, but it introduces fragmentation as one story gets split along functional lines.
The siloing of technical skills manifest as inequality, when work gets blocked because of the different capacities of various team members. It manifests as inconsistency when there are integration issues arising from bringing together independently developed tasks of the same story. It manifests as unevenness when bugs result from a variety of different solutions for essentially the same problem.
Classifying our observations gives us the context to reason about the knotty problem of how to allocate work considering the technical skill distribution of the team, and what steps we might take to break down silos.
DevOps started as a movement to break down the barriers between dev and ops teams, to reduce problems attributable to the siloing of work by technical skills, as popularized by the novel “The Phoenix Project”.
Deming wrote about the problem in Quality, Productivity and Competitive Position:
Break down barriers between staff areas. People in research, design, purchase of materials, sales, receipt of incoming materials, must learn about the problems encountered with various materials and specifications in production and assembly. Otherwise, there will be losses in production from necessity for rework caused by attempts to use materials unsuited to the purpose.
— W. Edwards Deming
The Overloaded Namespace of DevOps
The term DevOps has been recast from the original meaning to refer to build automation and the skills useful for that purpose. The original intention as developed in “The Phoenix Project” has been superseded, although not because the problem of siloed Dev and Ops efforts has been resolved. Jez Humble’s rant provides good context on the unfortunate overloading of the DevOps namespace.
There’s no such thing as a DevOps Team
— Jez Humble
Consistency and Build Automation
DevOps in the build automation context is another aspirational practice that targets the problem of unevenness, irregularity, inconsistency, and lack of uniformity in software deployment activities. That practice area grew out of the recognition that inconsistency in software development is expensive.
It might not seem like you’d have to encourage software engineers to automate the build process, but sometimes it’s like the case of the shoemaker’s children have no shoes. Devops is like making shoes for your kids first, so they don’t stub their toe when you need them to help you with a deployment.
Defects as an Indication of Mura
The cause of many defects is rooted in inconsistency. For example,
- defects result from taking an ad hoc approach where a protocol is available,,
- problems resulting from local dev environments being different from production,
- errors attributable to deploying to incorrectly deployed servers.
- intermittent failures in build tooling
We can’t learn from the time we spent on rework unless we have some idea of why:
- incorrect specification?
- a misunderstood specification?
- a sneaky change in the specification?
- an error in implementation?
- a missed edge case?
- a misunderstanding by the tester (no defect)?
- a missed integration issue?
- a deployment misconfiguration?
Or, more simply, an ambiguous definition of done.
Sorting out the root cause of process bugs by classifying and categorizing according to a taxonomy of waste clears the path to understanding what process changes might help avoid similar issues going forward. Time saved by ironing out Mura is time that can go into new work.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.