Probe Freely with a Problem-Centered Approach

The last post described how most transformation or change programs are planned around the facets of change. It explained why it might be better to consider a problem-centered approach. We’ll explore a real example in this post. Details specific to the situation are changed or omitted to respect client confidentiality.?

Motivated Assessments

Just over a decade ago, I led an effort to assess the “agile delivery” capability of a set of teams at a big, industrial safety and automation company. These kinds of assessments were popular in those days. A VP of engineering at the client had called for it. Despite following Scrum, his teams were struggling with repeated delays in software release due to the discovery of many high-severity defects close to the release date. It is important to take this motivation into account during assessment. The typical approach to assessment does not do this.

Cookie-Cutter Assessments

The usual approach to an agile delivery assessment is to assess its facets—process and engineering—and their sub-facets. In terms of processes, we might assess the work-intake process, the requirements elaboration process, and the continuous improvement process, for example. In terms of engineering, we might assess coding and testing practices, continuous integration practices, and automation maturity, for example. We might rate each facet on a scale of one to five with recommendations for improvement. This is a classic facet-centered approach and although it has its uses, it tends to lose sight of the problems (or symptoms)? that led to the call for the assessment in the first place.

If all we do is to come up with recommendations based on a facet-centered assessment, the original problem might still be unaddressed or addressed only partially.?

Probe Freely

On the other hand, when we take a problem-centered approach, we are not limited by any predefined facets. We go where the problem takes us. That’s what we did with the problem of late-stage defects. We did not restrict ourselves to engineering and process issues.

We started by asking if system testing and end-to-end testing could be brought forward. When we encountered resistance, we probed further. It was like a root-cause analysis along multiple branches of the problem we started with except that we didn’t believe in a solitary root cause. This approach opened up a rich vein of dysfunctions, common to the classic enterprise of the time, comprising aspects of their org design, work norms, capabilities, and ways of working.?

The curious case of too many late-stage defects

For details of what we uncovered, please check out this video . I’ve spoken about this case in a couple of forums because it is a great example of how a problem-centered approach uncovers issues that might otherwise seem irrelevant to the scope of the assessment. For true change to occur, it is necessary to deal with all the issues we encounter. But that’s easier said than done because the issues might be outside the remit of the person authorizing the assessment.

When we shared the full scope of our findings, the VP said I had exceeded my brief by venturing into areas outside the scope of Scrum! Initially, I was surprised by his reaction. Wasn’t he interested in addressing all the factors that were contributing to the situation? But then I realized that he did not want to take to his boss a report that had findings and recommendations beyond his pay grade.?

Nonetheless, our findings served to temper his expectations. He realized that things would only improve so much by focusing on behavior change within his teams. And that's useful learning for transformation or other change efforts.

But what about the other issues uncovered by our probe? It doesn’t make sense to simply set them aside because they are “out of scope”. How to exploit the full power of a problem-centered approach? That’s a topic for the next post.

Until next time, take care and prosper.

Sriram

agileorgdesign.com