Open Space der Usergroup “Agile Rhein-Main” am 21.4.2012

Es war auf dem Rückweg vom “Community Day” einer Konferenz im vergangenen Jahr. Mit meinen Kollegen von //SEIBERT/MEDIA komme ich zu dem Schluss, dass das Open-Space-Format des “Community Day” mindestens so wertvoll war wie die Vorträge von den Vortagen. Die Vielfalt der Themen und die Interaktion der Sessions haben den Tag unglaublich kurzweilig und lehrreich gemacht.
Keine Frage, so etwas brauchen wir auch im Rhein-Main-Gebiet.

Gemeinsam mit Benjamin Reitzammer, Reto Kiefer und Joachim Seibert von der Agile Usergroup Rhein-Main haben wir in den letzten Wochen die Rahmenbedingungen abgestimmt und laden nun am 21.4.2012 zum 1. Agile Open Space Rhein-Main nach Wiesbaden in die Räumlichkeiten von //SEIBERT/MEDIA ein.

Was ist ein Open Space?

Um es auf den Punkt zu bringen: Wir bieten den Rahmen, Ihr sorgt für die Inhalte.

Bei einem Open Space gibt es keine vorab festgelegte Agenda. Jeder Teilnehmer bekommt die Möglichkeit, eigene Sessions zu seinen Wunschthemen einzubringen. Dies können vorbereitete Sessions sein, die eher den Charakter eines Kurz-Workshops haben, z.B. auch Dojos oder Katas. Aber auch Diskussionsrunden, bei denen der “Session-Host” nur das Thema einbringt und die Moderation der Session übernimmt, die Inhalte aber von allen Teilnehmern gemeinsam erarbeitet werden, sind üblich. Es gibt keine Verpflichtung, selbst Themen einzubringen, es kann sich auch einfach Sessions von anderen Personen angeschlossen werden.

Wir erhoffen uns ein breites Themenspektrum über Scrum, Lean, Kanban, XP, Agile, … in den unterschiedlichsten Ausprägungen.

Nicht zu kurz kommen soll dabei auch der lockere Austausch zwischen den Teilnehmern, etwa beim Mittagessen, so dass wir uns untereinander noch besser kennen- und voneinander lernen.

Anmeldung

Die Anmeldung zu diesem Event erfolgt über XING. Es wird bei Anmeldung eine Kostenbeteiligung in Höhe von 29 Euro für Verpflegung, Materialien und Organisation berechnet.

Hier geht es zur Eventseite bei XING.

Foto: von logicalrealist

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

Innovation needs waste – Verschwendung kann sinnvoll sein

Design ThinkingIm Rahmen einer Session auf den XPDays 2011 (17.-19.11.) wurde Design Thinking unter dem Titel “Innovation needs waste” von Dirk Lässig und Pierluigi Pugliese vorgestellt.

Im Kern der Session ging es um die Ergänzung von agilen und schlanken Vorgehensweisen in der Umsetzung durch Design Thinking in der vorgelagerten Ideengenerierung und -findung. Im Rahmen von “Agile” und Lean wird viel über die Vermeidung von Verschwendung gesprochen. Wenn das Ziel aber die Entwicklung einer innovativen Lösung bzw. eines innovativen Produkts ist, kann der Fokus im ersten Schritt nicht auf der Vermeidung von Verschwendung liegen. Hier ist zunächst einmal eine breit aufgestellte Suche sinnvoll, um sicherzustellen, dass ein sehr gutes Produkt für die zu lösende Problemstellung entwickelt wird.

Grundprinzipien des Design Thinking

Nach der Einleitung in das Thema stellten Lässig und Pugliese die Grundprinzipien von Design Thinking vor:

  • interdisziplinäres Team: Es wird mit interdisziplinären Zusammensetzung gearbeitet. Die Hintergründe sollten vielfältig sein. Es kommen z.B. Leute aus dem Marketing, dem Design, dem Vertrieb, Product Owner und Entwickler zusammen. Die Vielfalt wird als Bereicherung wahrgenommen.
  • iterativ & mit Timebox: Es wird über mehrere Iterationen hinweg an und mit den Ideen gearbeitet. Timeboxes helfen dabei, dass dennoch auf den Punkt auch ein Ergebnis vorliegt.
  • Ermutige Experimente: Experimente sollen angeregt und gefördert werden.
  • Kollektives Eigentum der Ideen: Ideen gehören, sobald sie geäußert wurden, dem Team und dürfen von jedem aufgegriffen und weiterentwickelt werden.
  • Reframe Fehler: Fehler mit Scheitern gleichzusetzen führt zu Angst, Fehler zu machen. Damit können innovative Ansätze im Keim erstickt werden. Ein anderes Verständnis von Fehlern ist daher erforderlich. Sie stehen auch für Erfahrung und gehören zum Erfolg dazu.
  • Sei empathisch: Versetze dich in die Anwender hinein.
  • Sei inspiriert.
  • Involviere reale Anwender: Damit die Lösung auch wirklich von den Nutzerbedürfnissen getrieben wird, sind diese in den gesamten Prozess einzubeziehen.
  • Entwickle Ideen: Denke nach.

Dann tauchten sie in das Thema ein und stellten vor, wie Design Thinking konkret angewendet wird.

Anwendung von Design Thinking – Breit starten, Optionen schaffen

Da es sich bei Design Thinking um ein iteratives Vorgehen handelt, lässt es sich als Kreislauf vorstellen, der mehrmals durchlaufen wird.
Der Kreislauf startet mit zwei zentralen Phasen:

1. Divergent thinking – create choices
2. Convergent thinking – make choices

In der Phase “divergent thinking” wird zunächst einmal unter Nutzung von Kreativitätstechniken Wert auf die Schaffung einer Vielzahl von Möglichkeiten gelegt. Es soll möglichst breit gedacht und sich umfangreich mit der Thematik beschäftigt werden. Viele Auswahlmöglichkeiten und Ideen sind besser als wenige. Insbesondere in dieser Phase wird deutlich, dass Verschwendung vorteilhaft sein kann. Wird am Anfang breit gedacht und in verschiedene Richtungen gedacht, steigt die Wahrscheinlichkeit für eine passende Lösung.
Im Rahmen des konvergenten Denken werden die am besten erscheinenden Wahlmöglichkeiten ausgesucht und für diese Prototypen gebaut und Feedback gesammelt. Dadurch kann gelernt werden und mit diesen Erkenntnissen eine neue Runde eingeleitet werden, die wieder mit dem divergenten Denken startet.

Methoden für die Ideengenerierung

Die Methoden, die im Rahmen des divergent thinking angewendet werden können, sind vielfältig. Es kann eine Vielzahl von Kreativitätstechniken genutzt werden. Eine Auswahl davon stellten Lässig und Pugliese im Rahmen der Session vor:

  • Innovation Games
  • Mindmaps
  • Brainstorming
  • Morphologischer Kasten
  • Disney Strategy (Dreamer, Implementer, Criticiser)
  • 6-3-5 (6 Personen, 3 Ideen, 5 Minuten)

Durch die Anwendung des Verfahrens 6-3-5 konnten wir als Teilnehmer auch selbst eines davon direkt ausprobieren.

Foto: thinkpublic

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

Erfahrungsberichte zur Scrum-Einführung

Scrum-Einführungen sind eine spannende Entdeckungsreise. Das lässt sich als Fazit aus zahlreichen Erfahrungsberichten herauslesen, die von Leuten veröffentlicht wurden, die sich mit einem Team auf diese Entdeckungsreise begeben haben.

Vielfach zeigt sich dabei ein ähnlicher Verlauf bei der Einführung von Scrum, den ich in diesem Artikel gespickt mit vielen Zitaten zusammengefasst dargestellen möchte.

Eine Scrum-Einführung stellt eine tiefgreifende Veränderung dar

Zunächst einmal sollten sich die Teams bewusst sein, dass sie sich auf eine große Veränderung einlassen, wenn sie Scrum einführen. Es ist nicht eine kurze Umstrukturierung und Umbenennung, sondern eine Veränderung des ganzen Mindsets und der Art, wie gemeinsam gearbeitet wird.

“Meine sicherlich wichtigste Erfahrung ist, dass eine sanfte Einführung von Scrum nicht möglich ist: ernenne den Projektleiter zusätzlich zum Scrum Master, erkläre den Produktmanager zum Product Owner, führe Taskboard, Sprint Planning, Review und Retrospektive ein und los geht’s.” (Katja Roth)

“Es genügt nicht, lediglich die neuen Rollen, Prozesse und Meetings einzuführen, aber ansonsten in den alten Strukturen zu verbleiben.” (Katja Roth)

Ein solches lapidares Vorgehen bei der Einführung von Scrum führt höchstens zu einem “Scrum, but”, dass bei weitem nicht die gewünschten Effekte bringt.

“Die erste Herausforderung war es, Scrum innerhalb des ganzen Unternehmens zu verstehen. Wenn Scrum als Projektmanagement-Methode oder als Vorgehensmodell wie etwa das Spiralmodell missinterpretiert wird, bleiben die meisten Vorteile ungenutzt.” (Traian Kaiser)

Dabei dürfen sich Teams auch nicht von der scheinbaren Einfachheit von Scrum blenden lassen.

“Das Regelwerk ist so unkompliziert und die Methode so einfach zu erlernen, dass man annimmt, man hat sofort alles verstanden. Erst wenn man Scrum tatsächlich einsetzt, merkt man, dass es sich um einen wirklichen Paradigmenwechsel handelt, der von allen Beteiligten ein radikales Umdenken verlangt.” (Ralf Ehrhardt)

Scrum-Einführungen erfordern Veränderungsbereitschaft und Ausdauer

Teams sollten sich auf einen langen gemeinsamen Weg einstellen, bei dem allen Beteiligten die Bereitschaft für tiefgreifende Veränderungen abverlangt wird. Eine Scrum-Einführung wirkt sich auch erheblich auf die gesamte Unternehmenskultur aus.

“Der Wille von Management und Mitarbeitern, diese Veränderungen voranzutreiben und auch mehr Verantwortung in die Teams zu geben und zu übernehmen, ist absolut notwendig. Damit dies funktioniert, bedarf es einer Unternehmenskultur, die grundsätzlich dem agilen Manifest folgen kann.” (Traian Kaiser)

Einige lieb gewonnene Angewohnheiten werden über den Haufen geworfen, um sich in der gemeinsamen Zusammenarbeit weiterzuentwickeln.

“Eine besonders große Herausforderung ist von Beginn an die Umsetzung der Maxime “Jeder macht alles” gewesen: Jedes Teammitglied hat ein Projekt, das ihm besonders am Herzen liegt, und sieht sich immer wieder versucht, sich vorwiegend um die Arbeiten an diesem Steckenpferd-Projekt zu kümmern.” (Manuel Kummerländer)

Die zunehmende Einbeziehung der Teams in viele Entscheidungen kostet dabei viel Kraft.

“Jetzt muss ich die Teams fragen, wie sie etwas lösen wollen, das ist oft anstrengend” (Oliver Zeiler)

“Die Selbstverantwortung und die vielen dadurch entstehenden Diskussionen finde ich recht auf- und anregend, manchmal auch sehr anstrengend.” (Manuel Kummerländer)

Auf einmal wird Personen Verantwortung übertragen, die dieses über einen langen Zeitraum nicht gewohnt waren.

“In den letzten 20 Jahren lief das so ab: Manager haben einen Plan erarbeitet. Wurde der umgesetzt, hieß das: Wir lösen jetzt das Kundenproblem mithilfe von Software. Die Manager wissen aber häufig nicht, wie man das macht. Deswegen schlage ich vor, dass man den Programmierern das Problem beschreibt, und sie finden dann selbst heraus, wie sie es lösen. (Ken Schwaber)

Erst nach und nach, über einen längeren Zeitraum, gewinnen alle Beteiligten eine zunehmende Sicherheit in ihren Rollen und lernen, mit der neuen Verantwortung umzugehen.

“Wir befinden uns auf einer langen Straße, die, um es noch bildlicher auszudrücken, am Anfang sehr holprig und ohne Beschilderung war und nun immerhin schon zu einer stattlichen Bundesstraße ausgebaut wurde.” (Matthias Müller)

Positive Veränderungen stellen sich nach und nach ein

Nicht umsonst entwickelte sich Scrum in den letzten Jahren zum State-of-the-Art-Vorgehensmodell in der Softwareentwicklung. Die meisten Erfahrungsberichte verweisen auf viele positive Effekte aus der Einführung von Scrum. Etwa Verbesserungen an der Qualität der Arbeitsergebnisse.

“Die Qualität unserer Software erscheint mir – insbesondere für so ein neues Team – schon sehr hoch. Wir haben viele Unit Tests mit annehmbarer Code Coverage, der Code ist fast zu 100% kommentiert, und die Software macht einen “runden” Eindruck.” (Mathias Raacke)

Aber auch Verbesserungen bei der Zusammenarbeit und der Produktivität.

“Alles in allem machen wir uns also immer besser. Es macht Spaß, zu erleben, wie man gemeinsam die Atmosphäre, in der man arbeitet, verändern, die Qualität verbessern und die Produktivität steigern kann.” (Matthias Müller)

Und erste Erfolge führen dazu, alle in ein gemeinsames Boot zu holen.

“Da haben alle anderen gesehen, dass Scrum Spaß macht und sexy ist.” (Oliver Zeiler)

Machen wir uns nichts vor: Eine Scrum-Einführung ist kein leichtes Unterfangen. Aber die positiven Effekte einer gelungenen Einführung zeigen sich auf vielen verschiedenen Ebenen. Und so lohnt sich diese Reise, auch wenn sie niemals wirklich zu Ende geht… .

Erfahrungsberichte von Scrum-Einführungen:

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-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

Non-Profit-Konferenz “Deutsche Scrum 2011″ am 12./13.7. in Stuttgart

Am 12. und 13. Juli findet in Stuttgart ein Treffen von Scrum-Enthusiasten und jenen, die Scrum noch besser (kennen-)lernen möchten, statt. Es handelt sich dabei um eine Non-Profit-Konferenz, zu der sich bereits zahlreiche Scrum- und Agile-Coaches angekündigt haben. Das gewählte Format beinhaltet einen OpenSpace-Anteil, so dass nicht nur zuschauen und zuhören, sondern auch eine aktive Beteiligung an der Konferenz möglich ist.

Produktvision

Stefan Roock hat einen Vorschlag für die Produktvision des Events gemacht, der auf Zustimmung gestoßen ist:

Für Unternehmen, die Scrum anwenden (wollen) ist das Deutsche Scrum-Meeting 2011 eine kleine Non-Profit-Konferenz mit klassischen Vorträgen sowie nicht-klassischen Sessions wie Innovations-Cafe.

Im Gegensatz zu den XP-Days Germany kümmert sich das Deutsche Scrum-Meeting ausschließlich um Scrum.

Im Gegensatz zum europäischem Scrum-Gathering findet das Deutsche Scrum-Meeting auf deutsch statt mit Teilnehmern aus dem deutschsprachigem Raum.

Ablauf

1. Tag

Start mit einem Open Space für alle. Danach Open Space mit dem Thema “Scrum Advanced” mit parallel einem Anfänger-Track und einem Track Intermediate/Special Interest

9 – 12h : Open Space
13-17h : Open Space Advanced Scrum
13:00-14:30h: Session INTRO 1
15:00-16:30h: Session INTRO 2

2. Tag

9 – 10:30h : World Cafe
Tracks: 11h – 16h :
Track 1: Team practices
Track 2: Scrum und andere Methoden: Synergin und Tendenzen
Track 3: Scaling Scrum, Scrum at Scale, Das Agile Unternehmen

Anmeldung

Die Anmeldung zum und Koordination des Treffens erfolgt über die Seite http://dtscrum2011.crowdvine.com/.

25 Blogs zu Scrum und agiler Softwareentwicklung

Welche Blogs zu Scrum und agile Softwareentwicklung solltet ihr nicht verpassen? Vor einiger Zeit habe ich meine persönlichen Top 5 Scrum-Blogs vorgestellt. Agile Office fragte in einem Kommentar, welche weiteren Blogs ich zu dem Thema lese.
Nachfolgend daher eine umfangreichere Liste von 25 Blogs zu Scrum und agiler Softwareentwicklung:

  1. “Scrum Log” von Jeff Sutherland: Der “Vater von Scrum” schreibt seit 2002 über alles rund um Scrum, von “Dealing with Bugs in a Sprint” bis zu “Hackathons – How it’s done at Facebook”
  2. “Telling It Like It Is” von Ken Schwaber: Der Mitbegründer von Scrum und Gründer von Scrum.org schreibt regelmäßig über seine Sicht auf die Entwicklungen in der Scrum Community.
  3. ScrumAlliance Articles: Hier gibt es Artikel von vielen erfahrenen Scrum Trainern und Professionals.
  4. “bor!sgloger — leading Scrum with passion” von Boris Gloger: Einer der bekanntesten Scrum-Trainer aus Deutschland versorgt uns regelmäßig mit aktuellen Tipps und Tricks rund um agile Softwareentwicklung.
  5. “All Things Product Owner” von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board.
  6. “Lean und Kanban” von Arne Roock: Der Prokurist bei it-agile und Träger eines schwarzen Gürtels in Karate schreibt einen der wenigen deutschen Blogs über Kanban in der Softwareentwicklung.
  7. “Dayley Agile” von Alan Dayley: Ein Softwareentwickler, der seit vielen Jahren auf agile Softwareentwicklung schwört und seine Erfahrungen mit uns teilt.
  8. Implementing Scrum von Michael Vizdos: Der Scrum-Trainer berichtet von seinen Erlebnissen, Tony Clark liefert ihm herausragende Illustrationen dazu. Sehr sehenswert.
  9. “inside-scrum” von Jean-Pierre: Ein Anwenderbericht vom Start und der Durchführung eines Scrum-Projekts.
  10. Agile Product Design: Agile Softwareentwicklung betrachtet aus dem Blickwinkel des Product Designs, eine längere Zeit schon still, aber mit sehr interessanten Artikeln.
  11. Peter Beck: Scrum-Trainer von DasScrumTeam. Zuletzt leider etwas ruhig geworden.
  12. “scrum breakfast”: Die Selbstbeschreibung drückt es am besten aus: “Blog about Scrum: getting started, crisis project management and transforming into a lean organization.”
  13. ScrumEdge: Ein weiteres Scrum-Blog, das durch eine hohe Frequenz von guten Artikeln überzeugt.
  14. “Agile Product Owner” von Jennifer: Die Eigenbeschreibung “Sharing the Art of Agile Product Ownership” trifft es auf den Punkt. Zuletzt ist es in dem Blog leider eher ruhig geworden.
  15. ScrumCenter: Der Corporate Blog eines agilen Beratungsunternehmens. Viele Inhalte von Präsentationen werden behandelt, aber auch auf interessante Artikel verwiesen.
  16. Scrumology von David Bland: Entgegen dem Namen geht es nicht nur um Scrum, sondern auch um Kanban und “schlanke” Softwareentwicklung. David teilt seine Erfahrungen aus der Praxis.
  17. Stefan Roock: Der Trainer für agile Softwareentwicklung berichtet über seine Erlebnisse und Erfahrungen aus seiner Beratungstätigkeit.
  18. The Agile Executive von Israel Gat: Dieser Blog beschäftigt sich mit dem Rollout von “Agile” auf Unternehmensebene, also über einzelne Teams hinweg.
  19. The Agilista PM von Donna Reed: Mit Fachartikeln, Webinaren und Webcasts werden hier Aspekte des agilen Projektmanagements behandelt.
  20. Scaling software agility: Wie lässt sich agile Softwareentwicklung in großen Projekten einsetzen? Hier gibt es Antworten.
  21. PM-Blog von Stefan Hagen: Obwohl sein Blog nicht ausdrücklich auf agile und schlanke Vorgehensweisen fokussiert, ist ihm dieses Faible von Stefan anzumerken.
  22. “ScrumTools – agiles Projektmanagement”: Neben einer Liste von Scrum-Tools gibt es von Zeit zu Zeit Artikel im zugehörigen Blog.
  23. agileoffice: Agile, Lean und Scrum sind die Themen, mit denen sich dieses Blog beschäftigt.
  24. “Systems Thinking, Lean and Kanban” von David Joyce: David teilt seine langjährigen Erfahrungen als Coach und Teammember und verweist regelmäßig auf spannende Artikel.
  25. “Lean Software Engineering” von Corey Ladas und Bernie Thompson: Die beiden teilen ihre Erfahrungen aus Teams von u.a. Microsoft und IBM. Ihre Artikel bekommen hohe Aufmerksamkeit und sorgen regelmäßig für umfangreiche Diskussionen.
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: Von Rafa[EU]

Agile Days bei der jax in Mainz

Anfang Mai findet in Mainz erneut die jax statt, eine Konferenz für Java, Architektur, Cloud und Agile. Im Programm sind auch einige Special Days, bei denen sich intensiv ausgewählten Schlüsselthemen gewidmet wird.

Drei dieser Special Days behandeln die verschiedenen Aspekte agiler Softwareentwicklung.
Zum Agile Day (2. Mai) werden unter anderem Jutta Eckstein (Autorin von “Agile Softwareentwicklung mit verteilten Teams”), Jens Coldewey (Geschäftsführer von it-agile) und Roman Pichler (Autor von “Scrum – Agiles Projektmanagement erfolgreich einsetzen”) erwartet. Inhalt der Sessions sind eher grundlegende Fragestellungen zur Agilität.
Beim Agile Day interaktiv (2. Mai) wird live gezeigt, wie u.a. Coding Katas und Retrospektiven ablaufen sollten. Karateka Arne Roock wird gar vorführen, woher die Bezeichnung “Kata” kommt.
Bei den Agile ALM Days (3. und 4. Mai) wird es wieder sehr technisch. “Besser Software schreiben” ist das Ziel, das u.a. durch professionelles Build-Management, technische QS und Continous Integration erreicht werden soll.

Zu den Special Days der jax 2011 in Mainz

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

Die besten Ressourcen zu User Stories

Userstories sind eine besondere Form der Anforderungsbeschreibung, die sowohl Kunden, Anwender, Projektmanager als auch Softwareentwickler verstehen können. Besonders gerne werden sie in der agilen Softwareentwicklung eingesetzt. Dieser Beitrag gibt einen Überblick über die besten Artikel und Bücher zum Thema User Stories:

Deutschsprachige Artikel

Englischsprachige Artikel

Buchtipps:

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

Englische Version des Artikels

Follow

Get every new post delivered to your Inbox.

Join 712 other followers