Agile Marketing Lessons Learned
What happens when you apply engineering team practices to a marketing org — what worked, what didn't, and what we should have done differently.
Background
This talk came from a cross-functional experiment: applying agile practices to a marketing team that had been running on quarterly plans and ad-hoc priorities. We ran it for six months. Here is what we found.
What we adopted
Two-week sprints. Marketing work, like engineering work, benefits from short feedback loops. Campaigns can be run, measured, and adjusted inside two weeks. Quarterly planning obscures whether tactics are actually working.
Sprint reviews. Showing work at a regular cadence forced clarity about what “done” means for marketing deliverables. The first sprint review was uncomfortable — nobody had defined success criteria upfront. That discomfort was useful.
A shared backlog. Moving from individual to-do lists to a shared backlog made prioritization explicit and visible. The first few weeks of grooming sessions surfaced a lot of hidden work and competing priorities that had been resolved informally before.
Retrospectives. This was the highest-value practice. The marketing team had never had a structured retrospective before. Within three sprints, they were identifying and addressing team friction that had been invisible for years.
What we adapted
Story points. We tried story points for the first month and abandoned them. The estimation problem in marketing work is different from engineering work — not because the work is less complex, but because the variability comes from external dependencies (approvals, vendor responses, publishing windows) more than technical complexity. We switched to t-shirt sizing with explicit “blocked by” tracking.
Definition of done. We had to define “done” very differently. For engineering, done usually means deployed and verified. For marketing, done is more layered: content created, approved, scheduled, published, initial data collected. We ended up with a marketing-specific DoD that made handoffs cleaner.
What we should have done differently
Involve the team in the design. We designed the process and then trained the team on it. This was backwards. Teams that design their own processes own them. Teams that have processes implemented for them tolerate them.
Slower ramp. We adopted too many practices at once. Two-week sprints, standups, retrospectives, sprint reviews, and backlog grooming simultaneously was overwhelming. One practice at a time, stabilize, then add the next.
Define success for the experiment. We started without clear success criteria for the experiment itself. This made evaluation murky at the end. Did it work? It depends on how you define work.
The net result
Six months in, the team had significantly better visibility into work-in-progress and was running more intentional experiments. Retrospectives were the highest-value adoption. Sprint structure and shared backlog were medium value. Story points and standups were not worth the overhead in this context.
The lesson: agile practices are tools, not ceremonies. Apply the ones that solve actual problems. Drop the ones that don’t.