Keywords

1 Introduction

2010 the SPI Manifesto was launched. It contains the PI knowledge of many leading experts of PI (Figs. 1 and 2). Everybody being in Alcala that year thought that this paper would have great impact on the evolution of PI. However –compared to the agile manifesto- the SPI Manifesto is something for expert clubs and did not have real impact. The paper creates an Idea Why.

The SPI Manifesto at a glance.

For PI experts it sounds trivial. But what was the Problem the SPI manifesto aimed at?

It was the process bureaucracy caused by the CMMI driven SEPG. It was a “no” to ivory towers where unsuccessful project managers and clueless beginners met in order to define the software development and testing processes of an organisation. Producing process descriptions that created very interesting sites on the intranet. The authors of the SPI manifesto were right to oppose this way of PI but they did not reflect the complete scenario.

Fig. 1.
figure 1

SPI Manifesto values

Full size image
Fig. 2.
figure 2

SPI Manifesto principles

Full size image

2 The Evolvement of Organisations and the Empowerment of People

To understand the trend and the current situation of PI we need to look at the core discipline of which PI is a part of: The theory of organisations.

Looking at one influencer, Marvin Weisbord (Weisbord 1987), we see his fundamental view on the learning curve of organisations (Fig. 3):

Fig. 3.
figure 3

Learning curve according to Weisbord

Full size image

One trend in this learning curve is that every member of an organisation now performs tasks formerly performed by experts.

We see that the Capability Maturity Model (CMM) was published in 1991.

We also see that the SPICE (Software Process Improvement and Capability dEtermination) started in 1993.

Last but not least we see the Bootstrap Approach published 1994.

They all contribute to the paradigm of that time: Experts improve whole systems.

They all had to deal with the new paradigm expected to step in 2000: Everybody improves whole systems.

And what happened 2001: The agile manifesto was published. By giving back the centre stage to the software developer, it seemed to be a perfect fit to this new paradigm.

2010 the SPI Manifesto was published written by experts who had a broad experience in improving organisations (Pries-Heje and Johansen 2010). However, the prognosis of Weisbrod was that in this time everybody has the task to improve whole systems.

Summarizing the provocation: The SPI Manifesto was the summary of expert knowledge in SPI but was outdated when written. Therefore, it had no practical impact and remained an academic footnote.

2.1 Was Weisbord Right and Does the Agile Manifesto Really Fit into His Paradigms?

When discussing the learning ladder of organisations as described by Weisbord, we need to have a look at his core cornerstones: Everybody. Improves. Systems.

Everybody. The word seems to be trivial but it isn’t. The problem arrives when we see the timeframe in the prognosis of Weisbord: 1900 to 2000. Looking at 1900, industrialization meant employing unskilled people in a plant or an office, organizing their work and letting them perform very little steps of the process (e.g. fasten a screw or add numbers). This time has gone. Currently we face completely automated back offices, and we see skilled workers with lot more authority and responsibility than even a team, lead in 1900, would have even dreamed about. Looking at this fact it becomes reasonable that “Everybody” improves whole systems because “Everybody” has rapidly changed, in the financial industry there are only some subject matter experts remaining as “Everybody”.

Improve, this word looks great, but again, we need to revisit. Everybody “Improves” whole Systems. What does it mean? Is every improvement of the individual work sphere also an improvement for the system? Certainly not. By learning how to deal with linear systems of equations, matrix calculation we learn that in a true system the optimum for a system is not the optimum for a factor. Therefore, every local improvement, often declared as low hanging fruit, hampers the total performance of a system. Also when frame conditions are complex and rapidly changing, how does one rate a change as an “Improvement”?

System, also this topic needs revisiting. In 1900 a system was a car and maybe a plant. But in 2000 we see system of systems and looking at European air travel we see systems of systems of systems. So what is the system that has received an improvement? How can someone make sure that an improvement in a low-level system also causes improvements in overarching systems?

So when we shortly analyze the paradigms of Marvin Weisbord, they still look attractive and helpful but also somewhat fuzzy.

2.2 The Agile Manifesto – Revisited

Revisiting the agile manifesto (Beck 2001), there could be doubts whether this manifesto really fits into the modern time paradigm of everybody improving whole systems.

The agile manifesto focuses on “teams”. A team can be understood as a system and with stand up, reviews and retrospectives there are tools for improvement available. Looking in team level it is a perfect fit. However, if the system is a whole organisation it turns out, that there are big doubts. If teams in an organisation come to different conclusions on how to work then these teams tend to work differently, measure their progress differently and deliver at a different cost. This causes a dilemma: By sticking to the team approach, the organisation might risk a decrease in performance. If the organisation decides to introduce guiderails, two questions remain. Namely, who it is to define the guide rails and who is in charge to control their effective implementation. At the end, it turns out that the same “everybody” who improved the Team System has to reject the improvement on the level of an organisational system. Therefore, at the end there are real doubts if the agile manifesto really fits into Weisbord paradigm. The agile community has developed several approaches to deal with this issue. One of these is the scaled agile framework: (Gerush 2017; Powell Horse 2017). See Fig. 4.

Fig. 4.
figure 4

Agile framework

Full size image

It is easy to see that this framework and the related certification scheme is a step back to expert driven process improvement.

The same impression is delivered by the disciplined agile framework (see Fig. 5).

Fig. 5.
figure 5

Disciplined Agile 2.0

Full size image

The issue of team vs organisation focus is unsolved and subject to debate (Mitchell 2013).

At the end it could be summarized that agile in its core is not a tool to improve organisations and as soon as it is used to improve organisations it tends to become expert improvement with certification schemes, and strict procedures in the background.

Organisations, which want to enable their people and try to move ahead in Weisboards learning curve, will find agile a plank road or even worse a dead end.

2.3 Comparing Weisbords Learning Curve with Typical Change Strategies

To improve an organisation means also to change it. The question is: Is there a difference between a system that is improved by experts and a system that is improved by “Everybody”? Are the underlying change strategies different? A possible answer is to refer to refer to the improvability approach.

The book describing the approach contains also a section dealing with change strategies

According to the research presented in this book the most typical change strategies (Pries-Heje 2013), are:

  1. (1)

    Commanding

Change is driven and dictated by (top) management (owner, sponsor and change agent).

  1. (2)

    Employee driven

Change is driven from the bottom of the organizational hierarchy.

  1. (3)

    Exploration

Change is driven by the need for flexibility, agility, or a need to explore news.

  1. (4)

    Learning driven

Change is driven by a focus on organizational learning, individual learning.

  1. (5)

    Metrics driven

Change is driven by metrics and measurements.

  1. (6)

    Optionality

Change is driven by the motivation and need of the individual or group.

  1. (7)

    Production organized

Change is driven by the need for optimization and/or cost reduction.

  1. (8)

    Reengineering (BPR)

Change is driven by fundamentally rethinking and redesigning the organization.

  1. (9)

    Socializing

Change in organizational capabilities is driven by working through social relationships. Diffusion happens through personal contacts rather than through plans and dictates.

  1. (10)

    Specialist driven

Change is driven by specialists (professional, technical, or domain knowledge).

The research in this topic was driven by IT-University, Copenhagen, Denmark, DELTA and 4 companies in a 3-year project.

Checking which of these strategies might more fit to an expert driven improvement or an “everyone” driven improvement, it becomes obvious, that commanding is really a tool from the 20th century but all other need a high level of collaboration, e.g. analyzing Metrics and as well analyzing potential impacts of measures. It is also obvious that the strategies “employee driven” and “socializing” fit best to the stage “Everybody improves whole systems” of the Weisboard approach.

3 The Customer as a New Factor in SPI Projects

In the last few years, a new strategy has emerged:

Customer Driven

This change was introduced in the last years mainly in the German automotive market and in the Dutch construction market.

In the German automotive market the Original Equipment Manufacturers (OEM) face the need to get the software parts of car components under control in the Dutch construction market the change was driven by Rijkswaterstaat (RWS) in order to implement the Design, Build, Finance and Maintain (DBFM) approach.

This seems to be a loop back to the start of the story where the US Department of Defense (DoD) tried to achieve control over underperforming software suppliers by pushing them into CMMI.

While the need is similar, RWS and the German OEM use different tools:

German OEM challenge their suppliers to fulfill Automotive SPICE® Requirements while RWS uses ISO/IEC 15504 Part 6:2013 – Systems engineering.

There is one big difference in both approaches:

OEMs use Automotive SPICE® to create pressure on the software engineers, which make them feel that they are threatened by only living to deploy standards, rather than employing the principles, which support business values.

RWS is aiming at the management system of its suppliers (van Loon 2012a) (Which is reasonable recognizing that a DBFM contract includes a maintenance period of 20 to 30 years). Even if RWS has difficulties in formulating reasonable improvement roadmaps (van Loon 2012b) for the DBFM contractor, its approach is a great success story, including huge infrastructure projects like Poort van Bunnik, Poort van North, OpenIJ and SAA1.

The other big difference is how contractors deal with the challenge: While German OEM contractors often do not see the business chances of process improvement with Automotive SPICE® the huge Dutch companies started to use the approach of RWS to improve their business and to create competitive advance.

Nevertheless, the customer on the driver seat has an impact of the role of (S)PI professionals.

4 Closing the Loop I: What Is Process Quality

Process quality can be expressed in very complex terms like capability diagrams including lots of information for (S)PI experts and hard to understand for the major parties (Workers, managers, customers).

Simplifying process quality from their perspective means

  • Worker: I step in, complete my tasks and step out, no time consuming disturbance, no over hours, no weekend work

  • Manager: I make money with a reliable business

  • Customer: I get what I want with an acceptable quality for an acceptable price.

Closing the loop to Weisbrod: When we ask, who is the everybody who improves whole systems than workers, managers, and customers are part of the group named “everybody”.

So what is the new role of the SPI expert in an organization on the top of Weisbords learning curve?

Currently hierarchy and silos define organizations. Often processes do not reflect the work but the organizational boundaries. Mike Hammer (Hammer 2007) defined the ability of an organization to define processes across silos even across formal boundaries of legal entities as one major tool for organizational maturity. Even if this is a key ability for process capability, neither the old framework of ISO/IEC 15504 nor the new Framework of ISO/IEC 33003/33020 require cross boundary process designs.

When transforming a silo organization and helping the organization to make the next step in the learning curve, the SPI expert needs organizational background knowledge. The SPI expert has to have the capability to organize cross silo and cross boundary cooperation to empower people by giving them tools for problem solution. The SPI expert also understands the needs of systems at different levels, creating customer satisfaction and thus constantly assuring management commitment to SPI activities.

SPI experts will also face the challenge to help organizations, which are misled by so-called agile evangelists to get back to sustainable IT business.

5 Closing the Loop 2: The Learning Curve of Organizations and the SPI Manifesto

When revisiting the thesis of Weisbrod, it becomes clear that using his scheme to categorize his work, Weisbrod is an expert, an expert in organizational learning. His work is a perfect fit into his learning curve but still he is an expert who wants to improve organizations but he wants to improve y empowering people. Otherwise, there would be no progress and his prognosis that everyone will improve systems will become a fairytale.

So differentiating the author from the message there is a huge overlap between the prognosis of Weisbrod and the SPI Manifesto because the SPI Manifesto is focused on People (Fig. 6).

Fig. 6.
figure 6

The values of the SPI Manifesto revisited

Full size image

As a conclusion, driving an organization through the learning curve is not a matter of Methods. It is a matter of orientation (Empowering or commanding) and a matter of skills.

The SPI manifesto and the related PI manager training by delivering the necessary principles, values and tools will help the (S)PI professionals to deal with these challenges and successfully help organizations to improve their business y empowering their people.

But the SPI community should not lose the focus on implementing and improving the SPI manifesto.