Schlagwort-Archive: agil

Microtrainings – Sinn oder Unsinn?

Allgemeines

Microstrainings sind Minni-Workshops, die in der Regel zwischen 15 und 60 Minuten dauern können. Sie eignen sich um schnell und kompakt Wissen zu einem speziellen Thema zu vermitteln.

Wann

Diese Art der Wissensvermittlung lässt sich einfach und unkompliziert in unterschiedlichem Kontext einbauen.

Ich nutze diese gerne um Scrum-Teams schnell verschiedene Kommunikations- und Konfliktlösungstool beizubringen. Die Microtrainings nutze ich aber auch um „große“ Schulungen vor- und nachzubearbeiten.

Sie eignen sich außerdem auch perfekt um Beispielsweise neue Produkte für Verkaufsteams, oder interessante Programmiermethoden und/oder –lösungen vorzustellen.

Microtrainings benötigen nicht viel Zeit und lassen sich Scrum-Events, wie einer Retrospektive, gut nachlagern. Auch als Vorbereitung für Scrum Master-Teams, wenn diese eine große, agile Veranstaltung organisieren  sollen, sind sie ideal.

Rentabilität

Als Vorbereitungsmaßnahme vor Kursen unterstützen sie einen einfacheren Wissenstransfer während des Kurses und nachgelagert geschickt eingesetzt,  können sie das Wissen noch vertiefen.

Auch als niedrigschwelliges Einstiegangebot zum Kennenlernen einer Dienstleistung oder eines Wissensthemas eignen sie sich optimal.

Durchführung

Organisatorisch ist der Aufwand oft gering. Die Vorbereitungen sind in der Regel nicht so umfangreich wie bei einem 2-Tageskurs. Und sie können auch mal spontan, einfach mit Flipchart & Stift, abgehalten werden.

Aus meiner Praxis empfehle ich eine Gruppengrüße von 4 – 6 Teilnehmern, vor allem wenn ich nach der Inhaltsvermittlung noch einen Frageblock einplane. Bei mehr Teilnehmern werden sonst die Diskussionen oder Fragen zu umfangreich und sprengen die time box.

Sollen mehr Teilnehmer einer Gruppe geschult werden, dann mache ich auch mehrere Termine.

Microtrainings können auch modular, aufeinander aufbauend, durchgeführt werden. Durch die kleine Gruppengröße ist eine Umsetzung oft auch einfach am Arbeitsplatz oder in der Mittagspause möglich. Oft werden keine speziellen Kurs- oder Meetingräume benötigt.

Die besten Erfahrungen habe ich, wenn ich mit meinem tragbaren Minni-Whiteboard mit den Teilnehmern eine Microtraining  im Park oder einfach irgendwo  im Freien veranstalte.

Aufbau

Ein Microtraining ist im Grunde wie ein „normaler“ Kurs aufgebaut:

  • Begrüßung & Fokussierung der Teilnehmer: Nach einer kurzen, wertschätzenden  Begrüßung hole ich sie zuerst aus ihrem (Arbeits)Alltag weg von ihren Gedanken, in den Raum. Dazu habe ich eine große Anzahl agiler Spiele in meinem Methodenkoffer die ich situativ anwende, d.h. je nach Stimmung und mentalem Zustand der Teilnehmergruppe.
  • Sinn der Trainingssession: Danach erkläre ich den Sinn und vor allem das Ziel der Trainingssession, also was das konkrete Ergebnis des Microtrainings sein soll.
  • Informationsvermittlung: Nun beginnt die eigentlich Vermittlung der Inhalte der Trainingssession. In der Regel nutze ich dabei gerne einen Mix aus vorbereiteter Präsentation (Flip Charts oder  PowerPoint) und während der Session entsteht in der Regel auch ein oder mehrere neue Plakate auf dem Flip Chart Board, der Planwand oder auf einem White Board.
  • Übung: In der Regel baue ich danach eine Übung ein, in der die Teilnehmer das Gelernte erleben könne.  Wenn wir etwas selber erleben, bleibt es haften. Von reiner Theorie, also Frontalvorträgen, bleiben in der Regel nur 10% bis 15% hängen.
  • Feedback: Nach der Veranstaltung lass ich mir auch gerne ein Feedback geben zum Inhalt und zum Rahmen der Veranstaltung.  Auch hier gibt es mannigfaltige Möglichkeiten zu messen wie zufrieden die Teilnehmer sind.
  • Abschluss: Auch hier platziere ich eine wertschätzende Verabschiedung.
(c) 2019 (AML)

Tipps für angehende Scrum-Master: Das „Daily Scrum“-Event

Können Sie sich erinnern, was Sie vor ein paar Tagen gegessen haben? Oder vor einer Woche oder einem Monat? Wir erinnern uns nur an die außerordentlich köstlichen (oder außerordentlich schlecht schmeckenden) Mahlzeiten.

Aber alle waren wichtig, auch wenn wir uns nicht an sie erinnern. Denn wenn wir keinen von ihnen gegessen hätten, wären wir jetzt nicht am Leben. Ebenso schadet es nicht, ab und zu eine Mahlzeit zu verpassen. Wenn Sie dies jedoch häufig genug tun, verlieren Sie langsam an Gewicht und werden schwächer.

In diesem Sinne sind tägliche Scrums, die „daily standup events“, wie Essen: Sie spielen eine entscheidende Rolle, um den Entwicklungsprozess des Scrum-Teams gesund zu halten. Für manche Menschen ist diese „agile Mahlzeit“ jedoch ein nicht gut schmeckendes Gericht. Manchmal kann sich das Daily lästig, unnötig oder unangenehm anfühlen, und Sie würden es lieber ganz überspringen.

Hier sind einige Einwände, die Sie möglicherweise von Mitgliedern des Scrum-Teams oder sogar vom Management in Bezug auf das tägliche Scrum hören könnten:

„Es ist langweilig. Die Tätigkeiten an denen anderen arbeiten, haben nichts mit meiner Arbeit zu tun. Die interessieren mich ja gar nicht.“:

Aber: Das daily scrum event  ist ein Weg, um alle über das, woran alle anderen arbeiten, auf dem Laufenden zu halten. Dies ist wichtig, um ein funktionsübergreifendes Team aufzubauen. Die Teammitglieder erfahren auch, wie die Arbeiten, an dem sie arbeiten, in die Arbeiten anderer Personen passt. Dies ist besonders wichtig, wenn nicht alle Teammitglieder an demselben Projekt arbeiten.

Und selbst wenn sie an völlig unterschiedlichen Anwendungen arbeiten, können die Probleme, mit denen die einzelnen Teammitglieder konfrontiert sind, gemeinsame Merkmale aufweisen. Wenn Peter hört, dass Andrea, ein Junior-Teammitglied, mit einem Problem zu kämpfen hat, das sie zu beheben weiß, kann sie diese Gelegenheit nutzen, um Andrea zu coachen.

„Entwickler sprechen bereits den ganzen Tag miteinander. Dafür brauchen wir kein tägliches Treffen. „:

Die spontanen Unterhaltungen, die während des Tages stattfinden, sind in der Regel „Tagesgeschäft“ im Scrum: Peter hat einen Compilerfehler. Michael benötigt einige Informationen von Andrea, bevor er eine Schnittstelle definieren kann. Peter kann nicht herausfinden, warum eine Datei fehlt und so weiter. Sie konzentrieren sich auf die Behebung sofortiger Probleme, während das daily scrum event eher ein taktisches Planungstreffen ist in dem der Status der Arbeit aus dem aktuellen Sprint besprochen wird.

Es ist keine Besprechung zur Problemlösung, sondern eine Besprechung, bei der der Staus bekannt transparent gemacht und Probleme die unsere Arbeit behindern oder verhindern  (impediments) bekannt gegeben werden. Das Team findet so heraus wer blockiert ist und wer helfen kann.

„Dies ist doch nur eine Statusbesprechung. Die Zeit können wir uns sparen um zu arbeiten“:

Ja, Entwickler teilen ihren Status. Aber das ist wie sich zu beschweren, dass Sie einatmen müssen, um zu atmen. Wenn das daily scrum event nur aus der Beantwortung der drei Fragen besteht, was ich getan habe / was ich tun werde / was mich behndinert und nichts anderes, dann ist es in der Tat nur eine Statusbesprechung.

Aber genau wie Sie nicht atmen können, indem Sie nur einatmen und niemals ausatmen, wird Ihr daily scrum event  nicht wirken, wenn die gesamte Kommunikation die vom Entwickler kommt zurückgehalten wird. Es handelt sich bei dem täglichen event  um ein Meeting, bei dem für die Tagesarbeit im Scrum schwerwiegendere Probleme auftreten können, wenn niemand etwas kommentiert oder weitere Fragen stellt.

„Es ist ineffektiv oder unhöflich, wenn Sie niemanden außer Entwicklern daran teilnehmen lassen.“:

Das daily scrum ist. losgekoppelt von den technischen Details, ein Meeting auf höherer Ebene, aber nur für kurze Zeit. Wenn das Team das so sieht, sind sie möglicherweise weniger geneigt, auf „fremde“ Teilnahme zu bestehen. Und mit einer 15-minütigen time-box  bleibt ohnehin nicht viel Zeit für andere Personen, um effektiv teilzunehmen.

Daily Scrum zu haben ist wie eine gesunde Ernährung. Möglicherweise möchten Sie dies nicht immer tun, und einige der Mahlzeiten sind möglicherweise langweilig oder gelegentlich ausgesprochen schlecht schmeckend, aber Sie können sie nicht überspringen. Sie sehen möglicherweise keine unmittelbaren negativen Auswirkungen bei Nicht-Einhatung, und die Leute sind möglicherweise sogar glücklich darüber.

Dies wird jedoch die Beweglichkeit und den Zusammenhalt des Teams im Laufe der Zeit beeinträchtigen. Ebenso kann es natürlich einige Zeit dauern, bis sich positive Effekte durch das daily manifestieren, aber sie helfen auf jeden Fall dem Team sich zu verbinden und ein höheres Leistungsniveau zu erreichen

(c) AML 2019

Der Agile Podcast – Scrum und Agilität in der Praxis

Der Agile Podcast - Scrum und Agilität in der Praxis

Willkommen zu meinem "Agilen Podcast"

Ich werde an dieser Stelle in unregelmässigen Abständen neue Folgen meines "Agilen Podcasts" veröffentlichen. Es geht dabei um die praktische Umsetzung von Agilität und Scrum im IT- und Wirtschaftsumfeld in mittleren und großen Firmen. Aktuell sind rund 62 Folgen geplant...

Folge 1 - Wer ich bin und warum ich diesen Podcast produziere

Folge 2 - Warum in Deutschland plötzlich so viele Firmen agil werden wollen

Folge 3 - Was bedeutet Agilität?

Folge 4  Das agile Manifest - Regel Nummer 1

Folge 5  Das agile Manifest - Regel Nummer 2

Folge 6  In Vorbereitung: Das agile Manifest - Regel Nummer 3

Folge 7  In Vorbereitung: Das agile Manifest - Regel Nummer 4

Folge 8  In Vorbereitung: In Vorbereitung; Agile Frameworks

Folge 9  In Vorbereitung: Das agile Mindset

Folge 10  In Vorbereitung: Der agile Manager - Kontrolle von komplexen Systemen

Folge 11  In Vorbereitung: Softskills und Agilität

Folge 12  In Vorbereitung: Allgemeines zu SCRUM

Folge 13  In Vorbereitung: Projektdurchführung - Agil oder klassisch?

Folge 14  In Vorbereitung: Agile Werte in SCRUM

Folge 15  In Vorbereitung: Die drei Säulen von SCRUM

Folge 16  In Vorbereitung: Die Rolle des Product Owner Teil 1

Folge 17  In Vorbereitung: Die Rolle des Product Owner Teil 2

Folge 18  In Vorbereitung: Die Rolle des Scrum Masters Teil 1

Folge 19  In Vorbereitung: Die Rolle des Scrum Masters Teil 2

und viele mehr in Kürze...

 

Viel Spaß beim zuhören!
Sollte es Fragen, Kritik oder Anregungen geben, schreibt mir bitte an podcast@ihreveraenderung.de.

 

(c) 2019 Dr. Alexander M. Loitsch, powered by IhreVeraenderung

Warum Agilität im Selbststudium nicht funktioniert

Warum Agilität im Selbststudium nicht funktioniert

Viele Menschen meinen durch das Lesen eines oder mehrerer Bücher oder dem sehen von Youtube-Videos über agile Managementmethoden genug zu wissen, um ein entsprechendes Vorgehen in der eigenen Firma etablieren zu können oder selber in diesem Bereich tätig sein zu können.

Für jeden Bereich ein Profi

Dies funktioniert jedoch leider so nicht. Ich kann kein Buch über Architektur und ein anderes über Maurerarbeiten lesen um dann selber ein ganzes Haus bauen zu können. Dazu gibt es nun mal Spezialisten.

Der Architekt ist die Person, die den Überblick hat, der Polier ist die Person, die die Prozesse auf der Baustelle organisiert und für jedes Gewerk gibt es einen oder mehrere Profis (Maurer, Dachdecker, Fliesenleger, Installateure, etc...)

Agilität = Umgang mit Menschen

Agilität hat in erster Linie mit Menschen zu tun, mit sozialem Gefüge, Erfahrung, Einstellung und anderen "weichen Faktoren".  Jemand der das Lernen einfach nur als erlesen von Fakten aus ein paar Büchern, oder als angucken von YouTube-Videos im Internet versteht, wird sich beim Erlernen einer solch anderen Einstellung sehr schwer tun.

Agilität ist eine Lebenseinstellung

Fakt ist: Agilität, sowie agile Vorgehensweisen wie Beispielsweise SCRUM, sind in erster Linie eine Lebenseinstellung. Erst darauf können die entsprechenden agilen Methoden und Praktiken der Frameworks aufsetzen.

Jeder der agil arbeiten möchte, sollte Agilität daher erst selber erlebt haben. Werte und deren Einsatz sollten selber spielerisch ausprobiert werden, ehe es in den Berufsalltag damit geht. Ein guter Scrum-Master oder Scrum-Trainer hat immer Methode und Tools in seinem Moderationskoffer die situativ passen. Vertrauen sie dabei den Spezialisten.

 AML

Agilität, SCRUM & Kanban in Unternehmen

Einleitung

Agilität ist beinahe zum Synonym für Effizienzsteigerung bei Projekten und bei der Produktentwicklung geworden. In Startups und Onlineunternehmen gehört agiles Arbeiten bereits zum Alltag. In Unternehmen anderer Branchen ist Agilität eher selten anzutreffen. Dabei kann jedes Unternehmen von der Effizienzsteigerung profitieren; und das ohne in einem groß angelegten Change-Prozess Scrum, Kanban oder ein anderes Framework einführen zu müssen. Die ersten Schritte in die Agilität sind klein und leicht umsetzbar.

Wenn in einem Unternehmen über Effizienzsteigerung der Prozesse, insbesondere bei Projekten und bei der Neu- bzw. Weiterentwicklung von Produkten, nachgedacht wird, kommt man an dem Begriff „agile“ heutzutage nicht mehr vorbei. Agilität verspricht geringe Bürokratie mit wenig Regeln und damit erhöhten Output bei gleichem Ressourceneinsatz. Gleichzeitig verfolgt Agilität ein iteratives Vorgehen. Der Zyklus „planen, bauen, messen, lernen“ wird in möglichst kurzen Zeitabständen und während eines Projekts zigmal durchlaufen. Im Gegensatz zur klassischen Projektplanung spielen vor allem die Phasen „planen“ und „lernen“ als ein integrativer Teil des Zyklusses die entscheidende Rolle. Die Maxime „fail fast and learn“ („Mache möglichst schnell Fehler und lerne daraus“) steht im Mittelpunkt der Agilität.

Agiles Arbeiten ist häufig in Startups anzutreffen

Schnell stößt man auf Scrum und Kanban, die beiden bekanntesten Projekt- bzw. Produktmanagement-Frameworks für agiles Arbeiten. Beide ähneln sich stark vom Vorgehen; unterscheiden sich jedoch in Rollen und Artefakten. Während Scrum mehr Rollen und Artefakte kennt und damit stärker reguliert ist, setzt Kanban auf mehr Transparenz und kann daher auch schnell unübersichtlich werden. Häufig ist eine Mischung aus Scrum und Kanban im Einsatz. Diese Mischform wird Scrum-Ban oder Scrum-But (= „Scrum, aber…“) genannt. In einem andauernden Lernprozess passen die Unternehmen die Prozesse immer weiter an die eigenen Bedürfnisse an. Sie begreifen den Prozess selbst als ein agiles Projekt.

Auffällig ist, dass in nahezu allen Internet-Startups agiles Arbeiten, unabhängig ob Scrum oder Kanban, an der Tagesordnung ist. Ebenso trifft man in einem Großteil der etablierten Onlineunternehmen agile Prozesse an. In Unternehmen anderer Branchen ist agiles Arbeiten dagegen weniger bekannt und wird entsprechend seltener eingesetzt.

Vielleicht liegt das daran, dass Startups mit dieser Methodik groß geworden sind. Vielleicht aber auch daran, dass Teamwork und kontinuierliche Produktverbesserungen von Anfang an großgeschrieben werden.

Sowohl der Wunsch nach besserem Teamwork als auch nach kontinuierlichen Produktverbesserungen sind ideale Voraussetzungen, um Unternehmensprozesse agil zu organisieren. Das Resultat ist ein effizientes Arbeiten. Bei wiederkehrenden und stark strukturierten Routinetätigkeiten, wie zum Beispiel dem täglichen Buchen von Rechnungen in der Buchhaltung, führen agile Prozesse dagegen nur zu einer geringen Effizienzsteigerung.

Jedes Unternehmen kann mit geringem Aufwand agil werden

In jedem Unternehmen gibt es Bereiche und Prozesse, die von agilen Prozessen profitieren würden. Der Einführungsaufwand und der damit verbundene Change-Prozess hält Unternehmen dagegen häufig ab, Methoden zu ändern. Sie bleiben lieber bei ihrer altbekannten Herangehensweise.

Dabei muss man als Unternehmen nicht gleich ein komplettes Framework, wie Scrum oder Kanban, einführen. Änderungen lassen sich Schritt für Schritt, auch abseits der Frameworks, umsetzen. Die anzustrebenden Prozessanpassungen betreffen zwei Bereiche:

  • agiles Team
  • agiles Projekt

Die Anpassungen in den beiden Bereichen lassen sich unabhängig voneinander in jeweils drei Stufen einführen.

Zwei Mal drei Stufen zur Agilität

Team Stufe 1: Regelmäßige Kommunikation forcieren. In einem täglichen Meeting zu Beginn des Tages tauschen sich die Teammitglieder darüber aus, woran sie an diesem Tag arbeiten. Das Meeting sollte nicht länger als 15 Minuten dauern und stehend im Teamraum durchgeführt werden. Kurz nach der Einführung wird das Meeting als zusätzlicher Overhead wahrgenommen werden, da ausschließlich Statusberichte ausgetauscht werden. Nach kurzer Zeit wird sich das Meeting jedoch zu einem Output fokussierten Format wandeln. Die zentralen Fragen sind: „Was brauche ich, um meinen heutige Arbeit fertig zu stellen?“ und „Wie kann ich meine Kollegen bei ihrer heutigen Aufgabe unterstützen?“ – Diese Richtung sollte vom Teamlead forciert werden, denn das Meeting hat keine Reportingfunktion.

Team Stufe 2: Fortschritt transparent darstellen. Auf einem Board an der Wand wird für jedes Teammitglied transparent dargestellt, wer gerade an welcher Aufgabe arbeitet. Ebenso werden die Aufgaben, die bereits erledigt sind und die Aufgaben, die als nächstes anstehen, visualisiert. Die Aufgaben können zum Beispiel auf Post-Its geschrieben und in die drei Spalten „Todo“, „In progress“, „Done“ sortiert werden. Jeder Aufgabe, die in der „In progress“-Spalte hängt, ist ein verantwortlichen Mitarbeiter zugeordnet. Falls eine Aufgabe längere Zeit in der „In progress“-Spalte hängt, kann nun jeder helfend eingreifen und fragen, wie er unterstützen kann.

Team Stufe 3: Kurze Feedbackschleifen einführen. In einem zweiwöchentlichen Meeting reflektiert das Team die letzten zwei Wochen. Was lief gut? Was kann verbessert werden? Aus jedem Meeting sollten ein bis drei Punkte für Verbesserungen (möglichst mit konkreten Aktionen und zugeteilten Verantwortlichkeiten) entstehen. Die Punkte werden in den folgenden zwei Wochen umgesetzt und so der Prozess im Team stetig verbessert.

Projekt Stufe 1: Gesamtprojekt in Teilprojekte teilen. Das Gesamtprojekt wird in möglichst viele Teilprojekte geteilt. Jedoch nur so klein, dass jedes Teilprojekt für sich genommen einen Mehrwert für den Kunden liefert. Gleichzeitig sollte darauf geachtet werden, dass sich die Teilprojekte möglichst wenig überschneiden und somit unabhängig voneinander bearbeitet werden können. Teilprojekte werden, genau wie Aufgaben, auf (andersfarbige) Post-Its geschrieben und an das Board in die Spalte „Todo“ gehängt. Sortiert man nun noch die Teilprojekte und Aufgaben in der „Todo“-Spalte nach Priorität, erhält man eine „Mini-Roadmap“. Hinweis: Bevor ein Teilprojekt bearbeitet werden kann, muss es noch einmal in konkrete Aufgaben runtergebrochen und granularer geplant werden.

Projekt Stufe 2: Nur die nahe Zukunft planen. Nur das nächste und das übernächste anstehende Teilprojekt werden geplant. Für diese liegen in der Regel ausreichend Informationen für eine detaillierte Planung vor. Außerdem sind die Rahmenbedingungen hinreichend bekannt. Für weiter in der Zukunft liegende Teilprojekte sind die Rahmenbedingungen häufig zu vage. Eine sofortige Planung hätte zur Folge, dass das Teilprojekt kurz vor Start wahrscheinlich ein zweites Mal geplant werden müsste.

Projekt Stufe 3: Aus Kunden-Sicht formulieren. Das zu erwartende Ergebnis eines Teilprojekts, aber auch das Ergebnis des Gesamtprojekts, wird aus Kunden-Sicht beschrieben. So ist sichergestellt, dass allen Team-Mitgliedern das zu erreichende Ziel permanent vor Augen ist. Auf im Projektverlauf auftretende Probleme kann jeder selbständig im Sinne des Kunden reagieren. Kunden können in diesem Zusammenhang sowohl (externe) Endkunden als auch (interne) Kollegen sein. Um das Ergebnis aus Kundensicht zu beschreiben, hilft die Formulierung: „Als … möchte ich … so dass ich …“ Zum Beispiel könnte das Ziel eines Teilprojekts zur Besserung des Services einer Autowerkstatt lauten: „Als Autobesitzer möchte ich einen Werkstatttermin vorab und verbindlich vereinbaren, so dass ich beim Abgeben meines Autos keine unangenehmen Wartezeiten habe.“

Schlusswort

Mit diesen 2×3 Schritten in Richtung Agilität sollte bereits ein erster Effizienzgewinn in Projekten und den kontinuierlichen Produktentwicklungen messbar sein. Außerdem lassen sich auf dieser Basis zum späteren Zeitpunkt nahtlos die bekannten agilen Frameworks Scrum oder Kanban aufsetzen. Ein abschließender Tipp: Agilität wird nicht „top-down“ eingeführt, sondern entsteht durch Zusammenarbeit im Team.

Artikel von Christian Landsberg: https://www.xing.com/profile/Christian_Landsberg

Meine agile Wort-Allergie

EINLEITUNG

Es gibt Wörter und Wortkombinationen auf die ich im agilen Kontext sehr allergisch reagieren kann. Anbei ein Beispiel:

MAL SCHNELL

Immer wenn ich mich selber dabei ertappe „…mal schnell…“ zu sagen, versuche ich sofort eine verbale Kehrtwendung hinzulegen. Und wenn ich es von anderen höre, hebe ich die Hand und stoppe erst mal den Sprecher. Warum?

Anbei mal schnell (Ups!) ein paar Beispiele:

  • „Baue uns mal schnell ein Formular für den Emailversandt.“
  • „Wir installieren mal schnell einen Datenbankserver.“
  • „Kannst du mir mal schnell die Präsentation fertig machen?“
  • „Lasst uns mal schnell einen Workaround verwenden, so wie es das andere Team auch gemacht hat.“

Oft höre ich auch ein Synonym dafür, das Wort „Einfach“:

  • „Lass uns einfach mal das Modul runterprogrammieren.“
  • „Wir nehmen einfach ein anderes Softwaretool.“
  • „Lasst uns einfach eine andere Library für die Programmierung einsetzen.“
  • „Wir suchen uns einfach einen anderen Zulieferer.“

Wenn wir „mal schnell“ oder „einfach“ oder „mal einfach schnell“ in einer Aussage benutzen, haben wir oft vergessen wie aufwendig es sein kann das entsprechende Vorhaben (User Story, Arbeitspaket, Projektaufgabe, etc..) umzusetzen, weil wir uns noch nicht bewusst sind wie viele Arbeitspakete (tasks) da wirklich dahinter stecken und welche Abhängigkeiten auf uns zukommen könnten.

Die oben angeführten Wörter gehören übrigens zur Familie der „Entschärfer“. Das sind Wortkombinationen die uns suggerieren sollen, das alles sehr einfach und reibungslos von statten gehen wird.

FREUNDLICH ABER BESTIMMT

Um nun die Details zu hinterfragen, sollte der Sprecher erst einmal verbal abgebremst werden, was oft nicht so einfach ist; vor allem wenn es sich um einen Vorgesetzten handelt.

Tipp: Einfach eine Gesprächspause abwarten und dann freundlich aber bestimmt nachfragen:

  • „Könnten wir hier kurz stoppen, mir ist da noch was unklar…“
  • „Bitte warten sie ehe sie fortfahren, könnten sie mir das genauer erklären?“
  • „Ich möcht sie ungerne unterbrechen, aber können sie mir folgendes etwas detaillierter erklären?“

PEINLICH?

Es ist natürlich nicht einfach solche Fragen direkt zu stellen, man möchte ja nicht als „doof“ dastehen und in den Ruf kommen „naive Fragen“ in den Raum zu werfen. Ich kann sie da aber beruhigen: Das genaue Gegenteil wird der Fall sein!

Wenn ich etwas bis in letzter Konsequenz hinterfrage, stehe ich als fokussierter, überlegter Mensch da, der seine Entscheidungen auf Fakten basieren lassen möchte, nicht auf Halbwahrheiten oder Annahmen.

Viele Menschen fürchten es wenn man genauer nachfragt, da viele Ihrer Entscheidungen oft vorher nicht komplett durchdacht wurden oder auf Halbwissen basieren. Erst wenn alles bis zu Ende gedacht und hinterfragt wurde, wird es transparent und politische Strömungen oder „Leichen im Keller“ kommen dann sehr schnell ans Tageslicht.

Und: Ist nicht eine der Säulen von Agilität und SCRUM eine bedingungslose Transparenz?

(c) 2017 A.M.L.

Agile Methoden – Was dahinter steckt

Scrum, Lean, Agilität, Digitale Transformation, Kanban & Co. Was wirklich dahinter steckt.

 

Aktuell sind Themen wie „Agiles Projektmanagement“, „SCRUM“, „Design-Thinking“, „Kanban“ und viele weitere agile Frameworks, Methoden und Vorgehensweisen auf dem Vormarsch. Doch was bedeutet das genau?

Weiterlesen