scrum im marketing

Scrum im Marketing„Scrum beyond IT“ sinnvoll nutzen

Björn Schotte // @BjoernSchotte // bjoern.schotte@mayflower.deMAYFLOWER 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.