Processes Stink!

Standards can be helpful in software development. A “clean and well-defined” collection of Best Practices (only recently known as “good practices”) is potentially a useful idea. On the other hand, in the hands of an inexperienced person, powerful standards can lead to disastrous effects. The results can quickly drive all involved parties insane. The consequence is often a frantic rush to agile concepts. Suddenly, everything is agile, and no sophisticated processes are required. Are they on the verge of extinction?

Automotive SPICE, CMMI & co. seem to be almost universally hated. However, consultants who earn money with these standards tend to dismiss that as mere stubbornness or lack of experience. What’s the problem? Frankly, it is our consultants’ own fault. Many of us have ignored the bleak reality of the standards-based process improvement. Consider the way it was supposed to work:

1. A need for improvement is identified; for example, the team wants to become more professional or to expand its market advantage.
2. A renowned process consultant, reportedly known as an expert in the field, such as SPICE, is hired to help the team.
3. The team jointly develops a new, standards-based process environment in which everyone has a well-defined role, outcome, and quality goals.
4. The consultant completes his work and leaves a satisfied customer.

The practical experience with process improvement often proved to be different. Instead of the orderly process above, the reality looked more like this:

1. The end-users (eg. car manufacturers) agree to make a new set of rules (“standards”) and impose them on their suppliers.
2. A desperate supplier hires a consultant.
3. The consultant, usually a trained salesperson with a well-founded, professional background, sells a consulting project to the customer. However, instead of delivering it himself, he sends a bunch of young “high potentials” into the project. Of course, he assures the customer that he will closely monitor his inexperienced young team so everything would work “as well as if he had done it himself.”
4. The young team assigned to the project has memorized the standard in question. They implement it literally, detail by detail.
5. Other stakeholders, such as QA staff and the customer’s employees, also memorize the standard and implement it literally.
6. As standards are mainly constructed analytically (and not systemically), the so-called process improvement project leads to an exponential cost increase, while the team, instead of taking care of the customer’s needs, fights over the fundamental meaning of a “Practice XY.47.11”  from the standard.
7. The project sponsor finally gets fed up with the project getting out of hand. The junior consultancy team gets fired.
8. Now, either a) most changes in the development process are rolled back, and the organization goes “hyper-agile,” or b) internal wannabe- experts take over the newly developed process and paralyze the entire organization by misusing the standard as a killer argument in the battle of egos.

THAT STINKS! Knowing the above, is it really surprising that the agility idea is going wild?

How could this happen?

It happened for a number of reasons. For example:

1. The business model of consulting firms. Profitable businesses are based on the leverage principle. Heads of consulting companies are businessmen, and leverage is their raison d’être. The leverage principle means that a sophisticated business idea must be multiplied, possibly by using cheap workers and distributors. The importance of leverage grows with the number of salaried consultants. To maximize their leverage, they are often not as highly qualified as their bosses pretend. Otherwise, they would be unaffordable. They may even be highly skilled in general consulting but have little practical experience in the matter in which they advise. Technical experience is scarce.
2. Again, Lack of technically experienced consultants. It is an extremely dangerous misconception that a beginner who has memorized all the details can effectively implement a standard. Quite simply, it is by no means enough. Standards are great when used as a checklist, but nothing can substitute real technical experience in the given field. If a consultant does not have years (or even better, decades) of experience developing marketable systems, then he or she has no actual ability to separate the important from the unimportant, the right from the wrong, and the useful from the harmful approaches. There may be scarce talents that are capable of this from the get-go, but no industry can rely on exceptions. And so, instead of using their own industry experience, supported by a crib sheet of standards, typical process improvement consultant acts literally and dogmatically, e.g., “The standard requires this.” If this killer argument often comes into play, then you should be cautious. In these situations, the outcomes will likely not match the real customer needs. They will match the consultant’s ones.
3. Susceptibility to hypes. What does a consultant sell? Unfortunately, concepts such as “experience”, “expertise” and “know-how” hardly market themselves. Anyone can pretend to have those. Thus, a magical phrase is required to generate credibility, such as “CMMI,” “Scrum” or “reengineering.” The PR industry is wonderful at spreading hype. As a result, those who fall for buzzwords like “waterfall,” “V-Model,” “design thinking,” “agility,” “ITIL,” “cloud computing” etc. truly deserve to fail. These hollow terms are sometimes used to represent very complex issues, and if they are used in conversation, then we may understand them with different meanings or contexts.
4. Lack of ability to select the right consultant. The right consultant is hard to identify. “Right” means a suitable mix of experience, expertise, and personal “chemistry.” Those who get fooled by the cool logos, business cards, and glossy brands are soon inclined to accept a moderate price-performance ratio. If you do not have many years of project experience in your field, then perhaps you should initially hire a consultant to help you search for a consultant. In effect, you may need to select a principal adviser to the project who will provide “meta advice” that might help your experienced staff search for the right expertise.
5. Fear of dependency on suppliers. Big corporations, for example, automobile manufacturers, are notoriously afraid of being dependent on their suppliers. This concern is not historically unfounded. Before the controversial Volkswagen manager Ignazio Lopez plowed the supplier landscape decades ago, the European car industry suffered from soaring costs and massive quality problems. But the opposite is not necessarily true either: mistreating suppliers with hundreds of standards until they gasp for air can destroy trust and open the back door to unwanted consultant invasion that will inevitably result in the aforementioned consultant’s business model.

The consequences of these and other problems are so dramatic that we should really rethink the way we deal with the standards. To question the effectiveness of a standard must not be a taboo anymore. Standards can indeed kill projects. The additional cost of a standard introduction (and its subsequent maintenance) must be taken into account, but instead, these costs are often purposely ignored by industrial customers. At the same time, there are rumors that the industrial customers themselves don’t satisfy the very standards they require from their suppliers. Who knows, might that be true? So do standards matter? The advocates of the strictly standard-oriented approach argue that standards as such are a good thing, but they are often misunderstood and incorrectly implemented. Indeed, it is often shocking how much mischief can be created when analytical standards are used to synthesize development processes. For example, reference process models such as SPICE are often implemented completely literally in practice. Its ENG processes (ten units), SUP, and MAN processes are called into existence as separate entities. That results in a double-digit number of processes and process owners who deal with largely redundant themes and contribute to friction and inefficiencies. Scary! And hardly productive. It is essential to understand that analytical process models are redundant by nature and are not a good blueprint for a well-working development organization. Only highly experienced industry experts can help create a beneficial, redundancy-free project and product development process landscape. As well as SPICE, ITIL, CMMI, ISO 9001, 26262 Functional Safety, and others are similarly problematic. Dear friends, it’s a fact: standards are powerful, and they can KILL your organization.

Processes are bad!

Dissatisfaction with process standards has already aroused unexpected desires. Ten years ago clever American consultants realized that there was a problem with CMMI and other standards. They proclaimed a new project management era and moved away from the “bureaucratic processes.” It was useless to point out that standards are good if implemented correctly. The credibility of the traditional process consultant was unfortunately already ruined. Now, all of a sudden, everybody had to be “agile”. But what does “agile” mean? The opposite of it is “clumsy” or “awkward”. This sounds more like an attempt to devalue differing ideas than a constructive solution proposal. Popular agile approaches intensify this impression. Take, for example, Scrum. Today, many say “agile” but mean, “Scrum.” Webster’s Dictionary says “a usually brief and disorderly struggle or fight. “ I cannot imagine this may represent a useful goal for a successful manager. The Scrum criticism can be easily deepened. In Scrum, the project manager was abolished. However, history teaches us that highly skilled project managers have always been the critical factor for successful project work. Project managers are often under pressure in matrix organizations because their behavior is product-oriented and they do not represent any corporate political side. In my view, the role of the project manager must be strengthened continuously for too many reasons to list here. But our Scrum friends removed project managers altogether from their concept. At the same time, they introduced a “ScrumMaster,” a typical consultant role that usually cannot be filled internally. Scrum was obviously designed purely to act as a well-oiled marketing machine for lucrative consultant contracts. What a gigantic step for mankind we have achieved! The practical implementation of agility is, therefore, itself often “clumsy” and “awkward” by its very nature. In any project, agile or not, a consultant must have at least as much professional experience as a meaningful process improvement project. If that’s not the case then, under the pretext of “agility”, chaos, activism, poor organization, and randomness are sold. To me, that sounds like the same old story all over again. Extreme views may be refreshing, but they only distract from the goal in the long run. We can do better. First, we need to seek “lean” project organizations and not mere “process compliance” or arbitrarily simplified “agility”. Secondly, as experts, it is our job to gain industry experience. We need to learn, but nothing can replace real, hands-on work. Thirdly, setting up a high-quality project management system is indispensable regardless of the approach. Fourth, the development processes must be tailor-made. Organizations need realistic and honest advice from experienced experts. There should never be an off-the-shelf process. That would be as absurd as ordering a toothfilling online. Fifth: No, processes do not stink. Agility does not smell, either. Lack of realism, openness, and hype-driven delusion do.

What now?

Simply becoming agile, “come hell or high water,” will solve nothing. Polarizing ideas and classifying them black-and-white is not helpful, either. A slavish, literal implementation of some book X or Y will not improve anything. However, undeniably, there is plenty of room for improvement. But what is the solution? Finding it must start with recognizing that a development process is part of its environment. This project environment is determined by critical factors such as available resources, the stage in the product life cycle, and the associated market requirements. On the other hand, it is essential to keep the process as lean as possible so that it is not too “fat.” A good software development process must evolve the right “DNA” to ensure that the resulting creature – the project – can survive. More details to follow soon on these pages.

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).