The formalization of the development process has been a bone of contention in the software industry for decades. How much process does a software project actually need? It turns out that the optimal degree of formalization may not be a constant. In early product releases a more agile process is useful, while in later stages a more formal process might be preferable. The development process has to be flexible.
The controversy over the dilemma of the formalization of the development process has now entered its twilight years. For over a decade, supporters of agile methods and CMMI / SPICE Group have been at war with one another. With the Agile Manifesto in 2001, U.S. consultant Kent Beck and his colleagues intentionally cast the first stone. The consulting business lives – often much to the chagrin of the customers and their sincere advisers – like other branches of industry trends and fads. These are promoted effectively in advertising. Similar to the CMMI experts of the SEI with their case studies, once provoked, agile consultants banged their drum and diligently reported that the use of Scrum & Co. was simple, cost efficient and successful.
After years of heated debates, the discussion gradually reached calmer waters: the last crisis has increased the pressure on all parties finally to present pragmatic solutions. The time has come for constructive reasoning.
CMMI and SPICE-consultants are to blame for their own plight
It can be difficult to deny that the CMMI / SPICE-based process improvement has lost much popularity. Much was promised, little delivered. This becomes clear when you look at the old SEI CMMI presentations. In the “Management Summaries” General Motors is presented as a successful “early adopter” of CMMI. According to the SEI, quality and efficiency of processes through the use of CMMI standards should have improved considerably. Given the dramatic bankruptcy of the automobile manufacturer, this portrayal looks unbelievable today. Since General Motors is not the only company that found themselves in some considerable difficulty during the financial crisis in spite of process improvement measures, process consultants lost one of the most important sales arguments for the use of CMMI / SPICE standards: prestigious reference examples.
Instead, increasingly agile principles are needed. In place of a continuous process design a simple approach based on a few core ideas is preferred. This change in attitude can be explained not only with long-term consequences of the financial crisis. Rather, CMMI / SPICE process consultants have at least partial responsibility for the demise of their business model. At SPICE Days 2010 when I asked Tom DeMarco how he sees the future of CMMI, he said without hesitation: “That’s the end of it.” Among other things this was due to some process consultants acting with insufferable arrogance that eventually led to widespread disillusionment. At least, that is the impression articulated by the participants of the panel discussion, who included C + + creator Bjarne Stroustrup as well as Tom DeMarco. This criticism holds a lot of truth. Despite their often superior expertise and experience, consultants have various distinct competencies. At the same time they are expected to relate confidently as change agents in an organisation’s position and defend it. This is after all not always good, and every failure is passed on as damage.
The dilemma of competence is tricky. A quick look at the consulting market illustrates the fact that few consultants in all process areas – from quality assurance to project management, configuration management and software architecture – can really demonstrate their own, hands-on experience . In Germany there are just a handful of such experts. At the same time consulting businesses live on a human scale effect: They need to add more and more employees. The natural resource shortages must inevitably lead to shortages in the quality of daily business consulting.
Pssst! CMMI is alive!
In my view it would be wrong to claim that CMMI (or SPICE, the European sister) has reached the end. CMMI is an extremely useful collection of practical experience in the software industry, which can be used to systematically evaluate the quality of development organisations. The SPICE standard goes one step further: It proposes process reference models, which provide fairly clear guidance for the design of high-quality development processes.
However, to dismiss these standards as an aberration is airy. A model such as CMMI demonstrates what can be done – but this does not mean that you should also implement everything that is written on paper. An innovative project with a major research portion must necessarily follow different rules than a retracted infrastructure project in the 17th release. In the first release – possibly an internal alpha release – the product quality is often secondary. At the other end of the scale are the nuts and bolts of more “mature” projects - and they can best be ensures with a sound development process. CMMI (or SPICE) is ideally suited for monitoring process quality in software development and is therefore sure to find a place in the software industry in the long run.
Not far from the tree: Products and Projects
An agile developed air traffic control system? CMMI Level 5 for a team of three? There must be something wrong. “We do not want us to over administrate ourselves” versus “Like that we descend into chaos” – such thought-terminating clichés in the corporate coffee lounge are, while entertaining, not very productive. There is a grain of truth but this truth is definitely dependent on context. A careful examination reveals the following findings:
- Not all projects are suitable for an agile approach.
- Not all projects have to be on the CMMI Level 3 or higher.
- Release 0.1 of a product should be designed differently than release 7.5.
The conversation in the corporate coffee lounge can therefore not be assessed without the context. To the question: “Can there ever be a universal process?” is the simple answer: “No”.
The nature of the product determines the degree of formalization of its development process, as each release of the product typically is a separate project. The structure of these projects is determined by the type of product to be created.
STRUCTURE (project) = FUNCTION (TYPE (product))
The project structure, in particular the formalization of the development process, is a function of the product type in the context of the required project activities.
Therefore there cannot be a singular process for all projects – for each product under development needs a suitable mapping of the project environment required.
The situation is complicated further by the observation that products must meet other requirements in early versions than in later releases. This situation can be demonstrated with the example of the iPhone. The very first release was by no means perfect. The camera provided poor image quality, the battery was short-lived, the connection speed was insufficient, etc. But that was not important during the initial phase – the “first movers” loved the design idea and blindly bought the product. But look at three years later: a small deficiency of the antenna design of the iPhone 4 produced a storm in a media teacup that lasted several weeks. That the reception of the new iPhones worsened under specific circumstances suddenly became an almost scandalous quality problem.
What had happened? Over the years the product “iPhone” had grown up. Users had become accustomed to the new concept, and millions of new customers acquired Apple’s smartphone. Instead of sensational innovations these new buyers simply expect stability and reliability.
In order to achieve the required quality, a risk-averse design of the manufacturing process is required in subsequent product releases. Extensive testing and proactive quality control is needed, and in general “Trust but verify” (trust is good, but checking is better) is the ethos. Products go through a cycle that begins with their new development and ends in degeneration.
Before entering the market, an intensive research phase is necessary for complex IT products, especially in software. The tender plant may not be “battered” by heavy processes. For prototypes or even a first release (sometimes just a “trial balloon”) a flexible – “agile” if you will - approach is practically indispensable. In subsequent product releases, however, the error acceptance of the product buyers is reduced: The readiness of the manufacturer to takes risks must therefore be adjusted accordingly.
Bureaucratic agility? Agile bureaucracy?
The perception of the product by its users is related to its respective phase of life. New products are well received, after that errors are not forgiven. A successful development process must also consider the type of product to be developed and its maturity. The development process must go through an evolution similar to the product itself: from creative chaos to stable, risk-averse bureaucracy. As suspicious as these terms may sound, it is a better system during the late phase saturation and degradation of a product. Finally, it is no longer about the conquering of new markets, but rather the reputation of the manufacturer as a supplier of quality products.
How do we design such conflicting requirements in the development process so that it is suitable for the entire product life cycle?
The answer to this question must necessarily take into account the time component. A written, formal process design is characterized mostly by a static, immovable nature. The balancing act can only succeed if the process “grows” with its product: agile at the beginning, more conservative later. This in turn implies of course that the process is intrinsically flexible. Bureaucratic agility is naturally just as unrealistic as an agile bureaucracy.
How can we resolve this contradiction?
Proponents of agile software development may argue that a more agile development process can be scaled and thus represents the solution to the dilemma. However, it is inevitable bureaucratising when activities such as code reviews or system tests, often perceived as unpleasant, are integrated in later product releases and become part of the daily project tasks. For example, a high test coverage can only be achieved if one can plan it. This in turn will only occur if accurate specification is available, which may relate to the individual test cases (“traceability”). That means adopting a waterfall-like approach, because a “request-reverse engineering” has never really provided good results, so the requirements have to be covered BEFORE their implementation. Other implications include a complete design (to assure interfaces and non-functional requirements), projectable review processes, extensive configuration management (for the consistency of documents in various stages of development), etc. Accordingly, the process can no longer be called “agile”.
If, however, the followers of the analytical process theory should announce now that they have “always known it”, one must be reminded again that a difficult process is not appropriate at the beginning of a product life cycle. This can be proved with the fact that a CMMI-compliant process MUST not be difficult. Standards such as SPICE or CMMI provide measures to ensure a reasonable and competitive approach to finding the “right” requirements. Also, from the third stage of maturity rules apply that require a corresponding adjustment of the development process to project types. But, as already mentioned, it is shown in practice that process consultants often do not have sufficiently broad knowledge of all engineering disciplines, so that the right “Tailoring Rules” (adaptation rules) for written, defined processes cannot effectively be created. Moreover, the fact exists that the scope of the written process documentation with the number of matching rules grows, if not possibly exponentially, then at least strongly polynomial. One can usually assume that the budget has no provision for the cost of creating and maintaining such adjustment rules in a process improvement project. Later on the transition from a formal process to a flexible one is, however, expensive and rarely successful.
Hybrid processes ante portas
In his paper, “A View of 20th and 21st Century Software Engineering” from 2006, the software luminary Barry Boehm predicts an integration of process models: agile and projectable approaches would merge. But unfortunately, missing from this (by the way very interesting, compact and recommendable) publication is any advice on HOW this integration can be carried out.
It has been much theorized. We finally need a reference model that not only tolerates agile components and an “agile V-model” summary, but also operates inclusive, exemplarily, and systemically. An example to “drill into”, which can be easily adapted or generalized. Within this example, the transition from an empirical (agile) to a rational (CMMI / SPICE) process must be carried out explicitly. The minimal overhead in the early stages of the product life cycle must be kept short and sweet, while the design process inherent in future product releases must be heavyweight and extensively documented.
A trivial solution is however not in prospect. To expect that one can eliminate 50 years of a swelling “software crisis” with some simple rules of thumb would almost be naive. It also needs to be finally realized that a development process may NOT be that often spiteful mocked “write-only book ‘, but constitutes an ongoing organisational challenge that can never be finally overcome. Development is done by people, not by processes. But the software industry requires a new kind of project manager to achieve the next level. Experienced software engineers with strong management skills, who have experienced all the process areas and can think both agile and rationally, must find their way into project management.
Project allocation remains the key to project success. It will need to change continuously with the product maturity, because from a certain size of project on it will not be possible to commission the same experts from the first to the last product release. The importance of personal preferences – agility versus discipline – must not be underestimated. There must be a gradual transfer of agile project research teams to organised maintenance teams.
Off to new shores
Experts on the matter who have dealt with the eternal conflict between empiricism and rationality will remain skeptical – and rightly so. The views are so diametrically opposite that an approach that satisfies all equals the quadrature of the circle. But the squabbling between the sellers of consulting products such as “agility” or “process maturity” will cost the economy astronomical amounts. We should look with skepticism on dogmas and agree to communicate on the working level. A balance between agility and projectable processes IS possible. The contradiction can be resolved by the evolutionary design of the development process, in which the ratio of agility and predictability is a function of time.
In our consulting practice we have given the child a name: “SlimTrace”. This is a collection of tools which are intended to enable the described process design. The idea is (once again) that the wheel does not always need to be re-invented.
More details will soon follow on these pages.