Auch am dritten Tag des Konferenzduos International PHP Conference und International JavaScript Conference haben wir spannende Sessions besucht. Was nehmen wir davon mit nach Hause?
Jahrelang bestimmte klassisches Projektmanagement den Alltag und das Denken in Unternehmen. Ganz plötzlich und fast wie von allein sollen agile Ansätze wie Scrum oder Kanban gleich einem Allheilmittel alles anders und am besten sofort erfolgreicher machen. Allerdings widerspricht das dem Grundprinzip von Agilität. Sie lebt von Inspect and Adapt und dem kontinuierlichen, iterativen Anpassen, ohne dabei das Bestehende aus den Augen zu verlieren. Es geht dabei nicht um einen faulen Kompromiss. Jedoch gilt es, auf dem Weg hin zu agilem Projektmanagement Hybridität zuzulassen, damit der für Ihre Firma passende Agilitätsgrad entwickelt werden kann, ohne sich dabei selber zu überholen.
Unternehmen mit differenzierten Konzernstrukturen tun sich teilweise schwer, sich auf neue Anforderungen seitens des Markts einzustellen. Vielfach gelangen aktuelle Projektvorgehen in eine Sackgasse, da die Strukturen und Systeme solcher Projekte maßgeblich durch unflexible und starre Mechanismen gesteuert und eingebunden sind. So auch im Fall eines Unternehmens, bei dem wir geholfen haben, Wege aus der Sackgasse zu finden - mit Scrum.
Wir neigen dazu, an essenzielle Themen mit einem gewissen Dualismus heranzugehen. „0 oder 1“, „dafür oder dagegen“, „Freund oder Feind“. Agile, für die digitalisierte Welt geeignete Projektorganisationsformen eignen sich hervorragend für dualistische Debatten. Gartner befürwortet bimodal, Forrester kritisiert es. Lassen Sie uns gemeinsam hinter die Fassade der Diskussion sehen und erkunden, ob es nicht doch einen pragmatischen Mittelweg gibt.
Scrum kennt die Rollen Product Owner, Scrum Master und Entwickler, aber nicht die Rolle „Architekt“. In einer klassischen Teamhierarchie wird die Softwarearchitektur allein durch den Architekten verantwortet. Im selbstorganisierten Scrum-Entwicklungsteam dagegen gibt es keine Rangfolge, und die Entwickler sind gleichberechtigt. Wie entsteht die Softwarearchitektur in einem Scrum-Team im Unterschied zur traditionellen Methodik?
Sie wollen agil werden. Also benennen Sie die Rollen in Ihren Teams um, machen alle Meetings und Rituale, über die Sie im Scrum Guide gelesen haben, und machen Zwei-Wochen-Sprints. Aber reicht das wirklich, um agil zu werden?
Selbstverantwortliche Teams klingen manchmal wie ein Traum: Man verbindet damit autonom agierende Gruppen mit der Kompetenz, eigenständige Entscheidungen zu treffen. In den meisten Fällen entspricht das allerdings nicht der Realität. Wir wollen uns in diesem Artikel anschauen, wie Architekten, Scrum Master und Product Owner den Kontext, in dem ihre Teams arbeiten, so gestalten können, dass selbstverantwortliche Teams möglich werden und nicht nur ein Traum bleiben.
Scrum ist doof, so beginnt die Geschichte „Der Scrum Master“ von Jürgen Knuplesch, selbst Scrum Master, agiler Berater, Autor, Mathematiker, Trainer, Theologe und vor allem Mensch. Als agiler Enthusiast und Pragmatiker versucht er jeden Tag die Welt ein wenig zu verbessern, was ihm aber nur selten gelingt. In unserer Fortsetzungsgeschichte gibt er einen Einblick in seinen umfangreichen Erfahrungsschatz.
Magazin Zahlen & Fakten Methoden Kolumne: A² – alles Agile PRINCE2: Grundprinzipien Titelthema Full Stack GraphQL Schneller Start dank durchdachter Frameworks GraphQL...
Schwerpunkt der BASTA! 2018 ist in diesem Jahr die Cloud. Ziel der Konferenz ist es, mithilfe einer praxisorientierten Herangehensweise die "Cloud down to earth" zu holen. Aber auch Themen wie Agile, Progressive Web Apps oder Open Source kamen nicht zu kurz.
Ist die Architektur-Metapher für ein Verständnis von Softwareentwicklung noch hilfreich? In Teil 2 des Artikels erarbeiten wir ein Modell, das besser auf die Anforderungen agiler Softwareentwicklung angepasst ist als die Metapher der Architektur: Mannschaftsspiel im Profifußball
Die Welt, besonders die der Computer und ihrer Software, wird immer dynamischer und volatiler. Ist unter diesen Bedingungen die Metapher vom Bauen wirklich noch hilfreich? Sollte Softwareentwicklung nicht besser als ein Mannschaftsspiel verstanden und der Softwarearchitekt als Trainer seines Entwicklungsteams gesehen werden?
