Schlagwort-Archive: Scrum

Wir arbeiten time boxed

Es vergeht selten eine Arbeitswoche ohne eine Besprechung. Die Regel sind mehrere wöchentlich. Umso wichtiger ist es, dass ein Rahmen gefunden wird, der effektive Meetings gewährleistet. Die Chefs von Google hatten in ihrer Anfangszeit z.B. das parallele Arbeiten am Smartphone eingeführt. Diesen Schritt haben sie selbst erst kürzlich wieder rückgängig gemacht, d.h. beim Suchmaschinenriesen herrscht jetzt Handyverbot während den Sitzungen.

Ich möchte an dieser Stelle auf feste Anfangs- und Endzeiten eingehen, englisch ‘time boxed’ genannt, und erklären, warum wir inzwischen ausschließlich auf diese Art Besprechungen führen:

  • Die Konzentration ist höher, da in der gegebenen Zeit der Inhalt durchgesprochen werden muss. Der Moderator (bzw. Scrum Master in entsprechenden Teams) sollte darauf achten die besonders redseligen immer wieder zurück in die Spur zu bringen. Bei massiven Problemen können Redezeiten oder Sprechbälle als Werkzeuge helfen. Bei uns klappt es allerdings recht gut, wenn die Person direkt mit dem Hinweis adressiert wird, dass uns die Zeit ausgeht. Ich habe eine deutlich stärkere Fokussierung und somit bessere Effizienz bei uns festgestellt.
  • Es werden weniger unnötige Informationen ausgetauscht. Unnötig im Sinne von nicht für alle relevant. In diesem Punkt ist ebenfalls der Moderator gefragt. Einfach die Bitte an die betroffenen Teilnehmer richten sich im Anschluss zusammenzusetzen.
  • Die Zeitersparnis, die mit Warten regelrecht verbraten wird, ist enorm. Je häufiger Meetings stattfinden und desto mehr Mitarbeiter daran beteiligt sind, desto höher ist die Ausbeute. Früher war es bei uns häufig der Fall, dass ein Teil der Gruppe durch ihr Warten kostbare Arbeitszeit verlor. Auf die Personalkosten möchte ich erst gar nicht eingehen.
  • Pünktlich zu kommen ist auch ein Zeichen des Respekts bzw. der Höflichkeit.
  • Für mich ist Pünktlichkeit auch ein Anzeichen für die Qualität des Selbstmanagements. Wenn wir externe Berater zu Gast haben und diese sich häufig oder besonders lange verspäten, dann stellt sich für mich immer die Frage wie zuverlässig sie beim Abliefern der Ergebnisse sind.
  • Durch fest definierte Endzeiten wird es überhaupt erst möglich verlässlich zu planen. Wenn ich beispielsweise beim Kollegen, der mir seinen Kalender freigegeben habe, sehe, dass sein Meeting bis 15 Uhr dauert, er dann aber 30 Minuten später immer noch nicht wieder am Platz sitzt, dann ist das für mich, der um 15.30 Uhr eine Besprechung hat, gelinde gesagt ungünstig. Mir wäre es dann auch nie möglich mit ihm direkt im Anschluss einen weiteren Termin zu vereinbaren, da ich immer damit rechnen muss, dass er nicht pünktlich sein kann.
  • Besprechungsräume sind bei uns wie vermutlich auch in anderen Unternehmen eine begrenzte Ressource. Wir arbeiten mit der in Outlook verfügbaren Verwaltung, um diese effektiv auszulasten. Das kann nur funktionieren, wenn time boxed vorgegangen wird.

Gerne würde ich noch weitere Punkte aufnehmen. Einfach in die Kommentare schreiben.

 

Als Hinweis sei noch mitgegeben, was bei der Umsetzung hilft:130618 141116 DSCI2486

  • Eine gewisse Unzufriedenheit mit dem aktuellen Ablauf
  • Disziplin
  • Einen guten Moderator (Scrum Master)
  • Eine Uhr (z.B. Time Timer wie im Bild)
Advertisements

Certified Scrum Product Owner Schulung

Im Zeitraum vom 18. bis 20. Juni nach ich an einer Certified Scrum Product Owner Schulung bei den Trainern Dr. Jürgen Hoffmann und Peter Beck teil. Den Kurs hatte über die wibas GmbH gebucht. Als Veranstaltungsort wählte ich die NTT DATA Ettlingen Academy.

 

Location

Das Angebot an kostenfreien Parkplätzen war optimal, sodass unnötig langes Suchen am frühen Morgen ausblieb. Die verfügbaren Räume waren schön hell mit genügend Platz für die knapp 20 Kursteilnehmer. Leider mangelte es an einer Klimaanlage, was mir bei tropischen 35°C besonders negativ auffiel. In den kleinen Pausen konnte man sich mit frischem Obst und Gebäck stärken; zur Mittagszeit gab es Essen in der Kantine, welche einen schönen Balkon mit Teich zur geistigen Erholung bot.  Bedenkt man die kurze Strecke für Karlsruher war es geradezu ideal..

 

Die Trainer

Eine kurze Recherche ergab, dass es sich um zwei etablierte, langjährige Trainer handelte, die in der Community recht arriviert sind. Deshalb bekamen die Teilnehmer das, was sie vermutlich am meisten hören wollten: Praxisberichte. Die Frage “Wie habt ihr das bei euch gemacht” kam so ziemlich jedem über die Lippen. Hierfür gibt es von mir “volle Punktzahl”. Die Aussagen waren klar, die didaktischen Methoden variierten in einem gesunden Maße und durch die Backlogs der einzelnen Gruppen konnte jeder in die Themenfokussierung eingreifen. Negativ fielen mir folgende Dinge auf:

Aufgrund meiner T-Shirt Wahl, welche meine Entwicklerwurzeln offen zeigte, wurde wohl der Eindruck bei den Trainern perpetuiert, dass man mich auch als solchen “coachen” sollte. Zumindest empfand ich dies teilweise so bei Gesprächen. Als ich mich zur Aussage, dass es gängige Praxis sei die Entwickler die Product Backlog Items schreiben zu lassen, kritisch äußerte und darüber diskutieren wollte, wurde dies einfach abgetan. Inzwischen habe ich vermehrt in der Community, unter anderem am .NET Open Space, das Thema aufgeworfen. Mein Resümee: Gängige Praxis sieht anders aus. Allerdings möchte ich fairerweise an dieser Stelle anmerken, dass selbst in der Fachliteratur (u.a. im Werk von Boris Gloger) ähnliche Aussagen stehen. Mir geht es jedoch darum, dass ich mich eine Schublade gesteckt sah, sodass eine konstruktive Diskussion in diesem konkreten Fall nicht zu Stande kam.

Ein weiterer Punkt waren ein paar wenige (!) fragwürdige Aussagen. Eine davon implizierte, dass die Definition of Done immanent unvollständig sein müsse, wenn das Produkt keine 100%ige Evolvierbarkeit aufweise.

Rein subjektiv gefielen mir die ausgewählten Planspiele nicht. Das lag vielleicht daran, dass es sich nicht um Geschäftsprozesse handelte. Vielleicht auch an den konkret gewählten Szenarien, wie das Bauen eines Lego-Parks für Kinder. Bei der zu Beginn gewählten Teambildungsmaßnahme mussten Seesterne gelegt werden. Eine gängige Praxis, wie ich von Bekannten mit selbiger Zertifizierung erfahren habe. Allerdings wurde es so umgesetzt, dass die Teams bereits blind in den Raum kommen, die Materialien finden und Position begeben mussten. Wenn aber die erste Gruppe direkt am Eingang stehen bleibt, dann ist das Resultat, dass mehrere Teams vorerst einfach rumstehen müssen, bis der erste Durchgang beendet wurde. Der Lerneffekt ist für mich genauso gegeben, wenn die Teams bereits im Raum mit den Materialien platziert wären. Sehr positiv wiederum kann ich über das Fallbeispiel zur Schätzung in Story Points im warmen Garten berichten. Die Teams sollten sich hierbei auf die Komplexität zum Entfernen von Gegenständen für den bevorstehenden Besuch von Obama (der an diesem Tag tatsächlich in Berlin war) einigen. Das fing bei Aschenbechern an, ging über Tische und hörte bei Autos auf.

 

Zur Schulung

Als einziges Angebot, welches ich in der näheren Umgebung finden konnte, ging dieser Kurs über 3 Tage. Die üblichen Schulungen sind in der Regel auf 2 Tage ausgelegt. Planspiele sind aber relativ zeitaufwendig und der Wunsch nach Erfahrungsberichten der Trainer führt zu starken Verzögerungen. Deshalb kann ich nur jedem empfehlen 3-tägige Seminare zu bevorzugen.

Die Kosten lagen auf gängigem Marktniveau. Bei entsprechendem Vorlauf wird Frühbucherrabatt gewährt.

Als Schulungszeiten waren 10-18 Uhr am ersten Tag und 9-17 Uhr an den darauffolgenden Tagen geplant. Diese wurden recht gut eingehalten, was nach meiner Erfahrung bei Schulungen sonst nur selten funktioniert.

Bereits vor Kursbeginn erhielt ich eine E-Mail mit Vorschlägen zur Vorbereitung. Während der Schulung wurde ein eigens dafür eingerichteter DropBox Ordner kontinuierlich aktualisiert. Darin landeten neben kostenlosen Ebooks die Fotoaufnahmen der erstellten Materialien (quasi eine Timeline der Flip Chart Blätter), sowie diverse Vorlagen und weiterführende Materialien. Ein dediziertes Dokument mit den erarbeiteten Inhalten gab es nicht.

Das klar kommunizierte Ziel war es jeden in die Lage zu versetzen, entscheiden zu können, ob Scrum mit seinen Prinzipien und Werten für das eigene Unternehmen geeignet ist und sich etablieren lässt. Der Fokus lag natürlich auf der Rolle des Product Owners, ist aber auch nach Aussagen der Trainer mit der des Scrum Master zu 80-90% deckungsgleich. Die restlichen 10-20% wurden dann aber speziell hervorgehoben bzw. ggf. auch intensiver erörtert.

Wer viele Planspiele, viel Eigenarbeit, viel Stehen und wenig PowerPoint Slides bevorzugt, kommt definitiv auf seine Kosten. Mir persönlich hätte ein wenig mehr “klassische” Schulung mit theorielastigerem Vorgehen besser zugesagt. Nach meinem Gefühl kommen dadurch mehr Fragen auf, v.a. abseits der der trivialen Oberflächenthemen. Das bestätigte sich für mich im Nachhinein beim Lesen der oben genannten Lektüre von Boris Gloger wieder. (Wenn Folien übrigens schlecht sind, dann weil der Autor Fehler gemacht hat, nicht weil diese per sé schlecht sein müssen, siehe meine Buchempfehlung.) Allerdings verhält es sich so, dass ich nach einer theorielastigen Sitzung der Einzige war,  der diese positiv bewertete. Deswegen gilt: Die Schulung muss nach der eigenen Präferenz ausgewählt werden.

 

Fazit

Auf einer Skala von 1 bis 10 gibt es von mir eine 7 mit dem klaren Hinweis, dass ich die Schulung für Menschen mit anderem Lernmodus durchaus bei 9-10 sehen würde. Darüber hinaus halte ich eine derartige Schulung für ganze Scrum Teams durchaus für förderlich, speziell wenn sich Fallbeispiele und Themen mitbestimmen lassen. Es bleibt ein positiver Rückblick mit kleinen Makeln und dem Ratschlag, dass auch das Seminar das Lesen entsprechender Fachliteratur nicht ersetzt (vice versa!).

4 Akronyme für Scrum

Diese 4 Akronyme sind hilfreiche Eselbrücken in Scrum.

 

MoSCoW

  • M – Must have this requirement to meet the business needs
  • S –  Should have this requirement if possible, but project success does not rely on it
  • C –  Could have this requirement if it does not affect anything else in the project
  • W – Would like to have this requirement later, but it won’t be delivered this time

 

130619 144705 DSCI2561Mit der MoSCoW Methode werden die Stories im Product Backlog in 4 grobe Priorisierungen aufgeteilt. Das ist v.a. bei der Initialisierung des Product Backlog und bei der Release Planung hilfreich.

Sind beispielsweise alle Product Backlog Items aus dem Bereich Must Have implementiert, könnte ggf. das Produkt einen so hohen Business Value haben, dass ein öffentlicher Release möglich ist.

Bedenkt aber, dass es sich nur um eine erste grobe Einteilung handelt und trotzdem jedes Item früher oder später eine eindeutige Priorisierung erhalten muss.

 

 

 

Deep130619 132854 DSCI2549

  • D – Detailed Appropriately
  • E – Estimated
  • E – Emergent
  • P – Prioritized

 

Das Deep Akronym ist im Kontext des Product Backlog und welche Merkmale dieses aufweisen sollte hilfreich. Die Begriffe sprechen für sich.

 

 

 

130619 141014 DSCI2552Invest

  • I – Independent
  • N – Negotiable and Negotiated
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

 

Mit dem Invest Akronym wird festgehalten, wann User Stories “wohlgeformt” sind. Denkt daran, dass eine User Story ein “Versprechen für eine Konversation” darstellen soll.

 

SMART

  • S –  Specific
  • M – Measurable
  • A – Achievable
  • R – Relevant
  • T – Time-boxed

SMART als Akronym gibt es in vielen Kontexten, unter anderem bei Mitarbeitergesprächen. Dabei macht es immer eine Aussage darüber, wie Ziele formuliert sein sollen. Wenn es bei Scrum also um Ziele geht, z.B. dem Sprint Goal, dann findet man in diesem Akronym Hilfe.

 

Die Sache mit den Entscheidern – Lean Management

Im ersten Teil habe ich mich mit Pair Programming beschäftigt. Auf dem .NET Open Space Süd kam natürlich auch das Dauerbrennerthema agiles Projektmanagement auf. Deshalb geht es in diesem Artikel genau darum, d.h. nicht um Scrum als eine Ausprägung davon, sondern um die Konzepte dahinter und wie sich diese den verantwortlichen Stellen verkaufen lassen.

Persönlich denke ich, dass sich die Ideen dahinter auch zum großen Teil umsetzen lassen, ohne dass der Prozess vollständig implementiert werden muss. Das könnte die Basis für eine offene Diskussion sein, denn viele Projektmanager (PMs) winken bereits ab, wenn sie Begriffe wie Agilität und Scrum hören.

Fangen wir doch mit dem Work In Progress (WIP) an: Statt an 10 Projekten gleichzeitig zu arbeiten, die erst nach 10 Monaten einsatzbereit sind, ist es betriebswirtschaftlich gesehen immer sinnvoller, ein Projekt nach dem anderen zu realisieren. Bündelt man die Arbeitskraft, wäre je ein Projekt nach einem Monat fertig (vereinfachte Rechnung…), sodass beispielsweise 3 Module nach 3 Monaten effektiv eingesetzt werden und Kosten eingespart bzw. Gewinne maximiert werden könnten. Diese Argumentation dürfte einfach zu gewinnen sein, wenn denn der PM rudimentäre Kenntnisse im Projektmanagement besitzt.

Bei der Projektplanung wird nicht über die innere Qualität diskutiert, d.h. Debatten wie ‘dann machen Sie es erst einmal Quick and Dirty, damit wir Zeit sparen’ entfallen. Mit der Fachabteilung wird lediglich der Umfang verhandelt, sprich wenn Zeit eingespart werden soll, dann nicht durch schlechteren Code, sondern durch weniger Features. Diese Diskussion könnte schon schwieriger zu gewinnen sein. Wenn der PM über längere Berufserfahrung verfügt, dürfte eine ehrliche Betrachtung der Vergangenheitswerte ihn aber ebenfalls zur Einsicht bringen. In jedem Fall – auch unabhängig von der Praxiserfahrung – können hier Beispiele aus dem privaten Leben fruchten: Wenn das Auto nur provisorisch repariert wird, dann folgt das böse Erwachen meistens früher als später.

Regelmäßige Meetings (alle 1-2 Wochen) ergeben sich allein schon aus der schnellen Entwicklung der geschäftlichen Prozesse. Wer aber auch hier Überzeugungsarbeit leisten muss, der könnte sich von dem PM bzw. der Fachabteilung das Spiel Tic Tac Toe erläutern lassen. Mir scheint es unrealistisch, selbst bei diesem einfachen Szenario, dass immer an alles gedacht wird. Was passiert, wenn ein Spieler gewonnen hat? Soll automatisch ein neues Spiel gestartet werden, soll eine Gewinnmeldung ausgegeben werden, etc.. Hierzu gibt es einen Artikel in der dotnet pro, in welchem besagtes Spiel auseinander genommen und aus diesem Kontext heraus beleuchtet wird. Viele der Fragen tauchen erst im Verlauf der Entwicklung auf, sodass ein großes Meeting, in welchem alles besprochen werden kann, zw. unrealistisch bis unmöglich schwankt.

Planungssicherheit ist ein Schlagwort, welches im Kontext des Wasserfallmodells völlig fehl am Platze ist. Welches Projekt, das auf 2, 5 oder 10 Jahre angelegt war, konnte tatsächlich die Rahmenplanung (Kosten, Zeit) einhalten. Die Zahl dürfte gegen 0 gehen. Vergangenheitsbetrachtungen dürften hier auch schnell Aufschluss geben. Es existieren keine Referenzprojekte? In der Tagesschau hört man wöchentlich von solchen, sei es nun der Bau eines neuen Flughafens oder die Einführung eines Mautsystems. Durch die kurzen Iterationen erreicht man schnell (meistens innerhalb von 8-12 Wochen) einen guten Eindruck dafür, was innerhalb von 2 Wochen erreichbar ist. Was scheint nun plausibler? Eine Planung, die auf Vergangenheitswerten beruht und die vom Kleinen ins Große rechnet oder der umgekehrte Weg, bei welchem 2 Jahre angesetzt werden und dann muss das Projekt abgeschlossen sein? Lieber den Spatz in der Hand oder die Taube auf dem Dach?

Zusammenfassend lässt sich sagen, dass es vielleicht langfristig mehr von Erfolg gekrönt ist, wenn sukzessive einzelne Punkte aus dem agilen Projektmanagement integriert werden, ohne diese vor dem PM als agil zu deklarieren. Wenn dann sowieso bereits zu 50% nach der entsprechenden Ideologie gehandelt wird, wäre ein Scrum Buch vielleicht das passende Geburtstagsgeschenk für den PM. Beim Lesen sollte es ihm/ihr dann wie Schuppen aus den Haaren fallen. Idealerweise hält der PM dann eure Idee noch für seine eigene…

Die Sache mit den Entscheidern – Pair Programming

Vergangenes Wochenende war wieder .NET Open Space Süd in Karlsruhe. Es zeichnete sich das gleiche Bild ab wie bereits in Leipzig 2011: Ein steigender Teil der Entwickler ist unzufrieden. Als Hauptursache meine ich folgende Punkte identifiziert zu haben:

  • Innovationen werden durch den CIO/CTO gänzlich abgelehnt
  • Neue Wege werden von der GL nur halb mitgegangen, solange sie noch “angenehm” zu gehen sind
  • Frische Ansätze werden vorsätzlich sabotiert, z.T. durch das Team

Dementsprechend trifft das dann die sogenannten “schöpferischen Zerstörer” (Buchreferenz fehlt mir aktuell), d.h. kreative, innovative Menschen, die den Status Quo und all seine negativen Mitbringsel aufbrechen wollen.

Betrachtet man die letzten Jahre, so hat sich vieles getan. Zum einen im Prozess- und Projektmanagement, als auch in den dazu passenden Werkzeugen. Zu nennen wäre die Ausrichtung am Lean Management, z.B. in Form von Scrum, oder Continuous Integration (bzw. Continuous Deployment) durch einen Build Server. Clean Code – heutzutage in aller Munde – besagt nicht viel mehr, als dass man sich ständig weiterbilden und Softwareentwicklung als Handwerkskunst verstehen muss.

Stand heute stehen viele Vorgesetzte respektive Entscheider – sei es nun der IT Abteilungsleiter oder Geschäftsführer -  dieser Bewegung entweder skeptisch oder gänzlich ablehnend gegenüber. Warum auch CIOs eine derartige Haltung einnehmen, ist für mich bis dato nicht nachzuvollziehen. Schließlich sind die Stellenanforderungen an diese Position primär Kreativität, innovatives und prozessorientiertes Denken, sowie ausgeprägtes Business Alignment.

Deshalb möchte ich in den nächsten Wochen hin und wieder Punkte aufgreifen, welche typischerweise von Entscheidern mit in der Regel altbackenen Argumenten abgelehnt werden. Heute befasse ich mich mit Pair Programming:

Hier ist natürlich als Gegenargument zu hören, dass es betriebswirtschaftlich keinen Sinn macht, wenn zwei Personen an der gleichen Aufgabe arbeiten. Genauer gesagt würde ja nur einer arbeiten und der andere schaut dabei zu. Aber gerade Pair Programming ist ein Musterbeispiel dafür, wie falsch solche Aussagen von entsprechenden Stellen sein können!

Inselwissen ist sicherlich in jeder Firma ein Problem – teilweise vielleicht so groß, dass die Geschäftsleitung gar keine Vorstellung davon hat! Wenn immer zwei Personen an einem Stück Code schreiben, ist dem von Anfang an Einhalt geboten. Wird beim Pair Programming auch noch regelmäßig durchgewechselt, was sich für Teams ab einer Größe von 4 Personen immer anbietet, so ergeben sich weitere Synergieeffekte, da z.B. das Gesamtverständnis für das System gefördert und Doppelentwicklungen vermieden werden.

Als nächster Punkt wäre anzumerken, dass dadurch quasi eine kostenfreie Schulung stattfindet. Nach meiner Erfahrung bietet selbst der einfachste Code Gelegenheit für neues Detailwissen. Als Beispiel diene das Schlüsselwort checked für die Addition zweier Integer-Werte. Darüber hinaus hat jeder Developer sein Spezialgebiet, in welchem er dem Kollegen Wissen vermitteln kann.

Und noch ein Argument darf aus betriebswirtschaftlicher Sicht nicht fehlen: Der Code wird “besser”, d.h. Arbeitszeit für Refactoring, Neuprogrammierung und Nachbesserung wird eingespart. Fehler die früh aufgedeckt werden, sparen bare Münze! Ein toller Spruch hierzu kam am Open Space ebenfalls: Für das Programmieren wird eine Gehirnhälfte im Menschen beansprucht, d.h. wenn zwei Entwickler am selben Problem arbeiten, hat man ein vollständiges Gehirn, welches sich dem Problem annimmt.

All about Scrum

 

Hier ein paar gute Scrum Artikel:

%d Bloggern gefällt das: