Scrum in Marketingsales

Transkript

1 Scrum in Marketingsales Eine Reise im Themenfeld Scrum beyond Software. Kommst du

2 björn schotte. Geschäftsführer MAYFLOWER CSM + CSPO berate Kunden im Umfeld Management + Technik kümmere mich um Vertrieb + Marketing Scrum bei Mayflower seit Wir lernen immer noch.

3 MAYFLOWER Leidenschaft für Technik Softwareentwicklung Web + Mobile Individuell - am Nutzen des Kunden entlang.

4 Agile bei MAYFLOWER. Scrum in den Entwicklungsteams. Kanban im Admin-Team. Mayday - unsere 14-tägigen R&D Tage.

5 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 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. We hire!

6 Warum Scrum im Marketing? Um die Vielfalt und Menge an Aufgaben geordnet und robust im Rahmen von Teilinkrementen zu liefern. Bereits mehr als User Stories erledigt. Ich bin stolz auf dieses Team. Ein Blick auf unsere Reise...

7 Die Anfänge. 2010/2011 unkoordinierte Spontan-Einführung von Scrum durch mich. #FAIL #WTF kein Mitnehmen der Personen im Team, die non-techies waren. SM aus dem Team. Verwechslung von Jira als Kalender für wiederkehrende Aufgaben wenig erfolgreich und frustrierend für alle

8 Reboot

9 neuer Marketing- Mitarbeiter mit technischem Background

10 Scrum Master nicht aus dem Team selbst.

11 Sondern von einem der Dev- Teams. Praktischerweise ist er seit einiger Zeit auch Technical Key Account Manager.

12 Zu Beginn: physisches Board für Impediments. physisches Board für User Stories. Und US im Jira.

13 Nutzen: wir gewöhnen uns an den Workflow. Das geht mit einem physischen Board besser.

14 Nach 2-3 Monaten: kompletter Switch auf Jira/Greenhopper EPICs - User Stories - Tasks

15 Und alle so: Yeeeaaahhh!

16 Unser Team- und Tool-Setup

17 Team PO (Björn) Scrum Master (ext Team) Marketing Manager (1 FTE) Growth Hacker (1 FTE) Werkstudentin Development Werkstudentin Marketing früher: Grafik Freelancerin

18 Anforderungen an die Teamarbeit: Jeder soll möglichst alles erledigen können. Das cross-funktionale Team überlegt sich eigenständig, wie es am besten die Aufgaben umsetzen kann. Kein Ich mach nur Marketing, Ich mach nur Development. Als KollegIn prüfe ich stets, wie ich das Team bei der Umsetzung der am höchsten im Sprint priorisierten Items unterstützen kann. Not easy, eh?

19 Tools Jira/Greenhopper EPICs, User Stories, Tasks im GH GH Scrum Board + RawIdeaBin (Stories mit Label rawideabin ) physisches Board für Impediments MacMini + Monitor für Scrum Board Team Kalender im Google Kalender + phys. Kalender interne Team-Mailingliste

20 Workflows und Artefakte I Wöchentliche Sprints Review, Planning I+II immer Montags Meist 1x wöchentlich Backlog Grooming Alle 4 Wochen feste Retrospektive zusammen mit dem PO Daily Scrum Definition of Ready Noch keine feste DoD.

21 Workflows und Artefakte II Schätzung von PBIs erst seit kurzem User Stories haben, wenn nötig, Akzeptanzkriterien Täglicher Blick aufs Impediment Board Beseitigung der Impediments hat hohe/höchste Priorität.

22 Story Point Schätzung nach Effort, keine Referenz-Story

23 Was sind bei uns EPICs?

24 Wie sieht das Planning Board aus?

25 Details einer User Story

26 Ein Sprint wird nicht komplett voll verplant

27 Platz für Aufgaben die nicht in User Stories erfasst werden

28 Beispiele: tweeten Facebook Fanpage

29 Oder um mal schnell dem Kollegen aus HR auszuhelfen

30 Dennoch: AdHoc Aufgaben = User Stories mit bestimmter Markierung (CriticalPrio)

31 Herausforderungen

32 Der Chef ist der Product Owner. #fail #WTF (kontrovers: war es nicht Scott Maxwell, Gründer von OpenView, der im Paper zu Scrum bei OpenView Partners als PO legitimiert ist?)

33 Was passiert? Im Daily Scrum unbewusst Reporting zum PO. Sprint Planning fühlt sich wie Die Aufgaben werden angeordnet an.

34 Abhilfe!

35 Im Daily Scrum: Bewusstes Wegschauen und leichtes Zurücktreten aus dem Halbkreis.

36 Im Sprint Planning: Keyboard+Maus wird von einem Team-Mitglied bedient. Team befüllt den kommenden Sprint eigenständig. PO gibt Hinweise und was ihm noch wichtig ist. Aber: funktioniert nur dann gut, wenn die Stories durchs Grooming gut vorbesprochen wurden.

37 Herausforderung: Zu viel pressende Deadline-Zeit in den Sprints (Reduktion von Mayday Zeit. #fail #WTF. Unzufriedenheit. Wir führen die Maydays wieder ein.)

38 Herausforderung: Koordination untereinander. Nicht immer sind alle da, speziell bei den Studentinnen. Aber auch Urlaub, Krankheit.

39 Das ist so. Und gleichzeitig gut so: das Team bemerkt aus sich heraus, dass es sich besser und frühzeitiger koordinieren muss.

40 What s next?

41 Reduktion von Scrumbutt.

42 Weitere Etablierung der SP Schätzung.

43 Noch stärkere Achtsamkeit/ Reservierung von Zeit, die nicht in PBIs fliesst (tweeten etc.), um Luft zum Atmen haben.

44 Retro-Box

45 Start CoP Kundenliebe

46 Ich lerne noch. Euer DANKE!