If you’re a developer, you've seen the “Interview with the Bob’s” clip from the film Office Space. (If you haven’t, you can’t be a real developer!). Milton “takes the software specs from the customer and delivers them to the software people”. While this clip takes the idea to absurdity, for those of us who have worked in IT, it ain’t that funny. After the lean and agile revolutions have changed management and IT forever, there are still many ridiculously unproductive processes that burn dollars, burn out precious talents, and burn up the stakeholders waiting for valuable products.
Lean and agile are kaizen practices; they drive towards perfection by using retrospectives and continuous improvement. An obvious way to improve any process is to remove activities that add no value, and anyone with an agile mindset develops an “eye for waste”, as Toyota Motors phrases it. Reduction of Muda, the Japanese term for waste, is a core concept of lean thinking, and “maximizing the work not done” is central to agility.
In an IT context, those of us who've toiled in the corporate data center know that waste abounds. In a traditional environment that hasn’t yet embraced lean and agile thinking, one of the most wasteful activities is waiting. How frequently do we have to wait for the business analysts to interview every stakeholder, develop a complete set of specifications, review them with managers for approval, and then throw them over the wall to a project manager or technical architect? How often do we then wait for the PM or TA to develop an architecture or project plan, predicting all the things that would, should, or might happen?
Waiting is but one of the wasteful activities that IT pros are familiar with. How much time do we spend estimating every line item on the project plan, only to come up with an estimate that can’t possibly be accurate, due to ‘unknown unknowns’? How much time do we spend building in features that will never be accessed, writing status reports that will never be read, and delivering applications that will never be used? From incompetent team members, to ingrained processes that don’t work, to interrupt-driven developers who aren’t allowed to concentrate on any task for more than a minute, the waste in most IT organizations drains the energy, morale, and value out of the most dedicated team.
Let’s take an walk though some types of waste that IT shops typically exhibit. The non-value-adding activities outlined above are destructive to speed and quality, not to mention attitudes. The biggest waste, in my view, is the waste of creativity, innovation, freedom, and sheer pleasure that bureaucratic, over-processed IT value chains create. IT pros are called “knowledge workers’ for a reason; we know how to do stuff. The ‘management-over-leadership’ dynamic that plagues control-centric environments is a crime. Rather than unleashing the talents of iconoclastic, passionate developers, control environments stifle them in the name of consistency and predictability, the twin illusions of traditional project management.
Knowledge loss or repetition is another waste center. “If only we knew what we know”, as former HP CEO Lew Platt was quoted as saying,”we’d be three times more profitable”. The tacit knowledge that is in people’s heads, but is never shared, causes the waste of rediscovery, rework, and redundancy. From the walls of functional silos that restrain sharing, to the individual performance metrics that distort teamwork and cooperation, many enterprises incentivize exactly the wrong behaviors. The individual performance metric, for example, causes the waste of “secret sauce” hoarding; why would I tell you my effective methods, when they’re the thing that enhances my prestige and value in a competitive ranking system? At the heart of many agile practices is the intentional violation of existing barriers, in the name of free exchange of information.
More subtle is the waste of unmanaged work-in-process, or partially completed value delivery. In agile here’s no such thing as “90% done”, the bane of development managers worldwide. Completion is binary, either done or not. Excessive WIP breaks the value chain, introducing waiting, interdependency challenges, and undiscovered defects that cascade though the entire chain. Overdependence on “super-specialists”, otherwise known as “the only guy who knows this stuff”, is also a source of Muda, as teams twiddle their thumbs while they wait for superman’s availability, and superman loses his mind by being dragged from project to project with no context except urgency.
Local optimization, at the expense of strategic focus, is another locus of waste. If you’re an agile coach or leader, how many times have you seen organizations that laser-focus on one process, usually software development, while the rest of the enterprise stumbles its way through archaic and ineffective processes? How often have you seen significant agile progress sucked into the black hole of faulty culture? As the agile community is learning through painful experience and disappointment, the benefits and habits of lean mindset swiftly dissipate when they’re confined to one tiny corner of a big corporate machine. The rubber band inevitably snaps back when agility is not a constantly expanding initiative.
It’s not enough, of course to point out the challenges and sources of waste. We need to fix them. We’ll explore the principles, both agile and lean, that enable us to apply our developing “eye for waste” in the next episode.