„Bei uns gibt es keine Sicherheit“

Ein Artikel über die zentrale Bedeutung von Sicherheit in Change- und Transformationsprozessen

Mir fällt dazu eine Geschichte aus einem großen Changeprozess ein, den kürzlich ein Agile Coach in einem Online-Forum geschildet hat:

Die Geschäftsführerin hatte morgens ganz spontan zu einem Abteilungsmeeting eingeladen. Natürlich hat sich jeder bereits im Vorfeld seine Gedanken gemacht.

Die Geschäftsführerin steht vorn, 150 Männer und Frauen sind spontan gekommen. Totenstille. Sie wirkt besorgt und beginnt nach einer kurzen Weile ihre Rede einzuleiten. Der Blick nach unten gesenkt, die Mimik kühl. langsame Worte, viele Redepausen.

In mir bewegt sich ein Gefühl von „Vorsicht“ und „Unstimmigkeit“ – ihr Auftritt wirkt fast wie gespielt.

Sie spricht über #Digitalisierung, neue #Prozesse, #Wandel und #Transformation …. und hält dazu nicht lange hin.

Es geht um die Schließung einer Abteilung.

– Schock –

20 Leute müssen das Unternehmen in 2 Wochen verlassen. Der Schock breitet sich weiter aus. Keiner ist in der Lage zu sprechen.

„Wir müssen das jetzt nicht unnötig weiter in die Länge ziehen.“, sagt sie: „Wer Fragen hat, kann sich gerne auch im Nachgang an mich oder die Personalabteilung wenden. Sie verweist auf eine Frau in der ersten Reihe.“

Ein Kollege aus dem Betriebsrat meldet sich:
„Das ist eine verständliche und schwierige Situation, es müssen auch mal schwere unternehmerische Entscheidungen getroffen werden, doch natürlich fragt sich jetzt jeder wann er der nächste ist.“ – ich zucke und denke noch einen Moment über die Qualität dieser Frage nach. Was macht diese Frage mit mir? Was macht diese Frage mit anderen? Angst oder Liebe?

Der Blick der Geschäftsführerin wird plötzlich sehr klar, fokussiert – gespielte Traurigkeit entweicht: „Es gibt keine Sicherheit. Ich kann niemanden eine Job-Sicherheit geben.“

„Es gibt keine Sicherheit.“ – wow.

– Das wars. – Das war alles.
Kein „Ich werde mein Bestes geben möglichst viel Sicherheit zu schaffen.“, kein: „Ich weiß wie sehr sich alle jetzt weitere Gedanken machen.“, kein „Ich werde viel mit euch gemeinsam tun, damit wir entsprechende Maßnahmen vermeiden können.“ – nichts, nada.

Ich bin systemischer #Coach, also macht sich in mir ein Unmut breit. Ich denke an Angst, Hilflosigkeit, Schock und Ohnmacht. Aspekte die der Großteil jetzt sicher erleben wird und gleichzeitig spüre ich ähnliche Gefühle natürlich bei mir. Doch weiter gedacht: „Mit was ist jetzt zu rechnen?“

Klar, ein Organisationssystem und jeder einzelne bekommt mit einer solchen Aussage den Boden unter den Füßen weggezogen. Absichtlich oder unbeabsichtigt. Wer weiß?

Es wird in Bewegung geraten, wie ein Baby-Mobilé in dem man nicht nur einen Teil anstoßt, nein, sondern die Verbindungslinien rausreißt.

Manche Menschen reagieren in solchen Situationen mit folgenden Aspekten:

  • Schock
  • Angst
  • Verletzung
  • Befürchtung vor Kontrollverlust
  • Bindungsverlust
  • Scham
  • Schuld
  • Tiefem Schmerz

Das sind tiefe Gefühl die wirklich krasse Systemdynamiken in Gang setzen können. Daraus kann Destruktivität resuliteren die tatsächlich außer Kontrolle gerät.

Das wirkt sich natürlich nicht nur auf die Leistung- und Arbeitsleistung, auf die Wirtschaftlichkeit, die Mitarbeitermotivation sondern auch darauf aus wie das Unternehmen wahrgenommen wird – innen und außen. Ob es für Bewerber noch interessant ist, ob Spitzen-Leute noch da bleiben wollen und letzlich natürlich auch welchen Umgang die bestehenden Mitarbeiter finden.

Angst oder Liebe? Was bewegt das eine und was macht das andere?

Natürlich sehe ich nun auch die Gefahr von Mobbing, Bossing und Co.

Also stelle ich mir die Frage:

  • Wo kann ich jetzt und in den nächsten Tagen möglichst ganz ganz viel Sicherheit finden?
  • Worauf kann ich mich berufen?
  • Was weiß ich schon? Was kann ich in Erfahrung bringen?
  • Wie sicher ist mein Job?
  • Wie kann ich anderen Sicherheit geben?
  • Auf was kann ich mich zurückziehen?
  • Wie kann ich durch meine Tätigkeit und meinen Einfluss mehr Sicherheit schaffen?
  • Wo kann mehr und mehr Sicherheit gefunden werden?

Im Laufe der nächsten Tage kommt es zu einigen Krankmeldungen.

Die Gespräche im Büro sind geprägt von Horrorszenarien und viele scheinen ihre persönlichen Sorgen nicht mal selbst wahrzunehmen. Es geht nicht mehr viel um die zentrale Aufgabe des Unternehmens und der Abteilung, sondern darum in wie sehr es die Menschen schaffen einen Umgang mit ihrer Angst zu finden. Damit allein gelassen, breiten sich die dysfunktionalen Muster meistens weiter aus.

Aufgrund der vielen Krankmeldungen suchte die Geschäftsführerin mit mir das Gespräch, wir sprachen miteinander und fanden relativ einfach Maßnahmen zur Stabilisierung des Systems.

Natürlich konnten wir die Ängste einzelner nicht weg-zaubern. Wir konnten aber einen konstruktiven Umgang finden, die Lage beruhigen und dafür sorgen, dass sich das soziale System wieder stabilisiert und eine sehr destruktive, dysfunktionale Situation wandeln.

Transformationsprozesse positiv wandeln: sie konstruktiv und sicher gestalten – meine Fähigkeit

Was war das Problem? Die Kommunikation und der Start in dieser Transformation war sicherlich nicht optimal und endete schließlich eher in einer Löschaktion.

Daher möchte ich Sie einladen, falls Sie qualitative Begleitung in solchen Transformationsprozessen haben möchten um sie ruhig, stabil, menschlich, sozial und wirtschaftlich gestalten wollen, kontaktieren Sie mich.

Sie können mich gerne auch kontaktieren, falls Sie als Führungskraft, Product Owner, Agile Coach oder Scrum Master in einer solchen Situation nicht weiter wissen, Klarheit über die Situation brauchen und Handlungsoptionen finden wollen:

Kontaktieren Sie mich

8 schwierige Dinge die dir als Product Owner in einem klassischen Projektkontext begegnen können

Hi!

Ich habe mich gefragt: „Was sind die wesentlichen Punkte die jemand helfen können, der völlig neu in die Rolle des Product Owners in einem neuen Team, in einer neuen Organisation, kommt?“

Kontext:

neuer Product Owner, klassisches Unternehmen, erste Erfahrung in dieser Rolle, Team kennt die Rolle noch gar nicht, vorher Projektmanager als zentraler „Leader“.

Anbei die acht Punkte. Punkt 1 habe ich schriftlich ausgeführt, alle anderen erfährst du auditiv in der Folge 12 meines Brandstiftung-Podcasts (podcast.de oder itunes).

1. Verwechslungsgefahr mit den Aufgaben des Projektmanagers

Du läufst in Gefahr die typischen #BullshitAufgaben (entschuldigt) eines Projektmanagers zu übernehmen, also Budgetplanung, Controlling, Reporting und Co.

Also all das, was wir im agilen Kontext möglichst soweit vereinfachen das es sehr wenig Arbeit kostet und wir uns auf die Wertschöpfung konzentrieren können.

Die Zeit fehlt dir dann bei der Qualität.

2. Du hast Probleme es zu „deinem Produkt“ zu machen

3. Die „Definition of ready“ wird nicht verstanden

4. Die „Definition of done“ wird nicht akzeptiert

5. Du bekommst Konflikte weil du priorisierst und „Nein“ sagst

6. Die Review-Vorgehensweise wird nicht akzeptiert

7. Du verfällst leicht dazu die Arbeit nach der vierten oder fünften Korrektur selbst zu erledigen

8. Entscheidungs-Ping-Pong

Hör dir jetzt in der Podcast-Folge 12 mehr Details dazu an:

podcast.de oder itunes.

Falls du jetzt Hilfe als Product Owner suchst, kontaktiere mich für eine Projektanalyse und kurzfristige Unterstützung.

Guter „Change“ ist Teamarbeit: Hin zur agilen Beta-Organisation in 18 Monaten

Wer das 47. Meetup der Agile Usergroup in Kassel mit Niels Pfläging erlebt hat, weiß nun bestätigt das der Umschaltprozess hin zur agilen Beta-Organisation ungefähr 18 Monate dauert.

1,5 Jahre! Das klingt viel, oder? Doch nur die Ruhe!

Ich unterbiete und sage es geht schon in sechs und die meiste Zeit kann eigenständig bewerkstelligt werden – das soll sie sogar. Schließlich ist das Ziel autonome Teams zu bilden. Wie soll das mit dauerhafter Begleitung gelingen?

Ok, in den sechs Monaten erfolgt die Umsetzung üblicherweise für 2-5 Teams. Aber das schafft frühen Wert, senkt Risiken und bringt erste Erkenntnisse! Sie können in dieser Zeit immernoch abbrechen, verlangsamen, intervenieren und anpassen.

Doch sicherlich werden Sie diesen psychologischen Trick durchschauen: in Summe bleibt es bei 12-18 Monaten.

Dafür ernten Sie eine zweckmäßige Organisation mit Teammitgliedern die Verantwortung übernehmen, ihre Konflikte selbst austragen, Umsetzungen liefern und Lösungen für eigene Probleme finden, uvm.

Die Alpha-Organisation ist tot – seit 1970. „Komplexität hat Management umgebracht“

Was viele jedoch nicht wissen ist, mit welcher Sorgfalt dieser Schritt durchzuführen ist. Verstehen Sie? Ein Chirurg operiert auch nicht alleine und wenn wir an ein System wie eine Organisation herantreten, wie könnte das alleine geschehen oder gar experimentiell?

Professioneller Change ist Teamarbeit – professionelles Umschalten erfolgt mit einem Team aus internen und externen Partnern

Das Ganze ist nicht ohne, es braucht eine gute Voranalyse, einige vorbereitende Gespräche mit einer umfangreichen strategischen Vorbereitung. Vielleicht werden Experten hinzugezogen, weitere bildhafte Untersuchungen durchgeführt.

Dann wird operiert. Kennen Sie das wie das im Op abläuft?

Alles liegt bereit. Der Zeitraum der Narkose wird optimal genutzt. Die Zeitspanne der Operation möglichst kurz gehalten, alles ist gut vorbesprochen, die lebensnotwendigen Funktionen werden überwacht und dann erfolgt der Eingriff.

Das kann mal schmerzhaft werden und dabei können Komplikationen auftreten. Doch es muss eben getan werden, weil alle vorherigen Optionen abgewogen wurden.

Anschließend wird weiter überwacht. Es gibt vielleicht Visitengespräche und nach einer kurzen Heilungsphase wird in der Regel alles gut.

Vielleicht werden Sie den Operateur nicht mögen, aber das System wird sich an der Genesung erfreuen. Bildhaft gesprochen.

Dabei ist „Change“ kein Alleingang – zumindest nicht wenn er eine gewisse qualitative Wirksamkeit haben soll.

Dabei arbeiten Menschen aus der Organisation mit externen Experten zusammen. Interne Agile Coaches und externe Analysten bilden ein Team mit der Geschäftsführung. In der Regel kommen schrittweise weitere Product Ownern, Scrum Mastern und Teammitglieder hinzu.

Die Hauptbeteiligen stehen in engem Dialog, Sie sprechen mit externen Supervisionspartnern und nichts wird dem Zufall überlassen. Dabei arbeiten alle gemeinsam für ein gutes Ergebnis.

Es ist somit eine Teamleistung und sicherlich nichts, was alleine gestemmt werden muss oder vielleicht kann. Das wollte ich Ihnen mit diesem Artikel nahebringen.

Viel Erfolg.

über »Magic Teams« und den Titel des neuen Buches

Die Arbeiten am aktuellen Buch gehen dem Ende zu. Endlich – es freut mich wirklich.

Nach ungefähr fünf Jahren! Es war ein auf und ab. Ein Hin- und Her mit umfangreicher Sondierungsphase und jetzt?

Jetzt ist es (hoffentlich) ein ganz einfaches Buch geworden – mit bedeutsamen Inhalt.

Nach vielen vielen Iterationen finden auch die Arbeiten am Titel und dem Cover ein Ende:

»Magic Teams« – Sicherer Rahmen für zielgerichtete Projekte?

Wieso »Magic Teams«?

Es ist die Basis jeder guten Zusammenarbeit: Magie, eine Art „Zauber“ der in erfolgreichen Teams innewohnt.

Es spricht genau das an, was Menschen in tayloristischen Organisationen mit anspruchsvollen Projekten fehlt: Kooperation und fast magische Kommunikation im Miteinander. Oder auch anders: Flow.

Der Haupttitel ist dabei nicht nur inspiriert durch viele Online-Diskurse und die Hilfe von vielen Unterstützern (Danke!), sondern es ist definitiv das Hauptthema des Buches!

Kooperative agile Beta-Teams statt Alpha-Management des letzten Jahrhunderts

Sehr treffend hat es dazu dieses Zitat auf den Punkt gebracht, was ich noch einmal erwähnen möchte:

»Wir haben jetzt dieses Team, wir leben jetzt diesen
Traum – der natürlich auch Schatten hat, das Leben
ist schließlich kein Ponyhof :). Der Unterschied ist:
es sind unsere Probleme und wir drücken uns nicht
davor, wir lösen sie zusammen.« (Quelle)

Weshalb »Sicherer Rahmen (…)«?

Viele „Modelle“ oder „Konzepte“ sprechen von großer Unsicherheit in agilen Projekten und das es dazu sogar Handlungsempfehlungen bräuchte. Ich glaube das nicht (mehr*)!

Das ist ein großer Irrtum.

*das war ein schmerzhaftes Learning

Aus welchem Grund?

Natürlich wissen wir in Vielerlei Hinsicht oft nicht ob ein Projekt wirklich fertig wird, wie es technologisch angegangen werden kann oder ob der Kunde in einem halben Jahr noch das möchte, was er bestellt hat.

Doch deshalb können wir doch nicht in völliger Unsicherheit auf allen Ebenen agieren.

Es braucht Sicherheit! Und wenn diese nicht (unmittelbar) auf Inhaltsebene erreicht werden kann, dann doch bitte am Rahmen – am Organisationssystem.

»Führung bedeutet sichere Systeme in unsicheren Feldern zu schaffen.
Nicht umgedreht.«

Daher: sicherer Rahmen.

und wieso »(…) für zielgerichtete Projekte«?

Der vorherige Arbeitstitel nutzte das Wörtchen „Fokus“. Ich hätte auch fokussierte Projekte schreiben können, doch das zielt nicht auf das Ergebnis. Das Resultat fehlt. Fokus ist nur ein Hilfsmittel.

Wann ist ein Projekt erfolgreich? Wenn es das definierte oder ein anderes akzeptierte Ziel erreicht.

Dann sind alle Beteiligten zufrieden.

Und wir Menschen brauchen Ziele für den Fortschritt. Damit wir wissen was erreicht werden soll und dann ist das auch schon alles 🙂

…aus meiner Erfahrung mit »Magic Teams«

Einmal in zehn Jahren habe ich »Magic Teams« erlebt und sie hatten zwei Dinge: ein gutes Ziel und sichere Rahmenbedingungen.

Also habe zehn Jahre lange die Parameter mit dieser Erfahrung abgeglichen, analysiert, mit wissenschaftlichen Aspekten gegenübergestellt und in der agilen Community reflektiert. Es waren die besagten Punkte*.

Und damit wird die Sache rund: »Sicherer Rahmen für zielgerichtete Projekte«

Wer jetzt mehr erfahren möchte, kann sich den Klappentext ansehen und einen Blick in die kostenlose Leseprobe werfen.

* Ok, vielleicht, 2-3 Punkte mehr – sie stehen im Buch, aber das war es! 🙂

Mit Delegation dezentralisieren

In einem dieser neuen unprofessionellen Videos von mir kam ich an das Thema „Delegation und Dezentralisation.“

Ich hoffe Sie kennen den Unterschied:

»Dezentralisierung geht weiter als Delegation. Delegation findet auf individueller Ebene statt, wenn ein Vorgesetzter sich entscheidet, eine Befugnis, eine Verantwortung oder Aufgabe an einen Mitarbeiter zu übertragen.

Dezentralisierung entsteht dagegen, wenn ein Vorstand (oder äquivalentes Führungsgremium) entscheidet, Entscheidungsmacht an periphere Teile der Organisation zu übertragen.

Dezentralisierung ist dauerhafter als Delegation.«

Niels Pfläging, Organisation für Komplexität, Seite 62

Vielleicht wissen Sie aus eigener Erfahrung bereits, das die Managementmethode »Delegation« in komplexen Domäne schnell an ihre Grenzen stößt. Warum? Im Nebel, ohne Karte und GPS können Sie nicht die Richtung angeben, sondern nur den nächsten Schritt. Das ist jedoch sehr zeitintensiv, weil das am Start von neuen Projekten ungefähr alle fünf Minuten sein kann.

Und Delegation hat wirkliche Nachteile wenn es über Abteilungsgrenzen hinaus geht. Dann kämpfen Sie mit Rückdelegation und dem ganzen Machttheater!

Wann und wozu ist Dezentralisierung so wichtig?

Besonders wenn Organisationen schnell wachsen oder ständig in Bewegung sind, wenn Sie sich als Chef oder Geschäftsführer plötzlich nicht mehr um alles kümmern können oder wollen, dann ist es wichtig Verantwortung abzugeben und zwar sicher!

Oder wollen Sie mit jedem Mitarbeiter einzeln lernen was er darf oder was er nicht darf – mit jedem neuen der kommt?

Es geht darum die wenigen unsichtbaren Leitplanken des Systems sichtbar zu machen. Ein System kann dabei eine gesamte Organisation oder ein Team sein.

Natürlich helfen dabei formulierte Prinzipien wie »Don´t be evil« oder »Ask the team«. Greifbarer sind jedoch konkrete Besipiele.

Zumindest war das die Erfahrung die ich mit einem Agile Coach während einer Transition bei einem mittelständischen Unternehmen gesammelt habe.

Das Unternehmen stellte damals von »Führung durch einzelne Chefs« auf »Führung im Team« um. Also praktisch hin zu agilen Scrum Teams die sich an Beta-Prinzipien orientieren.

Nur gerade ließen diese in dem Kontext zu viele Fragen offen und es gab bereits große Unruhe weil das Unternehmen in wenigen Jahren von 10 auf rund 200 Mitarbeiter gewachsen war.

Aufkommende Fragen und Unsicherheiten während einer Transition sicher beantworten

Wir wollten Stabilität reinbringen und gleichzeitig die vielen Fragen beantworten:

  • »Was darf ich? Was nicht?«
  • »Wer macht eigentlich was?«
  • »Wann muss ich wen fragen?«

Oder konkreter:

  •  »Können wir einen Sprint abbrechen?«
  • »Brauchen wir einen Product Owner?«
  • »Wer schreibt die Anforderungen?«
  • »Darf ich meine Rolle abgeben an jemand anderes?«
  • »Wer muss Urlaub genehmigen?«

Die Intervention die dabei herauskam war nannten wir »Entscheidungstabellen«.

Entscheidungstabellen zeigen wer was darf und in welchem Rahmen. Sie können einmal initial mit dem Team erarbeitet und anschließend mit der Geschäftsführung oder entsprechenden Vertretern abgestimmt werden.

Vorgehensweise:

1. Fragen, Punkte und Entscheidungsaspekte für die Entscheidungstabellen sammeln
2. Lösungsvorschläge im Team diskutieren und vorbereiten
3. Vorschläge mit der Geschäftsführung oder einem vergleichbaren Entscheidungsträger abstimmen
4. Abschließende Zustimmung aller Beteiligten einholen
5. Entscheidungstabelle zentral, einsehbar und erweiterbar ablegen (zum Beispiel in einem zentralen System wie Confluence)

Beispiel:

Dieser Ansatz ist praktisch die Vorbereitung zum »Modell der agilen Organisation«. Es ist, wie dieses Kapitel, ein Teil meines eBooks »Fearless Focus«

Mehr dazu auch in diesem Video:

Das Modell der agilen Beta-Organisation nachbauen

Bei der Betrachtung der historischen Geschichte von Scrum, Lean Management und Agilität im Sinne des agilen Manifests kann es verblüffen, das es mehr als zehn Jahre gedauert hat, bis sich diese Ansätze tatsächlich in neuen Organisationsstrukturen manifestiert haben und zunehmend bekannter werden.

Dabei haben die beiden Organisationstheoretiker Takeuchi und Nonaka bereits 1986 in „The new new product development game“ von ihren Studien und Beobachtungen selbstorganisierter Produktentwicklungs-Teams berichtet. Das ist mehr als 30 Jahre her.

Sie verglichen Teams mit kleinen selbstorganisierten Einheiten die mit einem Ziel von außen voranschreiten. Vergleichbar mit dem Rugby-Spielzug »Scrum«.

Ken Schwaber und Jeff Sutherland griffen diese Bezeichnung später auf und benannten das heute bekannte Rahmenwerk für agile Produktentwicklung danach. Inzwischen wurden diese Ansätze weiterentwickelt, verwissenschaftlicht und mit praktischen Erfahrungen ergänzt. Einige davon wurden von Niels Pfläging und Silke Hermann in „Organisation von Komplexität“ beschrieben. Auch das Beta-Netzwerk befasst sich umfassend damit.

Aus diesen Parametern lässt sich ein Modell der agilen Organisation skizzieren und beschreiben das in die Praxis übertragen werden kann.Sie finden eine ausführliche Beschreibung als Gastartikel von mir auf dieser Seite:

https://t2informatik.de/blog/projektmanagement/die-agile-organisation/

Wie Unternehmen ihre Führungskräfte loswerden können

Wenn wir der Annahme folgen das Menschen unter den richtigen Rahmenbedingungen in der Lage sind, gute Arbeit zu leisten, dann ist auf kurz oder lang erforderlich, das wir Lösungen finden, welche Aufgaben ehemalige Führungskräfte übernehmen können.

“Es wird wieder die Zeit kommen, in der das Management nicht nur nach dem Return on Investment, sondern nach den Voraussetzungen, den Strategien und Innovationen beurteilt wird, welche die langfristige Existenz des Unternehmens gewährleisten, Investitionen, Dividenden und Arbeitsplätze sichern sowie durch die Verbesserung der Produkte und Dienstleistungen neue Arbeitsplätze schaffen.”

William Edwards Deming

Denken Sie daran: Selbstorganisation ist bereits Führung

„Das Ziel eines Unternehmens ist nicht, Geld zu erwirtschaften, sondern den Menschen einen Sinn und Zweck zu bieten. Gewinn erwirtschaften ist eine notwendige Bedingung, damit das Unternehmen lebensfähig ist.“

Björn Czybik interpretiert Götz Werner auf Basis dieses Artikels

Open Teams – Open Space auf Organisationsebene

Mit etwa 100 Studenten saßen wir im Vorlesungssaal. Unser Auftrag: „Findet ein Projekt für das ihr brennt, mit genau denjenigen bei denen ihr glaubt das es im Team gut harmonieren wird und mit einem Thema aus dem ihr am Ende viel mitnehmen könnt.“

Damit wurde uns ungefähr 2014 der Rahmen für neue Projekte eröffnet. Im Anschluss daran wurden uns, in wirklich kurzen Blöcken die begleitenden Professoren und ihren Aufgabenstellungen vorgestellt. Nach zehn Minuten erfolgte ein Wechsel und somit kamen rund 8 Projekte zusammen.

Im Anschluss daran konnten wir eine Entscheidung treffen.

Das erinnert stark an Open Space? Irgendwie schon. Kannte nur keiner. Wir haben einfach gemacht. Ein halbes Jahr später war jedes Projekt ein voller Erfolg.

Einfach? Stimmt.

Was ist #OpenTeams?

#OpenTeams – eine #Komplexithode wie sich Projektteams selbstorganisiert finden damit die Wahrscheinlichkeit auf Zielerreichung, gute Zusammenarbeit, Harmonie und Commitment bei anspruchsvollen Vorhaben steigt.

Welche Probleme kann dieser Ansatz lösen?

  • Das Menschen miteinander arbeiten müssen die sich nicht selbst gefunden haben, sondern über Chefs und HR-Abteilung zusammengesetzt wurden
  • Das Menschen und die Zusammensetzung nicht die erforderlichen Komposition ergibt die für ein Projekt gebraucht wird
  • Das Menschen mit niedriger Verpflichtung an der Zielerfolgung arbeiten

„Schluss mit: Wir haben einfach nicht die richtigen Leute.“

Was sind die wesentlichen Erfolgsfaktoren:

  1. Diejenigen die zusammen passen finden freiwillig zueinander – kein Zwang
  2. Alle bilden ein Team für ein gemeinsames Ziel – hohes Commitment mit sozialem Prozess
  3. Auftraggeber und Team finden sich – hohe Passung
  4. Projekt und Teammitglieder finden sich – hohe Chance das die richtigen Kompetenzen zusammenkommen um das Ganze erfolgreich zu machen
  5. Alle wissen das sie für einen Zeitraum x fest als Einheit zusammen agieren und ein Ziel erreichen wollen – Zweckgebundenheit

 

 

Noch mehr Irrtümer zur „Warum?“-Frage – Teil 2 – oder Wie Teams ins Fliegen kommen?

Wahnsinn welche Kreise die Sache mit der „Warum…?“-Frage zieht:

Was genau steht in diesem Artikel:

Das Forschen nach der Sinnfrage, nach dem Warum und Wozu zu fragen, ist eine Hauptaufgabenstellung für eine Arbeitsgemeinschaft. Wenn Menschen einen Sinn erkennen und bereit sind, aufgeschlossen mit Aufgaben umzugehen, dann fördert das innovative Lösungen, neue Produkte können kreiert oder kreative Dienstleistungen angeboten werden. Die Menschen verbinden sich mit ihren Aufgaben, und der Arbeitsplatz wird zum Lebensschauplatz.

Quelle

Nun, nochmal genauer:

Das Forschen nach der Sinnfrage, nach dem Warum und Wozu zu fragen, ist ein Hauptaufgabenstellung für eine Arbeitsgemeinschaft.

Ist das wirklich so?

Ganz kurz: Ich glaube damit überfordert man Teams und es kann nicht grundsätzlich ihre Aufgabe sein wenn die Wirtschaftlichkeit eine Rolle spielt.

Teams die keine Aufgabe oder keine sinnvolle Aufgabe haben die suchen sich natürlich welche. Eine Folge kann eben sein, das sie das Warum…? und den Nutzen hinterfragen. Ja.

Nur ist das die Aufgabe eines Teams? Wollen Sie ein solches Team?

Aus meiner Erfahrung heraus, kann das derartige Gespräche hervorbringen:

„Als Kunde möchte ich eine Webanwendung zum Pflegen der Kundendaten.“

„Warum möchten Sie das?“

Verstehen Sie was passiert? Die Teammitglieder beginnen indirekt mit der Diskussion und dem Hinterfragen. Der Kunde muss sich und die Idee jetzt erklären. Dabei bezahlt er das Team in aller Regel für die Umsetzung einer Vision und nicht die Prüfung der Sinnhaftigkeit oder anders: sehr wenige Auftraggeber beauftragen Spaß an der Freude des Geldausgebens. Davon darf jedes Teammitglied auskennen.

Warum…? führt Teams in die Irre

Mit einem Appell zum Forschen über das „Warum…?“ und den Sinn eines Auftrags können Sie das Team, Menschen und Leser des Appells verwirren. Sie können damit stabile Systeme und Kundenbeziehungen ins Wanken bringen.

Wenn das Team den Auftrag hat Kundenaufträge in Frage zu stellen, dann kann das einen Nutzen haben. Klar. In etwa wenn man die aktuellen Projekte reflektieren möchte oder Verbesserungschancen im Rahmen einer Strategiearbeit sucht.

Grundsätzlich ist es jedoch keine gute Idee eine Vision eines Teams offen zu lassen oder den Auftrag zu erteilen diese zu hinterfragen. Es sei denn, sie möchten ein Hinterfragungs-Team bilden was Unruhe reinbringt. Diesen Anwendungsfall gibt es natürlich, nur ist es nicht grundsätzlich nützlich.

Ein solcher Appell ist sozusagen etwas fahrlässig. Insbesondere weil sich damit natürlich jeder im Team seine eigenen Gedanken dazu macht und einen Sinn entwickelt.

Damit allerdings ein Team zu einem Team wird, braucht es ein gemeinsames akzeptiertes und frei gewähltes Ziel. Praktisch ein übergreifendes Meta-Ziel oder noch besser eine Vision:

In einer agilen Beta-Organisation bildet sich das wie unten dargestellt ab.

Die Akzeptanz für eine solche Vision lässt sich beispielsweise durch Projektmärkte steigern oder eben prüfen. Findet sich keiner ist die Vision unklar. Nur startet ein Team mit der Umsetzung, dann kann diese fest genug sein, damit das Team sich binden kann. Dieses Thema wird im Buch „Die Selbstorganisation“ noch einmal näher vorgestellt.