Montag, 26. Oktober 2020

Der Product Owner als Key Account Manager

FS
Bild: Pexels / Christina Morillo - CC0 1.0

Eine der zentralen Vorraussetzungen von agiler Produktentwicklung ist die Etablierung von so genannter Product Ownership. Um für den eigenen Fortschritt nicht auf andere angewiesen zu sein wird eine möglichst starke Focussierung angestrebt. Ein einziges crossfunktionales Team exklusiv für ein Produkt, mit allen Berechtigungen es verändern und modifizieren zu dürfen. Nur so ist das schnelle Inspect & Adapt möglich, das den Kern aller agilen Vorgehensweisen bildet.


Der de facto Standard dieser Umsetzungen ist mittlerweile Scrum, das in seinen Teams sogar eine explizite Rolle für Product Ownership hat, sinnigerweise Product Owner genannt. Richtig umgesetzt ist der nicht nur ein einfacher Business Analyst oder Anforderungsmanager sondern er entwickelt sein Produkt langfristig und strategisch weiter, hat den Überblick über vergangene Entscheidungen und hält Kontakt zu dessen Anwendern und Stakeholdern.


Soweit die Theorie. In den meisten Fällen ist sie anwendbar, in einigen allerdings nicht. Im Agentur-Umfeld kommt es beispielsweise vor, dass Teams für einzelne Sprints an Kunden verkauft werden um an dessen Systemen zu arbeiten, in Konzernen kann es sein, dass die Zuordnung eines Teams zu einem Produkt nur so lange anhält wie die dahinterstehende Fachabteilung Projektbudget hat. In diesen und vergleichbaren Fällen springen Teams und Product Owner regelmässig von Produkt zu Produkt.


Um die negativen Effekte dieser ständigen Wechsel zumindest in Grenzen zu halten findet man in manchen Unternehmen eine Ausgestaltung der Product Owner-Rolle die in Teilen einem Key Account Manager entspricht, also dem Hauptbetreuer eines wichtigen Kunden oder Auftraggebers. Für diesen ist der jeweilige Product Owner dann der primäre Ansprechpartner in der Anwendungsentwicklung, selbst dann wenn es um verschiedene (weiter)zu entwickelnde Produkte geht.


Was in einer solchen Konstellation weiterhin möglich ist, ist eine dauerhafte Beziehung zu wichtigen Anwender- und Stakeholdergruppen. Andere Auswirkungen können zumindest abgeschwächt werden: die Kontextwechsel werden tendenziell weniger, da die Wahrscheinlichkeit steigt auch zukünftig wieder mit den Produkten zu tun haben, und vergangene Erfahrungswerte können in diesen Fällen wiederverwertet werden.


Ganz ersetzen kann eine solche Konstellation echte Product Ownership nicht (alleine deshalb nicht weil zwischendurch andere Teams daran arbeiten können), in den oben genannten Konstellationen ist sie aber eine gute Möglichkeit dem zumindest so nah zu kommen wie möglich.

Donnerstag, 22. Oktober 2020

Der Agile Song

FS

Auf die Gefahr hin in diesem Monat eine leichte Schlagseite in Richtung "agile Netzfundstücke" zu bekommen - das hier ist dann doch zu bemerkenswert um es hier nicht einzubetten. Der "Agile Song"  von Adam Janosch wurde gestern auf dem kölner Scrumtisch zwischen den Sessions gespielt und zumindest bei mir ist er direkt im Ohr hängen geblieben.


 


Um es auf eine Meta-Ebene zu hieven: dass es Werke wie dieses Lied gibt würde ich in ein Phänomen einordnen, dass ich einmal The Soft Power of Scrum genannt habe. Viele Umsetzungen dieses und anderer Frameworks sind bewusst verspielt, bunt und geekig gehalten, und das nicht etwa als von oben verordnetes Image-Programm sondern weil die an der Umsetzung Beteiligten sich über das rein Berufliche hinaus mit dem Vorgehen identifizieren und ihre Energie und Kreativität einfliessen lassen. Das ist etwas was nur sehr wenige andere Projekt-, Produkt- oder Prozessmanagement-Ansätze über sich sagen können.

Dienstag, 20. Oktober 2020

Agile Bauprojekte (IV)

FS
Bild: Wikimedia Commons / Michael Wolf - CC BY-SA 3.0

Die Zukunft hat bereits begonnen. Noch vor kurzem galten agile Vorgehensweisen bei Bauvorhaben als etwas hochgradig Theoretisches, mittlerweile können wir eines mitten in Deutschland beobachten. Die Tesla-Gigafactory 4 bei Berlin wird iterativ-incrementell gebaut (nachzulesen bei der SZ): zuerst werden kleinere, schnell fertigzustellende Gebäude errichtet, deren Konstruktionsgeschichte wird ausgewertet und die Erkenntnisse fliessen als Verbesserungen in die nächstgrösseren Bauvorhaben ein, und das in Rekordzeit. Wie ist das möglich?


Ein lesenswerter Artikel der Zeit (leider hinter einer Paywall) liefert einige Antworten. Es beginnt mit den bekannten Faktoren, die z.T. auch den schnellen Bau der chinesischen Corona-Kliniken geprägt haben: Einfachheit, Standardisierung, Modularisierung, Entbürokratisierung und wenn möglich Wiederverwendung der Pläne von bereits erfolgreich abgeschlossenen vergleichbaren Bauvorhaben. Im Mittelpunkt stehen aber zwei weitere, bei Bauprojekten hochgradig unübliche: Risiko-Toleranz und Fehlerkultur.


Um nachvollziehen zu können warum das ein Paradigmenwechsel ist muss man auf das Risikomanagement klassischer Bauprojekte schauen. In ihm wird versucht Risiken dadurch zu begrenzen, dass die Beteiligten in möglichst detaillierten Verträgen regeln was welcher der beteiligten Geschäftspartner zu welchem Zeitpunkt zu erbringen hat. Gelingt einem von ihnen das nicht hat er für die entstehenden Mehrkosten aufzukommen, die anderen aber nicht.


In der Theorie mag das wie eine sinnvolle Umsetzung der Verursacherprinzips aussehen (wer Aufwände und Verzögerungen verursacht zahlt), in der Realität führt es aber zu ausufernden Vertragsverhandlungen, absurd detaillierten Vertragswerken, dem Zweckentfremden von Flexibilitätsreserven, extrem aufwändigen Prozessen bei nachträglichen Anpassungen und oft auch zu erbittert ausgefochtenen Rechtsstreitigkeiten. Die dadurch entstehenden Kosten und Aufwände gehören dann zu den stärksten Treibern von Budget- und Zeitplan-Überschreitungen.


Um derartige Entwicklungen gar nicht erst aufkommen zu lassen werden beim Bau der Gigafactory 4 bewusst Risiken eingegangen: statt der üblichen Festpreis-Verträge für bestimmte Gewerke erhalten die Baufirmen pauschale Aufwandsvergütungen, wenn für den schnellen Baufortschritt mehr Geld benötigt wird als initial geplant ist der Freigabeprozess unbürokratisch und wenn derartige Mehraufwände entstehen liegt das Hauptinteresse nicht auf dem Finden und Bestrafen von Schuldigen sondern auf dem schnellen Reagieren auf die geänderten Rahmenbedingungen.


Letztenendes wird hier ein systemischer Ansatz sichtbar. Natürlich kann es sein, dass bei diesem Vorgehen Teile des Gesamtvorhabens teurer werden als gedacht. Durch den bewussten Verzicht auf Detailregelungen, Prozessverflechtung und (juristische) Konflikte wird die Umsetzungsdauer aber derartig verkürzt, dass die frühe Betriebs- und Wertschöpfungsfähigkeit (und das dadurch mögliche frühere Erwirtschaften von Gewinnen) das bei weitem ausgleichen dürfte.


Für alle die das nicht so ganz glauben können hält der deutsche Standort von Tesla übrigens noch eine schöne Pointe bereit. Nur 30 Minuten Autofahrt entfernt kann man begutachten wohin klassisches Management eines Bauprojektes führen kann. Die Rede ist vom neu gebauten Berliner Flughafen, der jetzt endlich eröffnet wird - neun Jahre nach dem ursprünglich geplanten Termin und deutlich teurer.

Donnerstag, 15. Oktober 2020

Ein Bild sagt mehr als 1000 Worte (XXX)

FS

Wow. einfach wow.

Montag, 12. Oktober 2020

Everything I know about teams, I learned from computers

FS

Das ist ein wundervoll nerdiger und ganz anderer Ansatz auf Teams zu schauen als der den man meistens vorfindet. Andrew Harvey nimmt sein Wissen über verteilte Systeme, überträgt sie auf die Zusammenstellung und das Managen von Teams - und das funktioniert erstaunlich gut.




Was ausserdem hervorzuheben ist sind die im Vortrag enthaltenen Anregungen sich in weitere Themen einzuarbeiten. Von den Neurowissenschaften bis zu den acht Irrtümern über verteilte Systeme ist Einiges dabei was sich zu erforschen lohnt.

Donnerstag, 8. Oktober 2020

Altsysteme (III)

FS
Screenshot: Flickr / Josiah Ritchie - CC BY-SA 2.0
Legacy Software ist immer ein ergiebiges Thema, so auch im folgenden aktuellen Fall. Im Rahmen der Nachverfolgung von Coronavirus-Infektionen ist den britischen Gesundheitsbehörden eine massive Datenpanne unterlaufen: die Daten von fast 16.000 Tests gingen verloren, und das zunächst unbemerkt, mit unabsehbaren Folgen für die Verbreitung der Pandemie. So einzigartig wie dieser Fall erscheinen mag, seine Ursache ist weit verbreitet - das Verwenden einer hoffnungslos veralteten Standardsoftware.


Die ganze Geschichte kann man bei der BBC nachlesen: der die Tests durchführende Dienstleister trug die Ergebnisse zuerst in eine CSV-Datei ein und schickte diese dann an die Behörde Public Health England (PHE). Diese übertrug sie in das dort bevorzugte Tool, Excel von Microsoft. Und bei dieser Übertragung kam dann es zum unbemerkten Datenverlust. Der Grund dafür - die verwendete Excel-Version war zu alt. Warum das ein Problem ist lässt sich einfach erklären.


Bis zum Jahr 2007 speicherte Excel seine Dateien im XLS-Format ab, das bereits im Jahr 1987 eingeführt worden war. Neben anderen Problemen hat dieses alte Format eine Grössenbegrenzung auf genau 65.536 Zeilen, werden mehr eingegeben werden diese einfach nicht gespeichert. Seit 2007 sind daher neuere Excel-Versionen im Einsatz, die Dateien im XLSX-Format abspeichern, mit bis zu 1.048.576 Zeilen (die Erklärung dieser scheinbar krummen Zahlen findet sich hier).


Dem die Testergebnisse zuliefernden Dienstleister dürfte nicht bewusst gewesen sein, dass der PHE seit mindestens 13 Jahren nicht mehr in der Lage gewesen ist sein Excel auf die aktuelle Version upzudaten (warum das so sein dürfte steht hier) und vermutlich wusste der PHE auch nicht, dass seine alte Version die oben erwähnte Beschränkung hatte. Ohne zu ahnen, dass das ein Problem war wurde also eine viel zu hohe Menge an Datensätzen geliefert1, von denen dann alles ab Zeile 65.537 aufwärts beim Übertragen in Excel verloren ging.


Die grundlegenden Phänome die man aus dieser Geschichte ableiten kann: wenn veraltete Versionen einer Standardsoftware im Einsatz bleiben nehmen Anwender oft ohne darüber nachzudenken an, dass Eigenschaften der neuen Versionen (z.B. hohe Speicherkapazität) auch in der alten bereits vorhanden sind. Ausserdem geraten Probleme der alten Version (z.B. ausbleibende Warnungen bei Datenverlust) in Vergessenheit, da sie in der neuen unbekannt sind.


Um nicht den damit verbundenen Risiken ausgesetzt zu sein empfiehlt sich ein permanentes Updaten aller Standardsoftwares auf die jeweils neueste Version. Wenn zu starke Anpassungen vorgenommen wurden kann das zwar aufwändig werden, dass es trotzdem Sinn macht dürfte aber spätestens seit der Datenpanne des PHE offensichtlich sein.



1Da jeder Datensatz mehrere Zeilen enthält konnten pro Datei nur 1.400 gespeichert werden

Montag, 5. Oktober 2020

Geht zur nächsten Windows-Schulung!

FS
Bild: Pixabay / Escola Espai - CC0 1.0

Würde man nach Veranstaltungen suchen die in der IT hochgradig unbeliebt sind, dann gäbe es sicher eine die weit vorne dabei ist: die verpflichtende Microsoft Windows-Schulung, die in vielen Unternehmen für jeden Mitarbeiter vorgesehen ist der neu ist oder der eine neue Windows-Version erhält1. Jeder der in der Softwareentwicklung tätig ist wird alleine bei der Ankündigung genervt fragen was er da noch lernen kann. Die überraschende Antwort - sehr viel, vorausgesetzt eine Sache ist gegeben. Der eigene Arbeitskontext muss einer sein bei dem Anwendungen für den internen Gebrauch entwickelt werden.


Was sich in diesem Fall hier gewinnen lässt ist ein gutes Verständnis der eigenen Zielgruppe, schliesslich sind die Kollegen in dieser Schulung im Zweifel auch die, die später auch die Software benutzen werden an der man selbst arbeitet. Und selbst wenn es um diese in dem Moment nicht geht - man kann trotzdem beobachten wie die Interaktion mit neuen Funktionen und Benutzeroberflächen vor sich geht und Rückschlüsse daraus ziehen.

 

Die offensichtlichste Erkenntnis betrifft die EDV-Affinität. Kennen die Schulungsteilnehmer die Fachbegriffe ("Was ist ein Browser?"), wissen sie wie man durch Dateien navigiert ("Im C-Laufwerk ist nichts") und sind ihnen die wichtigsten Troubleshootings bekannt ("Das Programm hatte sich aufgehängt, ich hab es mit dem Task-Manager geschlossen")? Basierend auf diesen Informationen kann entschieden werden wie kompliziert die eigene Anwendung sein darf und wie gut sie dokumentiert sein muss.


Auch über die Bereitschaft sich in neue Funktionalitäten einzuarbeiten und neue Designs zu akzeptieren kann man hier viel lernen. Gibt es Beschwerden darüber, dass Outlook nicht mehr gelb ist? Wird Freude darüber geäussert von Skype auf Teams-Calls umzusteigen? Abhängig davon kann entschieden werden ob Bedienelemente oder Styleguide sich eher an bisherigen Standards orientieren sollten oder ob man Neues ausprobieren kann.


Ein weiterer Aspekt sind die Hilfsmittel die üblich sind und ggf. erwartet werden. Reicht eine Beschreibung in Textform? Werden Anleitungen mit kommentierten Screenshots erwartet? Gibt es eine Akzeptanz für Wikis, Chatbots und Schulungsvideos oder wird ein Kursleiter erwartet der Fragen beantworten und bei Problemen helfen kann? Für das Rollout der eigenen Features kann später auf dieses Wissen zurückgegriffen werden.


Eine oft vernachlässigte Erkenntnis bezieht sich auf den Grad des Austausches zwischen den Kollegen. Bitten sie sich gegenseitig um Hilfe oder bieten sie sich diese sogar von selbst untereinander an? Oder sitzt jeder still vor seinem Rechner und ruft nur den Kursleiter per Handzeichen zu sich? Je nachdem was der Fall ist kann es für das eigene Produkt ausreichend sein nur jeweils einem "Multiplikator" pro Team Neuheiten vorzustellen oder besser alle einzuladen.


Nicht zu unterschätzen ist auch, dass man lernen kann wie gerne überhaupt in Schulungen gegangen wird. Von "endlich mal was Neues" bis "während wir hier Zeit verschwenden türmt sich bei uns die Arbeit" sind alle möglichen Reaktionen denkbar, und aufbauend darauf kann entschieden werden ob man zukünftig eher häufig oder eher seltener zu Demonstrationen und Hands on-Sessions einlädt.


Zuletzt, und vielleicht ist das sogar das Wichtigste, kann man auf Windows-Schulungen auch etwas über sich selbst lernen. Kommen einem bestimmte Dinge vielleicht selbstverständlicher vor als sie sind (um das Naheliegendste zu nennen - geht man z.B. davon aus, dass eigentlich jeder weiss wie Windows funktioniert)? Und kann es sein, dass man in die eigene Zielgruppe viel von sich selbst hineinprojiziert? Die Antwort auf diese Fragen kann ernüchternd sein, sie verhindert aber, dass man Anwendungen versehentlich für sich selbst entwickelt statt für die Menschen für die sie eigentlich gedacht sind. 


1In vielen Firmen ist die Umstellung auf Windows 10 noch nicht abgeschlossen. Ein eigenes Thema.

Powered by Blogger.