Donnerstag, 30. März 2017

Kommentierte Links (XXIII)

FS
  • Produktbezogen: Management vs. Produkt. Der ewige Kampf.

    Man lernt immer wieder dazu. Christian Becker zitiert hier aus The Art of Action, dem Buch eines Militärhistorikers namens Stephen Bungay. Basierend auf einem Organisationsmodell der preußischen Armee (woran erinnert mich das?) werden dort drei Wissenslücken beschrieben, mit denen in komplexem Umfeld operierende Organisationen konfrontiert sind:
    1. Knowledge Gap: The difference between what we would like to know and what we actually know.
    2. Alignment Gap: The difference between what we want people to do and what they actually do.
    3. Effects Gap: The difference between what we expect our actions to achieve and what they actually achieve.
    Im Grunde wäre diese Ausgangslage ideal für agile Vorgehensweisen geeignet, im klassischen Management ist aber im Regelfall das Gegenteil der Lösungsansatz - mehr Berichtspflichten, mehr Vorschriften, mehr Kontrolle. Ausführlicher steht das bei Bungay selbst.

  • Extreme Uncertainty: The myth of culture change

  • Weise Worte von Leon Tranter: eine Unternehmenskultur kann man nicht nur durch Anordnungen ändern, dazu ist sie zu tief in den Prozessen verankert. Was bringen zum Beispiel alle Bekenntnisse zu einer Kultur der Verantwortungsübernahme und Selbstorganisation wenn immer noch die Einhaltung aller Vorgaben, Detailreporting und Gruppenkonformität verlangt werden? Im Sinne eines Function follows Form-Ansatzes geht Tranter davon aus, dass erst geänderte Arbeitsbedingungen eine neue Kultur ermöglichen, bzw. sie zum Resultat haben. Erst wenn die Mitarbeiter selbst entscheiden können (und müssen) welche Arbeit sie bis wann erledigen wollen wird sich überall die entsprechende Kultur herausbilden. Das kann man so sehen, es kollidiert aber z.T. mit anderen Sichtweisen (zum nächsten Absatz bitte).

  • Lars Vollmer: Organisationskultur ist keine Frage der Entscheidungen

    Man kann sich mit vollem Recht fragen: warum muss eine Firma immer eine einheitliche Organisationskultur haben? Sind die Menschen dafür nicht zu unterschiedlich? Und hätte das nicht zur Folge, dass ein Teil der Mitarbeiter sich immer verbiegen muss um den Erfordernissen der Firmenkultur zu entsprechen? Vollmer erklärt das hier am Beispiel von zwei unterschiedlichen Abteilungen (Elektrotechniker und Biologen), aber selbst innerhalb einzelner Abteilungen kann man die Frage stellen wie zielführend eine Einheitskultur ist. Welche Auswirkungen eine Vereinheitlichung auch da haben kann hat fast zeitgleich Sal Freudenberg unter der treffenden Überschrift When the culture becomes the cult aufgeschrieben. Nicht zum Nachmachen empfohlen.

  • Zeit: Der Mitarbeiter, das Versuchskaninchen?

    Menschenversuche. Klingt böse, ist aber letztendlich nichts anderes als die konsequente Umsetzung von Inspect & Adapt in der Organisationsentwicklung. Was Nico Rose hier schreibt ist nämlich State of the Art der Wissenschaft: nur durch den Vergleich mehrerer Versuchsgruppen kann man erkennen, welche Lösungsansätze funktionieren und welche nicht. Und darüber hinaus: nur durch eine zufällige Auswahl nicht eingeweihter Probanden lassen sich Laboreffekte vermeiden. In der Realität großer Organisationen dürften solche Experimente allerdings an der Geheimhaltung scheitern. Was dagegen vorkommen kann ist das Arbeiten nach verschiedenen Methoden aufgrund politischer und/oder historischer Ursachen. Auch das lässt sich auswerten: Ich habe einmal ein Nebeneinander von agilen und nichtagilen Teams erleben dürfen. Am Ende waren die agilen Teams den anderen um ein Jahr voraus.

  • Retrospective.co: Brilliant Jerks Cost More Than They Are Worth

    Vor einigen Jahren war es ein kurzzeitiger Hype bei einigen meiner Kunden "Rockstars" anzuheuern, worunter Entwickler verstanden wurden, die (angeblich) so gut waren, dass sie kritische Situationen im Alleingang retten konnten. Das Problem: sie neigten auch dann zu Alleingängen wenn das gar nicht nötig war und waren dann meistens nicht kritikfähig. Neben den in diesem Artikel genannten zersetzenden Auswirkungen auf die Arbeitsatmosphäre führte das zu verschiedenen Formen von Code Ownership. Meines Wissens nach spielen alle diese "Rockstars" heute Solotourneen.

Mittwoch, 29. März 2017

Walk the Board

FS
Was soll ich sagen? Es ist Frühling, die Sonne scheint und ich habe ein kleines Motivationsloch was das Schreiben betrifft. Zum Glück habe ich noch ein paar Videos als Backup, diesesmal zu einem Thema das einfach scheint aber nicht immer einfach ist: wie führe ich ein Daily Standup durch? Enjoy.



Donnerstag, 23. März 2017

Broken Window

FS
Bild: Pixabay/Taken - CC0 1.0
Wenn kleinere Schäden an einem Objekt nicht sofort behoben werden, werden sich Menschen eingeladen fühlen weitere Beschädigungen an ihm durchzuführen. Unversehrte Objekte werden dagegen mit großer Wahrscheinlichkeit von Vandalismus verschont bleiben. Die Richtigkeit dieser Theorie wurde im Jahr 1969 vom amerikanischen Psychologen Philip Zimbardo anhand zerbrochener Fensterscheiben nachgewiesen, weshalb sie heute als Broken Windows Theory bezeichnet wird. Auch kleine Beschädigungen zu verhindern und ggf. sofort zu reparieren gilt seitdem als effektives Mittel gegen den Verfall und Niedergang von sozial gefährdeten Nachbarschaften und Stadtteilen.

Die Broken Windows Theory ist allerdings nicht auf die Stadtsoziologie beschränkt sondern lässt sich auch auf das Change Management übertragen: wenn eine neue Methode (egal ob agil oder nicht) eingeführt wird und auf den eingespielten Konzern-Anarchismus trifft entstehen häufig Schneeball-Effekte - sobald an einer Stelle die Vorgaben aufgeweicht werden folgt schnell eine zweite, eine dritte, und so weiter. Tatsächlich ist es auch schwer dagegen zu argumentieren, wenn die Betroffenen die berechtigte Frage stellen "warum müssen wir uns an alles halten und die Nachbarabteilung nicht?". Schon wird ein weiteres mal eine Ausnahme gemacht, und nochmal, und nochmal, bis von der ursprünglichen Idee nichts mehr übrig ist.

Die Alternative besteht darin, auf die Einhaltung der Regeln zu bestehen. Das führt zwar zu einer Vermeidung des Broken Window-Effekts, kann aber schnell andere ungewünschte Auswirkungen haben. In dem Moment in dem die Mitarbeiter das Gefühl haben, dass nur aus Prinzip auf Regeln bestanden wird und nicht weil sie Sinn machen, steigt der Widerstand gegen sie nämlich exponentiell an. Um das zu verhindern muss durchgehend und immer wieder aufs neue erklärt werden warum diese Regeln einen Mehrwert bringen und warum auch "pragmatische Anpassungen" nicht wirklich zielführend sind.

Ein nützlicher Nebeneffekt dieses Vorgehens ist, dass sich die zu verteidigende Methode in einem Prozess der permanenten Überprüfung befindet. Wird dieser angenommen lassen sich zwei Vorteile aus ihm ziehen: zum einen wird sichergestellt, dass der Lösungsansatz tatsächlich noch zu dem Problem passt (wenn nicht sollte man ihn abschaffen), zum anderen lassen sich so Vorgaben identifizieren die nur scheinbar auf die Methode zurückgehen, in Wirklichkeit aber optional sind (vor allem im Fall von Scrum ist das häufig der Fall). Die können ggf. wirklich weggelassen werden, wobei aber erneut klar kommuniziert werden sollte, dass das eben keine Aufweichung des vorgesehenen Vorgehens ist. Wird das vergessen tritt der Broken Window-Effekt nämlich sofort wieder ein.

Montag, 20. März 2017

How to hire an Agile Coach

FS
Bild: Flickr/Mike Mozart - CC BY 2.0
Wenn man sich die Ausschreibungen für die Stellen von Scrum Mastern oder Agile Coaches ansieht (egal ob Festanstellung oder Freelance) sind sie fast immer nach dem selben Muster aufgebaut. Welche Rolle wird gesucht, was sind die Aufgaben, welche Qualifikationen werden erwartet, was sind die Rahmendaten. So weit so gut. Aber: Das Ganze ist in den allermeisten Fällen so allgemein gehalten, dass es auf praktisch jede andere Stellenausschreibung auch zutreffen würde. Ein Beispiel:
Gesucht: Scrum Master für ein Standardsoftware-Projekt im Banking-Umfeld

Aufgaben:
• Methodische Unterstützung eines agilen Projektteams
• Management von Hindernissen und Problemlösungsprozessen
• Moderation von Regelmeetings (Planning, Refinement, Review, Retrospektive)

Qualifikationen:
• Erfahrung als Scrum Master für Software-Entwicklungsprojekte
• Erfahrung in Moderationstechniken
• Erfahrung mit agilen Projekten in einer eher Wasserfall-geprägten Organisation
• Beherrschung der üblichen Tools (Jira, Confluence, HP ALM)
• Optional: Branchenerfahrung

Rahmendaten:
• Projektstart: asap
• Projektdauer: 6 MM++
• Einsatzort: Luxemburg
• Kapazität: Vollzeit 5 Tage, davon max 1 Remotetag
• Sprachkenntnisse: Deutsch, Englisch, optional Französisch
Alles nicht falsch, und trotzdem - alles auch nicht besonders aussagekräftig. Man kann deutlich sehen, dass hier einfach ein standardisierter Textbaustein genommen wurde, bei dem lediglich Branche und Einsatzort angepasst wurden. Welche Herausforderungen hier wirklich warten kann man bestenfalls erahnen. Gerade das wäre aber eigentlich der zentrale Punkt. In einem stark Nachfrage-orientierten Markt sollte man hervorheben warum die zu vergebende Position besonders interessant oder anspruchsvoll ist, nur so zieht man die richtigen Leute an. Und umgekehrt sollte auch zumindest zu erahnen sein ob es ein "Pain in the ass-Job" ist, sonst ist der gefundene Kandidat schnell wieder weg und die Suche muss wieder von vorne beginnen.

Wie man es besser machen kann zeigt eine Ausschreibung die ich vor ein paar Monaten erhalten habe. Offen, ehrlich, anspruchsvoll, individuell und spezifisch. So sah sie aus:
Gesucht: Agile Coach für ein Unternehmen der Energiewirtschaft

Aufgabenstellung:
Das Team hat sich vor einem Jahr entschieden ohne externe Unterstützung auf Scrum umzusteigen. Rückblickend betrachtet keine gute Entscheidung, ein Audit hat ergeben, dass die Methode unvollständig und zum Teil fehlerhaft umgesetzt wurde. Die gelieferten Ergebnisse entsprechen folgerichtig nicht den Erwartungen. Gesucht wird ein Agile Coach der diese Mißstände erkennen und benennen kann, bei ihrer Beseitigung hilft und das Team und die Stakeholder aus ihrer Frustration herausführt.

Qualifikationen:
• Langjährige Erfahrung als Agile Coach oder Scrum Master in komplexen Team-Setups
• Erfahrung in der Restrukturierung fehlerhafter Scrum-Implementationen
• Hohe Methodenkompetenz in Moderation und Konfliktlösung
• Hohe Methodenkompetenz in der Motivation von Teams und Einzelpersonen
• Gute Kommunikations- und Präsentations-Skills
• Starke Persönlichkeit und hohes Durchsetzungsvermögen
• Belastbarkeit und Stressresistenz
• Optional: Erfahrung im Bereich agiles Testen/Testautomatisierung

Rahmendaten:
• Projektstart: asap
• Projektdauer: 10 MM++
• Einsatzort: Frankfurt
• Kapazität: Vollzeit, 5 Tage vor Ort
• Sprachkenntnisse: Deutsch
Ein Knaller. Man muss die Ausschreibung nur einmal lesen und weiss sofort worum es geht: hier wurde beim potentiellen Kunden in großem Maßstab Mist gebaut, der Job wird wirklich, wirklich anstrengend. Aber - wenn man auf der Suche nach einer echten Herausforderung ist und sich einen großen Namen machen will ist man hier genau richtig. Unabhängig davon, dass die Situation sicherlich ein Extremfall ist - mit der offenen Kommunikation der Problemstellung und der in diesem konkreten Fall nötigen Skills ist das hier ein positiver Ausnahmefall. Würden Ausschreibungen immer so formuliert sein würden offene Positionen deutlich besser besetzt werden als es heute häufig der Fall ist.

Donnerstag, 16. März 2017

Scaled Agile: Integrations-Teams

FS
Bild: Flickr/Craig Anderson - CC BY-SA 2.0
Lange Zeit war die Scrum-Welt einfach. Wann immer es darum ging, dass irgendjemand die vielen Rollen der alten Welt in die neue Welt übertragen wollte konnte man auf den Scrum Guide verweisen: es gibt den Product Owner, es gibt den Scrum Master und es gibt das Entwicklungsteam, in dem alle anderen Personen einfache Mitglieder sind. Wie der Guide so schön sagt: Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment. Punkt.

Seit eineinhalb Jahren ist die Sache aber nicht mehr ganz so klar, denn mit dem Nexus-Framework von Ken Schwaber und Scrum.org gibt es erstmals einen Skalierungsansatz der von einem der Verfasser von Scrum stammt, der damit also "quasi-offiziell" ist. Und in dem taucht auf einmal etwas Neues auf, das Integrations-Scrum Team (offiziell "Nexus Integration Team"). Ein Team mit Product Owner, Scrum Master und Team-Mitgliedern, das dafür sorgen soll, dass die Ergebnisse der anderen Teams zusammenpassen. Was jetzt passiert ist war erwartbar - plötzlich kleben sich alle mittleren Manager und Koordinatoren dieses Label auf: die Architekten? Sind ein Integrations-Team. Das Testmanagemet? Ist ein Integrations-Team. Das Rollout-Management? Ist ein Integrations-Team. Und so weiter.

Natürlich ist das nicht das was Nexus will. Nexus Teams sind volatil, sie setzen sich bei Bedarf neu zusammen, ihre Mitglieder arbeiten in den normalen Scrum Teams mit wenn sie dort gebraucht werden und versuchen so viel wie möglich von ihrem Wissen dorthin zu verlagern. Auch der Nexus Guide ist eindeutig: Nexus Integration Team Members ensure that practices and tools are implemented, understood, and used to detect dependencies, and frequently integrate all artifacts to a definition of “Done.” Nexus Integration Team Members are responsible for coaching and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools. Machen wir uns nichts vor - das ist nichts was klassische Management-Teams tun, egal wie sie sich jetzt nennen.

 Was soll man also jetzt machen? Diesen "Etikettenschwindel" enttarnen? Ihn anprangern? Ihn bekämpfen? Vielleicht. Ich würde aber das Gegenteil empfehlen: ihn willkommen zu heissen. Ein unterschätzter Effekt der Selbst-Deklaration zu einem (speziellen) Scrum Team ist nämlich, dass agiles Arbeiten auch dort Einzug hält. Auf einmal müssen auch Architekten, Testmanager, Rollout-Manager und ähnliche Rollen mindestens einmal pro Monat Ergebnisse abliefern. Auf einmal müssen auch sie diese Ergebnisse in Reviews präsentieren. Und auf einmal müssen auch sie sich dem Feedback ihrer Stakeholder stellen - zu denen auch die "einfachen" Scrum Teams gehören. Populistisch gesagt - sie müssen herabsteigen aus ihrem Elfenbeinturm.

Ich korrigiere den letzten Satz. Sie dürfen herabsteigen aus ihrem Elfenbeinturm. Zu denjenigen die am meisten unter ihrer Realitätsferne gelitten haben gehören nämlich die mittleren Manager und Koordinatoren selbst. Statt nur theoretische Konzepte zu entwerfen dürfen sie selbst an der Umsetzung teilhaben. Statt nur final (wenn es oft zu spät ist) Abnahmen durchzuführen können sie frühes Feedback geben und nehmen. Ich habe viele Fälle erlebt in denen die Betroffenen von dieser neuen Art der Zusammenarbeit begeistert waren. Natürlich, es gibt auch Personen die lieber weitergemacht hätten wie bisher und jetzt destruktiv reagieren. Aus meiner (subjektiven) Erfahrung würde ich aber sagen, dass sie die deutliche Minderheit sind.

Montag, 13. März 2017

Remote-Arbeit passt nicht zu agiler Software-Entwicklung

FS
Bild: Startup Stockphotos - CC0 1.0
Eine mitgenommenes Thema vom Barcamp Bonn: die Vereinbarkeit von agiler Software-Entwicklung und Remote-Arbeit. Die Aussage aller Anwesenden - sie ist gering, zumindest wenn man an der hohen Produktivität interessiert ist, wegen der man diese Methoden überhaupt anwendet. Das ist für viele überraschend, da Heimarbeit als irgendwie modern gilt und Scrum & Co auch, weshalb automatisch davon ausgegangen wird, dass beides harmonieren müsste. Tatsächlich sorgt eine Kombination aber eher für Probleme.

Der Grund ist einfach: wenn in kurzen Abständen von 1 - 3 Wochen funktionierende Software erzeugt werden soll, muss während der Arbeitsvorgänge eine schnelle und unkomplizierte Kommunikation möglich sein. Selbst wenn jeder Informationsaustausch um nur 30 Minuten verzögert würde gingen dadurch in Summe ganze Tage verloren - aufgrund der kurzen Zyklen ein zu großer Zeitverlust. Das Ziel muss also sein, die Zusammenarbeit so zu gestalten, dass diese Verluste so weit wie möglich minimiert werden. Dafür gibt es eigentlich nur eine Lösung: Colocation, also das gemeinsame Arbeiten in einem Raum.

Zusammensitzende Teams können Informationen auf die einfachste denkbare Art und Weise verteilen - sie reden miteinander. Ohne Mails, ohne Videokonferenzen, ohne Telefon, ohne Chat. Dass das in einem gemeinsamen Raum auch alle anderen mitbekommen wird nicht nur toleriert sondern ist sogar notwendig: wäre das nicht der Fall müsste man ggf. alle anderen im Anschluss benachrichtigen oder um ihre Meinung bitten, mit erneuten Zeitverlusten als Folge. Natürlich erfordert es Disziplin und Focus, damit nicht ein permanenter Lärmpegel entsteht, erfahrene Teams sind dazu aber in der Lage.

In vielen Firmen kollidiert diese Art zu arbeiten mit Bestrebungen, durch Heimarbeit Büroflächen einzusparen. Letztendlich muss aber klar sein, dass diese Einsparungen nur scheinbare sind. Wer weniger Miete zahlt, dafür aber deutlich an Produktivität verliert, hat seine Situation nicht wirklich verbessert.

Donnerstag, 9. März 2017

Resilience and Antifragility (and Einheit)

FS
Man kennt das: Man klickt auf einen Link, sieht ein Video, ist irgendwie fasziniert und schaut es sich bis zum Ende an. In diesem Fall eine Stunde und zwanzig Minuten.



Was mich auf der Stelle gefesselt hat ist wohl die unwahrscheinliche Kombination dreier Faktoren: des Themas der resilienten und antifragilen Organisationen, des gleichsam faszinierenden wie undefinierbaren Dialekts von David J. Anderson und last but not least des Sakkos von Uli Stieleke, das irgendwie seinen Weg nach Kalifornien gefunden hat. Ein Gesamtkunstwerk.

Montag, 6. März 2017

Deine Muda (ist gar keine)

FS
Bild: Wikimedia Commons - Public Domain
In den seltensten Fällen ist "Agilität" die erste Methode die meine Kunden bei sich eingeführt haben1. Meistens gab es bereits vorher Transitionsversuche, und einer der mir häufig begegnet ist der Richtung Lean Management. In den meisten Fällen ist davon nicht mehr viel übrig, sonst müsste man ja keinen neuen Versuch unternehmen (meine These: wenn Lean Management wirklich funktioniert ist Agilität bereits enthalten, zumindest wenn wir von der IT reden). Wenn überhaupt etwas geblieben ist, ist es meistens ein eher untergeordneter Aspekt, das Vermeiden von Verschwendung (warum das untergeordnet ist kann man hier nachlesen). Im Regelfall wird aber nicht einmal dieser Grundsatz richtig eingesetzt - "das ist Verschwendung" ist eher ein Totschlagargument gegen alles was man nicht versteht.

In der Initiierungsphase von Scrum- oder Kanban-Implementationen sitzen aufgrunddessen oft Stakeholder mit am Tisch für die erstmal alles Neue dem Verdacht unterliegt Verschwendung zu sein2. Plannings alle zwei Wochen? Verschwendung! Retrospektiven? Verschwendung! Backlog Refinements? Verschwendung! Reviews? Verschwendung! Und so weiter. Schließlich wird in dieser Zeit ja nichts produziert. Die Ironie der Geschichte: in anderen Kontexten könnten sie sogar recht haben, beispielsweise bei der Produktion von seriell gefertigter Hardware, oder beim Betrieb eines Callcenters. Dort wo Software entwickelt wird ist es jedoch grundlegend anders.

Anders als im Fall der beiden gerade genannten Beispiele besteht Software-Entwicklung nicht aus der Wiederholung immer gleicher Arbeitsschritte, die so effizient gestaltet sind, dass man von ihnen nicht abweichen sollte. Die kann es nur dort geben wo ein standardisiertes Produkt in hoher Stückzahl auf standardisierte Weise erstellt wird. Bei Software wäre eben das die Verschwendung - warum sollte man den Erstellungsprozess permanent wiederholen, wenn es doch ausreicht den Code einfach mit Copy & Paste zu duplizieren? Dementsprechend macht das auch niemand. Was in Software-Projekten erstellt wird sind Prototypen: noch nie zuvor hat jemand für dieses Problem und mit dieser Technologie eine Lösung gebaut. Bestenfalls gibt es ähnliche Probleme, deren Lösungen man "nur noch" anpassen muss - auch das ist dann aber wieder prototypisch.

Aber heisst das nicht, dass es Lean Management in der IT gar nicht geben kann? Keineswegs! Es sieht hier nur anders aus. Da im Entwicklungsprozess permanent und an allen Enden neue, bis dahin noch nicht voraussagbare Probleme auftauchen benötigt man permanente Analyse- und Lösungs-Prozesse. Diese durch verschiedene Hierarchie- oder Eskalations-Ebenen zu schicken würde zu Overhead führen: entweder wären die oben sitzenden Entscheider permenent überlastet oder es würden so viele von ihnen benötigt, dass sie sich koordinieren müssten, mit Bürokratie als Folge. Das kann also nicht der Weg sein.

Lean in diesem Kontext kann nur bedeuten: permanent auftauchende neuartige und einzigartige Probleme müssen möglichst weit unten in der Hierarchie gefunden, analysiert und behoben werden, und zwar mit möglichst individuellen Lösungen. Das ist dann aber nicht anderes regelmässiges inspect & adapt in Form von Plannings, Retrospektiven, Refinements und Reviews. Mit anderen Worten: in der IT ist Lean von Agil nicht zu trennen. Siehe oben.

Bleibt nur noch eine Frage: was soll die Überschrift dieses Artikels? Die ist ist ein Wortspiel. Sorry, aber manchmal muss das sein.


1Die Diskussion ob Agile eine Methode ich spare ich mir an dieser Stelle
2Ja, mir sind tatsächlich Leute begegnet, die Lean Management und Kanban für unvereinbar gehalten haben

Donnerstag, 2. März 2017

No Estimates

FS
Schon seit einiger Zeit habe ich versprochen etwas zum Thema No Estimates zu veröffentlichen, also zum bewussten Verzicht auf das Schätzen von Aufwand und/oder Komplexität von Arbeitspaketen. Ich mache es mir diesesmal einfach und binde hier einfach Vasco Duarte, den Begründer dieser Bewegung, ein. Praktisch: der Titel seines Vortrags, "How you can predict the release date of your project without estimating" geht auch direkt auf den größten Kritikpunkt ein, dass ohne Schätzungen keine Planung möglich wäre. Das eingebettete Video springt direkt zur 29. Minute, in der das eigentliche Thema beginnt. Wer Zeit hat kann sich auch den Teil davor ansehen, er bietet zusätzlichen Kontext.



Und btw: ich habe No Estimates bereits selbst eingesetzt, es funktioniert wirklich. Warum ich den von mir gecoachten Teams trotzdem eine Storypoint-Estimation empfehle ist ein Thema für sich, dazu schreibe ich irgendwann einen separaten Text.
Powered by Blogger.