As a software leader or middle management cat herder, one is often driven to attempt a process improvement. The things, they’re happening too slowly, or without enough quality, or the wrong people are doing them. And so we propose a new process or a new tool. Maybe a miracle happens and everyone thanks you for this brilliant new way to do things — the process gets used, and then someone brings in a tool that makes it even better! And yet, speed and quality and ownership remain a little lower than desired. What’s worse, it’s more likely that the suggested process isn’t embraced or loved. Why not?
Imagine a three layer Tower of Hanoi. The largest bottom disk is people, the middle disk is process, and the smallest top disk is tools. You can’t build a stable tower by putting the disks in the wrong order. Another way to stretch this metaphor: if the disks are in the wrong order, someone has to personally act as the dowel in the middle holding everything steady. A correctly ordered set of disks stands on its own through gravity and inertia.
If the problem with current software delivery practice is really important to people, then the people will enforce a process, and then they will pick the tools that make that enforcement relatively painless. Acting as a member of the team, a manager might use their visibility into many process options and experience across many teams to propose process and tools that will fit with this team’s wishes and needs. Conversely, if the people don’t perceive a problem and agree that the process is an improvement, then the process won’t work, even if you schedule lots of meetings and buy some nice tools for it.
If software delivery practices are something that we wish was better but we’re not willing to change process, then we can keep wishing indefinitely without getting results. If you’d like to be better at guitar but you never practice, you will not become better at guitar.
It is not “wrong” to not practice at things you don’t want to attain. A software team should want to improve on some metric, be it velocity or quality or elegance or something else entirely. That same software team may have no desire to become masters of the agile scrum ceremonies. If they do, then they will need to add process and tools to their regular flow and practice towards the desired outcome. What really matters is that the team has the desire. Adding a manager-coach to harangue an unwilling team with process ceremonies will only produce short term results (if any), but that same person can be a great addition to the team that seeks to be better at thin-steel-thread feature delivery. Returning to our Tower of Hanoi toy, the manager-coach is the dowel in the center of the tower. They help a good structure but cannot sustain a bad one indefinitely.
George Sudarkoff wrote eloquently about this aspect of process change recently, noting that “when we try to change other people’s practices, we inadvertently question their values.”. Questioning people’s values might just produce confusion, but a perceived repeated pattern is rapidly going to lead to amygdala hijack and an emotional response.
Monkeynoodle.Org 