Neulich hatte ich ein interessantes Gespräch mit einer Kollegin zum Verständnis der Agilität in Unternehmen, insbesondere im kaufmännischen Bereich.
Wir haben aktuell damit zu kämpfen, dass die Stakeholder 1. zu viel Einfluss auf das Backlog nehmen und 2. nicht wissen, was Agilität genau bedeutet. Der PO ist also nur ein Proxy, der die Planung im Entwicklungsteam vornimmt.
Zudem haben wir noch die Schwierigkeit, dass die Stakeholder keine langfristige Planung vornehmen und Themen sehr verstreut und kleinteilig einwerfen.
„Wir arbeiten doch agil“ – So oder so ähnlich lauten oftmals die Sätze wenn es dann darum geht ungeplante Themen einzuwerfen.
Doch das ist keine Agilität, sondern Ungeplantheit durch Flexibilität aufzufangen.
Wir sind zu dem Entschluss gekommen, dass im kaufmännischen Bereich die Agilität am besten mit OKR funktioniert um eine längerfristige Planung und Fokus zu haben. Aus unserer Sicht benötigt es diese 4 Schritte um die Grundsteine für die Etablierung der Agilität im Unternehmen zu legen. Wir arbeiten unbewusst bereits nach diesen 4 Schritten, wobei wir #1 nachholen werden.
#1 agile Denkweise etablieren
Damit die agile Denkweise, das agile Mindset, von allen gleich verstanden wird ist es zwingend erforderlich eine Keynote über die Agile Denk- und Arbeitsweise zu halten. Nur so erreichen alle wichtigen Personen (Stakeholder und Vertreter, PO’s und Entwickler) mit einem Termin und können ihnen ein gleiches Bild vermitteln, damit sie an einem Strang ziehen. Zudem machen wir so klar, dass sich IT und Business auf Augenhöhe bewegen und ersticken das Hierarchiedenken somit im Keim. Es besteht eine Interdependenz zwischen IT und Business und diese muss klar und bewusst sein, damit im Sinne des Unternehmens das bestmögliche erreicht werden kann.
#2 regelmäßige Unterstützung in der Arbeitsweise
Um sicherzugehen, dass die Arbeitsweise richtig gelebt wird, werden die Teams in IT und Business von Agile Coaches begleitet. Sie sorgen dafür, dass auch wirklich agil gearbeitet und gehandelt wird. Wenn etwas in alte Muster verfällt oder etwas gegen die agile Arbeitsweise spricht, sagen sie Stop und sorgen dafür, dass die agile Arbeitsweise angewandt wird.
#3 längerfristige Planung (OKR’s)
Falls es noch keinen Plan gibt, wo das Unternehmen in den nächsten Monaten (3 oder 6) hinsoll, so ist es zwingend erforderlich dies zu nachzuholen und die Objectives und Key Results im ganzen Unternehmen zu veröffentlichen. Planen, planen, planen! Bis zu einem gewissen Punkt funktioniert das alles ohne klaren Plan (wie bei meinem aktuellen Arbeitgeber), wenn dein Unternehmen jedoch wächst solltest du dafür bereit sein die Kapazitäten den wichtigen Themen zuordnen zu können und eine klare Strategie zu haben.
Denn Agilität bedeutet: Flexibel auf einen Plan zu reagieren und ist nicht der Ersatz von Planung durch flexbiles jonglieren von Themen.
#4 Priorisierung auf Unternehmensebene
Stehen die Objectives und Key Results, so müssen daraus die Initiativen abgeleitet werden um die Ziele zu erreichen. Damit wir die wichtigen Ziele zuerst erreichen müssen wir zwingend eine Priorisierung der Initiativen vornehmen. Die Priorisierung der Initiativen findet im kaufmännischen Entscheidungsbereich des Unternehmens statt um im Sinne des Unternehmenserfolgs zu handeln. Nachdem die Priorisierung durchgeführt wurde, werden die Themen dann in die Entwicklung gegeben, die dann für die Umsetzung allein verantwortlich ist.
Fazit
Agil zu arbeiten bedeutet nicht nur in der Entwicklung Scrum oder Kanban einzuführen, sondern es ist essentiell IT und Business gleichermaßen mit der agilen Denkweise auszustatten, damit die Zusammenarbeit funktioniert und alle beteiligten ihre Rolle korrekt ausführen können. Dazu ist es wichtig, dass es einen Plan, einen sogenannten roten Faden gibt, damit die Entwickler den Sinn hinter ihrer Arbeit sehen. Durch kleinteilige Anforderungen, die auf kein Ziel einzahlen wird die Motivation der Entwickler herausgefordert. Kurzfristig ist das kein Problem, langfristig gesehen muss dies jedoch zwingend unterbunden werden. Da spreche ich aus eigener Erfahrung als Entwickler.