Gordon kennt Lukas von der gemeinsamen Arbeit in einer Community of Community of Practice . Er hat ihn gebeten, ihm bei einem Programmierproblem zu helfen. Deshalb sitzen sie in Gordons Teamraum gemeinsam vor dessen Computer.

Nur noch wenige Stunden bis zum Sprint-Review. Das MusicStore-Team arbeitet intensiv daran, letzte Stories fertigzustellen.

Ruben, der Scrum Master des MusicStore-Teams, ist gerade von einem längeren Termin gekommen, betritt den Vorraum der Toilette und wird zufällig Zeuge einer Unterhaltung.

Lukas hat sich mit seinem alten Studienkollegen Arne getroffen. Wie früher in ihrer Studenten-WG haben sie schon eine ganze Zeit die Spielkonsole traktiert. Jetzt machen sie eine Pause, weil der Pizzalieferant gerade ihr Abendessen gebracht hat.

Die letzte Woche des Septembers ist vorbei und stand ganz im Zeichen von Java: Java 11 wurde veröffentlicht und erregte eine Menge Aufmerksamkeit. Außerdem zeigte Sven Ruppert in seinem Fachartikel, was der JDK-Release-Zyklus konkret für Entwickler bedeutet. Und auch das Release von Spring 5.1 hatte einige Neuerungen im Gepäck.

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.

Sollte man zu funktionalen Expertenteams zurückkehren? Aufgrund der vielen Vorteile der crossfunktionalen Produktteams möchte das keiner so richtig. Ideal wäre es, wenn man bei crossfunktionalen Teams bleiben könnte, ohne die Vorteile der Expertenteams ganz zu verlieren.

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.

Aus funktionalen Teams sind crossfunktionale Teams geworden. Da heißt es, sich mit den neuen Kollegen zusammenzuraufen. Und weil der Chef keine Entscheidungen mehr für das Team trifft, muss das Team das selbst regeln: mit einem Teamvertrag.

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.