Fehlende Software-Qualität kann auch große Unternehmen gefährlich stolpern lassen!

Dass fehlende Qualität von Software ein Unternehmen in Krisen führen kann, bestätigt sich auf jeden Fall dann, wenn anhaltende Probleme mit einen unter­nehmenskritischen neuen System den CFO zu einer Gewinnwarnung zwingen und so auch die Aktionäre beunruhigen.

Sie glauben nicht, dass so was passiert? Nun, hier ist ein Beispiel:

Wie die Computerwoche berichtet, droht das misslungene neue Computersystem “New Forwarding Environment” (NFE) die Deutsche Post im Frachtgeschäft um Jahre zurückzuwerfen.

Deteils finden sich auf FinanzNachrichten.de in einer Meldung vom 29.10.2015:
 

Larry Rosen, der Finanzchef der deutschen Post, erklärt, NFE sei zu fehleranfällig und müsse wohl ersetzt werden, was Jahre dauern könne, denn eine neue, weniger komplexe Lösung stehe kurzfristig nicht zur Verfügung.

Man überlege nun, schrittweise neue Komponenten zu integrieren und habe Rückstellungen in Höhe von 37 Millionen Euro gebildet für Ausgaben zur erwarteten Rückabwicklung des Systems in den bereits umgestellten Pilotländern.

Der Bonner Konzern schätze die Wahrscheinlichkeit, aus dem derzeitigen System positive Effekte erzielen zu können, als sehr gering ein und habe deshalb auch Abschreibungen in Höhe von 309 Mio. Euro vorgenommen.

Die bereits nach dem zweiten Quartal 2015 schon einmal korrigierte Prognose sei nun nicht mehr zu halten.

 

Nachdenklich macht: NFE basiert auf Software von SAP und wurde mit IBM Global Business Services als Implementierungspartner umgesetzt.

Da sollte man sich schon fragen, wie es zu einem solchem Unglück kommen konnte.

Eines dürfte klar sein:

Obgleich zu akzeptabler Software-Qualität weit mehr gehört als nur die Abwesen­heit von Programmierfehlern, wird sie doch (vom Software-Lieferanten) gerne auf genau solche reduziert gesehen. Dem Auftraggeber fällt das zunächst gar nicht auf.

Doch können denn wirklich nur Programmierfehler so ein Desaster verursachen, wenn das System auf Code beruht, den SAP und IBM entwickelt haben (Firmen also, von denen man erwartet, dass sie kompetentes Personal einsetzen)?

Meine etwa 30-jährige Erfahrung mit Software-Entwicklung sagt mir, dass ein System, dessen Anforderungen vor Beginn der Programmierung genau und vollständig schriftlich spezifiziert und entsprechend gründlich durchdacht worden sind, von erfahrenen Programmierern auf keinen Fall derart verkorkst werden kann, dass es nicht gelingt, alles wesentliche Fehlverhalten innerhalb weniger Monate, wenn nicht Wochen, beseitigen zu können.

An was aber mag es denn dann liegen, dass selbst weltweit bekannte Software-Lieferanten wie IBM — solche, denen man größtmögliche Erfahrung unterstellt — ein System abliefern, welches seine Anwender und Betreiber als kaum nutzbar, auf jeden Fall aber als nicht länger tragbar einstufen?

Mein Verdacht: Man wird wohl versucht haben, nach dem Agilen Manifest zu arbeiten — nach dem Vorgehensmodell also, das seit der Jahrtausendwende unter dem Label “Agile” hochgelobt wird, weil junge Entwickler sich nicht mehr die Mühe machen wollen, die klassischen Verfahren des Software-Engineerings wirklich zu verstehen und der inzwischen neu hinzugekommenen Notwendigkeit, maximal flexibel zu sein, erfolgreich anzupassen — auch und gerade unter der Neben­bedingung, dass heute fast alle Entwicklungsaufträge zum Festpreis vergeben werden.

Wenn die Deutsche Post jetzt plant — und sich sogar gezwungen sieht — “eher evolu­tionär” vorzugehen (wie Rosen sich ausdrückt), klingt mir das schon fast nach einer Wiederholung des von mir vermuteten Fehlers.

Will man wirklich riskieren, dass ich recht habe? Will man nicht zuerst über die Ursachen des Mißerfolgs nachzudenken?

Oder will man einfach nicht einsehen, dass der klassische Weg, Software zu ent­wickeln, eher Erfolg garantiert als SCRUM-artig gestaltete Prozesse in Kombination mit dem blinden Glauben an die Effektivität der allzu naiven Prinzipien des Agilen Manifests?

Ist uns denn nicht bewusst, dass Agile, SCRUM und dieser ganze verhängnisvolle, viel zu wenig durchdachte Trend auf eine kleine Gruppe von Wartungsprogram­mieren zurückgehen, die dachten zu wissen, wie man wirklich große Software-Entwicklungsprojekte so durchführt, dass (fast) nichts mehr schief gehen kann?

Wer glaubt, man könne die Wahl des Prozessmodells zur Entwicklung einer umfangreichen IT-Lösung einfach der Mode oder nur an ihren Code denkenden Programmierern überlassen, der irrt gewaltig.

Dem CIO der Deutschen Post jedenfalls kann man nur raten, die Ursachen seines Desasters genau zu identifizieren.

Versäumt er das, könnte die Deutsche Post in einer eher noch folgenreicheren IT-Sackgasse landen. Ob es dann noch reichen würde, einfach nur eine Gewinn­warnung herauszugeben, kann bezweifelt werden.
 

Advertisement

Why IT Contracts should address Questions of Agility

What exactly is Agility in Software Development?

One definition is: To get a nice (software) solution is more important than to sit on a no longer useful contract.

There is no need to make Agile Software Development a complicated concept: We only have to realize which kind of agility will help in modern IT projects.

But never forget: There is one important consequence you and your client should be aware of: Agile and Fixed Price are like Fire and Water — if not tamed they simply annihilate each other (and do so in many unexpected ways).

The case De Beers vs Atos Origin is ample proof of this fact.

To avoid similar desasters, there is only one possible solution:

Before starting a software development project, suppliers and customers, in their contract, should agree not only on the scope of work and a project plan — the basis for a possible fixed price — but also on how to deal with any changes that might become necessary. This is the part specifying a specific degree of agility the project partners promise, or should promise, each other.

The accusations brought forward in the lawsuit De Beers vs Atos Origin clearly show that agility could become necessary on both sides (not only on supplier’s side).

To summerize:

• Agility is nothing more than to acknowledge that changes to the contract itself may become unavoidable.
   
• The contract should forsee this possibility.
   
• Contracts not addressing this issue can become a problem: The supplier may even end up being accused of fraudulent misrepresentation (as EDS was as a supplier of BSkyB).

 
To learn more you may want to read:

• Contracting Agile Projects
• Agile Contracts Primer

 

Against misunderstandig Agile

Most people — Agile evangelists are no exception — tend to define Agility via a specific way of working (e.g. via SCRUM) or via the Agile Manifesto (which is a set of too easily – and by far too often – misunderstood principles totally ignoring the CIO as one of the most important stakeholders).

But to really understand what it means to become agile as a software developer (or a developer’s client) in some positive manner

• we have to understand Agility as a Necessity to survive in today’s fast changing environment,
• we have to adopt the right Agile Attitude,
• and we have to accept Agile as a Best Practice.

If you don’t believe me, there are others who also say:

• We are tired about reading misinformation about Agile,
• Agile is certainly not SCRUM (or some other specific process), and
• Agile is often used for an excuse not to work professionally enough.

 

Agile Methods (so far) ignore CIO’s Interest

Gartner as well as Cutter Consortium tell us about more and more clients who realize that agile methods — if defined by XP, SCRUM, or the Agile Manifesto — let developers forget that they should also think about product features that are to guarantee maintainability of the software in the long run.

And indeed: So far the problem is that in contrast to a Software Owner (a CIO), the typical Product Owners in the sense of SCRUM do not think beyond the development phase of the software life cycle.

After trying out Agile for some years, CIOs more and more realize that teams doing agile software development left chaos: software that is neither well defined nor easy to maintain.

Evangelists of Agile should accept that Software Owners are stakeholders quite different from Product Owners and that therefore Agility as defined by the Agile Manifesto is far from being professional enough.

This is why we need

• The New (2011) Definition of Agile
  and
• Agile Methods no longer ignoring a prominent stakeholder: the CIO.

A process model for software development not ignoring CIO’s interest is Specify, Subcontract, Test (SST).

 

Be agile – forget the Manifesto

One fact is: The world around us is moving faster and faster, and so we must learn to become agile (in software development, but also in project management and everywhere else).

Fact is also: The still ongoing, now already more than 10 years old discussion about how to be agile (especially when developing software) so far did not generate much progress.

The reason for this sad fact clearly is that the Agile Manifesto is leading us into a wrong, less professional direction.

Why this is so and why, therefore, we need to focus on the goal of Agile rather than on the misleading way suggested by the Manifesto, is convincingly explained in the document The New (2011) Definitions of Agile.

To read that paper (2 pages only) is a MUST for everyone interested in Agile.

By far the best introduction to Agile is the short article Best Practice Agile.