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.

„Scrum & Kanban im Agenturgeschäft“ – Slides jetzt online

Im Rahmen des andrena ObjektForum berichtete ich am vergangenen Dienstag über Scrum & Kanban im Agenturgeschäft von //SEIBERT/MEDIA. Seit etwa eineinhalb Jahren nutzen wir in mehreren Teams intensiv die Möglichkeiten der agilen Softwareentwicklung und weiten die Ideen nach und nach auch auf das gesamte Unternehmen aus.

Durch die aktive Beteiligung der Zuhörer entwickelte sich der Vortrag zu einem eineinhalb-stündigen Dialog. Vielen Dank an alle, die dabei waren und auch an Kurt Jäger von andrena für die Ausrichtung und Moderation.

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

Vortrag zu “Scrum & Kanban im Agenturgeschäft” am 10.1. in Frankfurt

Für Agenturen mit ständig wechselnden Projekten stellt es eine besondere Herausforderung da, agile und schlanke Vorgehensweisen wie Scrum und Kanban anzuwenden. Dieser Vortrag beleuchtet, wie Agenturen Scrum und Kanban für die Verbesserung ihrer Abläufe einsetzen können, wann besser auf Scrum und wann besser auf Kanban gesetzt werden sollte, sowie die kritischen Erfolgsfaktoren bei der Einführung von “Agile” in Unternehmen. Dabei werden u.a. Fragen wie diese beantwortet:

  • Lohnt sich die Einführung von agilen Vorgehensweisen?
  • Wie führe ich agile Vorgehensweisen im Unternehmen ein?
  • Welche Voraussetzungen für einen Erfolg bestehen?
  • Soll ich besser auf Scrum oder auf Kanban setzen?
  • Welche Fallstricke und welche Herausforderungen gibt es zu überwinden?
  • Wie kann ich Scrum und Kanban in nicht-Programmierprojekten einsetzen?
  • Wie werden wir zum agilen Unternehmen?

Datum und Zeit: 10. Januar 2012 um 18:30 Uhr

Ort: Saalbau Gallus, Frankfurt

Referent: Paul Herwarth von Bittenfeld

Moderation: Kurt Jäger (andrena objects ag)

Die Anmeldung erfolgt über die Website von andrena

Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: “Ist das Daily Standup für Teammitglieder zwingend?”
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung “daily scrum” verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit “Strafen”, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

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

Hyperproduktive Teams mit Scrum: “From Good to Great”

Wie können gute Teams mit Hilfe von Scrum zu großartigen Teams werden? Damit beschäftigt sich Scrum Co-Founder Jeff Sutherland schon seit vielen Jahren. Vor einiger Zeit hat er hierzu in seinem Blog geschrieben.

Jeff Sutherland macht allen motivierten Teams Hoffung, dieses Ziel erreichen zu können. Nach dem aktuellen Forschungsstand soll jedes Team in der Lage sein, hyperproduktiv zusammenzuarbeiten, auch wenn das Unternehmen, in dem das Team arbeitet, nicht die optimalen Bedingungen bietet.

Auf welche Punkte sollten Teams unbedingt achten, wenn sie hyperproduktiv zusammenarbeiten möchten?

  • Alle Teammitglieder müssen in Scrum geschult sein.
  • Der Backlog muss READY seine, bevor er in einen Sprint übernommen wird.
  • Das Software-Inkrement muss am Ende jedes Sprints DONE sein.
  • Immer wenn nur eine Person eine Aufgabe erledigt werden kann, sollte sofort mit Pair Programming gearbeitet werden.
  • Volle Fokussierung – kein Multitasking.
  • Das Team nutzt ein physisches Scrum Board / Taskboard.
  • Kurze Sprints, häufig von nur einer Woche.
  • Der Burndown erfolgt auf Story Point-Ebene (nicht Tasks oder Stunden)
  • Alles (inklusive Support) wird durch den Product Owner priorisiert.
  • Die höchstpriorisierten Hindernisse müssen aus dem Weg geräumt werden.
  • Die Führung des Teams erfolgt nach dem “Servant leadership”–Gedanken.

Eine Verdopplung der Produktivität ist laut einer Untersuchung bereits dann möglich, wenn darauf geachtet wird, dass alle Arbeiten am Ende des Sprints auch wirklich DONE sind. Die Fehlerquote konnte bei den betrachteten Scrum-Teams damit um ganze 40 Prozent reduziert werden. Wenn die Teams konsequent daran arbeiten, Hindernisse aus dem Weg zu räumen und ihre Arbeiten wirklich DONE abzuschließen, können sie leicht ihre Produktivität drastisch erhöhen. Leider tun dies nur geschätzte 50 Prozent der Scrum-Teams auf der Welt.

Eine weitere Verdopplung der Performance des Teams kann erreicht werden, wenn der Backlog einen hohen Grad von READY erreicht. Dies wirkt sich direkt auf die Effizienz in der Story-Umsetzung aus. Wenn Teams es schaffen, ihre Arbeiten jeweils entsprechend der Definition of DONE abzuschließen und auch einen sauberen Backlog pflegen, der hochgradig READY ist, können sie den Untersuchungsergebnissen nach durchaus mit der vierfachen Produktivität eines Durchschnittsteams erreichen.

Ein weiteres Level der Produktivität kann erreicht werden, wenn es sich um selbstorganisierende Teams handelt, die an der Maximierung ihrer (nachhaltigen) Team Velocity arbeiten und gemeinsame Ziele verfolgen. Dies erfordert flache Organisationsstrukturen und enge Zusammenarbeit.

Auch wenn es einfach klingt, ist es mit Sicherheit herausfordernd in der Umsetzung. Auch hier zeigt sich, dass eine gute Anwendung von agiler Softwareentwicklung viel Disziplin erfordert. Angesicht der starken Produktivitätsverbesserungen, die möglich sind, lohnt es sich denke ich dennoch, sich weiter in diese Richtung zu entwickeln. Dabei hilft diese Präsentation von Jeff Sutherland:
A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity (PDF)

Foto: drewgstephens

——–
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.

“Kanban und Scrum in der Praxis” bei AOE Media in Wiesbaden

Am 20.10.2011 findet ab 19:30 Uhr das nächste Treffen der Scrum User Group Rhein-Main statt. Nach dem Special „Scrum & Kanban im Agenturgeschäft“ im Juni 2011, bei dem Joachim Seibert und ich die Nutzung von Agile am Beispiel von //SEIBERT/MEDIA präsentiert haben, wird es wieder ein Special zu “Kanban und Scrum in der Praxis” geben.
Gastgeber sind die Kollegen von AOE Media in Wiesbaden.

Die Agenda für den Abend:

  • Begrüßung und Kurzvorstellung AOE media
  • Scrum im Einsatz bei Congstar
  • Kanban als Methode bei AOE
  • Diskussionsrunde: Vorteile und Gegenüberstellung Scrum vs. Kanban oder spezialisierte Teams vs. Generalisten
  • Offene Runde

Für Snacks und Getränke ist gesorgt.
Zum anschließenden Austausch und Socializing werden wir noch ein Lokal in unmittelbarer Nähe aufsuchen.

Die Anmeldung zu diesem Event erfolgt per XING. Ein besonderer Dank gilt bereits jetzt Joern Bock für die Ermöglichung dieser Veranstaltung.

Einen kleinen Vorgeschmack auf das Event bietet der Vortrag von AOE-Media-Mitarbeiter Andreas Demmer zu Kanban vom Webmontag #32.

Rückblicke auf die Veranstaltung

Produktmanagement Lesetipps: Architekturvision in Scrum, Top 10 Startup-Erfolgsregeln, Kundenfeedback, Kostenplanung in agilen Projekten

Die Produktmanagement Lesetipps enthalten diesmal eine Mischung aus Beiträgen zu agiler Softwareentwicklung, Startup-Vermarktung und der Nutzung von Kunden-Feedback. Viel Spaß dabei! Falls Ihr in letzter Zeit einen spannenden Artikel aus diesem Themenbereich gefunden habt, teilt es doch über einen Kommentar mit.

Die Architekturvision in Scrum

Auch wenn ein Team nach den Leitsätzen und Prinzipien der agilen Softwareentwicklung arbeitet, ist eine initiale Architekturvorstellung wichtig, um nicht ständig alles umbauen zu müssen. Sie muss aber Raum lassen, um inkrementell von Sprint zu Sprint weiterentwickelt werden zu können.
Stefan Roock und Roman Pichler stellen in einem Artikel das Konzept der Architekturvision vor und beschreiben Kriterien und Techniken für ihre Erstellung: “Die Architekturvision in Scrum: Vorausplanung und emergentes Design balancieren”. Er kann als PDF heruntergeladen werden.

Richtig groß rauskommen

Reid Hoffman, Co-Founder und Vorsitzender von LinkedIn hat auf Greylockvc.com 10 Regeln für Gründer veröffentlicht, zu denen er beim diesjährigen South by Southwest vorgetragen hat.
t3n hat diese 10 Regeln wie man richtig groß rauskommt auf deutsch übersetzt. In seiner 10. Regel stellt Hoffman selbst klar, dass solche Regeln nicht als Naturgesetz, sondern als Richtlinie verstanden werden sollten. Wenn man den Erfolg von Hoffman bedenkt, der neben der Mit-Gründung von LinkedIn und PayPal auch in Facebook, Flickr und Zynga investiert hat, lohnt es sich, sich ein paar Minuten Zeit für seine Erkenntnisse zu nehmen.

Warum Kundenfeedback wichtig ist

Evan Hamilton, Community Manager des Kunden Engagement Tools Uservoice, stellt seine Präsentation vom Online Community Meetup in San Francisco zur Verfügung.
Darin präsentiert er, warum Kundenfeedback so wichtig ist, wie es erhalten und gesammelt werden kann. Er gibt auch einen kleinen Einblick, wie am besten mit Kundenwünschen umgegangen wird, gegen deren Umsetzung sich das Unternehmen entscheiden hat.

Kostenplanung in agilen Projekten

Bei Scrumology schreibt Kane über die Kostenplanung in agilen Projekten. Sein zentraler Punkt: Kostenplanung wird durch agile Softwareentwicklung unglaublich viel einfacher.

There are two important facts about Agile projects that I need to make clear before I continue.

  • Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.
  • Agile teams are dedicated for the duration of the project. At the risk of repeating myself, this means that everyone (Analysts, Developers, Testers etc) are 100% allocated to the project for the entire duration of the project.
    • Given these two ideas, it should now be obvious how to cost an Agile project. We have static team compositions and the team is dedicated 100% of the time, so there is a fixed cost for the team per day.

Mit einer Beschätzung durch das Team und das Abschätzen der benötigten Sprints kann somit eine wesentlich bessere Schätzung abgegeben werden als in Projekten, bei denen zahlreiche Übergabepunkte mit einem Wechsel der beteiligten Personen bestehen.

Weitere Ausgaben der Produktmanagement Lesetipps:

Follow

Get every new post delivered to your Inbox.

Join 712 other followers