A recent discussion got me thinking about how governance (assuring regulatory compliance, etc.) fits in with “Agile” delivery methods. We were discussing how to advise a client about where to apply agile approaches and why. When the subject of governance came around, someone tossed out a statement along the lines of, “Well, that’s just like waterfall, so there’s nothing to do there.”
The statement took me aback. I asked for clarification. The reasoning was that governance requirements are predefined and fixed, while agile methods are based on collaboration and feedback loops to discover stakeholder needs and to steer work in progress toward the best outcome.
This internally-consistent argument spurred a realization:
People don’t necessarily connect dots that lie outside their sphere of expertise.
Three Aspects of Agility
On re-reading that last sentence, it strikes me as a bit cryptic. No doubt it’s even more cryptic for someone who didn’t write it five seconds ago. So, let’s break it down.
I’ve long thought about “Agile” as touching on three broad areas or aspects:
Some Agilists focus strongly on the human aspect of Agility.
When you hear/read people using terms like safety, heart, and collaboration, they’re considering this aspect of agility.
Some Agilists focus strongly on the process-related side of Agility.
When you hear/read people using terms like prioritized product backlog, empirical forecasting, and rolling-wave planning, they’re considering this aspect of agility.
Others Agilists focus strongly on the technical elements of Agility.
When you hear/read people using terms like software craftsmanship, test-driven development, and built-in quality, they’re considering this aspect of agility.
It can be challenging to see how elements from one of these broad categories may connect with, reinforce, or enable elements in the other categories, when one’s personal expertise lies mainly in one of the three. That’s what I mean by connecting dots from outside one’s sphere of expertise.
Enter Lean Thinking
Lean thinking has become so fused with Agile thinking that I sometimes forget the origin of various ideas. The assumption that we want to eliminate wait states and bottlnecks from our software delivery process has become so natural for me that I forget it isn’t fundamentally part of “Agile” (except indirectly as an effect of forming cross-functional teams). It’s a notion that comes from the Lean school of thought.
Lean ideas are a natural fit for the goal of increasing Agility. Reducing delay in the delivery pipeline (a lean notion) naturally has the effect of shortening the feedback loop (an agile notion) between the consumers and producer of the software. So, when considering how to help a client increase Agility, I automatically think about reducing delay in their delivery pipeline.
Compliance Checking and Automation
Coming from a technical background, it’s easy to see how one could automate the checking of governance requirements as a way to minimize the amount of time spent in after-the-fact manual review by human experts. But someone who approaches agility from a process-focused background might not see that connection intuitively. The fact that governance requirements are fixed might cause him/her to assume such requirements must be handled “the same” as in a waterfall process.
For a technical person, any “fixed” requirements are potentially candidates for automation. Anything that doesn’t require collaboration and feedback for steering and adjustment may potentially be scripted, because it doesn’t change frequently. Anything that is scripted will flow more smoothly than something requiring manual intervention of any kind, be it manual server provisioning, manual regression testing, or manual auditing of a proposed release for compliance.
It may be useful to consider automation for more than the most obvious things. It may also be useful to learn to connect dots that are farther away from each other than we usually do.