scrum im marketing
DESCRIPTION
Wie wir Scrum im Marketing einsetzen, zeigen diese Slides, als Anwendungsfall von "Scrum beyond IT". Gehalten auf einigen deutschen Agile Konferenzen 2013, wird regelmäßig hier auf Slideshare aktualisiert.TRANSCRIPT
Scrum im Marketing„Scrum beyond IT“ sinnvoll nutzen
Björn Schotte // @BjoernSchotte // [email protected] GmbH http://creativecommons.org/licenses/by-sa/3.0/deed.de
Über den Referenten: Björn Schotte‣ Unruhestifter ;-)
‣ Geschäftsführer MAYFLOWER GmbH
‣ CSM + CSPO
‣ Scrum seit 2006. Wir lernen noch.
‣ hilft Kunden, die Herausforderungen ihres Geschäfts im Online Umfeld zu lösen.
‣ MAYFLOWER: 60+ Devs, Individualsoftware Web, Mobile & E-Business/E-Commerce
Agil bei Mayflower:Scrum + Kanban
(Dev-Teams + Sysadmin)
Marketing bei Mayflower
Website. Blog. mtl Webinare. 2-3 Konferenz-Stände/Jahr. Microsites. Marketing Devtools. CRM. Facebook. twitter. Marketing Collateral. Case Studies. Werbeanzeigen. Eigene Events. DoVos. Grafikdesign. PR/MarCom. Texte schreiben. Videos drehen. Fotos nachbearbeiten. Cluetrain Manifest. Konferenz-/RFP-Scouting. Kommunikation nach innen. Studien. Broschüren. Mini-eBooks. Tools wie http://scrumbutt.me/. Xing Unternehmensprofil. Mayflower Xing Gruppe. Newsletter. Confluence WikiSpace. Präsentationen. Fotolia. Sales Support. Redaktioneller Review. Personas. YouTube Channel.
PHP5. MySQL5. NodeJS. puppet. JavaScript. HTML5. CSS3. ResponsiveDesign. Git/GitHub. Mac/Windows. Mobile Apps. SaaS. Drupal. WordPress. SugarCRM. WebServices.
Warum Scrum im Marketing?
Um Vielfalt + Menge an Aufgaben geordnet und
robust in Teilinkrementen zu liefern.
Bereits mehr als 2.000 User
Stories geliefert.
Unsere Scrum Reise ...
Die Anfänge: 2011/2012
Unkoordinierte, spontante Einführung
durch mich.#WTF #FAIL
Kein „Mitnehmen“ der Non-Techies im
Team
Scrum Master aus dem Team.
Nutzung JIRA als Kalender für
wiederkehrende Aufgaben.
Fazit:wenig erfolgreich und frustrierend für alle
#WTF #FAIL
Reboot.2012.
neuer Marketing-Mitarbeiter mit
technischem Background
Scrum Master aus benachbartem
Dev-Team
praktischerweise ist der seit einiger Zeit auch Key Accounter.
Beginn der Einführung
physisches Board für Impediments
physisches Board für User Stories.
(+ User Stories im Jira)
Nutzen:wir gewöhnen uns an den Workflow.
(noch) keine SP Schätzung.
Switch auf JIRA/Greenhopper nach
2-3 Monaten.
Alles elektronischUser Stories,
Tasks, Mockups, ...
Und alle so:„Yeeeaaahh!“
Unser Team- und Tool-Setup
Team-Setup‣ Product Owner (Björn)
‣ Scrum Master (ext. Team)
‣ Marketing Manager (1 FTE)
‣ Growth Hacker (1 FTE)
‣ Werkstudentin Development
‣ Werkstudentin Marketing
‣ früher: Grafik Freelancerin
Anforderungen an Team Arbeit
Jeder soll möglichst alles
erledigen können.
Cross-Funktionales Team überlegt eigenständig, wie es die Aufgaben am
besten löst.
Es gibt kein „Ich bin nur Marketing“, „Ich bin nur Developer“
Ich prüfe stets, wie ich das Team bei Umsetzung
der User Stories unterstützen kann.
Not easy, eh?
Unser Tool Setup
JIRA, JIRA Agile (Greenhopper)
Im GH: EPICs, User Stories, Tasks
Im GH Scrum Board + RawIdeaBin
(Stories mit Label „rawideabin“)
physisches Impediment Board
Dashboard, großer Monitor für
Marketing KPIs
Team Kalender(Google Calendar)
interne Team-Mailingliste
Retro-Briefkasten
Workflows und Artefakte
Wöchentliche Sprints
Review, PlanningI + II immer
Montags
Review „Script“
Meist 1x/Woche Backlog Grooming
Monatliche Retrospektive, PO
included
Daily Scrum
Definition of Ready + Definition
of Done
Schätzung von PBIs in Story Points
(3 Monate nach Einführung)
User Stories haben Akzeptanzkriterien
(wenn nötig)
Scrum Master blickt mit dem Team täglich auf
das Impediment Board
Beseitigung der Impediments hat höchste Priorität
SP Schätzung nach Effort, keine
Referenz-Story
Beispiele für EPICs
Planning Board
Details User Story
Sprint wird nicht komplett verplant.
Platz für Aufgaben, die nicht in User Stories landen
(zum Beispiel twittern, regelm Tasks etc)
AdHoc Aufgaben werden reingenommen + speziell
markiert(für PostMortem Analyse)
ProblemeHerausforderungen
Der Chef ist der PO.#WTF #FAIL
Lösung: Loslassen, Team befüllt Backlog und priorisiert, PO ist mehr „Gast“ im Planning +
Grooming und bringt Stakes ein.
Daily Scrum: Reporting zum PO
Sprint Planning: Aufgaben fühlen sich wie „angeordnet“ an
Auflösen der Patterns
bewusstes Wegschauen im Daily
ODER BESSER ...
PO nicht mehr aktiv im Daily Scrum dabei
(nur noch selten als Chicken)
Sprint Planning: Team „führt“ mit Maus+Keyboard
Sprint Planning: Team priorisiert Sprint-Planung vor(PO gibt nur noch Hinweise, was ihm noch wichtig ist)
Funktioniert nur dann gut, wenn Stories durch
Grooming gut vorbesprochen wurden!
Herausforderung: zu viel pressende Deadline-Zeit zwischen den Sprints
keine Maydays mehr, Unzufriedenheit, #WTF #FAIL. Wir
führen Maydays wieder ein
Herausforderung: Koordination untereinander
Urlaub, Krankheit, Studentinnen sind nicht immer da
Gut so:das Team merkt selbst, dass
es sich besser und frühzeitiger absprechen muss
What‘s NEXT?Optionen zur
Weiterentwicklung
Reduktion von ScrumBUTT
Stärkere Reservierung von Zeit, die nicht in
PBIs fliesst(tweeten etc)
Nutzung Story Mapping
für Feature Entwicklung bei größeren Projekten wie zB „neue Mayflower Website“
Kanban Board für„Portfolio Management“ und
Projekt Inkubator der einzelnen Marketing-Projekte
Ich lerne noch.Danke für Euer
Feedback.