Nächste Woche findet der mehrtägige Entwicklertag ;-) in Karlsruhe statt. Genauer:

23.06.2010 – Agile Day mit der Keynote von Ken Schwaber “The State of Scrum”
24.06.2010 – Conference Day (Keynote: Dr. Peter Hruschka: “3 Schlüsselrollen im Projekt”)25.06.2010 – VKSI Day (Keynote: Prof. Stefan Tai (KIT), Prof. Jörn Müller-Quade (KIT))

Zuvor gibt es noch Tutorial Days (21./22.6.)

Teilnehmen werde ich am Agile Day und am VKSI Day. Dazwischen muss ich mich meinen diversen Projektaufgaben widmen.

Java Forum Stuttgart 2010

Am 1.7. findet das Java Forum Stuttgart statt, ich nehme teil, um mein Netzwerk zu pflegen und wie immer einen Überblick über den aktuellen Stand in der Java-Welt zu bekommen. Als leitender Projektleider braucht es solche Veranstaltungen, damit man nicht in die irre Welt des Top-Management abgleitet ;-)

Hinweis: Ich werde am 1.7. mit dem Auto morgens von Karlsruhe nach Stuttgart und abends zurück fahren. Hier gibt es noch mehrere Mitfahrgelenheiten! Einfach melden!

Related posts:

1. Veranstaltung: Java Forum Stuttgart 2009 & 6. Experten Forum Stuttgart
2. Veranstaltung: Karlsruher Entwicklertag – Programm voll mit Themen aus der agilen Entwicklung
3. Java Forum Stuttgart 2008

2. Juni 2010: Treffen der Scrum User Group Karlsruhe

2.06.2010, 20-23 Uhr

Ort: Großer Kurfürst, Sophienstraße 80, 76135 Karlsruhe

Thema dieses Mal: Agile Simulation.

Wir werden eine kleine Simulation (der ein oder andere würde auch Spiel sagen) durchführen, die sehr schön einige Agile Grundprinzipien erfahrbar macht.

Mehr Informationen und Anmeldungen via XING Event.

7. Juni 2010: 5. Deutschsprachiges Scrum Meeting

Bei SAP in Walldorf findet am 7.6. das 5. deutschsprachige Scrum Meeting statt.

10 – 17h Open Space

Ort: bei der SAP AG, Walldorf

Die Teilnahme ist frei, das Event wird von SAP gesponsert.

Mehr Infos dazu findet ihr hier.

Anscheinend gehen die Plätze aus, deshalb wurde eine Warteliste erstellt – auf der jedoch bisher nur ein Eintrag zu finden ist.

Related posts:

1. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe
2. Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart
3. SUGK: Scrum User Group Karlsruhe – Scrum & Kanban

Der Termin – obwohl schon länger bekannt – ist wohl etwas in Vergessenheit geraten, erst Heute wurde der entsprechende Xing-Termin angelegt wo man sich auch schön registrieren kann. Wer will kann aber auch einfach vorbeischauen.

Das Thema diesmal: “Scrum in unseren Unternehmen”.

Related posts:

1. Erinnerung: Veranstaltung: Scrum User Group Karlsruhe – Treffen April
2. Scrum User Group Karlsruhe – 1. Treffen
3. Treffen Scrum User Group Karlsruhe

03.02.2010, 18:30-20:30 Uhr, Schlosshotel Karlsruhe, Bahnhofplatz 2 , 76137, Karlsruhe, Germany

• Dr. Nagi (POET Egypt) wird einen Vortrag halten zu: “Nearshore-Entwicklung und -Services mit agilen Methoden”
• Dr. Mevius & Herr Stephan (FZI, Mitglied im Team ZIKS (http://www.ziks.de/)):
  “Projekterfahrungen mit internationalen, kollaborativen Softwareprojekten”
• Ashant Chalasani, Vertreter des Indo-German Software Competence Network (http://indescon.org): “Kooperation zwischen indischen und deutschen Firmen in der IT-Branche: Nicht nur ein Einwegmodell!”

Interessenten können sich via XING registrieren:

• https://www.xing.com/events/roundtable-fzi-forschungszentrum-informatik-karlsruhe-near-offshore-452312

Related posts:

1. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe
2. SUGK: Scrum User Group Karlsruhe – Scrum & Kanban
3. Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart

Here we go:

29.01.2010, 18:00-20:00 Uhr: Indescon X-Table Dinner in Karlsruhe

Restaurant Punjab, Amalienstraße 46, 76133, Karlsruhe

Treffen der indisch-deutschen IT-Community. Ziel ist es, dass Kontakte zwischen regionalen Softwareeunternehmen, Indescon-Mitgliedern und indischen IT-Experten geknüpft werden.

Termin bei Xing: https://www.xing.com/events/indescon-table-dinner-karlsruhe-439618

03.02.2010, 20:00–22:00 Uhr: Scrum User Group Karlsruhe

Großer Kurfürst, Sophienstraße 80, 76135 Karlsruhe

Thema diesmal: “Konflikte im agile Umfeld und wie geht ihr damit um?”

Termin bei Xing: https://www.xing.com/events/scrum-user-group-karlsruhe-453234

Related posts:

1. Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart
2. Termin: Roundtable (FZI) Forschungszentrum-Informatik Karlsruhe "Near-/Offshore"
3. SUGK: Scrum User Group Karlsruhe – Scrum & Kanban

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

• Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
• Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
• POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
• POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.
• …

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

• Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
• Product Owner sollte ein gutes technisches Verständnis haben
• Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
• Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
• … sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu  der verbreitesten Form der Scrum Implementierung zählen ;-(

Related posts:

1. Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart
2. Scrum Product Owner – eine sehr anspruchsvolle Aufgabe
3. Investitionen in einen Product Owner

02.12.2009: Scrum User Group Karlsruhe – Product Owner Herausforderungen

02.12.2009, ab 20:00 Uhr, Großer Kurfürst, Sophienstrasse 80, 76135, Karlsruhe, Deutschland

Agenda:

• n.n. moderiert das Thema “Herausforderungen für unseren Product Owner”
• Freie Gespräche zu jedem Thema das gerade aktuell ist
• Themensammlung für folgende Treffen aktualisieren

Anmeldung via Termin bei Xing:
https://www.xing.com/events/scrum-user-group-karlsruhe-product-owner-herausforderungen-432772

04.12.2009: Regionale Fachgruppe IT-Projektmanagement in Stuttgart – PM & Stress

04.12.2009, 18 Uhr in Raum K5 (EG), Kienestr. 35, S-Mitte

PM & Stress – mit Stress besser umgehen, Spielregeln & Teamvertrag, Gesundheitsbewusste Teamführung

Es geht diesmal um das Thema Gesundheit und Stress im Umfeld von Projekten und Projektmanagement.
Damit ist eine der Fragestellungen: “Wie gehe ich als Projektleiter (gut) mit dem Stress um?”, eine andere, “Wie berücksichtige ich als PL die Gesundheit meiner Projektmitarbeiter?” und “Worauf ist dabei überhaupt zu achten?”.

Details zur Anmeldung befinden sich auf der Webseite: http://www.stz-itpm.de/de/detail.php?nr=1329&rubric=Fachgruppe_ITPM.

Related posts:

1. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe
2. Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner
3. Veranstaltung: Scrum User Group Karlsruhe (April)

Für den einen oder anderen bieten die XPDays sicherlich einen guten Überblick über die aktuellen Diskussionen zu agilen Themen wie Scrum und XP. Interessant sind jedoch sicherlich die Vorträge von Wolfgang Kraus (Collaboration – Agile Softwareentwicklung in verteilten Teams) und von Thomas Starz (Erfahrungen mit Scrum in global verteilten Teams).

Schöne Idee ist der Community Day – eine Möglichkeit sich nach den zwei durchgeplanten Tagen nochmals auszutauschen. Insgesamt ist das “Drumherum” zudem deutlich moderner geworden: Neben dem Blog gibt es nun einen Twitter-Account (@xd_de) inkl. Tag (#xdde09) und sogar Poken sollen herumgeistern.

Für mich fehlen jedoch “die Knaller” im Programm und deshalb nehme ich dieses Jahr nicht an der Konferenz teil. Aufgrund akut immer stärker angreifenden “Wishful Thinking”-Rotten bin ich auf Grund akuter Frust-Anfälle auch nicht in der Verfassung dem Community Day beizuwohnen ;-).

Dazu passt eine Karikatur der Hippenstocks Strategen (Süddeutsche), Ausgabe letzten Samstag:

Man sieht einen Manager an seinen Schreibtisch; er telefoniert: “Hallo ich bin Manager. Bitte verbinden Sie mich mit der Realität.”

Diese Karikatur trifft es auch recht gut: “Kopf hoch Kottelmann! 50 Prozent der Wirtschaft sind Psychologie – die Fakten sollten Sie nicht überbewerten!”

So, das reicht für Heute.

Related posts:

1. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe
2. KADEV09: Entwicklertag 2009: Bilder online
3. Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!

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.

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?

Related posts:

1. SUGK: Scrum User Group Karlsruhe – Scrum & Kanban
2. SUGK: Scrum User Group Karlsruhe – Nächstes Treffen am 5. August
3. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe

• 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

Related posts:

1. SUGK: Zusammenfassung Scrum User Group Karlsruhe – Scrum und Kanban
2. SUGK: Scrum User Group Karlsruhe – Nächstes Treffen am 5. August
3. Termine: Indescon X-Table Dinner in Karlsruhe & Scrum User Group Karlsruhe

Enjoy!

Related posts:

1. Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!
2. KADEV09: Entwicklertag 2009: Agile Nearshoring
3. KADEV09: Entwicklertag: Zusammenfassung Agile Day

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 ;-)

Related posts:

1. KADEV09: Entwicklertag: Zusammenfassung des Conference Day
2. KADEV09: Entwicklertag 2009: Agile Nearshoring
3. KADEV09: Entwicklertag 2009: Bilder online

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.

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

Related posts:

1. SUGK: Scrum User Group Karlsruhe – Scrum & Kanban
2. SUGK: Zusammenfassung Scrum User Group Karlsruhe – Scrum und Kanban
3. Treffen der Scrum User Group Karlsruhe 7. April

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).

Related posts:

1. Veranstaltung: Karlsruher Entwicklertag – Programm voll mit Themen aus der agilen Entwicklung
2. Karlsruher Entwicklertage 2009
3. KADEV09: Entwicklertag 2009: Bilder online

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.

Related posts:

1. Karlsruher Entwicklertage 2009
2. Web Montag Karlsruhe März 2009
3. Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!