Schlagwort-Archive: Scrum

Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

flask-304943_1280Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Product Owner lasst eure Entwickler den Tunnel

Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

 

Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.

 

Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.

Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.

Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.

Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.

Aus der täglichen Retrospektive #3

2014-07-31 12.08.30Unsere Retrospektiven gehen weiter und die Teammitglieder entwickeln meiner Einschätzung nach ein immer besseres Gespür für Impediments. Das ist für mich als Scrum Master besonders erfreulich. Ich habe mir wieder einmal etwas herausgegriffen, von dem ich denke, dass es dem Leser helfen kann.

Es hat sich herausgestellt, dass ein wichtiger Prozess bisher nicht explizit gemacht wurde: Der Go Live.

Das führte unter anderem dazu, dass das Update erst mit mehreren Tagen Verzögerung und teilweise sogar mit Änderungen aus dem neuen Sprint durchgeführt wurde. Darüber hinaus war nicht gewährleistet, dass mit der Codebasis auch die Datenbasis aktualisiert wurde. Deshalb haben wir uns zusammengesetzt, den Prozess besprochen und diesen im Wiki festgehalten.

image

Darin wird klar zw. Daten- und Code- Go Live unterschieden. Damit einhergehen auch unterschiedliche Termine und Verantwortliche. Interessanterweise wurde in der Diskussion deutlich, dass der Prozess noch detailliert visualisiert und kommuniziert werden muss. In Kanban ist das fest als Regel aufgelistet:

                  Visualize Your Workflow

Einen Einblick in unser Wiki und den Prozess werde ich demnächst in Form eines Screencasts auf YouTube und auf meinen Blog stellen. Als Abonnent kriegt ihr das automatisch mit.

Mit welchem Tool verfasst bzw. persistiert ihr eure Regeln? Wer macht das? Wird das kontinuierlich erweitert oder war das nicht mehr notwendig? Ist es euch auch schon öfters passiert, dass ihr feststellen musstet, dass Regeln nicht explizit gemacht und dadurch Probleme verursacht wurden? Gerne könnt ihr mir einen Kommentar schreiben.

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Quelle: FotoliaWelche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

  • Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
  • Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

  • Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
  • Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
  • Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
  • Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
  • Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
  • Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
  • Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
  • Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Wie besetze ich die Rolle des Product Owners

Prinzipiell ist es nie leicht die Rollen in Scrum adäquat zu besetzen. Der Product Owner (PO) ist dabei keine Ausnahme. An dieser Stelle kann ich deshalb keine generellen Empfehlung aussprechen, einfach weil dies meines Erachtens nicht möglich ist. Stattdessen beschreibe ich den Weg, den wir in der Firma heco mit Erfolg gegangen sind.

Einer unserer Administratoren in der IT sprach mich darauf an, dass er mit seinen Aufgaben zum Teil unterfordert ist und sich zum Teil auch noch mehr einbringen wolle. Beim Reflektieren darüber stachen für mich 5 wesentliche Eigenschaften hervor:

  • In seiner aktuellen Aufgabe hatte unser Admin sehr engen und guten Kontakt zu allen Mitarbeitern, die das Produkt (hauseigenes ERP-System) einsetzen
  • Sein Verständnis für Geschäftsprozesse war stark ausgeprägt, was auch seine akademische Karriere (Wirtschaftsgymnasium, DHBW Studium) belegte
  • Seine IT-Kenntnisse machten die Kommunikation mit dem Entwickler Team einfacher
  • Er betreute bereits das Produkt auf technisch administrativer Ebene
  • Er war motiviert und wollte das Produkt aktiv mitgestalten

Klar war aber, dass ihm das fachliche Know How und deshalb auch die konkrete Produktvision fehlen würde. Deshalb waren die ersten zwei Schritte ihn direkt zu der Person zu setzen, die das Produkt bis ins kleinste Detail kannte: Unseren Geschäftsführer. Um den Einlernungsprozess zu beschleunigen, war die erste Aufgabe eine vollständige Dokumentation über alle Schnittstellen zu schreiben – sowohl fachlich (das WAS) als auch technisch (das WIE).

In der anschließenden Retrospektive zeigte sich, dass damit der Lernprozess nicht schnell genug voran kam. Deshalb übertrugen wir ihm die Aufgabe alle User Stories fortan selbst zu erfassen. Wir wichen also von den Empfehlungen der Standardliteratur ab, dass die Entwickler die User Stories schreiben sollen. Für mich eine der besten Entscheidungen überhaupt. Immer wenn er nicht in der Lage war die User Story zu erfassen, egal ob zu formulieren oder gemäß dem Business Value zu priorisieren, musste er mit unserem GF darüber sprechen. Zur Gänze hab ich ihn immer zusammen mit den Fachexperten die zugehörigen Informationen im Unternehmens-Wiki festhalten lassen, also z.B. die erarbeitete Domänen-Sprache (vgl. Ubiquitous Language) oder die Bedienungsanleitung. Konsequenterweise war er auch an allen Meetings anwesend. Dass Informieren der Mitarbeiter in Form von Trainings, Schulungen oder E-Mails vervollständigte die Botschaft: Er ist der PO, an den sich die Belegschaft wenden muss.

Die ersten 4 Monate agierte er als sogenannte Proxy Product Owner, der dem eigentlichen PO (in unserem Falle dem Geschäftsführer) versuchte möglichst viel Arbeit abzunehmen, v.a. wenn dieser nicht die nötige Zeit für die Ausübung seiner Rolle hatte. Der Anlernphase folgte dann das Gespräch mit unserem GF, in welchem er seine PO Position übergab. Das bedeutete in erster Linie: Benötigt das Entwickler Team sofort eine Antwort auf eine Frage, dann hat der neue PO die entsprechende Kompetenz, eine etwaig endgültige Entscheidung zu treffen. Diesen Aspekt möchte ich ganz klar hervorheben, weil er nicht unterschätzt werden darf! Zuvor hatten wir bereits eine 100%ige Verfügbarkeit des PO für das komplette Scrum Team erreicht. Diese beiden Eigenschaften zusammen lieferten einen unglaublichen Impuls für die Entwicklung.

Ein Beispiel hierfür: In der Vergangenheit trauten sich die Kollegen aus den Niederlassungen nicht direkt an unseren Geschäftsführer mit Verbesserungsvorschlägen oder Fehlermeldungen heran. Oftmals wählten sie einen Umweg über mich, jedoch verwies ich immer auf den GF als Product Owner, da ich nicht priorisieren konnte bzw. wollte. Das Problem war mir bereits früher aufgefallen, doch fand ich nie eine zufriedenstellende Lösung. Inzwischen ist eine äußert produktive Feedback Kultur entstanden, bei der die Belegschaft die Umsetzung ihrer Wünsche logischerweise sehr positiv aufnimmt.

Selbstverständlich machte unser PO parallel zur Produktschulung regelmäßig Scrum Schulungen (Inhouse), las Bücher (Empfehlung hier), ging zu Scrum Stammtischen oder machte Webinare. Alternativ kann auch ein externer Berater herangezogen werden, mit dem die ersten Schritte gemeinsam gegangen werden.

 

Mich würde interessieren, wer unter den Lesern mit der unternehmenseigenen Besetzung des PO zufrieden ist. Vor allem in Hinblick auf Verfügbarkeit fürs Team!

Wo findet sich der Quality Manager in Scrum wieder?

Kürzlich sprach ich mit einer Bewerberin, die während ihres Studiums erste Erfahrungen mit Scrum in einem größeren Betrieb gemacht hat. Mit Interesse verfolgte ich ihre Antwort auf die Frage, wie die konkrete Implementierung aussah. Dabei fielen die Bezeichnungen Product Manager und Quality Manager.

Das ist insofern interessant, weil Scrum die beiden Rollen gar nicht kennt. Während der klassische Product Manager in den 3 Rollen Product Owner, Scrum Master und Developer Team aufgeht, sieht das beim Quality Manager anders aus. Wie schon beim Lean Management steckt der Gedanke hinter Scrum, dass die Qualität nicht zum Schluss durch eine Person geprüft werden, sondern dass Qualität im kompletten Entwicklungsprozess von jedem Beteiligten als eigener Anspruch etabliert werden soll. Im Falle eines Autos würde das bedeuten, dass nicht erst das fertige Auto am Ende der Fertigungsstraße auf Qualität geprüft wird. Stattdessen soll kontinuierlich vom Start bis zum Ende an jeder einzelnen Fertigungsstelle der Bearbeiter über die Standards Bescheid wissen und sie kontrollieren. Sollte währenddessen das Produkt dem Anspruch nicht genügen, würde die Fertigungsstraße pausiert und darüber beraten werden, wie es mit dem Fahrzeug weitergehen soll. Kurz gesagt: Wenn das Kind in den Brunnen gefallen ist, muss nicht mehr über die Absicherung des Brunnens gesprochen werden.

Besagter Gedanke wird in Scrum zum Einen über die Definition of Done etabliert. Eine User Story darf erst als erledigt gekennzeichnet werden, wenn der Definition entsprochen wurde. Darin stehen unter anderem Spezifikationen für die automatisierte Testabdeckung, sowie etwaige manuell durchzuführende Tests. Im Übrigen finden sich dort auch Aussagen zur Sicherheit, weil das Absichern einer Anwendung im Nachhinein genauso wenig zielführend ist wie im Falle der Produktqualität.

Darüber hinaus gehört zu einem erfolgreichen Scrum Prozess auch ein Build Server, der automatisiert alle Arten von Tests durchführt und bei jedem Check-In im Versionskontrollsystem (auch das VKS ist Teil der Qualitätssicherung) alle Produktteile integriert.

Das bedeutet, dass die Aufgaben des Quality Managers in Scrum an das Entwickler Team übergehen. Das Team soll schließlich eigenverantwortlich arbeiten und gerade hier zeigt sich, ob sich der Product Owner das richtige Team für seine Vision herausgesucht hat. Oder aber es zeigt sich, dass dem Team gar nicht erlaubt wird so zu arbeiten, wie es das für richtig hält. Hier ist dann der Scrum Master gefragt. Beispielsweise habe ich von Teams gehört, denen der Build Server und das Versionskontrollsystem vorgeschrieben wurde, obwohl die Entwickler klar kommunizierten, dass die Software nicht den Ansprüchen genügt.

Agiler Scrumtisch Heilbronn

Gestern waren mein Kollege aus der Webentwicklung und ich beim Agilen Scrumtisch in Heilbronn.

CIMG4644

 

Die Truppe vor Ort ist ein lockerer, gut gemischter Haufen. Logischerweise wurde der Scrumtisch auch Scrum-like organisiert, d.h. jeder Teilnehmer konnte Backlog Items einreichen. Dabei profitierte ich auch prompt, da sogenannte Stattys Notes verwendet wurden, die es hier gibt. Dabei handelt es sich um eine besondere Art von PostIts. Einfach auf der Webseite nachschauen. Die Seite ist übrigens nach dem Why How What Prinzip von Simon Sinek (“People don’t buy what you do they buy why you do it”) aufgebaut. Das ist umso lustiger, als ich genau darauf gestern im Kontext von Motivation und Produktmarketing zu sprechen kam. Das entsprechende Video, welches ich jedem nur ans Herz legen kann, gibt es hier.

Aber zurück zum Thema: Nachdem alle Backlog Items (Themen) gesammelt wurden, erhielt jeder ein 3-Punkte-Konto, aus welchem er die Items voten konnte. Daraus entstand der Business Value, nach welchem die Items priorisiert wurden. Danach zogen wir ein Item nach dem anderen heraus und diskutierten es. Dabei standen immer initial 10 Minuten zur Verfügung. Benutzt wurde eine Time Timer Uhr. Im Anschluss wurde in die Gruppe gefragt, ob das Thema weiter besprochen oder zum nächsten gewechselt werden soll. Per Handzeichen (Daumen hoch oder runter) entschied die Gruppenmajorität. Fiel die Entscheidung  zur Weiterführung der Diskussion, so gab es weitere 5 Minuten. Dies wiederholte sich dann bis ein Votum gegen das Thema fiel. An dieser Stelle sei mein vorheriger Blogbeitrag Wir arbeiten time boxed erwähnt, der den Vorteil von festen Zeitabschnitten aufgreift. Für mich eine tolle Art den Abend zu gestalten.

Die Gespräche verliefen konstruktiv und vielschichtig. Es gab unterschiedliche Betrachtungsweisen und Lösungsansätze. Einen speziellen Punkt habe ich mir herausgegriffen und in der Xing Scrum Gruppe als Frage eingestellt. Dabei geht es um sogenannte Evaluierungsstories, welche Boris Gloger in einem seiner Bücher erwähnt. Der geneigte Leser ist dazu angehalten sich an dem Gespräch zu beteiligen.

3 interessante Punkte, die ich mitgenommen habe, seien noch in aller Kürze erwähnt:

%d Bloggern gefällt das: