Wie bleibt eine Anwendungsarchitektur bei mehreren Teams konsistent? Klassischerweise gibt es dafür eine zentrale Architektur-Instanz, die genaue Vorgaben an die Entwickler-Teams weiter gibt. Doch scheint ein solches Vorgehen im Kontext agiler Software-Entwicklung nicht mehr zeitgemäß zu sein. Dennoch müssen gerade in großen Projekten, die mit mehreren Teams arbeiten, gewisse architektonische Entscheidungen übergreifend getroffen werden. In der Kolumne Groß und (Fr)agil stellt Timo Becker eine Lösung für dieses Problem vor: Die Architektur mit Tigern.

Sprint-Reviews und Retrospektiven – diese beiden Regel-Meetings aus der Scrum-Welt lassen sich nicht ohne weiteres auf große Agile-Projekte übertragen. Wie man dennoch auch in großen Szenarien die gewünschten Effekte der regelmäßigen Reviews erzielen kann, ist heute das Thema unserer Kolumnisten Christoph Niemann und Timo Becker.

Im dritten Teil der Kolumne „Groß und (Fr)agil?“ greift Christoph Niemann ein Thema heraus, mit dem jedes Entwicklerteam umgehen muss: Es geht um die Frage, wie sich die immer vorhandenen Wissensunterschiede im Team ausgleichen lassen. Wie stellt man sicher, dass wichtiges Know How nicht siloartig an Einzelpersonen hängen bleibt?

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen. Heute geht es um den richtigen Schnitt von Teams.

Mit diesem Beitrag starten Christoph Niemann und Timo Becker in ihre neue JAXenter-Kolumne: „Groß und (fr)agil?“ Sie erhalten handfeste Tipps aus der Praxis, wie sich Agilität auch in großem Maßstab betreiben lässt, ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!