Enterprise Transformation by Donovan Brown : Azure Saturday Keynote Report

 

„Enterprise Transformation (and you can too)“

Bei diesem Vortrag von Donovan Brown auf dem Azure Saturday in München ging es um die Arbeitsstruktur innerhalb des Microsoft-Konzerns und die Themen Projektmanagement, Zeitplanung im Unternehmen sowie Teamwork.

Nachfolgend möchte ich die für mich wichtigsten Aspekte in eigenen Worten wiedergeben und versuchen Ihnen, dem Leser, ein möglichst gutes Bild des Events zu geben.

Wie in meinem anderen Beitrag speziell zum Azure Saturday 2018 zu lesen, war dieser Vortrag der erste Punkt auf der Agenda des Events. Thematisch ist er im Bereich DEV einzuordnen.

Aufgrund der Überfüllung des normalen Raums hatte ich das Glück den Vortrag live im Premium-Raum zu sehen und mir einen Eindruck von Donovan Browns Ideen und Anregungen zu verschaffen.

 

20180526_090923

 

Ein leinwand-großes Bild eines Rennwagens, war das Erste was Brown den Teilnehmern präsentierte. Der Rennwagen und der schnelle Reifenwechsel zeigen die Veränderung, die unsere Industriegesellschaft gerade durchläuft. Schaut man sich einen Formel 1 Reifenwechsel vor 30 Jahren an und vergleicht ihn mit heute, fällt eines sofort auf: Es werden mehr Menschen eingesetzt und der ganze Ablauf geht um ein Vielfaches schneller.

Es geht längst nicht mehr nur um die Arbeit zwischen „Mann und Maschine“, denn der Strukturwandel im Arbeitsbereich bietet nun die Herausforderung und Chance der Teamarbeit, der vermehrten Kommunikation und der größeren Arbeitsteilung.

 

20180526_183041

 

„Change what hurts most“ war das Prinzip, welches Donovan Brown für die Effizienzerhöhung vorstellte. Man sollte in einem Projektablauf immer den Teil ändern, der am meisten Zeit verbraucht beziehungsweise am ineffizientesten ist. Bei unserem Rennwagen Beispiel, war dies das Nachfüllen des Sprits. Dieser Arbeitsschritt wurde in den letzten Jahren konsequent optimiert und somit beschleunigt. Man sollte also salopp gesagt den Fokus immer auf das legen, was einem am meisten zu schaffen macht.

Wer nun einen Schritt weiter denkt entdeckt, dass dies zwangsläufig dazu führt, dass anschließend etwas Neues an die Stelle des ersten Problems tritt. Dieses Neue ist zumeist das vorherige Zweitschlechteste. Man könnte argumentieren, dass man mit dem „Change what hurts most“ Ansatz somit nie zu einem Ende der Optimierung kommt. Und ja das stimmt, aber macht nicht genau das auch den Entwicklungsprozess eines Produktes aus?

Des Weiteren sollte man laut Brown die zeitliche Komponente nicht vergessen. Es geht nicht darum einen Projektplan für die nächsten zwei Jahre aufzustellen, sondern darum einzusehen, dass sich dieser Plan immer wieder verändern wird. Zwei Jahre sind für die Industrie eine sehr lange Zeit, welche man nicht vorausplanen kann. In seinem Vortrag verdeutlichte Brown, dass bei einem für 18 Monate ausgelegtem Projekt, spätestens nach 6 Monaten eine radikale Planänderung zu erwarten ist. Dies ist keinesfalls negativ gemeint, denn jede Veränderung bedeutet hier nur eine optimierte und notwendige Anpassung an die neuen Verhältnisse.

 

20180526_183029

 

Das letzte Drittel des Vortrags widmete Brown dem Thema des Umgangs der Kollegen untereinander. Ein, wie ich finde, wesentlicher Aspekt, wenn es um die Strukturierung eines Unternehmens geht. Es wurde verdeutlicht, dass Menschen sich so verhalten, wie man sie behandelt. Konkret soll dies heißen, dass wenn man jemanden wie ein Kind behandelt, er sich auch wie ein Kind benehmen wird. Behandelt man jemanden wie einen Erwachsenen, verhält er sich erwachsen. Darin liegt gemäß Brown der Grundstein für verantwortungsvolles Arbeiten.

Stichwort „If you write it, you run it“. Dieser Ansatz soll dazu führen, dass bessere Programmtests geschrieben werden und man nicht einfach einen schlechten, ungetesteten Code an das nächste Team abwälzt. Diese Verantwortung für sich und die eigene Arbeit ist zentraler Aspekt effizienter und funktionsfähiger Programme.

In Anlehnung an Programmtests schlug Brown die Nutzung von Bug Bars vor. Diese zeigen die Fehlerrate von Programmen an und lassen somit Schlüsse auf die Qualität des Codes zu. Trotzdem ermahnte er die Teilnehmer davor bei zu hohen Fehlerwerten keine Demotivation der Entwickler herbeizuführen. „Don not punish your engineers“ war einer der Sätze, die er mehrmals wiederholte. Ich denke, was er damit sagen wollte war, dass diese Bug Bars den Code verbessern sollen, jedoch nicht die Stimmung der Mitarbeiter verschlechtern.

 

20180526_121725

 

Zusammenfassend lässt sich sagen, dass die Hauptaspekte einer guten Projekt- und Unternehmensstruktur in der realistischen Zeitplanung, dem koordinierten Optimieren des Worstcase und dem richtigen Umgang der Mitarbeiter untereinander liegen.

Abschließend möchte ich Ihnen noch Donovans wichtigsten Tipp verraten:

„There is no better test, than using your own Software!“