Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten.
Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten.
Alle Mitglieder des MusicStore-Teams sitzen an ihren Computern und haben Kopfhörer auf den Ohren. Außer dem Klappern der Tastaturen sind keine Geräusche im Raum zu hören. Auf einmal kommt Erik, der Product Owner, zur Tür herein und spricht die Kollegen an.
Die Mitglieder des MusicStore-Teams haben sich zu einem Backlog-Grooming-Termin zusammengefunden. Erik, der Product Owner, hat einen Entwurf für ein neues Feature mitgebracht und stellt es den Kollegen vor.
Das MusicStore-Team hat vor einigen Wochen ein paar neue Funktionen am Recommender live geschaltet. Durch diese Änderung sollen die Kunden bessere Vorschläge erhalten, welche Musik für sie interessant sein könnte. Manuela, die sich um den Support für MusicStore kümmert, wendet sich an die Kollegen im Raum.
Es ist ein ganz normaler Tag im Büro des MusicStore-Teams. Lukas und Christian sitzen an Lukas’ Rechner und entwickeln im Pair Programming. Martin ist auf dem Sprung in eine Community of Practice[1].
Die beiden Entwicklerinnen Julia und Su unterhalten sich beim Mittagessen über Frauen in der IT-Branche.
Welches IT-Unternehmen kennt die Situation nicht? Man müsste unbedingt weitere IT-Spezialisten einstellen. Die bestehenden Teams sind schon überlastet und schieben diese Aufgabe deshalb gerne an die HR-Abteilung ab. Auch Lukas und sein Team denken hier sehr stark in Silos.
Projekte sind endlich, Produkte für die Ewigkeit. Viele Entwickler sind mittlerweile der Meinung, dass IT-Projekte eigentlich Produkte sein müssten, denn abgeschlossen ist das Projekt mit der Fertigstellung eben nicht. Wo genau es sinnvoller ist, Projekte durchzuführen und wann man von der Definition „Produkt“ Gebrauch machen sollte, erklärt Konstantin Diener in diesem Teil der DevOps Stories.
In einem crossfunktionalen Team bringen Kollegen aus unterschiedlichen Bereichen ihre Erfahrungen und ihr Wissen ein. Das kann über das reine Erstellen und den technischen Betrieb von Software hinausgehen. Gerade bei kleinen oder neuen Produkten lohnt es sich, Supportmitarbeiter direkt ins Team zu holen. Dann kommen die Schmerzen der Anwender direkt an.
Das eine Modell für die Kollaboration zwischen Dev und Ops gibt es nicht. Ganz grundsätzlich gibt es drei Möglichkeiten: Collaboration, Embedding und X as a Service. Aber welche davon ist die richtige? Auch hier sind die Kommunikationswege das entscheidende Kriterium.
Entscheidungen im Team zu treffen ist komplizierter als es auf den ersten Blick oft aussieht, denn es lauern einsame Wölfe, Technologieverliebte, zu viele Köche und Schatten-CTOs. Auch hier helfen klare Regeln, die gemeinsam aufgestellt und eingehalten werden.
