Kommentare 0

Folge #002 Mögliche Organisationsformen von agilen Unternehmen

Möglichkeiten von Organisationsformen – Unternehmen, die agil sind oder sein wollen
Muss ich als kleines mitteständiges Unternehmen überhaupt agil werden?
Wichtig ist es zu bewerten was ich Zulieferer, wie komplex und kompliziert meine Produkte sind und wie eng ich in den Herstellungsprozess eingebunden bin. Bei einer engen und tiefen Kopplung schlagen Veränderungen im Produktionsprozess direkt und häufig auf mich als Zulieferer durch.
Die Zusammenarbeit von unterschiedlichen Organisationsbereichen (Teams oder Abteilungen) spielt bei der Auswahl ebenso eine Rolle. Im Soli-Organisationen werden die unterschiedlichen Bereiche für die Herstellung zusammengezogen – bilden sich die Wertschöpfungsorganisation erst heraus. In einem Team, das die notwendigen Skills alle bereits zusammengezogen hat – ist der Fokus auf das „veränderliche“ Produkt schon angelegt.

Maschinenbau in Deutschland – Hier übernehmen innovative kleinere Unternehmen Komponenten und Teile aus einem großen End-Produkt. Wie kann man das dann auch einführen? Welche Organisationsformen und Rollen sollten sich durchsetzen? Ist das von der Branche abhängig?
Solche und ähnliche Fragen diskutieren wir anhand von Beispielen.

Kommentare 0

Folge #001 Praxis Beispiele der agilen Vorgehensweise außerhalb der Softwareentwicklung

Können die agilen Methoden, die aus der Softwareentwicklung kommen und maßgeblich dort weiterentwickelt wurden auf andere Branchen übertragen?
Entwicklung das den Charakter des „Neuen“ und Unbestimmtheit innewohnt sind bei zusätzlich hohen Änderungsdruck von außen agile Methoden besonders geeignet.
Die Verfahren und Methoden sind besonders dann gut anwendbar wenn auch auf dem weg zur fertigen Produkterstellung Teile sichtbar werden die dann auch einsetzbar sind und einen (Teil-) Kundennutzen erzeugen.

Macht es Sinn vor dem Start eines Projekt „Eignungskriterien“ zu erheben und zu Prüfen welches Vorgehensmodell am besten auf das Vorhaben passt? Gibt es solche Kriterien – wenn ja, welche sind das?
Änderungshäufigkeit sowie die Unterscheidung von Kompliziert und Komplex sind in der Literatur dazu herangezogen worden. Dazu hat Dr. Ralph D. Stacey das „Stacy-Diagramm“ entwickelt.
https://en.wikipedia.org/wiki/Ralph_D._Stacey

Kommentare 0

Agile Coach – Wir suchen Dich für Automotive Projekt in Stuttgart

Wir suchen zur Unterstützung von 3 agilen Team mit „starken Persönlichkeiten“ einen erfahrenen Coach der agile Werte stärkt, für die Einhaltung und Durchführung der Zeremonien  sorgt und dem Team hilft, sich auf den Kundennutzen zu konzentrieren.

Die Teams bauen an der Integration von Cloud Diensten wie AWS und IBM in die Konzern-Infrastruktur. Innovative Applikationen und neue Dienst nutzen diese Lösungen am Automotive – Standort Stuttgart.

Zusammen mit Ihnen/Dir möchten wir die Teams noch effektiver machen. Wir wollen agile Werte hochhalten und die Gruppe von Leuten zu erfolgreichen Teams machen.

Wir haben Unterstützung aus dem Management und Freiheiten zu Gestalten.  Interesse?

Janko Böhm  

Kommentare 0

Kosten der Projekt Gesundheit

Unternehmer treffen Entscheidungen auf Basis von Daten. Diesem Grundsatz wollte ich ebenso bei der Auswertung der Projekt-Gesundheit folgen. Entscheidungen über Maßnahmen sollen auf Datenbasis getroffen werden und Kosten dem Nutzen gegenübergestellt werden.

Als Ergebnis lagen mir aber nur die Handzeichen der Teammitglieder vor.

Kent Schwaber hat das Modell Evidence-Based Management entwickelt, die eine Datenbasis schafft um Entscheidungen nach Wertschöpfung zu treffen. Donald G. Reinertsen argumentiert 2009 im Buch Product Development Flow auch für einen Daten-basierten Ansatz zur Priorisierung nach Wert, dem Profit aus dem Produkt.

Eine wichtige Aussage von beiden dazu ist, die Entscheidungen auf Kennzahlen zu begründen die auch genau diese Wertschöpfung direkt ausdrücken. Kent Schwaber nennt das „evidence“. Wenn Unternehmen die gute bzw. korrekte Umsetzung von Scrum Praktiken und Zeremonien im Unternehmen messen, ist das eine Stellvertreter-KPI: „cirumstanced evidence“. Kent definiert den Agility Index in Punkten, der einen Reifegrad aus verschiedenen Bereichen verrechnet. Dieser Index kann über die Zeit gemessen werden und zeigt einen Trend. Ebenso können die aufgewendeten Kosten je Agility Index Punkt ausgewiesen werden. Ebenso dient der Index als Vergleichsgröße zwischen Unternehmen und in der Branche.

Diese sinngemäß gleiche Aussage der Unterscheidung von Stellvertreter KPIs von „echten“ KPIs drück Donald Reinerts auch aus. Er spricht dabei von „proxy variable“. Reinertsen nutzt als KPI den Profit des entwickelten Produkts über dessen Lebenszyklus: den „Life Cycle Profit“.

Seit einiger Zeit sind die Indikatoren des Produkt-Erfolgs auf denen Evidence-Based Management basiert, auch öffentlich zugänglich:

  1. Produkt Kosten Verhältnis
  2. Mitarbeiter Zufriedenheit
  3. Kundenzufriedenheit
  4. Umsatz je Mitarbeiter
  5. Gesamtanzahl von Fehlern
  6. Auslieferungsfrequenz
  7. Stabilität der Lieferungen bzw. Produkt-Inkrement
  8. Dauer einer Iteration
  9. Anzahl der Produktinstallationen
  10. Anzahl der Produkt-Nutzung
  11. Innovationsrate

Es werden die Bereiche Mitarbeiter, Kunden, Produkt, Kosten und Innovation berücksichtigt. Genaueres auf Scrum.org 

Diese Ideen habe ich aufgegriffen, um den Spotify Health Check Approach von Henrik Kniberg und Kristian Lindwall auszuwerten. Wir haben im Projekt das Assessment im Zuge unserer letzten Retrospective durchgeführt. Dazu hat jedes Teammitglied in den 12 Bereichen sein voting wie folgt abgegeben   „grün“ alles OK, „gelb“ könnte verbessert werden, „rot“ starker Handlungsbedarf. Diese votes habe ich gezählt.

Die Wertungen habe ich als Handlungsdruck in Zahlen ausgedrückt:  Grün = 0 (kein Handlungsdruck), Gelb = 1, Rot = 3 (hoher Druck, mehr als doppelt so hoch als bei einer Meldung für gelb)

Ausmultipliziert ergibt sich so je Bereich eine Kennzahl „Handlungsdruck“ die über die Zeit zu einem Trend führt.

In der Sektion „Mission“ hatten wir 15 grün und 3 gelb Meldungen. Das Führt zu einem Health-Index im Bereich Mission von 3   ( 15×0 + 3×1 + 0x3 ). Normiert auf 18 Teilnehmer zu Mission Health  0,17

Anders ausgedrückt weichen wir im Bereich „Mission“ um 17 Punkte vom Ideal-Zustand Null (kein Handlungsdruck) ab.

Maßnahmen welche wir im Team ergreifen, die zu einer Veränderung der Kennzahl führen, können wir in Euro ausdrücken. Wenn wir diese Kosten zur Veränderung des Health-Index ins Verhältnis setzen lassen sich die Kosten eines Health-Index Punkts errechnen.

Für das gesamte Produkt-Entwicklungsteam ergibt sich ein Health Index aus der Summe der Sektionen-Einzelwerte. Ich unterstelle dabei, dass alle Kriterien gleichberechtigt sind.

Dieser Health Index kann nun mit anderen Produktentwicklungs-Teams verglichen werden. Ebenso können wir so die Kosten der Verbesserung je Health Index-Punkt zwischen den Produkt-Teams vergleichen. Bei welchem Team ist eine Verbesserung billiger bzw. teurer – so können wir nach dem Warum fragen.

Kommentare 0

Gesundheit agiler Projekt & Teams

In Retrospectives wird der zurückliegende Sprint im Team besprochen. Gute Ideen und Praktiken werden gesammelt und im Team besprochen wir daraus noch mehr Nutzen gezogen werden kann. Ebenso kommen Punkte zur Sprache die weniger gut gelungen und verbesserungsfähig sind.

Das zugrundeliegende Vorgehen haben Henrik Kniberg und Kristian Lindwall hier ausführlich beschrieben. Ich habe noch die Kategorie „Feedback“ ergänzt und auf Deutsch erstellt. Das Ganze ist ein praktisches Werkzeug für die Phase „Gather Data“ der Retrospective.

Ablauf

  1. Der Coach oder Scrum Master stellt den Gesundheitscheck im Team vor
    • Ziel : Breites Spektrum in der Retro abdecken und Trends erkennen
    • Vorgehen
    • Kategorien
      1. Support : Bekommen wir die Hilfe die wir brauchen?
      2. Teamwork :   Funktioniert unser Team?
      3. Delivering Value : Bauen wir das Richtige?
      4. Einfache Lieferung : Können wir continous delivery ?
      5. Code Base :  Haben wir eine gesunde Source Code Base ?
      6. Lernen : Praktizieren wir  cross functional learing?
      7. Mission :  Haben wir einen gemeinsamen Fokus ?
      8. Selbstbestimmtheit :  Leben wir das starke agile self-empowered team?
      9. Speed : Liefern wir schnell?
      10. Abläufe :  Arbeiten wir effizient mit abgestimmtem Vorgehen?
      11. Feedback : Nutzen wir Feedback zur Verbesserung?
      12. Fun  :  Haben wir auch Spaß an der Sache?
  2. Jedes Team-Mitglied erhält 3 Ampel-Karten oder die Bewertung erfolgt über die Handzeichen.
  3. Für jede Kategorie wird die Bewertung im Team erfragt – alle zur gleichen Zeit – wie beim Planning Poker. Die Anzahl der Nennungen je Kategorie wird auf einem Board gesammelt.
  4. Schwerpunkte werden sichtbar und können in der weiteren Retrospective mit Maßnahmen unterlegt werden.

Download der Karten

Sample

 

Kommentare 0

Das Ende eines Agilen Projekts finden

Kosten-Nutzen Break-Even in agilen Projekten

Das richtige Ende eines Projekts zu finden ist nicht immer so einfach. Der Vertrag beschreibt noch viele Elemente und das Budget ist auch noch nicht aufgebraucht. Das Team macht einen guten Fortschritt – warum aufhören?

Die Agile Idee stellt den Nutzen für den Kunden in den Mittelpunkt aller Entscheidungen. Elemente mit einem hohen Nutzen werden zuerst umgesetzt. Das heißt aber auch, das Elemente mit geringerem Nutzen später umgesetzt werden.

Das Agile Projektteam ist über die Projektlaufzeit konstant und damit sind die Kosten auch in jeder gleich langen Iteration ebenso konstant.

Das heißt dann, dass in den früheren Iterationen mehr Wertschöpfung je eingesetzter Mittel erzeugt wird.

Wenn man nun den geschaffenen Wert und die dafür eingesetzten Mittel über die Projektlaufzeit gegenüber stellt, ergibt sich eine abflachende Kurve der Wertschöpfung zu konstant wachsenden Kosten. Beides trifft sich in einem Punkt. Ab diesem Punkt – dem Kosten-Nutzen Break Even – übersteigen die Kosten den geschaffenen Wertbeitrag in der Iteration.

An diesem Punkt sollte sich der Kunde und das Projektteam bzw. der Dienstleister die Frage stellen: Können wir in einem anderen Umfeld der Organisation einen größeren Nutzen schaffen oder sollten wir den Projektumfang nach Vertrag erfüllen?

Wenn der Vertrag es vorsieht, hat der Auftraggeber den Vorteil nicht zu viel für weniger werthaltige Elemente zu zahlen. Der Auftraggeber hat einen Antrieb den Dienstleister nicht „aus-zupressen“ und Scope in die bewusst offen gehaltenen Use Cases zu interpretieren.

Das Team kann mehr Wertschöpfung für die Organisation schaffen und das Messen der Erfüllung aller vertraglich zugesicherten Bausteine tritt hinter die Frage der Wertschöpfung für den Kunden.

Eine Herausforderung bei der praktischen Umsetzung ist es, die passende Einheit zu finden, mit der Kosten und Nutzen zueinander in Beziehung gesetzt werden. Ebenso erfordert die Umsetzung den Willen aller, diese Idee in die Verträge einfließen zu lassen.

Wo liegt in Ihrem Projekt dieser Punkt?  Arbeiten Sie links oder schon rechts dieses Punktes?

Kommentare 0

Haben wir im Projektmanagement seit F. W. Taylor vor 100 Jahren wirklich alles Falsch gemacht – Ist Agilität die Antwort?

Kann ein plan-orientiertes Projektmanagement unter bestimmten Umständen mein modernes Unternehmen wettbewerbsfähig halten?

In den Produktionsstraßen der großen Automobilhersteller läuft ein ausgetüftelter Ablauf von einzelnen Arbeitsschritten an verschiedenen Stationen des Produktionsbandes. Die Handgriffe der Mitarbeiter und die Arbeitsschritte der Roboter sind bis auf Sekunden optimiert. Da nicht nur ein Fahrzeug in der einen Ausstattung über das Band läuft gibt es viele Varianten, Sonderfälle und Bedingungen. Der Plan ist aufwendig zu erstellen und bei Änderungen an den Parametern muss kostenintensiv ein neuer Plan erstellt werden. Das Vorhaben ist dennoch wirtschaftlich.

Ein Projekt wurde bisher auch als ein solches komplexes Gebilde gesehen, das optimiert werden musste. Wenn die Parameter stabil bleiben, ist diese Art der Durchführung optimal.  Es kann auf geringste Produktionszeit oder minimale Personalkosten, minimale Überkopfarbeiten oder einem Mix daraus optimiert werden.

Die Abarbeitung dieses optimalen Plans erfordert es, dass sich alle Beteiligten an die Absprachen halten. Entscheidungen vorhersagbar und wiederholbar getroffen werden – es also Sicherheit gibt. Wenn diese Kriterien mit hohem Maße zutreffen, ist das Vorhaben planbar und das Optimum der Abfolge von Arbeitsschritten kann mathematisch optimiert werden.

Je nach Umfeld bietet es sich an, eine den Bedingungen entsprechende Methodik zur Umsetzung des Projekts zu wählen. Kann ich auf optimale Kosten und Zeit mathematisch exakt planen oder sollte ich besser ein flexibleres Modell nutzen?

Ralph D. Stacey ist Professor für Management an der Hertfordshire Business School und hat dazu ein Modell, die „Stacy Matrix“ publiziert. Das ist eine Hilfestellung zur Auswahl der passenden Projektmanagementmethode.

Je mehr Sicherheit über das Lieferergebnis „Was vorhanden ist und je mehr Sicherheit bei der Frage nach dem „Wie“ existiert, umso sicherer können wir uns auf einen optimierten Plan verlassen. Dieser muss dann auch nicht ständig verändert werden – es bleibt das „Wie“ und das „Was“ konstant.

Im Scrum Framework definiert das Projekt-Team zusammen mit dem Kundenvertreter (Product Owner) für eine kurze Zeit diesen Umfang fix (Sprint Backlog). Es werden keine Änderungen daran zugelassen. Jetzt kann das Team die Arbeiten an diesem kleinen Teil optimieren. Änderungen beziehen sich immer auf den Product Backlog – aber nie auf den Sprint.  Das Scrum Team arbeitet somit also immer in linken unteren Teil (simple) der Stacy Matrix.

Quelle: https://www.linkedin.com/pulse/complexity-why-your-software-project-needs-scrum-christiaan-verwijs/

Darstellung von Christiaan Verwijs

Eine Produktionsstraße der Automobilhersteller ist kompliziert. Viele Einzelteile müssen sich zum Ganzen fügen – aber das ist vorhersagbar. Allerdings kommt jetzt der Faktor Mensch dazu. Der Mensch ist nicht vorhersagbar. Jedes System das den Mensch mit einschließt, ist damit auch nicht mehr vorhersagbar. Reicht die Stabilität der zwei Achsen mit diesen Projekt­beteiligten nun für mein Projekt aus, um das Modell links unten „Simple“ zu wählen?

Unser Irrtum in den letzten Jahrzehnten war dabei nur, dass die Projektleiter, Kunden, Einkaufsabteilungen und letztlich die Unternehmensvertreter davon ausgegangen sind, dass der Bereich links unten im Stacy Diagramm wirklich für ein ganzes Projekt existiert.

Automobilhersteller gehen vom großen detailreichem Plan weg. Audi setzt auf flexible Produktionsinseln und Daimler auf eine Schwarmorganisation. Diese Unternehmen haben erkannt, dass der Kunde mit seinen wechselnden Anforderungen Teil des Systems ist. So gut mein Plan heute auch ist – morgen muss ich mit meiner komplizierten Produktion, flexibel auf neue Informationen und neue Prioritäten reagieren können.

Reine Plan getriebene Projektmanagement Modelle haben hier einen Nachteil gegenüber hybriden oder rein agilen Modellen. Sowohl in der Produktion als auch in Softwareprojekten müssen wir die komplizierten großen Vorhaben in solche Teile schneiden, die in die linke untere Ecke „hineinpassen“. Zwischen diesen Teilen gibt es dann Platz mit der Komplexität umzugehen. Antworten auf Umgang mit Komplexität hat z.B. Niels Pfläging in seinem Buch Komplexithoden  gegeben.

Danke für das Review des Posts an Matthias Kupka

 

Kommentare 0

Bei kritischem Liefertermin zielsicher Liefern und Mitarbeiter entlasten – Smarter – mit Kanban Pull

Gerade in kritischen Projektsituationen baut sich großer Druck auf. Der Chef oder Projektleiter drückt mehr Arbeit in das „System“ und die Arbeitslisten der Mitarbeiter werden länger.

Das Prinzip folgt dem Push-Prinzip. Die Fertigstellung kann nicht von einem Mitarbeiter an einem Platz erledigt werden – es sind immer mehrere Beteiligt – darum wurde ja auch ein Projekt TEAM gebildet. Diese Teammitglieder führen unterschiedliche Arbeitsschritte aus und diese hängen voneinander ab – so bilden sich Abläufe.

Jeder Schritt benötigt unterschiedliche lange um fertig gestellt zu werden. Der ersten in der Kette beginnen, schieben die halbfertigen Ergebnisse weiter und beginnen beim nächsten Element. In einem Software-Produkt würde so eine Vielzahl von Features begonnen werden, in unterschiedlichen Zuständen der Fertigstellung im Team an unterschiedlichen Arbeitsplätzen „liegen“ aber noch keines wirklich Fertig zur Verwendung stehen. Wenn eine Station fertig ist, wird die User Story dann weiter „geschoben“.

Mit dem Prinzip des Pull wird dieses Vorgehen umgekehrt. Der nachfolgende Arbeitsschritt fordert (pull) ein Element der Kette an. So gibt es keine größeren Stapel von halbfertigen Elementen im Ablauf. Die Mitarbeiter von vorgelagerten Arbeitsschritten haben dann weniger „Stress“ um ein weiteres Element zu bauen von dem Sie wissen, dass dieses nur auf den Stapel gelegt werden würde. Die einzelnen Elemente werden dann fertig, wenn diese gebraucht werden – indem sie angefordert werden.

Die frei werdende Zeit in an den Stationen der vorherigen Arbeitsschritte können sinnvoll ausgefüllt werden. So können auch Teammitglieder in dem Arbeitsschritt aushelfen bei dem die kritische Durchlaufzeit aktuell liegt.  Für diese Aushilfen müssen die Teammitglieder keine fach-Experten für diesen Arbeitsschritt sein, sondern Ihrem Teammitglied bei anderen störenden Einflüsse und Aufgaben helfen.

Wenn in so einem System zu einem bestimmten Zeitpunkt ein kritisches Lieferergebnis angefordert wird und jetzt in das (nicht überfüllte) System eingebracht wird, hat es eine signifikant geringere Durchlaufzeit als im Push-System. Dort würde das kritische Element erst fertig bearbeitet sein, wenn die Puffer zwischen den Arbeitsschritten abgearbeitet wären. Das kann in einigen Fällen ein Vielfaches der gesamten Durchlaufzeit eines einzelnen Elements durch das gesamte System bedeuten.

 

Die Mitarbeiter arbeiten nicht schneller – die Durchlaufzeit eines einzelnen auch wichtigen und kritischem Liefergegenstand bleibt gleich, aber durch die Verringerung der Wartezeiten und Stapel von unfertigen Teilen steht das gewünschte Ergebnis dennoch früher zur Verfügung. Die Mitarbeiter sind in ihren Aufgabenbereichen nicht resourcenbasiert optimiert, haben Zeiten um an anderen Stellen aus zu helfen und sind entspannter. Es fühlt sich besser an und das Ergebnis ist dennoch besser. Je kleiner die Losgrößen (batch sizes) in diesem System sind, desto besser und optimaler funktioniert das Gesamtsystem.

Kommentare 0

Das Risiko „Projektverzug“ für große Vorhaben halbieren

Klassische Projektmanagement Methoden können von Agilen Methoden profitieren

In großen, klassischen Projekten gibt es vor größeren Meilensteinen und besonders vor der End-Abnahme viel Stress. Mitarbeiter machen Überstunden und der Projektleiter bangt der Abnahme entgegen.
Agile Vorhaben sagt man nach, dass dies nicht in dem Maße der Fall ist – wie kann das sein?

Einer der agilen Werte „Customer Collaboration Over Contract Negotiation” adressiert diesen Punkt. Noch wichtiger als die gute und vertrauensvolle Verhandlung von Verträgen ist die offene und transparente Zusammenarbeit mit dem Kunden während der Umsetzung.
Die Zusammenarbeit mit dem Kunden findet regelmäßig und kontinuierlich satt. Die Entscheidung über die wertschöpfenden Elemente [PBI’s] (Product backlog Items) sind ein wichtiges Thema bei dieser Zusammenarbeit. Die Elemente werden zu einer frühen Projektphase nur grob umrissen um dem Team eine relative Bewertung der Komplexität zu ermöglichen. Das geht schnell, bindet wenig Zeit und Geld aber ist zu dieser frühen Phase der Genauigkeit der Anforderung zumeist angemessen.
Zu Beginn der aktuellen TimeBox wird mit dem aktuellen Wissen der Umfang und die Sonderfälle zusammen mit dem Kunden besprochen. Interaktion zu diesem Zeitpunkt im persönlichen Gespräch zwischen Kunde und Team ist effizient und fördert das gegenseitige Verständnis. Nach jeder festen Zeiteinheit werden diese kurz vorher im Detail besprochenen PBI’s vom Kunden getestet und abgenommen. Wenn es Abweichungen in der Umsetzung zur Erwartungshaltung gibt, wird dies sehr früh und dann auch noch regelmäßig sichtbar. Anpassungen können während der gesamten Zeit der Zusammenarbeit vorgenommen werden.
Die Abnahme ist in diesem Sinn der Umsetzung sehr gut vorbereitet, der Kunde wie auch das Team wissen was da abzunehmen ist. Je nachdem wie weit die Sprint-Reviews in einem klassischen Projekt auch vertraglich als Teilabnahmen vereinbart wurden, kann so das Risiko der Ablehnung mindestens halbiert werden. Wenn zur Abnahme nur der Liefergegenstand aus dem Team selbst Bestandteil ist, kann das Risiko noch weit geringer sein.
Agile Prinzipien können so auch in klassischen Projekten eingebracht werden, die aus besonderen Gründen nicht vollständig als Agile Entwicklung ablaufen können.

Kommentare 0

Stolze Mitarbeiter in produktiven Teams durch einen Wettbewerb: „Der beste Fehler der Woche“

Mitarbeiter sind in kreativen Aufgabenstellungen das größte Potenzial. Für Personal fallen die höchsten Kosten an.
Zufriedene Mitarbeiter sorgen für höhere Produktivität, setzen sich ein und nehmen andere mit.

Zufriedenheit wollen Unternehmen mit Feelgood Managern und Obst am Arbeitsplatz erreichen. Das Wichtigste für die kreativen, motivierten und zufriedenen Mitarbeiter ist ein Arbeitsumfeld wo diese die Kreativität auch entfalten können.
Organisation im Unternehmen ist nicht das Organigramm – es ist die Art wie diese Mitarbeiter zusammenarbeiten, gemeinsam Probleme lösen und kreativ sind.
(die meisten) Menschen arbeiten gern in Teams. Das kommt den sozialen Bedürfnissen entgegen und fühlt sich gut an. Funktionsübergreifende Teams sind Zusammenschlüsse von Menschen mit unterschiedlichen Fähigkeiten und Fertigkeiten die sich ergänzen. Nicht die Mitarbeiter einer vertikalen Linienorganisation – Abteilung.
Die Aufgabe des Unternehmens ist es, die dafür erforderlichen Strukturen, und Freiräume zu schaffen. Freiraum heißt hier Entscheidungsfreiräume und Bevollmächtigung. Diese Freiräume nutzen Mitarbeiter dann, wenn eine Kultur für Fehler besteht.
Loben Sie doch einen Wettbewerb für die besten Fehler der Woche aus, die bisher im Team noch nicht gemacht wurden und die zu einer späteren Phase des Projekts viel teurer gewesen wären. Die Teammitglieder bekommen Kuchen vom Team und machen einen Vorschlag um diese Fehler zuverlässig zu vermeiden.