What does your company smell like?

Tim Lister from the Atlantic System Guild inspired the topic for this month’s e-newsletter. I recently attended a talk Tim gave about a new book he and his colleagues are writing. Their forthcoming book is a collection of patterns that Tim & Co. have observed over the years in their consulting work with many organizations. Patterns are familiar concepts to many in the software development industry. For example, identifying and reusing a design pattern is a common technique for developing software.

The patterns that Tim spoke about in his talk were patterns of organizational behavior. Such patterns are important because they affect the health and vibrancy of projects and organizations. As you might expect, there are good patterns and bad patterns.

Tim characterized several patterns he and his colleagues have observed by associating them with a distinct and recognizable smell. What we need to do, according to Lister, is to recognize various smells, name them, and determine if they are good, bad or indifferent so we can decide whether or not to apply them again.

Associating a smell with organizational behaviors is an interesting idea. Scientists who have studied our five senses have found that the sense of smell can contribute anywhere from 70-95% of what we perceive as taste when we eat. Smell is a powerful sense that often can result in emotional responses. This is true whether the smell is of a freshly baked loaf of bread or of a project headed for disaster.

Like Tim and his colleagues, I’ve smelled a few smells over the years - from the sweet smell of success to the pungent odor of failure and everything in between. Here are some examples of project and organizational behaviors that you may recognize and some suggestions on how to deal with them...

• The “No-one Smells Like Us” Smell

I can’t keep track of how many times I’ve heard this... I ask a simple question about why some aspect of the software development process seems so unusual and the answer I invariably get is - We couldn’t possibly do that the way everyone else does - we’re different!

Well guess what? No, you’re not. Every organization that develops software has many of the same problems - every one. I’ve seen many of the same problems at the 100+ organizations I’ve worked with over the years.

What should you do if you work for a company that exhibits this behavior? Well, I’d suggest trying to get the people who believe this to be true to talk to people at other companies about their problems. They can do this by attending a software engineering conference or by blogging. Another option - have a reputable consultant come in to a give a talk on software development topics. Sometimes companies will listen to outsiders even though their own people tell them the exact same thing.

• The DOA Smell

Some projects are dead on arrival. Before they even get started, they smell really bad. On such projects, everyone (except Management apparently) knows that the schedule is ridiculous and that the requirements are totally screwed up.

Or maybe Management has decided to outsource this project and the Project Manager doesn’t have a clue as to how to manage a development team half-way ‘round the world...

These are two examples of projects that are clearly DOA. Ed Yourdon has a name for projects like this - he calls them Death March Projects. Tim Lister calls this a Dead Fish Project.

What should you do if you’re working on a project like this? I’d suggest reading Ed Yourdon’s book Death March to learn what to expect and maybe a few survival skills.

• The Who’s-on-First Smell

I’ve seen several project teams where basic roles and responsibilities of team members were never clearly defined. When this happens, stuff always falls through the cracks. Comments like “I thought you were supposed to code that feature?” or “I assumed you knew that QA was doing the daily builds,” are artifacts of this behavior.

This brings to mind the classic Abbott & Costello comedy routine called “Who’s On First?” about the names of players on a baseball team...

Listen to Abbott & Costello’s Who’s On First routine...

What should you do if you find yourself on a project that has this smell? Try having a discussion with the Project Manager and help him or her identify the roles and responsibilities that need clarification. Offer suggestions on what the roles and responsibilities need to be and offer to help get buy-in from the rest of the project team.

• The Insane Asylum Smell

Bill Walsh, former coach of the San Francisco 49ers, defined insanity as:

“Insanity is doing the same thing over and over ...
and expecting a different result.”

Management, it seems, is constantly complaining that development takes too long, testing requires too many resources, and products are released with too few features and too many defects.

Some organizations conduct project retrospectives as a way to identify what mistakes were made and what needs to be improved. Sometimes, project retrospectives identify many things that need to be changed in order to be faster, better, and so forth. However, for some reason, needed changes are never put into practice. Management often is the reason that process improvements and other changes identified from post-mortems and retrospectives are never realized.

And so we plod along using the same broken process that failed us before and somehow expect the results to be different the next time. Doesn’t Management realize how insane that is?

A basic law of nature states that:

“If you always do what you’ve always done
You’ll always get what you’ve always gotten.” [1]

Learn more about project retrospectives...

• The Something’s Always Burning Smell

These days, many organizations are struggling with doing more, in less time and with fewer resources. More often than not, I see organizations that are constantly in firefighting mode. These companies spend almost all of their time reacting to the latest disaster. This mode of operation clearly takes its toll on people. In fact, an organizational behavior expert observed that:

“In today’s business climate, many organizations have settled into a permanent crisis mode. Management is continually unhappy with performance, everything is always over budget, all projects need to be done faster and cheaper, and jobs are constantly in jeopardy.

Stress management experts tell us that, to stay healthy, for every period of stress, there must be an equal period of ‘Whew!’ to break the pressure. The predicable consequences of unremitting stress are:

(1) people try harder as long as they can,

(2) people burn out or break down, and

(3) people ultimately give up.

A fear-driven, unhappy, pressured, can’t-win environment generates employees who check their brains at the door. The problem is a total lack of balance. Organizations cannot survive in a continuous crisis mode. Management must either provide breaks in the crisis or else develop established processes for handling day-to-day requirements without merely applying more pressure to workers.” [4]

If you work for an organization that is always in firefighting mode, I’d strongly suggest that you find another job so you can preserve your sanity and maybe your health (mental and physical).

It’s All About Managing Risk

All of these behaviors result in increased risk of failure. A recently published analysis of project risk from assessments of more than 280 projects yielded the following seven characteristics of dysfunctional software projects... [2]

1. Failure to Apply Essential Project Management Practices

Many troubled projects fail to apply proven project management disciplines like cost estimation, project scheduling, resource planning, configuration management, and proactive risk management, and then wonder why their project is in constant turmoil.

2. Unwarranted Optimism and Unrealistic Management Expectations

Some managers recognize the potential for negative impact on their project from potential problem areas; however, they choose to see things through rose-colored glasses, assuming that problems will work themselves out even when all available evidence raises a red flag.

3. Failure to Implement Effective Software Processes

Many projects fail to implement effective software processes because their approach to process application is not balanced. Some apply minimal process and rely on staff expertise, while others insist on rigorous global process conformance.

4. Premature Victory Declarations

Pressures to deliver timely products often result in premature declarations of completion by managers. Success cannot be declared until products have been completed with the built-in contracted quality and reliability.

(A noteworthy example of this behavior...)

5. Lack of Program Management Leadership

Managing a software project requires "courageous" and often clairvoyant individuals who are willing to confront today's challenges to avoid tomorrow's catastrophes. We have observed two types of problem managers: those with software engineering and no management experience, and those with management and no software engineering experience. Both types lack the ideal blend of both technical and managerial know-how.

6. Untimely Decision-Making

Some managers avoid making time-critical decisions until it is too late, even when they are faced with overwhelming warning signs of impending problems.

7. Lack of Proactive Risk Management

Many projects claim to implement risk management but few do so effectively. "What distinguishes the best organizations and best managers is not just how well they do in their successful efforts, but how well they contain their failures." [3]

Summary

Patterns (smells) are everywhere - in our work as well as in our personal lives. We need to learn to identify patterns and recognize those that are positive and those that are negative. Only then can we begin to identify a compelling rationale for change - be it changing the organization or changing jobs.

If you want to savor the sweet smell of success, remember...

Walt Kelly, Pogo Cartoon Strip, 1970

Happy Holidays!