From the scrum guide:

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

A platonic dialogue on agile leadership

We have a fundamental change upcoming (like the move to more agility or the introduction of a system-wide Definition of Done).

What do we do?

Ownership

Agile Leader: What if we get everyone in a big room & come up with a vision and steps for this to together?

Traditional Leader: Ouch! Imagine all the billable hours of the people just talking! I think we need to make a clear proposal in a small group and ask everyone in the company meeting, if they have any objections.

Agile Leader: Hm, but then not everyone will have spent effort in defining the steps. They will not own it. Consider this piece of wisdom:

.. But my rose, all on her own, is more important than all of you together, since she’s the one I’ve watered. Since she’s the one I put under glass, since she’s the one I sheltered behind the screen. Since she’s the one for whom I killed the caterpillars (except the two or three butterflies). Since she’s the one I listened to when she complained, or when she boasted, or even sometimes when she said nothing at all. Since she’s my rose.

Le pètit prince, Antoine de Saint-Exupéry

Will we sustain our change like we would water and care for our rose together, if leadership had just presented a solution in the company meeting?

Traditional Leader: Ok, I see your point. Would be nice to try. However I have one more objection:

Group Convergence

Traditional Leader: Can large groups converge or are they only good for divergence? I hate all those futile discussions in groups.

Agile Leader: This question has been driving facilitators for decades.  Divergence is the airing of different perspectives and options. Convergence is the integration of some, elimination of others in the service of one next idea everyone supports.

Between divergence and convergence the gods have put the groan zone. Yes it’s painful. But getting people together will just get the real pain out faster, provided we do converge and don’t get stuck. Groups need help and good facilitation to get over the groan-zone and into convergence and action.

See Samuel Kaner: „Facilitator’s Guide To Participatory Decision Making„.

New communication patterns to help group convergence have been showing up since the 60s. Today these are hitting the mainstream and are being implemented in the companies that will disrupt tomorrow.

Look into Open Space Technology or the newer Liberating Structures. Also check out Systemisches Konsensieren – a method originating in Germany and finding more and more followers.

Go check your local MeetUp Directory. Having experienced one of these might give you a new perspective.

Traditional Leader: Don’t let yourself be interrupted. You’re sounding beautiful..

The double diamond

Agile Leader: There is still one more point regarding the diamond of divergence & convergence in groups, that Design Thinking has to offer to us.

We will get much better results if we invite groups to diverge and converge separately on the problem and solution space.

Consider: Most complex changes are ambiguous in both spaces (E.g. What do we want to achieve next year – time2market down? quality up?, adaptivity up? –  and what should we try next quarter to get there (Start implementing proper Kanban? Deepen our crappy scrum in one or two teams?, try LeSS for 4 teams? Gradually migrate 4 teams to feature-teams?)

Designers speak about the double diamond.

First diverge on the exact question, then converge on a question/problem to solve.

Then diverge on solution approaches. Finally converge on those. Finally move to action and validate in cycles. It looks like this:

Traditional Leader: I admire your eloquence you beautiful one..  I have to run. Got the next board meeting coming up..

Agile Leader: As an intermediate organizational development step we could converge on the problem definition in a small strategic circle and invite a large group to own the solution space. What do you think?

Traditional Leader (one the way to next meeting): Sure. You’re great. Keep you’re ideas flowing..

Team: We don’t really have anything interesting to show tomorrow. We suggest to cancel the review for this sprint.

Scrum Master <insecurely insisting> If we’re doing scrum, we must show what we completed last sprint and at least try to deliver a good review. For example we could also be talking about our problems in the review and looking at options for the next sprint, right?

Team<irritated> We have no big problems to mention. We just don’t have anything interesting to show right now.  We just want to be pragmatic now & cancel the meeting since it doesn’t make sense right now. Please let us do our work!

You might be thinking: Right, the Scrum Master is suggesting to do Scrum by the Book  while the team is somehow resisting and drifting along with ScrumBut.

But what could be the context in today’s ubiquitous & poor scrum-adoptions? Consider for example these fairly typical scenarios:

• The product is designed outside of scrum. Specialized UX experts define it using prototypes. All of this takes place outside the team. For the typical review only non-empowered representatives show up and nod at seeing the prefabricated design now working in code.
  How should the team truly engage in reviews? Decisions have been made elsewhere. Why not cancel the review – just for tomorrow?
• An enterprise architecture department has devised a solution-path that entails large packages of work to be completed before the feature can be started. How should the team deliver customer-centric features now? For this reason the backlog items presented during the last review-meetings sounded so technical to stakeholders that they stopped showing up.Why not cancel the review – just for tomorrow?
• The team is hit by a large list of bugs. The underlying phased development process is still in place and the test-department has been testing the whole low quality product during last sprint. So now bugs are pouring in swamping any tangible story progress. The last two weeks were turned into a reactive nightmare rather than a skillfully planned sprint resulting in a demonstrable increment.Why not cancel the review – just for tomorrow?

And so on..

I bet you’ve seen it before: The organizational structure around the scrum-team is sucking the life out of their ability to scrum effectively.

Looking at the example scenarios above, what are organizational changes needed for scrum to thrive?

1. Separated product management & engineering units need to merge into one product development unit.
2. Specialized engineers need to become much more broadly tasked „product developers“.
3. Architecture needs to be integrated into the teams and transition from large descriptive to emergent code-based architecture.
4. Code ownership between different teams needs to become weak.
5. End 2 End testing departments need to be integrated into the teams and heavy investment in testautomation is needed.
6. Deployment and service-departments need to be integrated into the teams and deployment must be automated.

Power, careers and role-appraisals etc. are attached to the status-quo structure that needs to undergo change before scrum can really thrive.

Without deep organizational change accompanying the adoption of scrum, Scrum by the Book will remain to be a pain while ScrumBut will remain to be ineffective regarding the promise why it was started in the first place.

What else can be done?

Meet VisionScrum

Here’s the deal I try to promote with the term VisionScrum.

I think that it should be understood by an entire organization that chooses scrum :

Each and every time truly enacting scrum does not make sense in the given moment the Scrum Master(s) are tasked to raise an impediment that addresses the root cause. For determining the delta the scrum-guide is used (the book!). It’s constraints are powerful and super clear. It is pre-accepted by everyone in the organization, that this root-cause will be a pointer to some deeper change.

Scrum by the book should not be forced for today’s process. Rather the full Scrum Guide and all it’s implications should be the vision & rhythm for tomorrow’s change. Nobody should feel bad if they only do as much of scrum they can today. As long as the delta is conscious and effective change to be able to do it in the future is started today.

Sure the teams should try even today. This very tension is what’s providing the rhythm and transparency for change. But teams may not be left alone with this! And not blamed for doing only ScrumBut or finding excuses!

Putting in a coach or two is not enough.

Rather an impediments-process based on root causes and effectively connecting Scrum Masters to senior management must be set up using an adequately powerful framework for continuing deep organizational change.

Be prepared to address existing power structures! Let everyone know beforehand that this will happen! Educate everyone in scrum, it’s promise & purpose as well as it’s implications.

Use scrum as the detailed vision and rhythm for this change.

Set up an adequate framework for continuing deep organizational change to go along with adopting scrum in your organization

John Kotter offers these necessary ingredients (and in fact in sequence) for deep organizational change (in my words):

1. Sense of urgency: Yes, we will be the next Nokia if we don’t act this year.
   But organization Development and learning is continuously held at lower priority than product development? Efficiency and speed trump organizational learning?  Adaptiveness  – the org’s capability to respond to disruption – is  and should be the reason for introducing agile & scrum in the first place. If there is not urgency to get to this, VisionScrum is not for your org. Save your org a lot of money and stress. Don’t use scrum. Use other agile methods that are not as fierce at heart.
   IDEA for communicating this sense of urgency:
   Consider looking at past local losses (i.e. the loss of business) through the light of external disruption and local response.  Make everyone and their families familiar with these stories. Consider conceptual frameworks like the Cunefin Framework or the Stacey Matrix to provide a lens for everyone (i.e. use it in trainings) to look at these stories. Point out the implications of possible disruption to the wider community (not just employees).
2. Guiding coalition:  A committee of managers always does exist. But what about it’s alignment & trust? What about it’s diversity in respect to change? What about it’s commitment to the adoption of deeper scrum in the organization? Did the members actually read the scrum guide? Are they trained in the implications of truly applying scrum? What do they really know about agility? Consider
   Scrum Alliance’s Certified Agile Leadership (CAL) courses. One flavor of CAL I can recommend are the personally daring but strongly effective trust & alignment building courses based on temenos.
   Look into Scrum@Scale for advice on how to set up an effective Executive Action Team (EAT).
3. Clear & Published Vision: Using the scrum-guide somewhere near the vision of change is what I’m suggesting. Sure, scrum is not a purpose by itself, but if you want the learning development organization, scrum is probably the most challenging framework to point your organization to places that could&should be changed next. You could also try to develop such a list of criteria for change yourself. But it will be hard to beat the sharpness of the scrum-guide. 
   What is needed to publish this kind of vision? A few days training for the key practitioners (Scrum Masters and Product Owners) as a means of sharing the vision with all it’s implications? Clearly insufficient. What about product managers, testers, architects, managers, HR, etc.. All are deeply impacted by a real application of scrum. Instead consider repeated open space with the entire development organization (see Daniel Mezick’s Open Space Agility). Since there are implications on power-structures and current roles in the vision, it is essential to be clear to guarantee job safety and individual appreciation but not role safety. 
4. Enlisting of volunteers: If you plan to start small, volunteers should be doing it. It’s that simple. Not enough volunteers? Don’t start scrum. Start something else.
5. The removal of impediments: I’m not talking about the ScrumMasters getting a broken cable in the meeting-room replaced. The real impediments to scrum are organizational structures with implications on power. Good ScrumMasters can do a lot by doing good retros in the team etc. But after a a few weeks the organizational structures start becoming the most important thing to address. Avoid creating an atmosphere of coping here. Sure the team should take responsibility for what they can do and avoid getting into the habit of blaming „them up there“. But they do need hope, that even the hard structural impediments will be effectively & promptly addressed by senior management. They need feedback on management’s progress. Then they can be patient and focus on their sphere of control. Connect the ScrumMaster community with a direct communication process to the senior management.  Don’t let agile coaches or highly paid consultants get in the way and block out the ScrumMasters. Cut the slack. Much about Scrum@Scale is about impediment removal by the Executive Action Team as a response to ScrumMaster-Input.
6. The implementation and demonstration of quick wins – Be crystal clear about what is to be achieved by scrum in the first year. It’s not _cultural_ and it’s not to do with a lot of PostITs. It should be something more tangible like: „Get the current phased development project de-scoped and delivered on time and in blazing quality without wasting any effort by using empirical process control. Itemize the backlog and shorten lead time. Do this entirely driven by self-organizing X-functional teams“. Depending on your situation, you can do much more (e.g. achieve bug-free continuous delivery of features based on hypotheses validated in optimal user-facing experiments). But for most organizations this is not the first step. Be clear about expectations on the first business values that scrum is expected to produce and focus on those.  Consider using a strategy map or some other publicly visible and unavoidable piece of information.
7. The widening and acceleration of the practices to larger parts of the organization. Only scale when you’re really good in doing scrum in the smaller circle. Consider Tobias Mayer’s Scaling Agile Metaphor of a fish. First get rid of all the things you don’t want to eat about the fish, before moving on to feed it to your org..
8. Institutionalize the change – Promote agile supporters. Get rid of bonuses. Get the new roles payed well. Provide perspective to generalizing experts, probably by innovating  on your compensation model.

You can’t do ScrumByTheBook today. Nobody can. Doing ScrumBut is costing the industry a lot and frustrating the hell out of people.

Senior Managers in product development: Please start to view scrum as a detailed vision and rhythm for deep organizational change in product development. Please use VisionScrum over ScrumByTheBook or ScrumBut.

Please stop rolling out scrum to the team-level in isolation. It creates a world of pain and will not deliver the results justifying their cost! Rather start surrounding teams with an effective framework for deep organizational change! Options exist. Please use what’s out there.

In den bisherigen Posts habe ich über die Rolle des Lernens und über optimale Bedingungen dafür in Entwicklungsteams geschrieben. In diesem Post möchte ich eine Utopie entwerfen, indem ich mich zur Abwechslung in die Rolle des Auftraggebers hineinversetze (In Wirklichkeit kenne ich die Auftragsvergabe von Software immer nur aus der Perspektive des Dienstleisters)

Ich stelle mir also vor, ich hätte ein Budget zu vergeben und versuche damit ein bestimmtes komplexes Problem meines Geschäfts mit Software von Dienstleistern lösen zu lassen.

Wie wähle ich ein Team oder einen Anbieter aus? Womit beauftrage diese Leute?

Ziele meiner Beauftragung

Bevor ich eine Strategie entwerfe, frage ich erst nach den Zielen. Ich stecke mir folgende Ziele:

1. Budgetsicherheit: Ich will vorab möglichst hohe Sicherheit haben, dass mein Geld genügt, um das Problem grundsätzlich zu lösen. Ansonsten sollte ich nicht anfangen.
2. Wenn ich hier ein grünes Licht habe, will ich anschließend möglichst wertvolle Software für mein Geld erhalten. Wichtige Faktoren hierzu (für mich gilt auch die Reihenfolge):
   1. Zielkonflikte:  Ich will, dass sich die Projekt/Produkt-Ziele der Entwickler/des Anbieters möglichst mit meinen eigenen Projekt/Produkt-Zielen decken (Qualität, Zeitplan, Architektur, Langlebigkeit etc.)
   2. Lernatmosphäre: Ich will eben insbesondere auch den Rahmen schaffen, dass bei der Entwicklung optimale Bedingungen zum Lernen vorherrschen
   3. Talente: Ich will die talentiertesten und effektivsten Entwickler bekommen, die möglichst wenig Projektunabhängiges lernen müssen
   4. Lösungsansatz: Ich will den Anbieter mit dem effektivsten Lösungsansatz für meine Produktziele finden
   5. Risiko: Ich will mich möglichst gegen das Risiko absicheren, dass sich die Lösung des Problems als viel teurer herausstellt, als anfangs angenommen

Ich vermute, dass andere Leute in den Faktoren A-E eine andere Reihenfolge definieren würden, als ich. Ich vermute das liegt an kurzfristiger Bindung und einer Sicht auf wenige Monate. Wenn aber langfristig genug gedacht wird, gilt in meinen Augen diese Reihenfolge. Ich versuche zu argumentieren:

Vermeidung von Zielkonflikten sehe ich als oberste Priorität. Nur so kann ich von der Kontrolle zum Vertrauen wechseln – der Schritt, der alles Weitere entscheidend zum Erfolg wendet. Wenn ich z.B. nicht Angst haben will, dass sich Entwickler mit der Technik verkünsteln und teures und kompliziertes Zeug bauen, sehe ich zu, dass sie sich ebenso wie ich am gesamten langfristigen Business Case messen lassen. Ich rufe hierzu die Motivatoren AMP  (Autonomy, Mastery, Purpose) von Dan Pink in Erinnerung. Stimmt nämlich der Purpose – Aspekt, muss ich nicht befürchten, dass sich Entwickler unverhältnismäßig auf den Mastery-Aspekt stürzen.

Danach und passend dazu, sehe ich die Lernfähigkeit des Systems. Lieber habe ich weniger Kenntnisreiche und sogar weniger talentierte Entwickler, die sich dann aber voll motiviert auf den Weg der rückhaltlosen und kontinuierlichen Verbesserung machen, als Rockstar-Entwickler, die weniger bereit zur Veränderung sind. Rolling Stones Fans sehen das vielleicht anders.

Wenn ich einmal annehme ich hätte motivierte, lernende und talentierte Entwickler ohne jeden Zielkonflikt aber leider zunächst einen falschen Lösungsansatz: Ich meine, dieser wird sich ausbügeln. Jedenfalls dann, wenn genug Zeit da ist. Schließlich können gute Entwickler refaktorieren, machen automatische Tests und sind in Retrospektiven ehrlich…

Zu guter letzt sehe ich die Kontrolle des technischen Risikos. Ich meine, dass die Kontrolle und das Abwälzen des Risikos, wie das z.B. beim Festpreis versucht wird, in der Regel irgendwie zurückschlägt. Dazu ist Software einfach ein allzu integraler Bestandteil der Organisation, als dass man deren Hersteller ohne eigenen Schaden Verluste erleiden lassen könnte.

Lieber trage ich als Business Owner das Risiko, als dass ich mir mit einem fixen und in der Regel dann ja auch sehr knappen Budget Zielkonflikte ins Haus hole. Im Gegenteil habe ich oft erlebt, dass das ursprüngliche Ziel, Entwickler mit einem knappen Budget zur Schlankheit und Simplizität ihrer Lösungen anzutreiben, erstaunlich schlecht funktioniert. Die in diesen Fällen zum Werkzeug degradierten Entwickler ziehen ihre tägliche Motivation dann nämlich nicht mehr aus Sinn und Autonomie sondern aus der Meisterschaft. Das Überziehen des Budgets ist aber zum frühen Zeitpunkt der teuren architektonischen Entscheidungen noch weit weg. Ein viel geeigneteres Mittel wäre somit die Ausrichtung der Entwickler am langfristigen Business Case.

Eine Utopie zur Beauftragung

Ich denke es kommt heraus, wofür ich mich nicht ausspreche: Der gute alte fixed preis/fixed scope Vertrag. Der setzt das Abwälzen des Risikos an erste Stelle, verführt zu verfrühter Analyse (damit die Dienstleister schätzen können) und lenkt den Blick vom Team, dessen Motivation und Talenten ab. Zudem zerstören die typischen Zielkonflikte hier die Lernatmosphäre.

Hier also mein teamorientierter Ansatz zur Beauftragung:

Ich erarbeite mir mit meinen Stakeholdern in sehr kurzer Zeit (z.B. 1-2 Wochen für ein Projekt, welches ein paar Mannjahre vorsieht) eine leichtgewichtige Team-Ausschreibung, die ich an mehrere Dienstleister herausgebe.

Ich mache darin von vorn herein klar, dass es mir primär um die Auswahl eines Teams geht, und nicht um die Auswahl eines Gesamtangebots mit fixem Scope, fixem Preis oder fixem Konzept.

Die Infos, die ich initia und schwungvolll intern erarbeite sehe ich wie folgt:

1. Eine Einleitung, in der erklärt wird, worum es in der Software gehen soll
2. Ein leichtgewichtiges Domänenmodell, welches die Begriffe der Domäne zueinander in Beziehung setzt. Hierdurch werden im gesamten Prozess Misverständnisse vermieden.
3. Eine initiale Produktvision des „Minimal Viable Product“, also des einfachsten Produkts, mit dem der frühest denkbare Einsatz der Software möglich ist. Idealerweise ist dieses Produkt sehr klein. Besonders Kreative Ideen für die Gangbarkeit eines sehr kleinen Produktes sind insbesondere dann gefragt, wenn es sich um die Ablösung (Replattforming) eines großen Systems handelt.
4. Eine grandiose Produktvision des Produktes, wie es möglicherweise in der Zukunft aussehen könnte. Hierdurch wird der Rahmen für eine evolutionäre Architektur gespannt
5. Priorisierte Qualitätseigenschaften (wie z.B. User Experience, Datendurchsatz, Stärke der Vertraulichkeit gewisser Daten etc.) mit einer Begründung warum diese Eigenschaften in dem Kontext wichtig sind
6. Ein möglichst kompakt aber balanciert formulierter initialer Business Case, der messbare Erfolgsindikatoren (z.B. Downloadzahlen und Sternchen im App-Store, Pageimpressions, Admin-Stunden, Ergebnisse aus Userbefragungen etc.) für den Einsatz der Software formuliert. Diese Kriterien soll das Scrum Team inklusive Product Owner gemeinsam optimieren. Dazu müssen sie balanciert sein und im Verlauf der Zeit auch angepasst werden. Achtung: What you measure is what you get!
7. Ein leichtgewichtiges Beispiel-Backlog mit 2-Zeiler Userstories, die mit den Begriffen der Domäne formuliert sind. Das Backlog sollte schon einen kleinen Release nach dem Minimal Viable Product umreißen und nach meiner eigenen Schätzung grob mit meinem Budget realisierbar sein.
8. Hinreichende Details zum technischen Umfeld, damit Anbieter eine Chance haben sinnvoll zu schätzen. Besonders zu behandeln sind z.B. Migrationen von Legacydaten und deren Strukturen, Schnittstellen, rechtliche Anforderungen etc.

Mit diesen Inhalten würde ich an bis zu 3-4 gute agile Anbieter herantreten und folgenden Fragebogen herausgeben mit einer extrem kurzen Bearbeitungszeit herantreten:

1. Haben sie Feedback zur Aufgabenstellung (Produktvisionen, BusinessCase, Backlog, Ziele etc.)?
2. Mit welcher Technik, welchem Lösungsansatz und welchen möglichst einfachen Mitteln trauen sie sich zu, das Minimal Viable Product umzusetzen? Warum ist diese Wahl gut für die angegebenen Ziele? Wie zukunftsfähig ist diese Wahl? Inwiefern geht dieser Ansatz auf die priorisierten Qualitätsmerkmale ein?
3. Bitte skizzieren sie eine Variante von Scrum, die sie für unsere Situation für sinnvoll halten. Geben unter andem drei Varianten von Paaren an, die jeweils die Definition of Ready und die Definition of Done beschreiben. Schlagen sie ein Definitionspaar vor und begründen sie, warum dieses zu unserer Situation passt.
4. Wie werden die priorisierten Qualitätsmerkmale der Software in diesem Scrumprozess berücksichtigt ? (z.B. UX-Design)
5. Was müsste sich im größeren an der Architektur ändern, wenn man nach dem Minimal Viable Product das ganze vorliegende Backlog bauen würde? Was wenn man bis zur grandiosen Vision weitermacht? Geben sie Kostenmodelle für etwaige Architekturschritte an.
6. Bitte ergänzen sie das Backlog durch möglichst effektive und simple Konzepte, wie wir die Erfolgsgrößen des Business Case bereits ab dem Minimal Viable Product messen können.
7. Bitte sortieren und clustern sie das Backlog nach relativem Aufwand (Affinity Estimation)

Der Clou ist: Bisher ist keine Schätzung der Kosten gefordert! Diese sollte nämlich das Team machen, welches ja in aller Regel noch nicht formiert ist. Die Fragen bisher zeigen nur, ob der Anbieter oder dessen Vertriebsarchitekten das Thema verstehen und bieten die Grundlage ein Team zusammenzustellen.

Als nächsten Schritt würde ich die Anbieter auffordern, ein Team zu präsentieren, welches verbindlich ab einem vom Anbieter zu benennenden Termin (bzw. Ramp-Up Verlauf) zur Verfügung stehen könnte. Diese Teams würde ich für jeden Anbieter zu Workshops einladen. Die Workshops würden 2 Tage dauern und folgende Teile enthalten:

• Fragenrunde
• Präsentation des Lösungsansatzes
• Präsentation des Teams inklusive transparenter Darstellung, wer noch was lernen müsste
• Sprint Planning einen 1-Tages Sprint
• 1-Tages-Sprint inkl. Review und Retro mit Team und PO (=ich)
• Als allerletztes: Interaktive Schätzung des Backlog mit dem Team

Im Anschluss müssten noch kommerzielle Verhandlungen stattfinden, in denen mit dem Anbieter über den gesamten Teamtagessatz, das terminliche Konzept für dieses Team (wer ab wann, zu welchem Anteil verfügbar sein kann) und die Rolle des ScrumMasters verhandelt wird.

Über dieses Vorgehen spare ich mir und dem Anbieter viel Zeit, die traditionellerweise mit dem Erarbeiten von Konzepten, Spezifikationen und Architekturen verwendet wird, die in dieser frühen Phase oft nicht angemessen sind. Stattdessen dringe ich mit diesem Ansatz mit dem Presales-Budget zu dem Wesentlichen – der Auswahl eines geeigneten Teams vor.

Wie werden die Ziele adressiert?

Im Kontakt mit einem konkreten Team vor der Beauftragung kann ich meine Ziele direkt adressieren. Ich schaue mir die obigen Ziele genauer an:

1) Budgetsicherheit: Wenn das Team ganz am Ende des Workshop schätzt, habe ich eine reale Chance, einen realistischen Preis zu erfahren. Das Team kennt mich jetzt schon etwas, hat schon was programmiert und das Umfeld kennen gelernt. Idealerweise ist die wichtigste Ressource in der Softwareentwicklung schon ein Wenig entstanden: Vertrauen!

Außerdem wird ein gutes Team stolz auf sich sein und es zum Schluss nicht mehr für nötig erachten, taktisch zu schätzen, um den Job zu bekommen. Stattdessen werden sie zum Schluss darauf setzen, dass ihre Qualitäten siegen.

2A)  Zielkonflikte: Über die Erfolgsgrößen und deren frühe Messbarkeit erzeuge ich eine Situation, in der die Entwickler mit mir an einem Strang in Richtung Business Case ziehen werden. What you measure is what you get!

2B) Lernatomosphäre: Durch den kollaborativen Ansatz werden die Entwickler als Personen und deren Organisation vorn herein ernst genommen, was die Motivation und Vertrauensatmosphäre positiv beeinflusst. Wichtig ist mir hier vor allem: Die Transparenz darüber, wer noch welches projektunabhängiges Thema (z.B. eine Technologie) im Projekt zu lernen hätte.

2C) Talente: Indem ich die verbindlich vorgeschlagenen Leute direkt und in Aktion kennen lerne, habe ich eine gute Chance, gute Leute auszuwählen.

2D) Lösungsansatz: Der initiale Ansatz wurde sogar schon vor der Teamgründung entworfen, da die Auswahl der richtigen Leute oft vom Ansatz abhängt. Das Team kann ihn immer noch ändern.

2E) Risiko: Das Risiko, dass alles viel schwieriger war und irgendwo ein Loch im Konzept ist, wird primär durch die schnelle Lieferung des Minimal Viable Product adressiert. Je kleiner dieses ist, desto kleiner auch mein Risiko. Ich versuche erst gar nicht, einen Anbieter für mein Risiko zahlen zu lassen, wenn ich überzeugt bin, dass die Leute gut sind und an meinen Zielen ehrlich bemüht arbeiten. Das Risiko, dass ein Anbieter nicht wirklich ernsthaft an meinen Zielen arbeitet, ist mit diesem Vorgehen ebenso minimiert.

Das technische und geschäftliche Risiko wird mit diesem Ansatz also minimiert aber nicht auf den Anbieter abgewälzt. Somit stört die Risikominimierung die zentrale Vertrauensbildung nicht und führt keinen Zielkonflikt ein. Das gängige Unheil in Softwareprojekten wird also vermieden.

Fazit

Ist das normal? Ist das legal? Was ist mit meinem Budgetgating? Welcher Manager ganz oben erlaubt mir, so einen Prozess zu verfolgen? Was sagt das Controlling? Was sagt die Buchhaltung? Auf welche Schulung muss ich jetzt meine Einkäufer schicken, wenn dieses ihr neues Vorgehen werden sollte?

Ok, es ist also eine Utopie!

Es ist aber aktuell eine Veränderungswelle in Gang, die Unternehmen dazu anstifen will, sich mehr auf solche auf intrinsisch motivierenden und auf Vertrauen abzielenden Prozesse einzulassen. Meine Überzeugung ist: Wer den Weg geht, wird mehr Erfolg haben und seltener auf die Nase fallen.

Stichworte von aktuellen Trends in dieser Richtung:

• Management 3.0
• Intrinsify.me
• Beyond Budgeting
• Lean Startup
• …

Feedback und Diskussion würden mich freuen!