Review: “The Lean Startup” von Eric Ries

"The Lean Startup" von Eric RiesBei der Schaffung von erfolgreichen Produkten und Dienstleistungen liegt heutzutage die größte Herausforderung nicht mehr in der Produktion oder Codierung, als vielmehr im sogenannten “market-fit”. Tatsächlich die Kundenbedürfnisse zu treffen, ist die größere Herausforderung für den Produktmanager von heute.
“The Lean Startup” von Eric Ries beschreibt ein Vorgehen, das für die erfolgreiche Realisierung von Ideen unter dieser Unsicherheit Anwendung finden kann. Es möchte dabei helfen, mit möglichst wenig Aufwand die Marktfähigkeit einer Idee zu testen, bevor diese in ein Produkt umgesetzt wird.

Der Kern: Build – Measure – Learn

Eric Ries schafft mit “Lean Startup” nicht wirklich etwas neues. Es handelt sich um eine Sammlung von Praktiken, Sicht- und Vorgehensweisen, die einen Namen erhalten, der für die Beseitigung der Unsicherheit steht, die jedem Produktmanager Unbehagen bereitet. Hervorzuheben bleibt dennoch, dass er eine Struktur in diese Vorgehensweisen bringt und so ein systematisches Vorgehen vereinfacht.

Im Kern steht dabei der Zyklus von “Build – Measure – Learn“. Ausgehend von einer Idee wollen wir etwas bauen, um damit einen Test durchzuführen. Mit dem, was wir gebaut haben, messen wir, ob unsere vorab getroffenen Annahmen sich bewahrheiten. Aus den Ergebnissen können wir lernen, ob wir uns auf dem richtigen Weg befinden oder mehr oder weniger tiefgreifende Anpassungen vornehmen müssen. Diesen Zyklus von Build – Measure – Learn versuchen wir immer schneller zu durchlaufen, in dem wir unsere Testverfahren optimieren.
Das wichtigste Ergebnis dieses Vorgehens ist nicht das Produkt, der Code oder ähnliches, was dabei entsteht, sondern das validierte Lernen. Wir beginnen, zu verstehen, was wirklich Akzeptanz am Markt erhalten kann.
Mit diesem Wissen können wir dann Produkte entwickeln, die sich durch einen guten “market-fit” auszeichnen.

Viele Praxisbeispiele, für die Anwendung ergänzende Literatur hilfreich

Durch eine Vielzahl von Praxisbeispielen verdeutlicht Eric Ries dieses Vorgehen. Die Beispiele reichen dabei von Internet-Anwendungen, die ihr Geschäftsmodell erst einmal komplett unautomatisiert im Real Life abbilden, bis hin zu Bundesbehörden, die erst einmal mit kleinem Budget auf lokaler Ebene den Dienst aufnehmen, um in kleinem Rahmen vor dem bundesweiten Roll-out zu lernen. Das Anwendungsfeld von Lean Startup ist breit.
Trotz der vielen Beispiele aus der Praxis bleiben noch viele Fragen für die konkrete Umsetzung und Anwendung in “The Lean Startup” offen. Das Buch verdeutlicht in erster Linie die Denkweise dahinter. Oder wie Eric Ries es sagen würde: “The philosophy of lean ist not just a concept or systematic approach, it is an aligned way of thinking and acting”. Es ist daher ein sehr guter Startpunkt für die Beschäftigung mit dem Thema, das dann um weitere Literatur ergänzt werden sollte.

Das Buch ist in verschiedenen Varianten verfügbar:

Weitere Literatur aus dem Themenbereich:

Interessante Blogs zum Thema:

  • Startup Lessons Learned von Eric Ries: Hier teilt er seine Gedanken rund um Lean Startup, Customer Development und Agile Produktentwicklung.
  • SteveBlank.com: Regelmäßige Posts zu aktuellen Präsentationen und Gedanken rund um Customer Development, Geschäftsmodell-Optimierung und Lean Startup.

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

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.

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

Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

  • Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
  • Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
  • Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
  • Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

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

Englische Version des Artikels

Aus Fehlern eine Chance machen

Problems are OpportunitiesEin aktueller Vorfall bei UserVoice zeigt sehr schön, wie sich aus Fehlern eine Chance machen lässt. UserVoice ist eine Webanwendung, die es ermöglicht, gemeinsam mit den Nutzern Feature-Wünsche und Fehlermeldungen zusammen zu tragen, zu diskutieren und bewerten zu lassen. Es hilft entsprechend, die Bedürfnisse der Kunden und Anwender besser zu verstehen und passgenauere Lösungen zu entwickeln.

Ungewollt wurde den kostenfreien Nutzern eine Funktion freigeschaltet, die eigentlich nur für kostenpflichtige Nutzer vorgesehen ist: sie konnten mehrere Administratoren gleichzeitig hinterlegen.

Die Ankündigung der Behebung dieses Fehlers erfolgt durch den UserVoice Community Manager Evan Hamilton auf diese Weise:

“Hey there,

The other day we discovered that we screwed up, and you benefited from it. You basically got the “Bank Error in Your Favor” card from the Monopoly board game. :)

Free UserVoice accounts are only supposed to be allowed to have a single Admin…to add additional Admins, you must upgrade your account. Due to a bug, this wasn’t the case: you, and a number of other accounts, were able to add as many Admins to your Free plan as you wanted. Oh dear.

Obviously, we need to rectify this; we can’t make any money unless we have limits on our accounts. However, this was our error and we do feel badly about that. Here’s what we’re going to do:

We’ll give you a little over 60 days (what with holiday schedules and all) to upgrade your account before we reactivate the restrictions. For more info on our plans, see http://uservoice.com/plans. To change your plan, follow these steps: https://feedback.uservoice.com/knowledgebase/articles/40223. That means you have until about February 13th to make any adjustments.
We’re going to give you 50% off any UserVoice plan for a year, since this was our issue. Just use this code: freebug (How to redeem: https://feedback.uservoice.com/knowledgebase/articles/40216)
I’m extremely sorry you had to be inconvenienced by this (Though I’m glad you were undercharged, not overcharged!) and I’d be happy to answer any questions you might have. Thanks for your understanding!

-Evan Hamilton
Community Manager, UserVoice”

Diese Dinge macht Evan in diesem Fall meines Erachtens besonders gut, um aus dem Fehler eine Chance für eine höhere Kundenbindung und mehr Umsatz zu ziehen:

  • Der offene Umgang mit dem Fehler führt zu einer großen Sympathie und schafft Vertrauen.
  • Es ist ein Anlass für UserVoice, mal wieder alle kostenfreien Nutzer zu kontaktieren. Aus eigener Erfahrung kann ich sagen, dass das kurzzeitig zu einer deutlichen Zunahme der Aktivität der Nutzer führt.
  • Die kostenfreien Nutzer erhalten den Vorteil für weitere 60 Tage, so dass auch andere kostenfreien Nutzer den ungeplanten Vorteil temporär nutzen und somit ein Premium-Feature ausprobieren können.
  • Evan leitet direkt in einen Verkaufsprozess über. Durch das besondere Angebot eines 50%-Discounts wird es besonders interessant, ein Upgrade durchzuführen.

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

Tipps zur Priorisierung des Product Backlogs von Mike Cohn

Product Backlog PriorisierungEine echte Perle zum Thema Priorisierung des Product Backlogs habe ich kürzlich bei Axel Heinz gefunden. Es handelt sich dabei um einen Vortrag von Mike Cohn (ich habe hier schon über sein Buch “User Stories Applied” geschrieben). In diesem Vortrag stellt er nach einer Einführung in das Thema und dessen Bedeutung die vier Ansätze für die Priorisierung des Backlogs vor: Kano-Analyse, Theme-Screening, Theme-Scoring und relative Gewichtung.

Die Bedeutung guter Backlog-Pflege

Mike Cohn betont zunächst noch einmal die Bedeutung der Pflege des Backlogs. Er konnte in der Praxis zahlreiche Teams beobachten und die richtig guten Teams zeichneten sich alle dadurch aus, dass sie rund 10% ihrer Zeit in die Pflege des Product Backlogs stecken und diesen aktiv pflegen.
Das Stichwort lautet hier Backlog Grooming und kann zum Beispiel in Form von Workshops mit dem ganzen Team erfolgen.
Mike Cohn betont, dass es für Entscheidungen in der Backlog Priorisierung immer eine solide Grundlage geben sollte, wie etwa die Ergebnisse von Umfragen, aus Statistiken oder ähnliches. Statistisch signifikant braucht es für ihn nicht zu sein, aber z.B. das Feedback von 20-30 Anwendern im Rahmen einer Umfrage kann schon viel aussagen.
Nun aber zu den vier Maßnahmen, die er im folgenden vorstellt.

Kano-Analyse

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten in verschiedene Kategorien möglich ist:

  • Basisfaktoren: Basisfaktoren werden von den Anwendern als selbstverständlich vorausgesetzt. Werden sie erfüllt, entsteht keine Zufriedenheit, bei Nichterfüllung entsteht jedoch Unzufriedenheit.
  • Leistungsfaktoren: Diese wirken linear und ein mehr von dieser Funktionalität führt zu mehr Zufriedenheit der Anwender.
  • Begeisterungsfaktoren: Begeisterungsfaktoren werden vom Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, den seine Frau spitze fand, der 1993 noch keineswegs selbstverständlich war. So etwas kann sogar das “Zünglein an der Waage” für eine Kaufentscheidung sein.

Manchmal ist es gerechtfertigt, darüber Schätzungen abzugeben, in welche Kategorie eine Funktionalität fällt. Noch sinnvoller ist meist jedoch die Befragung einer kleinen Gruppe von Anwendern, etwa 20-30 Stück.
Als Tipp für die Einplanung in das Produkt schlägt er vor, dass alle Basisfaktoren integriert werden, da sonst mit Unzufriedenheit gerechnet werden muss. Darüber hinaus sollten einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren eingeplant werden.

Weitere Informationsquellen für das Kano-Modell:

Theme-Screening

Das Vorgehen beim Theme-Screening erfolgt mit den folgenden Schritten:

  1. Identifiziere als erstes die Faktoren, die für die Priorisierung als Kriterien für das nächste Release herangezogen werden sollen. Zum Beispiel die Bedeutung für die bestehenden Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa 5-9 Kriterien sein.
  2. Nach der Festlegung der Priorisierungskriterien wird ein “baseline theme” gewählt. Eine Story oder ein Theme, die im weiteren Vergleich als Basis für die relative Bewertung genutzt wird. Dafür eignen sich solche, die wahrscheinlich in das nächste Release aufgenommen werden und das allen Teammitgliedern vertraut und verständlich ist. Es sollte aber nicht das wichtigste Theme sein, da in diesem Fall alle weiteren Themes im Verhältnis schlechter abschneiden würden. Das gilt also analog zu Referenz-Stories beim relativen Beschätzen des Product Backlogs, wo meist eine mittelgroße oder eine eher kleinere Story als Vergleich genutzt wird.
  3. Alle Themes oder Stories, die zur Auswahl stehen, werden nun im Vergleich zum “baseline theme” nach allen Kriterien bewertet. Für die schlechter abschneidenden Themes wird jeweils ein – eingetragen, für die besser abschneidenden ein + und für die gleich zu bewertenden Themes eine Null.

Mike Cohn stellt auf seiner Website sogar ein kleines Tool zum Theme-Screening bereit, das auch schnell das Vorgehen beim Theme-Screening verdeutlicht.

Weitere Informationsquellen für das Theme-Screening:

Theme-Scoring

Theme-Scoring ist dem Theme-Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Als erstes werden auch hier die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie einen Prozentwert, der sich zu 100% aufsummiert.

Als nächstes werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes bewertet auf einer Skala von 1-5, wobei 1 für eine schlechte Erfüllung des Kriteriums und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, als erstes für alle Kriterien ein Basis-Theme festzulegen, dass eine Bewertung von 3 erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.

Mike Cohn stellt auf seiner Website auch ein kleines Tool zum Theme-Scoring bereit.

relative Gewichtung

Die relative Gewichtung (“relative weighting”) ist ein Priorisierungsansatz, bei dem sowohl die positive Auswirkung der Präsenz eines Features als auch die negative Auswirkung der Abwesenheit eines Features in die Beurteilung einbezogen wird. Für jede Funktionalität wird eine bewertung von 0 (gering) bis 9 (hoch) vorgenommen.

Die Themes werden dabei in die Reihen einer Tabelle eingetragen. Dann wird jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und der Strafe bei Abwesenheit hinterlegt. Zusätzlich wird noch ein Wert für den geschätzten Aufwand, etwa in Story Points oder auch einem Euro-Betrag, hinterlegt. Es werden also in diesem Fall die Kosten einer Funktionalität explizit mit berücksichtigt.
Es wird dann geschaut, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden durcheinander geteilt und es ergibt sich eine Priorisierungskennzahl.

Anteil am Gesamtnutzen Anteil an den Gesamtkosten Priorisierung
57% 67% 0.85
43% 33% 1.30

Das als zweites in diesem Fall aufgeführte Feature bringt zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger. Dadurch ist der Return on Investment (ROI) von letzterem größer.

Auf der Website Mike Cohn gibt es auch zur relativen Gewichtung ein kleines Tool.

Links zum Vortrag von Mike Cohn

Der Vortrag von Mike Cohn
Folien von Mike Cohn (PDF)

An dieser Stelle möchte ich auch noch auf eine Excel-Vorlage für die Product Backlog Priorisierung von Michael Romer hinweisen.

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

Englische Version des Artikels

“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

Bekomme jeden neuen Artikel in deinen Posteingang.

Join 1,272 other followers