Gruppe: SCRUM

Hallo,

aus meiner Projektpraxis als CSM kann ich dem o.g. nur zustimmen.
In einem Sprint und letztlich in jedem Team und Projekt gibt es ungeplante Einflüsse und Tasks - sei es auch nur organisatorisches, die den Ablauf beeinflussen.
Eine Ressourcenkalkulation mit einer netto Verfügbarkeit um ca. 70% ist eine gute Planungsgrösse.
Ich habe in meinen Sprints auch +/-30% als Puffer für Debug, DevTests und QA eingeplant.
Es bleibt aber nach wie vor die Frage was sind 100% für ein Sprintbacklog?

- Selbsteinschätzung (Team)
- Skills
- Lernkurve

und meine Definition des (Bermuda-)Dreiecks aus SCOPE - TIME - COSTS, welches letzlich in QUALITY endet haben hier Einfluss auf die Sprints und das Gesamtprojekt.


Grüsse
Dieter Langjahr

Dieter Langjahr schrieb:
Ich habe in meinen Sprints auch +/-30% als Puffer für Debug, DevTests und QA eingeplant.
Es bleibt aber nach wie vor die Frage was sind 100% für ein Sprintbacklog?
Ziel des innerhalb von Scrum stattfindenden KVP des Teams soll es sein, daß das Team möglichst früh lernt, realistisch zu schätzen, also übliche Aufwände für Debugging, Tests, Refactoring etc. in die Umsetzungsaufwände für die Stories einzuschätzen bzw. Tasks hierfür zu generieren, sofern mit Tasks gearbeitet wird - Alternative bei fortgeschrittenen Team-PO-Kombinationen wären kleine Stories. D.h., daß Puffer nicht mehr eingeplant werden müssen, sondern daß die Sprint-Planung realistisch ist ohne Kunstgriffe wie Puffer.

Ein anderes Thema ist die Frage, wieviel Prozent der Brutto-Arbeitszeit von 8 Stunden pro Tag tatsächlich produktive Arbeitszeit im Sprint sein können, da es außen herum noch andere Meetings, Consulting- und Support-Aufgaben, Personalgespräche, Kundenanrufe o.ä. geben kann. Hier statt 8 z.B. nur 6 oder 7 Arbeitsstunden anzunehmen, kann Sinn machen, wenn es die Realität widerspiegelt. Achtung, ich spreche hier nicht von Arbeitszeit für andere Projekte, die nach Möglichkeit zu vermeiden ist, sondern vom "normalen"(?), organisations-immanenten Overhead, der dann auch wieder firmen- oder abteilungsspezifisch oder sogar individuell unterschiedlich sein kann.

Nachtrag: Wieso bin ich gegen Puffer? Weil Puffer in den allermeisten Fällen auch verbraucht werden. Das ist menschlich und nennt sich Studentensyndrom. Goldratt bemüht den Begriff z.B. in seiner Engpaßtheorie (Theory of Constraints, kurz ToC).
Dieser Artikel wurde am 04.11.2009 um 00:49 Uhr geändert.

Das ist das elegante daran, mit abstrakten Einheiten zu planen und dann Yesterday's Weather zu benutzen - ich brauche mir um Puffer oder Stunden pro Tag gar keine Gedanken mehr zu machen. Erledigt sich einfach statistisch von selber.

Wenn der PO keine Zeit gefunden hat, die Bugs zu priorisieren - ja, wenn er noch nicht mal ein, zwei nennen kann, die auf jeden Fall behoben werden sollten - wie wichtig kann es dann sein, dass sie noch in diesem Sprint behoben werden?

Hans-Peter Korn schrieb:

Wenn es solche Kausalitäten gibt, welche auch in Zukunft gelten, dann macht das Sinn. Das ist jedoch nur in simplen oder komplizierten Systemen der Fall, nicht aber in komplexen. Und Projektsysteme sind "Soziale Handlungssysteme" und naturgemäss komplex. Und dort trifft das zu (gemäss Cynefin framework):
the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
 
Also: Statt Ursachensuche z.B. mit den "5 x Why" zu betreiben ist es in komplexen Situationen erfolgreicher, Freiräume ("Puffer") für das "Probe - Sense - Respond" zu schaffen.
Das kann ich aus dem Zitat überhaupt nicht herauslesen, im Gegenteil: es impliziert ja genau, dass wir *im Nachhinein* sehr wohl Ursachen feststellen und unsere Handlung für die Zukunft entsprechend adaptieren können und sollten. D.h. wenn ein Defekt auftritt, können wir sehr wohl feststellen, warum wir ihn nicht verhindert haben (z.B. durch five why) und dann Maßnahmen einleiten, um ähnliche Probleme in Zukunft zu verhindern.

Und ich habe von Teams gehört, die es auf diese Art und Weise schaffen, nur noch alle paar Monate mal eine Defekt-Meldung zu bekommen.

Ilja Preuß schrieb:

Das kann ich aus dem Zitat überhaupt nicht herauslesen, im Gegenteil: es impliziert ja genau, dass wir *im Nachhinein* sehr wohl Ursachen feststellen und unsere Handlung für die Zukunft entsprechend adaptieren können und sollten.
Also, wenn Snowden schreibt: " ((in complexity)) the relationship between cause and effect can only be perceived in retrospect, but not in advance" dann beschreibt er das, was für komplexe Systeme auch von anderen "Komplexitätsforschern" als Merkmal "echter" Komplexität beschrieben wird: Sie ist auf Basis Ursache -> Wirkung nicht analysierbar derart, um damit ein Modell für das zukünftige Verhalten zu erstellen.

D.h. wenn ein Defekt auftritt, können wir sehr wohl feststellen, warum wir ihn nicht verhindert haben (z.B. durch five why) und dann Maßnahmen einleiten, um ähnliche Probleme in Zukunft zu verhindern.
Genau das funktioniert bei Defekten in simplen und komplizierten Systeme wie z.B. Fertigungsprozesse. Oder bei trivialen Situationen wie: "Wenn ich vom Büro zum Bus 5 min brauche, dann muss ich spätestens um xx:55 los, um ihn zu erwischen". Oder: "Wenn ich mich darauf verlasse, dass xxx von Norbert getestet wurde, ohne das aber zu überprüfen, dann ist das Risko gross, dass der Test nicht stattfand".
Und aus diesem Kontext stammen auch die "five why" und "TOC".
In komplexen Systemen (wie z.B. sozialen Handlungssytemen) funktioniert das nicht. So etwa sind bei Konflikten im Team derartige "Warum-Fragen" wenig hilfreich - sondern eher ein Auslöser für "Schuldzuweisungen".
Und: Wenn ich im Beispiel "xxx funktionierte nicht .... weil es wurde nicht gestestet .... weil ich mich verlassen habe, dass es Norbert macht .... und weil ich das nicht überprüft habe" kommen wir schon in einen Grenzbereich: Norbert wird dieses "weil ich mich verlassen habe, dass es Norbert macht" möglicherweise als ungerechtfertigten Vorwurf verstehen .... und sich zu wehren beginnen .... und der schönste Konflikt ist da....

Siehe dazu auch das hier:
https://www.xing.com/app/forum?op=redirect;id=25580149;artic...

Hallo Zusammen,

vielem vor mir geschriebenen kann ich zustimmen. Grundsätzlich sehe ich das so, daß eine hohe Anzahl von Fehlern auf Probleme im Team oder in den Anforderungen hinweisen und der einzige Weg dies zu beseitigen eine tiefergehende Ursachenanalyse ist. Dazu muß man aber bereit sein, denn nicht immer sind die Ergebnisse einer solchen Analyse willkommen. Aber das ist ein anderes Team.

Generell würde ich in technische Fehler und fachliche Fehler unterscheiden. Technische Fehler sind Umsetzungsfehler in der Software. Fachliche Fehler weisen auf fehlerhafte Storys und Anforderungen hin, für die das umsetzende Team nichts kann.

Ich bin praktisch immer mit folgendem Vorgehen gut gefahren:

1. Technische Fehler die den aktuellen Fortschritt gefährden werden sofort behoben, wenn der Aufwand dafür überschaubar ist und wird nicht als eigenes Item aufgeführt, denn der Verwaltungsaufwand dafür ist zu hoch. Ausnahme ist, wenn man auch solche Änderungen in der Software in Form von Releasenotes oder Bugfix-Listen zur Verfügungstellen muß.

2. Technische Fehler die nicht den Projektfortschritt gefährden, aber behoben werden sollten, werden zu eigenen Items und damit zum Teil der Planung.

3. Fachliche Fehler werden immer zu einem Item und damit zum Teil der Planung.

Also, zusammengefaßt: Wenn man soviele Fehler hat, daß hier schon ein Teil der Zeit regulär mit eingeplant werden muß, dann liegt das Problem an einer ganz anderen Stelle und das ist nicht die Planung.

Hans-Peter Korn schrieb:

Also, wenn Snowden schreibt: " ((in complexity)) the relationship between cause and effect can only be perceived in retrospect, but not in advance" dann beschreibt er das, was für komplexe Systeme auch von anderen "Komplexitätsforschern" als Merkmal "echter" Komplexität beschrieben wird: Sie ist auf Basis Ursache -> Wirkung nicht analysierbar derart, um damit ein Modell für das zukünftige Verhalten zu erstellen.
Wenn das damit gemeint ist, dann stimme ich wohl nicht damit überein, dass das Verhinden von Bugs im Allgemeinen ein komplexes Problem ist.


Genau das funktioniert bei Defekten in simplen und komplizierten Systeme wie z.B. Fertigungsprozesse. Oder bei trivialen Situationen wie: "Wenn ich vom Büro zum Bus 5 min brauche, dann muss ich spätestens um xx:55 los, um ihn zu erwischen". Oder: "Wenn ich mich darauf verlasse, dass xxx von Norbert getestet wurde, ohne das aber zu überprüfen, dann ist das Risko gross, dass der Test nicht stattfand".
Oder "wenn ich bei Methoden mit for-Schleifen die Randbedingungen mit Unit-Tests abdecke, mache ich keine one-off-Fehler mehr."

Und aus diesem Kontext stammen auch die "five why" und "TOC". In komplexen Systemen (wie z.B. sozialen Handlungssytemen) funktioniert das nicht. So etwa sind bei Konflikten im Team derartige "Warum-Fragen" wenig hilfreich - sondern eher ein Auslöser für "Schuldzuweisungen".
Wobei "verkleidete" Warum-Fragen durchaus sehr hilfreich sein können - "was war Dein Ziel", "was hat Dich bewogen, dass zu tun" etc.

Und: Wenn ich im Beispiel "xxx funktionierte nicht .... weil es wurde nicht gestestet .... weil ich mich verlassen habe, dass es Norbert macht .... und weil ich das nicht überprüft habe" kommen wir schon in einen Grenzbereich: Norbert wird dieses "weil ich mich verlassen habe, dass es Norbert macht" möglicherweise als ungerechtfertigten Vorwurf verstehen .... und sich zu wehren beginnen .... und der schönste Konflikt ist da....
Sicher, ein Team ist ein komplexes System. Und damit es schön adaptiv bleibt, sind Konflikte sogar notwendig - es braucht halt entsprechendes Handwerkszeug um selbige konstruktiv auszutragen. In dem Fall würde ich z.B. dafür sorgen, dass Frank (Name zufällig gewählt) versteht, wie Norbert sich mit dem gesagten fühlt, und Norbert versteht, wie es tatsächlich gemeint war. Vielleicht war es kein Vorwurf, oder vielleicht sieht Frank ihn als gerechtfertigt an. Beides ist wichtig zu klären, um in Zukunft besser miteinander arbeiten zu können.

Das heißt aber nicht, dass es nicht eine Lösung für das allgemeine Problem gibt. In diesem Fall könnte man z.B. die Regel einführen, dass jeder seinen eigenen Code selber testet. Vielleicht gar noch test-first.

Ilja Preuß schrieb:
Wenn das damit gemeint ist, dann stimme ich wohl nicht damit überein, dass das Verhindern von Bugs im Allgemeinen ein komplexes Problem ist.Ja, sehe ich auch so. "Komplexe" Ausnahmen sind für mich z.B. unterschiedliche Interpretationen von Requirements oder das "Übersehen" von sehr komplizierten Zusammenhängen im Code oder zwischen verschiedenen Modulen oder die Unkenntnis über unerwartete Verhaltensweisen von Modulen in seltenen Spezialfällen (für die deshalb auch keine Testfälle erstellt wurden). Das sind typisch "menschliche" Einflüsse - und die können nie ausgeschaltet werden.

Oder "wenn ich bei Methoden mit for-Schleifen die Randbedingungen mit Unit-Tests abdecke, mache ich keine one-off-Fehler mehr."Genau: Das ist ein "linear-mechanischer" Zusammenhang. Und solche Zusammenhänge sind am besten beherrschbar mittels "Sense - Categorise - Respond and we can apply best practice" bzw. "Sense - Analyze - Respond and we can apply good practice". Ein inkrementelles Vorgehen auf Basis "inspect & adapt", also "Probe - Sense - Respond and we can sense emergent practice" wäre dort unangemessen und würde zu Vergeudung von Arbeitszeit führen.
(Nebenbemerkung: Deshalb erachte ich agile Vorgehensweisen für simple und komplizierte Situationen als "overkill".)

So etwa sind bei Konflikten im Team derartige "Warum-Fragen" wenig hilfreich - sondern eher ein Auslöser für "Schuldzuweisungen".
 
Wobei "verkleidete" Warum-Fragen durchaus sehr hilfreich sein können - "was war Dein Ziel", "was hat Dich bewogen, dass zu tun" etc.
Genau! "Der Ton macht die Musik" Und nicht nur der Ton, sondern auch welche "Spielkarten" (= Worte) wir für unser "Sprachspiel" verwenden (siehe Pelle Ehn, Wittgenstein’s Language Games, bei Alistair Cockburn: http://alistair.cockburn.us/ASD+book+extract:+%22Naur,+Ehn,+...)

"was war Dein Ziel", "was hat Dich bewogen, dass zu tun" ist eine "wohlwollende Annahme", dass die andere Person nicht "unvernünftig" handelte, sondern eine Intention verfolgte und mit meiner Frage drücke ich aus, dass ich diese Intention kennenlernen möchte, bin also in der Rolle des "interessiert Lernenden".
Natürlich macht der "Tonfall" einen Unterschied: Wenn ich "was war Dein Ziel" sage und im Hinterkopf denke: "sicher hattest du dir nichts dabei überlegt .. und jetzt will ich dir das mir dieser Frage bewusst machen", dann kommt diese Frage "verhörmässig" rüber.
Eine andere Formulierungen wäre:

"Ich gehe davon aus, dass du damit, dass du es so und nicht anders machtest, einen Nutzen erzielen wolltest. Und ich würde gern mit dir herausfinden, was das für ein Nutzen war und wie er auf einem anderen Weg erreicht werden könnte."

Sicher, ein Team ist ein komplexes System. Und damit es schön adaptiv bleibt, sind Konflikte sogar notwendig - es braucht halt entsprechendes Handwerkszeug um selbige konstruktiv auszutragen.
Nun, für mich ist das einer vielen "beschönigenden Glaubenssätze". Ich unterscheide zwischen einem "Konfiikt" und "als unvereinbar betrachtete Unterschiede" oder "Widersprüche". Ich möchte damit "die übliche emotionale Beipackung", nämlich dass ein Konflikt unangenehm, unbedingt auszuräumen, für die Zusammenarbeit hinderlich .... sei, umgehen. Damit erhalte ich eher die Bereitschaft, diese Unterschiede mal aus Distanz anzusehen statt in "verhärtete Positionen" zu kommen, die dann erst wieder "verflüssigt" werden müssen.

Also: Für mich sind Unterschiede eine Quelle von Energie und Inspiration - solange sie nicht zu "Konflikten" werden.

In dem Fall würde ich z.B. dafür sorgen, dass Frank (Name zufällig gewählt) versteht, wie Norbert sich mit dem gesagten fühlt, und Norbert versteht, wie es tatsächlich gemeint war. Vielleicht war es kein Vorwurf, oder vielleicht sieht Frank ihn als gerechtfertigt an
Beides ist wichtig zu klären, um in Zukunft besser miteinander arbeiten zu können
Ich vermeide es, Gefühle explizit anzusprechen. Das sind (für mich!!!) "Internas der Person" über welche einzig und allein die Person bestimmt. Sie sind für mich nicht Gegenstand des klärenden Dialogs.
Mehr dazu hier: "Inbetween, not inside or outside" (McKergow MW and Korman H (2009), Journal of Systemic Therapies Vol 28 No 2 pp 34 – 49) ==> http://www.sfwork.com/jsp/index.jsp?lnk=6d8

Meine Intention wäre also nicht, dass Frank "versteht wie sich Norbert fühlt". Damit komme ich vollends in "psychologische Innenwelten" - statt zu zukunftstauglichen und pragmatischen Lösungen.

Ich würde ganz einfach auf der Ebene "beobachtbarer Begebenheiten" bleiben - und z.B. so fragen:

"Frank, du bis also davon ausgegangen, dass Norbert das getestet hat. Ich nehme an, dass du dich dabei auf eine Erfahrung aus der Vergangenheit abgestützt hast. Auf welche? Oder auf eine Abmachung? Auf welche?"

---- Frank erzählt so etwas -----

"Norbert: Wie war das ((diese vergangene Situation / diese Abmachung)) aus deiner Sicht?"

---- Norbert erzählt seine - höchstwahrscheinlich unterschiedliche - Sichtweise -----

"Ok. Ich sehe, das sind unterschiedliche Sichtweisen. Für mich es normal, das solche unterschiedlichen Sichtweisen existieren. Nun, Frank und Norbert, wie ist es in Zukunft möglich, solche Unterschiede frühzeitig zu erkennen und zu klären, und zwar konkret für den Fall "wer testet wann was"?"

Das heißt aber nicht, dass es nicht eine Lösung für das allgemeine Problem gibt. In diesem Fall könnte man z.B. die Regel einführen, dass jeder seinen eigenen Code selber testet. Vielleicht gar noch test-first.
Das ist der Unterschied zwischen deiner und meiner Herangehensweise:
Ich thematisiere das konkrete Problem auf der Ebene erlebter und sichtbarer Gegebenheiten und auf dieser Ebene mögliche (schrittweise) konkret sichtbare Lösungen.

Mehr dazu übrigens hier: http://www.korn.ch/LF-auf-einer-Seite.pdf

Und auch hier (Vorsicht!! Eigenwerbung!!): http://www.scrum-day.de/workshops/ws2teamworkrefactoredbysim...

Hans-Peter Korn schrieb:
Ilja Preuß schrieb:
Wenn das damit gemeint ist, dann stimme ich wohl nicht damit überein, dass das Verhindern von Bugs im Allgemeinen ein komplexes Problem ist.
Ja, sehe ich auch so. "Komplexe" Ausnahmen sind für mich z.B. unterschiedliche Interpretationen von Requirements oder das "Übersehen" von sehr komplizierten Zusammenhängen im Code oder zwischen verschiedenen Modulen oder die Unkenntnis über unerwartete Verhaltensweisen von Modulen in seltenen Spezialfällen (für die deshalb auch keine Testfälle erstellt wurden). Das sind typisch "menschliche" Einflüsse - und die können nie ausgeschaltet werden.
Oh, ok. Ich hatte Dich erst so verstanden, dass es grundsätzlich keine großen Sinn macht, zu versuchen sich die Ursachen für Defekte anzuschauen. War wohl ein Missverständnis. :)

"Ich gehe davon aus, dass du damit, dass du es so und nicht anders machtest, einen Nutzen erzielen wolltest. Und ich würde gern mit dir herausfinden, was das für ein Nutzen war und wie er auf einem anderen Weg erreicht werden könnte."
Genau. :) Meine Grundannahme ist eigentlich immer die Retrospective Prime Directive: http://www.retrospectives.com/pages/retroPrimeDirective.html


Also: Für mich sind Unterschiede eine Quelle von Energie und Inspiration - solange sie nicht zu "Konflikten" werden.
Da benutzen wir den Begriff "Konflikt" wohl einfach unterschiedlich.

Ich glaube allerdings nicht, dass sich ein (unangenehmer) Konflikt immer verhindern lässt. Die Gefühle sind manchmal halt einfach da, und dann *nicht* darüber zu sprechen, sondern zu versuchen, rein sachlich zu bleiben, ist nach meiner Erfahrung auch nicht zielführend.

Ich vermeide es, Gefühle explizit anzusprechen. Das sind (für mich!!!) "Internas der Person" über welche einzig und allein die Person bestimmt. Sie sind für mich nicht Gegenstand des klärenden Dialogs.
Ich verstehe noch nicht, wie letzteres aus vorherigem folgt.

Ich habe bisher jedenfalls durchweg gute Erfahrungen damit gemacht, in Dialogen auch meine Gefühle transparent zu machen.

Mehr dazu hier: "Inbetween, not inside or outside" (McKergow MW and Korman H (2009), Journal of Systemic Therapies Vol 28 No 2 pp 34 – 49) ==> http://www.sfwork.com/jsp/index.jsp?lnk=6d8
Sehr interessanter und symphatischer Artikel, danke!


Meine Intention wäre also nicht, dass Frank "versteht wie sich Norbert fühlt". Damit komme ich vollends in "psychologische Innenwelten" - statt zu zukunftstauglichen und pragmatischen Lösungen.
Ich bin ja gar nicht dafür, "vollends in psychologische Innenwelten" abzutauchen. Auf der anderen Seite kann die Erkenntnis "wenn Frank x macht, dann gar nicht weil er sauer auf mich ist, sondern selber unsicher" oder "Frank ist gar nicht sauer auf mich, weil ich so unfähig bin, sondern weil ich ihm nicht gesagt habe, dass ich seine Hilfe brauche" oder... die produktivste des Tages sein, die nicht nur zu einer pragmatischen Lösung für das aktuelle Problem führt, sondern eben auch signifikante Auswirkungen auf die zukünftige Zusammenarbeit hat.

Das heißt aber nicht, dass es nicht eine Lösung für das allgemeine Problem gibt. In diesem Fall könnte man z.B. die Regel einführen, dass jeder seinen eigenen Code selber testet. Vielleicht gar noch test-first.
 
Das ist der Unterschied zwischen deiner und meiner Herangehensweise: Ich thematisiere das konkrete Problem auf der Ebene erlebter und sichtbarer Gegebenheiten und auf dieser Ebene mögliche (schrittweise) konkret sichtbare Lösungen.
OK.

Mehr dazu übrigens hier: http://www.korn.ch/LF-auf-einer-Seite.pdf
Erinnert mich stark an Appreciative Inquiry, mit dem ich auch schon sehr gute Ergebnisse erzielt habe. Ist aber nicht für *jede* Situation das richtige.