Wie kann es gelingen, Agiles Arbeiten auch in Business-Teams wie Marketing und HR zu etablieren? Wie vertikalisieren sich Unternehmen? Wie kann Kanban als Change Management Methodik hier helfen? Und welche Anti-Patterns gibt es im Agilen Marketing/HR?
27. Wertströme in Marke]ng
• Recrui<ng: RecruiFng-AkFonen, Employer-Branding, …
• Kunden: A^ract / Nurture (evtl. auch Close), zB
Konferenz-AuTri^e, Broschüren, Blogbeiträge, …
• Empowerment der Rest-Organisa<on: Interne
DokumentaFon, Kundenteam-Support (zB Slides
aueübschen, Vorlagen erstellen und warten, …)
• Wich<g: Die Wertströme bei dir sehen anders aus als
bei mir oder deinem Sitznachbarn!
28. Bauen wir also das inkrementell-
adapFve MarkeFng-Team.
Unsere Zutaten sind …
29. Zielmanagement
• Beantwortet: „Wo wollen wir eigentlich hin?“
• Global: OKR, Kanban Flight Levels, … Alignment
gegenüber der OrganisaFon
• Alignment im Team: IteraFons-Ziele, zB aus agiler
IteraFonsplanung oder OKR-Teamziele
• (Fast) egal, welches Zielsystem du verwendest: Achte auf
Bo^om-Up-Top-Down-Prinzipien für besseres Alignment
30. Plan zur Zusammenarbeit
• … „Wie wollen wir zusammenarbeiten?“, „Ab wann können wir
Aufgaben bearbeiten?“, „Wann ist eine Aufgabe auch wirklich
ferFg?“
• Working Agreement
• DefiniFon of Ready
• DefiniFon of Done
• Teile davon auch unter Feedback von Stakeholdern erarbeiten
• … moderiertes Ritual, in größeren Abständen reviewen
31. Projekt-Por^olio
• Fluglevel-Sicht: Wo stehen wir mit unseren Projekten/
IniFaFven?
• Projekt-Porlolio-Board: EPICs zB OpFonen für Projekte,
MVPisierung, Projekt Ready, Projekt WIP, Projekt „deployed“,
Projekt in Lernschleife, Done
• IteraFves (Regelmäßiges) Besprechungs-Ritual mit Team,
Projektverantwortlichen, Stakeholdern: Stand & Abgleich
gegenüber Team-/Org-Zielen; ReflekFon aus der Lernschleife
• Kümmern um Impediments, die im Projekt-Team nicht gelöst
werden können (Scrum@Scale EAT-Ansatz)
32. Refinement
• Regelmäßige Vorausplanung von Aufgaben in den einzelnen
Projekten; Sweet spot zwischen Zuviel/Zuwenig :-)
• Alle anwesend, die Wissen haben und die Aufgaben später
realisieren werden/können
• Erzeugen eines gemeinsamen mentalen Modells über die
anstehenden Aufgaben in einem Projekt
• Vorsicht: bei vielen Projekten und/oder großem Team evtl.
auch Bildung von „Subteams“ mit eigenen entkoppelten
Refinement-Ritualen sinnvoll (beachten: Wissensverteilung)
33. Daily / Checkin
• Tägliche KoordinaFon: Wo stehen wir? Was wollen wir
heute erreichen? Was behindert uns?
• Ideal: Mit „walk the board“-Prinzip
• AlternaFv: „Checkin“ / „Daily Huddle“, Gefahr jedoch
von Verwesung im Board (-> Visual Management Prinzip
gefährdet, Dark Ma^er Etablierung)
• Impediments, die nicht im Team gelöst werden können,
in Richtung „Porlolio-Ebene“ spielen und/oder
anderweiFg eskalieren
34. Retrospek]ve / KVP
• Regelmäßig besser werden
• Analog wie in Scrum alle x Tage, oder zB täglich
kleine Verbesserungen besprechen
• Tipp: Moderator nützlich
• Tipp: retromat.org für Ideen zur RetrospekFven-
ModeraFon
35. (Interne) Kundenabfrage
• „Liefern wir das, was du wirklich brauchst?“
• Fit for Purpose oder NPS Score
• QualitaFve Fragen:
• „Wie gut verstehen wir Eure Bedürfnisse?“
• „Wie gut kooperieren wir mit Euch aus Eurer Sicht?“
• „Welche Leistungen braucht Ihr von uns zukünTig?“
• regelmäßig, zB alle 6-8 Wochen
36. Weitere Tipps (I)
• Pair / Mob Doing (re Pair / Mob Programming)
• „Honk der Woche“: Ticketeingang beobachten
• „PO-Rolle“ roFerend verteilen im 2er-Tupel
• Monitoring zB mit Grafana (Website-Aufrufe,
Conversions, Mailinglisten-Subscriber, …)
• Spikes (aus eXtreme Programming), um Wissen zu
erzeugen
37. Weitere Tipps (II)
• Klassifizierung der Arbeitsaufgaben (Bug, Chore,
Spike, User Story, Content, …)
• Wait States sichtbar machen (zB „WaiFng for
Stakeholder“-Spalte) und in RetrospekFven und
Porlolio-MeeFng besprechen
• Fluss-basiertes Prinzip mit Kalender-
Rückwärtsrechnung kombinieren (Abgabetermine!)
• Value Stream Mapping: Visualisierung des Wertstroms
44. Was meint Ver]kalisierung?
• Antwort: „BizDevSecOps“
• Wertströme idenFfizieren und sich danach ausrichten
(KundenorienFerung!)
• „echte“ x-funcFonal Aufstellung: MarkeFng-Leute im
Produktentwicklungs-Team
• Experimente definieren, global betrachten und
auswerten (PDCA-Cycle)
• Team-Strukturen veränderlich gestalten
46. Was kann ich hier tun?
• „Change-Team“ definieren
• Ziele für den Change vornehmen
• Inkrementell-adapFves System für dieses Team bauen
• Regelmäßiger Review
• Change „Porlolio“ Board
• Abgleich mit den Zielen / Kurskorrektur
• RetrospekFve/KVP im Change-Team
• „Inhalieren“ agiler Prinzipien: „Kunden“-Fokus, Reduce Waste, KVP,
gemeinsame Zielerreichung mit den Betroffenen
48. (Re)Ak]onismus
• Symptom
• Keine Übersicht über die laufenden und
abgeschlossenen Projekte
• Keine Verankerung mit den Produkt- oder
Abteilungs-/Unternehmenszielen
50. Marke]ngOps-Abteilung
• Symptom
• MarkeFng agiert als Abteilung wie eine DevOps-
Abteilung, völlig losgelöst von den eigentlichen
(Produkt-)Teams
• Es gibt keinerlei Feedback-Schleifen untereinander
51. Marke]ngOps-Abteilung
• Abhilfe
• Umbau „truly X-funcFonal“: Jedes Produkt-Team bekommt einen
Marketer, Cross-Cuxng-Concerns werden als CoP/Gilde
besprochen
• MarkeFng-Leute besuchen regelmäßig die Teams und verbringen
dort ihre Zeit, nehmen sich Feedback und Backlog-Ideen mit
• Zu den Projekt-Porlolio-Ritualen auch Vertreter aus den
(Produkt-)Teams einladen
• Regelmäßiges Feedback (NPS o.ä.) zur Zusammenarbeit zwischen
Business-Team und Produkt-Teams etablieren und davon lernen
52. Lonesome Marke]ng Heros
• Symptom
• BesFmmte Aufgaben-/Projekt-Typen (zB Design,
Veranstaltung) werden immer von den gleichen
Personen gemacht
• Bei Ausfällen (Urlaub, Krankheit) kommt es zu
Verzögerungen
53. Lonesome Marke]ng Heros
• Abhilfe
• Pair Doings zur Verteilung von Wissen / Auyau von
Skills auch bei anderen Personen im Team
• Regelmäßige Lightning-Talks / Brownbag Sessions
(Wissensverteilung)
• RoFerende Verantwortlichkeiten (zB wöchentlich/
monatlich) zu besFmmten Themen-/Aufgaben-Bereichen
• RoFerende ModeraFon von Ritualen
54. Headless Project Mode
• Symptom
• Es ist unklar, was das Ziel einer IniFaFve / Projekt
ist (zB Konferenz-AuTri^, RecruiFng-Maßnahme,
…)
• Es gibt keinen Sync mit den Bedürfnissen /
Anforderungen aus den (Produkt-Teams)
55. Headless Project Mode
• Abhilfe
• Agile Product Vision zu Beginn eines Projekts/
IniFaFve/… gemeinsam erstellen
• & regelmäßig reviewen / anpassen
• Lern-Schleife nach Ende einer IniFaFve (Inspect &
Adapt, auf Porlolio-Ebene)
56. Silo-Ziele
• Symptom
• Es gibt einen Head of „Abteilung“, der
Zielvorgaben hat, die denen anderer „Abteilungen“
widersprechen
• KommunikaFon zwischen Teams wird über die
Abteilungsleiter geroutet
57. Silo-Ziele
• Abhilfe
• Abschaffen von Individual-Zielen
• Etablierung gemeinsamer Ziel-Systeme (zB OKR
oder andere)
• Direkte KommunikaFon zwischen den Teams
fördern