Der agile Mentor - Planning Meeting Sprint 1

Im Anschluss an die Retrospective von Sprint Zero kam der eigentlich wichtige Teil, zumindest für mich. Mein nächstes Ziel war es, eine Aufwandschätzung vom Team zu bekommen, um einen Sprint planen zu können. Damit das gesamte Team hinter diesem Ziel steht, habe ich eine List angewandt: Wir haben geschaut, was im Sprint Zero realisiert werden konnte. Bis zu diesem Zeitpunkt wurden keine User Stories verwendet, also haben wir die abgeschlossenen Arbeitspakete im Plannungstool einfach mal zusammengezählt: 21 von 26, nicht schlecht! Oder doch?

Also fragte ich,

• ob dass ein gutes Ergebnis sei? - konnte man nicht richtig beanworten, wahrscheinlich schon
• hatte man sich über-committed? - konnte man nicht richtig beantworten, eher nicht - es sind ja ständig neue Dinge dazu gekommen
• wieviel Aufwand steht hinter 21? - konnte man nicht beantworten
• warum wurde 26 nicht erreicht? - ja, man hätte noch viele Dinge gemacht, die man da nicht sehen könne
• wo stehe man denn im Hinblick auf den Endtermin - konnte man nicht beantworten, eher so ein Bauchgefühl

Viel Verwirrung - und ich kam mir vor wie ein Lehrer vor seiner 8.Schulklasse, der eben verkündet hat, dass man auf der Klassenfahrt kein Alkohol trinken darf, toll!
Was soll denn das? Wo führt das hin? Warum müssen wir das tun?

Ratlosigkeit! Nach ein paar Sekunden Schweigen habe ich vorgeschlagen, dass wir die kommenden zwei Wochen planen (hatten wir bei Sprint Zero nicht gemacht). Wir wollen uns gemeinsam ein Ziel setzten und dieses erreichen und - viel wichtiger - wir wollen wissen, was wir in zwei Wochen erreichen KÖNNEN

Wir befragten das Plannungstool - was gibts überhaupt noch zu tun?

Schnell wurde festgestellt, dass man im Planungstool Tasks, Issues, Bugs, Packages, Components, SubTask u.v.m. auf gleicher Ebenen behandelt und viele Zusammenhänge, z.B SubTask --> Tasks --> Components bestehen. Ausserdem fehlte die Aufwandschätzung pro Arbeitspaket, unabhängig von der Granularität. Von meinem Standpunkt aus sah das alles unübersichtlich aus. Ich konnte mir absolut kein Bild darüber machen, was noch getan werden musste und wie Arbeitspakete zusammen hingen- keine Ahnung, und ich war nicht allein! Also beschloss man, schnell ein paar Arbeitspakete zu eleminieren und zusammenzufassen - eben aufräumen.

Ich beobachtet das Geschehen und so langsam wurde mir klar, dass das Plannungstool eher ein Gedächtnisstütze jedes Einzelnen war. Alles, was einem so eingefallen ist bei er Bearbeitung von Issues, wurde als Task, SubTask, Component, Issue oder was auch immer hinuzugefügt. Damit änderte sich die Menge und Inhalt der Informationen im Tool quasi stündlich. Das Plannungstool diente der Dokumentation.

Planung? Auf dieser Basis unmöglich!

Nach der Bereinigung verständigte man sich auf eine Entität für planbare Arbeitspakete im Plannungstool - Task. Components, SubTasks, Issues und alles andere sind Dokumentation, Tasks sind Arbeitspakete, planbare Arbeitspakete.

Ok, ich gab dem Team die Aufgabe, für die nächsten Tasks die Aufwände zu schätzen. Was die nächsten Tasks sind, sollte das Team selbst entscheiden. Ich beschäftigte mich damit, die verfügbaren Ressoucen abzuklären.

Am Ende beschloss das Team Arbeit für 184h anzunehmen.

Zürück zur: Retrospective Sprint Zero
Weiter zur: Retrospective Sprint 1

Der agile Mentor - Retrospective Sprint Zero

Nachdem im Sprint Zero der Daily Scrum von Team eingeführt wurde, lebte die Kommunikation auf - in manchen Punkten mussten Teammitglider sogar gebremst werden. Im Grossen und Ganzen haben wir es erreicht nicht mehr als 15 min pro Daily Scrum zu nutzen.

Vierzehn Tage später, am Ende von Sprint Zero plante ich eine Retrospektive, um den Puls des Teams zu fühlen. Dabei wurden folgende Punkte mit Verbesserungspotenzial festgehalten:

• Daily Scrum schweift teilweise ab
  
• AJAX Exception Handling fehlerhaft
• Close Event bei Lightboxe löst einen Reload aus - Usability!
• viel unused Code, viel FIXME und TODO
• Testabdeckung mangelhaft
• Exception bei Suche
• Wireframe zum Task - Wo liegt der? Bessere Vorbereitung!
• Tooling und Infrastruktur Handling kompliziert

Ok, gut!

Wir haben die Punkte angesehen und ein paar herausgenommen, die im kommenden Sprint 1 verbessert werden können.

Zurück zu: Sprint Zero
Weiter zum: Planning Meeting Sprint Zero

Der agile Mentor - Sprint 0

Nachdem ich mich mit der Projektsituation und der Arbeitsweise des Team vertraut gemacht hatte, brauchte ich einen Plan - ganz entgegen den Scrum Prinzipien.

Zunächst gab es vier Punkte, die ich dem Team nahebringen wollte:

1. tägliche Status-Meetings (max. 15 min)
2. fokussiertes Arbeiten im 2 Wochentakt - wir wollen alle 2 Wochen etwas produzieren
3. Aufwandschätzungen zu den Arbeitspakten vom Team
4. Planung der kommenden 2 Wochen

Um diesen Plan umzusetzen und das Commitment vom Team zu bekommen habe ich ein Meeting zu einem Kaffee einberufen. Bereits nach wenigen Argumenten waren das Team dafür, dass man tägliche Statusmeetings einführen sollte, denn oft gingen wichtige Informationen unter oder waren nicht für jeden im Team verfügbar. Da das Team räumlich eng beieinander sass, machten wir die die Stand-up's an einem Arbeitsplatz, wer nicht da war nahm per Skype teil.

Mehr nicht! Das war die erste und einzige Neuerung. Als nächstes wollte ich den 2 Wochen Takt inklusive Planung einführen. Ich hatte etwas Zeit gewonnen, die nächsten Punkte vorzubereiten.

Was daraus wurde und was das Team von den Stand-up's hielt, sollte ich in der ersten Retrospective erfahren.

Dranbleiben!

Zurück zur: Scrum Einführung
[Update]
Weiter zur: Retrospective Sprint Zero

Get Started: Workreportr

Vor etwas mehr als einem Monat habe das Ruby on Rails Buch endlich mal aufgeschlagen und war sofort begeistert. Schnell war mir klar - das musst du mal machen! Ok, ich brauchte ein Übungsprojekt und hier sind wir nun ...


Get Started:

Das Projekt heisst Workreportr und es lebt bei amazee.com.

Da amazee eine social collaboration Plattform ist, kann jeder mitmachen. Also bitte, einfach beitreten und mitwirken.

Danke, jp

Der agile Mentor - Scrum Einführung

Vor kurzem wurde ich bei einem externen Projekt als agiler Coach hinzugezogen. Bei diesem Team hatte ein Entwickler bereits Erfahrungen mit Scrum. Es wurde der Wunsch geäussert, nach Scrum vorzugehen. Der zuständige Projekt Manager überliess diese Entscheidung dem Team und so arbeitete man nach Scrum. Kurz vor dem ersten Release wurde ich als Entwickler und agiler Mentor hinzugezogen.

Nach wenigen Tagen ergab sich folgende Bild:

Vor dem Projekt wurde ein detaillierte Spezifikation geschrieben, die zum Projektbeginn von einem Entwickler in Arbeitstasks runtergebrochen wurde, ohne Aufwandschätzung. Der Endtermin war fix. Man zerlegte die Realisierungzeit in kleine Teil-Releases und verteilt die Arbeitspakete (gleichverteilt, x Tasks pro Release). Daraus abgeleitet ergab sich eine grobe Releaseplanung bis zum Projektende. Verschiedene Elemente von Continous Integration wurde installiert: Version Control, Build Server, Unit Testing. Rollen, Regel und die Scrum Rituale, Planning & Estimation Meeting, Sprints, Demo, Retrospective und Daily Scrum wurden nicht angewendet. Der Kunde, in seiner Funktion als Product Owners oder im allgemeinen, war im Verlauf der Realisierung nicht involviert. Es gab eine ausführliche Definition von DONE, kaum jemand hielt sich dran. Wöchentlich wurden Status Meetings abgehalten. Als Projektmanagement und Entwicklertool wurde Jira eingesetzt. Wenige Wochen vor dem ersten Release wusste man nicht, ob man fertig würde. Zusammenfassend kann man sagen: kein agil, kein Scrum!

Ok, ich habe mir also eine Strategie zurechtgelegt, wie Scrum vom Team angenommen und vollumfänglich implementiert werden könnte. Grundsätzlich gab es zwei Optionen:

• Sofortige Scrum Einführung mit allen Ritualen, Rollen und Regeln, quasi "von jetzt auf gleich", oder
• Sequentielle Implementierung, nach und nach ein weiteres Element aufnehmen.

Aus der Erfahrung heraus schien mir die erste Option zu unrealistisch. Ein etabliertes, produktives Team ist alles andere als glücklich, wenn ein Aussenstehender ein neues Vorgehen einführt, dazu noch eines, was so radikale Veränderung mit sich bringt und kaum Akzeptanz findet. Ich entschied mich also für die zweite Option.

Als ich zum ersten Mal mit Scrum in Berührung kam, war ich in einem Projekt als Software Engineer tätig, was mässig erforgreich war. Der Kunde wurde mehrfach hingehalten, die Reaktionszeit war schlecht und die Bug Rate war sehr hoch. Die Projektleitung wurde ausgetauscht und mit der neuen Person kam ein neues Vorgehen - agil nach Scrum! Der ScrumMaster hat zu Beginn nur eine Regel eingeführt - wir wollen fokussierter arbeiten und alle 3 Wochen etwas nützliches produzieren.

Ich legte mir einen Plan zurecht - was daraus geworden ist und welche Erfahrungen ich gemacht habe?

Dranbleiben.

Warum machst DU Scrum?

Neulich wurde ich mit dem Vorwurf konfrontiert, Scrum der Karriere wegen zu verfolgen. Hm, nun ja - man kann zweifellos zugeben, dass man zu einen kleinen Personenkreis zählt, denn bislang ist die Scrum Gemeinde in Europa recht klein, und dass, obwohl Scrum keineswegs etwas Neues ist.

Aus meiner Sicht gibt es nur ein Alleinstellungsmerkmal bezüglich der Karriere - man arbeitet anders.

In einem Beitrag Erfolg! habe ich drei Sichten beschreiben, die Erfolg definieren:

• Stufe 1: persönlicher Erfolg
• Stufe 2: technischer Erfolg
• Stufe 3: unternehmerischer Erfolg

Aus Entwicklersicht behaupte ich, dass man mit Scrum zwangsläufig mit Stufe 3 auseinander setzen muss - quasi der Entwickler der dritten Generation.

Ich sehe das als absolutes Job-Enrichment! Mit Scrum kann ich meine Arbeit so erledigen, dass ich alle Stufen erreiche. Aber Moment mal, kann man das mit klassischem Projektvorgehen, z.B. nach Wasserfall nicht ereichen?

Nun, die Antwort muss jeder selbst finden. Ich allerdings fand mich bei diesem Vorgehen immer wieder mit der Tatsache konfrontiert, dass ich Dinge machen musste, bei denen ich bereits zu Beginn wusste, dass sie wenig Erfolg bringen werden, weder persönlich, noch technisch, noch unternehmerisch.

Man hat eine detaillierte Spezfikation vorliegen und die arbeitet man ab. Nicht selten stellt man während dessen fest, dass die Spezifikation nicht alle Fragen beantwortet oder sich sogar in wichtigen Punkten wiederspricht. Dazu kommt, dass man in früheren Phasen der Analyse oder Konzeption als Entwickler garnicht involviert ist - Argumente und Hintergründe, warum z.B. genau DIE Architektur gewählte wurde, ist oft nicht transparent. Architekten, Business Analysten, GUI Experten und Designer gehen in zu Beginn oft parallel vor, sodass die Spezifikation nicht aus einem Guss ist und teilweise nicht aufeinander abgestimmt wird. Und zu guter letzt ist meistens mehr als die Hälfte der Zeit bzw. Budget bereits aufgebraucht, bis man mit der Realisierung beginnen kann ...

Ich habe Scrum eher auf die harte Tour kennengelernt und habe mich anfänglich nicht damit identifizieren können. Heute, nach diversen Erfahrungen mit agilen Projekten nach Scrum würde ich das Thema agil als Evolutionsstufe bezeichnen. Zurück führt kein Weg mehr!

tinyPM 1.1 Agile Project Management Tool Released

tinyPM, wie der Name bereits verrät, ein schlankes Tool zum Managen von agilen Projekten.

Ich habe mir kurz die Zeit genommen und die Software ausprobiert. Wirklich gut, hat mich überzeugt. Einfach, schlank, auf das wesentliche reduziert, sehr usable und leicht zu bedienen. Kaum Schnick-Schnank und bis zu 5 Usern auch noch Freeware (Communitiy-Edtion).

Features:

• Backlog
• User Stories
• Iteration Planung
  
• Taskboard
• und vieles mehr ...

Goodies:
Ich find, dass einige Dinge sehr schön gelöst sind:

• Automatische Taskgenerierung (Dinge, die man bei jeder User Story braucht)
• Verschlagwortung von User Stories und Tag Cloud
• Sehr übersichtliches Dashboard
• History, woran habe ich gearbeitet (filterbar)
• Wiki, einfaches und gutes Wiki im Tool - für die Brainstorming's

Summary:

Ich bin ja ein Fan von Flip-Chart und White Boards, aber das Tool hier ist echt mal nicht schlecht. Einfach mal ausprobieren, lohnt sich.

Ergebnisse: Blitzumfrage/Training

Die Umfrage zu Scrum-Trainingsbedarf war eine Woche aktiv und leider sind nur 7 Antworten gekommen. Die grosse Frage ist, können wir diese Ergebnisse überhaupt brauchen?

Tun wir ein Moment so, als ob die Ergebnisse relevant sind, und schauen wir, was sie bedeuten würden. Wie ist der deutschsprachige Scrum-Markt anders als die globale Scrum-Markt?

Akzeptanz der CSM

Das erste was auffällt ist die hohe Akzeptanz der CSM. Bei der internationale Umfrage hat man etwa gleich viel Interesse für zertifizierte und nicht zertifizierte Ausbildung. Hingegen bei den deutschsprachigen spricht eine klare Mehrheit für den CSM.

Woran liegt das? Ich kann mir vorstellen, das Scrum eher in den Startlöchern hierzulande steht. Das heisst, es sind die 'early adopters', die auszubilden sind. Also die, die für Scrum werben und für sich einen Zukunft mit Scrum sehen. Für sie ist die Zertifizierung wichtig.

Hingegen im englisch sprachigen Ausland, die uns ein bischen im voraus ist, ist man womöglich eher mit Ramp-Up und Roll-Out beschäftigt: grössere Zahlen von Entwicklern und Projektleitern, die ausgebildet werden müssen, wo die Kosten eine grössere Rolle spielen.

Bei beiden Sprachgruppen stellt man fest, das agile Planung und Schätzung ein wichtiges Thema ist. Wie kann man ein agiles Projekt aufgleisen...

Und die Sprachfrage

Nicht überraschend, man hat eine starke Vorliebe für Kurse auf Deutsch und man ist nur mittelmässig von Kursen auf Englisch begeistert -- aber auch nicht total abgeneigt, was meine persönliche Erfahrung eher nicht entspricht. Diese Erfahrung bezieht sich auf Firmen, die die Ausbreitung überlegen. Hier ist Englisch weniger akzeptabel, da die Kenntnisse sehr unterschiedlich sind. Die early Adopters haben wohl ihre erster Kontakt über den Englisch sprachigen Schriftweg gemacht und haben dabei weniger Berührungsängste.

Sind die Ergebnisse brauchbar?

Rein statistisch gesehen, sicher nicht. Die Umfrage ist weder wirklich representativ, noch sehr breit verbreitet. Und dennoch, in manchen Bereichen, v.a. die Akzeptanz der CSM-Ausbildung wie auch die Sprach-Frage, entspricht die Umfrage meine Erfahrungen. Ferner habe ich bei diversen Umfragen beobachtet, die Verhältnisse zwischen den Stimmen werden sehr früh ersichtlich. Also meiner Meinung nach: sicher nicht perfekt, aber auch nicht wertlos.

Ich für mich habe vor, so zu tun, als ob die stimmen würden. Ich habe mir den Ziel gesezt, die CST-Stufe zu erreichen (na gut, die englische Version dieser Umfrage und die vereinfachte Bedingungen haben dazu beigetragen). Ich weiss, was mein nächster Kurs sein wird. Schauen wir mal! So ist das Leben, man entscheidet auf Grund von unvollständigen und womöglich unrichtigen Daten...

Blitzumfrage: Scrum-Trainingsbedarf

Vor ein paar Wochen habe ich auf meinem Blog eine Umfrage zum Thema Scrum Ausbildung gestartet. Da ich in der Schweiz wohne, trotzdem aber lieber auf English schreibe, ist die Thema Sprache interessant. Konkret: wie wichtig ist es, dass Scrum-Ausbildung auf Deutsch angeboten wird? Sind die Bedürfnisse bei deutschsprachigen Firmen ähnlich, oder hat die englisch sprächende Welt diese Umfrage dominiert?

Also habe jp gebeten, die Umfrage zu wiederholen - was eine Gegenaufforderung produziert hat — und hier sind wir ;-)

Vorher hatte ich eine Blitzumfrage zum Nokia Test durchgeführt, die gezeigt hat, dass viele Firmen eigentlich gar kein Scrum machen (und das, obwohl die Mehrheit der Teilnehmer über die 'scrumdevelopment'-Gruppe davon erfahren haben!). Und so hat sich die Frage gestellt, wie Firmen ihren Scrum Ausbildungsbedarf einschätzen.

Zurzeit wird die Scrum Ausbildung als ein Art Zunft organisiert. Der erste Schritt ist dabei, Certified Scrummaster (CSM) zu werden. Das ist die Grundlage für alle weiteren Stufen, das wichtigste ist allerdings der Certified Scrum Trainer (CST). CSTs dürfen wiederum neuen CSMs ausbilden. Zurzeit gibt es etwa 25'000 CSTs, allerdings nur 54 CSMs. Bis vor kurzem musste man bereits 5 Jahre CSM sein, bevor man sich als CST bewerben durfte.

Das Kern der Scrum Ausbildung in der CSM Kurs. Dabei bieten die meisten CSTs zusätzliche Kurse für besondere Nischen. So weit ich weiss, gibt es nur 4 deutschsprachige CST's, Boris Gloger, Andreas Schliep, Joseph Pelrine und Roman Pichler, auch wenn nicht alle ihre öffentlichen Kurse auf Deutsch durchgeführt werden.

Also stellt es sich die Frage, ob dieser Angebot dem Bedarf gerecht ist. Was braucht Ihre Firma für Scrum Ausbildung?

Unten habe ich eine Liste von Möglichkeiten zusammengestellt, die hoffentlich dem Bedarf in den deutschsprachigen Ländern gerecht wird. Bitte in der Umfrage oben rechts alles ankreuzen, was zutrifft:

Zu meinem Ausbildungsbedarf, bzw zu den Bedarf meiner Firma gehören:

• Zertifizierte Scrum Ausbildung (CSM)
  
• günstigere, nicht zertifizierte Training
• Starthilfe Workshops
  
• Workshops für Fortgeschrittene
• Agile Schätzung und Planung
  
• Agile Vertragswerke
  
• Lean Strategie-Workshops
  
• XP (SW Engineering)
• Offene Kurse
  
• Firmen-Kurse
  
• Web-basierte Ausbildung (Webinars)
  
• Podcasts
  
• Kurse auf English
• Kurse auf Deutsch
• Kurse auf Französisch
• Kurse in anderen Sprachen
  
• Englisch wäre akzeptabel
  
• Englisch ist nicht akzeptable
  
• Kein Bedarf an Training
• anderes
  
• Weiss nicht/ist egal

Zum Datenschutz: obwohl ich an die Ergebnisse nicht uninteressiert bin, die Umfrage-Software von Blogger.com sammelt keine persönliche Informationen (oder falls doch, mir sagen sie nichts). Also werde ich mit niemandem Aufgrund der Stimmabgabe kontaktieren (es sei denn, Sie nehmen aktiv Kontakt mit mir auf).

Die Ergebnisse (samt Vergleich mit der englischen Ausgabe) werde ich hier zusammenfassen, nachdem die Umfrage abgeschlossen ist.

Gastbeitrag Peter Stevens

Peter Stevens, der Autor von http://scrum-breakfast.blogspot.com, hat bei mir angefragt, ob ich nicht ein Umfrage auf meinem Blog posten könne, die er auf seinem Blog bereits in Englisch durchgeführt hatte. Darauf hin habe ich ihn eingeladen auf meinem Blog einen Gastbeitrag zu schreiben.

Wir dürfen gespannt sein. Bis bald.

Wie wird man agil?

Ob man sein Auto wäscht, einen Schrank von Ikea zusammenbaut oder Software entwickelt, man folgt einem Prozess, teils intuitiv oder entlang einer schriftlichen Anleitung per Text oder Piktogrammen.

Agile Softwareentwicklung ist kein Prozessmodell und es gibt nicht DEN agilen Weg. Agil ist ein Bewusstsein, eine Haltung. Das agile Manifesto fast das gedankliche Modell in 4 Werten und 12 Prinzipien zusammen.

Die agilen Werte.[http://agilemanifesto.org/]

Die agilen Pinzipien.[http://agilemanifesto.org/principles.html]

Agil sein bedeutet, dieses Werten und Prinzipien zu folgen.

Erfolg!

Erfolg! Was genau heisst das? Traditionell definiert sich Erfolg durch Lieferung on time, on budget und gemäss Spezifikation.

Doch an dieser Definition ist ganz richtig! Man kann Projekte on time, on bugdet und gemäss Spezifikation abwickeln und mit dem Ergebnis verdient man keinen Cent. Andererseits gibt es Projekte, die über Budget, über den Deadlines und mit weniger Funktionen als spezifiziert abgeschlossen werden und man verdient damit viele hundert Dollar.

Es muss also noch etwas geben, ausser Deadlines einzuhalten. Was?

Als ich noch studierte habe ich oft nebenbei Websites mit PHP programmiert, viel herumgespielt, ausprobiert und umgebaut, bzw. weggeworfen. Solange ich Spass hatte, war ich erfolgreich, auch wenn etwas nicht funktioniert hatte. Mein Definition von Erfolg beruhte auf persönlichen Erfolgserlebnissen, he - Programmieren macht Spass!

Später, bei meiner ersten Anstellung als Software Engineer, wurde die Codebasis schnell sehr gross. Teilweise wusste man garnicht, warum oder wo etwas überhaupt funktioniert. Plötzlich wurde Wart-, Pfleg-, und Integrierbarkeit von Code wichtig. Ich musste lernten sauberen, eleganten und pflegbaren Programmcode in einem Team zu schreiben. Erfolg definiert sich nun so: technisch hervorrangend.

Trotz technisch hervorrangendem Programmcode wurden viele Projekte ein Desaster! Ich musste feststellen, dass Software neben mir und dem Team noch viele andere Stakeholder hatte, dessen Bedürfnisse es zu befriedigen galt - Endbenutzer, Betrieb'ler, Projektleiter, Controller und natürlich mein Chef, der mir meinen Lohn zahlt. Ich lernte, dass der Wert einer Software die gesamten Kosten abdecken muss. Erfolg hatte plötzlich eine unternehmerische Dimension!

Alle drei Dimensionen von Erfolg schliessen sich nicht aus, vielmehr sind alle besonders wichtig, denn nur im Zentrum findet man die Antwort auf die Frage, was neben Deadlines noch wichtig ist.

Ohne persöhnlichen Erfolg ist man schwer motivierbar. Ohne technischen Erfolg gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmerischen Erfolg wird sich das Team vom Unternehmen abwenden und eine neue Herausforderung suchen.

Der unternehmerische Erfolg wird von Softwareentwicklern oft zu Gunsten des persönlichen und technischen Erfolgs vernachlässigt, denn die sind einfacher zu erbringen und dafür ist jeder Softwareengineer letztendlich auch verantwortlich. Absurder Weise erwartet man aber, dass sich die Softwareentwickler dem übergeordneten Ziel - unternehmerischer Erfolg - unterordnen. Manager und Entscheidungsträger interessieren sich nicht für sauberen, eleganten und pflegbaren Code und die persönlichen Vorlieben der Entwickler - sie sind an Ergebnissen interessiert, am Return of Investment von einem Projekt.

Leider gibt das Management den Teams den Weg nicht vor, man erwarten dass das Team die Details klärt und einen richtigen Weg wählt. Wenn das erhoffte Ergebnis ausbleibt, werden Massnahmen eingeleitet, die sicherstellen, dass Entwicklerteams die gewünschten Erfolge bringen. Die Kosten sind an der Stelle ein beliebtes (Streit)Thema. Es gibt dann aus Managementsicht drei Ansätze:

• Vorgabe harter Deadlines um Entwicklungzeit zu reduzieren
• Outsourcing der Entwicklung in scheinbar billigere Länder
• beides

Wenn einem diese drei Punkte bekannt vorkommen, ist es vielleicht Zeit den unternehmerischen Erfolg bei Entwicklungsteams überhaupt ins Spiel zu bringen.