Herbert Bellem über Software-Projekterfahrungen, Management-Training und Agile Methoden

Herbert Bellem war von 1981 bis 2012 in verschiedenen Funktionen in der Software-Entwicklung des IBM Labor Böblingen tätig. Er begann seine Karriere in der VSE- und MVS-Entwicklung. Als Leiter der Qualitätssicherung der Unix-Entwicklung (IX/370) stellte er die technische Verbindung her zu einer Partnerfirma in Kalifornien. Nach einem Aufenthalt in den USA übernahm er die Verantwortung für das System-Management auf MVS-Systemen. Parallel dazu koordinierte er das Management-Training. Später hatte er Verantwortungen für die Entwicklung von Programmen für das System-Management und für Finanzanwendungen. Zuletzt oblagen ihm die Entwicklerunterstützung für den Bereich Information Management. Bellem hatte in Saarbrücken Informatik studiert und bei Kurt Mehlhorn seine Diplomarbeit gemacht. Im Juli 2012 tritt er nach 31 Jahren bei derselben Firma in den Ruhestand.

Bertal Dresen (BD): Sie vertreten die erste Generation, die mit einer Ausbildung in Informatik zur IBM kam. Um sich an die Schwaben zu gewöhnen blieb Ihnen nicht viel Zeit. Gleich wurde ihre Arbeit international. Sie pflegten die Kooperation mit der Firma LOCUS in St. Monica, Kalifornien. Das Locus System des leider früh verstorbenen Jerry Popek war ein Unix, das es heute noch nicht gibt. Wie erlebten Sie Ihren Berufseinstieg? Was hat sich geändert für heutige Berufsanfänger? Was ist Ihre Erinnerung an die LOCUS-Gruppe und das LOCUS-System? Wo lag der Unterschied zur IBM als Großfirma?

Herbert Bellem (HB): Was den Berufseinstieg angeht, muss ich rückblickend sagen,  dass ich zwar von der Uni einen sehr guten theoretischen Background mitgebracht habe, was aber Programmiersprachen, Entwicklungsumgebungen und Entwicklungsprozesse angeht, habe ich doch vieles erst im Beruf gelernt. Zum Teil lag das daran, dass Rechner in meinen Studienjahren gleichzusetzen waren mit Großrechnern und damit ein knappes Gut waren, von dem man nur kleine Zeitscheiben an der Uni abbekommen konnte. Das hat sich in der Zwischenzeit dramatisch verändert: Rechenleistung ist überall zugreifbar und billig. 

Jeder Informatikstudent hat selbstverständlich einen eigenen Webauftritt und jede Menge Erfahrung in Sprachen und Entwicklungsumgebungen wie sie auch in der Industrie eingesetzt werden.  Firmen schätzen natürlich, dass Neueinstellungen so schnell produktiv sind. Was sich nicht geändert hat ist,  dass neue Mitarbeiter das aktuelle Wissen aus den Universitäten mit in die Unternehmen tragen. Das habe ich in meinen ersten Jahren erlebt und erlebe ich noch heute. 

Mit dem LOCUS-Projekt hat sich damals für mich ein erster Traum erfüllt – ich durfte mehrfach nach Kalifornien reisen und das in einem Zeitalter, wo es noch keine Billigflieger gab und Firmen ihre Mitarbeiter noch die Business Class gegönnt haben. Technisch fand ich das Projekt sehr ehrgeizig und viele Ideen finden sich heute in ‚Software as a Service‘ und in Cloud-Implementierungen. Zum damaligen Zeitpunkt war das System allen anderen weit voraus. Es fehlte aber die Robustheit und Stabilität. Ich war ja damals mit der Qualitätssicherung betraut und wurde von der dynamischen uni-nahen Startup-Mannschaft am Anfang manchmal mitleidvoll belächelt. Sie hielten sich alle für große Programmierer, die keine Fehler machen. Als unser Team dann mit automatisierten Tests und Coverage-Messungen verifizieren wollte,  dass das auch stimmt, haben sie uns anfangs noch tatkräftig unterstützt. Erst als die ersten Ergebnisse vorlagen und Qualitätsdefizite zu Tage kamen, war’s mit der Unterstützung vorbei. Letztendlich hat Jerry Popek dann doch eine eigene unabhängige Testgruppe etabliert. Ich habe in diesem Projekt viel gelernt. Zum einen, was ein kleines motiviertes Team – das waren die LOCUS-Leute – leisten kann, zum anderen aber auch, wie wichtig es ist ein ebenso motiviertes und kompetentes Team zu haben, was sich um die Qualitätssicherung kümmert.

BD: Schon bald nach Beendigung des LOCUS-Projekts verschlug es Sie nach Poughkeepsie, N.Y. Sie befassten sich dort mit Software zur Verwaltung von großen Systemen. Nach der Fusion mit der gleichnamigen Firma wurden diese Programme unter dem Namen Tivoli zusammengefasst. Sie dienen dazu, Rechner zu überwachen, Software zu verteilen, Systeme zu inventarisieren oder Daten zu sichern. Was bedeutete es für Sie, plötzlich ein Teil der Großsystemwelt (MVS, VM) zu sein? Welche Besonderheiten zeichneten diese Programme aus? Spielen sie heute noch eine Rolle?

HB: Ich habe ja im Großrechnerbereich als Programmierer angefangen und insofern war mir die Welt vertraut. Mir war aber auch klar, dass sich die Bedienung dieser Systeme dramatisch vereinfachen musste. Denn die ständig günstiger werdenden Hardwarepreise machten plötzlich die Operator, Systemprogrammierung und Administratoren zu den teuren „Ressourcen“. In meinen Anfangstagen bestanden die Systeme aus vielen Einzelkomponenten. Systemprogrammierer beim Kunden konnten und mussten sich daraus z.B. erst ein lauffähiges Betriebssystem zusammenstellen. Das überflüssig zu machen, war eines der wichtigsten Projekte zu meiner Zeit in Poughkeepsie und die Systemmanagement-Komponenten – für die ich verantwortlich war – waren ein wichtiges Element davon. Heute ist das alles zusammenpaketiert in z/OS.

In dieser Zeit begann auch das Imageproblem der Großrechner. Sie wurden von den Unix- und Windows-Fans als Dinosaurier dargestellt, in meinen Augen völlig zu unrecht. Klar gab es im Benutzerinterface noch Schnittstellen, denen man die Lochkartenzeit angesehen hat, gleichzeitig gab es schon damals auf dem Großrechner Konzepte, die erst viel später – und oft mit großem Hype – auf anderen Plattformen eingeführt wurden: Virtuelle Maschinen und Hochverfügbarkeit. Heute hat sich die Diskussion etwas versachlicht und es geht mehr um Fähigkeiten und Kosten und die Plattform rückt vor allem im Zeichen der Cloud in den Hintergrund.

BD: Später machten Sie einen fachlichen Sprung zu Anwendungen im Finanzbereich (System Merva). So viel ich verstehe, ging es dabei um Erweiterungen von WebSphere, um das SWIFT Internet Protocol Network (SIPN) zu unterstützen. Es heißt, dass Finanzler hohe Ansprüche bezüglich Sicherheit und Benutzbarkeit stellen. Wie machte sich dies für einen Entwickler bemerkbar? Was mussten Sie dazulernen, um Web-Anwendungen zu entwickeln?

HB: Merva war zu diesem Zeitpunkt ein etabliertes Programm, das von vielen Banken auf Großrechnern eingesetzt wurde, um mit dem SWIFT-Netz zu kommunizieren. SWIFT selbst hatte sich entschlossen, die Netzwerkprotokolle von X.25 auf ein modernes IP [Internet-Protokoll] umzustellen. Wir haben im deutschen Labor eng mit dem SWIFT-Konsortium, dem die wichtigsten Banken und Finanzdienstleister angehören, zusammengearbeitet und dabei nicht nur die Großrechnerlösung modernisiert, sondern auch eine UNIX-basierte Lösung mitentwickelt.

Und natürlich ist Sicherheit oberste Priorität für ein System, über das stündlich Milliarden von Euros abgewickelt werden. Hier kam uns die jahrelange Erfahrung der Mitarbeiter im Bereich Zahlungssysteme [im Böblinger Labor] zugute. Sie waren, was Sicherheitskonzepte angeht, auf der Höhe der Zeit und haben letztendlich auch SWIFT bei der Implementierung der entsprechenden Services beraten.

BD: Sie haben sich für die Einführung neuer Management-Methoden und die entsprechende Schulung engagiert. Ich erinnere mich an Wanderungen Im Tannheimer Tal in Österreich, wo wir mit verbundenen Augen durch ein Waldstück geführt wurden. Welche Auswirkungen auf das Team und seine Produkte ließen sich aufgrund dieser Schulung nachweisen? Sind die damals verkündeten Prinzipien der Teambildung und Teamführung heute noch relevant?

HB: Schon immer war ich der Überzeugung, dass es vor allem die Menschen sind, die ein gutes Entwicklungsteam ausmachen, ihr Wissen und vor allem ihre Motivation. Softwareprojekte lassen sich in meinen Augen nicht mit Operations-Research-Methoden managen, sondern brauchen vor allem ein motiviertes und funktionierendes Team. Ich habe im Laufe meiner Karriere einige Ansätze erlebt, Teams zusammenzubringen, Vertrauen ineinander zu stärken, sich auf gemeinsame Ziele zu einigen, offen zu kommunizieren und gemeinsam erfolgreich zu sein. Die Grundprinzipien und Fragestellungen haben sich meines Erachtens nicht geändert und finden sich auch bei der Agilen Entwicklung wieder.

Die „Pfadfinderspiele“ im Tannheimer Tal  ̶  auf die Sie Bezug nehmen  ̶  haben Themen wie Vertrauen in andere, Kommunikation und Verlässlichkeit in einer spielerischen Ebene vermitteln wollen. Wir waren damals eine der ersten Gruppen, die so etwas gemacht haben. Heute hat sich daraus ein ganzer Geschäftszweig von „Outdoor Teamtrainings“ entwickelt.

BD:  Zuletzt leiteten Sie eine Abteilung für Entwicklungsunterstützung. Was änderte sich im Laufe Ihrer Berufszeit, was Methoden und Werkzeuge anbetrifft, am meisten? Welche neuen Werkzeuge stellten besondere Anforderungen? Wo lagen die Probleme? Was sehen Sie als besondere Herausforderungen an, will man Entwickler optimal unterstützen?

HB: Wenn ich zurück denke an meine ersten Berufsjahre, dann kann ich es kaum glauben, wie primitiv die Entwicklungswerkzeuge damals waren: „Dumme“ Terminals dienten der Eingabe der Programme, Editoren hatten keinerlei kontextsensitive Hilfen, Compiler waren separate Werkzeuge. Komponenten und Komplettsysteme wurden zum ersten Mal als Ganzes zusammengebaut, wenn mehr als die Hälfte der Entwicklungszeit um war. Testen war eine weitgehend manuelle Angelegenheit und Projektmanagement fand mit handgemalten Charts statt. Und vielleicht der größte Unterschied: Entwicklungsteams arbeiteten im Wesentlichen an einem Standort.

Das sieht heute dramatisch anders aus: Nahezu alle Entwicklungsprojekte arbeiten mit internationalen Teams, verteilt über mehrere Zeitzonen. Integrierte Entwicklungsumgebungen, wie z.B. die Jazz-Plattform von IBM, unterstützen Entwickler, Tester und Projektmanager vom Requirements Management über Implementierung, Test, Integration und Driver-Bau bis hin zum Projektmanagement mit einem hohen Grad an Komfort und mit jeder Menge Hilfestellungen. Jeder bekommt zu jedem Zeitpunkt die Information, die er braucht, und am Ende eines Projektes weiß ich z.B. genau, welches Requirement durch welchen Code implementiert wurde, wie hoch der Aufwand dafür war, welche Testabdeckung ich dafür erreicht habe, welche und wie viele Fehler ich dabei gefunden und behoben habe. Das heißt auch, dass die Arbeit heute wesentlich transparenter geworden ist, was für manche Kolleginnen und Kollegen gewöhnungsbedürftig war und ist. Die Zeiten, als sich Programmierer noch als Künstler fühlten, sind vorbei. Software-Entwickler sind heute eher Ingenieure.

Wie unterstützt man Entwickler optimal? Indem man ihnen solche Umgebungen zur Verfügung stellt, also Umgebungen, die Hilfestellungen geben, aber auch Flexibilität erlauben, möglichst die Prozesse und Werkzeuge einzusetzen, mit denen sich das Gesamt-Team wohl fühlt.

BD: Sie waren auch ‚Evangelist‘ für Agile Methoden (z.B. Scrum). Ich habe den Verdacht, dass sich die Entwickler freuten, dass sie endlich ohne Planung loslegen konnten und keine Zeit mehr für Dokumentation draufging. Stimmt das? Welche Art von Projekten profitieren von Agilen Methoden? Wie groß ist deren Anteil im Labor? Was sind die harten Fakten, die man als Entwickler und Manager nicht außer Acht lassen sollte (also Dinge, die wir seinerzeit nicht wussten)?

HB: Agile Methoden haben sich zumindest in der Softwareentwicklung in den letzten Jahren weitgehend durchgesetzt. Ja, Sie haben recht: anfänglich hat schon der ein oder andere Entwickler gedacht, dass damit Prozesse und Dokumentation hinfällig sind. Um dieser Fehlinterpretation entgegenzuwirken, hat IBM deshalb seine Implementierung von Agilen Methoden bewusst auch ‚Disciplined Agile Development‘ genannt.

Für mich adressiert dieser Ansatz viele Fragestellungen, die wir eigentlich schon immer hatten, die sich aber in den letzten Jahren noch verstärkt haben: Wie entwickele ich genau das, was meine Kunden brauchen – und nicht mehr? Wie mache ich das effektiv und in hoher Qualität? Wie kann ich in jeder Projektphase noch auf neue  oder geänderte Anforderungen reagieren, ohne Endtermin, Aufwand und Qualität zu kompromittieren? Und nicht zuletzt: Wie sorge ich für eine optimale Einbindung und Kommunikation des Teams?

Viele Methoden und Techniken, die dabei zum Einsatz kommen, hätte man schon früher anwenden können z.B. Scrum Meetings, das Aufbrechen der Anforderungen in kleine Einheiten, die aus Benutzersicht formuliert sind, zeitlich fest terminierte, kurze Iterationen, an deren Ende das Ergebnis demonstriert wird. Andere sind meines Erachtens erst durch moderne Entwicklungsumgebungen möglich geworden, in denen hochgradig automatisierte Tests ablaufen und quasi jederzeit eine aktuelle Version der Software gebaut werden kann und auch wird. Auch das Entwickeln in weltweit verteilten Teams über mehrere Zeitzonen hinweg ist durch diese Tools und die heutigen schnellen Kommunikationsleitungen erst möglich geworden.

BD: Ihre Familie wohnt in Darmsheim, einem Stadtteil von Sindelfingen. Wie ich kürzlich las, sind sie Mitglied des Kirchengemeinderates der katholischen Pfarrei Dagersheim-Darmsheim. Was kann man als erfahrener Manager zu diesem Gremium beitragen? Gibt es ein nicht-fachliches Thema, dem Sie in der Nach-IBM-Zeit verstärkte Aufmerksamkeit widmen wollen? Was haben Sie in den 30 Jahren Ihres Berufslebens fürs Leben gelernt, auf das Sie nicht verzichten möchten?

HB: Ja meine Frau und ich fühlen uns heute im Schwabenland heimisch. Unsere drei Kinder fühlen sich genauso wohl, sind aber in der Zwischenzeit nach Bayern und in die Pfalz – für Saarländer eigentlich ein Unding  ̶  ausgewandert. Wir sind beide im Dorf aktiv. So bin ich seit über 12 Jahren im Kirchengemeinderat. Ja, in solchen Gremien profitiere ich sehr von meinen IBM-Erfahrungen: Strukturen zu verschlanken, effektiv Sitzungen zu leiten, Teams zu motivieren. Die Themen unterscheiden sich nicht sehr von der beruflichen Arbeit, nur dass man es mit Freiwilligen zu tun hat, die jederzeit nein sagen können.

Was habe ich gelernt? Ich denke sehr vieles, und vor allem, dass das Lernen nie aufhören darf. Wenn ich eine Sache herausheben soll, dann ist es die Erkenntnis,  dass für erfolgreiche Arbeiten und Projekte die Menschen und ihre Motivation das wichtigste sind.

BD: Herr Bellem, vielen Dank für das interessante Interview und herzlich willkommen in der Rentnerwelt. Bleiben Sie Ihrem Kirchengemeinderat auch bitte weiterhin treu.