Attitudes toward continuous improvement

Question: Is it a general pattern that organizations in need of improvement tend to be satisfied with the status quo, while organizations that pay attention to improvement tend to forget that they already do many things very well?

Here are sanitized descriptions of four client environments where I’ve worked in the past few years.

Case 1: Cumbersome traditional process developed in “ivory tower” fashion by two senior managers. Large, laminated posters of the process are displayed prominently on the walls. Those managers cannot tolerate any suggestion that the process could be improved, or that staff are not actually following the process as it is specified. If everyone followed the process to the letter, no work would ever be completed. Staff would be shackled into a permanent interlocking set of wait states, queued up to review and approve each other’s interim documentation artifacts. The formal process includes numerous redundant reviews of documents, quality gates, planned back-flows for defect correction, and so forth. Of the ten-month release cycle, about six weeks is spent doing any real work.

At ground level, each work group or team has crafted ways to get around the process while reporting to management that they have followed specific process steps. No two teams or work groups operate in the same way. A handful of personnel can be credited with enabling most of the work to get done. They are working 80+ hours per week all year long. The rest of the staff of some 800 people are extremely busy for short periods of time during the 10-month release cycle, and otherwise go through the motions of holding meetings and reviewing documents. A typical work day for most staff members consists of 8 or 9 hours of meetings, and nothing else. Working there is like being trapped in the Hypercube.

Case 2: Self-styled “agile” shop comprising some 400-500 people that, at first glance, appears to have implemented first-generation “agile” methods successfully. They are quick to pat themselves on the back for being an exemplary “agile” environment. A deeper dive into the organization reveals significant dysfunction in “agile” mindset, and a well-entrenched culture of pretense. Everything about people’s words and behavior is fake. It is not politically safe for people to suggest the organization might not be fully and deeply “agile” in every way. They don’t bother with retrospectives, ostensibly because they are already perfect, but perhaps more realistically because no one would dare suggest anything needs improvement.

In practice, the organization is highly traditional in mindset and staff feel “beaten down.” People have learned to affect the required smile, chant the required mantras, and tolerate the never-ending Death March that is their working life. Management likes to boast about how “agile” they are while actually practicing Theory X management, with the X’s embedded in staff members’ backs like shuriken. They consider themselves masters of the art of software delivery, with nothing left to learn from anyone else.

Case 3: An organization that has experimented with ideas from various schools of thought, including all the various management frameworks and process models that have come along over the past few decades. They have adopted methods and practices that work well for them in their business context. They have a formalized continuous improvement process that they take seriously, and that they use to experiment with new ideas on an ongoing basis. They do a good job of delivering high-quality software, although they have their fair share of monolithic legacy systems to support, and they are constantly on the look-out for potential improvements.

Case 4: An IT shop that a few years ago reached a nadir of delivery performance, morale, and cost management, and undertook a “big bang” transformation into “agile” methods. They have turned things around very nicely and are currently delivering high-quality software in a sustainable way. They have exceptionally good morale and have internalized “agile” principles honestly. They take continuous improvement seriously and frequently try different ideas to see how they might offer benefit. The present focus of their improvement effort is to move from a one-month release cycle to a continuous delivery model.

I’ve noticed something interesting (to me, anyway) about these four organizations. I will suggest the four represent a broader pattern in industry, as well. The interesting thing is this: The two organizations that are most proud of their current state do an extremely poor job of delivery, and have the least awareness that they need to improve; meanwhile, the two organizations that are most aware of the importance of continuous improvement are pretty much unaware of how well they are performing already. The two that least deserve to feel proud of themselves feel great pride in themselves; the two that actually deserve to feel pride see themselves as poor performers. Note that this is completely independent of the methods they use – there is no connection with “agile” or “lean” or anything of the kind.

In the most dysfunctional organizations, people walk around proclaiming that they are the best IT shop on the planet. In the best-performing organizations, people walk around saying things like “We suck” and “We’re highly dysfunctional.”

Psychologists, help me understand this phenomenon.