Agile Teams Challenge Corporate Assumptions: Part 1

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.

Coaching Birds, Bats, and Squirrels from the House

Ever Had a Client Stuck in a Nasty Situation?
Ever Had a Bird Trapped in Your House?

I’ve had both. In both cases, I learned not to mess up in the following way: trying to grab the bird and toss it out of the house. Birds hate that, and are really skillful at resisting the attempt. You or the bird can also get badly injured that way.

As a Shu-level, novice coach, I did the classic wrong-headed stuff, and still work hard to resist temptations to do the same stuff: pushing, pulling, badgering the client from a bad situation to a good one. It really is like chasing a bird around the house, brandishing a tennis racket. (Note to self: No!)

Releasing Attachment to the Outcome

We cannot truly control whether, indeed, the bird leaves the house, much less how fast or how well. There are no shortcuts for us or the bird. We can, however, strongly influence how the whole thing unfolds.

It really does have to be the bird’s idea to leave the house, if it will ever in fact happen. This may take a few seconds, a few minutes, a few hours (a few weeks! a few months!  a few years!). Take your time.

Those of us who have (as I have) released birds, bats, and squirrels from the house have learned (A) how to open and close doors, and leave seed trails, in a way that invites the unhappy bird or squirrel out of the house; and (B) patience. With one bat, who flew along walls at 2″ from the wall, straight to each corner, then turned an abrupt 90-degree turn at the next corner, over and over, in perfect silence, it really took awhile. That bat took 30 minutes to notice that there was a door open along one of those walls (if the door had opened in, instead of out, it might have taken 1 minute).

When he finally flew through it, I pounced up and shut that door, preventing regression. I had been sitting there, drinking a beer, and tracking him as he flew these perfectly rectangular room circuits (not easy: bats indoors are flying about as fast as your neck muscles will allow your head to pivot).

Once he had found that first door, he seemed to sense that other open doors were good things, and flew straight through the remaining rooms out to freedom, bugs, and no doubt a well-earned nap. In classic coaching fashion, I had reached that tipping point where I had won enough trust to say goodbye.

Close Some Doors, Open Others

If you close doors to the inner part of the house (example: removing folks from their cubes and placing them in open workspaces, or not engaging in thermonuclear email exchanges about the New Agile Initiative),  you can invite clients to not worsen their situation.

If you open other doors and windows to the great agile outdoors, you invite clients to try inviting, healthy, addictively fun, cool new things (example: tweaking the card wall to reveal blockages or gaps in value flow; helping clients write their first few storytests).

Asking Gently Provocative Questions: Opening Windows in the Mind

By this, I don’t mean “Where the hell are all of your unit tests”?  (BTW, you know the question I REALLY don’t mean?  It’s this one:  ”Don’t you realize testability is vastly more crucial than encapsulation, you dolt?”)

I mean, instead, questions like “Has Rob paired with Lily recently?”  or “How did method-level cyclomatic complexity change this past iteration?”  or “How do you think that business verification went?” or “What do you think about the size of that test?” or “What do you think of that class name?” or “Did we see this retrospective improvement item in the last retrospective?” or “What do you really enjoy doing most on the team?”

If the Bird Blogs About How Cleverly I Let Him Out of the House,
I Probably Messed Up

The best of my personal coaches model for me, and counsel to me, the art of the client never discovering that the great idea was not originally theirs. Smart subordinates have been leading their managers from below in this fashion since the dawn of command and control, no doubt.

Not only is it OK, in a coaching position, to be a peer-to-peer influencer, as opposed to a top-down manager, it is typically preferable. People who I coach end up taking leaps of faith and trying scary new things, in good faith, not because anyone, including me, commands them to do them, or to try them. They do so because they trust me, like me, respect me, and happen to have had this cool idea pop spontaneously into their heads, unbidden.

The coaches I most respect, and most seek to work with, are those who help me as I refine my Ha and Ri in this coaching by question, coaching by seed trail, coaching by patient, engaged, gently provocative observation.

If you see me badgering someone to just shut up and do this Super Advanced Best Agile Practice Thing, please bust me on it. I will likely thank you (eventually, anyway).