Dr. Andrea Tomasini 

• How can you enforce self-management in teams?
• How to make Scrum with non-developer-teams?
• How to handle unplanned interruptions of sprint work?

Die Diskussion wird wegen der Teilnahme einiger nicht Deutsch sprechender Gäste auf Englisch geführt. 

Ich fand besonders den ersten und 3. Topic interessant, der 2. stellte sich leider nicht als das heraus, was die meisten (Wähler) annahmen, nämlich die Arbeit mit sonstigen Projektgruppen, Sales oder Marketing. Der Topic-Owner wollte im speziellen die Zusammenarbeit mit Hardware-Teams diskutieren, die nur für Commitments über ca. 9 Monate bereit waren. diese Diskussion spielte sich dann mehrheitlich zwischen ca.3 Teilnehmern ab.

Zum Thema “How can you enforce self-management in teams?” fand eine interessante und anregende Diskussion statt.

Auf der einen Seite stehen Praktiken wie bei netflicks Inc., deren Angestellte beliebig Urlaub nehmen dürfen , auf der aderen interessen der Firma und Prozessregeln.  Für eine volle Wirksamkeit und Machbarkeit von Selbstorganisation wurden die folgenden Aspekte erarbeitet.

• Es muss ein Ziel, eine Vision, einen Sinn geben.
• Es muss eine Umgebung und Infrastruktur geben, um das Ziel zu erreichen.
• Es müssen constrains (Rahmenbedingungen) gesetzt werden.
• Es muss bei Bedarf Unterstützung gegeben werden. (Team nicht allein lassen)
• Es muss nach einer Weile der Erfolg kontrolliert werden.
  Das heißt zum Beispiel bei wikipedia,

1. Wir wollen eine weltweit verfügbare, aktuelle Enzyklopädie schaffen
2. Mit der Wiki/Browser-Technologie + Internetanschluß steht eine Infrastruktur zur Verfügung, die leicht benutzbar ist,
3. Die Artikel dürfen nicht geklaut sein (Urheberrecht) und müssen wahr sein
4. Es gibt Hilfe-Seiten und Foren für Hilfestellung
5. Leser kontrollieren und können ausbessern/korrigieren/ ergänzen
   Der anwesende Coach für “self-organizing teams” gab noch die folgenden Hinweise mit auf den Weg:

• Selbstorganisation ist nicht erzwingbar, man kann sie nur ermöglichen.
• Die (einzigen) Triebkräfte sind Zweck, Meisterschaft, Selbstbestimmung.
• Meditiert über “A=B”.

Viel Spaß beim Meditieren !

Originally uploaded by DVIDSHUB.

Wenn man ein neues Produkt entwickelt, das erst später nach entsprechenden Qualitätssicherungen zum Einsatz kommen soll, ist es verhältnismäßig einfach, Scrum nach dem Lehrbuch einzuführen.
Firmen jedoch, die Ihre eigene Software entwickeln, wie z.B. einen Webshop, und die diese Software auch selbst betreiben, kommen oft mit Troubleshouting-Problemen auf die Software-Entwickler zu, die eben umgehend gelöst werden müssen und keinen noch so kleinen Aufschub dulden. Unter diesen unvorherbestimmbaren Umständen ist es natürlich schwieriger, ein Sprint-Commitment zu halten. Der Artikel soll zeigen, wie dies mit einer Scrum-Taskforce gelöst werden kann.

Fast alle Sprints litten immer darunter, das es Emergency-Bugs im laufenden Betrieb des Webshops gab und gibt, die, sind sie einmal bekannt, dann keinen Aufschub dulden. Dies können Fehler sein, die
den Betrieb der Software verhindern oder gefährden,
die aus rechtlich relevanten Gründen der umgehenden Anpassung bedürfen,
die wichtige inhaltliche oder ablauftechnische Funktionen des Verkaufsprozesses verhindern.
Bei all diesen Themen muss umgehend im Life System ein Bugfix eingespielt werden. Bisher wurde dann immer eines der Teams beauftragt, dies zu fixen. Dies führte zu der allseits anerkannten Tatsache, das ein Team das Recht hatte, unter diesen Umständen commitete Stories nicht fertigzustellen. Ein eigentlich im Scrum unakzeptabler Zustand! Dennoch ging die Notwendigkeit der dringenden Bugfixes immer vor, was aus kommerziellerSicht begreiflich ist.

Nach Diskussion mit anderen ScrumMastern und dem Team kam die Idee auf, ein Bugfixing Team ausserhalb der Sprint Teams zu etablieren. Dieses sollte sich um akute und existente Bugs kümmern und damit quasi den anderen Teams den Rücken frei halten, damit diese sich voll auf Ihre Sprint-Ziele fokussieren können. Ich hatte bereits Erfahrung mit solch einer Taskforce und kannte die positive Seite, das die Teams ungestört am Sprintziel arbeiten konnten.

Es gab aber auch eine Kehrseite: Bugfixing ist nicht gerade populär.
Wen also in die Bug-Task-force nehmen? In einem früheren Team/anderen Firma hatte ich dies mit einem Freelancer gelöst, der mit bei den Teams saß und (fast) alle Bugsrequests abfing. Nach einer Einarbeitungszeit von ca. 3-4 Wochen lief das auch sehr gut und der Freelancer war fast ein Jahr dabei. Der Haken war, das man mit Bugfixing auch die verschiedensten Stellen der Anwendung kennenlernt. Nach einem halben Jahr wusste der Freelancer teilweise mehr über die Anwendung als in dieser Zeit neu eingestellte Entwickler, die nur Ihre bis dahin realisierten Themen kannten. Bugfixing ist also auch ein intensiver Weg des Lernens! Diese Fehlentwicklng wollten wir diesmal unbedingt vermeiden.

Die Lösung war ein rotierendes Bugfixing -Team! Je (3-Wochen-) Sprint gehen 2 andere Entwickler ins Bugfixing-Team. Bei ca. 12 Entwicklern kommt also rein rechnerisch jeder alle 15 Wochen für 3 Wochen dran. Das ist sehr akzeptabel, zumal er dann ca. 3 Monate Ruhe vor Bugfixing hat.

Im nächsten Artikel werde ich beschreiben, Wie wir die Arbeit organisieren, welche Aufgaben das Bug-Task-Force Team hat und ein Fazit zu den ersten Erfahrungen geben.

Sprint Reviews sollten eine Veranstaltung sein, bei der sich die Anwender und künftigen Nutzer die Ergebnisse der Entwicklungs-Teams aus erster Hand ansehen können und mit den Entwicklern in eine Diskussion kommen sollten. Soweit so gut.

Praktisch kommt ausser den ProductOwnern selten jemand. Daher habe ich diesmal etwas Werbung betrieben und für unser nächsten Sprint Review ein Poster gestaltet. Dieses Flugblatt habe ich dann überall ausgehängt und einige der Auftraggeber persönlich eingeladen und das Poster überreicht.
Das Feedback war erst mal ermutigend. Wenn der Review vorbei ist, werde ich nochmals was dazu berichten.

Seit dieser Woche nutzen die Teams nun die neu angeschafften Whiteboards als Scrumbords. Das Team CRUD hat dies besonders gut umgesetzt und kreativ erweitert. Die ersten fünf Spalten sind die Klassiker:

• Story selected,
• Tasks (not started),
• Tasks in progress,
• Task done,
• Story done.

Dann folgt ein “Story approved” für eine Abnahme vom PO, die hier vor der Review erfolgt, danach vier Spalten mit den durchzuführenden Tests als Checkboxen. Diese sind vom Team festzulegen, zu schreiben und durchzuführen. (in unserem Fall sind das DB-Unit Tests, Unit-Tsts, Selenium Tests und Regression bzw. manuelle Tests.)

Die rechte Seite ist noch mit dem Burn-down-chart, der Definition of done und dem Abwesenheitskalender bestückt.

Dies ist sehr übersichtlich gestaltet und zeigt auch die Testbemühungen sehr gut auf. Wie ich finde ein gutes Beispiel für ein “best practise Scrum board”.

Sticky notes are convenient in use. But my user stories are often done with Word/other software for a clear readable print. So here I want to show how you can print user stories on sticky notes.

First you need to buy sticky notes with the size of 200 * 149 mm. This is A5 landscape. Now you can write your user story with MS Word or Open Office, but limited to the upper half of a A4 page.

Now you have to prepare the sticky note for the print (see right pic) :

Paste the sticky note on a plain paper and put it in the universal feeder of your printer.

Now you may print the user story. You just have to take care thet the printer is using the universal feeder and not the paper box below. Adjust this in the printer setup.

The next step is to remove the sticky not from the paper and that’s it:

A new user story ready to use & printed on a sticky note.

SSL25263

Originally uploaded by Stephan’s Place.

Well last week I attended successful the Scrum Master certification course of Simon Roberts in Berlin. Simon is a dedicated teacher of the agile principles and lives scrum with his heart. That’s the kind of teacher I seeking for, they inspire you to do the right things. Their knowledge results from practical experience and shared experience is the key to knowledge.

However, I’m now a proud Scrum Alliance certified Scrum Master and I got a lot of ideas how I could improve my work.

Thank you Simon for that inspiring training.

Since I have been working in a localization company, you get a sharper focus when viewing translations: this example made me laugh.

While we saw, that the old way of developing software was full of adversities, like missing the milestones, getting things that nobody needed or just a general bad quality of software without documentation, we decided to try something new. The team-leader, Rene , picked Scrum as the most hyped methodology to meet our problems.

So we started by reading books, blogs and other sources and picked Agilo as basically cost-free software to work along that line.

To be honest, the only good result was that the programmers liked the 2-week sprints because of the better prepared job definition and tasks. At least for that short duration they got clear messages what to do. We didn’t use a task board and relied pretty much on the free Agile features.

But still I did not saw major improvements. To increase our professionalism, we decided to get a coaching with Boris Gloger.

The real start of practicing SCRUM

Now we returned excited and enthusiastic with new knowledge and many ideas. So far, the coaching may have looked for others like a brainwash, but it was just a mind- and eye opener.

Our first important step was to skip the scrum software as backlog and use a plain physical board with 6 sections:

• Product backlog,
• Selected Stories,
• Tasks to do,
• Tasks in progress,
• Done
• …and a section for the burn-down chart

Rene is adding the first user story to the sprint board
Originally uploaded by Stephan’s Place.

We had a crude situation in the company, which has a open-plan office in an old factory area and therefore a lack of walls were you could mount a white-board. So we decided to channel the glass divider-wall of the former smoker area to sprint planning wall and used it as  a background for our post-notes.

Now we were able to start and in the next article I’ll tell you more about our ground breaking results.