Design Thinking – Buch Empfehlungen

Design Thinking erfreut sich einer steigenden Beliebtheit in Deutschland. Immer wieder kommt in unseren Trainings und bei unseren Kunden daher die Frage auf, was ist das eigentlich? Hast du eine Buchempfehlung für mich, damit ich mich einlesen kann? In diesem Blog haben wir euch ein paar Bücher zusammengestellt die wir gelesen haben und mal unseren „Senf dazu gegeben“.

Falls du dich gerade noch fragst was Design Thinking überhaupt ist schau dir vorher doch noch dieses kleine Video an.

Übersicht

Alle Bücher findet ihr hier in unserer Tabelle einmal übersichtlich zusammengestellt. Aufgebaut ist sie nach dem Shu Ha Ri Prinzip, damit du schnell ein Gefühl hast, um was für ein Detail es sich handelt und so schnell weisst ob dieses Buch vom Wissensstand zu dir passt oder etwas für später ist. Design Thinking – Buch Empfehlungen weiterlesen

Entscheidung auf mehreren Ebenen

Agiles Portfoliomanagement bedeutet Ermächtigung.

Es gibt nur einen Grund, um Unternehmen in mehreren Ebenen zu organisieren: Dadurch werden die unterschiedlichen Planungshorizonte miteinander verbunden und große strategische Aufgaben in bearbeitbare Häppchen geschnitten und umgesetzt.

Um dieser Strukturierung auch Sinn zu geben, ist Ermächtigung nötig. Verantwortliche auf allen Ebenen sollten ermächtigt werden – auf Basis bisheriger Ergebnisse oder anderer Grundlagen – Entscheidungen zu treffen, um das Unternehmen zu steuern.

Entscheidung auf mehreren Ebenen weiterlesen

Agiler Takt auf drei Ebenen

Die drei Planungsebenen einer Organisation adressieren unterschiedliche Fragestellungen:

  • Die strategische Ebene beschäftigt sich mit Fragen wie Budget- und Ressourcenplanung oder dem Eintritt in neue Märkte.
  • Die taktische Ebene gibt Aufschluss darüber, inwieweit die strategischen Ziele erfüllt sind; zudem bieten größere Funktionspakete, die hier geplant werden, eine gute Grundlage für Stakeholder-Feedback auf ein integriertes Gesamtprodukt.
  • Auf der operativen Ebene geht es um den nächsten kleinen Schritt. Im Vordergrund stehen Details und die genaue Ausgestaltung einer Lösung. Feedback ist hier bereits möglich und wichtig, die Entwicklung zeigt aber noch keine signifikante Veränderung im Big Picture.
Agiler Takt auf drei Ebenen weiterlesen

Priorisierung & Cost of Delay

Wie können Projekte priorisiert werden?

Wer limitieren und damit den Durchsatz optimieren will, muss Projekte zunächst priorisieren. „Stop starting & start finishing“ heißt, eine klare Aussage darüber zu treffen, was als Nächstes gemacht werden soll – und was eben nicht. Wer nicht in der Lage ist zu priorisieren, bringt das Unternehmen um viel Geld. Zwei Aufgaben als gleich bedeutend anzusehen und parallel bearbeiten zu lassen bedeutet, die Laufzeit beider Aufgaben zu verdoppeln. Was niemand direkt möchte, geschieht damit indirekt: Aufgaben dauern länger als nötig, wodurch Wert später generiert wird und sie kosten durch zusätzliche Rüst- oder Einarbeitungszeiten mehr als geplant.

Priorisierung & Cost of Delay weiterlesen

Company Kanban

Wie können strategische, taktische und operative Ebene
zusammengeführt werden?

Um diese durchgängige Agilität zu schaffen, muss eine Voraussetzung erfüllt sein: das gemeinsame Verständnis über die Strategie und jene Parameter, an denen sich ablesen lässt, ob der strategische Ansatz am Markt erfolgreich ist oder nicht und inwieweit die Ziele erreicht wurden oder noch erreichbar sind. Dieses Verständnis lässt sich nur durch regelmäßige Kommunikation zwischen dem strategieverantwortlichen Management und den Mitarbeitern der umsetzenden Einheiten schaffen. Für das Verständnis und das Zusammenspiel der einzelnen Steuerungsebenen in einem Unternehmen hat sich das Konzept der „Flight Levels“ bewährt [vgl. Leopold 2016 und Leopold 2018] 1, 2

Company Kanban weiterlesen

Agiles Portfoliomanagement

„Am Rande einer Einführungsveranstaltung wurde ich in ein Gespräch mit einem Trainingsteilnehmer verwickelt. Der Teilnehmer habe – nachdem er anfänglich skeptisch gewesen sei – verstanden, warum er und sein Team ihre Arbeitsweisen ändern müssen. Er sei gespannt, wie lange es dauert, bis dieser Change vorbei sei.“

Vorbei? Das ist der springende Punkt: Die Transformation hört nie auf. Agile Transition bedeutet nicht, punktuell agile Arbeitsweisen in einem Unternehmen zu etablieren oder ein bestimmtes Framework einzuführen. Agilität bedeutet eine nachhaltige Veränderung im Denken, in der Philosophie und in der Kultur eines Unternehmens. Nicht einzelne Teams sollten sich nach agilen Werten und Prinzipien ausrichten, sondern die gesamte Organisation.

Agiles Portfoliomanagement weiterlesen

Das Meeting – ein Organisations-Bug

Du hast zu viele Meetings im Kalender und weißt nicht mehr, wo dir der Kopf steht? So geht es vielen.
Und die schlauen Ideen für bessere Meetings helfen gar nicht? Das kann ich gut nachvollziehen.

Ich schlage dir vor, ein Meeting wie einen Fehler zu behandeln, wie einen „Organisations-Bug“, und daran zu arbeiten, das Meeting zu beseitigen – statt es zu verbessern.
Einen Softwarebug wollen wir nicht optimieren, sondern an der Ursache packen und für die Zukunft verhindern. Das sollten wir auch mit Meetings anstreben. Viele von ihnen entstehen nämlich in Folge von Fehlern beim Organisieren von Arbeit.

Natürlich gibt es sinnvolle Zusammenkünfte. Das agile Arbeiten sieht mehrere davon vor: Ein Team erzeugt aus einer neuen Aufgabe in einem kreativen Prozess eine neue Lösung. Ein Gremium wählt aus verschiedenen Handlungsoptionen per Entscheidung eine Option aus. Wir kommen alle zusammen, weil Informationen verteilt, oder Meinungen eingeholt werden sollen. Und wir wollen als soziale Wesen gerne in Kontakt mit den anderen Menschen sein. Das ist völlig in Ordnung. Diese Treffen nenne ich hier Arbeitsmeetings.

Aber sonst? Die vielen Abstimmungs-, Koordinations-, „Wir setzen uns mal zusammen“- und „nächste Woche machen wir weiter“ – Meetings braucht es nur, weil jemand etwas tun soll oder will, was er nicht kann, nicht darf oder sich nicht traut. Denn sonst könnte er/sie es ja einfach tun. Der Fehler liegt offenbar im Auftrag, im Ziel, in der Fähigkeit oder in der Befugnis.

Ein solches nicht-Arbeitsmeeting ist ein Hinweis, dass etwas Ungeregeltes zu regeln ist. Es ist ein Bug in der Organisation aufgetreten. Man dachte, dass alles klar sei, das ist es aber offenbar nicht. Jemand kennt die Richtung nicht, kann die Aufgabe fachlich nicht erledigen, oder darf es nicht. Also müssen die Regeln angeschaut und angepasst werden.

In Organisations-Deutsch kann man sagen, dass die „AKVs“ (Aufgabe, Verantwortung, Kompetenz) nicht zusammenpassen. Denn sonst könnte ein Mensch die Aufgabe schlicht erledigen: Er weiß, was er soll; darf, was er braucht; und kann, was er muss.

Der Ansatz zur Lösung liegt darin, die Ursachen in den Regeln und Rahmenbedingungen zu ergründen:

Ist die Richtung klar?

Ist der Auftrag präzise?

Passen die Fähigkeiten?

Reichen die Befugnisse?

Wie steht es um die Traute?

Wer die Fragen aufrichtig beantwortet, kommt auf ganz andere Suchräume für die Lösungen, und muss vermutlich kein „Folgemeeting“ einberufen:

Da braucht jemand Orientierung oder Info über Prioritäten,

braucht Hilfe beim Klären des Auftrags oder der Anforderung,

braucht Unterstützung beim Aufbau von Fähigkeiten,

braucht andere Befugnisse und Entscheidungskompetenzen,

oder braucht Zuspruch, um sich zu trauen.

Und schon riecht es nach Führungsarbeit. Denn die aufgeführten Fragen sind von denjenigen Rollen zu beantworten, die die Arbeit von und für andere organisieren. Das sind die Vorgesetzten, Führungskräfte, Product Owner, Team Leads, Scrum Master, usw., usf. Wer sich die Mühe der Führungsarbeit spart, seine Leute bestmöglich mit Orientierung, Auftrag, Fähigkeiten, Befugnissen und Traute auszustatten, verursacht Meetings. Wer die Mitarbeitenden nicht entwickelt, nötigt sie in Meetings, die ihnen die Kalender vollmachen und die sie vom Arbeiten abhalten. Das kann man den Mitarbeitenden vorwerfen, aber Schuld sind sie nicht.

Eine Organisation, die insgesamt unter der Last der vielen Meetings leidet, schiebt eine technische Schuld an Organisations-Bugs vor sich her. Haben sich erst einmal alle Mitarbeitenden mit den unklaren Zuständen arrangiert, setzt sich der Meetings-Missstand fort. Niemand kann sich leisten, irgendwo zu fehlen.

Es ist eben wie bei einer Software, die „buggy“ ist: Alle organisieren sich dann aufwändig um die Fehler herum und halten das irgendwann für normales Leiden.

Wer viel „meeten“ muss, ist offenbar schlecht organisiert.

Foto von unsplash.com by rodeo-project-management-software

Krise als Chance für Wandel

Eine Krise ist nicht nur ein Bedrohungszustand für ein Unternehmen. In einer Krise herrschen bessere Ausgangsvoraussetzungen für Veränderungen im Unternehmen als zu „normalen Zeiten“. Wer diese Bedingungen in einer Krise als Chance nutzt, die eigene Wettbewerbsfähigkeit zu verbessern, geht gestärkt aus der Krise hervor und sichert sich langfristig einen höheren Unternehmenserfolg.

Krise als Chance für Wandel weiterlesen

Karte der Veränderung – Orientierung bei Veränderungen

Was gehört alles zu einer erfolgreichen Veränderung dazu? An was muss ich denken? Mit der Karte der Veränderung geben wir Ihnen einen Überblick über die wichtigsten Elemente einer erfolgreichen Organisationsveränderung. Wir haben dazu die Begriffe aufgezeichnet und zueinander in Beziehung gesetzt. Auch wenn die Karte mit einem Augenzwinkern gestaltet ist, so ist es dennoch eine ernstgemeinte Topologie der zentralen Begriffe einer erfolgreichen Prozessverbesserung. Sie bereitet die Erfahrung vieler erfolgreicher Prozessverbesserungsprojekte, die wibas mit seinen Kunden durchgeführt hat, graphisch auf.

Wie setzen Sie Veränderungen und Verbesserungen in Ihrer Organisation systematisch und nachhaltig um? In der Schulung zur Karte der Veränderung lernen Sie die Methoden und Techniken.

Karte der Veränderung – Orientierung bei Veränderungen weiterlesen

Wie skaliert Scrum?

Scrum ist für Teams mit einer Größe von fünf bis neun Personen gedacht. Scrum skaliert, indem man für größere Projekte mehrere Scrum Teams aufsetzt.

Jedes der Teams nutzt das Scrum Framework: es gibt für jedes Team genau einen Product Owner und einen Scrum Master. Die Product Owner haben die Verantwortung, ein gemeinsames Product Backlog zu führen. Sie bilden zusammen ein Product Owner Team. Zusammen ordnen sie das Product Backlog. Für die Product Backlog-Einträge, die für den nächsten Sprint in Frage kommen, entscheidet das Product Owner Team, welches der Scrum Teams den jeweiligen Product Backlog-Eintrag umsetzen soll. Das Product Owner Team bildet also aus dem Gesamt-Product Backlog einzelne Product Backlogs für die jeweiligen Scrum Teams.

Wie skaliert Scrum? weiterlesen