SUGK: Zusammenfassung Scrum User Group Karlsruhe – Scrum und Kanban

Das letzte Meeting der Scrum User Group Karlsruhe war wieder ein großer Erfolg. Ich habe ein Schnitzel bekommen und das Thema “Scrum und Kanban” lockte ca. 30 Interessenten an, die sich sehr aktiv vor und nach dem Vortrag austauschen konnten.

Scrum und Kanban

Der Vortrag von Lutz Ehrlich war sehr gut vorbereitet und sehr informativ. Da Jeff Sutherland anwesend war, wurde der Vortrag und die dazu passende Diskussion kurzerhand in Englisch gehalten. Nach dem Vortrag und Ende der Diskussion wurde ein Kanban-Spiel ausprobiert, das guten Anklang fand.

sugka-0910-1

sugka-0910-2

Am Tag nach dem Meeting habe ich  mich kurz mit Heiko unterhalten: Es muss unbedingt kommuniziert werden, dass der Vortrag von Lutz nicht die neue Messlatte für Vorträge wird – sonst gehen der SUGKA die Vortragenden aus ;-)

Agile schlägt Wasserfall

Aus der Diskussion um Kanban und wie schlecht planbare Aktivitäten via Kanban und WIP-Limits trotzdem noch beherrschbar bleiben wurde schnell eine Diskussion über Agile vs. Wasserfall. Laut Jeff: “Agile has proven to work much better than waterfall. IF waterfall does work, it costs twice as much as agile.” (kein wörtliches Zitat). Leider habe ich die Links auf die Dokumente vergessen.

Hat hier jemand besser aufgepasst als ich??

DIN-Norm für Scrum und Übersetzung der Scrum-Termini

Wie viele zertifizierten Scrum’ler mitbekommen, scheint es organisatorische Herausforderungen bei der Scrum Alliance zu geben. Ausgehend von dieser Diskussion ist ein “Normungs-Tisch” sehr schnell zur Auffassung gekommen, dass wir unbedingt eine DIN-Norm für Scrum benötigen. Zunächst muss  jedoch ein guter und belastbarer Plan aufgestellt werden, dann ist die Umsetzung sicherlich schnell erledigt ;-). Danke auch an Go Fragile für die vielen hilfreichen Tipps ;-)

Da diese Planung sicherlich Monate, wenn nicht Jahre benötigt wurde als ergänzender Vorschlag diskutiert, ob nicht zumindest mit der Übersetzung der Scrum-Terminini in Landessprachen begonnen werden könnte: Bayrisch, Schwäbisch, Badisch, Platt. Erste Übersetzungsversuche fanden bereits statt, das dazu nötige Bier wurde schnell und problemlos geliefert.

Hat jemand Interesse daran dieses Übersetzungsprojekt mit mir weiter zu treiben?

SUGK: Scrum User Group Karlsruhe – Scrum & Kanban

Die Zeit vergeht schnell, so schnell, dass demnächst bereits wieder ein Meeting der Scrum User Group Karlsruhe ansteht:

  • Dienstag, 6. Oktober, ab 20 Uhr
  • Großer Kurfürst, Sophienstraße 80, 76135 Karlsruhe
  • Xing-Termin, Karte

Xing sagt, dass ich schon zugesagt habe. Hey, der Urlaub war so gut, dass ich mich nicht mehr daran erinnern kann.

Thema diesmal: Scrum & Kanban (Lutz Ehrlich)

Besonderer Gast: Jeff Sutherland

KADEV09: Entwicklertag: Zusammenfassung Agile Day

Nach dem VKSI Day und dem Conference Day war der Agile Day der dritte Tag mit interessanten Veranstaltungen.

Anmerkung: Jetzt ist es schon August und es sind immer noch keine Fotos online ;-(

Getting done your non-functional Requirements


Thomas Starz von IBM stellte in seinem Vortrag (Folien) vor, wie sich Scrum, XP und GTD kombinieren lassen.
Das Problem, dass ständig irgendwas dazwischen kommt, kennt wohl jeder. So kommt es schnell dazu, dass obwohl das Team viel arbeitet keine sichtbaren Ergebnisse erzeugt werden.
Kurze Diskussionen gab es um die Definition von “Nicht-funktionalen Anforderungen” (NFA), Thomas bezeichnete abhängige Anforderungen als NFAs:

  • neue Entwicklungsumgebung
  • neue Server
  • Performance
  • Usability

Nicht jeder im Publikum wollte diese Definition teilen.

Nach Meinung von Thomas legt der Product Owner (PO) seinen Fokus auf die Funktionen, dem sollte als Gegenüber ein Architekt auf die NFAs achten.

Für die Planung im Rahmen von Scrum gab es folgende Tipps:

  • Puffer für unvorhergesehene Arbeiten
  • NFA als Story im Backlog
  • PO (Funktion) soll sich intensiv abstimmen mit Architekt (NFA)
  • alles erfassen, was erledigt werden muss -> wirklich ALLES ins Backlog
  • Backlog ist Grundlage für Entscheidung

Hierbei sollte die Erfahrung berücksichtigt werden, dass viele POs zu häufig NFA nicht ausreichend berücksichtigen. Zudem wird man früher oder später wohl immer mit einem Verweis auf das Vorgehen nach Wasserfall bekommen: “Wir hätten nur die Spezifikation (besser) schreiben müssen!”

Scrum bei der BASF IT Services

Irene Kuhn von der BASI IT Services und Fahd Al-Fatish von andrena objects stellten ein Einführungsprojekt von Scrum bei der BASF IT vor.

Folien

Ziel des Projektes war der Relaunch des Internetauftritts (www.basf.com) von BASF.

Für dieses Projekt wurde ein erfahrenes Kernteam von sechs Entwickler um sechs weitere Mitarbeiter aufgestockt. Das Kernteam hatte in dem Bereich bereits viel Erfahrung mit Intra- und Internetauftritten (Portale, CMS, Redaktionssysteme)

Neben dem Relaunch von basf.com war ein weiteres Ziel die Vorgehensweise nach Scrum zu etablieren und Know-how-Träger als Scrum Master auszubilden.

Herausforderungen und Vorbehalte

Wie in Großunternehmen nicht unüblich stoßen Veränderungen schnell auf Vorbehalte. Gerade die Transparenz, die mit Scrum möglich ist, wird nicht immer nur positiv gesehen. Zudem wird bei der Einführung von Scrum auch oft kritisiert, dass die Methode zu viele Meetings mit sich bringt. Angesprochen wurde auch die Herausforderung, die sich daraus ergibt, dass trotzdem noch das klassische Reporting befriedigt werden muss. Weiterer Punkt war die Definition der Rolle des Projektleiters. Im konkreten Fall wurde der PL zum Scrum Master ernannt.

Vorbereitung

Um das Projekt richtig aufzusetzen und das Team auf Scrum vorzubereiten wurde in eine gute Vorbereitung investiert. Zuerst wurde mittels Einzelgespräche und Teambefragung der Ist-Zustand analysiert (Retrospektive). Es wurde geklärt, welche Probleme existieren und wo die Stärken des Teams liegen. Im nächsten Schritt wurde über Ziele gesprochen und diskutiert, was beibehalten werden kann und was sich ändern soll.

Durch diese Vorbereitungsphase war klar, auf was während der Einführungsphase geachtet werden musste.

Einführungsphase

Um das Team zu stärken (Teamfindung) und Vertrauen in Scrum zu schaffen wurden vier Sprints als “Probezeit” angesetzt. In diesen vier Sprints wurden die Mechanismen und Rollen eingeführt sowie ein erstes Product Backlog (PBL) geschrieben. Durch die Abarbeitung des Stories aus dem PBL war es möglich, eine Team-Velocity zu ermitteln.

Planung

Die Vorplanung für die Sprints erfolgte in mehreren Schritten: Zunächst eine Vorausplanung in einer kleinen Gruppe (Anmerkung: IMHO wichtige Methode, nicht bei jedem Estimation muss 90% des Teams anwesend sein!), gefolgt durch das Planungsmeeting mit dem gesamten Team am Folgetag.

Für die Vorausplanung wurde die Sprint-Kapazität abnehmend festgelegt: 1. Sprint 100%, 2. Sprint 80%, 3. Sprint: 75%. Durch die abnehmende Kapazität wurde der Unsicherheit Rechnung getragen.

Das PBL wurde durch ein “Product Owner-Team” bestehend aus PO & Chief Architect & Technical Architect geschrieben. Damit wurden sichergestellt, dass sowohl Funktionen als auch NFAs berücksichtigt werden. Die Schätzung des Aufwands erfolgte in Ideal-Tagen, zur Ermittlung kam die Planning-Poker Methode zum Einsatz.

Herausforderungen und Zusammenfassung

Im Rahmen des Projektes war es nötig eine Brücke von Scrum zum klassisches Reporting zu etablieren. Der klassische Projektleiter war jedoch eher als übergeordneten Stakeholder eingebunden. Hierbei spielt es eine Rolle, dass Projektleiter häufig zu viele Projekte gleichzeitig betreuen, deshalb beschränkte sich das “Management” hauptsächlich auf die Review-Meetings.

Sehr gut funktioniert hat das Team-Building und sehr effektiv war auch, dass der ProductOwner aus dem Team (!!) verantwortlich für das Management des PBLs war.

Auf die Einführung von komplexen Softwarelösungen wurde bewusst verzichtet. Als Tools kamen lediglich Excel und ein Task-Board zu Einsatz.

Durch die Restschätzung des PBL und Abgleich mit der Restschätzung Budget wurde eine sehr  gute Transparenz erreicht.

Fazit: Das Projekt war ein Erfolg und Scrum wird bei BASF IT Services immer häufiger eingesetzt.

Making Scrum stick – Transforming the Enterprise

Christoph Mathis (ScrumCenter) beschäftigte sich in seinem Vortrag (Folien) damit, wie Scrum nachhaltig im Unternehmen verankert werden kann.

Jeder von uns kennt es – unter Druck fallen wir schnell zurück in alte Verhaltensweisen und vergessen das neue. Hierbei spielt es oft auch eine Rolle, dass konservative Kollegen nichts mit den neuen Ansätzen anfangen können und dagegen opponieren. Auch Manager, die zu viel Transparenz fürchten, sorgen oft für einen gewissen Druck, wieder zurück zur alten Vorgehensweise zu wechseln. Ein kritischer Moment ist dann gekommen, wenn der Sponsor von Scrum die Firma verlässt.

Wie lassen sich solche Rückschläge vermeiden?

Christoph schlägt als erfolgsversprechendes Herangehen vor, dass Scrum vollständig praktiziert werden soll und damit letztendlich Scrum in der DNA der Firma verankert wird.

Er bezieht sich auf grundlegene Praktikern und Ideen von Scrum:

  • ask the team
  • inspect & adapt
  • deliver every 30 days
  • treat people as adults

Ergänzt werden sollen diese durch den konsequenten Einsatz von Engineering Praktiken.

Immer wieder soll die Frage gestellt werden, was getan werden muss, damit Scrum maximale Produktivität bringt?

Sein Vorschlag ist der Einsatz eines Verbesserungs-Backlog. Dieses wird in der Diskussion in Gruppen zu 2-3 Teilnehmern erstellt. Zentrale Fragestellung hierbei: Was braucht es, damit unsere Scrum-Praxis wirklich exzellent wird?

Um Scrum in der DNA des Unternehmens verankern zu können, muss die Kultur des Unternehmen berücksichtigt werden. Beispiele für die Kultur in einem Unternehmen sind:

Geschichten (worüber geredet wird)

  • welche Geschichten im Unternehmen (Held, Armleuchter, Erfolge, Misserfolge)
  • welche Geschichten sollen erzählt werden?
  • Was soll nächstes Jahr über das Projekt und das Team erzählt werden?

Symbole

  • wer hat welches Büro und welchen Dienstwagen?
  • wie ist die Kleiderordnung?
  • wer ist “Anzugträger”?

Organisationsstrukturen

  • wie ist die Organisation?
  • formal / informell

Kontrolle

  • wer fördert wen?
  • was bedeutet es Scrum Master zu sein für die Karriere?

Rituale & Routine

  • was für Veranstaltungen werden gemacht?
  • wie tut man Dinge?
  • wie initiiert man einen Vorschlag bei seinem Chef?
  • “das macht man bei uns so!” – nicht rational

Macht (Beeinflussung)

  • wer kann welche Vorgaben machen?
  • Methodenabteilung – hat diese Macht?
  • wer hört auf wen?

Durch sorgfältige Analyse können die einflussreichen Personen identifiziert und überzeugt werden. Nur mit der Unterstützung der Schlüsselpersonen, kann es gelingen Scrum dauerhaft im Unternehmen zu verankern.

Wichtig ist es, dass nach Identifikation des bzw. der Sponsoren Hilfe von außen geholt wird.

Hilfe von außen holen:

  • Hilfe von außen
  • Leuchtfeuer
  • Professionalisierung (Kompetenzzentrum)
  • Fördern
  • Diversifizieren
  • Etablieren
  • Konsolidieren
  • Integrieren

1) Scrum gut machen: Verbesserungs-Backlog
2) Scrum in Unternehmens-DNA einbauen: Transition-Backlog

Insgesamt wurden einige wichtige Hinweise gegeben, wie eine Einführung und Verankerung von Scrum im Unternehmen gelingen kann. Aus den Hinweis, dass es wichtig ist, Hilfe von außen zu holen durfte natürlich nicht verzichtet werden ;-)

Fazit Agile Day

Jetzt hat es doch wirklich mehr als einen Monat gedauert bis ich meine Notizen endlich überarbeitet habe. Nunja, zumindest bin ich mit der Zusammenfassung fertig bevor Fotos erscheinen ;-)

Insgesamt war der Agile Day sehr interessant – nicht nur wegen den Vorträgen! Die sehr spannende Podiumsdiskussion zum Thema “Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten.” bekomme ich jetzt nicht mehr zusammen, dazu sind meine Notizen einfach zu wirr ;-)

Nun, es scheint ich tauge nicht zum Konferenz-Blogger. Na, wieder einmal etwas gelernt ;-)

SUGK: Scrum User Group Karlsruhe – Nächstes Treffen am 5. August

Das nächste Treffen der Scrum User Group Karlsruhe ist wohl für den 5. August ab 20:00 Uhr geplant. Zumindest ist Heiko und die Wiki-Seite der Meinung. Ein Entsprechender Termin bei XING existiert leider noch nicht.

Laut Backlog auf der Wiki-Seite soll dieses Mal das Thema Kanban im Kontext Scrum besprochen werden. Nunja, ein Vorgehen was ich aus der Produktionsplanung in Fabriken kenne inkl. schönen Eingangskörben etc.

Wer sich im Vorfeld etwas informieren möchte kann nachlesen bei Henrik Kniberg, Boris Gloger oder Corey Ladas (Autor des Buches “Scrumban”).

Wer sich also für dieses Thema interessiert oder sich sonst über Scrum austauschen möchte kann gerne kommen:

5. August 2009, 20Uhr im Großen Kurfürsten (Sophienstraße 80, 76135 Karlsruhe), vgl. auch den Termin in Xing.

Map picture

Update 31.07.: Das Thema ist diesmal nicht KANBAN sondern “Produkt Vision und Scrum”!

Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!

Die drei Tage “Karlsruher Entwicklertag 2009” sind vorbei, begonnen hat alles am Montag mit demVKSI Day (vgl. Posting), gefolgt vom Conference Day und dem Agile Day.

Trotz der etwas verwirrenden Benennung “Entwicklertag” für drei Tage haben sich alle drei Tage für mich gelohnt. Jede Menge interessante Menschen getroffen und viele gute Vorträge gehört. Erstaunlicherweise hat es mit den Netbook und dem Surf-Stick meist gut funktioniert und der Akku des 1000he hat wirklich den ganzen Tag durchgehalten. Somit ist auch dieses Experiment gelungen. Überrascht hat mich, dass einigen Teilnehmern ArmerKater.de bereits bekannt war!

Über den VKSI Day habe ich bereits etwas geschrieben, die Notizen zu den anderen beiden Tagen muss ich noch aufbereiten. Es ist doch mehr Text geworden als ich zunächst vermutet hätte und ich werde diesen noch sehr stark reduzieren müssen. Die beiden Berichte sollten in den nächsten Tagen fertig werden (=> zum Live-Reporter tauge ich also nicht).

KADEV09: Karlsruher Entwicklertage 2009 – Montag

Entwicklertag in Karlsruhe: 22.06.2009: VKSI Tag

Nach der Ankunft in Esslingen direkt in das freundliche Gebäude der Silverstroke AG. Glücklicherweise funktionierte die Registrierung einfach und schnell. Nach den ersten Minuten dann auch schon die ersten Bekannte getroffen und über die Wehen des Scrum-Prozesses diskutiert.

Im Laufe des Tages konnte ich immer wieder interessante Gespräche führen und mich mit vielen anderen Teilnehmern austauschen.

Sehr interessant war die Keynote von Jens Coldewey und die nachfolgende Podiumsdiskussion.

In seiner Keynotes “Software Engineering Heute” stellt Jens Coldewey 7 Thesen sowie das Ergebnis seiner letzten Umfrag vor.

7 Thesen

1) Softwareentwicklung ist Ingenieurstätigkeit
Definition des VDI ist jedoch problematisch:
- definierte Ausbildung > aber eine Vielzahl unterschiedlicher Angebote
- Stand der Technik > ändert sich jedoch ständig und schnell
- Best Practices > schwierig, wenn sich vieles ständig ändert

2) Softwareentwicklung ist Entwicklung (und keine Produktion)
- Softwareentwicklung ist nicht tyloristisch
- Anforderungen sind fast immer unscharf
- Entwicklung basiert auf Versuch und Irrtum / Experimenten
- Produktionsansätze sind unbrauchbar

3) Software ist komplex
- im Spannungsfeld zwischen deterministischen und chaotischen Systemen
- Verhalten ist oft überraschend und nicht vorhersehbar
- Forderung: Änderung an erzeugten Produkten und eingesetzten Prozessen muss möglich sein.

4) Softwareentwicklung basiert auf einer Kette von Entscheidungen
- Entscheidungen müssen zu einem optimalen Zeitpunkt getroffen werden
- zu früh/spät -> hohe Folgekosten

5) Softwareentwicklung ist iterativ und inkrementell
- seit Garmisch bekannt
- ein Grund: Komplexität und Unsicherheit
- Neues (Änderung Rahmenbedingung) ist nicht die Ausnahme sondern die Regel
- entscheidender Faktor: Architektur des Systems, diese muss Änderungen unterstützen -> wesentliche Forderung: Änderbarkeit

6) Softwareentwicklung ist Kommunikation
- Kommunikation dominiert Softwareentwicklung
- soziales Problem
- organisatorisches Problem
- selten rein technisches Problem
- “leader’s framework for decission making”
- unklare Vorgaben -> selbstorganisierende Teams
- Entwicklungsteam muss Wirtschaftlichkeit bewerten können

7) Softwareentwicklung ist Handwerk
- impliziertes Wissen, basierend auf Erfahrung, nicht beschreibbar
- Code als das Material für den Software-Ingenieur
- lebenslanges Lernen -> jahrelang
- Schüler, Geselle, Meister
- lernen am lebenden System
- lernen und arbeiten in Gruppen

In der darauf folgenden Podiumsdiskussion wurden die These aufgegriffen und kontrovers diskutiert. Interessant auch die Frage, welche Anforderungen heutige Informatik-Absolventen erfüllen sollen und wie die Universitäten dies unterstützen sollen.

Veranstaltung: Karlsruher Entwicklertag – Programm voll mit Themen aus der agilen Entwicklung

Seit einiger Zeit ist das Programm des diesjährigen Karlsruher Entwicklertags (22. bis 26. Juni 2009) verfügbar.

Alle drei Tage enthalten spannende Vorträge die für agile Teams interessant sind.

22. Juni – VKSI Day „Eine Region, vernetzt in der Welt: Software Engineering aus Karlsruhe – Software Engineering in Karlsruhe”

  • Keynote: Jens Coldewey Ort: Silverstroke AG (Ettlingen)
  • Interessante Vorträge u.a.:
    • Einsatz von Freiberuflern
    • Juristisch Aktuelles vom Software Engineering
    • Podiumsdiskussion “Software-Engineering heute – Herausforderung an Industrie und Hochschulen”

23. Juni – Conference Day „Softwaretechnik, Innovation, Qualität“

  • Keynote: Prof. Walter Tichy Ort: IHK Karlsruhe
  • Interessante Vorträge u.a.:
    • Agile Offshoring
    • Entwicklung bei Microsoft: Formal oder Agile?
    • Agil inspiriertes Muti-Projekt-Management
    • Agile Portfolio Management

24. Juni – Agile Day „Agile Entwicklung, agiles Management – Schlüssel zur Wettbewerbsfähigkeit“

  • Keynote: Joseph Pelrine Ort: Technologiepark Karlsruhe
  • Interessante Vorträge u.a.:
    • Making Scrum Stick – Transforming the Enterprise
    • Agile Planung – Agiles Geschäftsmodell
    • Podiumsdiskussion: “Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten.”

Der Karlsruher Entwicklertag 2009 bietet damit zusammen mit dem Java Forum Stuttgart 2009 etwas später eine gute Gelegenheit sich hinsichtlich Entwicklungsmethodik und agilem Vorgehen auf den aktuellen Stand zu bringen.

SUGK: Zusammenfassung Treffen April

So, gestern war das zweite Treffen der Karlsruher Scrum User Group (Wiki-Seite). Wieder waren mehr als 20 Interessenten dabei.

Das Treffen fand diesmal im Wolfsbräu statt. Ein Gag der ein Foto verdient- Pizza Calzone mit Augen:

calzone-watching

Zurück zu den Themen und der Diskussion:

Agile Verträge

Jürgen Hoffmann hat unter der Überschrift “Agile Verträge” das Vorgehen der Firma CodeSprinters vorgestellt, deren Vortrag er auf dem Scrum Gathering in Stockholm gehört hat.

Letztendlich basiert der vorgeschlagene Ansatz auf einer Art Dienstvertrag, d.h. es wird im Sprint-Rhythmus nach Aufwand (Stunden) bzw. Entwickler abgerechnet. Um den Kunden die Entscheidung für einen solchen Vertrag zu erleichtern, gibt es ein paar Rahmenbedingungen, die eingehalten werden sollten. So sollten die eingesetzten Team-Mitglieder nur an einem Projekt arbeiten und der Kunde soll zu jedem Zeitpunkt Zugriff auf den aktuellen Arbeitsstand (SVN) inkl. aller Artefakte (z.B. auch interne Dokumentation) haben. Der Kunde sollte eng eingebunden werden, im besten Fall wie es Scrum vorsieht: Direkt als Product Owner. Die enge Zusammenarbeit mit dem Kunden führt jedoch dazu, dass elektronische Helferlein eingesetzt werden müssen: Scrum Planning Tools statt dem guten alten Task-Bord mit PostIts. Dies ist zumindest der Fall, wenn Kunde und Team nicht im gleichen Gebäude arbeiten:

  • Project repository – it’s client’s code after all.
  • Test system – they should see what changes.
  • Scrum tool – backlogs, tasks, burndowns, etc.
  • Bug tracking – they must go somewhere.
  • Project Wiki or other documentation.

Quelle: Selling agile Scrum based Services

INHO sicherlich ein guter Weg, falls der Kunde wirklich dazu gebracht werden kann einen Vertrag nach Aufwand zu unterschreiben. Leider ist oft nicht möglich, da der Kunde auf Festpreisangebote besteht und nicht Dienstleistungen erwerben möchte sondern eine “fertige Lösung”. Die Probleme von Festpreisprojekten wurden kurz andiskutiert.

Weitere interessante Informationsquellen für den Themenkomplex “agile Vertragsgestaltung” sind beispielsweise:

Leider kenne ich keinen Vertriebler, der sich ernsthaft mit diesen Themen beschäftigt. Festpreis und bei Problemen dann Bashing Richtung Projektleitung / Entwicklungsteam ist ja schließlich ein Pattern, welches schon immer funktioniert hat ;-)

Product Owner als Nebelschwade

Nach dem kurzen Vortrag gab es dann Diskussionen an jedem Tisch. Letztendlich bin ich wieder beim Thema “Product Owner” gelanden, schließlich ist dieses auch sehr ergiebig. Schönes Bild: Der Product Owner als Nebelschwade, hinter der sich die Komplexität der Organisation verbirgt.

Naja, das Thema Product Owner scheint ja langsam wichtiger zu werden.