The Old Atomic Unit of Production: the Project

I came up in a software industry in which the atomic unit of production capacity was The Programmer. Programmers were largely assigned, as needed, to ephemeral entities called Projects. Yes, it had a Taylorist mechanistic undertone, and often still does.

Cut to scene: The Project Manager whisks into the Development Manager’s office and declaims, rather like a Hollywood casting director, “Well, you need to get us Joe and Terri for the Melathobner Project. We can’t do it without them. It just won’t work without them.”  (Lots of action films have the word “Project” right in the title!  Coincidence?  I think not.)

As a film crew comes together once, against tremendous odds fought by various producers and directors, to birth a film production, so have I seen most projects run. As if after this project, the world might end. As if after this project, we could all retire. As if deep down in their hearts, stakeholders and managers secretly believe this: “The idea that this project might actually make it out the door on-time, under-budget, with few defects?  That’s hilarious.”

Then, at miraculous Project conclusion, all cast and crew return to their structural silos (their true homes). Then off to the next Project. Emergency permeates the whole mechanism. Whoa!  This next Project might be the one that finally kills us all!

Project: Wrong Atomic Unit of Production?

Even if a product or system might persist for years, each of its major releases (sequels, in fact) is typically still a Project. Most software projects still have this one-time, heroic, desperate, fire-and-forget feel to it. This very narrow focus, this “goal obsession” on the part of project managers was recently described well here. Certainly there are Project Managers who are better than that, and focused more broadly on notions of business value flow, portfolio, market differentiation, team productivity, context switching costs. They are the exception, partly for reasons I cover below.

One or the root cause issues here is this: as an atomic unit of production, Projects can be inherently bad. And, as I’ll discuss later, fundamentally different than an alternative granule: the Release. First, let’s go to a military metaphor, which is always galvanizing.

Corporate Silos: 14th Century Italian Civil War Between City States

Meanwhile, what, in the context of software Projects, is the corporate atomic unit of budget authority, responsibility, and power? The structural silo. Ouch. We have somehow evolved default software development structure and process that seem to quietly mimic 14th Century Italian feudal warfare.

Our structural silos, under their various VPs and Directors, are capable of behaving like city states. People who report up through Architecture, Development, Production Deployjment/Support, DBAs, QA, Facilities, etc — are typically most loyal to their role and responsibility silos. How could they not be? That is how they have been incentivized and empowered. They represent abstract notions of “quality” and “architecture” and “programming,” divorced from the very real, complex, organic, end-to-end needs of the enterprise (or worse; more below).

None of these silos owns the proper flow of business value through the organization. You could say that our corporate Italy has insufficient representation and incentive for its larger, nation-sized concerns. It’s OK with our corporate Firenza if Italia perishes, as nonsensical as that seems at first blush.

None of the city states owns whether we are reducing costs and increasing revenues for the entire enterprise. Indeed, I have frequently seen these city states incentivized to combat cost reduction and revenue increase, in order to gather more resources and power to themselves. QA is incentivized to find bugs, and find them they do; their weapon of choice: the bug report system. Architecture is incentivized to represent the bigger picture, the technology future; their weapons of choice: Visio and PowerPoint. And so on. It’s a fabulous buck-passing machine at best and, (segue alert! New metaphor) at worst, as if some corporate departments are like parasites feeding on the enterprise as host organism.

Note that I am not saying that the enterprise does not need to address the concerns and skills and worldviews traditionally represented by architects, testers, production deployment and configuration experts, project managers, etc. I am not against all specialization.

But meanwhile, again and again, the Project Managers assemble these temporary Waterfall initiatives, using the best go-to condottieri (think “Ronin”) they can find, and lead them through Waterfall-phase silo-gauntlets, one at a time. As the project winds down, the temporary allegiances dissolve. Back everyone goes to their little city-state.

So, as I’ll discuss, what I increasingly question is the idea of empowering structural silos that represent sets of skills, concerns, and worldviews, using budgets, hiring authority, etc. If that’s how the money flows, into these little city states, I think you should expect your own little replay of the 14th Century Italian civil wars.

Voila, Disruptive Change:
The Agile Team as New Atomic Unit of Production Capacity

So we have this existing corporate socio-economic fabric: Projects being pushed, against powerful odds, through this fractured system of city states. Real business value is not created as a direct result of this fabric, but despite it. People strike backroom deals. A barter economy of favors breaks out. Grudges arise, and are repaid. It is, to my mind, more ugly than pretty.

And then along comes this notion of a self-organizing, empowered, cross-functional, high-discipline, highly-skilled Agile Team, as the new fundamental unit of production capacity. We’re going to mow down all these cube walls, bring all of these people in from their various city states, several of whom quietly loathe each other, and ask them to form a cohesive team. We’re going to ask them to sit with each other, deliver measurable business value in a steady flow together. Form, Norm, and Storm. We’re going to ask them to treat this new team space, not like a brief Project-scope visit to a kind of summer camp, but as their permanent home. We’re asking them to break their powerful, traditional allegiance to their city state. Remove that tattoo; forget that secret handshake. Even though that’s how their performance gets evaluated. That’s how they get paid. No wonder it so frequently looks like a bunch of Hippie Kumbaya.

No wonder the corporate anti-bodies swarm (oops, yes, another metaphor; should have warned you). No wonder the first several retrospectives feel like the teacher asking the class who put the thumbtack on her chair.

Yes, I am Over-Simplifying

To make a point, yes I am. The truth is, I have seen the above scenario more than once. The larger the organization I am working with, the worse it is, and the likelier it is to fight agility, and fight smooth business value flow.

But let’s at least find a common pattern language or metaphor set for this fundamental issue of “cultural change” in the enterprise. In future blog posts, which will be about how all the Hippy Kumbaya agile team culture can actually help the entire enterprise evolve in a way that results in true competitive advantage at the enterprise level, I’ll propose new terms and newish structure (not entirely my invention).

Meanwhile, though, here is my premise:

Your entire corporate socio-economic fabric might be fundamentally busted, seen through the lense of software development “Projects.” You might be recreating civil war in Italy in the 14th century. This might make a great film, but it could be a terrible context within which to try to optimize how the collaborative creation of software systems (be they products out in the market wild, or internal web services) increases your revenue, or decreases your expenses.