Agile Marketing: Scrum, Kanban and Matrix Organization
The Agile philosophy and its Marketing variant foster openness to change by rethinking the way work is organized. Having read the excellent book “Hacking Marketing”, we tried simplifying our work processes to see if we could improve upon Scrum, the methodology we’ve been using for our Marketing projects for the last three years. Here is what we discovered.
Hacking Marketing’s approach is largely based on the following Kanban table:
Migrating to a Matrix Team
We killed two birds with one stone. Formerly, our work was divided among three teams: Design, Integration and Marketing. The three teams were merged into one, the Marketing team.
The classical points-based calculation of Velocity under Scrum was temporarily replaced by the number of hours of availability per week. The “points” system probably works well for dedicated teams that work on one project at a time, but that’s not the way we work. Our teams and our people’s availability are constantly evolving, making the points system poorly suited to our working conditions and out of sync with our circumstances.
Designers, integrators and clients are more frequently in touch under Kanban, where the continuity of the “story” facilitates conversations. Nothing can ever match in-person contact; however, the fact is that some of our work is performed remotely, making it difficult to restrict discussions to face-to-face contact, especially between teams. Using a centralized management software has facilitated communication and allowed us to document previous conversations about a project. It has made it easier for designers and integrators to exchange information, since supporting documentation is attached to the story map.
“Get Sh*t Done”
Kanban has sped up delivery. Before Kanban, delivery time was at least one month, due to the “design sprint” and the “integration sprint”. But one month is far too long in the Marketing world. Under Kanban, or rather when using Kanban as directed by Hacking Marketing, delivery can be sped up to just a few days, even though the story goes through several “review” stages. Reducing sprints to less than two weeks has turned our lives into one continuous meeting.
Cost of Matrix Organization
Matrix organization is often dismissed as being “expensive”. Our experience confirms what the Harvard Business Review observed in its article: we are wasting less time searching for Permit A38. In our case, we’ve been able to trim back the time spent on project management by 30%.
We used to use Jira for our Scrum projects, since the tool is specifically designed for Scrum. When we switched to Kanban, Jira was less than ideal, since we were increasingly feeling limited on the User Experience side of things. This was probably the main problem we had to overcome.
There are (many) other software options that are better suited to Kanban: Trello, Wekan, Restya, Leankit, etc.
|Ease of calculation of velocity through team points.||Better workflow: easier to perform tasks quickly.|
|Well suited to a high number of participants/high participation.||Better suited to variable-availability situations.|
|Simplifies/eases communication in matrix teams.|
|Enhanced production continuity.|
|Rigidity of Scrum concepts, sometimes incompatible with the flexibility touted by the Agile philosophy.||Points-based velocity harder to control.|
|In non-matrix environments, communication between teams is more complex.||In our case, Jira’s rigidity was an issue.|
Things that may make our situation different from yours:
- The total number of players in any given project is high, but actual time spent on the project by each player varies wildly;
- For part of our team, marketing projects take a back seat to other client projects;
- Our company mostly works in Scrum mode;
- Jira is used by the entire company in every aspect of its work;
- We simultaneously changed our team structure, from a divided team to a matrix team;
- Tasks to be performed are varied: integration, newsletters, design…