Not Seeing the Big Picture

Fair warning: the next person who shows me a pretty process picture and says, "See?  This is how you're supposed to work!" is going to get punched in the nose.  Or better yet, I'm going to sign them up for a visit from Cranky, the junk-punching elf (and if that isn't a service yet, I have a great startup idea for someone).

You've been warned.

It's not that I don't like a good process discussion; looking for better ways to build things is a good portion of my job, after all.  And it's not that I don't see the value in a good graphic.  Building software is an abstract process, and a good picture or analogy is a great way to take the abstract and make it real.  I understand these things and I value them, and yet I still have a visceral response every time someone trots out "The Agile Enterprise" pictograms or sends me their "Kanban Supply Chain in a Box" schematics.  At one point in my career, these pictures educated me. For a while after that, they amused me.  Now, they just irritate me.

I know this isn't an entirely reasonable response, but I'm not sure I care anymore.  I've spent the past twenty years listening to people tell me how my organization should work.  Heck, many times I've been the person with the pretty picture, telling other people the right way to do things, so I'm not innocent.  My hands are stained red with dry erase marker just like the next "expert's."  These pictures aren't even wrong, as far as they go.

Here's what bothers me: the pictures and the experts aren't wrong, but neither are they helpful.  At the high level, the only thing that's changed in the last twenty years is the naming convention.  I look at a "Scaled Agile Framework" picture today and I think, "Add a few gates and replace some of those bobblehead images with committees, and you've got the Phase Gate model that everyone was using at Fidelity 10 years ago.  Or wait, did someone just paste a few copies of the Staged Delivery model that I built at ATG in the 90s?  Maybe this is just a scaled-up version of the Department of Defense's general contractor process with different labels."  For someone who has spent 20 years trying to do things better, this can be frustrating.  When the pitch is coming from the mouth of someone who was still trying to figure out how to buy beer when I was already building e-commerce products, it's maddening.

Here's the deal, folks: we can relabel it, we can rearrange the parts, we can even apply exciting verbs, clever adjectives, and trendy nouns to the process, but work is still work.  No amount of marketing is going to make that go away.  There's a basic order of operations to building new things, a Generalized Theory of Productivity with laws that can't be broken, no matter how much you might wish to, and our lives would be a lot simpler if we all agreed to stop arguing about them and get back to work.

Allow me to elucidate (sans pictures):

1. You have to know what you want to build before you can build it.
Over the years, I've regularly had this conversation with people on my team:

Them: [Insert name of Agile expert here] says that we should be prototyping already.  Functional code is better than documentation.  All this sitting around and talking is wasting time and reducing our productivity.
Me: OK, what are you building?
Them: I don't know.
Me: An online payment app?  A business rules engine?  The Pyramids?
Them: Maybe I should go talk to my Product Owner.
Me: Good idea.

We want to skip steps, and we've been told that the old way of doing things, where everyone sat in requirements meetings for months on end, was wrong.  It was inefficient, and I'm glad that we don't operate on the theory that you have to be omniscient and cover every single possibility before you write a single line of code, but it also recognized this fundamental law.  If you run off into the woods without knowing where you want to go, you're more likely to be eaten by a bear than to stumble into a gold mine.  A little planning goes a long way.

2. You have to build something before you can test it, and when you don't test, bad things happen.
Another conversation:

Agitated Scrum Master: Why is QA always behind?
Me: Um, is the code done yet?
ASM: No.
Me:  I think I might have an idea...

In the old days, when PMBOK ruled the world, everyone had to wait until all the development was done, then everyone watched while the Quality Assurance team tested that code, then they told the developers whether it worked or not.  Much like those massive requirements sessions, we all hated this hurry-up-and-wait model, so we came up with something different.  We organized into sprints, and we broke those long phases into smaller ones.  Then we decided that sprints took too long, so we moved to Kanban.  Then we decided that waiting for someone else to test something before we knew if it worked was stupid, so we came up with Test-Driven Development.  Then we decided that testing things ourselves was inefficient, so we decided to Test In Production (yes, that's a thing: look it up) and let our clients find the bugs for us.

By themselves, none of these ideas are wrong (well, maybe Testing in Production), and if any of these practices help teams produce higher quality code earlier in the development lifecycle, that's great.  What they don't do is eliminate the need to check your work.  Testing isn't as fun as building, and building a high-quality product takes a lot longer than building a crappy one, no matter how you try to rearrange the work, but the end result is usually worth it.  It would be nice if more people realized this before their customers got their hands on the product.

Let me put it this way: if I sold you a house and said, "I haven't seen it, no one has stepped inside since the builders left, and we've had nothing but good weather since then.  The contractor seems like a smart guy, though, so I'm sure it's beautiful and will last you a lifetime," would you buy?  And yet I regularly see Agile process pictures with no mention of testing and I talk to people who believe that, if everyone is careful, quality is a given.  I'm not buying that.

3. Processes are clean.  People are messy.
We're getting close to the heart of the matter now, and starting to see why I've just about given up on the process gurus.  When it comes down to it, most people aren't motivated by pretty pictures, and those who are motivated by them frequently aren't terribly useful in real life.  People are more complex than those bobbleheads on the chart: they have their own motivations, their own strengths and weaknesses, and -- God help them -- their own ideas about the best way to do things.  They're messy, and they'll keep screwing up your pretty process.

I spent years struggling with this fact.  For at least the first decade of my working career, I was angry at the morons who couldn't understand why they should just do what I told them to do if they wanted to be happy.  People who showed every other sign of being intelligent beings became complete dunderheads with respect to my processes and methodologies.  When my process said, "Go left," they veered right.  When it said, "Stop here and wait for the others to catch up," they rushed ahead and messed everything up.  I suspect that Joseph Stalin had similar feelings; the difference between me and him is that he had more power and I eventually learned better.

I see other people go through this all the time.  They thrash around and get angry, they lecture their teams, they draw more pictures and point at them emphatically, then they storm off into the sunset.  Like Young Me, they're missing the point:

A leader doesn't point out an ideal path and then tell his people to walk down it.  A leader finds the right path for his people and then leads them down it.

The right process is the one that works for your team today, whether you've done it before or not.  That process needs to build on their strengths and account for their weaknesses, and you need to give them the grace to fumble through changes.  If the team is getting things done, then the process is right.  If the team is non-functional, then it doesn't really matter how pretty the process looks on the wall.

4. The details matter.
And now we have arrived.  My biggest complaint about the pretty pictures is that, in the end, they give me very little to work with until I bring them into my reality.  At 50,000 feet, all processes look pretty much the same: same sequence of events, same general skill sets, same chance of being correct in some way.  When you come down to earth, though, things get messy.  My organization can't adopt that practice because we have security restrictions that make it impossible.  Your team doesn't have that skill set, so unless you hire it or someone does a lot of reading you can't arrange people that way.  My clients are surprisingly uncomfortable with the idea of changing mission-critical systems without allowing them to preview the changes.  We tried that practice last year and it didn't work, so everyone hates it now.

Until you understand these details you can't make anything work, and you ignore them at your own risk.  Unless you account for the environment, no process is perfect, and many are downright dangerous.  To return to the house analogy, you'd be pretty stupid to build an open-sided grass hut in the middle of Antarctica, but I see people do the equivalent in their businesses all the time.  That methodology that worked amazingly well for the social media company that lived in "perpetual beta" until they were purchased by Google may not be the best idea for the bank that's handling sensitive financial information.  Your approach for managing a team of 5 people might not scale to an organization of 105, and insisting that any approach other than yours is "old thinking" might just be insulting to the other 104 people.

Details matter.  Environment matters.  Until your "best practice" fits in my world, it's just someone else's good idea.

So should we give up on change?  To quote the Apostle Paul: by no means!  Continuous improvement is essential to success in life as well as business, and learning from the experience of others is a far more efficient path to improvement than making all of the same mistakes yourself.  Just don't try to make their experience a replacement for your own.  Don't tell me how someone else said to do something, tell me how you're going to do it now. Use your own judgment, test ideas within the framework of your own environment, and recognize that there are no shortcuts to success.

If it would help, I could draw you a picture....


Top Posts

The Giving Season

Do You Really Want to Be CTO?

Announcing Da Primus Consulting