Ich glaube, der Kunde von heute ist ebenso verwirrt wie ich und sucht Sicherheit, Verlässlichkeit, also Produkte, die ihm einen echten Wert verschaffen. Wert ist “das Gute”, was in einem Produkt steckt, eben der Grund, warum jemand das Produkt interessant, attraktiv, gebrauchsfähig, praktisch oder kaufenswert findet.

Platon glaubte (um 400 vor Christus) ja noch, ein Ding habe zwei Werte: einen intrinsischen (also fest eingebauten) und einen extrinsischen, weil es uns hilft, etwas damit tun zu können. Ein Weinglas zum Beispiel könnte schön oder antik sein (intrinsisch), und man könnte vielleicht gut daraus trinken (extrinsisch). Jedes Produkt hätte also nach Platon einen Wert aus seiner Essenz heraus und einen aus der Erfahrung heraus, die man mit dem Produkt macht.

Mehr als 2000 Jahre später kam Adam Smith. Er schrieb 1776 darüber, dass es einen Gebrauchswert gebe und einen Tauschwert. Aha, da kommt das Geld ins Spiel, was natürlich alles verändert (sie erinnern sich: Ein wenig Silber auf der Rückseite einer Glasscheibe macht den großen Unterschied!). Der Gebrauchswert beschreibt, wie gut mir ein Ding hilft. Der Tauschwert hingegen beschreibt, welche Macht das Ding hat, andere Dinge zu erkaufen.

Fast zweimal hundert Jahre später gab es schon längst das industrielle Zeitalter, und der amerikanische Philosoph John Dewey äußerte 1949, dass der Wert eines Produktes (extrinsisch und intrinsisch) von der Situation abhängt, in der es sich befindet. Beispielsweise könnte ein Weinglas auf dem Tisch oder in der Hand einen höheren extrinsischen Wert haben, als wenn es im Schrank steht. (Vor ihm gab es noch Karl Marx, der sich in “Das Kapital” ebenfalls mit Smith auseinandersetzte und zu einem Konzept, das er “Ware” nannte, interessante Gedanken äußerte – doch “Ware” ist schon wieder ein anderes Thema).

Was sagt uns das? Wenn Sie Ihre Produktentwicklung optimieren wollen und möchten, dass die Kunden begeistert bei Ihnen kaufen (so will ich das jedenfalls von meinen Kunden), dann sollten wir uns Gedanken über Wert machen. Welchen inneren Wert haben unsere Produkte? Welchen Gebrauchswert? Welchen Tauschwert? Und, besonders interessant: Welchen Wert in genau der Situation, in der der Kunde das Produkt tatsächlich benötigt?

Ein Kunde kauft, wenn seine Einschätzung des Gebrauchswertes oder des Wertes in der aktuellen Situation deutlich größer ist als der Tauschwert (der Preis) des Produktes, oder? Denke ich mir zumindest, wenn ich mein eigenes Kaufverhalten beobachte. In meiner Beratungspraxis zeige ich Klienten, wie sie den Gebrauchswert und den Wert in der aktuellen Situation so deutlich steigern können, dass die Kunden kaufen.Diese Beiträge könnten Sie noch interessieren:

• Relative Feature-Bewertung
• Geschäftsmodelle für Ihre Softwarefirma
• Drei Fragen zu Ihrer Produktstrategie
• Mehr Erfolg in der Produktentwicklung (Strategie)
• Coaching

Die Fehler kommen manchmal schneller als man sie beseitigen kann. Klar, es gibt gute Spezifikations- und Testverfahren wie TDD, ATDD, BDD, mit denen Entwickler Feedbackschleifen einbauen können, um Fehler so schnell wie nur irgend möglich zu bemerken. Schlägt so ein Test fehl, kann man den Bug gleich fixen, ohne dass er weiteren Schaden anrichten könnte.

Manche Bugs schlüpfen jedoch bis zum Kunden durch. Dieser bemerkt sie, meldet sie dem Support, der ihn aufnimmt und den Entwickler schon wieder etwas mehr zu tun gibt. Manchmal nimmt die Zahl der Bugs so schnell zu, dass sie nicht mehr rechtzeitig fertig werden mit dem Fixen und das Produkt langsam an Qualität verliert. Sie entscheiden sich, den Releasetermin halten zu wollen und liefern aus, inklusive Bugs. Ihre Entwickler verlieren an Kapazität, weil sie sich um Bugs kümmern müssen. Der Return on Investment pro neu eingebautes Feature lässt nach. Das ist meist der Anfang vom Niedergang eines Produktes. Diesen Anfang sollten Sie hinausschieben, zuerst so weit wie möglich und später so weit wie es geschäftlich Sinn ergibt.

Zu viele Bugs – wie kommt’s?

Bugs entstehen als unliebsame Nebenwirkung von Änderungen an der Software. Eine an sich nützliche Änderung an einer Stelle A des Programmcodes führt dazu, dass eine Stelle B sich nicht mehr so verhält wie sie soll. Offenbar muss B eine Verbindung zu A gehabt haben, sonst wäre B nicht betroffen gewesen. Als Softwarearchitekten nennen wir das Kopplung.

Eine Stelle B ist an eine Stelle A gekoppelt, um mit ihr Informationen auszutauschen oder einen Kontrollfluss auszulösen. Beispielsweise könnte ein Bug in einem Report entstehen, der Kundendaten ausgibt, weil jemand an der Struktur oder am Code für die Kundendaten etwas geändert hat, ohne an die Reports zu denken. Wir sagen, der Report ist an das Konzept Kunde gekoppelt.

David Parnas, einer der Väter des modernen Software-Engineerings, hat vier Arten der Kopplung identifiziert:

Alle diese Fälle führen dazu, dass Sie B nachtesten müssen, sobald Sie an A etwas ändern. Je mehr Kopplung Sie in das System einbauen, umso mehr Stellen gibt es, die von Änderungen betroffen sein werden und deshalb nachgetestet werden müssen.

Was können Sie tun?

Also muss es ein Ziel sein, geringe Kopplung im System zu haben. Am besten, wir eliminieren alle Arten von Kopplung, oder? Nein, im Ernst, ein System ohne Kopplung tut auch nichts mehr, was geschäftlich interessant wäre. Also müssen Sie als Entwickler oder Softwarearchitekt auf lose Kopplung achten.

Schaffen Sie Bereiche im Code, die gemeinsam etwas Sinnvolles tun, und zwar konzentriert auf ein Thema. Jeder dieser Bereiche sollte an den Rest des Codes nur über ganz definierte Wege gekoppeltsein. Rufen Sie den Rest des Codes nur über diese Wege auf, anstatt alles und jedes im System freifliegend aufzurufen. Versuchen Sie, die Zahl der Kopplungen so gering wie irgend möglich zu halten, indem Sie eindeutige Zuständigkeiten im Code schaffen und nur diese aufrufen.

Alarmsignale

Worauf müssen Sie achten, wenn Sie existierenden Code auf Kopplung untersuchen? Es gibt zwei klassische Fälle, wie man es nicht machen sollte, die immer wieder ins Auge springen. Diese werden Ihnen sicherlich schon vertraut sein:

• die “Gott”-Komponente
• die “Party”-Komponente

Die Gott-Komponente ist eine, die alles weiß und alles kann. Sie ist so interessant, dass sie von allen Seiten her aufgerufen wird und deshalb viel Kopplung erzeugt. Was ist die Folge? Kaum ändert jemand etwas an dieser Gott-Komponente, müssen alle Stellen, die Gott aufrufen, nachgetestet oder sogar angepasst werden. Meiden Sie Gott-Komponenten, indem Sie sie in kleinere zerlegen, die keine Götter mehr sind.

Die Party-Komponente ist das Gegenteil davon: Sie ist ein sehr soziales Wesen, kommuniziert und feiert gern. Sie ruft dafür viel zu viele andere auf, was wiederum viel Kopplung erzeugt. Was ist die Folge? Kaum ändert jemand etwas an einer der aufgerufenen Komponenten, schon muss die Party-Komponente nachgetestet oder sogar angepasst werden. Meiden Sie Party-Komponenten, so weit es geht. Lassen Sie Komponenten immer nur in kleinem Kreise feiern und sich ansonsten über einzelne, definierte Mitglieder mit anderen Kreisen austauschen. Dafür gibt es Muster, wie Sie das arrangieren können.

War das schon alles?

Sicherlich nicht. Leider kann ich in diesem Artikel nicht über alles schreiben, was Sie brauchen, um ein perfekt wartbares System zu haben (nicht, dass Sie das überhaupt brauchen würden, aber das steht auf einem anderen Blatt). Es gibt außer Kopplung noch mehr Probleme, auf die Sie achten müssen. Davon ein anderes Mal mehr. Wenn Sie nicht auf dieses andere Mal warten möchten, können Sie mich auch gern anrufen, dann sprechen wir darüber.Diese Beiträge könnten Sie noch interessieren:

• Fünf Argumente, warum Sie fix entwickeln sollten
• Warum einen Coach nehmen?
• Budgetierung ist schädlich
• Mit TDD schreibt man Spezifikationen
• Folgen von Stress in agilen Teams

Hier habe ich 8 Tipps für Sie:

1. Bereiten Sie sich vor! Überlegen Sie sich vorher, was er für ein Interesse an dem haben könnte, was Sie vorschlagen (nicht nur, was Sie daran so toll finden). Und versetzen Sie sich in seine Lage: Was will sein Boss von ihm? Was muss er in der nächsten Zeit (z.B. in diesem Jahr) erreichen? Wenn Sie das nicht wissen, fragen Sie ihn und hören ihm zu!
2. Mischen Sie dann seine Interessen mit den Ihren – die Amerikaner nennen das dove tailing. Das bedeutet: Im Schwanz der Taube, die Sie fangen wollen, sollten sich immer eine Feder in Ihrer Farbe und eine in der Farbe Ihres Bosses abwechseln!
3. Passen Sie Ihren Boss ab, wenn er gut gelaunt ist und etwas Zeit hat. Holen Sie ihm seinen Lieblingskaffee und sprechen Sie dann über das, was Sie wollen.
4. Argumentieren Sie dabei mit dem Wert, den Ihre Idee für das Unternehmen einbringt, und nutzen Sie dafür die Sprache des Geldes. Wird Ihre Idee dafür sorgen, dass die Gruppe Ihres Bosses mehr Einkünfte generieren kann? Werden existierende Einkünfte durch Ihre Idee geschützt oder gesichert? Oder spart Ihre Idee auf grandiose Weise Kosten ein?
5. Argumentieren Sie auch in der Sprache emotionaler Werte. Bedeutet Ihre Idee z.B. weniger Stress für Ihren Boss? Oder für Ihr Team? Mischen Sie das wenn nötig mit der Sprache des Geldes: Werden vielleicht Kündigungen durch Ihre Idee verhindert? (Die Kosten für die “Wiederbeschaffung” einer Fachkraft können z.B. leicht bei mehr als 75.000 EUR liegen!)
6. Sorgen Sie unbedingt dafür, dass Sie vorher eine Ahnung davon haben, wie man Ihre Idee umsetzt! Nichts schlimmer als wenn Ihr Boss sagt: “Alles klar, ich unterstütze Sie. Und wie geht das denn jetzt in der Praxis?” – und Sie fangen an zu stottern!
7. Sagen Sie ihm, wen Sie dafür brauchen. Und wie viel Zeit. Und wie viel Geld und andere Ressourcen wie Räume, Material, usw. Und wie sich das für ihn und für Sie alle auszahlen wird. Und woran Sie das messen werden und wann er das erste Mal mit einem Messwert rechnen kann, der ihm sagen wird, ob es funktioniert oder eben nicht.
8. Wenn Sie die Genehmigung haben, dann tun Sie, was getan werden muss und halten Sie Ihren Boss zeitnah und regelmäßig auf dem Laufenden. Nichts motiviert ihn mehr, als wenn Sie ihm klar sagen können, was seine Genehmigung bewirkt hat!

Wenn Sie das so machen, haben Sie mehr als 80% Chance auf die Genehmigung. Es kostet Sie mehr Zeit für die Vorbereitung, doch die lohnt sich auf jeden Fall.

Jetzt noch ein Angebot von mir an Sie, das die 80%-Chance noch weiter vergrößert:

• Schicken Sie mir eine Mail mit Ihren Verbesserungs-Ideen. Ich übernehme die Rolle Ihres Bosses, Sie müssen mich überzeugen.
• Ich gebe Ihnen Feedback dazu.
• Sie optimieren damit Ihre Vorbereitung und gehen dann zu Ihrem Boss.
• Sie sagen mir danach, wie Ihr Boss darauf reagiert hat, und ich kann daraus lernen.
• Absolute Vertraulichkeit sage ich Ihnen jetzt schon zu.
• Falls ich Sie vorher noch nicht kannte, ist die ganze Aktion für Sie kostenlos!

Ist das ein Angebot? Was sagen Sie dazu?Diese Beiträge könnten Sie noch interessieren:

• Fünf Argumente, warum Sie fix entwickeln sollten
• Webinar: Kaizen, KVP, Kata – einfach jeden Tag besser werden
• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Verstehen, was die Software tun soll
• Produktentwicklung

Diese Beiträge könnten Sie noch interessieren:

• Google weiß sowieso alles
• Mit zwei Fingern auf dem Trackpad
• Neu: Scrum-Meisterklasse für Scrum Master
• Scrum-Meisterklasse für Scrum Master
• Fernseh-Feedback

Katalysatoren für Motivation

Natürlich ist jeder Mensch anders, dementsprechend sind seine Bedürfnisse verschieden. Doch es lassen sich drei gemeinsame Katalysatoren finden:

1. Ein Mensch im Team (oder das gesamte Team gemeinsam) sollte sich selbstständig fühlen können: “Wir können hier selbst entscheiden, es redet uns keiner in unsere Kernkompetenz hinein. Andere kümmern sich um ihre Sachen – wir können frei und ungehindert den unsrigen nachgehen.”
2. Jeder im Team sollte seine Fähigkeiten weit über den Stand hinaus entwickeln können, auf dem er gerade steht: “Ha, ich kann mich hier zum Meister meines Fachs entwickeln, und ich habe tolle Leute um mich herum, von denen ich viel lernen kann!”
3. Ein Mensch im Team muss das Gefühl haben, dass seine Arbeit einen Sinn und Zweck erfüllt: “Wow, es gibt etwas Größeres als das, woran ich hier gerade arbeite. Ich weiß, was es ist, und ich trage mit meiner Arbeit zu diesem Größeren bei!”

Als Führungskraft handeln

Sind Sie ein Chef, Firmengründer, Manager, Teamleiter, Product Owner, oder eine andere Art von Führungskraft? Dann können Sie viel für die Motivation und Zufriedenheit in Ihrem Team tun! Auch hier drei Beispiele:

1. Sorgen Sie dafür, dass das Team kein Befehlsempfänger ist, sondern an der Entstehung des Produktes wirklich konkret mitwirken kann. Geben Sie keine fertigen Lösungen vor, die vom Team lediglich “umzusetzen” sind, sondern schildern Sie den Vorteil, den der Kunde oder Nutzer des Produktes haben soll. Das Team soll dann selbst überlegen, wie es diesen Nutzen gescheit realisiert und soll Ihnen Vorschläge dazu machen.
2. Geben Sie Ihren Mitarbeitern regelmäßig Rückmeldung über das, was gut klappt und womit die Teammitglieder bereits wieder zum Gelingen beigetragen haben. Fragen Sie bei den Dingen, die noch nicht so gut klappen, wie das Team das wohl noch besser hinbekommen könnte. Bringen Sie Meister mit Anfängern oder mit Fortgeschrittenen zusammen, so dass alle voneinander lernen und selbst zu Meistern werden können.
3. Wenn Sie jemand Müdes erblicken, fragen Sie ihn, ob er den Sinn in seiner Arbeit sieht. Erzählen Sie davon, was mit den Ergebnissen, die diese Person oder dieses Team erarbeitet, alles geschieht. Bringen Sie erfolgreiche, zufriedene Nutzer Ihres bisherigen Produktes mit in die Firma und lassen Sie diese Nutzer dem Team zeigen, wie erfolgreich sie das einsetzen, was das Team gemacht hat. Lassen Sie jeden im Team sehen, wozu das gut ist, was er/sie gerade entwickelt. Und: Tun Sie’s regelmäßig, nicht nur einmal im Jahr!

Heute, ja jetzt, gleich anfangen!

Dies waren ein paar Beispiele. In Ihrer Firma gibt es bestimmt noch ganz andere Möglichkeiten, für Zufriedenheit und Motivation zu sorgen. Fragen Sie Ihre Leute: Was würde Euch am meisten helfen? Was hält Euch davon ab? Womit kann ich Euch unterstützen?

Wie Sie das machen? Sie erfahren dazu mehr in meinem kostenlosen Webinar und können es auch praktisch üben, indem Sie mein Seminar besuchen: Kaizen, KVP, Kata: Einfach jeden Tag besser werden!

In weiteren Blog-Artikeln werde ich auf weitere Verbesserungsmaßnahmen jenseits von Cash Flow und Mitarbeiterzufriedenheit eingehen, z.B. auch auf das Thema Produkt-Langlebigkeit. Und auch darauf, wie Sie solche Verbesserungsmaßnahmen systematisch in Ihrem Team-Alltag verankern.

Bis dahin: Viel Erfolg!Diese Beiträge könnten Sie noch interessieren:

• Leute feuern oder sich selbst organisieren lassen?
• Mehr Geld mit der Softwareentwicklung verdienen
• Flow in der Produktentwicklung
• W-JAX 2012: Agile Teams im Gleichgewicht
• WJAX 2011: Flow in der Arbeit – Flow im Team

Leider war das nicht der Fall! Als ich heute den App Store aufrief und den Download fortsetzen wollte, erschien eine Fehlermeldung “Fehler beim Installieren, benutzen Sie das Fenster ‘Käufe’, um fortzusetzen.” Dieser Artikel bei Apple Support half mir auch nicht weiter.

Im System-Logfile fand ich folgenden Satz:

12.04.13 10:49:51,718 App Store[19886]: PKDistributionController: 
Found asset mzm.qqpgefiz.pkg on disk for item 408981434 - Size 152698880

Deshalb meine Vermutung: Der App Store glaubt, die Datei (das “asset”) sei vollständig geladen und versucht, die Installation zu starten. Das schlägt fehl, weil erst 153 MB statt 1.36 GB geladen sind.

Nach weiteren Recherchen kam ich mit diesen 12 Schritten zum Erfolg:

1. Im App Store das Menü “Store > Abmelden” wählen
2. Die Anwendung App Store beenden
3. Ein Terminal-Fenster (Shell) öffnen
4. Eingeben: defaults write com.apple.appstore ShowDebugMenu -bool true
5. App Store wieder starten (Debug Menü erscheint!)
6. Menü “Store > Anmelden” wählen
7. Menu “Debug > Show Download Folder…” (es erscheint der Ordner, in dem die Downloads liegen, irgendwo verborgen unter “/private/var/folders…”). Dort lagen nun das teilweise geladene Asset sowie eine Datei manifest.plist.
8. App Store beenden.
9. Doppelklick auf die Datei manifest.plist
10. Es startet XCode und editiert die plist-Datei. In der Beschreibung des teilweise geladenen Assets fand sich ein boolesches Attribut “paused” mit dem Wert NO. Diesen Wert auf YES setzen.
11. App Store wieder starten.
12. Im App Store in den Reiter “Einkäufe” gehen. Dort sieht man, wie der Download plötzlich fortgesetzt und danach das Programm erfolgreich installiert wird.

Nun kann ich mich also an iMovie erfreuen und merke mir, dass ich keine App Store Käufe mehr über das Vodafone Netz machen sollte, warum auch immer.Diese Beiträge könnten Sie noch interessieren:

• Gastbenutzer unter Mac OS X absichern
• Kein Vodafone UMTS nach Mac Update?
• Amazon Kindle nicht wirklich global?
• UMTS auf dem Mac
• Cumulative Flow Diagram zeichnen in Excel

Feature-Entwicklung

Bei diesem Modell entwickelt Ihre Firma einzelne Features, die der Nutzer mit der lauffähigen Software zur Verfügung gestellt bekommt. Diese Features geben dem Nutzer neue Fähigkeiten, die er schätzt und die ihm bei der täglichen Arbeit weiterhelfen. Der Kunde bezahlt Geld für die Entwicklung eines Features, weil er es für seine Nutzer erwerben möchte. Wenn Ihre Firma diese Features entwickelt, verdienen Sie also mehr Geld, je mehr Features Sie erfolgreich entwickeln und verkaufen können.

Mitgliedschaft

Etwas anders verhält sich das bei webbasierten Clubs, in denen man Mitglied werden kann. Ein gutes Beispiel ist das Geschäftsleute-Netzwerk XING. Hier zahlen die Kunden dafür einen Mitgliedsbeitrag, dass sie Kontakte zu anderen Mitgliedern bekommen, in Gruppen diskutieren oder Events veranstalten oder besuchen können. Wenn Sie eine Clubseite entwickeln und betreiben, dann verdienen Sie mehr Geld, je mehr zahlende Mitglieder Ihr Club hat.

Transaktionen

Wieder anders ist es beim transaktionsbasierten Geschäftsmodell, wie zum Beispiel bei Amiando, bei der Deutschen Bahn oder bei Online-Shops wie Amazon. Kunden wickeln geschäftliche Transaktionen ab und bekommen Waren geliefert. Amiando liefert Tickets für Veranstaltungen, bei der Deutsche Bahn kaufe ich Fahrkarten, Amazon verkauft mir alles Mögliche. Wenn Sie Entwickler und Betreiber einer solchen Site sind, verdienen Sie mehr Geld, je mehr bezahlte Transaktionen die Kunden auf Ihrer Site durchführen.

Lizenzen

Ein Klassiker ist das auf Software-Lizenzen basierende Geschäftsmodell. Ihre Firma entwickelt Software und verkauft Lizenzen dafür, damit Kunden die Software nutzen können. Die Kunden zahlen z.B. beim Kauf einer App eine Lizenzgebühr und erwerben das Recht, die Software zu nutzen. Sie als entwickelnde Firma verdienen mehr Geld, je mehr Kunden Ihre Software einsetzen und für die Lizenz bezahlen wollen.

Wozu all die Beispiele?

Meine Kunden fragen mich oft, ob ich ihnen nicht bei interner Verbesserung helfen könnte, z.B. bei der Steigerung der Entwicklerproduktivität. Natürlich kann ich das, doch im ersten Schritt frage ich dann nach dem Geschäftsmodell, um festzustellen, ob die Entwicklerproduktivität wirklich zu mehr Wohlstand für diesen Kunden führen würde. Beim Geschäftsmodell “Feature-Entwicklung” ist das wahrscheinlich, beim Modell “Mitgliedschaft” oder “Transaktionen” ist das nicht unbedingt so klar. Würde die Firma mehr Mitglieder bekommen oder mehr Transaktionen abwickeln, wenn die Entwickler produktiver wären? Selbst bei der Feature-Entwicklung ist es häufig so, dass die Entwickler arbeiten wie der Teufel, doch die Firma trotzdem nicht mehr Geld verdient als sonst, weil es in Wirklichkeit woanders klemmt.

Was fehlt also? Der Blick auf’s Ganze – in Gestalt eines ökonomischen Modells für die Entwicklung.

Den Cash Flow verbessern

Im Artikel Lean und das Geld habe ich es schon angedeutet. Es gibt geschäftliche Variablen, mit denen sich der Geldstrom beschreiben lässt: Umsatz (T), Kosten (oE), Investitionen (I). Die Kosten entstehen sofort während der Entwicklung, der Umsatz entsteht u.U. erst später, wenn der Kunde zahlt. Um Ihre Tätigkeit zu verbessern, brauchen Sie also noch geschäftliche Variablen, die sich den Ursachen für den späteren Geldstrom zuordnen lassen:

• Entwicklerproduktivität
• Qualität der Software
• Auftragsvolumen aus dem Vertrieb
• Zahl neuer Nutzer-Registrierungen
• Nutzungszahlen für ein bestimmtes Feature
• Gründe, warum jemand Mitglied im Club wurde oder gekündigt hat
• Zahl der Transaktionen eines bestimmten Typs
• Zeiten hoher oder geringer Nutzung des Produktes
• Vergleich der Features mit dem Wettbewerb
• und vieles mehr.

Die Variablen sind spezifisch für Ihre Firma und hängen stark vom Geschäftsmodell ab. Wenn diese Variablen sich auf Euro abbilden lassen (sei es sofort oder später in der Rückschau), dann haben Sie einen Hebel, um Verbesserungsmaßnahmen anzusetzen. Fragen Sie sich bei jeder Maßnahme, die Sie planen:

• Welche Ursachenvariable versuchen wir damit zu beeinflussen?
• Wird die Maßnahme mehr Umsatz bringen?
• Wird sie existierenden Umsatz bewahren?
• Wird sie Kosten einsparen?
• Lässt sich die Investition für die Maßnahme klein halten?
• Woran werden Sie den Erfolg der Maßnahme feststellen?
• Wann wird sich das erste Mal ein Effekt aus der Maßnahme erkennen lassen?

Untersuchen Sie auch, wie stark der Einfluss der Ursachenvariablen auf die Geldstromvariablen ist. Suchen Sie dann zu jeder Ursachenvariable einen Hebel, den Sie allen Kollegen und Mitarbeitern geben können. Kollegen und Mitarbeiter können dann mit Hilfe des Hebels die Ursachenvariable günstig beeinflussen. Wählen Sie die Ursachenvariable mit dem größten Einfluss und dem leichtesten und zuverlässigsten Hebel als Grundlage für Ihre Verbesserungsmaßnahmen.

Beispiel für zwei solcher Maßnahmen:

• Sie möchten die Qualität der Software steigern, damit die Kunden begeistert sind und mehr Lizenzen kaufen, und damit die Entwickler weniger Fehler zu beheben haben, was auch die Entwicklerproduktivität steigern würde.
• Bei sehr hoher Kundenbegeisterung und zu starker Last auf den Entwicklungsteams könnten Sie anschließend den Lizenzpreis erhöhen, um mehr Umsatz zu erzielen und die Last auf den Entwicklungsteams zu reduzieren, um zu verhindern, dass Ihre Entwickler kündigen.

Hinter diesem Satz stecken gedanklich vereinfacht folgende Dinge:

Ursachenvariablen:

• Lizenzzahl
• Lizenzpreis
• Fehlerzahl
• Entwicklerproduktivität
• Gehalt
• Personalfluktuation (z.B. Leute pro Quartal)

Geldstromvariablen:

• Umsatz
• Kosten

Abbildungen:

• Umsatz = f(Lizenzzahl, Fehlerzahl, Lizenzpreis)
• Kosten = f(Gehalt, Personalfluktuation)

Bei welcher Ursachenvariable wollen Sie den Hebel ansetzen? Die lohnendste ist aus meiner Erfahrung die Fehlerzahl, denn alles andere ist nicht so leicht beeinflussbar.

Den Hebel ansetzen

Nun brauchen Sie noch Hebel, mit denen Sie die Ursachenvariablen beeinflussen können. Die Fehlerzahl hängt von mehreren Hebeln ab:

Hebel:

• Zeit bis zum Feedback über Qualität
• Architektur
• Testabdeckung
• Testarten und Teststufen

Lassen Sie Ihre Kollegen und Mitarbeiter darüber nachdenken, wie sie die Zeit bis zum Feedback minimieren können, denn schnell bemerkte Fehler lassen sich leichter beseitigen als spät bemerkte. Setzen Sie mehrere Testarten und Teststufen ein (Unit-, Integrations-, Akzeptanztests). Damit die Kosten dafür nicht zu hoch werden (z.B. unwartbare Tests), denken Sie rechtzeitig und oft genug über Ihre Architektur nach (Stichworte Kopplung und Kohäsion).

Fangen Sie an!

Dies war ein Erfahrungsbeispiel. In Ihrer Firma könnten andere Maßnahmen, andere Variablen und andere Hebel notwendig sein. Beginnen Sie mit dem dringendsten Problem. Wählen Sie die Ursachenvariable mit dem größten Einfluss und dem leichtesten und zuverlässigsten Hebel als Grundlage für Ihre Verbesserungsmaßnahmen.

Wie Sie das machen? Sie erfahren dazu mehr in meinem kostenlosen Webinar und können es auch praktisch üben, indem Sie mein Seminar besuchen: Kaizen, KVP, Kata: Einfach jeden Tag besser werden!

In weiteren Blog-Artikeln werde ich auf weitere Verbesserungsmaßnahmen jenseits des Cash Flows eingehen, z.B. auf die Themen Mitarbeiterzufriedenheit und Produkt-Langlebigkeit. Und auch darauf, wie Sie solche Verbesserungsmaßnahmen systematisch in Ihrem Team-Alltag verankern.

Bis dahin: Viel Erfolg!Diese Beiträge könnten Sie noch interessieren:

• Kopfrechnen mit Dreisprung
• Zufriedene Mitarbeiter im Team
• Geschäftsmodelle für Ihre Softwarefirma
• Drei Fragen zu Ihrer Produktstrategie
• Webinar: Kaizen, KVP, Kata – einfach jeden Tag besser werden

Möchten Sie zum Beispiel…

• Mehr wirtschaftlichen Ertrag
• Bessere Arbeitsbedingungen für die Mitarbeiter
• Ein langlebiges, gut wartbares Produkt

Machen Sie mit bei diesem kostenlosen Webinar “Kontinuierliche Verbesserung erfolgreich starten” und sprechen Sie mit mir über den neuen Workshop Kaizen, KVP, Kata: Einfach jeden Tag besser werden! Es wird im Webinar um einige der typischen Probleme mit Verbesserungsmaßnahmen gehen, von der Idee über die Genehmigung der Maßnahmen bis zur Umsetzung und Bewertung. Danach eröffne ich die Runde der Fragen und Antworten. Bringen Sie Ihre eigenen Fragen mit!

Selbst wenn Sie es zum Webinar nicht schaffen, bitte registrieren Sie sich trotzdem. Ich kann Ihnen dann anschließend die Aufnahme des Webinars zugänglich machen.Diese Beiträge könnten Sie noch interessieren:

• Boss, ich will die Genehmigung!
• Kaizen, KVP, Kata: Einfach jeden Tag besser werden!
• Kanban Workshop in Köln
• Kaizen, KVP, Kata: Einfach jeden Tag besser werden!
• Zufriedene Mitarbeiter im Team

Ein Tag über kontinuierliche Verbesserung, am 13. Mai 2013, in Köln.

Der Workshop findet statt im STARTPLATZ, hoch über den Dächern der Stadt – ein wunderbarer Raum zum Treffen und gemeinsamen Arbeiten.

Kontinuierliche Verbesserung ist heute in mehr und mehr Organisationen wichtig; auch Entwicklungsunternehmen sehen sich mit zunehmend starker Konkurrenz konfrontiert. Nicht nur, dass der Wettbewerb ein besseres Produkt herausbringt oder einen besseren Service liefert – auch um gute Mitarbeiter und Fachkräfte gibt es inzwischen Wettbewerb. Das Internet hat zusätzlich dazu beigetragen, dass die Kunden perfekt informiert sind und den Wettbewerb auch aktiv ausleben.

Wie können Sie in der Softwareentwicklung jeden Tag besser werden? Und was heißt hier eigentlich besser?

• Mehr wirtschaftlichen Ertrag
• Bessere Arbeitsbedingungen für die Mitarbeiter
• Ein langlebiges, gut wartbares Produkt

Melden Sie sich auf der Workshopseite gleich an. Erfahren Sie, was Sie lernen und mit nach Hause nehmen können.Diese Beiträge könnten Sie noch interessieren:

• Kaizen, KVP, Kata: Einfach jeden Tag besser werden!
• Webinar: Kaizen, KVP, Kata – einfach jeden Tag besser werden
• Kontinuierlich besser werden
• Warum Manager zu Designern werden müssen [OOP 2013]
• OOP 2013: Warum Manager zu Designern werden müssen

Sie wollen meinen Content sicherlich weiterhin komfortabel lesen. Mit dem Google Reader stirbt ja auch nicht die RSS-Technologie, sondern lediglich eine Implementierung davon. Deshalb empfehle ich zwei Alternativen:

• Abonnieren Sie mein Blog per Email (siehe Button ganz rechts unten auf der Webseite)
• Stellen Sie rechtzeitig um von Google Reader auf einen anderen. Ich verwende Feedly oder Blogshelf. Feedly zum Beispiel kann Ihre Feeds aus Google Reader erkennen und sofort weiter abonnieren.

Die Internet-Gemeinde macht sich natürlich noch mehr Gedanken:

• Über 100.000 Personen (Stand: 16.3. 11:30 Uhr) haben eine Petition zur Rettung des Google Reader unterschrieben.
• Wie man seine Google-Reader-Daten retten kann, erklärt Google hier.
• t3n hat schon 2011 5 Alternativen zum Google Reader vorgestellt.
• MarketingLand hat ebenfalls 12 Alternativen zusammengestellt.
• Flipboard bringt sich gleich selbst als Alternative ins Spiel.
• Feedly verkündet, dass man bereits an einem Klon der Google-Reader-API gearbeitet habe, der Übergang am 1. Juli soll reibungslos laufen.
• Reeder erklärt auf Twitter: “Don’t worry, we won’t die with Google Reader”.

Wie auch immer – mein Blog und ich sind immer für Sie da!Diese Beiträge könnten Sie noch interessieren:

• Google weiß sowieso alles
• GAE: Datenbank ohne Aggregatfunktionen
• Annoying American Narrative
• Mächtig Du bist!
• Bulletins

Was kann Kanban?

Lean und Kanban scheinen die aktuellen Wunderwaffen im Arsenal des organisierten Wissensarbeiters zu sein. Sei es Projektmanagement, Produktentwicklung, IT-Betrieb oder evolutionäres Change-Management – „Lean“ und Kanban sind nicht mehr wegzudenken.

Die Limited WIP Society macht seit 2007 weltweit die Erkenntnisse aus Lean-Production und die Erfahrungen aus der agilen Projektarbeit in Form von „Software-Kanban“ für Wissensarbeiter effektiv nutzbar.

Mehr auf der Kölner Kanban Konferenz

Wenn Sie kennenlernen wollen, wie Sie Ihre Prozesse mit Kanban und Techniken aus dem Bereich „Lean“ optimieren können, kommen Sie bei uns vorbei. Die von der Kölner Limited WIP Society am 19.04.2013 veranstaltete halbtägige Konferenz, für die Sie sich hier anmelden können, ist ein nahe liegender Startpunkt für Sie.

Nehmen Sie direkt von der Konferenz erste Werkzeuge für die tägliche Arbeit mit. Mehr Informationen finden Sie hier im Konferenzprogramm.Diese Beiträge könnten Sie noch interessieren:

• Limited WIP Society Köln in Gründung
• Lean/Kanban 2011 Benelux in Antwerpen
• Feedback zum Produkterfolg-Bulletin
• Zweites Treffen der Limited WIP Society Cologne
• Kanban-Training im Februar 2010

Am 25. April ist wieder Zeit für die JAX in Mainz. Dort können Sie mich wieder bei einem Vortrag erwischen. Das Thema diesmal:

Softwarearchitekten, die für den Entwurf großer Systeme zuständig sind, haben in der Regel einen vollen Terminkalender und wissen oft nicht, wo ihnen der Kopf steht. Das muss nicht sein. Lernen Sie in diesem Vortrag, wie Sie durch mehrfaches Anwenden von Teile-und-Herrsche und mithilfe moderner Methoden wie Kanban die Architekturarbeit für große Systeme vereinfachen und sich Zeit nehmen können.

Bis dahin ist hoffentlich der Frühling schon etwas näher gekommen. Das Datum: 25.04.2013 | 14:00 – 15:00. Ich freue mich, Sie dort zu treffen!Diese Beiträge könnten Sie noch interessieren:

• JAX 2013: Softwarearchitektur entwerfen, ohne verrückt zu werden
• iSAQB Architekturtag
• Jax on Tour Architecture 2012
• Kalender
• Treffen Sie mich 2012

Nächsten Freitag können Sie mich live erleben. Fast. Genauer gesagt, bin ich live im Web erreichbar. In Zusammenarbeit mit AgileConnection veranstalten wir ein agiles MeetUp – es wird eine halbe Stunde dauern, und Sie können mit mir über Ihre Fragen zum Thema Management von agilen Teams sprechen. Gäste aus aller Welt werden dabei sein, deshalb haben wir Englisch als Sprache. Nach dem MeetUp geht es noch auf Twitter weiter.

Mehr Informationen und Anmeldung

Hier die Original-Einladung auf Englisch:

Diese Beiträge könnten Sie noch interessieren:

• Scrum-Jobs wachsen stark
• Gantt charts considered uncool
• Projektverträge ohne Tauziehen
• MBCalendar
• W-JAX 2010: Kanban kurz und bündig

Besonders interessant sind in diesem Zusammenhang die finanziellen Auswirkungen. Siemens hätte 16 Züge liefern sollen und hatte bereits als Kompensation für die 2011er-Verzögerung einen 17. Zug in Aussicht gestellt. Jetzt, nach den neuen Verzögerungen, hat Siemens für ein Quartal des Geschäftsjahres 2012/2013 noch einmal ca. 116 Millionen Euro zurückgestellt.

Was mag wohl dieser 17. ICE kosten? Und für wie viele Quartale muss Siemens noch Rückstellungen machen? Damit kratzt Siemens wahrscheinlich fast schon am Euro-Milliardenbereich.

Verzögerungskosten können in der Softwareentwicklung eine viel größere Rolle spielen als die Gehälter der Mitarbeiter. Es hat also Sinn, wenn man Entwicklung mit dem Ziel managt, schnelle und zuverlässige Lieferung von Wert zu erzielen, bei minimaler Verzögerung. Es hat keinen Sinn, wenn man Softwareentwicklung auf maximale Auslastung oder auf minimale Gehaltskosten (z.B. durch Outsourcing ins Ausland) hin managt. Die Optimierung, die man dadurch erzielt, wird sehr schnell durch Verzug in Folge von Kommunikations- und Qualitätsproblemen aufgefressen. Outsourcing in der Entwicklung ist damit praktisch keine Option mehr. Insourcing mit Lean ist die neue Option, die sich hoffentlich immer weiter herumspricht.Diese Beiträge könnten Sie noch interessieren:

• Lean und das Geld
• Neues eBook: Liefern, schon vor dem Schätzen!
• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Kanban-Training im Februar 2010
• Die Persona: Schlüssel zu besseren Anforderungen

Passen noch die traditionellen finanziellen Modelle zu agiler und lean Softwareentwicklung? Oder gibt es auch ein neues Verständnis über das Verhältnis zwischen Aufwand, Wert, Zeit und Geld? Wie kann es in Firmen umgesetzt werden?

In der Tat gibt es heute noch viele Verwechslungen zwischen Aufwand, Umfang, Wert, Zeit, Aktivität und Kosten:

• Oft wird dem Kunden der Aufwand in Rechnung gestellt (z.B. per Tagessatz pro Personentag). Dabei wird Aufwand mit Wert verwechselt. Der eigentliche Wert für den Kunden bleibt dabei unbekannt, er ist keinesfalls proportional zum Aufwand.
• Oft wird auch Zeit mit Fortschritt verwechselt. In solchen Projekten sagt man: “Es sind 9 von 12 geplanten Monaten um, also sind wir zu 75% fertig”. Auch das stimmt nicht, denn der geschaffene Wert hat nichts mit der Zeit zu tun.
• Als Nächstes kann man auch Scope mit Wert verwechseln. In solchen Projekten sagt man: “Wir haben 300 von 400 User Stories lauffähig, also sind wir zu 75% fertig”. Ebenfalls ein Irrtum, denn die Zahl der fertigen Stories sagt nichts über deren geschäftlichen Wert aus.
• Schließlich wird in vielen Organisationen die Stundenzahl pro Task, pro User Story oder pro Feature erfasst. Entwickler “buchen” dann ihre Stunden auf eine gewisse Kostenstelle oder auf ein Kundenprojekt. Das ist eine Verwechslung von Aktivität mit Kosten. Die Kosten der Produktentwicklung liegen nämlich zum großen Teil nicht in der Aktivität, sondern in der Verzögerung, die entsteht, wenn Arbeit begonnen wurde und nicht beendet werden kann. Verzögerungskosten können Aktivitätskosten um ein Vielfaches übersteigen (wie man gerade am Beispiel von Siemens und den neuen ICEs sieht, doch davon ein anderes Mal).

Es gibt ein besseres Verständnis aller dieser Größen. Im Zeitalter von Lean könnte man mit folgendem Modell in der Wissensarbeit, also z.B. in der Produktentwicklung, viel weiter kommen: (siehe obiges Bild – klicken Sie darauf, um es zu vergrößern)

1. Ein Kunde bezahlt Geld an eine Firma, die ihm Wert liefert. Der Wert ist ihm wichtiger als Geld, deshalb gibt er das Geld aus, um Wert zu bekommen.
2. Das Geld, das die Firma durch Verkauf von Wert generiert, nennt man Durchsatz.
3. Eine Firma “saugt” Ideen oder andere Formen von Wissen an und wandelt sie zunächst in Inventar um (z.B. in Requirements oder User Stories). Das nennt man Investition. Investition ist das Geld, das eine Firma ausgibt, um Dinge zu kaufen, die sie eines Tages verkaufen, also in Wert und dann in Durchsatz verwandeln möchte.
4. Um Inventar (z.B. User Stories) in andere Formen von Inventar (z.B. Dokumente, Code, Tests), dann in Wert und damit hoffentlich in Durchsatz umzuwandeln, gibt die Firma Geld aus. Dazu gehören z.B. die Löhne der Mitarbeiter. Das Geld, das die Firma verlässt, nennt man operative Ausgaben.
5. Wenn Inventar zu lange liegenbleibt, verliert es das Potenzial, zu Wert werden zu können. Beispiel: Ein Anforderungs-Dokument, dessen Erstellung 60.000 EUR Investition gekostet hat und nicht sofort in Code und Wert umgesetzt werden kann, könnte nach drei Monaten unverständlich geworden sein, weil die Menschen vergessen haben, was es bedeutet. Das wäre eine Abschreibung von ca. 1000 EUR pro Arbeitstag, welche man zu den operativen Ausgaben hinzuzählen muss.
6. Wenn man mit der Umwandlung von Inventar in Wert und Durchsatz zu lange wartet, kann es sein, dass sich das Zeitfenster für die Werterzeugung schon geschlossen hat und der Wert nicht mehr realisiert werden kann. Das sind Verzögerungskosten, die man ebenfalls abschreiben muss.

Wenn man dieses Denkmodell operationalisiert, müssten wir als Firma eigentlich zu folgendem Verhalten kommen:

• Wir “saugen” ein wenig Ideen an und bekommen durch wenig Investition das erste Inventar.
• Dieses Inventar wandeln wir möglichst schnell in Wert (lauffähiges Produkt) um, mit möglichst wenig Ausgaben. Die Ausgaben für Löhne betrachten wir als monatlich fix.
• Bei den operativen Ausgaben betrachten wir besonders die Abschreibung auf Inventar (Dokumente, Code, Tests, alles was noch nicht verkaufbar ist) und besonders auch Verzögerungskosten, indem wir Warteschlangen kappen und das Inventar begrenzen!
• Für den erzeugten Wert nehmen wir möglichst schnell Geld ein, also Durchsatz.
• Erst dann investieren wir wieder, um Ideen für neues Inventar anzusaugen.
• Wir versuchen ständig, den Return on Investment, also den Quotienten “(Durchsatz – Kosten) / Investitionen” zu maximieren.

In einer Firma, die so arbeitet, ergeben sich erstaunliche Konsequenzen. Ich schildere sie hier einmal möglichst provokativ und pointiert, um den Punkt klarzumachen:

• Man braucht man keine Stunden mehr zu buchen und dem Kunden in Rechnung zu stellen. Kosten für Stunden sind fix und brauchen nicht einzeln aufgeschrieben zu werden. Man lässt den Kunden für geschaffenen Wert bezahlen, den man regelmäßig in handlichen Portionen ausliefert, so dass der Kunde ihn gut konsumieren kann.
• Man braucht nicht nach Indien, Russland oder China outzusourcen, denn die Ausgaben für Löhne sind nur ein Teil der operativen Ausgaben. Verzögerungskosten und Qualitätsverluste durch zu lange Zykluszeiten verursachen weit mehr Ausgaben als die Löhne.
• Man braucht keine Zeitpläne mehr zu verfolgen, weil Schlagzahl, Work in progress und Zykluszeit (zusammen mit einer Abbildungsfunktion nach EUR) viel aussagekräftiger sind. Flow ist viel leichter zu verfolgen als geplante Zeit.
• Man beachtet Termine nur, wenn man Verzögerungskosten vermeiden will (Beispiel: Frische Videospiele verlieren nach Weihnachten den größten Teil des Wertes). Man verfolgt keine Zeitpläne mehr, sondern priorisiert nach möglichem Durchsatz oder Durchsatzausfall.
• Bei Überlastung der Firma durch zu hohe Nachfrage versucht man nicht mit Gewalt, versprochene Zeitpläne einzuhalten, sondern mit weniger Aufwand ein Äquivalent zum geplanten Wert zu liefern. Schlägt das auf Dauer(!) reproduzierbar fehl, erhöht man die Preise, um die Nachfrage und damit die Last auf der Firma zu reduzieren, ohne an Durchsatz zu verlieren. Man bleibt dadurch schnell und lieferfähig und wird zu einer Premium-Firma mit Premium-Kunden. (Achtung: Geändertes Marketing und geänderte Vertriebsmechanismen erforderlich!)
• Den Mitarbeitern geht es richtig gut, weil sie Dinge wirklich mit hoher Qualität fertigstellen und ihre Schlagzahl auf Dauer halten können. Die Mitarbeiter rufen begeistert ihre Bekannten an und laden sie ein, ebenfalls in dieser Firma zu arbeiten.

Sollten Sie solch eine Firma sein oder werden wollen, weil Sie das geschilderte Denkmodell teilen, rufen Sie mich an. Ich coache Sie, damit Sie das wahr machen können und freue mich heute schon darauf!Diese Beiträge könnten Sie noch interessieren:

• Wenn der VerZug kommt
• Fünf Mythen der heutigen Projektkultur
• Stresskultur in agilen Teams
• Budgetierung ist schädlich
• Mehr Geld mit der Softwareentwicklung verdienen

Also, liebe Leser, nehmen Sie die Tastatur in die Hand und schreiben Sie in das Kommentarfeld dieses Blogbeitrages Ihre Fragen hinein! Oder schicken Sie sie mir per Email, per XING oder per Twitter, ganz wie Sie wollen.

Ich behandle die Themen dann im nächsten Newsletter und bin gespannt, was Sie sagen!

Redaktionsschluss zur Abgabe der Fragen: Montag, der 25. Februar, 17 Uhr! Danach werde ich die Themen sortieren und aufbereiten. Also: Seien Sie schnell und schreiben die Fragen in das Kommentarfeld zu diesem Artikel.Diese Beiträge könnten Sie noch interessieren:

• Fünf Argumente, warum Sie fix entwickeln sollten
• Boss, ich will die Genehmigung!
• Vier Fragen für das Neue Jahr
• Schätzen, verschätzen, nachverhandeln
• Online AgileConnection MeetUp

1. Wenn man etwas öfter tut, beherrscht man es besser. Kürzere Zyklen sorgen dafür, dass man dasselbe öfters tut, also besser übt. Jeder Musiker weiß, wie wichtig das ist. Als Entwickler können wir uns das bei den Musikern abgucken.
2. Wenn man kleinere Dinge tut, steigt die Qualität. Ein kürzerer Zyklus sorgt dafür, dass Sie sich besser daran erinnern können, was Sie getan haben, sobald Sie mit einem Fehler konfrontiert werden. Wenn die Ursache des Fehlers Monate zurückliegt, dauert es lange, bis Sie die Ursache gefunden haben. Ist es nur 1 Stunde her, wissen Sie in der Regel noch genau, was Sie zuletzt geändert haben.
3. Kürzere Zeit macht nutzlose Dinge (waste) offenbar. Wenn ich etwas Kleines umsetzen will, fallen mir unproduktive Dinge viel eher auf. Wenn die Umsetzung nur 2 Tage dauert, frage ich mich: Muss ich dafür extra ein Planungsmeeting, und ein Reviewmeeting haben? Kann sein – aber wenn, dann bewusst!
4. Kürzere Zeit steigert die Motivation. Wenn Sie wissen, Sie können etwas morgen fertig haben, weil es so klein ist, sind Sie motivierter als wenn Sie wissen, dass eine Aufgabe so schwierig ist, dass sie drei Wochen braucht. Wenn Sie wissen, dass Ihre Kollegen etwas schnell fertigstellen, haben Sie mehr Lust, sie darum zu bitten.
5. Die kürzere Zeit sorgt für mehr Fokus. Wenn ich weiß, dass wir im Team durchschnittlich nur 2-3 Tage für etwas brauchen wollen, dann versuche ich auch, nicht zu viele Dinge auf einmal (work in progress) zu eröffnen, denn sonst verzettele ich mich und schaffe die 2-3 Tage nicht.

Welche Gründe gibt es noch, z.B. aus der Erfahrung in Ihren Teams? Schreiben Sie sie in das Kommentarfeld ganz unten – wir können alle daraus lernen! Für die 3 besten Gründe bekommen die Einsender von mir einen Gutschein für eines meiner eBooks!Diese Beiträge könnten Sie noch interessieren:

• Fünf Mythen der heutigen Projektkultur
• Die Zukunft als Droge
• Denksport für Entwicklungsmanager
• Lean und das Geld
• Training: Flow in der Produktentwicklung

Gestern stolperte ich nun über eine Website, die heißt projectmanagement.com. Auf der About-Seite dieser Website fand ich folgendes:

This is why we built ProjectManagement.com. Our mission is simple: To make project managers more successful. … You might remember us as gantthead, which launched in 2000. At that time, every project worth managing was run using a gantt chart. However, times changed and many project leaders were more focused on their KanBan Boards than on a linear schedule.

Oh Du liebes Gantt-Chart, Matthias Bohlen hat also Deinen Tod mindestens sieben Jahre zu früh vorausgesagt. Entschuldige bitte herzlich!

Was er vor sieben Jahren noch nicht sagte, sage ich Ihnen heute:

1. Aus Gantt-Charts lernen Sie nichts über die Fähigkeiten Ihres Teams.
2. Sie lernen auch nichts über die Probleme, die in Ihrem Prozess stecken.
3. Sie lernen auch nichts darüber, wie sich die Ankunftsrate neuer Anforderungen zur Abarbeitungsrate alter Anforderungen verhält und ob Ihr Projekt deshalb im Gleichgewicht steht.

All das, was Sie heute wie selbstverständlich aus einem Cumulative Flow Diagram entnehmen, haben Sie in einem Gantt Chart nicht. Möge dieser Diagrammtyp ruhen in Frieden!Diese Beiträge könnten Sie noch interessieren:

• Gantt charts considered uncool
• OOP 2010: Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?)
• Mehr Erfolg in der Produktentwicklung (Strategie)
• Honorarfreies Strategiegespräch
• Empfehlungen

Machen Sie es anders! Hier sind acht Tipps, mit denen Sie in den Fluss kommen und mehr lernen als andere Projektorganisationen:

1. Betrachten Sie das Ganze nicht auf der Zeitlinie, sondern als einen strömenden Fluss von Features.
2. Messen Sie die Geschwindigkeit dieses Flusses (Durchsatz) und deren Schwankung.
3. Messen Sie, wie lange es dauert bis ein einzelnes Feature fertig entwickelt ist (Zykluszeit).
4. Begrenzen Sie die Breite des Flusses auf das, was Ihr Team gleichzeitig leisten kann (work in progress).
5. Sorgen Sie dafür, dass die im Fluss schwimmenden Gegenstände (Features) geringes Gewicht haben (small batch size).
6. Wenn der Fluss gleichmäßig zu fließen beginnt, können Sie anfangen, den Bezug zur Zeit herzustellen und erste Termine vorauszusagen.
7. Wenn Ihr Projekt vorbei ist, lassen Sie das Team beieinander und machen Sie mit ihnen das nächste Projekt. Benutzen Sie die gemessenen Daten als Planungsgrundlage.
8. Wenn Sie genügend Projekte gemacht haben, vergessen Sie den Begriff “Projekt” und stellen Sie auf stabile Wertströme um.

Wenn Sie das so machen, steigern Sie den Erfolg und erzeugen eine angenehme Arbeitsumgebung. Ihre Leute werden Freunde und Bekannte einladen, ebenfalls dort zu arbeiten, und das Wort Fachkräftemangel wird in Ihrer Organisation unbekannt sein.

Holen Sie sich das für diesen Wettbewerbsvorteil nötige Wissen dafür ins Haus, zum Beispiel mit der inHouse-Version meines Trainings Flow in der Produktentwicklung.Diese Beiträge könnten Sie noch interessieren:

• Denksport für Entwicklungsmanager
• Boss, ich will die Genehmigung!
• Halt die Schlange kurz!
• Die Persona: Schlüssel zu besseren Anforderungen
• Angst vor Work in Progress?

Lurens – beföhr isch wat Nüüs noh Indien geb, probeersch dat all mal kuchz doosch, sons jibt dat wedder nohr dat nächse Durjenando!

(Für den Fall, dass Sie des Ripuarischen nicht mächtig sein sollten, das im Köln/Bonner Raum gesprochen wird, habe ich am Ende des Artikels die Übersetzung ins Schriftdeutsche eingefügt.)

Sie griff also beherzt in die Tasten und schrieb ein Stück Code, das von den indischen Kollegen nur noch ausgefüllt bzw. nachprogrammiert werden musste – die einzige Chance, um unter diesen Bedingungen lauffähigen, trotz aller Kommunikationsprobleme halbwegs geordneten Code zu bekommen. Danach verfasste Sie das laut Vorgehensmodell erforderliche Spezifikations- und Auftragsdokument, hängte einen Verweis auf den Code an und schickte alles an den Haus- und Hof-Dienstleister, der es nach Indien weiterleiten würde.

Welch eine Verschwendung, und gleichzeitig welch eine Weisheit dieser Person! Das Unternehmen überlebt weiterhin – trotz Outsourcing. Es überlebt eben, weil es weise Mitarbeiter hat, die das Richtige im Alltag tun, selbst wenn die Richtlinien, nach denen gearbeitet wird, stark optimierungsbedürftig sind.

Wäre es nicht eine gute Idee, auch weiter oben in der Hierarchie weise zu sein und solche Richtlinien wieder abzuschaffen?

Ach ja: Die Übersetzung des obigen Satzes lautet:
Hören Sie mal – bevor ich etwas Neues nach Indien gebe, probier ich das alles mal kurz durch, sonst gibt das wieder nur das nächste Durcheinander!Diese Beiträge könnten Sie noch interessieren:

• Präzise Ausdrucksweise
• Selbstorganisation in kleinen Scheiben
• Zurück von der JAX 2012
• Premierminister, werde agil!
• Mit TDD schreibt man Spezifikationen

Manchmal höre ich dann von Teilnehmern “schade, leider konnte ich gerade nicht kommen, weil wir ein neues Release herausgeben” oder “wir müssen Reisekosten sparen” oder sonstige Hindernisse, die Leute davon abhalten, in eine persönliche Schulung zu kommen.

Deshalb frage ich Sie heute, ob Sie das Flow-Training auch online besuchen würden. Wir würden uns gemeinsam bei einem Videokonferenzprovider anmelden, uns gegenseitig sehen/hören und über Flow sprechen und diskutieren. Vielleicht erproben wir das ein oder andere Flow-Konzept auch als online gemeinsam erstellte Grafik oder ähnliche interaktive Möglichkeiten. Das ist natürlich nicht dasselbe als wenn man sich live begegnet, doch eventuell gelingt uns ja etwas ganz Anderes dadurch! Wir probieren das zunächst in einem kleinen Kreis aus, max. 6 Leitungen auf einmal – pro Leitung können Sie auch mit mehreren Personen teilnehmen, wenn Sie wollen.

Hier einige kurze Fragen an Sie, mit denen ich feststellen möchte, wie groß das Interesse und die Präferenzen für ein solches Online-Seminar sind:

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.Diese Beiträge könnten Sie noch interessieren:

• Zurück von der JAX 2012
• Flow in Lean, Flow im Team
• Flow in Lean, Flow im Team
• OOP 2012: Flow in Lean, Flow im Team
• Honorarfreies Strategiegespräch

• Feedback zum Produkterfolg-Bulletin
• Video von der JAX 2010
• Struktur in die Form füllen
• Vortrag: Quantitatives Management
• Flow in der Produktentwicklung

Jetzt die Herausforderung für Sie: Es kommt ein neuer Kunde, der für die neue Firma sehr wichtig ist. Der Vertrieb möchte ihm das Produkt X verkaufen, der Kunde braucht aber noch eine Anpassung Y am Produkt X. Die Anpassung ist in etwa so groß wie das, was die beiden Teams bisher im Durchschnitt unter “einem Feature” verstehen. Der Vertrieb bittet Sie, Y umsetzen zu lassen.

Wie reagieren Sie? Sie möchten es nicht gleich verbocken und Y zuverlässig liefern, um den Kunden zu bekommen. Andererseits wissen Sie, dass alle anderen Kunden auch das Recht haben, bedient zu werden – deshalb möchten Sie existierende Arbeit nicht unterbrechen. Sie haben sich aber überlegt, das neue Feature wenigstens höher zu priorisieren als alles, was die beiden Teams sonst noch vor sich herschieben.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.Diese Beiträge könnten Sie noch interessieren:

• Relative Feature-Bewertung
• Alles eine Frage der Blickrichtung
• Drei Fragen zu Ihrer Produktstrategie
• Halt die Schlange kurz!
• Schlanke Zeiten [OOP 2010]

Wenn Sie schon zu viel WIP haben und zwischen vielen Aufgaben hin- und herwechseln müssen, dann ist die Timebox Ihr Freundin. Nehmen Sie sich ganz klar eine bestimmte Zeit für bestimmte Aufgabenpäckchen und wechseln Sie erst dann wieder zu einer anderen Art von Aufgabenpäckchen. Berücksichtigen Sie dabei Ihren Aufmerksamkeitsrhythmus: Wann sind Sie wach, dann ist es Zeit für die kreativen, neuartigen Dinge! Wann sind Sie müde, dann ist es Zeit für die langweiligen Dinge, die ohne viel Gehirnschmalz oder Emotion gemacht werden können. Lesen Sie noch einmal die Pomodoro-Technik nach und setzen sich dann an Ihren Schreibtisch. Das habe ich auch gerade getan, und es geht mir gut, trotz viel WIP.Diese Beiträge könnten Sie noch interessieren:

• Fünf Argumente, warum Sie fix entwickeln sollten
• Projektmanagement im Fluss
• Verhüten oder bekämpfen?
• Wann sollte man nicht agil arbeiten? [OOP 2010]
• Boss, ich will die Genehmigung!

23.1.: Management traditionell: Wie viel Arbeit, wie viele Leute, wie verteile ich das, und bis wann? Das klappt in der Produktentwicklung heute so nicht mehr. Manager sind Teil eines komplexen, adaptiven Systems aus Teams, Geld, Maschinen, Ideen, existierender Software, Kunden und Mitbewerbern, in dem sich alles gegenseitig beeinflusst. Wir müssen uns als Manager neu erfinden und dieses System aktiv mit entwerfen, damit es Kunden begeistert, Geld verdient und Menschen weiterbringt. Der Vortrag gibt Ihnen die Design-Anleitung dafür in die Hand.

Zielpublikum: Manager, Teammitglieder
Voraussetzungen: Interesse an der Weiterentwicklung des eigenen Unternehmens
Schwierigkeitsgrad: Fortgeschritten

Der Vortrag basiert auf dem Denkmodell der komplexen, adaptiven Systeme und macht diese auf der Grundlage praktischer Erfahrung für die heutige Managementpraxis anwendbar.

Gliederung:

• Motivationsbeispiel: Eine Firma und ihr Produkt sind in die Jahre gekommen. Der Vertrieb verkauft was er nur kann, die Produktmanager sind zu sehr in Presales gebunden, die Entwickler tun nach bestem Wissen was sie können, um Fortschritt zu zeigen, teilweise auf Kosten der Qualität. Die Qualitätssicherung steht wegen enger Termine unter Druck, beim Support steht wegen zu vieler Fehler das Telefon nicht mehr still – die gesamte Organisation kommt trotz Vollbeschäftigung zu einem knirschenden Halt.
• Grundlagen komplexer adaptiver Systeme: Eine Organisation, gesehen als System aus unabhängigen Agenten, die Signale miteinander austauschen, dabei eigenen Regeln folgen und die Regeln auf Basis von Feedback selbst modifizieren, verwerfen und neu erfinden. Agenten sind z.B. Mitarbeiter, Kunden, Ideen, die vorhandene Software, Mitbewerber und vieles mehr.
• Die zweigeteilte Rolle eines Managers: Er ist einerseits selbst ein Agent in diesem System. Andererseits entwirft er das System mit, indem er neue Agenten hinzufügt (z.B. Ideen gibt, Mitarbeiter einstellt, usw.), diesen Agenten Regeln, Signale und Nahrung mitgibt und sie im Lebenszyklus betreut, d.h. selbst wieder mit ihnen interagiert. Er wird gleichzeitig zu einem Teilnehmer und zu einem Architekten des Systems.
• Wertbasiertes Management: Wie Manager im System Feedbackschleifen verankern, die selbstregelnd wirken, so dass das System sowohl inhaltlich (vom Produkt und von den Menschen her) als auch betriebswirtschaftlich (vom “return on investment” her) in eine wertvolle Richtung regelt. Dabei überfordert es sich selbst nicht, so dass das System jahrzehntelang operieren und sich selbst anpassen kann. Hier ist der Wertbegriff wichtig. Dieser Abschnitt des Vortrags zeigt, was Wert ist, wie er entsteht und langfristig gehalten werden kann. Die oben erwähnten Feedbackschleifen bildet man im Entwurf wieder auf Signale und Regeln ab, die man den Agenten zuordnet oder die die Agenten sich selbst zuordnen (schließlich hat eine Firma schlaue Leute, die das selbst tun können).
• Wohin das führt: Besserer Service für die Kunden, mehr Ergebnis unter dem Strich, bessere Mitarbeiter-Moral (in Zeiten knapper Fachkräfte eine wichtige Bedingung). In diesem Teil des Vortrags wird das Motivationsbeispiel aus der Einleitung noch einmal aufgenommen und gezeigt, wie die kritische Situation durch geeigneten Systementwurf aufgelöst werden kann.
• Aufruf zur Aktion: Manager sollten sich aktiv mit Systemen beschäftigen und ihre eigene Organisation als lebendiges System verstehen, tiefgreifend verstehen. Danach sollten sie sich das Management mit ihren Mitarbeitern teilen und gemeinsam an der Wertsteigerung arbeiten.

Sie lernen:

Teilnehmer verstehen, warum traditionelles Management nicht mehr anwendbar ist, wie sie die eigene Organisation als System besser verstehen können und wie sie gemeinsam am Entwurf einer modernen, erfolgreichen und flexiblen Organisation arbeiten können.Diese Beiträge könnten Sie noch interessieren:

• OOP 2013: Warum Manager zu Designern werden müssen
• Flow in der Produktentwicklung
• Trainings in Kanban
• Slides von der WJAX 2012: Agile Teams im Gleichgewicht
• Softwarearchitektur im Team entwerfen

Eigentlich ist es doch ganz einfach: Woran erkennen Sie eine erfolgreiche Firma? Sie hat…

• begeisterte Kunden,
• einen hohen Ertrag und…
• zufriedene, begeisterte Mitarbeiter.

Eine Firma, die der bisher üblichen Projektkultur huldigt, verschiebt alle diese Dinge gedanklich in die Zukunft und wartet ab, bis der Projekterfolg die obigen drei Kriterien wahrmacht. Kann man das nicht besser machen?

Projektkultur war gestern

In der Projektkultur reisen Sie einem vordefinierten Ziel hinterher (oder einem beweglichen Ziel und passen unterwegs Ihre Richtung an). Was wäre, wenn es kein solch fernes Ziel mehr gäbe? Dann würde der ständige Soll-/Ist-Vergleich entfallen und damit auch der Stress. Unmöglich? Sie meinen, die Tür zum Chaos würde sich dadurch öffnen? Spielen wir das einmal durch.

Die Business-Leute erarbeiten einen ebensolchen “Case”. Sie rechnen mit einem bestimmten Umsatz, der erreicht wird, wenn das Projekt abgeschlossen wird. Sie merken allerdings unterwegs: “Hmm, gestern dachten wir noch, der Business Case würde so und so aussehen. Heute merken wir, dass ein anderes oder zusätzliches Geschäft am Wegesrand wartet. Könnten wir das nicht mitnehmen?”

Was sich da auftut, ist eine Option. Sie können diese realisieren oder auch nicht. Wenn Sie dem Fernziel folgen, würde das Realisieren dieser Option Sie im Hinblick auf das Fernziel langsamer machen, also nehmen Sie die Gelegenheit nicht mit, sondern arbeiten weiter für das Fernziel. Bei einem Projekt nennt man das “einen abgelehnten Change Request”. Damit schließen Sie die Option. Sie läuft meist kurz danach ab und ist nicht mehr realisierbar. Auf dem Weg tauchen aber nach und nach immer wieder solche Optionen auf. Diese rufen vom Wegesrand aus “nimm mich mit, nimm mich mit” und laden Sie dadurch ein, langsamer zu gehen und zusätzliches Geschäft zu machen.

Optionenkultur ist heute

Was wäre nun, wenn Sie anstatt ein Projektziel zu verfolgen immer wieder nach der nächsten Option Ausschau halten, die Ihrem Kunden und damit Ihnen selbst bereits wieder Geld einbringt? Das Business verfolgt dabei die Optionen im Markt und stellt an das Entwicklungsteam entsprechende Nachfrage nach Features, um diese Optionen wahrzumachen. Das Team hebt die Nachfrage in einer Warteschlange (Backlog) auf. Der Product Owner managt die Warteschlange so, dass die wertvollsten Optionen gezogen werden und der Rest dabei möglichst lange offen (realisierbar) bleibt und sich eben nicht schließt.

Das Team stellt seine Fähigkeit in den Dienst des Business und balanciert Nachfrage gegen Fähigkeit aus. Die Teammitglieder ziehen immer dann eine Option (ein Stückchen Nachfrage) in die Realisierung, wenn wieder etwas Fähigkeit (Entwicklungskapazität) frei ist. Die Entwickler achten dabei darauf, möglichst wenige der Optionen gleichzeitig zu ziehen, um einerseits den Überblick zu behalten und andererseits dem Business zu erlauben, den Rest der Warteschlange nach Gutdünken umzusortieren, Optionen hinzuzufügen oder herauszunehmen – ganz wie es der Markt (also das am Wegesrand liegende Geschäft) verlangt. Dadurch, dass Optionen sehr spät gezogen werden, entsteht das Commitment auch sehr spät. Dadurch geht Ihre Entwicklungsorganisation gleichzeitig möglichst wenig Risiko ein – ein aktiver Beitrag zum Risikomanagement.

Das hält dem Chaos die Tür vor der Nase zu. Es wird ganz diszipliniert eine Option nach der anderen realisiert und das Geld dafür einkassiert. Ein übergeordnetes Ziel ist lediglich für die Verständlichkeit, Gerichtetheit und Konsistenz dieses Wertstromes erforderlich. Sie brauchen jedoch keine detaillierte Liste von zu realisierenden Anforderungen mehr, die entdecken Sie stattdessen unterwegs.

Das Business-Motorrad

Die bisherige Projektkultur ist vergleichbar mit einem Supertanker, der mit Rohöl beladen langsam manövriert, um an seinem Ziel eine große Menge Wert zu schaffen, indem er eine Raffinerie beliefert. Ein Team, das in der neuen Optionenkultur arbeitet, gleicht eher einem schnellen Motorrad, das zwar nicht viel Last tragen kann, aber mit dem das Business ein interessantes Ziel im Markt nach dem anderen anfährt und dort Wert mitnimmt.

Flow-Kultur tut ein Übriges

Wenn Ihr Product Owner schlau ist, balanciert er mit dem Team zusammen die Nachfrage gegen die Fähigkeit aus. Er erlaubt dem Team, nur so viele Optionen in die Realisierung zu ziehen wie sie Kapazität haben. Das Team misst laufend seine Fähigkeit, z.B. in realisierten Features pro Tag oder pro Monat, und veröffentlicht diese Zahl. Das Business kennt diese Kapazität und hat explizit den Auftrag, sie mit möglichst kleinteiliger Nachfrage auszunutzen, um flexibel zu bleiben und das Team nicht zu überlasten. Dadurch gerät das ganze System (Kunde, Business, P.O., Team) in einen ausbalancierten Flow-Zustand, den Sie ohne Probleme über lange Zeit aufrechterhalten können.

Der Kunde bekommt ständig lauffähige Features, die Qualität ist sehr hoch, weil die Entwickler nicht mehr einem Termin nachjagen, deshalb keine Kompromisse mehr zu machen brauchen, sondern jede Option gescheit realisieren können (natürlich trotzdem kosten-angepasst, nicht vergoldet, das ist klar). Die Mitarbeiter im Team sind sehr zufrieden, denn sie leben im Gleichgewicht: Es entsteht weder Überlastung noch Langeweile, sondern eine gleichmäßig hohe Herausforderung ihrer Fähigkeiten.

Verzicht auf Ballast

Der Auftrag lautet nicht mehr, eines Tages an einem bestimmten Punkt angekommen zu sein. Deshalb brauchen Sie auch keinen Soll-/Ist-Vergleich mehr, keinen langfristigen Plan und keine Kostenverfolgung. Die Kosten sind ein gleichmäßiger Strom, da die Zahl der Leute im Team konstant bleibt. Es gibt keinen langfristigen Plan mehr, der Ihnen trügerische Sicherheit vorgaukelt. Ihre Aufmerksamkeit kann sich damit auf die folgenden Fragen verlagern:

• Wo ist die nächste Business-Gelegenheit?
• Welche Option liegt dafür am Wegesrand?
• Welchen Wert kann diese Option generieren?
• Wenn wir uns auf diese Option committen, welche anderen Optionen werden dadurch geschlossen?
• Wie lange bleibt welche Option offen? Bis zu welchem Ereignis oder welcher Entscheidung?
• Gibt es Mittel, sie noch länger offen zu halten? Was kosten diese Mittel?
• Wie viele Optionen pro Zeiteinheit realisiert unser Team?
• Welche Gelegenheiten werden in solch einem Zeitraum am Wegesrand auftauchen? Wie müssen wir sie sortieren, so dass das Team sie mit wenig Energieaufwand wahrmachen kann?
• Falls wir von den Kunden zu viel Nachfrage auf einmal bekommen – wie stark können wir den Preis der Optionen anheben, so dass sich die Nachfrage auf ein sinnvolles Maß reduziert?

Das neue Management

Als Manager sollten Sie ein System gestalten, in dem diese Kultur von Optionen und Flow möglich werden kann. Informieren Sie alle Mitarbeiter darüber, wie das funktioniert und was die neuen Ziele sind. Der schlaue Product Owner mit Systembewusstsein erlaubt dem  Team, sich in Balance zwischen Nachfrage und Fähigkeit zu bringen. Er verdient für seine Firma Geld ohne Ende, indem er Optionen verteuert, Nachfrage beschränkt, durch Flow die Lieferzeiten verkürzt und die Firma dadurch zu einer Premiumfirma macht. Der Wettbewerb wird nur noch staunen, die Kunden werden es lieben. Die Mitarbeiter werden ihre Freunde ermutigen, ebenfalls in dieser Premium-Firma zu arbeiten.

Haben Sie den Mut zur Premium-Firma?

Haben Sie Mut, sich zu einer Premium-Firma zu entwickeln? Sicher, am Anfang erfordert das Energie, man trennt sich schließlich nicht so gern von alten Denkgewohnheiten. Doch die Vorteile sind so eklatant, dass sich der Einsatz lohnt.

Vielleicht denken Sie: Der Bohlen malt alles rosarot! Ob das bei unserer Firma auch funktioniert? Rufen Sie mich einfach an – ich kann Ihnen helfen, die konkreten Schritte zu lernen, die auf dem Weg zu einer Kultur von Optionen und Flow notwendig sind. Nehmen Sie Fahrt auf – mit Ihrem Business-Motorrad!Diese Beiträge könnten Sie noch interessieren:

• Wenn der VerZug kommt
• Selbstorganisation in kleinen Scheiben
• Softwarearchitektur im Team entwerfen
• Lean und das Geld
• Coaching

Beim Optimieren der Performance einer Website warf ich einen Blick auf die Felder im HTTP-Header, die von einem fremden Webserver an meinen Browser gesendet wurden. Neben den üblichen Verdächtigen fand ich ein Feld mit dem Namen “If-you-are-reading-this”. Der Inhalt dieses Feldes war:

then you should come work with our engineering team! Please send your resume and a brief note to jobs@abcdef.com.

Die Entwickler eines auf der Website verwendeten Frameworks hatten diese Nachricht so geschickt versteckt, dass einer, der sie findet, ein potenzieller Kandidat für sie ist und aufgefordert wrd, sich per Email zu melden. Kreativ, oder? Schafft das Ihre Personalabteilung auch?Diese Beiträge könnten Sie noch interessieren:

• Scrum-Jobs wachsen stark
• Personal Kanban: a matter of attitude
• Java resource bundle Editor für Eclipse
• Kaizen, KVP, Kata: Einfach jeden Tag besser werden!
• OOP 2012: Flow in Lean, Flow im Team

Mythos Nr. 1: Das Backlog ist abzuarbeiten

Neulich sah ich eine schöne deutsche Übersetzung für das englische Wort Backlog: “Rückstand”. Das klingt doch gleich so als wäre das Team mit irgendetwas im Rückstand. Schon wieder ein Stressfaktor, weil man einen Soll-Ist-Vergleich durchführt. In Wirklichkeit ist es anders: Die Elemente im Backlog verlieren an Wert, je älter sie sind, weil der Markt sich inzwischen weiter entwickelt, während die Backlog-Elemente auf ihre Umsetzung warten. Kunde oder Projektmanager sollten also nicht auf Abarbeitung des Backlogs bestehen. Den Inhalt des Backlogs betrachtet man besser als Optionen, die man ziehen kann oder auch nicht!

Mythos Nr. 2: Je eher wir anfangen, desto eher sind wir fertig!

Durchschnittlich gilt das Gesetz von Little: Die Zykluszeit ist gleich der Menge der Backlog-Elemente, die noch in Arbeit sind (work in progress), geteilt durch den Durchsatz in Backlog-Elementen pro Zeiteinheit. Beispiel: Ein Team hat 10 Elemente gleichzeitig in Arbeit, schafft 4 pro Woche, dann dauert jedes neue Element 2,5 Wochen, bis es einmal durch den Entwicklungsprozess gegangen ist. Alles durchschnittlich natürlich, nicht für jedes Element gleich. Das bedeutet: Je eher wir anfangen, desto mehr work in progress, desto länger dauert alles!

Mythos Nr. 3: Aktivität verursacht Kosten

In vielen Firmen ist es üblich, die Arbeitszeit der Mitarbeiter zu erfassen, die sie für die Realisierung einer bestimmten Anforderung benötigt haben.Die Annahme dahinter: je mehr jemand an einer Anforderung arbeitet, desto mehr kostet sie. Diese Kosten muss man den Kunden in Rechnung stellen. Auch das ist letztlich ein Mythos, denn:

Die Zeit, jemand an etwas arbeitet, besteht aus reiner Bearbeitungszeit und aus Wartezeit. Betrachten Sie ein Team das zu 90 % ausgelastet ist. Wenn Sie diesem Team eine neue Aufgabe geben wollen, wird es in 10 % aller Fälle sagen: “ja, machen wir sofort”, und in 90 % aller Fälle wird es sagen: “diese Arbeit muss warten, denn wir sind noch beschäftigt”. Das bedeutet: Wenn das Team zu 90 % ausgelastet ist, dann verbringt die Arbeit des Teams 90 % der Zeit in der Warteschlange, und nur 10 % der Zeit in Bearbeitung. Die wahren Kosten der Arbeit liegen also nicht in der Aktivität, sondern der Wartezeit. Daraus folgt eigentlich sofort: Zeiterfassung ist überflüssig.

Mythos Nr. 4: Hohe Produktivität bringt’s!

Produktivität (also zum Beispiel Durchsatz in Features pro Zeiteinheit) ist nur eine Proxy-Variable. Proxy-Variable deshalb, weil sie kein Wert an sich ist, sondern weil wichtig ist, wie diese sich auf das finanzielle Ergebnis der Firma auswirkt. Und Tatsache ist: auf das finanzielle Ergebnis der Firma wirken viel mehr Variablen als nur die Produktivität. Dazu später mehr.

Mythos Nr. 5: Hohe Auslastung ist gut!

Mitglieder von Softwareentwicklungsteams (Entwickler, Architekten, Projektleiter, Anforderung sanalysten, Tester) gehören zu den gut bezahlten Leuten. Daher ist die Annahme, dass man diese Leute nicht ohne Arbeit herum sitzen lassen darf. Wenn ich Projektleiter frage, wie hoch ausgelastet ihre Teams sind, so kommen antworten wie 80 %, 90 %, 99 %. Je mehr, desto besser für das finanzielle Ergebnis der Firma, oder? Noch so ein Mythos!

Definieren wir zunächst einmal Auslastung. Auslastung ist Ankunftsrate neuer Arbeit geteilt durch Abarbeitungsrate der bestehenden Arbeit. Wenn jemand durchschnittlich zehn Sachen pro Woche schafft, und sie ihm acht Sachen pro Woche zu tun geben, dann beträgt seine Auslastung 80 %. Es gibt nun einen Zusammenhang zwischen der Länge der Warteschlange, und der Auslastung desjenigen, der arbeitet. Der Zusammenhang ist exponentiell: Je höher jemand ausgelastet ist, desto überproportional länger wird die Warteschlange an unfertiger Arbeit, die sich vor ihm bildet. Hier eine Tabelle mit typischen Werten für Auslastung und Warteschlangenlänge:

Sie sehen, hohe Auslastung ist gar nicht gut! Bei mehr als 80 % Auslastung bildet sich bereits eine Warteschlange von mehr als drei Dingen, die nicht sofort getan werden können. Bei 90 % liegen schon acht ungetane Dinge auf dem Schreibtisch desjenigen, der so hoch ausgelastet ist. Bei 95 % sind es 18, bei 97 % schon mehr als 31 Elemente! Gegen 100 % Auslastung wird die Warteschlange unendlich lang. Eine empfindliche Warteschlange bei hoher Auslastung ist deshalb so kritisch, weil Sie bei jedem Schnupfen eines Ihrer Mitarbeiter sofort in die Unberechenbarkeit abdriften und Zusagen Ihren Kunden gegenüber nicht mehr einhalten können. Liegen Sie hingegen bei 75-80% Auslastung, ist die Warteschlange bei weitem nicht so empfindlich, und es ist Platz für Unvorhergesehenes (z.B. eben den Schnupfen).

Machen Sie’s besser!

In der nächsten Folge dieser Reihe schreibe ich darüber, wie Sie sich von den Mythen trennen und es besser machen können, in Richtung einer erfolgreichen Firma, die begeisterte Kunden hat, einen hohen Ertrag und zufriedene, begeisterte Mitarbeiter. Und Sie erfahren auch, was ein “Business-Motorrad” ist.Diese Beiträge könnten Sie noch interessieren:

• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Stresskultur in agilen Teams
• Wohin mit den Puffern im Flow?
• Zufriedene Mitarbeiter im Team
• Delegieren wie ein echter “Leader”

Thorsten Janning und ich bieten ab dem neuen Jahr dafür die richtige Lösung: Die Scrum Masterclass.Vielleicht denken Sie, dass die Zertifizierungsschulung Ihnen nur die Grundprinzipien von Scrum beigebracht hat, und Sie wünschen sich eine regelmäßige Vertiefung der grundlegenden Techniken, einen Erfahrungsaustausch mit Gleichgesinnten und bei wirklich schwierigen Situationen einen Coach im Projekt.

• Die Masterclass läuft ein Semester (5 Monate) lang und ist auf 12 Teilnehmer beschränkt.
• Es gibt jeden Monat einen 1-tägigen Workshop mit praktischen Tipps, Erfahrungen aus Projekten, mit Rollenspielen für schwierige Situationen und vielem mehr.
• Wir coachen Sie als Teilnehmer aber auch in Ihrem Projektalltag. Angepasst an Ihre individuellen Bedürfnisse stehen Ihnen im Semester 5 Coachingtage zu, in denen beispielsweise Retrospektiven oder Sprintplanungen begleitet, ausgewertet und optimiert werden. Auch spezielle Konflikt- oder Krisensituationen im Team können Sie im Rahmen des Coachings gemeinsam mit Ihrem Coach angehen.

So werden Sie zu Meistern in Scrum, nicht nur zu Scrum Mastern.

Die Meisterklasse wird veranstaltet von der KEGON Akademie. Dort können Sie sich anmelden und erhalten auch weitere Informationen. Auch auf der OOP 2013 wird es mehr dazu geben – wenn Sie im Januar in München sind, fragen Sie einfach am KEGON-Stand nach!

P.S.: Sie kennen mich ja und können deshalb sicher sein, dass ich nicht nur über Scrum sprechen, sondern meine ganze Erfahrung in Agilität und Lean einbringen werde!Diese Beiträge könnten Sie noch interessieren:

• Scrum-Meisterklasse für Scrum Master
• Zufriedene Mitarbeiter im Team
• Ein Software-Architekturteam organisieren
• Die Zukunft als Droge
• Gute Teams wieder aufwecken

• Teams machen Überstunden,
• die Qualität könnte besser sein,
• es entstehen Missverständnisse,
• schließlich werden Projektmanager gesucht, die das ganze “im Griff” behalten.

Mit der Überlastung einher geht die Unausgeglichenheit (auf Japanisch: mura). Die Symptome hierbei:

• Produktmanagement und Vertrieb erzeugen mehr Backlog als die Entwickler abarbeiten können.
• Vor dem Entwicklungsteam bildet sich eine lange Schlange von unfertigen, noch nicht realisierten Anforderungen.
• Die Entwickler schreiben dabei mehr Software, als Kunde und Betrieb abnehmen können.
• Es gibt Phasen mit Stress und solche, in denen man warten muss. Stop-and-go Verkehr, sozusagen.

Unausgeglichenheit führt schließlich zu Verschwendung (auf Japanisch: muda).

• Es entstehen Warteschlangen voll von halb fertiger Arbeit.
• Die Entwickler springen zwischen vielen Aufgaben hin und her.
• Durch Fehler muss bereits getane Arbeit noch einmal gemacht werden.
• Man muss auf Spezialisten warten.
• Jemand hat Zeit und erarbeitet etwas, obwohl sein Nachfolger im Prozess noch gar nicht bereit für die Ergebnisse ist.

Die Ursache von alledem: Unwissen (auf Japanisch: muchi). Die auftretenden Symptome und Effekte werden nur gegen das alte Denkmodell geprüft:

• Termin eingehalten? Nein!
• Budget eingehalten? Nein!
• Umfang erreicht? Nein!
• Wie kommt das nur? Also: “Haut stärker rein, Jungs!”

Wie sich herausstellt, stecken hinter diesen Phänomenen unausrottbare Mythen, die es endlich einmal aufzulösen gilt. Über Fünf Mythen der Projektkultur schreibe ich in der nächsten Folge.Diese Beiträge könnten Sie noch interessieren:

• Fünf Mythen der heutigen Projektkultur
• Stresskultur in agilen Teams
• Raus mit dem Stress, rein in den Erfolg!
• W-JAX 2011: Flow und Risikomanagement
• WJAX 2011: Flow in der Arbeit – Flow im Team