Regelmäßig gehen Teams mit mir durch diesen Umstellungsprozess. Danach erlebe ich jeweils einen völlig perplexen Produktmanager, weil seine Teams nach einer solchen Umstellung sehr früh neue Software liefern und nach neuer Arbeit verlangen, noch ehe er damit gerechnet hat! Schätzen, planen, Termine halten – wozu noch viel Energie da hineinstecken, wenn man fast so schnell liefern wie planen kann?

Die Kunden sind jeweils ganz begeistert, wenn sie das erleben. Deshalb habe ich mich entschlossen, darüber einmal ein längeres White Paper zu verfassen, mit dem Sie versuchen können, diesen Erfolg in Ihrer Firma, mit Ihren Teams zu wiederholen. Wenn Sie bis Ende Mai dieses White Paper in Händen halten wollen, senden Sie bitte Ihre Kontaktdaten an mbohlen@mbohlen.de – ich nehme Sie in den Verteiler auf und sende Ihnen das Papier kostenlos und automatisch Ende Mai zu.

Ich bin sehr gespannt auf Ihr Feedback!Diese Beiträge könnten Sie noch interessieren:

• Wo ist denn nur der Kunde inzwischen?
• Was ist agil, was ist lean?
• Verstehen, was die Software tun soll
• Kalender
• Die Zukunft als Droge

Wir haben Scrum im Einsatz. Wir haben soundsoviele Sprints erfolgreich hinter uns, wir liefern regelmäßig, es geht uns gut. Nun naht der Releasetermin, in zwei Sprints werden wir ihn erreichen. Der Releasetermin steht seit Monaten fest, weil viele europäische Länder auf ihn hinarbeiten und gleichzeitig releasen. Mein Vorgesetzter fragte mich: “Werden Sie den Termin erreichen?”. Ich sagte: “Uns fehlen vermutlich drei Tage.” Darauf der Vorgesetzte: “Dann setzen Sie doch bis dahin drei Wochenend-Schichten an, das passt!”. Herr Bohlen, was soll ich tun? Das geht gegen alles, was wir für wertvoll halten! Das will ich meinen Teams nicht antun!

Als ich die Geschichte hörte, stellten sich mir gleich mehrere Fragen:

1. Wie kann es sein, dass man drei Tage vermisst, wenn man Scrum macht? In Scrum hält man den Termin und lässt eine sehr unwichtige Story weg, na und?
2. Wo ist das Risikomanagement geblieben? Wie konnte es soweit kommen, dass kein Puffer mehr da ist?
3. Diese Teams sind fantastisch! Nach so vielen Sprints fehlen nur drei Tage – wie haben die das geschafft?
4. Wie kann es sein, dass man auf einen bestimmten Termin mit bestimmtem Scope hinarbeitet, anstatt auf maximalen Wert zu einem bestimmten Termin?

Offenbar wirkt die Zukunft wie eine Droge. Wir planen etwas, glauben dann, die Zukunft zu kennen und versuchen, die Gegenwart so zu verbiegen, dass sie dem Plan entspricht. Und das, obwohl Scrum im Einsatz ist, also das agile Manifest bekannt sein sollte. Hmmm…

Es würde helfen, zu Beginn eines solchen Projektes über die grundsätzliche Abmachung zwischen Business und Team zu reden. Ist das Team ein gehorsamer Sklave? Muss es einfach alles machen, was das Business sagt? Oder ist das Team wie ein gut geöltes Motorrad, auf dem das Business an interessante Ziele fahren kann? Ein Ziel nach dem anderen, mit gegebener PS-Zahl, die man nicht durch grobe Tuningmaßnahmen (z.B. Wochenendarbeit) stört?

Setzen wir die Droge “Zukunft” ab. Bleiben wir in der Gegenwart und arbeiten wir für das Heute! Lassen Sie uns heute etwas ausliefern und morgen wieder. Und nächste Woche auch. Und dabei erzeugen wir gemeinsam so viel Wert, dass weitere Termine keine Rolle mehr spielen, weil Kunde und Mitbewerber mit Staunen beschäftigt sind.

Das ist die Kultur, die weiterhilft. Die andere (die mit der Zukunftsdroge) ist von gestern, sie passt nicht mehr zu den engen Märkten von heute.

Wie Sie dahinkommen? Fragen Sie mich, dann reden wir drüber.Diese Beiträge könnten Sie noch interessieren:

• Scrum und seine Nebenwirkung
• Scrum-Jobs wachsen stark
• Produkte effektiv entwickeln
• Was ist agil, was ist lean?
• OOP 2010: Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?)

• Papier schlägt Elektronik
• Physische Kanban-Tafel – warum?
• Produkte effektiv entwickeln
• Kanban Workshop in Köln
• Reduce confusion in meeting series

Auf der Vorträge-Seite habe ich die Folien verlinkt. Sie können Sie dort live ansehen oder von Slideshare herunterladen.

Wenn Sie sich fragen: “Kann diese Art, Risiken zu managen oder auf Schätzen von Aufwänden zu verzichten, auch in meinem Unternehmen funktionieren?”, nehmen Sie bitte Kontakt mit mir auf – ich komme zu Ihnen und Ihren Teams ins Haus, und wir sehen uns das gemeinsam an!Diese Beiträge könnten Sie noch interessieren:

• Schätzen, verschätzen, nachverhandeln
• Liefern schon vor dem Schätzen
• JAX 2012: Risikomanagement mit Real Options
• Risikomanagement mit Kanban
• Artikel: Risikomanagement mit Kanban

Die JAX findet in der Rheingoldhalle statt, meine Vorträge sind am nächsten Dienstag, dem 17. April.Diese Beiträge könnten Sie noch interessieren:

• JAX 2012: STOP IT: schätzen, verschätzen und (nach-)verhandeln
• Zurück von der JAX 2012
• Kalender
• [OOP 2009] Was ist Kultur?
• JAX 2011: Lean Development = Übertunter Motor?

Die Frage in Hamburg

Vorige Woche traf sich die Limited WIP Society Deutschland in Hamburg zu einem Open Space mit diversen, interessanten Sessions zu Themen aus dem Umfeld von Kanban, einer der Lean-Methodiken. Ich war auch dort. Sergey Shishkin stellte in einer Session unter der Überschrift “Science and Fiction” eine für mich sehr interessante Frage:

Wie kann es sein, dass wir unserem Prozess mit Hilfe von Kanban Gleichmäßigkeit geben wollen, und gleichzeitig wollen wir  agil sein, das bedeutet doch, jederzeit Veränderung willkommen zu heißen, oder? Wie viel Science ist denn das, und wieviel ist Fiction?

Am Ende der Session antwortete ich:

Wir heißen Veränderung im Produkt willkommen. Der Kunde darf sich jederzeit etwas anderes wünschen, wir machen das möglich. Wir benutzen dafür jedoch meistens den gleichen Prozess und optimieren ihn, dadurch werden wir in gewissem Maße “berechenbar”. Agilität im Produkt und Gleichmäßigkeit im Prozess widersprechen sich nicht.

Agil und Lean, eine Beziehung

Das Thema geht mir noch weiter im Kopf herum, weil ich das Gefühl habe, die Antwort müsste noch vielschichtiger sein.

Die vier Werte aus dem Agilen Manifest heißen ja: wir schätzen…

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Wenn ich das mit dem Alltag in einem Kanban-System vergleiche, mache ich die folgenden Beobachtungen:

Individuen und Interaktionen: Für mich ist das am spannendsten an Kanban – wir stehen gemeinsam vor der Tafel, sehen zu, was die Arbeit gerade macht und reden darüber, wie es weitergeht. Ab und zu staut sich die Arbeit, wir laufen gegen das WIP-Limit und (weil wir es respektieren) arbeiten wir nicht weiter, sondern lösen gemeinsam das Problem, das zu dem Stau geführt hat. Individuen, die interagieren, um ein Problem zu lösen. Das ist es. Das bleibt ein konstanter Wert im Team.

Funktionierende Software: Ein Team, das ich einmal coachte, hatte sich entschieden, über jeder Spalte (verstehen, entwickeln, abnehmen, akzeptanztesten, usw.) der Kanban-Tafel einen Zettel anzubringen, auf dem die “definition of done” für diese Spalte steht. Wann gilt etwas als “verstanden”, “entwickelt”, “abgenommen”, usw.? Wann ist “fertig” wirklich fertig? Verständliche Stories, klare Abnahmekriterien à la BDD, das ist am Ende der “verstehen”-Spalte wichtig. Funktionierende Software, vorzeigbar, getestet, eingecheckt im Konfigurationsmanagementsystem, usw. – das ist am Ende der “entwickeln”-Spalte wichtig. Das Team spricht oft darüber. Die Leute versuchen, die DoDs  ernst zu nehmen und Karten nur durchzulassen, wenn sie wirklich der DoD in der Spalte entsprechen. Seltsam, die DoD bleibt jetzt (nach kurzer Einschwingzeit) ziemlich konstant, obwohl die Arbeit sich jeden Tag verändert und jeden Tag neu ist.

Reagieren auf Veränderung: Mit dem Management dieses Kanban-Teams habe ich gesprochen, als die Kanban-Einführung anstand. Sie ließen sich überzeugen, dass ein stetiger Fluss von fertiger Software wichtiger ist als hohe Auslastung der Leute und das Erreichen eines Releaseplans mit festem Termin und festem Umfang. Die Kunden bekommen dadurch mehr Flexibilität, denn wenn das Team wenig WIP im Gepäck hat, kann es seine Richtung auch schnell verändern. Lean funktioniert hier als Enabler für Agilität. Und dafür darf auch schon mal jemand unbeschäftigt herumsitzen, das ist auch gut so.

Zusammenarbeit mit dem Kunden: Kanban-Teams erreichen im Laufe der Zeit eine einzigartige Fähigkeit: Bewusstsein über das, was sie können, Bewusstsein über die eigenen Fähigkeiten: Wie viele Karten pro Woche schaffen wir? Wann können wir die Software für eine neue Karte liefern, die wir heute angefangen haben? Welche Qualität können wir sicherstellen, wenn man uns das tun lässt? Mit diesem Wissen kann das Team ganz anders mit dem Kunden zusammenarbeiten. “Vertragsgegenstand” ist nun nicht mehr ein bestimmter Inhalt oder Umfang, sondern das Verhalten eines reifen, engagierten Teams! Es geht um Service, nicht um Scope. Kunde, wir zeigen Dir, was wir können und wie wir arbeiten, und Du entscheidest, wie Du dieses Können innerhalb des Alltags möglichst gewinnbringend für Dich nutzt. Zusammenarbeit: Der Kunde will, das Team kann. Beide kommen überein, Willen und Können zusammenzubringen, um Wert zu schaffen.

Gegenseitigkeit

Lean-Methoden wie Kanban räumen engagierten Teams die Bahn frei in Richtung Agilität. Kenntnis der eigenen Fähigkeiten (Berechenbarkeit im guten Sinne) gibt Teams die Ruhe, die sie brauchen, um jeden Tag neue Veränderung willkommen zu heißen.

Hört sich philosophisch an, merke ich gerade. Doch: Warum eigentlich nicht?Diese Beiträge könnten Sie noch interessieren:

• Liefern schon vor dem Schätzen
• Trainings in Kanban
• Danke für 2011, hallo 2012!
• Wo ist denn nur der Kunde inzwischen?
• W-JAX 2011: Flow und Risikomanagement

• Liefern schon vor dem Schätzen
• WJAX 11: Risikomanagement mit Kanban
• Die Persona: Schlüssel zu besseren Anforderungen
• Emergente Architektur: Der machtlose Architekt
• JAX 2008: Not invented here: "Soft Bugs" finden und reparieren

• die Teams tun nicht, was sie sollen,
• die von den Teams erstellte Software performt nicht,
• die Leute verstehen nicht, was die eigentliche Aufgabe der Firma ist,
• die hervorgebrachte Architektur kennt oder versteht man außerhalb der Teams nicht,
• die Teams brauchen viel zu lange, um etwas zu entwickeln,
• und vieles dergleichen mehr.

Klingt das für Sie vertraut? Hatten Sie auch schon Lust, mit dem eisernen Besen zu kehren, so nach dem Motto: “Da kann doch mit der angeblichen Selbstorganisation etwas nicht stimmen! Ich gehe hin und sage denen jetzt mal, was Sache ist … Wenn die Leute das selbst nicht können, muss ich halt ran!”.

Das kann ja wirklich so sein. Bevor Sie als Manager jedoch Leute feuern, lassen Sie mich noch ein paar Fragen stellen:

• Wenn die Teams nicht tun, was sie sollen … Woran hätten die Mitarbeiter erkennen können, was sie tun sollen? Haben Sie z.B. Abnahmekriterien oder Entscheidungsfilter ausgegeben? Woran erkennen Sie, dass die Leute nicht das tun, was sie sollen? Ist es möglich, dass die Leute etwas vermeintlich oder tatsächlich Besseres tun?
• Wenn die Software nicht performt … Haben Sie eigentlich klar vorgegeben, was Performance im jeweiligen Kontext  genau heißt? Antwortzeit? Durchsatz? Speicherverbrauch? Wann haben Sie’s den Leuten ins Backlog gestellt?
• Wenn die Leute nicht verstehen, was die eigentliche Aufgabe der Firma ist … Haben Sie ihnen erzählt, welchen Wert Ihre Firma für Ihre Kunden stiftet? Welche Fähigkeiten Ihre Kunden dadurch haben, dass sie Ihre Software einsetzen? Und: Was daran eigentlich so genial ist, dass alle neidisch auf Ihre Firma sein müssten? Wo ist das Feuer, wann haben Sie den Menschen Begeisterung ermöglicht?
• Wenn die Architektur unsichtbar ist oder niemand sie versteht … Haben Sie von Ihren Teams und Architekten auch klar verlangt, was Sie sehen möchten? Und zwar früh genug, gleich nach jeder umgesetzten User Story? Zum Beispiel: Komponenten und ihre Verantwortlichkeiten, wichtige Abläufe im System, Deployment-Zuordnung von Komponenten zu Maschinen und Kommunikationskanälen, Lösungen für nicht-funktionale Anforderungen?
• Wenn die Leute viel zu lange brauchen, um etwas umzusetzen … Wie groß war das Paket, das die Leute auf einmal stemmen mussten? Haben Sie auf dem Bestellzettel des Paketes alles klar genug vermerkt? Wie groß war die Klarheit und Qualität der gestellten Anforderungen? Wie oft bekamen die Leute Feedback? Was mussten die Leute Unnötiges tun, was sie abgehalten haben könnte (z.B. Stundenzettel ausfüllen)?

Worauf ich mit diesen Fragen hinaus will, ist folgendes:

1. Intelligente Leute verhalten sich in guten Systemen (z.B. gut geführten Teams oder Firmen) vernünftig – niemand will ein Trottel oder ein Spielkind sein.
2. Mitarbeiter wollen professionelle, gute Arbeit machen und damit Erfolg haben.
3. Menschen wollen selbst operative Entscheidungen treffen, zu Meistern ihres Faches werden und wissen, welchen Sinn und Zweck das Ganze hat.
4. Ist das gegeben, dann ist es nur noch eine Frage der Kompetenz und ob ihnen jemand dabei hilft, Grundbedingungen schafft und Hindernisse aus dem Weg räumt.

Fragen Sie sich einmal folgendes:

• Wenn der Mitarbeiter nicht tut, was er soll – würde er es denn tun, wenn sein Leben davon abhinge? Zum Beispiel wie bei einer Polarexpedition?

Lautet die Antwort “ja”, so hat er die Kompetenz und ist lediglich demotiviert oder konfus/desorientiert. Fragen Sie sich dann, ob es an Ihnen oder an der von Ihnen gestalteten Firma liegt. Wenn ja, tun Sie etwas, um die Systembedingungen zu verändern und es für den Mitarbeiter einfach zu machen, das zu tun, was für die Firma am besten ist.

Lautet die Antwort “nein” (er würde es also auch nicht tun, wenn sein Leben davon abhinge!), so hat er die Kompetenz nicht. Fragen Sie sich (und/oder ihn selbst) dann, ob er diese erwerben oder etwas anderes Wertvolles für Sie tun kann. Erst wenn die Antwort darauf ebenfalls “nein” lautet, feuern Sie ihn.

In jedem Fall: Schaffen Sie Attraktoren – das sind Punkte mit gewünschtem Verhalten, zu dem die Leute fliegen wie Motten zum Licht. Scheuchen Sie die Motten nicht (da haben Sie nämlich viel zu tun!). Stellen Sie stattdessen klar erkennbare Lampen auf, die ständig leuchten.Diese Beiträge könnten Sie noch interessieren:

• Lösung ohne das zugehörige Problem?
• Delegieren wie ein echter “Leader”
• Liefern schon vor dem Schätzen
• Leader entwickeln
• Mitarbeiter mit Lean-Erfahrung einstellen

Meine Empfehlung: Versetzen Sie sich in die Lage eines echten Benutzers und denken Sie dann erst darüber nach, was Ihre Software für ihn tun kann. Arbeiten Sie heraus, wer dieser Benutzer ist, seine “Persona”:

• Wie alt ist er wohl?
• Welche Fähigkeiten oder Ausbildung hat er schon?
• Welche Werkzeuge benutzt er sonst noch für seine Arbeit?
• Mit wie vielen Leuten arbeitet er zusammen?
• Wie oft braucht er Ergebnisse?
• Was will seine Chefin oder was wollen seine Kollegen von ihm?

Stellen Sie sich ihre typischen Personae mal vor und entwerfen Sie einen Steckbrief für jede Persona. Erfinden Sie…

• Name
• Geschlecht
• Beruf
• Alter
• Arbeitszeiten
• Arbeitsorte/-plätze
• Bedürfnisse
• Hobbies
• Beziehungen zu anderen Personae

usw. usw. — was auch immer Sie brauchen, um sich wirklich vorzustellen, für wen Sie eigentlich die Software entwickeln. Und dann fällt es Ihnen plötzlich ganz leicht, deren Verhalten im Umgang mit der Software aufzuschreiben, in Form von Szenarios:

• GEGEBEN: eine bestimmte Grundsituation, in der die Persona vor der Arbeit mit Ihrem System steckt oder eine Menge von früheren Ergebnissen, die die Persona bereits in der Hand hält
• WENN: ein bestimmtes Ereignis auftritt, das Vorgänge in Ihrer Software auslöst
• DANN: die Menge von Ergebnissen, die Ihr System der Persona liefern muss, damit sie das Gefühl hat, einen Fortschritt erreicht zu haben.

Schreiben Sie Szenarios auf Karteikarten und ordnen Sie sie an der Wand, z.B. nach Persona und nach derjenigen User Story, die in dem Szenario ausgeführt wird. Bilden Sie dann Pakete von Szenarios und geben Sie sie in die Entwicklung und den Test. Besser noch: Lassen Sie Entwickler und Tester gleich an der Erarbeitung der Szenarios mitmachen und Ideen liefern. Das reduziert Kommunikationsaufwand und öffnet den Blick für mehr Ideen. (Das Ganze nennt man nebenbei “behaviour driven development”.)

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

• Produkte effektiv entwickeln
• Verstehen, was die Software tun soll
• Delegieren wie ein echter “Leader”
• Kanban
• Was ist agil, was ist lean?

Risikomanagement ist wichtig – das weiß jeder, der in einem IT-Vorhaben gearbeitet hat. Doch so manche Risikoliste veraltet einsam auf der Festplatte eines Servers, ohne dass ein Mitglied der Entwicklungsorganisation hineinschaut. Mit Kanban kann das anders werden. Risiken sind nicht mehr getrennt von der Arbeit, sondern werden als Bestandteil der Arbeit gesehen und verfolgt. Entwicklungsteams und Management teilen sich diese Aufgabe – die Entwickler haben die Informationen, die Manager geben Entscheidungsrichtlinien. Gemeinsam können Risiken so schneller berücksichtigt und behandelt werden.

Lesen Sie den Artikel auch online.Diese Beiträge könnten Sie noch interessieren:

• Risikomanagement mit Kanban
• JAX 2012: Risikomanagement mit Real Options
• WIP – Aufgaben in Arbeit
• W-JAX 2011: Flow und Risikomanagement
• Flow in Lean, Flow im Team

Zeit erfassende Entwickler

Von Zeit zu Zeit sehe ich Zeiterfassungssysteme bei meinen Kunden. Zum Beispiel müssen manche Softwareentwickler die Zeit buchen, die sie an einem bestimmten Stück Code gearbeitet haben oder die Zeit, die sie in einem Meeting verbracht haben. Ich frage dann ab und zu, warum das so ist. Meist liegt es daran, dass das Unternehmen für ein Projekt oder sogar ein einzelnes Feature ein bestimmtes Budget vorgesehen hat und nun wissen möchte, ob das Budget auch eingehalten wird. Vom Standpunkt einer effektiven, flüssigen Entwicklung her gesehen ist das schädlich, denn es setzt künstlich Grenzen wo keine sind. Die Entwickler werden sich dann mehr mit der Frage beschäftigen, ob das Budget eingehalten wird als mit der Frage, ob der Wert, der durch ihren Code erzeugt werden sollte, auch erreicht wurde.

Geld fließt besser ungeteilt

Besser ist es, die Einnahmen und die Ausgaben als Ströme zu betrachten, die so wenig wie möglich aufgeteilt werden. Die Einnahmen sind schon natürlicherweise aufgeteilt, weil sie aus verschiedenen Quellen kommen. Die Ausgaben fließen in verschiedene Senken, z.B. Gehälter, Energie, Material usw. und sollten auch nicht weiter aufgeteilt werden. Meist sind die Ausgaben pro Zeitraum sogar mehr oder weniger fix, weil sich die Zahl der Mitarbeiter nicht großartig verändert. Man kann deshalb die Kostenseite als bekannt annehmen und mehr Augenmerk auf die Steigerung der Einnahmen legen. Dabei gehen Sie am besten vom Jetzt aus und überlegen, woher Ihre Einnahmen stammen. Als nächstes fragen Sie am besten: Wie können wir das, was wir tun, für den Kunden noch weit wertvoller gestalten? Wie können wir den Kunden so begeistern, dass er noch mehr dafür bezahlt? Das bringt Sie gedanklich in eine ganz andere Motivationslage als wenn Sie rein über Kostenverfolgung oder Kostenreduzierung nachdenken.

Das budgetierte Radio

Auch bei der Gestaltung des Produktes selbst sollten Sie darauf achten, nicht unnötig zu segmentieren und zu budgetieren. Ein schönes Beispiel ist das Internetradio, das meine Frau und ich vor kurzem gekauft haben. Unser altes FM-Radio in der Küche hatte ein Grundrauschen, das beim Zuhören kaum noch zu ertragen war. Deshalb wollten wir einen klaren Empfang über WLAN, eine große Senderzahl, eingebauten CD-Player, UPNP-Streaming und eingebaute Lautsprecher. Wie sich herausstellte, waren diese Anforderungen gleichzeitig kaum zu befriedigen. Ich habe wochenlang gesucht. Die meisten Geräte fallen in zwei Kategorien, die sich nicht überlappen:

• Geräte mit WLAN und UPNP und Lautsprecher, doch ohne CD-Player
• Geräte mit FM-Radio, CD-Player und Lautsprecher, aber ohne WLAN und UPNP-Streaming

Meine Vermutung: Die Hersteller haben ihren Markt “budgetiert” in zwei verschiedene Märkte. Wahrscheinlich glauben die Hersteller, es gäbe zwei Arten von Kunden: die internet-affinen und die traditionellen. Der einen Gruppe geben sie die eine Featuremenge, der anderen Gruppe die andere. Für meine Frau und mich stimmt das ja sogar! Doch dummerweise leben wir in derselben Küche und wollen nur ein Gerät, in dem beides enthalten ist. Die Budgetierung in zwei Märkte führte lange Zeit dazu, dass wir gar kein Gerät kauften. Jetzt haben wir endlich eins gefunden, und es funktioniert sogar, deshalb haben wir es behalten.

Beim Konfigurieren des Gerätes fand ich dann aber doch wieder drei “Budgets”. Das Radio hat drei verschiedene Arten, Sender zu empfangen: Internet, FM und DAB. Dafür hält es drei verschiedene Sendertabellen vor, mit jeweils 10 Einträgen, in denen man die Lieblingssender speichern kann. In unserer Küche nutzen wir aber keine FM-Sender und keine DAB-Sender, weil ja ohnehin mehr als 10.000 Stationen über das Internet empfangbar sind. Eine einheitliche Sendertabelle mit 30 Sendern hätte uns also viel mehr genützt als drei Tabellen zu je 10 Sendern! Wieder eine Art von Budgetierung, die in diesem Fall die Usability des Gerätes und damit dessen Wert für den Kunden herabsetzt. Nach so viel Zeit des Suchens und Findens habe ich jedoch beschlossen, dass ich die drei kleinen Tabellen in Kauf nehme und (wenn ich mehr will) mit dem Cursor durch eine große Senderliste scrolle.

Ganzheitlichkeit

Also langer Rede kurzer Sinn: Budgetieren Sie nicht! Lassen Sie es einfach. Lassen Sie das zusammen, was zusammen gehört. Trennen Sie nicht unnötig, und Ihre Kunden und Ihre Firma werden mehr davon haben. Fragen Sie mich, falls Sie Ihre Produkte oder Ihre Organisation auf diese Art von Ganzheitlichkeit umstellen wollen – ich kann Ihnen helfen.

Mehr zum Thema finden Sie unter anderem hier: Beyond BudgetingDiese Beiträge könnten Sie noch interessieren:

• Kanban im Supermarkt [OOP 2011]
• Wo ist denn nur der Kunde inzwischen?
• Geschäftsmodelle für Ihre Softwarefirma
• Drei Fragen zu Ihrer Produktstrategie
• Wohin mit den Puffern im Flow?

Heute geht es um die Qualität dessen, was da entwickelt wird, denn auch die muss stimmen. Sie sollten die Qualitätsanforderungen, die der Kunde hat, früh im Blick behalten:

• Wie schnell muss das System sein (Performanz)?
• Wie viele Daten muss es verarbeiten (Größe)?
• Wie viele Benutzer wird es heute und morgen haben (Skalierbarkeit)?
• Wie sicher muss es gegen Angriffe sein (Sicherheit)?
• Wie leicht muss es erweiterbar sein (Wartbarkeit)?
• usw.

Sie müssen diese Qualitäten nicht sofort einbauen, denn das kann teuer sein. Wenn Sie zum Beispiel zu früh Wert auf Performanz legen, noch bevor Sie wissen, wie die Systemstruktur aussehen wird, investieren Sie vielleicht zu viel. Wenn Sie jedoch zu spät auf Performanz achten, müssen Sie sie „hineintesten“, wenn schon alles fertig ist. Auch das wird teuer.

Fassen Sie die Qualitäten am besten genauso in Anforderungen wie Sie es mit den funktionalen Aspekten des Systems getan haben. Sie können beispielsweise folgende Typen kreieren (wie von Stefan Toth vorgeschlagen):

Qualitätsstory

ist eine Qualitätseigenschaft, die man einmalig einbaut (wie eine User Story) und die dann im System enthalten ist. Das könnte z.B. das Aufsetzen einer Load Balancer Infrastruktur sein, die für Lastverteilung und damit Skalierbarkeit sorgt.

Qualitätsaspekt

ist eine Qualitätseigenschaft, die eine oder mehrere User Stories betreffen wird und dort berücksichtigt werden muss. Beispiel: „Bei allen Adress-Eingaben, in denen der Benutzer eine Postleitzahl eingegeben hat, muss das System den Ort selbst automatisch einsetzen.“

Qualitätsrichtlinie

ist eine Qualitätseigenschaft, die viele oder alle User Stories betreffen wird und deshalb immer im Gedächtnis aller Teammitglieder bleiben muss. Beispiel: „Neu eingebauter Code darf die Laufzeiten der bisherigen Performanztests nicht verlängern.“

Für den ersten der drei Typen von Qualitätsanforderungen, die Qualitätsstory, erzeugen Sie Einträge im Product Backlog, wie für User Stories auch. Den zweiten Typ, den Qualitätsaspekt, fügen Sie als Akzeptanzkriterium zu einer oder mehreren User Stories hinzu. Den dritten Typ, die Qualitätsrichtlinie, schreiben Sie in die Definition of Done für das gesamte Produkt.

Lassen Sie Ihren Software-Architekten mit dem Product Owner, der das Backlog pflegt, zusammenarbeiten. Der Software-Architekt wird Ihnen sagen können, welche Qualitätsanforderungen wie in Ihrem System abgebildet werden sollen. Lassen Sie den Software-Architekten, den Product Owner und das Team darüber diskutieren, mit welcher Priorität die Qualitätsanforderungen bearbeitet werden sollen. Ein gemeinsames Verständnis über Kosten der Architekturarbeit (und die Kosten, wenn man diese Arbeit unterlässt!) vermeidet Streit in einer agilen Softwarefirma.Diese Beiträge könnten Sie noch interessieren:

• Wo ist denn nur der Kunde inzwischen?
• Leader entwickeln
• Einkauf von geistigem Rohstoff
• Drei Fragen zu Ihrer Produktstrategie
• Fernseh-Feedback

Verstehen

Ihr Kunde und Ihre Softwarefirma sind Teile einer Wertschöpfungskette. Ihre Teams haben die Fähigkeit, Software zu entwickeln oder Dienste zu leisten. Ihr Kunde sucht diese Software oder Dienstleistungen, um seine eigenen Fähigkeiten zu steigern. Diese Fähigkeiten vermarktet er wiederum an seine Kunden und bekommt Geld dafür. Einen Teil des Geldes gibt er Ihnen für die gelieferte Software oder Dienstleistung.

Vision

Lassen wir die Kette der Vision des Kunden beginnen bzw. mit einem Ausschnitt daraus, einem seiner Geschäftsziele. Beispiel: Der Kunde gibt eine Zeitung heraus, zu der er auch einen Online-Auftritt im Web anbietet. Sein Ziel ist, die Zahl der Abonnenten zu steigern und mehr Zeitungen zu verkaufen. Im Kopf des Kunden ist die Idee, die Leser der Zeitung besser in den Online-Auftritt einzubinden, indem er ihnen die Möglichkeit gibt, die Artikel zu kommentieren und zu diskutieren. Das bindet die Leser besser an diese eine Zeitung, und außerdem bekommen die Redakteure dadurch mehr Ideen, worüber sie als Nächstes schreiben könnten.

Fähigkeit und Features

Sie bekommen also den Auftrag, den Online-Auftritt der Zeitung so anzureichern, dass der Dialog der Zeitung mit den Lesern möglich wird. Dieser Dialog soll später zu den Fähigkeiten des Kunden gehören, zu sehen auf der linken Seite des Bildes. Der Kunde hofft, diese Fähigkeit wird der Zeitung einen Wert einbringen, in Form von treueren Lesern oder mehr Abonnenten.

Im Gespräch mit Ihren Teams stellt der Kunde fest, dass folgende Features in der Software nötig sind, um die Fähigkeit zum Dialog auszubilden:

Artikel kommentieren

Die Leser sollen zu einem Artikel, den sie gerade gelesen haben, Kommentare abgeben können. Die Website stellt die Kommentare nach dem Artikel dar.

Kommentar moderieren

Die Redakteure der Zeitung sollen eingehende Kommentare prüfen und bei ungeeignetem Inhalt ablehnen können.

Die Redakteure der Zeitung sollen einzelne Benutzer sperren können, falls sie wiederholt ungeeignete Kommentare abgeben.

Identität des Kommentierenden prüfen

Kommentare sollen nicht anonym sein, sondern jeweils einem bestimmten Benutzer der Website zuzuordnen sein. Der Benutzer muss sich also authentifizieren, bevor er anfängt, Kommentare einzugeben.

Während Sie diese Features mit dem Kunden gemeinsam analysieren, behalten Sie immer im Hinterkopf, dass die Features dazu dienen sollen, eine bestimmte Fähigkeit des Kunden auszubilden, nämlich den Dialog der Zeitung mit den Lesern. Aus Features, die Sie gemeinsam mit dem Kunden finden und analysieren, entsteht die erste Granularitätsstufe der Nachfrage. Das ist es, was der Kunde von Ihren Teams bekommen will und für was er bereit sein wird, zu bezahlen: Eine Lösung aus fertig entwickelter, lauffähiger, getesteter und angemessen dokumentierter Software, zu sehen in der Mitte des Bildes.

Story

Jedes Feature ist eine Gruppe von zusammengehörenden Funktionen des Systems. Die zukünftigen Benutzer des Systems können mit jeder dieser Funktionen eine Geschichte erzählen, die den Umgang des Benutzers mit dem System beschreibt – eine so genannte User Story. Zu den oben genannten Features könnten Ihre Teams mit dem Kunden die folgenden User Stories identifiziert haben:

Artikel kommentieren

Als Leser möchte ich einen neuen Kommentar hinzufügen, um meine Meinung zu einem Artikel zu sagen und mit anderen Lesern ins Gespräch zu kommen.

Als Leser möchte ich alle meine bisher eingegebenen Kommentare auflisten, um nachzusehen, ob ich noch etwas ändern möchte.

Als Leser möchte ich einen eingegebenen Kommentar überarbeiten, um sicherzustellen, dass er wirklich meine Meinung wiedergibt.

Als Leser möchte ich einen eingegebenen Kommentar zurücknehmen, weil ich inzwischen meine Meinung geändert habe.

Kommentar moderieren

Als Redakteur möchte ich neue Kommentare auflisten, um festzustellen, was die Leser über einen Artikel denken.

Als Redakteur möchte ich einen einzelnen Kommentar sperren, um sicher zu sein, dass qualifizierte Äußerungen und offene Diskussion anstatt Zank und Streit auf der Website herrschen.

Als Redakteur möchte ich einen kommentierenden Benutzer sperren, um notorische Streithähne auszuschließen.

Identität des Kommentierenden prüfen

Als Leser möchte ich mich anmelden, um kommentieren zu können und sicherzustellen, dass mir meine Kommentare später noch zur Verfügung stehen.

Als Leser möchte ich mich abmelden, um sicher zu sein, dass niemand in meinem Namen einen Kommentar einstellt, wenn ich einen öffentlichen Computer verlassen habe.

Als Leser möchte ich mein Kennwort zurücksetzen, wenn ich es vergessen habe.

Als Leser möchte ich eine OpenID hinzufügen, um nicht immer für jede Website ein eigenes Kennwort merken zu müssen.

Beispiele

Menschen denken in Beispielen. Beispiele haben im Verstehensprozess eine ganze Reihe von Vorteilen:

• Beispiele sind eine Möglichkeit, um zu klären, was der Kunde mit einer User Story genau gemeint hat.
• Beispiele erforschen Grenzbedingungen, unter denen eine Story anders abläuft als normalerweise.
• Beispiele helfen, Geschäftsregeln zu finden, die in einer Story gelten müssen.
• Beispiele liefern Testdaten, mit denen die lauffähige Story später getestet werden kann.
• Beispiele lassen sich in Akzeptanz- oder Regressionstests verwandeln und automatisieren, um sicherzustellen, dass die Software auch bei Veränderungen nicht an Funktionalität einbüsst.

In natürlicher Sprache abgefasste Stories können noch mehrdeutig sein, weil natürliche Sprache von verschiedenen Personen unterschiedlich interpretiert wird. Deshalb ist es gut, wenn sich der Kunde, die Anforderungsanalysten, die Entwickler und die Tester zusammenfinden, um Beispiele zu den Stories miteinander durchzugehen. Das fördert das gemeinsame Verständnis und vergrößert die Chance, dass man gleich jetzt (und nicht erst beim Codieren) feststellt, was die wahre Bedeutung einer Story ist.

Ein Beispiel für Beispiele: Ihre Entwickler sind mit dem Kunden die Anforderungen durchgegangen und haben die oben genannten Stories aufgeschrieben. Dabei fiel den Entwicklern auf, dass noch nicht so recht klar ist, wann ein Kommentar nun wirklich „live“ auf der Website zu sehen sein wird: gleich nach der Eingabe oder erst nachdem ein Redakteur den Kommentar freigibt. Die Stories hören sich an, als ob der Kommentar erst einmal live geht und erst im Nachhinein durch einen Redakteur gesperrt werden kann. Die Entwickler formulieren deshalb das folgende Beispiel:

• Hans (ein Leser der Zeitung) fügt folgenden Kommentar hinzu: „Der Schreiberling, der diesen Artikel verfasst hat, hat ja wohl überhaupt keine Ahnung, von was er redet. Erstens weiß er nicht, worum es geht und zweitens drückt er es auch noch schlecht aus.“
• Die Website der Zeitung stellt den Kommentar sofort ins Netz.
• Rudolf (ein Redakteur) kommt am nächsten Tag ins Büro und lässt sich neue Kommentare auflisten. Er entdeckt den provozierenden Kommentar von Hans.
• Rudolf lässt das System diesen einzelnen Kommentar sperren.
• Die Website stellt ab jetzt nur noch den Anfang des Kommentars und die Bemerkung „vom Moderator gesperrt“ dar.

Dieses Beispiel kann zu mehreren gesunden Dialogen zwischen Fachbereich und Entwicklung führen. Einerseits könnte ein Gespräch über die Frage entstehen, ob die Redaktion jeden Kommentar zuerst genehmigen möchte, bevor er live auf die Website geht, um zu verhindern, dass solche Bemerkungen ins Netz kommen. Vielleicht möchten die Redakteure angesichts der großen Zahl von Kommentaren, die kommen werden, nicht jeden genehmigen sondern nur die unqualifizierten sperren. Vielleicht möchten die Redakteure aber später eine weitere User Story „Negativ gestimmte Kommentare automatisch erkennen“, um der großen Zahl noch Herr zu werden. Oder sie möchten eine Geschäftsregel, die sagt: Wenn drei Kommentare eines Lesers genehmigt wurden, werden von da an alle automatisch genehmigt.

Sie sehen, solch ein Beispiel führt zu intensiven Gesprächen über das, was die Software später tun soll.

Zusammenfassung

Das bedeutet für mich Verstehen: Aus der Vision und den Zielen des Kunden Fähigkeiten ableiten, die er gerne hätte. Dann diese Fähigkeiten mit Hilfe von Software-Features unterstützen. Diese Features in erzählbare Stories aufteilen und die mit Hilfe von Beispielen verständlich und später testbar machen.Diese Beiträge könnten Sie noch interessieren:

• Qualitätsanforderungen agil managen
• Wo ist denn nur der Kunde inzwischen?
• Die Persona: Schlüssel zu besseren Anforderungen
• Was ist agil, was ist lean?
• Geschäftsmodelle für Ihre Softwarefirma

Kunden finden

In einer Softwarefirma liegt der Fokus normalerweise auf der Produktentwicklung. Viele ziehen sich zurück ins stille Kämmerlein, entwickeln dort das Produkt, gehen damit an dem Markt und hoffen, dass Kunden es kaufen. Das ist eine der häufigsten Ursachen für Fehlschläge. Das Produkt mag gut sein, doch die Annahme, der Markt wolle es auch einsetzen, ist bis zum ersten Release meist nicht überprüft worden. Deshalb ist es am besten, neben dem Prozess der Produktentwicklung auch gleich die Kunden „mitzuentwickeln“, wie es Steve Blank in seinem Buch Four Steps to the Epiphany¹ formuliert:

Most startups lack a process for discovering their markets, locating their first customers, validating their assumptions, and growing their business. … Customer Development focuses on understanding customer problems and needs, Customer Validation on developing a sales model that can be replicated, Customer Creation on creating and driving end user demand, and Company Building on transitioning the organization from one designed for learning and discovery to a well-oiled machine engineered for execution.

Die eigenen Annahmen zu überprüfen, ist dabei einer der zentralen Schritte. Produktentwickler machen alle möglichen Arten von Annahmen:

• Die Kunden brauchen eine Software vom Typ X, die das Problem Y löst.
• Die Kunden befinden sich in Unternehmen der Art Z.
• Das Produkt muss die Eigenschaften A, B und C haben.
• u.v.a.m.

Diese Annahmen sind alle ungeprüft, bis der erste Kontakt zwischen Software und Kunde zustande kommt. Dann zeigt sich, ob das Problem Y tatsächlich gelöst werden musste, ob die Kunden wirklich bei Z sind und ob das Produkt wirklich A, B und C haben musste. Doch dann ist das Investment für die Entwicklung bereits ausgegeben, und man sagt sich „wenn wir das vorher gewusst hätten, dann…“.

Es ist also gut, wenn Sie zuerst nur ein minimal überlebensfähiges Produkt entwickeln und die Annahme, dass Kunden dafür bezahlen würden, gleich „live“ im Markt verifizieren, bevor Sie größere Beträge in die Entwicklung investieren. Wenn Sie Kunden finden, die mit Ihnen reden und die Geldbörse für einen Teil dessen öffnen, was Ihre Firma entwickelt hat, dann haben Sie schon mal eine erste Testumgebung für Ihre Annahmen.

Verkaufen

Verkaufen ist der nächste Schritt, wenn Sie Ihre Kunden einmal gefunden haben. Achten Sie zunächst darauf, dass Sie wirklich denjenigen finden, der für die Entscheidung, in Ihr Produkt zu investieren, verantwortlich ist. Nichts ist schlimmer als an jemanden zu geraten, der zwar „nein“ aber nicht „ja“ sagen kann, weil er noch die Erlaubnis von jemand anderem braucht.

Hören Sie dem Kunden zu, stellen Sie ihm den Wert vor, den Ihr Produkt bietet, zeigen Sie ihm, wie er selbst damit arbeiten und sein Geschäft optimieren könnte. Versuchen Sie, mit ihm eine konzeptionelle Übereinstimmung zu erzielen. Diese beinhaltet: Welches Problem soll mit dem Produkt gelöst werden? Welche Vorteile können geschaffen werden? Woran kann der Kunde erkennen, ob und wann die Vorteile auch tatsächlich entstehen?

Wenn der Kunde und Sie konzeptionell übereinstimmen, d.h. über die zu liefernde Software und die möglicherweise dazugehörende Dienstleistung einig sind, senden Sie dem Kunden ein Angebot, das in kurzer Form das zusammenfasst, über das Sie ohnehin schon einig sind und das dann dem Wert einen Preis zuordnet. Der Kunde kann nun entscheiden, ob ihm der versprochene Wert die angekündigten Kosten wert sein wird.

Wert schaffen

Sie haben einen Auftrag bekommen? Schön! Dann brauchen Sie den Wert, den Sie angekündigt haben, ja „nur noch“ zu schaffen. Sie haben hoffentlich nicht versucht, einen Riesenauftrag zu definieren – das geht in aller Regel später bei der Erfüllung schief! Große Aufträge haben einen langen Planungshorizont und deshalb erhöhtes Risiko bezüglich Zeitplan und Machbarkeit. Definieren Sie kleine Stücke, die Sie regelmäßig ausliefern und dem Kunden zur Überprüfung geben können. Das können Sie besser planen und steuern, der Kunde bekommt früher lauffähige Ergebnisse zu sehen, mit denen er vielleicht sogar schon Geld verdienen oder Kosten sparen kann.

Zur Erschaffung des Wertes brauchen Sie fünf wichtige Fähigkeiten:

• Verstehen
• Planen
• Bauen
• Liefern
• Helfen

Verstehen bedeutet zu begreifen, welche Vision der Kunde hat, welche Fähigkeiten die Software braucht und welche Features geeignet sind, die Fähigkeiten zu realisieren.

Planen bedeutet, die Unsicherheit im Vorhaben greifbar zu machen und herauszufinden, was Sie alles tun müssen, welche Zwischenergebnisse Sie liefern können, in welcher Qualität und in welcher Zeit.

Bauen ist die eigentliche Tätigkeit, mit der Sie die Software erschaffen. Manchmal trifft es auch nicht der Begriff „bauen“, sondern „anbauen“ (wie bei Pflanzen) würde es besser treffen. Finden Sie heraus, was das minimal auslieferbare Feature wäre, das dem Kunden die Fähigkeiten gibt, die er verlangt. Liefern Sie das Feature aus und fragen Sie, was jetzt noch bis zum produktiven Einsatz fehlt.

Liefern ist die Fähigkeit, ohne viel Aufwand das herauszubringen, was Sie schon lauffähig haben. Sie haben diese Fähigkeit, wenn es keiner großartigen Umstände mehr bedarf, etwas in Produktion zu bringen, das beim Entwickler schon läuft. Sie müssen Ihre Prozesse noch optimieren, wenn das nicht so sein sollte. Großer Aufwand beim Ausliefern ist nicht normal, sondern eine Schwäche, die man überwinden sollte.

Unter Helfen fallen Tätigkeiten wie Schulung und Support. Die Software selbst sollte ja einfach zu bedienen sein – es ist jedoch möglich, dass die Geschäftsprozesse sich mit der Software ändern und deshalb lieb gewordene Gewohnheiten durch Schulung verändert werden sollen.

Lernen

Eine erfolgreiche Softwarefirma ist immer eine lernende Firma. Kunden geben Ihnen Feedback zur gelieferten Software: Was war leicht zu verstehen, wofür brauchte man Hilfe? Welche Teile waren leicht zu benutzen, wo gab es Schwierigkeiten, welche Features der Software funktionieren im Alltag überhaupt nicht? Nehmen Sie dieses Feedback, um die Natur der Nachfrage immer weiter zu verstehen und den Wert, den Ihre Software für den Kunden erzeugt, immer weiter zu steigern.

Beobachten Sie jedoch auch die Fähigkeiten Ihrer eigenen Firma. Das ist das zweite Feld, auf dem Sie lernen können: Wie lange brauchen wir, um ein Feature zu realisieren? Was stand uns dabei im Weg? Wie hoch ist der Anteil der langweiligen Tätigkeiten, wie hoch der kreative Anteil? Lässt sich der langweilige Anteil vielleicht automatisieren? Was können wir gut, woran müssen wir noch arbeiten?

Managen

Wert schaffen und Lernen brauchen eine weitere, unterstützende Fähigkeit: Management. Darunter fasst man landläufig mindestens drei Dinge zusammen: führen, steuern und organisieren. Führen bedeutet, die Richtung anzuzeigen, in der das Ziel liegt. Steuern bedeutet, Pläne und Regeln aufzustellen und die Leute zu deren Einhaltung zu motivieren. Organisieren bedeutet letztlich, herauszufinden, was man zwischen 14 und 16 Uhr tut, wer dabei mitmacht und was man dazu braucht. Führung kann und muss „von oben“ ausgehen, kann aber auch situationsbezogen von einem Mitarbeiter, der gerade am besten Bescheid weiß, ausgeübt werden. Steuern müssen die Vorgesetzten, organisieren können sich die meisten selbst. Der Trick liegt in der richtigen Aufteilung von führen, steuern und organisieren.

Mitarbeiter entwickeln

Mitarbeiter zu entwickeln ist genauso wichtig wie Kunden oder Produkte zu entwickeln. Es heißt so schön „Talent kann man nicht lernen, man hat es oder man hat es nicht.“ Darin steckt sicherlich ein Körnchen Wahrheit. Talente müssen Sie finden und einstellen – Sie können Talent nicht durch Schulung „erzeugen“. Was Sie jedoch tun können: Talent in ganz normalen Leuten finden, hervorholen und stärken.

Zusammenfassung

In diesem Blogeintrag habe ich über sechs grundlegende Fähigkeiten einer Softwarefirma gesprochen: Kunden finden, verkaufen, Wert schaffen, lernen, managen und Mitarbeiter entwickeln. Alle erfolgreichen Firmen, die ich getroffen habe, hatten alle diese Eigenschaften ausgebildet. Deshalb meine ich, diese sind essenziell, um eine Softwarefirma zu sein.

Was meinen Sie dazu? Diskutieren Sie mit! Benutzen Sie die Kommentarfunktion unterhalb dieses Artikels!

1. Steven G. Blank: The Four Steps to the Epiphany: Successful Strategies for Startups That Win, K&S Ranch (Februar 2005), ISBN 978-0976470700 ↩

Diese Beiträge könnten Sie noch interessieren:

• Drei Fragen zu Ihrer Produktstrategie
• Geschäftsmodelle für Ihre Softwarefirma
• Relative Feature-Bewertung
• Coaching
• Qualitätsanforderungen agil managen

Wenn Sie eine Softwarefirma erfolgreich machen wollen, brauchen Sie unter anderem ein Geschäftsmodell. Es beantwortet in vereinfachter Form die folgenden Fragen:

1. Welchen Wert stiftet diese Firma, für ihre Kunden und für die strategischen Partner?
2. Wie macht die Firma das? Welche Produkte oder Dienstleistungen bietet sie an?
3. Wodurch verdient die Firma Geld? Wie kommt es, dass Ihr Kunde für den Wert bezahlt, den Ihre Firma für ihn erzeugt?

Wert stiften

Deshalb zuerst zu der Frage: Was ist Wert? Wenn Ihr Kunde ein Produkt oder eine Dienstleistung bei Ihrer Firma kauft, dann tut er das, weil er sich etwas davon verspricht. Er hat einen Grund, eine Motivation dafür. Er möchte seine Prozesse automatisieren, mehr Kunden bedienen können, sein unternehmerisches Risiko senken oder vieles andere mehr. Meist lässt sich die Motivation auf drei monetäre Hauptziele zurückführen:

1. Neue Einnahmen erzielen
2. Existierende Einnahmen sicherstellen und schützen
3. Kosten sparen

Ihr Kunde kann mit Hilfe Ihrer Software neue Einnahmen erzielen, wenn er beispielsweise selbst zusätzliche Märkte bedient, mehr Produkte verkauft, mehr neue Kunden erreicht oder seinen Mitbewerbern Kunden abjagt.

Ihr Kunde muss natürlich darauf achten, dass seine Wettbewerber dasselbe nicht mit ihm selbst machen. Er kann Einnahmen, die er jetzt schon bekommt, schützen und weiter sicherstellen, indem er z.B. mit Hilfe Ihrer Software die Qualität seiner eigenen Leistungen so verbessert, so dass die Konkurrenz ihm keine Kunden abwerben kann, weil diese so begeistert sind.

Die Optionen 1 und 2 dienten dazu, das Ergebnis „über dem Strich“ zu vergrößern. Sie können Ihrem Kunden aber auch helfen, das Ergebnis „unter dem Strich“ zu vergrößern, indem Sie ihm Möglichkeiten zur Kosteneinsparung anbieten. Wenn Ihr Kunde einige Jahre im Geschäft ist, wird er versuchen, diejenigen Leistungen billiger zu machen, die an Attraktivität verloren haben. Er könnte diese Leistungen beispielsweise mit Hilfe Ihrer Software automatisieren und sich dann darauf konzentrieren, neue Leistungen anzubieten, die er teurer verkaufen kann.

Insgesamt: Wert besteht darin, dass Sie mit Ihren Produkten und Leistungen dem Kunden helfen, die drei oben genannten Hauptziele zu erreichen: Neue Einnahmen zu erzielen, existierende Einnahmen sicherzustellen und zu schützen sowie Kosten einzusparen.

Wert anbieten

Mit Ihrer Firma haben Sie sicherlich eine Idee, welches Angebot Sie dem Kunden machen wollen, mit dem der Wert gestiftet werden soll. Wollen Sie ihm ein Produkt anbieten, das er einsetzt? Oder führen Sie für ihn ein Projekt durch? Haben Sie mit Ihrem Kunden einen Wartungsvertrag, z.B. für Erweiterungen eines bestehen Systems oder für die Fehlerbehebung? Auch Schulungen in der Nutzung eines Systems oder in der Programmierung von Erweiterungen zu einem System können einen solchen Wert schaffen.

Produkt

Fangen wir beim Produkt an. Ihre Firma könnte eine Software entwickeln und den Kunden auf unterschiedliche Arten zur Verfügung stellen, die jeweils auch den Ertrag auf verschiedene Weise erbringen.

Lizenzen verkaufen

Der Klassiker ist sicherlich der Verkauf von Lizenzen für die Nutzung einer Software beim Kunden. Der Kunde bekommt ein Recht, Ihre Software zu benutzen und bezahlt dafür Lizenzgebühren, einmalig bei der Erstinstallation und später bei jedem Upgrade. Die Software wird beim Kunden installiert, er macht sie seinen Mitarbeitern zugänglich. Er muss auch die dafür nötige IT-Infrastruktur (Hardware, Betriebssystem, Datenbank etc.) bereitstellen und betreiben. Die Software wird hierbei von einem Unternehmen genutzt – sie ist nicht öffentlich im Internet zugreifbar. Beispiele für diese Art der Ertragsgewinnung sind Standardsoftware-Pakete wie Microsoft Office oder mobile Applikationen wie die im Apple AppStore.

Mitgliedsgebühr einnehmen

Sie können mit Ihrer Software auch eine Plattform bieten, die von Ihren Kunden genutzt wird. Der Kunde installiert die Software nicht, sondern benutzt sie im World Wide Web. Er bezahlt in diesem Falle dafür, Mitglied der Plattform zu sein. Beispiele hierfür sind das Geschäftsleutenetzwerk Xing, die Blogging-Plattform WordPress oder das Projektmanagement-Werkzeug Basecamp. Die Gebühr ist unabhängig davon, was der Kunde auf der Plattform tut oder wie viele Transaktionen er durchführt.

Transaktionen verkaufen

Bei dieser Variante benutzt der Kunde Ihre Software, um Transaktionen durchzuführen. Beispielsweise könnte er Event-Tickets verkaufen wie bei Amiando, Börsenhandel betreiben wie bei Interactive Brokers oder Auktionen einstellen wie bei eBay.

API anbieten

Damit die Kunden Ihre Software besser und intensiver nutzen, können Sie ein API (application programming interface) zur Verfügung stellen, also eine Programmierschnittstelle, die die Leistungen Ihrer Software aufrufbar macht. Das könnte die Anzahl der Transaktionen steigern oder mehr Mitglieder auf eine Plattform bringen, weil der Nutzen der Plattform durch die Automatisierung der Vorgänge ansteigt.

Projektarbeit

Im Gegensatz zu einem Produkt, an dem Ihre Firma ständig weitere Verbesserungen vornimmt, ist ein Projekt typischerweise ein einmaliges Vorhaben. Die Qualitätsnorm EN ISO 9000 definiert ein Projekt so:
„Ein Projekt ist ein einmaliges Vorhaben, das aus einem Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit und Ressourcen (zum Beispiel Geld bzw. Kosten) ein Ziel zu erreichen.“
Ihre Firma kann dem Kunden helfen, ein Projekt durchzuführen und dadurch sein Ziel zu erreichen, nämlich in der Regel ein funktionsfähiges Softwaresystem, das er anschließend erfolgreich betreibt und in seine Geschäftsprozesse integriert.

Auftragsentwicklung

Bei einer Auftragsentwicklung übernimmt Ihre Firma die Rolle der Entwicklungsorganisation. Sie arbeiten mit dem Kunden aus, worin der Nutzen des Systems bestehen soll, welche Fähigkeiten das System deshalb braucht und welche Funktionen diese Fähigkeiten realisieren. Ihre Mitarbeiter schreiben den Code, der die Funktionen lauffähig darstellt, machen ihn testbar und stellen das System dem Kunden regelmäßig zur Inspektion zur Verfügung.

Implementierung eines Produktes

Es gibt auch Projekte zur Implementierung eines Produktes. „Implementierung“ bedeutet hier, das Produkt beim Kunden zu installieren, in seine Systemlandschaft zu integrieren und nötigenfalls an seine Daten und Prozesse anzupassen. Ihre Firma könnte das Produkt bereits entwickelt haben (vgl. den Abschnitt über Produkt/Lizenzen verkaufen) und es nun noch für den Kunden spezifisch anpassen, so dass es bei ihm „rund“ läuft.

Wartung

Wenn Ihre Firma für den Kunden ein Produkt in Betrieb genommen hat (sei es in Lizenz oder als Auftragsentwicklung), können Sie dem Kunden einen anderen Wert anbieten: Erweiterungen und Fehlerbehebung.

Erweiterungen

Erweiterungen sind dazu gedacht, Anforderungen zu befriedigen, die erst nach erster Fertigstellung des Produktes entstehen. Die folgenden Situationen können Wünsche für Erweiterungen entstehen lassen:

• Benutzer haben erste Erfahrungen mit dem System gemacht und haben Ideen, wie man dem System weitere Fähigkeiten oder Funktionen hinzufügen könnte.
• Die Administratoren haben das System eine Zeitlang betrieben und wissen nun, welche Teile der betrieblichen Prozesse man noch besser automatisieren könnte.
• Die Stakeholder im Business haben gesehen, welchen Wert das System dadurch schaffen könnte, dass man es noch mit anderen, wertschaffenden Systemen verknüpft.

Was auch immer der Anlass war: Sie können durch Erweiterungen Wert schaffen, den der Kunde als Auftragsentwicklung bezahlt.

Fehlerbehebung

Auch die Fehlerbehebung schafft Wert. Komplexe Systeme sind beim heutigen Stand der Technik (und der Menschen) niemals fehlerfrei, deshalb hilft es den Benutzern, wenn Sie die Fehler finden und beseitigen. Der Kunde bezahlt dafür Wartungsgebühren, in der Regel in festen Zeiträumen, beispielsweise monatlich, quartalsweise oder jährlich. Es ist üblich, dass Sie dem Kunden eine bestimmte Art von Service bieten und diesen garantieren. Kritische Fehler, bei denen die Produktion steht, müssen anders behandelt werden als wenn eine Schaltfläche auf dem Bildschirm die falsche Farbe hat.

Schulung

Schulungen können die Einführung eines Systems erleichtern, neue Benutzer an ein existierendes System heranführen oder Kundenmitarbeitern beibringen, wie sie das API des Systems nutzen, um betriebliche Abläufe selbst zu automatisieren.

Nutzerschulungen

Schulungen für die Nutzung eines Systems ersparen in der Praxis Missverständnisse, der geschaffene Wert ist also Kostenersparnis. Wenn Ihre Firma ein Produkt entwickelt har, das regelmäßig bei Kunden eingeführt werden muss, können Sie gleich einen Ausbildungsplan und Schulungsunterlagen dazu entwerfen, die Sie den Mitarbeitern des Kunden innerhalb der Schulungen zur Verfügung stellen.

Programmierschulungen

Wenn Ihr Produkt ein API besitzt, können Sie auch Schulungen entwerfen, die den Mitarbeitern des Kunden zeigen, wie sie das API möglichst effektiv nutzen. Das erspart dem Kunden Zeit, wenn er in einer Schulung Beispiele sieht und Übungen durchführt anstatt sich stundenlang durch API-Dokumentation zu kämpfen.

Diskutieren Sie mit!

Welche Geschäftsmodelle kennen Sie noch, die hier nicht aufgeführt sind? Welchen Wert stellen diese zur Verfügung und durch welches Angebot? Kommentieren Sie diesen Beitrag und diskutieren Sie mit!

 Diese Beiträge könnten Sie noch interessieren:

• Drei Fragen zu Ihrer Produktstrategie
• Essenzielle Fähigkeiten einer Softwarefirma
• Relative Feature-Bewertung
• Wo ist denn nur der Kunde inzwischen?
• Qualitätsanforderungen agil managen

Um die Chance auf Erfolg beim Delegieren zu erhöhen, können Sie diese Checkliste anwenden, die auf das Buch Behind Closed Doors von Johanna Rothman und Esther Derby zurückgeht und von Jurgen Appelo angereichert wurde:

1. Ist das Risiko, diese Arbeit zu delegieren, angemessen betrachtet worden?
2. Haben Sie überlegt, mit wie viel Autorität Sie delegieren wollen? Sprich: Delegieren Sie per Befehl, per “Verkaufen”, per Beraten, per Bestätigung, per freier Überlassung?
3. Haben Sie nachgedacht, ob Sie an ein Team oder eine Einzelperson delegieren wollen?
4. Haben Sie herausgefunden, ob es besser ist, diese Arbeit zu delegieren anstatt einer anderen?
5. Handelt es sich bei dem, was Sie delegieren, um ein definiertes Stück Arbeit?
6. Haben die Leute die Fähigkeiten, um diese spezielle Arbeit zu tun?
7. Haben die Leute die richtigen Werkzeuge, um bei dieser Arbeit erfolgreich zu sein?
8. Wissen die Leute, wie das Ergebnis aussehen soll?
9. Haben Sie die Randbedingungen für diese Arbeit gesetzt (z.B. Budget, Zeit, Ressourcen, Qualität?)
10. Wissen die Leute, wann die Arbeit fertig sein soll?
11. Wissen die Leute, wie Fortschritt bei dieser Arbeit aussieht?
12. Wissen die Leute, wie oft sie Ihnen über den Fortschritt berichten sollen?
13. Steht jemand als Coach oder Mentor zur Verfügung, im Fall dass die Leute Hilfe brauchen?

Wenn Sie auf alle Fragen mit “ja” oder “unzutreffende Frage” antworten können, ist alles gut. Wenn Sie auf ein “nein” als Antwort kommen, besprechen Sie es offen mit Ihren Leuten und finden Sie gemeinsam einen Weg, zurechtzukommen. Vielleicht kann man die fehlenden Bedingungen doch noch erfüllen und kommt zu einem guten Ergebnis.

Achso: Lesen Sie das Buch und Jurgens Blog-Einträge – es lohnt sich!Diese Beiträge könnten Sie noch interessieren:

• Comics für seltsame Leute
• Einkauf von geistigem Rohstoff
• Führung, Motivation, Produktivität [OOP 2010]
• Danke für 2011, hallo 2012!
• Kanban-Missverständnisse, Teil 2

Am 28./29. Februar gebe ich wieder mein Seminar “Flow in der Produktentwicklung”. Hier ein Auszug aus der Seminarbeschreibung:

Heute stehen für das Management von Produktentwicklungen (z.B. für die Software- und Systementwicklung) bessere Methoden zur Verfügung als noch vor wenigen Jahren. In diesem Kurs geht es um “Flow”, das gleichmäßige Fließen von Arbeit durch das Projektteam, bis alles beim Kunden als getestetes, funktionsfähiges Produkt ankommt.

“Flow” zu managen ist eine fundamental andere Art, als Zeit zu managen: Der Wertstrom in der Entwicklung steht im Vordergrund, nicht mehr das möglichst genaue Einhalten eines früh und unter großer Unsicherheit entstandenen Zeitplans. Das hat dramatische Auswirkungen auf das Leben in der Entwicklung: Die Menschen sind entspannter, gleichzeitig fokussierter, und Arbeit geht leichter von der Hand.

Mehr Information zu Inhalt, Zielgruppe und zur Anmeldung finden Sie auf der Seminarseite.Diese Beiträge könnten Sie noch interessieren:

• Flow in der Produktentwicklung
• W-JAX 2011: Flow und Risikomanagement
• WJAX 2011: Flow in der Arbeit – Flow im Team
• Produktentwicklung
• Wo ist denn nur der Kunde inzwischen?

Flow herrscht in der Arbeit, wenn Bedarf und Lieferfähigkeit gegeneinander ausbalanciert sind, z. B. durch den Einsatz von Lean-Verfahren in der Produktentwicklung. Flow gibt es auch in der Psyche, wenn vom Einzelnen soviel gefordert wird, wie er auch leisten kann. Im Flow-Zustand entstehen die besten Ergebnisse, die Arbeit ist angenehm, man vergisst die Zeit. Dass man für Flow im Sinne von „Lean Product Development” dasselbe Wort verwendet wie in der Psycholo­gie, ist nach meiner Ansicht kein Zufall. In diesem Artikel geht es darum, die Beziehung zwischen Flow in Lean und Flow in der Psyche herzustellen und zu erforschen.

Lesen Sie den Artikel auch online.Diese Beiträge könnten Sie noch interessieren:

• Flow in Lean, Flow im Team
• WJAX 2011: Flow in der Arbeit – Flow im Team
• OOP 2012: Flow in Lean, Flow im Team
• W-JAX 2011: Flow und Risikomanagement
• Lean/Kanban 2011 Benelux in Antwerpen

In diesen Tagen fiel mir eine seine Zeichnungen besonders auf, als ich über das Thema Veränderung von Menschen in Organisationen nachdachte. Der Slogan lautet in etwa “Du kannst das Etikett auf der Dose, in der Du steckst, nicht lesen!”

Er erinnert uns daran, dass wir (egal, was wir denken) immer in einer bestimmten Denk-Dose stecken und uns unserer Annahmen, die wir machen, nicht bewusst sind. Wenn wir miteinander sprechen, sollten wir uns gelegentlich nach den Annahmen fragen, die wir gerade machen und diese miteinander teilen.

Diese Beiträge könnten Sie noch interessieren:

• XPDays 2011: Ein Team und seine Verträge
• Leader entwickeln
• Halt die Schlange kurz!
• Vorstellung auf Javanisch
• Produktentwicklung führt zu Flow

1. Warum?
2. Was?
3. Wie?
4. Wohin noch?

Warum ist es besonders gut, diesen oder jenen Artikel zu schreiben, Vortrag vorzubereiten, Podcast aufzunehmen, Methodik für den Kunden auszuarbeiten oder was auch immer? Das “warum” bringt mich auf die Erde, an die Wurzel der Dinge.

Was muss ich dafür tun? Welche Schritte sind erforderlich? Welche Ressourcen brauche ich dafür? Fakten, Kontakte zu anderen Menschen, Ort, Zeit, Werkzeuge und vieles andere.

Wie geht das konkret? In welcher Zeit kann ich wieviel Wert schaffen? Will ich die perfekte Lösung oder reicht eine erste Version von dem, was mir vorschwebt? Hängen die Schritte voneinander ab, brauche ich also eine Reihenfolge? Kann ich es vielleicht so machen, dass einmal Nachdenken reicht, um ein Konzept zu finden, das meinen Kunden immer wieder, an verschiedenen Stellen und in verschiedener Form, helfen kann?

Wohin bringt mich das Thema noch, wenn ich es z.B. zwei Jahre weiterverfolge? Soll es dann (aus heutiger Sicht) noch vorhanden sein? Ist es also etwas Strategisches oder eher etwas Kurzfristiges, was ich da vorhabe? Gehört es zu der Vision von mir oder geschieht es mehr nebenbei?

Mit diesen vier Fragen können Sie in Ihrer Planung die Themen auf den Punkt bringen. Seien es Eigenschaften für Ihr neues Produkt, für Ihren neuen Service, für Veränderungen in Ihrer Abteilung, was auch immer Sie vorhaben – die vier Fragen helfen Ihnen, sich darüber klar zu werden. Viel Erfolg dabei!Diese Beiträge könnten Sie noch interessieren:

• Drei Fragen zu Ihrer Produktstrategie
• Mit TDD schreibt man Spezifikationen
• Coaching
• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Mitarbeiter mit Lean-Erfahrung einstellen

• This blog is now iPhone-ready!
• MBCalendar
• How to become a hacker
• Shopping list for Enterprise Architects
• Parallels on the Mac: Where is my Insert key?

Der Abteilungsleiter plante allerdings die Change Requests anhand von Schätzungen auf einem Zeitstrahl und ordnete sie den verfügbaren Entwicklern in seiner Abteilung zu, zeitlich möglichst dicht an dicht gepackt, um die verfügbare Kapazität gut zu nutzen. Wenn ein Entwickler frei wird, bekommt er ein neues Change Request zugeteilt. Der Abteilungsleiter wusste, dass Dinge manchmal etwas länger dauern und rechnete deshalb 25% Pufferzeit hinzu, bevor er den Kunden versprach, welche Change Requests wahrscheinlich im nächsten Release umgesetzt sein würden. Seine Annahme war anscheinend: je besser die Leute ausgelastet sind, desto höher der Durchsatz, desto höher die Einnahmen der Abteilung.

Aus Sicht des Durchsatzes eine schlechte Idee! Ich sagte ihm, er solle doch die Aufträge an seine Leute nicht so dicht packen und stattdessen kleine Puffer lassen, um zu vermeiden, dass sich Warteschlangen auf den Schreibtischen bilden. Jeder Mitarbeiter, der frei wird, soll sich am besten selbst seinen nächsten Auftrag holen (Pull-Systeme wie Kanban tun genau das). Er tolerierte durch die hohe Auslastung implizit, dass teilweise fertige Arbeit Zeit in Warteschlangen verbringt und Geld kostet, weil die Menschen inzwischen vergessen, was sie getan haben, Fehler verursachen und dann die Arbeit zum Teil noch einmal tun müssen.

Die mathematischen Gesetzmäßigkeiten hinter diesem Problem sind interessant. Es gibt nämlich einen stark nichtlinearen Zusammenhang zwischen Auslastung der Leute und der Bildung von Warteschlangen. Nehmen wir an, jemand schafft 10 Dinge im Monat. Wenn man ihm 8 Dinge pro Monat gibt, ist er zu 80% ausgelastet. Wenn man nun etwas von ihm will, ist die Wahrscheinlichkeit, dass er es sofort tun kann, nur 20%. In 80% aller Fälle wird er die neue Arbeit zunächst in eine Warteschlange legen und später erledigen.

In der Warteschlangentheorie bezeichnet man die Ankunftsrate neuer Arbeit mit dem griechischen Buchstaben , die Servicerate für existierende Arbeit mit dem Buchstaben . Den Quotienten, die Auslastung, bezeichnet man mit :

Die Länge der Warteschlange ergibt sich dann als Funktion der Auslastung der Leute (Formel von Allen-Cunneen):

Die beiden Koeffizienten C sind die Schwankungen in der Ankunftsrate und der Servicerate. Sie liegen zwischen 0 und 1 und ergeben sich durch Division der Standardabweichung durch den Mittelwert. Im Umfeld der Softwareentwicklung kann man beide Schwankungen getrost mit 1 (also 100%) annehmen (das entspricht einer Exponentialverteilung).

Der Abteilungsleiter, der versucht, seine Leute zu 100% auszulasten und die Verzögerungen durch einen großen Puffer auszugleichen, tut sich aus Sicht von Flow keinen Gefallen: Es bilden sich lange Warteschlangen zwischen den Mitarbeitern, die gar nicht sein müssten. Beispiel: Wenn ein Mitarbeiter zu 95% ausgelastet ist, ist seine Warteschlange 8 bis 9mal so lang wie bei jemandem, der zu 75% ausgelastet ist. Und: Die Länge der Warteschlange schwankt bei einem zu 95% ausgelasteten Mitarbeiter 25mal so stark  wie bei einem 75% ausgelasteten Mitarbeiter! Kein Wunder, dass der Abteilungsleiter ständig Probleme hatte, seine versprochenen Termine einzuhalten.

Also: Mitarbeiter am besten nur so hoch auslasten, dass sich keine Warteschlangen bilden. Am einfachsten geht das so: Die Warteschlangenlänge rigoros begrenzen (z.B. mit Hilfe eines Kanban-Systems) und die Mitarbeiter verpflichten, selbst dafür zu sorgen, dass ihre fertige Arbeit zuerst weitergereicht oder ausgeliefert wird, bevor sie neue Arbeit angehen. Das reduziert die Auslastung, doch spart es Kosten für Warteschlangen und macht den Kunden zufriedener, weil die versprochenen Termine aufgrund der geringeren Schwankungen leichter eingehalten werden können.

Insgesamt könnte der Abteilungsleiter damit günstiger arbeiten und mit seinen Leuten mehr Geld verdienen als zuvor.

P.S.: Solche Dinge lernen Sie in meinem Flow-Seminar. In 2012 gibt es dafür wieder neue Termine.Diese Beiträge könnten Sie noch interessieren:

• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Halt die Schlange kurz!
• Danke für 2011, hallo 2012!
• Delegieren wie ein echter “Leader”
• XPDays 2011: Ein Team und seine Verträge

“Erzählen Sie mir über einen Moment, in dem Sie gemerkt haben, dass Sie an zu vielen Dingen gleichzeitig arbeiten. Woran haben Sie das erkannt?” (Pause und auf Antwort warten.) “Gab es dabei eine Tafel oder einen anderen Visualisierungsmechanismus?” (Pause.) “War das eine Einzelaktion oder waren Sie Teil eines Teams?” … “Was haben Sie getan?” (und noch einige mehr, lesen Sie selbst).

Johanna kann das richtig gut: Einfache Fragen formulieren, aus deren Antworten man viel lernen kann! Ich bin gespannt, Johanna auf der OOP 2012 zu treffen.Diese Beiträge könnten Sie noch interessieren:

• Delegieren wie ein echter “Leader”
• Transparente Arbeit
• Physische Kanban-Tafel – warum?
• Mitarbeiter hoch auslasten – ist das ökonomisch?
• Vier Fragen für das Neue Jahr

Es ist viele Jahre her, seit ich diesen Text gelesen habe und habe es jetzt (mit meinem heutigen Erfahrungsstand) noch einmal gelesen. Siehe da: Ich kann sagen, dass ich das Wort Wasserfallmodell ebenfalls nicht mehr benutzen werde, weil es die Intention des Papiers meines Erachtens unzutreffend reduziert. Ich finde Royces Modell zwar trotzdem in vielen Kontexten unangemessen, doch Wasserfall werde ich es nicht mehr nennen.

Lesen Sie’s doch auch (noch einmal) und kommentieren Sie hier, was Sie davon halten. Hat sich in Ihrer Wahrnehmung des Themas nach dem Lesen etwas verändert?Diese Beiträge könnten Sie noch interessieren:

• Kein Vodafone UMTS nach Mac Update?
• VHS auf bilinguale DVD
• Präzise Ausdrucksweise
• Inhaltsorientiert führen – die “Möglichmacher”
• Wo ist denn nur der Kunde inzwischen?

Ich tue es, weil ich eine bestimmte Leidenschaft habe: Produktentwicklung zu einer mitreißenden und effizienten Aktivität zu machen. Jeder sollte sich einbezogen und beteiligt fühlen und sich täglich verbessern. Indem alle das tun, tragen sie zum Erfolg der gesamten Organisation bei. Um dieser Vision näherzukommen, verwende ich Techniken aus Agile und Lean, bei denen Individuen und Teams im Mittelpunkt stehen.

In Japan sagt man: Muri erzeugt Mura erzeugt Muda, also: Überlastung erzeugt Unausgeglichenheit erzeugt Verschwendung. Das habe ich in der Produktentwicklung immer wieder beobachten können, vom ersten Tag an als Entwickler, später als Consultant, dann als Manager. Als gemeinsame Ursache stellt sich immer wieder Muchi, die Unwissenheit, heraus.

Meine Philosophie als Coach: Muchi auflösen, indem Stakeholder, Teams und Manager sich ihrer eigenen Fähigkeiten bewusst werden und die Entwicklung zum Fließen bringen. Muri, Mura und Muda werden unnötig und verschwinden. Der Kunde freut sich, weil er hohe Qualität und hohen Wert bekommt. Die Mitarbeiter haben angenehme Arbeitsbedingungen, sie können sich zu Meistern ihres Fachs entwickeln und sich an den Ergebnissen freuen, die sie erzeugen.

Auf dem Weg dorthin erreichen Sie dramatische Verbesserungen:

• Wissen und Bewusstsein: Sich selbst, seine Arbeit und seine Stärken gut zu kennen vereinfacht die Planung und macht Versprechen an den Kunden verlässlicher. Muchi verschwindet.
• Sinnvolle Auslastung, sinnvolle Prozesse:  Zufriedene Mitarbeiter, die unter guten und vernünftigen Bedingungen arbeiten, zeigen sinnvolles Verhalten. Muri verschwindet.
• Gleichmäßiger Fluss: Voraussagbarkeit und Verlässlichkeit stellen sich ein, je gleichmäßiger die Arbeit durch die Teams fließt. Mura verschwindet.
• Wertfokussierung: Der für den Kunden erzeugte Wert wird zum Hauptziel. Profit und positives Wachstum des Unternehmens und der Leute werden gefördert. Muda verschwindet.

Diese Verbesserungen konnte ich in diesem Jahr bei Ihnen beobachten, die Sie mit mir zusammengearbeitet haben. Es fasziniert mich jedes Mal aufs Neue, und ich möchte mich bei Ihnen dafür bedanken, denn auch ich lerne von Ihnen allen: Stakeholder, Teams, Manager, wer es auch sei.

Ich wünsche Ihnen allen viel Erfolg bei dem, was Sie sich vorgenommen haben und freue mich auf die weitere Zusammenarbeit mit Ihnen in 2012!Diese Beiträge könnten Sie noch interessieren:

• Produktivität
• Alles eine Frage der Blickrichtung
• Gute Teams wieder aufwecken
• Vier Fragen für das Neue Jahr
• Kontinuierlich besser werden

Das Jahr beginnt mit einem Flow-Vortrag auf der OOP in München, geht weiter mit zwei Seminaren zu Flow und Kanban, dann kommen Vorträge über Schätzkultur und Risikomanagement auf der  JAX in Mainz.

Die Seminare zu Flow und Kanban werden sehr spannend werden, denn immer mehr Mosaiksteine aus neuen Wissensgebieten fügen sich in das Bild der existierenden Erkenntnisse ein und machen den Stoff noch wertvoller für Sie als Teilnehmer.

Ich freue mich darauf, Sie in 2012 wiederzusehen. Die aktuellen Termine finden Sie wie immer auf meiner Kalenderseite.

P.S.: Lesen Sie mal wieder OBJEKTspektrum – da finden Sie neue Artikel von mir!Diese Beiträge könnten Sie noch interessieren:

• W-JAX 2011: Flow und Risikomanagement
• Schulungen
• Kalender
• Lean/Kanban 2011 Benelux in Antwerpen
• Kanban Workshop in Köln

• Danke für 2011, hallo 2012!
• Cumulative Flow Diagram zeichnen in Excel
• XPDays 2011: Ein Team und seine Verträge
• Premierminister, werde agil!
• Papier schlägt Elektronik

• Coaching
• Liefern schon vor dem Schätzen
• Im Flow arbeiten! Der Kunde wird es danken!
• Drei Fragen zu Ihrer Produktstrategie
• Geschäftsmodelle für Ihre Softwarefirma

Flow in der Arbeit – Flow im Team

Flow herrscht in der Arbeit, wenn Bedarf und Können gegeneinander ausbalanciert sind (z.B. in Kanban). Flow gibt es auch in der Psyche, wenn vom Einzelnen soviel gefordert wird wie er/sie auch leisten kann. Im Flow-Zustand entstehen die besten Ergebnisse, die Arbeit ist angenehm, man vergisst die Zeit. Matthias Bohlen zeigt, wer Sie sein können, wenn Sie Flow im Team entstehen lassen.

Zeit und Ort: 07.11.2011 | 13:30 – 14:15 | München, Westin Grand, Ballsaal A

Risikomanagement in Kanban

Termin verpasst? Software zu spät geliefert? Kein Geschäft mehr zu machen? Das ist das eine Extrem. Oder ist es bei Ihnen genau andersherum: Alle Termine gehalten, immer pünktlich geliefert, doch dafür Teams im Stress und Qualität/Architektur im Keller? Im Vortrag lernen Sie, solche Risiken mit dem “Classes of Service”-Konzept in Kanban zu managen und die Arbeit für Ihr Team angenehm zu gestalten.

Zeit und Ort: 08.11.2011 | 18:15 – 19:15 | München, Westin Grand, Raum Lillehammer

Diese Beiträge könnten Sie noch interessieren:

• WJAX 11: Risikomanagement mit Kanban
• WJAX 2011: Flow in der Arbeit – Flow im Team
• OOP 2012: Flow in Lean, Flow im Team
• Kalender
• Flow in Lean, Flow im Team

1) In welchem ​​Markt verkaufen Sie Ihre Produkte? Ist er riskant, ist es kaum vorhersehbar, was mit dem Produkt passieren wird? Oder ist es ein langweiliger Markt, in dem das Risiko gering, weil alles bekannt ist? Spielt diese Frage für Ihre Prozesse und Richtlinien eine Rolle oder verhält sich Ihre Organisation identisch für beide Arten von Märkten?

2) Welche Arten von Produktfeatures entwickeln Sie für Ihre Kunden? Sind es Basisfeatures, bei denen Ihr Kunde sich ärgert, wenn er sie vermisst, aber sich nicht freut, wenn er sie findet? Oder entwickeln Sie spannende Funktionen, von denen Ihr Kunde gar nicht glaubte, sie seien überhaupt möglich? In diesem Fall wird Ihr Kunde sich freuen, diese Features zu sehen, aber sich neutral fühlen, wenn er sie nicht findet. In welche Art von Features investieren Sie welche Art von Arbeit (z.B. automatisierte Tests, User Experience Design-Arbeit)? Wie planen Sie angesichts dieses Wissens Ihre Releases? Oder denken Sie einfach, alle Features seien gleich?

3) Wie dringend sind die Features, die Sie entwickeln? Was sagt der Kunde: Wird sein Geschäft darunter leiden, wenn ein oder zwei Features zu spät kommen? Welche sind wirklich dringend aufgrund von rechtlichen Änderungen, Änderungen bei Partnern (z.B. Kreditkarten-Providern), wichtigen Kalenderdaten (Messen, Weihnachten)? Welche können warten, sollte aber nicht ewig warten (Datenbank-Upgrade auf eine neuere Version, die Weitergabe von kritischen Programmierkenntnissen in COBOL)?

Was auch immer Ihre Antworten sind auf diese drei Fragen: Machen Sie einen Unterschied, der einen Unterschied macht! Behandeln Sie nicht alles gleich. Märkte unterscheiden sich, Kriterien für die Kundenzufriedenheit sind jedesmal andere, Dringlichkeit bedeutet für jeden Kunden etwas anderes. Warum sollte Ihre Produkt-Entwicklungsstrategie alles gleich behandeln? Sie können mehr Wert für Ihre Kunden schaffen und mehr Geld in der gleichen Zeit verdienen, wenn Sie unterschiedliche Dinge auch unterschiedlich bearbeiten und berechnen.Diese Beiträge könnten Sie noch interessieren:

• Coaching
• Verhüten oder bekämpfen?
• Schlanke Zeiten [OOP 2010]
• Essenzielle Fähigkeiten einer Softwarefirma
• Alles eine Frage der Blickrichtung