Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Irgendwo im Dschungel zwischen jenen, die sich für den Erfolg und Misserfolg eines Unternehmens im Ganzen verantwortlich fühlen, und jenen, die vor sich hin entwickeln, gedeiht eine giftige Frucht – die Ungeduld. Der Grund hierfür, je nach dem, wen man befragt, liegt – wie könnte es anders sein – immer wo anders. Mal sind es die langsamen oder bisweilen auch unwilligen Entwickler, mal sind es die wechselnden Anforderungen, mal ist es der Kunde. Die Liste ist so lang wie unergiebig (ausser man glaubt an Management by Blaming).

Wir sind diesem Phänomen nun auf den Grund gegangen. Was wir gefunden haben, ist sicher nicht die allumfassende, absolute Ursache. Aber sicher ein Aspekt, über den es sich Gedanken zu machen lohnt. Unser Tipp: “Reporting”.

Kaum ein Statusreport, der die Hirarchieebenen hinaufklettert, unterläuft nicht dem “Stille Post Syndrom”. Was sich im Dickicht der Teams als “unhaltbarer Liefertermin” darstellt, wandelt sich zum “lösbaren Impediment”, weiter zum “Releaseplan, der sicher hält, wenn … ” bis hin zur verkürzten “Ampel auf Grün”. Summa summarum eine wachsende Geschichte der Rechtfertigungen und Hoffnungsmache.

Unser Vorschlag: killen Sie jedwede Form von Reporting. Wenden Sie sich, gleich wer Sie sind und was Sie tun, der einzig wirklich wichtigen Frage zu: Was kann ich heute dazu beitragen, dass wir als Team (also alle, die potentiell etwas beitragen können) erfolgreicher werden. Wandeln Sie die Energie Ihrer Ungeduld (die auf allen Seiten nichts als Frustration produziert) in einen produktiven Beitrag. Fangen Sie im Sinne heilender Transparenz an, ernsthaft miteinander zu reden! Und zwar darüber, was es wirklich braucht. Und darüber, was Sie selbst beitragen können. Und schreiben Sie sich mal auf ein Flipchart auf, welche Ihrer Handlungen in den letzten Ihrer Projekte wirklich zu einer Verbesserung geführt hat. Sie werden überrascht sein. Noch besser – fragen Sie Ihre Mitarbeiter, KollegInnen, ihre Teams, welche Ihrer konkreten Handlungen geholfen hat.

Oder – und das gilt vor allem für alle Sandwichmanager: verkriechen Sie sich in Ihrem Büro, schliessen Sie die Augen und hoffen Sie weiterhin, dass das Märchen, das Sie sich über mühseliges Report- und Planschreiben aufgebaut haben, auch morgen noch ihr Team, ihre KollegInnen und Vorgesetzen über die Wirklichkeit hinwegtäuschen kann und dass, wenn das Projektende naht, noch ein unglaubliches Wunder passiert. Vielleicht erhöhen Sie auch den Druck auf die Teams, machen noch mehr Vorgaben und drücken Stories und Anforderungen rein. Dann können Sie wenigstens im Nachhinein darstellen, dass Sie alles getan haben, damit das Ziel doch noch erreicht wird. Oder eben auch nicht.

Jürgen Margetich

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ein Leser meines Blogs hat mich auf folgenden Text hingewiesen:

“Product Backlog. Priorisierte Liste von Anforderungen (→ Requirements) mit zeitlichen Schätzwerten (Estimates) für deren Fertigstellung. Die Einheit der Schätzwerte ist meist der Personentag. Je höher die Priorität einer Anforderung, desto genauer sind tendenziell die Schätzwerte, da der Product Backlog im wesentlichen nach absteigender Priorität abgearbeitet wird.” [1] und mir geschrieben: ”Mir ist jetzt schon oft aufgefallen, dass Erklärungen, die man im Internet findet, oft falsch sind.” [2]

Ohne Alexander Kriegisch [3] nahezutreten, aber hier hat er meiner Meinung eine überalterte Variante des Backlogs beschrieben, die man bei Ken Schwaber [4] findet. Dieses Verständnis der Schätzwerte des Backlogs ist 15 Jahre alt und mittlerweile selbst von Ken Schwaber in Stockholm 2009 revidiert worden. Dennoch gibt es immer noch Consultants und CSTs, die das, was sie einmal erlernt haben, weiterverbreiten. Das ist sicher gar keine böse Absicht, oder mangelnde Beschäftigung mit dem Thema, sondern mit großer Wahrscheinlichkeit auf ihren eingeschränkten Erfahrungsschatz zurückzuführen. Mike Cohn hatte bereits in Agile Estimation and Planning [5] gezeigt, dass das Schätzen keineswegs als eine Schätzung von Aufwänden, sondern von Funktionsumfang zu verstehen ist. Auch wenn im Wikipedia ebenfalls steht:

“The product backlog [... ] is open and editable by anyone and contains rough estimates of both business value and development effort.” [6] Wird es nicht richtiger. Es bleibt eine Variante. Einige Teams fahren damit gut, andere, ohne den Druck, Aufwände schätzen zu müssen, fahren besser.

————-

[1] http://scrum-master.de/Scrum-Glossar/Product_Backlog

[2] Leser meines Blogs, der nicht genannt werden will.

[3] http://scrum-master.de/Ueber_uns

[4] Ken Schwaber, Software Development with Scrum, 2001

[5] Mike Cohn, Agile Estimation and Planning

[6] http://en.wikipedia.org/wiki/Scrum_(development)

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

“Alle guten Worte dieser Welt stehen in Büchern.”
(Chinesisches Sprichwort)

Es ist hilfreich und wichtig sich in der Auseinandersetzung mit Scrum ein Wenig mit der Theorie anzufreunden. Mittlerweile ist der Lektüre reichlich zu finden. Hier einige Vorschläge zum Thema Scrum, Agile Development und Change.

• Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln
• Ken Schwaber, Agile Software Development with Scrum
• Mike Cohn, Agile Estimation and Planning
• Mike Cohn, Succeeding with Agile
• Norman Kerth, Project Retrospectives
• Jeffrey K. Liker, The Toyota Way
• John P. Kotter, Leading Change

Und wem das noch nicht genug ist, hier eine Auswahl weiterer Bücher zum Thema:

• Ken Schwaber, Agile Project Management with Scrum
• Ken Schwaber, The Enterprise and Scrum
• Mike Cohn, User Stories Applied
• Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen
• Ralf Wirdemann, Scrum mit User Stories
• Alistair Cockburn, Chrystal
• Tom Peters, The Tom Peters Seminar
• Diana Larsen, Agile Retrospectives

Viel Spaß beim Lesen und Lernen!

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ich traf Giora Morein [1], den Gründer von BigVisible, einer Bostoner Firma, beim Scrum  Treffen in Orlando 2010. Er zeigte mir seine unglaublich tolle ScrumBoard Anwendung SeeNowDo. Das Ziel von SeeNowDo ist es, eine Aufgabentafel für verteilte Teams zu bieten, sodass jedes Teammitglied seinen Fortschritt bei den Aufgaben melden kann. SeeNowDo ist eine Web Anwendung und gänzlich gratis. Toll zu benutzen und sehr, sehr nett gemacht.

Anfangen

Erwartungsgemäß wird Ihr Einstieg bei der Anwendung sein,  ein Projekt anzulegen. Es ist möglich den Start- und Endpunkt des Projekts zu definieren, die Story-Arten und Story-Unit-Type, voreingestellt sind auch Punkteinheiten. Danach können Sie das Projekt anderen zeigen, indem Sie sie einladen, – sehr unkompliziert.

Danach ist es Zeit für den ersten Durchlauf, – definieren Sie einen Namen, ein Zeitintervall und einen Status.  Es ist auch möglich, Ihre Taskboard-Spalten zu konfigurieren, wie viele und wie sie heißen sollen. Ich empfehle die einfache “To-Do”, “In Progress”, “Done” – Reihe. Bei dieser Funktion können Sie auch verschiedene Farben für Ihre Aufgabenkarten definieren, je nach Kategorie (Kodieren, Testen, Design, etc.).

Das Taskboard

Die Board-Ansicht ist der Platz, wo Sie Ihre eigenen Stories und Aufgaben herstellen können. Es gibt eine Menge Felder, die Sie ausfüllen können, um Ihre Story zu schreiben, aber nur ein Pflichtfeld, das ist der Story-Titel. Auf dem Story-Register Schirm gibt es kein Priority Feld, um eine Priorität zu definieren, muss man nur mit “drag and drop” bei den Story Cards arbeiten, – einfach, schnell und leicht.

So, jetzt können Sie an den Tasks arbeiten und hier gibt es etwas, das mich stört – Taskschätzung in Stunden und wie Sie sich vielleicht schon gedacht haben, ist das verpflichtend, wenn der “Burndown Chart” richtig funktionieren soll. Wenn Ihnen Taskzeitschätzungen egal sind, Sie aber einen voll funktionierenden Burndown Chart möchten, können Sie jeder Task 1 Stunde zuweisen und Ihren Fortschritt mit der Zahl der Aufgaben kontrollieren.

Das Taskboard funktioniert gut und ist visuell gut gelöst, mit “drag and drop” können Sie den Status der Tasks updaten, man kann eine bestimmte Story schließen/ erweitern oder das ganze Board. Das Burndown-Feature  ist einfach und klar, aber wie gesagt, es funktioniert nur auf Basis von Zeitschätzungen für die Tasks.

Conclusio

Ich mag dieses coole Scrum Board Werkzeug wirklich sehr. Es ist raffiniert, hat ein cooles Design und wird mit der Bürde eines verteilten ScrumBoards sehr gut fertig. Es ist nicht mehr und nicht weniger. Gut gemacht!

[1] Giora Morein, ist ein wunderbarer  Certified ScrumTrainer. Er ist klar in seiner Botschaft.

You get SeeNowDo, here: http://www.seenowdo.com/

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ganz egal wie oft ich zu Garr Raynolds [1] Blog: pesentationzen.com [2] gehe, ich bin beeindruckt. Dieses Mal fand er einen sehr coolen Vortrag von Roz Savage [3]. Sie war die erste Frau, die über den Atlantik gerudert ist, und sie wird die erste Frau sein, die den Pazifik überquert haben wird.

Sie berichtet über ihr Abenteuer und dass sie begann, ihr Leben zu ändern, weil sie ein Leben voll von Abenteuern wollte. Viel Spaß beim Anschauen:

www.youtube.com/watch?v=dXqPaHQp4Xw

[1] Garr Reynolds ist derzeit Associate Professor of Management an der Kansai Gaidai University , wo er  Marketing, Global Marketing und Multimedia Presentation Design unterrichtet. Garr ist aktiv in der japanischen  Community und man kann ihn oft zu Themen wie Design, Branding, und effektive  Firmenkommunikation reden hören. www.garrreynolds.com

[2] Der inspirierendste  Blog über  Präsentation und Design, den ich kenne.

[3] Roz ist eine  aktive Umweltschützerin: ihre Botschaft ist,  dass wir  alle  etwas bewirken können.  Sie ist auch stolz darauf,  dass sie mit einer großen Zahl von Umweltorganisationen in Verbindung ist, vgl. ihre Eco Affiliations. www.rozsavage.com

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Die brasilianische Konferenz über Agile Methoden – Agile Brazil 2010 – ist eine gemeinnützige nationale Konferenz, die von den Repräsentanten der wichtigsten brasilianischen Agilen Gemeinschaften organisiert wird. Das Ziel der Veranstaltung ist es, Kommunikation und Kooperation unter seinen Teilnehmerinnen und Teilnehmern zu fördern und die Agile Kultur im ganzen Land zu verbreiten.

Agile Brazil 2010 wird am Hauptcampus von PUCRS in Porto Alegre vom 22.- 25. Juni stattfinden. Dort werden Kurse, Arbeitspräsentationen und Erfahrungsberichte aus ganz Brasilien angeboten werden.

Mehr Information finden Sie hier: http://www.agilebrazil.com

Entschuldigung, ich habe gerade den Text gestohlen, um die Veranstaltung zu bewerben. Ich hoffe, das ist ok. — Boris

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ich hatte am vergangenen Freitag die Freude, am TNG Big Techday in München teilnehmen zu dürfen. Es war insgesamt eine sehr gelungene Veranstaltung mit einem angenehm bunten Publikum und spannenden Themen.

Einer der Beiträge ist besonders im Gedächtnis geblieben: “Woher kommen Software-Fehler?” von Prof. Dr. Andreas Zeller [1] – ein aufs Äußerste amüsanter und vor Allem interessanter Vortrag über den Ursprung, das Entdecken und das Vermeiden von Bugs in der Software Entwicklung.

Herr Prof. Dr. Zeller hat anschaulich gezeigt, wie man mittels “Delta Debugging” Bugs schneller lokalisieren kann. Vor Allem aber auch, wie man durch das Isolieren verschiedener Aspekte besonders fehleranfällige Bereiche in einer Software identifiziert. Zu guter Letzt wurde erklärt, wie es möglich ist, maschinell zu lernen, welche Code- und Prozesseigenschaften in der Vergangenheit mit Fehlern korrelierten und damit Bugs zu vermeiden [2].

Soviel Freude hatte ich schon lange nicht mehr an einem Bug…
Danke Herr Prof. Dr. Zeller!

Karoline Zufelde

[1] http://www.st.cs.uni-saarland.de/zeller/
[2] http://www.whyprogramsfail.com/

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Mike Cohn [1] schrieb in seinem neuesten Buch “Succeeding with Agile” [2], dass es gefährlich ist, etwas „best practice“ zu nennen [Cohn 2009, S.9] und kein guter Grund um Scrum einzuführen. Wenn eine Firma es best practice nennt, kommt die kontinuierliche Verbesserung zum Stillstand. Er bezieht sich auf Taiichi Ohno [3], der sagte, dass Standards gut seien, aber ständig überarbeitet werden müssen.

Ständige Verbesserung ist faktisch nur möglich, wenn man Standards hat. Also wie werden wir mit dem Faktum fertig, dass man einerseits stabile Umgebungen braucht, in denen Leute arbeiten können und dass wir andererseits Veränderung brauchen, um uns verbessern zu können? Ken Schwaber erwähnte vor Jahren eine wundervolle Regel, die ich seit damals in meinen Scrum Anwendungen gebrauche: Eine Regel, eine Art von best practice, ist für die Länge des laufenden Sprints gültig. Alles ist veränderbar. Nichts ist für immer. Mir gefiel diese Idee, weil sie Leuten hilft zu verstehen, was die Regel im Moment bedeutet.

Für mich als Berater und Trainer, der mit Kunden in verschiedenen Kulturen und Regionen gearbeitet hat, hat diese Regel von Ken einen großen Einfluß auf meinen Zugang zu Beratungen gehabt. Als Trainer erzähle ich den Leuten, was die „best practice“ ist. In den Trainings zeigen wir ihnen, wie man sie verwendet. Als Berater wende ich die „best practices“ an um Teams und Abteilungen so schnell wie möglich losstarten zu lassen, im Bewusstsein, dass alles, was wir tun, später veränderbar ist. Wenn wir später nach drei Sprints in die Coachingphase unserer Anwendung kommen, beginnen wir, die Prozesse unserer Arbeit mit den Teams umzuformen und ihnen anzupassen. Zum Beispiel beginnen wir mit Standards wie unserer Scrum Checklist und dann verbessern wir das, was wir haben, um bessere Resultate zu erzielen.

[1] Mike Cohn, ist vielleicht der beste lebende Scrum Experte. Seine Schreib- und Lehrfähigkeiten sind wunderbar. Seine Bücher lesen sich sehr gut. Er ist ein Mitglied des Vorstands der Scrum Alliance und er war der Mitgründer der allerersten Scrum Alliance Inc.

[2] [Cohn 2009] Mike Cohn, Succeeding with Scrum, Addison Wesley 2009

[3] Taiichi Ohno, Schöpfer des Toyota Production Systems. Vgl. auch The Toyota Way, Liker

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In einem Certified ScrumMaster Training, das ich mit Peter Hundermark [1] in Frankfurt vor zwei Wochen hielt, führte er uns in eine nette Übung ein: Die Trust Line.

Sie und Ihr Partner/Partnerin stehen sich gegenüber. Zwischen Ihnen beiden ist eine Linie. Jetzt müssen Sie Ihren Partner/ GegnerIn dazu überreden, seine/ihre Position zu verlassen und auf Ihre Seite der Linie zu kommen. Er/sie wird dasselbe mit Ihnen versuchen. Sie gewinnen, wenn er/sie auf Ihrer Seite ist. Er/sie gewinnt, wenn Sie auf seine/ihre Seite wechseln.

Es gibt natürlich keine richtige Lösung, aber es ist eine wunderbare win-win-Lösung möglich.

[1] Peter Hundermark ist ein bemerkenswerter Certified Scrum Trainer, der in Cape Town, Südafrika, lebt und arbeitet. Ich habe mehrmals mit ihm gearbeitet, nachdem er Scrum-süchtig geworden war. Kontaktieren Sie ihn unter www.scrumsense.com oder  wenn sie mit ihm in Europa arbeiten wollen, kontaktieren Sie uns direkt.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In ihrem Meeting am 20. Mai hat die Scrum Alliance (SA) einen neuen Zertifizierungsprozess zum CST beschlossen, der mit 1. Juni 2010 in Kraft tritt. Im Rahmen dessen wurde auch der Prozess zur Verlängerung einer CST Zertifizierung fixiert:

Alle bereits bestehenden CST Lizenzen verlieren erst ab 31. Dezember 2010 ihre Gültigkeit. Nach diesem Zeitpunkt werden diese Lizenzen quartalsweise temporär verlängert, bis der offizielle Verlängerungsprozess abgeschlossen ist. Damit ist also eine Verlängerung vor dem 31. März 2011 derzeit nicht nötig.

Jeder CST bekommt eine dreimonatige Frist zum vollständigen Abschließen des Prozesses der Zertifizierungsverlängerung. Dieser wird sich inhaltlich am Neuzertifizierungsprozess anlehnen, jedoch ein wenig reduzierter ausfallen.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In vielen Unternehmen geht mit der Einführung von Scrum eine deutliche Steigerung der Kommunikation einher – im Scrum-Team selbst aber auch zwischen den verschiedenen Teams. Dazu ein Auszug aus “the twelve Principles behind the Agile Manifesto”: “The most efficient and effective method of conveying information to and within a development team is face-to-face Konversation.”

Was macht gesteigerte Kommunikation eigentlich so erstrebenswert? Kann man denn Dokumente und Protokolle nicht viel besser überwachen?

Ein offensichtlicher Vorteil des direkten Dialoges, ist die Minimierung von Missverständnissen. In wenigen gesprochenen Worten lässt sich so viel mehr vermitteln als in seitenlangen Ausführungen. Zudem stärkt eine Konversation den Team-Zusammenhalt. Ein wichtiger Grund für die Nutzung von Post-its und Flipcharts anstelle digitaler Medien in Scrum  ist die Förderung der direkten Kommunikation.

Das Team ist vor Allem im Rahmen der Planning Meetings gefordert, Dinge zu hinterfragen und selbst zu verstehen, anstatt sie hinzunehmen, wie es bei seitenlangen Dokumenten üblich ist. Damit übernimmt es bereits Verantwortung für das Produkt. Die Maxime der Übernahme von Verantwortung und die Selbstorganisation im Team ist ein Grundbaustein für die gesteigerte Qualität und ständige Verbesserung der Arbeit.

Darüber hinaus führt die Selbstorganisation bei den Mitarbeitern zu einer verbesserten Identifikation mit der Arbeit. Damit steigt die Zufriedenheit im Job, die Mitarbeiter werden weniger häufig das Unternehmen verlassen. Außerdem führt das Umhängen von Taskzetteln auf “Done” zu kleinen Erfolgserlebnissen, welche sonst im Arbeits-Alltag allzu leicht verloren gehen. Das Team kann die Geschehnisse und den Sinn seiner Arbeit wieder spüren. Ist das nicht Grund genug?

[1] http://agilemanifesto.org
[2] Mike Cohn, Succeeding with Agile, Addison-Wesley, 2010

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Eine kurze Kundenerfahrung über das Arbeiten mit einem Scrum Team.

Ich bin kein Held im Zahnarztstuhl. Gestern besuchte ich meine neue Ärztin. Sie ist eine junge und hübsche Frau, so wie ihre Assitentinnen. Sobald Sie zu arbeiten begann, kamen Furcht und Unsicherheit in mir hoch. Die Bohrer ähnelten den Maschinen aus MATRIX. Jedoch, ich bin nicht Neo. Üblicherweise fühle ich mich übel.

Aber nicht gestern.

Ich wurde durch die gesamte Prozedur geführt. Ich fühlte mich miteinbezogen, wo ich doch sonst immer nur der Klient war – “der Nächste bitte” – zumindest bei meinem früheren Arzt. Denken Sie darüber nach! Von der Sicht des Kunden aus gesehen.

Ein Kunde.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Den meisten Veränderungsprozessen liegen in der Regel sehr gute Gedanken und Ideen zugrunde. Dennoch scheitern Unternehmen an den unterschiedlichsten Hürden. Auch bei der Einführung von Scrum muss Einiges bedacht werden, um aus der Euphorie Einzelner eine langfristige Veränderung zu machen.

Zu den häufigsten Fehlern beim Change Management zählt John P. Kotter (1996) unter Anderem das Nicht-Vorhanden-Sein einer Vision oder der Mangel an Kommunikation im Zusammenhang mit derselben. Worte und Taten müssen immer wieder vermitteln, warum es wichtig und richtig ist, diesen Wandel zu vollziehen.

Bei der Kommunikation der Veränderung sollte diese auf keinen Fall zu einer Marketing-Kampagne verkommen. Zu oft haben die Mitarbeiter andere Maßnahmen und Projekte miterlebt… was ist von diesen noch übrig seitdem? Vielversprechende Methoden zur Verbreitung von Scrum in größeren Unternehmen, bietet zum Beispiel Mike Cohn. Das Veröffentlichen von Erfolgsgeschichten, oder das Ermöglichen einer „agile Safari“ (quasi ein Schnupperkurs in einem Scrum-Team) sind nur zwei davon.

Hilfreich ist hier auch die Bildung einer „Guiding Coalition“ (Kotter, 1996) – einer kleinen Gruppe, welche die Botschaft in die Teams trägt und die Umsetzung voranbringen soll. Im Zusammenhang mit Scrum empfiehlt es sich hier, mit einem Transition Team zu arbeiten. Eine Handvoll “Pioniere”, die wirklich an die Veränderung glauben, kann weit mehr bewirken, als ein Pamphlet an durchdachten Argumenten im Intranet oder firmen-eigenen Newsletter.

[1] John P. Kotter, Leading Change, Harvard Business School Press, 1996
[2] Mike Cohn, Succeeding with Agile, Addison-Wesley, 2010