Let's talk mental models. The biggest one we have in IT.
In the broad system of IT management, we often hear of three stages, “Plan/Build/Run.” We make plans for a new IT system, we construct it, and we run it.
IT organizations often structure themselves and communicate to a large degree along these lines. I’ve used them myself in any number of writings. However, I have come to question the usefulness of “Plan-Build-Run” (which I’ll abbreviate PBR) as a mental model for understanding and guiding IT management.
While it pervades IT management thinking, and can clearly be seen in the structures of frameworks like ITIL and COBIT, PBR is ill suited for the demands of 21st century IT management. I believe it is fundamentally a statement of waterfall thinking.
The major structures of Plan, Build, Run in my experience are framed as discrete, mutually exclusive states, with interfaces (information exchanges and control signalling) in between them. The model reflects IT's history of project-centric management, in which large batches of work are moved across those three phases. Since each large batch is fragile and the state transitions are risky and high ceremony, there is also concern for insulating each batch from outside "interference."
This results in systems being built in isolation from one another and without openness to feedback from later stages or other batches of work. Thus we also lose opportunities to learn from mistakes, leverage shared services and ensure architectural consistency across the IT estate.
Continuous improvement cannot be an afterthought. Yet when PBR is the fundamental model, continuous improvement activities are run as spreadsheet-driven initiatives, poorly resourced and in constant contention with the "real" work of Plan, Build, Run. (The classic example is the massive spreadsheet of Audit findings which becomes a political football in The Phoenix Project. Note that I advocate for a broad definition of continuous improvement.) I'd suggest these kinds of approaches are essentially "inspecting quality in" and therefore not what Deming would have wanted. ("We cannot rely on mass inspection to improve quality.")
Finally, is PBR the reflection of your organization's communication structures? Conway's Law would suggest that PBR is the reflection of embedded organizational communications structures - dating I would argue from the time of Frederick Taylor and the worst excesses of hierarchical, command and control management philosophy.
This is probably the most pernicious consequence - specialists in planning, building, and running, all trying to optimize their worlds, with the "planners" at the top, the "builders" in the middle and the "runners" taking orders at the bottom. The trouble is that this idealized hierarchical model is utterly ineffective. It certainly doesn't reflect military principles, often caricatured as "command and control" (see Reinertsen's discussion of military doctrine on decentralized control in Principles of Product Development Flow). Effective product and software development has also long eschewed it; much evidence demonstrates the futility of relying on "expert" opinion and planning in truly complex domains. (See this excellent discussion from a venture capitalist at Y-Combinator.)
Concepts like Lean Startup experimentation, generalizing specialists, and empowered 2-pizza product teams do not seem to reflect a PBR model. In an Agile world, the work boundaries blur across these phases. Those who plan, also build and run, and the primary planning of worth is planning the next experiment for testing.
Some will say this is unfair. One hears various responses:
- Iterate (with increasing speed), either the whole cycle or subsets
- Insert feedback loops.
- See the stages as overlapping
My question is, even with these enhancements, is this mental model the best foundation?
Let's look at the "fast PBR" response a bit more. Agile and Lean Startup arguably would call for many cycles of PBR, with each cycle constituting a test, or a story, or some other small grained delivery. Increasing the speed of this cycle is a widespread theme in discussions of Agile, DevOps, Continuous Delivery, and the rest.
Now if you are going to "spin it faster," a circular illustration would seem more appropriate:
But what happens when we spin this fast? Remember your elementary physics of color? It all blends together, just as we see boundaries blurring today between Dev and Ops:
And when the phases blur, what emerges? That's the question...
Now, I should say... IF YOU ARE LUCKY it all blends together. This assumes that you have somehow overcome the transactional overhead with those state transitions, information exchanges, and organizational handoffs, as you attempt to speed them up.
What if a given state change isn't needed for a particular cycle? You wind up fighting a system hard-wired to protect the role of each activity (and all their sub-activities). You wind up asking to "tailor" methodologies, to exempt your work from activities that are clearly non-value-add, and so forth.
Accelerating PBR isn't sufficient; it is still a sequential process with discrete steps and implications of information and control flow betwen each, reinforcing a dysfunctional division of organizational responsibilities. Can you get up to speed if people are trying to "optimize" the "plan," "build," or "run" phase independently? How can you optimize one third of a wheel?
I ask: is PBR how work really gets done? How value gets delivered? If it is how work gets done in your organization, how effective is it? If you are fortunate to be working in an organization using Agile approaches, can you in truth characterize them as simply "fast PBR"? Does this mental model fundamentally inform your daily experience?
I think "spin it faster" is an insufficient response. A continuous flow is needed. Go back to the blended circle above. We'll pick up there on the next post.