Scrum und Agile Softwareentwicklung – Praxisorientierte Einführung am 24. und 25. Februar 2014

Am 24. und 25. Februar 2014 findet in den Räumen der //SEIBERT/MEDIA GmbH in Wiesbaden eine zwei-tägige, praxisorientierte Einführung zu Scrum & agiler Softwareentwicklung an.

Neben den interaktiven Workshop-Teilen bieten wir auch Einblicke in die konkrete Anwendung agiler Vorgehensweisen im Projekt- und Produktgeschäft bei //SEIBERT/MEDIA.

Inhalte des Workshops

Einführung in Scrum & Agile Softwareentwicklung

  • Was ist agil? – Agile Werte und Prinzipien
  • Unterschiede zum klassischen Projektmanagement
  • Scrum: Konzepte und Funktionsweisen

Das Scrum-Framework

  • Die Rollen in Scrum: Team, Scrum MasterProduct Owner
  • Iteratives Vorgehen: Die Scrum-Sprints
  • Anforderungen planen, priorisieren und umsetzen: User-Stories
  • Wartungsaufgaben und Neuentwicklung unter einen Hut bekommen
  • Das TaskboardProduct Backlog, Todo, Doing, Done
  • Die Scrum-Meetings und ihre Bedeutung
  • Papier vs. Tool-gestützt oder Papier und Tool-gestützt?
  • Der visuelle Teamraum

Strategie

  • Politische Argumente für Agile
  • Einführungsstrategien: Best Practices
  • Stolperfallen und Probleme
Scrum-Prozess

Einführung in das agile Framework „Scrum“

Die Trainer

Joachim Seibert

Überzeugter Verfechter agiler Softwareentwicklung, zertifizierter Scrum Master (CSM) und Scrum Developer (CSD) und Scrum Professional (CSP). Leitet seit 1996 die Entwicklungsabteilung bei //SEIBERT/MEDIA und ist maßgeblich dafür verantwortlich, dass dort agile Methoden eingeführt worden sind. Er hat es sich zur Hauptaufgabe gemacht, Entwicklungsteams und Unternehmen agiler zu machen.

Paul Herwarth von Bittenfeld

Paul Herwarth von Bittenfeld arbeitet seit 2003 bei //SEIBERT/MEDIA mit und in Software-Entwicklungsteams, zunächst als Projektleiter, später als Product Owner und aktuell als ScrumMaster. In den letzten Jahren begleitete er die Einführung von Scrum und Kanban in mehreren Teams und die Einführung agiler Methoden und Vorgehensweisen auf Unternehmensebene sowohl bei //SEIBERT/MEDIA selbst als auch als Agile-Coach in Kundenprojekten.

Location

//SEIBERT/MEDIA GmbH
Kirchgasse 6
65185 Wiesbaden

Anmeldung

Die Anmeldung kann über die XING-Eventseite erfolgen. Die Teilnahme für die zweitägige Schulung inklusive Verpflegung kostet 799 Euro zzgl. MwSt.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

„Today I’m going to change the world“ – die ersten 24h beim Agile Coach Camp

Gerade findet in Rückersbach in der Nähe von Aschaffenburg das 4. Agile Coach Camp statt. Eine Mischung aus Agile-Coaches, ScrumMastern, agilen Managern und sonstigen Agilisten hat sich zusammengefunden, um sich gute 48h lang auszutauschen.

IMG_5338Das ganz bescheidene Motto der Unkonferenz:

Today I’m going to change the world … (a little).“

Am gestrigen Abend begann es mit einem get together in der Bar des Seminarzentrum Rückersbach. Nach einer Stärkung und ersten intensiven Gesprächen haben wir uns für die Begrüßung und zahlreiche Lightning Talks im Forum versammelt. Dort wurden auch die T-Shirts mit dem Slogan (siehe das T-Shirt links) ausgeteilt.

Den Rest des Abends verbrachten wir mit zahlreichen Gesprächen. Bei uns drehte es sich hauptsächlich um zwei Themen: Mitarbeiter-Einstufungen und -Vergütung sowie Abrechnungsmodelle. In beiden Fällen gibt es zahlreiche unterschiedliche Ansätze, wobei der Großteil der Organisationen nur auf zwei oder drei übliche Varianten zurückgreift. Womöglich werden wir die Themen auch morgen noch einmal in einer Session weiter vertiefen.

IMG_5344Nach einem erholsamen Schlaf und einem kurzen Lauf ging es nach dem Frühstück im Forum des Seminarzentrums weiter. Ein paar organisatorische Hinweise, ein paar Hintergrundinformationen zur Open Space-Technologie, dann ging es auch schon los mit der Themensammlung.
Ein interessanter Timetable ist entstanden, bei dem zu jedem Zeitpunkt gleich mehrere Sessions interessant wären.

In den Open Space-Tag bin ich dann mit einer eigenen Session über das Spannungsfeld Velocity & Customer Value gestartet. Es ging darum, dass viele Teams ihre Velocity in Form von bspw. Story Points messen, und ihren Fortschritt danach messen. Außer Acht bleibt bei solch einer Betrachtung allerdings, ob die gebauten Features/umgesetzten Anforderungen auch wirklich genutzt werden und damit wirklich einen Wert für den Kunden liefern.
IMG_5350Mit dem Build – Measure – Learn -Zyklus im Kopf haben wir dann darüber gesprochen, wie sich Methoden aus Lean Startup in agile Teams, insbesondere Scrum-Teams, integrieren lassen.

Neben einer methodischen Herausforderung ist es auch eine kulturelle: Viele Teams werden es befremdlich finden, ein gerade gebautes Feature aus einer Anwendung zu streichen, weil es nicht genutzt wird. Daher ist der Einsatz von MVP (Minimal Viable Products) zum Abtesten von Ideen wertvoll.

 

Ein weiterer Ansatz dafür ist die Nutzung von Discovery Stories. Die Idee ist dabei, dass zunächst einmal vom Team abgeklärt wird, ob eine Idee auf das Interesse der Anwender stößt und wirklich einen Business Value liefert.

Für die kulturelle Herausforderung kann es interessant sein, interdisziplinäre Hackathons durchzuführen, in denen sich neben der Beschäftigung mit dem Hacken auch den Nutzerbedürfnissen gewidmet wird.

Den Rest des Vormittags habe ich mit TEMENOS verbracht. Worum es da geht?

Temenos is about understanding our deepest personal visions and how we want to influence the organizational, social and family containers around our lives.

Christine und Olaf haben von ihren Erfahrungen aus einem Training in den USA berichtet und ein „Speed Temenos“ durchgeführt. Dabei haben sie Inhalte des Trainings, das über 9 Tage lief, in knapp zwei Stunden mit den Teilnehmern behandelt und gemeinsam durchgeführt. Demnächst werden sie auch in Deutschland Trainings dazu anbieten. Infos zu TEMENOS gibt es unter www.visiontemenos.com.

IMG_5365Nach dem Mittagessen war die Session „How to improve your retrospectives“ sehr hilfreich. In einer Runde von gut 20 ScrumMastern und Coaches haben wir uns darüber ausgetauscht, wie Retrospektiven abwechslungsreich und effektiv gestaltet werden können.

Insgesamt sind dabei über 20 Ideen zusammengekommen, von denen ich viele am liebsten gleich ausprobieren möchte.

Noch ein guter Tag liegt vor uns, wenn es so weiter geht wie bisher lässt sich das Agile Coach Camp 2013 allerdings mit einem Wort beschreiben: großartig!

Danke an die Organisatoren!

Einige Bilder vom Agile Coach Camp gibt es in meinem Flickr-Account.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

 

Commitment gerissen! Na und?

Sprint-Review. Das Scrum-Team hat sich für den Sprint einiges vorgenommen. Schnell stellt sich heraus: ein großer Teil davon konnte nicht erreicht werden. Doch scheinbar stört sich das Team nicht daran. – Wie sollte ein Product Owner darauf reagieren?

Dieses Szenario wurde vor kurzem bei einem OpenSpace besprochen und es sind einige Anregungen zusammen gekommen, wie darauf reagiert werden könnte. Im Kern steht dabei unsere Annahme, dass das Team vor allem deshalb relativ gleichgültig auf das Verfehlen ihres Sprintziels reagiert hat, weil sie nicht mehr erkennen konnten, dass es irgendjemanden interessiert. Die Geschäftsführung hatte sich schon seit Monaten in keinem Review mehr blicken lassen, die Ergebnisse wurden nicht nach außen kommuniziert und die Reviews wurden nur noch pro forma Team-intern durchgeführt.

  • In das Review für regelmäßige Beteiligung von Kunden und anderen Stakeholdern sorgen: Die Beteiligung der Kunden, Geschäftsführung oder anderer Stakeholder könnte dem Team aufzeigen, dass es diesen Teilnehmern wichtig ist, was an Software ausgeliefert wird.
  • Kosten eines Delays aufzeigen: Es könnte dem Team aufgezeigt werden, wie sich die Verzögerung über mehrere Sprints hinweg derart auswirkt, dass das kommende Release über deutlich weniger Funktionalität verfügt und damit auch die Zufriedenheit der Kunden klar gefährdet wird.
  • Gemeinsames Review mit mehreren Teams, wenn vorhanden: Sofern mehrere Teams im Unternehmen arbeiten, könnte ein Review mit mehreren Teams gemeinsam durchgeführt werden. Dies könnte es auch der bereits genannten Geschäftsführung ermöglichen, wieder an Review-Terminen teilzunehmen, wenn nicht jedes Team einen eigenen Termin hat.
  • Die Art des Reviews variieren, z.B. im Stil einer „Messe“: Damit das Review interessant bleibt, könnte das Setting von Zeit zu Zeit variiert werden. Einmal im Besprechungsraum mit allen gemeinsam an einem Tisch, mal im Büro des Scrum-Teams mit verschiedenen Stationen, an denen die einzelnen Arbeitsergebnisse präsentiert werden, … .
  • Kundenbeirat zum Review einladen: Wenn das Unternehmen über einen Kundenbeirat verfügt, könnte dieser einmal zu einem Review eingeladen werden, damit Kunden und Entwickler sich einander annähern und dem Team präsent wird, für wen sie das Produkt entwickeln.

Wie würdet Ihr in so einer Situation verfahren?

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Open Space der Agile Usergroup Rhein-Main am 18. Oktober

Das Oktober-Treffen der Agile User Group Rhein-Main steht kurz bevor. An diesem Donnerstag, 18. Oktober 2012, treffen wir uns im //SEIBERT/MEDIA-Office. Dieses Mal ist das Treffen als kleines Open Space konzipiert: Jeder kann seine Fragen und Themen einbringen und gemeinsam mit anderen Agile-Interessierten diskutieren und Lösungen erarbeiten.

Open Space: Eure Themen sind gefragt

Open Space – das heißt, dass keine Themen vorgegeben sind, sondern jeder selbst Themen einreichen und sie mit anderen Teilnehmern besprechen kann. Dabei sind alle Themen erlaubt. Sie sollten möglichst irgendetwas mit agiler Softwareentwicklung im weiteren Sinne zu tun haben und es sollte sich mindestens eine weitere Person finden, die Lust darauf hat, über das Thema zu sprechen.

Aber von konkreten Fragen zur Arbeit als ScrumMaster, ProductOwner oder Teammitglied über Herausforderungen bei der Einführung von Agile bis hin zur Ausweitung agiler Organisationsformen über die Software-Entwicklung hinaus kann eine breite Themenvielfalt erwartet werden. Damit werden an einem Abend in kompakter Form viele ganz unterschiedliche Agile-Aspekte gewinnbringend vertieft.

Einführung um 19 Uhr, Themensammlung um 19:30 Uhr

Auch wer noch nicht mit dem Open-Space-Konzept vertraut ist, ist herzlich willkommen. Ab 19 Uhr werde ich für Unerfahrene eine kurze Einführung in das Format geben. Wer sich vorab etwas einlesen möchte, der sei auf diese Artikel im Blog von //SEIBERT/MEDIA verwiesen: Das Open-Space-Konzept: Prinzipien, Regeln, Besonderheiten und Open Space bei //SEIBERT/MEDIA: Rückblick auf die jüngste Konferenz. Auch die Wikipedia-Seite gibt einen Einblick in das Konzept.

Wer Open Space bereits kennt, sollte dann zur Themensammlung ab 19:30 Uhr vor Ort sein. Gerne können auch vorab bereits Ideen für das Open Space im XING-Forum der User Group oder per E-Mail an pherwarth@seibert-media.net vorschlagen werden.

Jetzt kostenlos anmelden!

Interessant? Die Teilnahme ist kostenlos! Veranstaltungsort ist das Hauptquartier von //SEIBERT/MEDIA im zentralen Wiesbadener LuisenForum, das Sie mit allen Verkehrsmitteln und auch zu Fuß zum Beispiel vom Hauptbahnhof aus prima erreichen. Hier findet Ihr eine detaillierte Wegbeschreibung.

Getränke und Knabberzeug werden bereitgestellt. Um eine Anmeldung über die XING-Eventseite oder per E-Mail an pherwarth@seibert-media.net wird gebeten.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Noch bis morgen einreichen: Call for Sessions der Tools4AgileTeams

Am 8. November möchten wir gemeinsam mit Euch eine Konferenz in Wiesbaden speziell zur Nutzung und Anwendung von Tools in der agilen Softwareentwicklung veranstalten.
An welchen Stellen ist die Anwendung von Tools wirklich hilfreich, an welchen Stellen eher ein „Impediment“? Und welches Tool eignet sich besonders gut für einen spezifischen Einsatzzweck?
Wir möchten Anwender, ScrumMaster, Manager, Tool-Hersteller und alle, die sich für das Thema interessieren, an diesem Tag zusammenbringen. Am Vormittag wird es 8 Vorträge geben, für die wir derzeit noch bis zum kommenden Freitag, 31.8., Einreichungen entgegen nehmen.
Am Nachmittag möchten wir dann Open Space mit mehreren parallelen Slots machen, um möglichst spezifisch auf alle brennenden Fragen an diesem intensiven und hoffentlich lehrreichen Tag eingehen zu können.

Weitere Informationen zur Einreichung von Sessions findet Ihr hier:
http://tools4agileteams.com/display/2012/Call+for+Sessions

Tickets für die Veranstaltung sind derzeit noch bis Ende September zum Earlybird-Preis von 199 Euro zu erwerben:
http://tools4agileteams.com/display/2012/Anmeldung+und+Preise

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Sprint-Review: Konstruktives Feedback geben, wenn es einmal schlecht läuft

Review / Demo / Sprint-Review / Scrum ReviewDer Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das Scrum-Team in den letzten Wochen geleistet hat und erreichen konnte. Der Product Owner ist gefordert, „seinem“ Team Feedback dazu zu geben, wie er mit den Arbeitsergebnissen zufrieden ist.

Doch wie sollte er damit umgehen, wenn es einmal wirklich schlecht gelaufen ist und das Team bei weitem nicht die Fortschritte erreichen konnte, die gemeinsam geplant wurden?

Dem Team zuhören

Zunächst einmal ist es wichtig, dem Team die Chance zu geben, aufgetretene Hindernisse im Sprint-Verlauf darzulegen. Womöglich waren sie durch größere Ereignisse im Live-Betrieb von der Arbeit am Sprint-Ziel verhindert, haben aber ihr bestes gegeben, das System am laufen zu halten. Dies kann z.B. der Fall sein, wenn ein ungewöhnlich starkes Nutzerwachstum aufgetreten ist, dass sich nicht vorhersehen ließ. Dadurch ändert sich nicht die Situation, dass das Sprintziel nicht erreicht wurde, es ist aber doch ein Unterschied, ob das Team alles gegeben hat und es trotzdem nicht geklappt hat, oder ob die Verfehlung des gemeinsamen Ziels andere Gründe hatte. Womöglich teilt das Team dabei auch wichtige Informationen mit, die dem Product Owner und dem ScrumMaster die Möglichkeit bieten, das Team bei der Erreichung zukünftiger Zielsetzungen zu unterstützen. Damit es dazu kommen kann, muss dem Team aber die Möglichkeit gegeben werden, eine Selbsteinschätzung zu geben.

Die eigene Perspektive erklären

Das Feedback des Product Owners sollte klar und verständlich zum Ausdruck kommen. Das sollte allerdings jederzeit sachlich und konstruktiv erfolgen. Wurde nicht nach den vereinbarten Prioritäten gearbeitet, kann noch einmal herausgestellt werden, warum sie so festgelegt wurden. Wurde einem Stakeholder gegenüber in Abstimmung mit dem Team eine Zusage gemacht, die nun nicht eingehalten werden kann, sollte das auch noch einmal betont werden. Die Konsequenzen des schlechten Sprintverlaufs sollten dargestellt werden. Da der Product Owner die wirtschaftliche Verantwortung für das Projekt trägt, sollte er gerade auch die betriebswirtschaftliche Sicht mit einbringen und die Interessen der Stakeholder vertreten.

Das Ziel nicht aus den Augen verlieren

Ein schlechter Sprint tut weh. Er tut dem Product Owner weh, der die wirtschaftliche Verantwortung für das Projekt trägt. Er tut dem Team weh, das seine selbst gesteckten Ziele nicht erreicht hat. Und auch dem ScrumMaster tut er weh, da ihm eine Menge Arbeit bei der Aufarbeitung bevorsteht.
Aus dieser schmerzlichen Situation heraus sollte das Ziel des Product Owners nicht sein, dass das Team sich noch schlechter fühlt. I.d.R. können sich die Teams auch selbst gut einschätzen und sind selbst unzufrieden, wenn das Sprintziel nicht erreicht wurde. Dennoch sollte er klar darstellen, wie die Erwartungshaltung war und wie das gelieferte Ergebnis sich dazu verhält. Es kann auch anhand eines Release-Burndown-Chart ermittelt werden, wie die Auswirkungen auf den Releasetermin (wenn der Umfang fixiert, das Datum variabel) oder den Releaseumfang (wenn der Umfang variabel, das Datum fixiert ist).

Gemeinsam nach Lösungen suchen

In der Retrospektive besteht noch einmal ausführlich die Möglichkeit, den zurückliegenden Sprint aufzuarbeiten und Verbesserungsmaßnahmen zu erarbeiten. Persönlich habe ich gute Erfahrungen damit gemacht, als Product Owner bei den Retrospektiven des Teams dabei zu sein. Das machen wir allerdings nur, wenn das Team dem zustimmt. Denn für einen offenen Umgang mit Kritik ist eine situative Ermöglichung der Kritik erforderlich. Die Teammitglieder müssen das Gefühl haben, dass sie Fehler offen ansprechen dürfen. Das ist meist eine Frage des Vertrauens.

Fazit

Gerade ein schlechter Sprint zeigt, ob das Team wirklich ein Team ist. Der Product Owner sollte seine Erwartungen und die Erwartungen des Stakeholder klar vertreten. Vertrauen ist die Basis für ein erfolgreiches Team.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: psd

Genial: Taskboard und JIRA automatisch abgleichen

Wie cool wäre es, die Vorteile eines Offline-Taskboards mit denen eines Aufgaben-Managementsystems wie JIRA vollständig zu verknüpfen? Wir selbst nutzen beides und sind auch überzeugt davon. Aber ein Nachteil ist offensichtlich: Das Taskboard muss immer offline und in JIRA aktualisiert werden. Jeder Task muss daher zweimal angepackt werden.

Nicht so bei einem Scrum-Team von Vodafone aus Dänemark. Deren ScrumMaster Ole Hojris Kristensen hat eine Lösung mit RFID-Technologie gebaut, bei der die Aktualisierung in JIRA direkt erfolgt, wenn ein Task von einem Status in einen anderen verschoben wird.

Weitere Sprint-Verläufe des Teams können bei YouTube verfolgt werden.

In diesem Präsentationsvideo stellt Ole vor, wie der automatische Abgleich zwischen Taskboard und JIRA funktioniert.

Was haltet ihr von dieser Konstruktion?

Via: Jeff Sutherland

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Scrum = Scrum, sagt Ken Schwaber

Immer wieder gibt es Diskussionen darüber, ob Scrum als „reine Lehre“ genommen werden sollte, oder ob auch Modifikationen von Scrum sinnvoll sein können. Da Scrum so häufig nicht vollständig implementiert wird, hat sich mittlerweile der Begriff ScrumBut eingebürgert. Diese Bezeichnung kommt von der Aussage: „Wir nutzen Scrum, aber…“.

Bis zu welchem Maße Modifikationen an Scrum sinnvoll und sogar notwendig sind, ab wann sie aber nicht erwünscht sind, dazu hat Ken Schwaber, einer der Begründer von Scrum, jetzt in seinem Blog Stellung bezogen.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: