For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.
“How's it going, dear?”
This has been my “seeking-to-avoid-the-minefield” question now for several weeks, ever since the freezer compartment in our recently-purchased (less than five years ago) refrigerator decided to take a nose dive and stop freezing. My wife has been working with the manufacturer (and the third party to whom they outsourced the warranty work) to get our freezer either fixed or declared a loss and a check cut to replace it.
The reason for the question is simple: half the time, when she gets off the phone with them, it's because she's ready to kill someone and I'd rather it not be me. It seems that the entire process has been fraught with dropped-ball scenarios. People are supposed to call her and never do. She calls back and has to repeat her story every time. She gets transferred, and then the new supervisor promises to “look into it personally,” and nothing happens. At no point has she ever felt like there was anybody on the other end of the phone that had the authority, the empathy, and the ability to just fix the problem - it's been a nightmare of a process from one end to the other. And, I should note, totally turned us off on ever buying any big-ticket appliance from that big-name manufacturer again.
Our frustration stems not from the quality of the manufacturer's work, per se. It's been a pretty good purchase all the way up until this warranty repair business. And all of our frustration lies entirely with the process we've been forced through; it's been inconsistent, incomplete, and entirely inaccurate in places.
Theory…
In 1990, Michael Hammer wrote a paper entitled Reengineering Work: Don't Automate, Obliterate, and kicked off what eventually came to be known in business circles as the Business Process Reengineering (BPR) movement. His thesis, put simply, was that businesses (that were busy looking for ways to automate the various tasks they were doing as part of their day-to-day operations) should be looking for ways to eliminate processes that added no value to the company. In a later book entitled Reengineering the Corporation, Hammer and his co-author, James Champy, defined BPR as “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed”.
On the surface of it, it sounds a lot like a collection of buzzwords that business-types love to throw together to make it sounds like what they're doing is important. ("Toss in a synergy, a few core competencies and maybe a best practice or two, and I think we have us a Mission Statement, boys!") But underlying it is a very simple idea: The business needs to ask themselves why at every stage of every process. When a salesperson is producing an order for a customer, every step that salesperson goes through needs to be examined. Why is she being forced to do this? What can be eliminated? What information do we already have for that customer? Why do we need to send this order to a supervisor before it can be placed? Why do we need signatures from the customer three times in four different places? And so on.
In essence, BPR seeks to take an end-to-end view of all the steps that take place as part of a business process (applying equally to internal and external processes) and look for the justifications and rationale for each one. If that step doesn't directly add value to the process in some fashion, it should be eliminated. Not just automated, but eliminated altogether.
Does this sound somewhat familiar?
...and Practice…
There've been two major industry trends in the last decade or two that seem directly related to the BPR effort of the 90s.
The first, as I suspect many readers will already have guessed, is the overall trend towards a more agile style of development, eschewing heavyweight processes for a more lightweight one along a number of different angles. The Agile Manifesto, when written, specifically targeted processes in its crosshairs. Not only were processes and tools on the right-hand side of the Individuals and interactions over processes and tools clause of the manifesto (meaning they were valued less than the items on the left-hand side), but it's not hard to see how heavyweight processes qualified under some of the other items on the right, too. Working software over comprehensive documentation seemed to be taking a shot at the document-heavy approaches that many waterfall software development teams (and processes) championed and used. Customer collaboration over contract negotiation seemed to be aimed at the “contracts” that software development teams created, even with other departments inside the same company. (I observed some of this going on at Pacific Bell back in the mid-90s.) And, of course, responding to change over following a plan easily targets those organizations that spend a great deal of time establishing a project plan (done in Microsoft Project, of course) that aims to establish a ship date eighteen months in the future before the development team even has a chance to get a sense for the size of the project.
In many ways, when an agile coach looks at a team's existing development process and starts asking “Why do we need to do this,” they're following in the hallowed footsteps of Hammer and Champy, and when said coach then starts tearing down the heavyweight artifacts (story cards instead of hundreds of pages of requirements documents), BPR enthusiasts across the world cheer. But the BPR knows neither allegiance nor alliance: Lose sight of the goal at your own risk. When an agile coach insists on two-week sprints because “that's the way Scrum says it should work,” the BPRists in the room grow restless. When an agile team insists that developers must pair in person (not online) despite being scattered (for intractable reasons) across five buildings, the BPRists get annoyed. And should a team eschew documentation because “agile doesn't do documents” - despite the fact that the Manifesto clearly says that documents have value - the BPRists stage a revolution. Agile is no more exempt from the “why” question than its predecessors are, nor should it be.
The second movement that seems directly from the BPR playbook is the more-recent DevOps movement, in which we deliberately and calculatingly tear down the silos that emerged between the different departments within an IT organization (development, QA, operations, and so on). Much of the BPR movement was about taking a “holistic” view of the process - in essence, following the process through from the process's viewpoint, rather than seeing the process as something entering our department and then leaving it again. This is, in many respects, the same attitude that DevOps seeks to foster: Software is something that stretches across the entirety of the IT department and needs to involve all facets of IT - development, QA, operations, and any other functions that might be siloed - as part of the overall process. In fact, when DevOps meets agile, it's not unreasonable to suggest that it needs to tear down the silos across the entirety of the company: IT, marketing, sales, procurement, HR - you name it. If there is inefficiency in the process because the process needs to transition across a silo boundary, then that inefficiency needs to be stripped out.
...and Summary
In many ways, BPR can be summed up with the following story:
A young man, recently married, was watching his wife prepare dinner (because they were still young and in that stage of their relationship) when he noticed something odd: As part of her preparations, she cut about an inch off each end of the roast and threw the ends away. A little surprised, he asked her why she did that. Her answer surprised him: "It makes the roast taste better, and besides, my mother always did it that way."
Intrigued, he called her mother and asked if she prepared roasts that way. Her mother, a little surprised by the call, said yes. When he asked why, she replied, "Because it makes the roast taste better, and besides, my mother always did it that way."
The young husband then called his grandmother-in-law at the home, and when she answered, he asked her the same question: Did she always cut the ends of the roast off when she prepared one? She said yes. When he asked why, she said, "Well, sweetie, it's because my pan is too small."
BPR says question everything. Don't be the one that accepts the “because we've always done it that way” answer, and ruthlessly eliminate the steps in the process that don't apply anymore or don't add value to the result.
