Stellen Sie sich vor, sie haben gerade Feierabend und ihr Magen knurrt – so gehen sie noch schnell zum Supermarkt und holen sich alle Zutaten für ihr Lieblingsgericht “Nudeln mit Tomatensauce”. Der fleißige Supermarktmitarbeiter füllt die Regale sobald er Zeit hat auf. Genau dieses Beispiel beschreibt das Pull-Prinzip: Sie ziehen sich eine Ressource, in diesem Fall Pasta und Tomatensauce und der Mitarbeiter füllt die leer gewordenen Plätze wieder auf – jedoch steht er nicht bereit und wartet bis Sie kommen um sich die Lebensmittel zu kaufen, sondern reagiert auf Ihren Einkauf in einer freien Minute. Das Pull-Prinzip lässt Sie immer dann konsumieren/ eine Ressourcen ziehen, wenn Sie den Bedarf dazu haben.
Doch was haben jetzt Nudeln und Tomatensauce mit der Softwareentwicklung zu tun?
Was ist das Pull-Prinzip und wie funktioniert dieses in der agilen Softwareentwicklung?
Das Pull-Prinzip ist einer der Grundprinzipien der Lean Management Philosophie, welches mittlerweile in vielen Branchen vertreten ist. Diese besagt unter anderem, dass eine Produktion, Handlung oder Dienstleistung vom Kunden angestoßen wird. Im Fall von Softwareentwicklung, fängt der Entwickler erst an Ihrer Software an zu arbeiten, wenn bei Ihnen Bedarf dazu besteht. Sie haben z.B. eine gut laufende Webanwendung, bei welcher Ihnen nun während des Arbeitsalltages aufgefallen ist, dass ein neuer Funktionsumfang diese perfekt abrunden würde. So erstellen Sie dem Software Unternehmen ein Ticket (dazu später mehr) und die Entwickler können mit diesem Ticket weiterarbeiten.
Wo sind die Vorteile vom Pull-Prinzip hingegen dem Push-Prinzip?
Zusammengefasst führt das Pull-Prinzip dazu, Handlungen und Dienstleistungen der wirklich benötigten Nachfrage auszuführen und nicht nach Vermutung oder Prognosen zu handeln. In einem Unternehmen können so unnötige Aufwände vermieden werden und der Projektablauf wird verbessert. Darüberhinaus ist es viel leichter die Arbeit pünktlich zu erledigen, da nur die tatsächliche Nachfrage bedient wird.
Im Push-Prinzip wird die vermutete Nachfrage bedient, die oft nicht mit der tatsächlichen Nachfrage übereinstimmen kann. So entstehen Aufwände, die unerwartet teuer werden können. Ein kleines Gedankenexperiment über ein fiktives Worst-Case Szenario: Sie haben bei uns eine neue Business-Webanwendung entwickeln lassen, die Ihre internen Arbeitsprozesse automatisieren kann, vorher haben Sie alles via Excel und E-Mail organisiert. Nach dem Sie zufrieden das Projekt abgenommen haben und die Webanwendung bereits nutzen, fällt einem unserer übereifrigen Mitarbeiter ein, dass es super gut wäre, wenn es einen Dateiupload gäbe (brauchen Sie bisher nicht). So geht er zu einem Entwickler und beauftragt ihn diesen Dateiupload so schnell wie möglich zu programmieren. Dieser muss Überstunden machen um diesen zu programmieren und seine normale Arbeit ebenfalls zu erledigen. Beim morgentlichen Kaffee fällt auf, dass sein Teamkollege momentan gar nicht ausgelastet ist.
So sollte es doch nicht laufen oder? Denn in diesem Gedankenexperiment hat sich gezeigt, dass das Push-Prinzip versucht sich gegen ein höhere mögliche Nachfrage (vielleicht hätten sie sich diesen Dateiupload gewünscht) abzusichern, indem man vor- und überproduziert.
Das ist das Gegenteil von dem Pull-Prinzip, bei welchem Sie sich bei uns gemeldet hätten, um uns diese Aufgabe zu stellen und ein Entwickler, der Zeit hat, diese Aufgabe bearbeiten kann. Im Pull-Prinzip werden so verschwenderische Arbeiten vermieden und der Entwickler kann sich auf seine wichtigen Aufgaben konzentrieren um diese pünktlich zu erledigen.
Wie sieht die Verwaltung des Pull-Prinzip aus?
Wir arbeiten mit dem Kanban-System, welches ebenfalls zum agilen Projektmangement gehört. Durch die Begrenzung der Arbeit, welche pro Spalte ausgeführt wird, ist ein optimaler Workflow und eine Qualitätssicherung stets gewährleistet.
Wir arbeiten mit folgenden 7 Spalten:
- to-do (Erstellt, noch nicht bearbeitet)
- in progress (in Bearbeitung)
- to review (Fertig für die Qualitätssicherung)
- in review (Qualitätssicherung in Bearbeitung)
- review done (Qualitätssicherung erfolgreich)
- to deploy (Zur Veröffentlichung freigegeben)
- done (Erledigt)
In die “To-Do” Spalte werden offene und benötigte Aufgaben eingestellt. Das kann von dem Kunden, dem Product-Owner oder auch in unserem Fall, vom Entwickler selbst eingestellt werden. Der nächste verfügbare Mitarbeiter holt sich dieses Ticket und schiebt es in die Spalte “in progress”. So wissen alle Projektbeteiligte, von wem diese Aufgabe gerade aktiv bearbeitet wird. Allerdings kann ein Mitarbeiter nur ein weiteres Ticket bearbeiten, wenn dieses eine definierte Maximalanzahl an Tickets nicht überschreitet. Sobald der Mitarbeiter das Ticket bearbeitet hat, verschiebt er es in die Spalte “to review. Hier kann ein anderer verfügbarer Mitarbeiter prüfen ob die Aufgabe/das Ticket richtig erledigt wurde (in review) – denn vier Augen sehen immer mehr als zwei. Sollte alles korrekt sein, wird das Ticket in die Spalte “to deploy” verschoben, bei welchem die Softwareerweiterung/änderung veröffentlicht werden. Sobald die Veröffentlichung stattgefunden hat, findet man das Ticket geschlossen in der Spalte “done” wieder.
Multitasking kann vielleicht im Haushalt funktionieren, doch wenn wir mal ehrlich sind, versucht man viele Dinge parallel zu machen, ohne eins zu 100% korrekt und zügig zu erledigen. Alleine wenn sich ein Entwickler jedes mal wieder in den “Code hineindenken” muss, vergeht Zeit, welche vermieden werden kann. So kann er sich in diesem Singletask-Modell immer auf eine/wenige Aufgaben konzentrieren, diese optimal abschließen und dann eine neue Aufgabe annehmen.
Die Vorteile des Pull Prinzips
Wir arbeiten nun schon lange Zeit mit dem Pull-Prinzip, bei internen, sowie bei externen Projekten. Dabei konnten wir folgende Vorteile für uns feststellen:
- Verbesserte Arbeitseffizienz
- Minimierte Aufwände, da nicht vorproduziert wird. So ist die Kapazität von Team & Aufwänden besser einschätzbar
- Auswertbare Daten um Prognosen erstellen zu können, wie viel Arbeit in einem bestimmten Zeitraum erledigt werden kann
- Ressourcen werden nachhaltig genutzt
- Überstunden werden vermieden
- Flexibilität im Arbeitsablauf
Sie sind neugierig darauf geworden, ob das Pull-Prinzip auch bei Ihnen anwendbar ist? Wir freuen uns auf Ihre Nachricht und beraten Sie gerne individuell und persönlich, um auch Ihre Arbeitsabläufe zu optimieren.
