CAS Agile Organisation

making your organisation agile

Archive for the 'Team Agility' Category

4 Hauptwerte des agilen Manifestes

Posted by Cindy Wittmer on 25th October 2019

In meinem heutigen Blogg werde ich die 4 Hauptwerte des agilen Manifestes erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden. Leider ist der Prozess im Moment aber so aufgesetzt, dass der persönliche Austausch nicht vorgesehen ist. Als eigenständige Personen können wir uns aber selbstverständlich trotzdem dafür entscheiden – aber ob das jeder tut?

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich hab schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.   sdqformat

erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden.·      

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.·    

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich habe schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Obwohl bei uns in der Unternehmung festgelegt Planungssheets zur Verfügung stehen, steht und fällt der sinnvolle Umgang mit dem Projektleiter. Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.

Posted in Agile Basics, Team Agility | No Comments »

Bestandesaufnahme – wie agil ist unser Team?

Posted by Doris Petermann on 9th November 2018

Doris Kubli und ich führen ein Team von 11 Fachexperten resp. Projektleitenden in der Berufsbildung. Wir beide haben zwei Rollen, Führungsperson und Projektleiterin – seit anfangs August 2018. Unsere gemeinsame Absicht ist es, das Team agiler zu „führen“.

Wo steht das Team aktuell?

Das Team leistet Entwicklungs- und Projektarbeit. Aufgrund von Veränderungen (Transformation 4.0, Kundenbedürfnisse) überarbeiten sie die Berufslehren im öffentlichen Verkehr oder entwickeln neue Produkte (Lehren, Fachausbildungen). Sie haben oft komplexe Aufgabenstellungen zu meistern.

Ich beurteile die folgenden Erfolgsfaktoren in Bezug auf unser Team:

  • Rollenklarheit: Mittels Stellenbeschrieben und Zielvereinbarungen werden die Aufgaben bei den Mitarbeitenden geklärt. Es zeigt sich jedoch in verschiedenen internen Diskussionen, dass die Aufgaben und Kompetenzen und damit die Erwartungshaltung der Firma gegenüber dem Entwicklungsteam geklärt werden müssen. Sie sollen „Eierlegende Wollmilchsäue“ sein, die Innovationspotential frühzeitig erkennen, Kunden Strategie konform beraten, Projekte professionell führen, qualitativ hochstehende Produkte mit wenigen finanziellen und personellen Mitteln entwickeln und die internen und externen Abnehmer befähigen und so alle glücklich machen. Mission impossible… vor allem mit dem aktuellen Arbeitsvolumen.
  • Interpersonale Zusammenarbeit: Die Einbettung im Team ist für die meisten zentral, da sie oft als Einzelkämpfer unterwegs sind. Desksharing hat ihre diesbezügliche Befindlichkeit negativ verschärft. Sie schätzen die punktuelle Zusammenarbeit sehr und sind sehr hilfsbereit. Oft gibt es aber stressige Momente, wenn sie sich inhaltlich auf Produkteebene abstimmen müssen und einen gemeinsamen Konsens finden müssen. Dies manifestiert sich in oft in den Teamsitzungen, die alle zwei Wochen vormittags stattfinden. Traktanden werden in eigener Verantwortung eingegeben, die Sitzungsleitung wechselt. Jede/r Mitarbeitende/r hat ein Ressort und übernimmt so auch Führungs- oder Koordinationsaufgaben für das ganze Team.
  • Lernorientierung: Das Team ist grundsätzlich offen für Neuerungen: Eine gewisse Müdigkeit und Überforderung macht sich aufgrund der vielen Änderungen (mehrere Projekte aus der Strategieumsetzung) bemerkbar. Die VUCA-World (Umgang mit Veränderungen) habe ich seit anfangs Jahr alle 1 bis 2 Monate thematisiert, Massnahmen wurden gemeinsam abgeleitet.
  • Informeller Austausch im Team: Die gemeinsamen Kaffeepausen oder Mittagessen werden sehr geschätzt und gesucht. Immer wieder organisieren die Mitarbeitenden auch einen Apéro, der bei allen auf offene Ohren stösst.

Wie werden wir agiler?

Die aktuelle Situation ist teilweise unbefriedigend. Grundsätzlich schätzen die Produktmanager/innen ihre Arbeit und das Team sehr. Die Arbeitslast (zu viel auf einmal, endlose Abstimmungsprozesse) ist jedoch das grosse Thema, wie auch wieder die jüngste Mitarbeitendenzufriedenheitsumfrage gezeigt hat.

Rollenklärung

  • Rollen- statt Stellenbeschrieb: Rollenbeschriebe sind auch durchlässig, sprich sie sind nicht „fix“ und abgrenzend zu verstehen, wie manchmal Stellenbeschriebe ausgelegt werden. Aus meiner Sicht macht es Sinn, zwischen Projektleitende (explorative Arbeit) und Produktmanager (operative Arbeit, Bereich KVP) zu unterscheiden. Es sind unterschiedliche Typen Menschen mit verschiedenen Stärken, die es pro Funktion braucht. Die Rollen müssen auch ggü einer GL transparent gemacht resp. ein gemeinsames Bild erarbeitet werden.

 Selbstorganisiertes Team

  • Führungs- und Koordinationsaufgaben aufs ganze Team verteilen: Bereits jetzt haben die Teammitarbeitenden sogenannte Ressorts, Koordinationsaufgaben (z. Bsp. Finanzen), die sie fürs gesamte Team übernehmen.
  • Kurzer Teamaustausch statt lange Sitzungen: Geplant haben wir nun wöchentlich eine Stunde Temaustausch statt alle zwei Wochen eine halbtägige Teamsitzung. Hier müssen wir jedoch noch unterscheiden zwischen „Stand ups“, also Übersicht und Planung von aktuell laufenden Aufgabenpakete und Austauschrunden zur Meinungsbildung. Jeder übernimmt hier Verantwortung, dass seine “Statusberichte” aktuell sind und er sich an die gemeinsamen Regeln hält.
  • Boards“ statt Papier: keine Traktandenliste und Protokolle mehr, die niemand liest. Kanban-Boards pro übergeordnete Teamaufgabe / Projekt scheinen für unsere Aufgaben hilfreich (siehe meine Ausführungen weiter unten).
  • Stärken-orientierte Teams: Teams in Subgruppen oder durchlässige „Bubbles“ (crossfunktional: unterschiedliche Stärken..) zusammensetzen, die ihre Arbeiten / Projekte selber verteilen und organisieren. Idealerweise haben wir solche „Bubbles“ pro Berufswelt, also für die handwerklichen Berufe, die Berufe „Büro und Kunden“, die MINT-Berufe und die übergeordneten Aufgaben. Fokus ist aber dabei, One Team“ zu sein mit der Idee, über den Tellerrand hinaus zu schauen.
  • Selfrecruiting statt verordnete Arbeitsgruppen: Warum rekrutieren die Mitarbeitende pro “Bubble” ihre Teammitglieder nicht selber? Warum werden die Projektmitarbeitende jeweils vermeintlich richtig ausgewählt? Die Arbeitsgruppe weiss ja selbst, was sie am ehesten braucht.

Interpersonale Zusammenarbeit

  • Regelmässige Teamretrospectiven statt punktuelle Feedbackrunden: Wir hatten bereits Feedbackschlaufen, aber zu wenig regelmässig. Teamretrospektiven, d.h. Feedbackrunden zur Zusammenarbeit einführen; idealerweise geschieht dies anhand der gemeinsam definierten Werten. Ganz im Sinne: Never stop learning…
  • Meinungsbildung statt lang anhaltende Diskussionen: eine Meinung bilden mit dem Ziel eine „konsente“ Lösung zu finden. Das heisst, nur noch berechtigte Einwände gegen die bestehende Lösung werden diskutiert, ansonsten gilt die formulierte Lösung. Dies braucht Disziplin!
  • Unsere Haltung: Unser genseitiges Vertrauen ist zentral; das gibt psychologische Sicherheit. Der Satz dazu ist mir geblieben: „Wer etwas sagt, dem wird nichts getan“.
  • Informeller Austausch fördern: wie bis anhin…

Welche Methoden unterstützen unser “agiles” Team?

Team führen ist von gestern – Team sich selber organisieren zukunftsführend. Das heisst, ich muss auch andere Methoden einführen, die das Team unterstützen. Folgende sehe ich:

Konstruktive Kontroverse:

  • Wozu? Ist eine Methode, die Konflikt- und Problemlösung unterstützt
  • Geeignet? Ja – oft haben wir die Herausforderung, eine konsolidierte Lösung zu generieren. Es gibt viele unterschiedliche Perspektiven, wie z. Bsp. Kundensicht, interne Umsetzung, Wirtschaftlichkeit, die wir „zusammenführen“ möchten. Besonders gefallen hat mir, dass man sich in die andere Perspektive versetzen muss, hilft sehr für das gegenseitige Verständnis.

Impact-Mapping

  • Wozu? Übersicht / gemeinsames Zielbild und Handlungsfelder für ein eher strategisches Thema erzeugen.
  • Geeignet? Ja – wir haben oft Abstimmungsprobleme zwischen der Geschäftsleitung / Strategie und was dies effektiv für die Entwicklung neuer Produkte konkret heisst. So haben wir aktuell den Auftrag, einen Innovationsprozess (siehe CAS-Projektarbeit) einzuführen. Hilfreich wäre nun, sich erstmals zu fragen, wozu wir Innovationsmanagement einführen.

Passion Modell

  • Wozu? Standortbestimmung um herauszufinden, ob ein Team agil unterwegs ist.
  • Geeignet? Ja – allerdings würde ich diese Standortbestimmung pro Teammittglied machen lassen und dann die Selbsteinschätzungen zu einem Bild zusammenfügen. Vielleicht wäre die Anwendung dieses Modelles ein guter Einstieg in Richtung agile Organisation. So sind erste „Hebel“ erkennbar.

Retrospective

  • Wozu? Feedback abholen und Hypothesen zu Verbesserungen ableiten. Agil heisst nun, dass ich Feedback-Loops nun häufiger durchführe als erst ganz am Ende eines Projektes oder eines Bildungsganges.
  • Geeignet? – Jein. Die vorgestellte Methode ist jedoch sehr umfassend und braucht Zeit und Geduld. Im Projek- oder hierarchisch geführten Team sehe ich die Häufigkeit bei max. einmal pro Monat. Sinnvoll scheint mir auch eine Kombination von eventuell zwei Methoden, eine kürzere (siehe „Retr-o-mat“, https://retromat.org/de/?id=18-7-66-103-104) und diese hier.

Kanban

  • Wozu? Bringt Ordnung in anfallende Projekte oder Aufgaben, hilft zu priorisieren und fokussieren, visualisiert gut und schafft ein gemeinsames Verständnis. Ist geeigneter, wenn die Planung durch äussere Einflüsse öfters gestört wird und die Aufgabe / das Projekt durch eine dafür definierte Arbeitsgruppe (nicht fixes Team) umgesetzt werden muss.
  • Geeignet? – Ja. Kanban kann bei login für unterschiedliche Ideen umgesetzt werden: Portfoliomanagement („Flight Levels“ gemäss Klaus Leopold), Abstimmungsprozess für Team übergreifende Aufgaben wie z.  Bsp. Einführung neuer Sicherheitsregeln bei allen Berufen und in der Projektplanung in einzelnen Projekten. Da wir viele Teilzeit-Angestellte haben, eignet sich Kanban besser.

SRUM

  • Wozu? Agile Methode für Produktentwicklung, nicht nur in der IT-Welt; klare Regeln und Wertehaltungen helfen, strukturiert, transparent und kooperativ zusammen zu arbeiten, komplexe Anforderungen in kleinere Bestandteile zu unterteilen und die Qualität und die anvisierte Vision zu überprüfen resp. zu sichern. Mit der Auslieferung von Teilleistungen, die dem Kunden aufgezeigt werden, kann laufend sichergestellt werden, dass der erhoffte Mehrwert generiert wird und das Produkt ein Erfolg wird.
  • Geeignet? – Jein. In reiner Form sehe ich aktuell die Umsetzung bei login eher weniger. Zu viele politische Abhängigkeiten und Störfaktoren ändern aktuell den Projektverlauf. Normalerweise kann kein Team ungestört über längere Zeit in nur einem Projekt tätig sein. Die Wertehaltungen oder die Idee der Reviews oder Retrospectiven können aber auch gut bei uns im Team umgesetzt werden.

Zusammenfassung

Es gibt viel zu tun… ab Januar 2019 packen wir es an, begleitet von einem agilen Coach. Der gemeinsam gezeichnete Flip zur Teamzusammenarbeit hilft mir, den Überblick zu behalten.

Das Zusammenspiel der drei „Systeme“  – Team, Produktentwicklung, Stakeholder – muss fluid und gut aufeinander abgestimmt sein.Jedes einzelne System muss gepflegt und gefördert werden, damit der Output (Zufriedenheit, Qualität) erhöht werden kann.

Immer gilt: Der Mensch steht im Fokus, Werte müssen gelebt werden.

 

 

 

 

 

 

Posted in Knowhow-Transfer, Team Agility | No Comments »