Processing, please wait.

Any development manager is bound to have a love-hate relationship with software process. On one hand, some things can’t get done without a solid process – especially for larger projects, global efforts, etc. But on the other hand, software processes can make projects bloat-out for apparently no good reason. That happens when, for example, a big process is applied to a small effort.

Let’s start analyzing this situation by realizing that some form of process is always necessary. I can win this argument by defining process to be whatever I want… it can be as simple as “keep a copy of anything you send out to a customer so you can test it later” or it can be much, much more than that. The concept of process was something hard for me to understand right out of school. I knew how to write code to solve problems. Sure, it made sense to make backups occasionally and I also liked the idea of code reviews from the start, but what else could you possibly need on top of that? Left to my own reconnaissance, I would have never conceived that those and a hundred other details could be the foundation of a framework for creating professional software.

I had a job right out of school with a company that had been writing software for decades. They started my indoctrination by giving me the two-inch-thick process binder on my first day. It was Greek to me. The thing had its own vernacular of TLA’s that you had to learn before you could even understand the table of contents. I set it aside and started coding. About 60 days later, we had a training class on the monster manual, so I dutifully inserted the six or seven updates that I received into their correct pages in my growing process definition binder, and went off to class. After that, I went back to coding. Two more months went by and I threw the thing out. In the round file. Landfill ledger. It had taken up space in my cube for too long and it was useless to me.

Not three days later my manager dropped by with a couple of updates for my process binder. Evidently there was a squirrel cage somewhere full of people whose role it was to crank out cryptic updates to this thing. The manager asked me where I kept it so he could put the updates with it – must have been something really important.

So, I told him “I tossed it.” He turned white as all the blood ran out of his face. He just stared at me, repeating my words “You tossed it” even as his eyes grew wider while he contemplated the impossibility of this situation. I had to say something more or else start CPR so I said “Yeah, I could not use it for anything useful and I understand what I have to do every day without it.” He walked away like a robot, wondering what planet I had come from and probably also wondering if I had carelessly found a way to make life more interesting and rewarding. Eventually I left and the company went into deep financial trouble so I’m sure they reformed, eventually.

I was wrong to toss out the process manual and that company was wrong to have a rigid, incomprehensible process pushed down on legions of people. As with most management situations, it’s not black and white; my situation arose after thousands of well-intended decisions created a process that justified its own existence without regard to practicality. Just exactly where it went wrong is impossible to say, but I am certain that nobody had tried to re-engineer the process in recent years; instead, they just patched it up with more inserts for the binder.

In the years and leadership roles I’ve held since then, I’ve gone through several process re-engineering efforts and I found each of them valid and each of them useful to improve on their predecessor. When the company grew, processes needed to change. When the company went global, processes needed to change. When technology went from Windows to Web, processes needed to change. In all cases the outcome was (a) a huge amount of change management that had to be done internally and externally and (b) net benefits that came much later and were never as great as expected because the downside of process changes was underestimated.

That said, I process definition efforts always surprise me because of how eager people are to participate. Every developer, QA and manager wants to have a say in the new process. In fact, most of them are downright dogmatic about it, having read about a style or technique that they think is the missing link that will allow the software engineering machine to suddenly work frictionlessly. Usually, groupthink sets in and defines something impossibly different from current processes (and process automation technology, which is rapidly growing in influence) so a smaller team has to sort out a reasonable plan.

I was asked to deliver a lecture on software process to an undergraduate computer engineering course about 10 years ago, but I screwed up. They caught me on a bad day. At the time, I had several team leads that were punch-drunk on process changes that they wanted to make. They were trying to tell me that they could not succeed because of the processes that were in place, with certain success predicted by changing 8 things at once.

My message to the class was to be wary of processes; following process does not guarantee success. Instead, bring ingenuity to the table and use your ability to create high quality as a means to avoid being told not just what to do but how to do it. It’s a message that resonated well with really smart, inexperienced left-brain people and I left the lecture happy. But I know I did the wrong thing. I know I should have made sure they understood how uniform processes guarantee quality even when you don’t have the best people working on every single feature. I should have told them how processes would save their butts when they were working too hard to remember all the minor steps that had been learned through years of mistakes. I should have guaranteed that they would never consider the job done until it was code-reviewed, tested and checked-in.

Now that I’m not as smart as I used to be, I know that the process manual is something to keep and respect, but only if you can change it when it’s wrong. Whoever is in charge of the process definition had better have an open-door policy and technology that makes it easy to follow (and monitor compliance!). Anyone who must submit to a process should have the right to influence it. I can actually get fired up when I read about a process that I know intuitively will make people productive and happy without controlling them. I see processes as something of a design pattern for project management.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.