Das Dokument beschreibt die Implementierung von Scrum im Marketing bei Mayflower, wo Björn Schotte als Geschäftsführer tätig ist. Es wird die Evolution des Scrum-Ansatzes erläutert, angefangen von den anfänglichen Schwierigkeiten bis hin zu einem erfolgreichen, agilen Teamsetup mit regelmäßigen Sprints und klaren Arbeitsabläufen. Zukünftige Entwicklungen umfassen eine stärkere Fokussierung auf Story Mapping und die Anwendung von Kanban für Projektmanagement.

1. Scrum im Marketing
„Scrum beyond IT“ sinnvoll nutzen
Björn Schotte // @BjoernSchotte // bjoern.schotte@mayflower.de
MAYFLOWER GmbH
http://creativecommons.org/licenses/by-sa/3.0/deed.de

2. Ü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 & EBusiness/E-Commerce

3. Agil bei Mayflower:
Scrum + Kanban
(Dev-Teams + Sysadmin)

4. Marketing bei
Mayflower

5. 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.

6. Warum Scrum im
Marketing?

7. Um Vielfalt + Menge an
Aufgaben geordnet und
robust in Teilinkrementen
zu liefern.

8. Bereits mehr als
2.000 User
Stories geliefert.

9. Unsere Scrum
Reise ...

10. Die Anfänge:
2011/2012

11. Unkoordinierte,
spontante Einführung
durch mich.
#WTF #FAIL

12. Kein „Mitnehmen“
der Non-Techies im
Team

13. Scrum Master aus
dem Team.

14. Nutzung JIRA als
Kalender für
wiederkehrende
Aufgaben.

15. Fazit:
wenig erfolgreich und
frustrierend für alle
#WTF #FAIL

16. Reboot.
2012.

17. neuer MarketingMitarbeiter mit
technischem
Background

18. Scrum Master aus
benachbartem
Dev-Team

19. praktischerweise ist
der seit einiger Zeit
auch Key Accounter.

20. Beginn der
Einführung

21. physisches Board
für Impediments

22. physisches Board
für User Stories.
(+ User Stories im Jira)

23. Nutzen:
wir gewöhnen uns
an den Workflow.

24. (noch) keine SP
Schätzung.

25. Switch auf JIRA/
Greenhopper nach
2-3 Monaten.

26. Alles elektronisch
User Stories,
Tasks, Mockups, ...

27. Und alle so:
„Yeeeaaahh!“

28. Unser Team- und
Tool-Setup

29. 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

30. Anforderungen an
Team Arbeit

31. Jeder soll
möglichst alles
erledigen können.

32. Cross-Funktionales Team
überlegt eigenständig,
wie es die Aufgaben am
besten löst.

33. Es gibt kein „Ich bin
nur Marketing“, „Ich
bin nur Developer“

34. Ich prüfe stets, wie ich
das Team bei Umsetzung
der User Stories
unterstützen kann.

35. Not easy, eh?

36. Unser Tool Setup

37. JIRA, JIRA Agile
(Greenhopper)

38. Im GH: EPICs, User
Stories, Tasks

39. Im GH Scrum Board
+ RawIdeaBin
(Stories mit Label „rawideabin“)

40. physisches
Impediment Board

41. Dashboard, großer
Monitor für
Marketing KPIs

42. Team Kalender
(Google Calendar)

43. interne TeamMailingliste

44. Retro-Briefkasten

45. Workflows und
Artefakte

46. Wöchentliche
Sprints

47. Review, Planning
I + II immer
Montags

48. Review „Script“

49. Meist 1x/Woche
Backlog Grooming

50. Monatliche
Retrospektive, PO
included

51. Daily Scrum

52. Definition of
Ready + Definition
of Done

53. Schätzung von PBIs in
Story Points
(3 Monate nach
Einführung)

54. User Stories haben
Akzeptanzkriterien
(wenn nötig)

55. Scrum Master blickt mit
dem Team täglich auf
das Impediment Board

56. Beseitigung der
Impediments hat
höchste Priorität

57. SP Schätzung nach
Effort, keine
Referenz-Story

59. Beispiele für EPICs

60. Planning Board

61. Details User Story

62. Sprint wird nicht
komplett verplant.

63. Platz für Aufgaben,
die nicht in User
Stories landen
(zum Beispiel twittern, regelm Tasks etc)

64. AdHoc Aufgaben werden
reingenommen + speziell
markiert
(für PostMortem Analyse)

65. Probleme
Herausforderungen

66. 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.

67. Daily Scrum:
Reporting zum PO

68. Sprint Planning:
Aufgaben fühlen sich
wie „angeordnet“ an

69. Auflösen der
Patterns

70. bewusstes
Wegschauen im Daily
ODER BESSER ...

71. PO nicht mehr aktiv im
Daily Scrum dabei
(nur noch selten als
Chicken)

72. Sprint Planning:
Team „führt“ mit
Maus+Keyboard

73. Sprint Planning: Team
priorisiert Sprint-Planung vor
(PO gibt nur noch Hinweise,
was ihm noch wichtig ist)

74. Funktioniert nur dann
gut, wenn Stories durch
Grooming gut
vorbesprochen wurden!

75. Herausforderung: zu viel pressende
Deadline-Zeit zwischen den Sprints
keine Maydays mehr,
Unzufriedenheit, #WTF #FAIL. Wir
führen Maydays wieder ein

76. Herausforderung: Koordination
untereinander
Urlaub, Krankheit, Studentinnen
sind nicht immer da

77. Gut so:
das Team merkt selbst, dass
es sich besser und
frühzeitiger absprechen muss

78. What‘s NEXT?
Optionen zur
Weiterentwicklung

79. Reduktion von
ScrumBUTT

80. Stärkere Reservierung
von Zeit, die nicht in
PBIs fliesst
(tweeten etc)

81. Nutzung Story Mapping
für Feature Entwicklung bei
größeren Projekten wie zB
„neue Mayflower Website“

82. Kanban Board für
„Portfolio Management“ und
Projekt Inkubator der
einzelnen Marketing-Projekte

83. Ich lerne noch.
Danke für Euer
Feedback.