Direkt zum Hauptbereich

Was ist eine gute Projektorganisation im Unternehmen? Teil 1

Das Scrum-Training ist zu Ende. Alle Beteiligten sind zufrieden. Viele neue Erkenntnisse. Aber wie setzt man sie um? Wie geht man mit den bestehenden Strukturen um?

Scrum sieht drei Rollen vor

Der Scrum Guide sieht bewusst drei Rollen vor: Product Owner, Scrum Master und Mitglied im Development Team. Nicht weil die "Methode" das so vorschreibt, sondern weil die Erfahrungen und Daten in dieses Organisationsdesign geflossen sind. Kleine, autonome, stabile Teams haben die achtfache Produktivität gegenüber großen Teams, deren Zusammensetzung sich ständig ändert und die nicht über die Dinge entscheiden dürfen, die für die eigene Arbeit wichtig ist. Sehen Sie sich einfach mal die Datenlage an.

Der Scrum@Scale Guide sieht Mechanismen für eine skalenarme Organisation vor. Wie organisieren wir viele Teams so, dass die Produktivität und die Liefergeschwindigkeit nicht sinkt. Auch hier gab es erst die Daten, bevor es den Guide gab.

Der Nexus Guide sieht verschiedene Mechanismen vor, um viele Teams zu organisieren, die an einem Produkt arbeiten. 

Ist Auslastung wichtiger als Erfolg?

Wenn die Daten so lange schon bekannt sind, warum halten wir immer noch an alten Strukturen fest? Eine große Rolle spielt unsere Weltsicht.

Wir wissen zwar, dass Multitasking dem Unternehmen schadet und Auslieferungszeiten massiv verlängert. Aber die eigene Auslastung kann ich wenigstens messen. Ich habe das Gefühl, wichtig zu sein. Ich bin eine gute Führungskraft, wenn ich in vielen Projekten und Meetings mithelfe. Ich bin einen gute Mitarbeiterin, wenn ich zu 100% ausgelastet bin. Richtig? FALSCH. Wichtig ist, was am Ende geliefert wird, wofür ein Kunde bezahlt.

Hoher Durchsatz und geringe Auslastung muss das Ziel sein. Ein Geschäftsführer hat mir mal gesagt: "Ich verstehe das schon, Herr Fischbach. Aber ich fühle mich damit gar nicht wohl."

Die Befürchtung ist oft, dass die Organisation durch Veränderungen NOCH langsamer wird, als sie jetzt schon ist. Aber was heißt eigentlich genau langsam?

Wie effizient sind Ihre Prozesse?

Wenn wir wissen wollen, wie schnell etwas fertig wird, messen wir die Durchlaufzeit für einen Vorgang. Leider besteht nur ein kleiner Teil der Durchlaufzeit darin, dass auch wirklich an dem Vorgang gearbeitet wird (mit dem Ziel den Vorgang abzuschließen). Neben der Bearbeitungszeit gibt es noch weitere Zeitanteile:
  • Rüstzeiten: es muss etwas vorbereitet werden, um dann mit der eigentlichen Arbeit zu beginnen.
  • Transportzeiten: es muss etwas an einen anderen Ort transportiert werden.
  • Liege- oder Wartezeiten: an dem Vorgang wird nicht gearbeitet.
Ich habe mal bei einem Kunden gemessen. Wir haben typische Supporttickets gesammelt, die Dauer von Anlage bis Abschluss und die reine Bearbeitungszeit gemessen. Wir kamen dort auf ein Verhältnis von 1 Tag für die Bearbeitung bei Laufzeit von 20 Werktagen, also eine Prozesseffizienz von 5%.

Prozesseffizienz = Bearbeitungszeit / Durchlaufzeit = 1 Tag / 20 Tage = 0,05

Ist es besser oder schlechter, wenn der Bearbeiter doppelt so schnell arbeitet? Wenn ich die Bearbeitungszeit von 1 Tag auf einen halben Tag reduziere, bin ich auch einen halben Tag eher fertig.

Prozesseffizienz = Bearbeitungszeit / Durchlaufzeit = 0,5 Tag / 19,5 Tage = 0,026
Prozesseffizienz für einen Vorgang
Die Prozesseffizienz hat sich also verschlechtert. Wir sehen uns also an, ob wir nicht die anderen Zeitanteile reduzieren können.

Kommentare

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

Ein Pfad durch den Skalierten Scrum Dschungel (10 Frameworks und ein Ratschlag)

Und wie mache ich es, wenn mehrere Teams mit Scrum arbeiten sollen? Bei uns soll die ganze Firma mit Scrum arbeiten. Wie beginnen wir?  Wie gehen wir am Besten damit um, wenn wir teamübergreifend agil werden wollen?  Wir setzen in der Firma SAFe ein – was hälst Du davon? In beinahe jedem meiner Professional Scrum Master Trainings werden solche und ähnliche Fragen zum Thema „Skaliertes Scrum“ gestellt. Das Framework Scrum selbst sagt wenig über die Art und Weise wie man es im Enterpriseumfeld erfolgreich einsetzt. Und doch ist der Bedarf an Lösungen wie man firmenweit agil zusammenarbeiten kann riesig. Inzwischen gibt es eine Reihe an Skalierungsframeworks die versuchen, diesen Bedarf zu decken. In diesem Blogpost geb ich eine Übersicht über die unterschiedlichen Ansätze und Frameworks und versuche damit einen Pfad durch das unübersichtliche Dickicht der Frameworks zu schlagen. Die bekanntesten Skalierungsframeworks: SAFe leSS Nexus Spotify Unfix Scrum@Scale Flight Levels Und noch mehr

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)