Agile in Marketing- Making it inclusive

Agile is a methodology which helps a team to work together in sync and achieve a common goal. It enables team to achieve quality output and faster time to market. At Xebia, we encourage its adoption not only in product development teams but across entire organization including IT, Training, HR and Marketing.

Over last few years, I have worked with several project teams and seen the implementation of Scrum framework from close corners. Last year I got chance to work with Marketing team and there also I have seen few Scrum ceremonies being implemented successfully. In this post, I would like to share my experience and throw light on how support teams can successfully implement this methodology in their system.

What motivated us to move to Scrum

Marketing team setup is entirely different from the scrum product development teams- like two ends of a spectrum which are a part of the same system but have very different wavelengths. Marketing Team’s nature of work is very dynamic and they have to flip-flop between tasks frequently and sometimes in a very ad-hoc manner. Most of the team members work independently in silos with each member having ownership of his/ her own task. In order to improve the team collaboration and help each other better, we decided to gravitate towards Scrum. But the first question that came across was:

How we can start using it and will this help marketing?

We have a big team of Agile coaches in Xebia. So we roped them in for their expert advice in implementing Daily scrum ceremony.

First all of us we listed out our goals we wanted to achieve:

  1. Improve productivity
  2. Measure the output
  3. Faster time to market
  4. Improve team communication and collaboration

We prioritized these goals so that we could allocate our time and efforts towards them in a more focused manner. Keeping these goals firmly entrenched in our mind, we moved ahead and prepared our Agile board.

Our Agile Board

Implementation of Scrum was not an easy task in Marketing as compared to scrum product teams.  In product teams you have a defined backlog from where you pick User stories for each sprint on priority basis whereas in marketing you cannot have a defined backlog as many times tasks are allocated on need basis. The challenges confronting us were different. While preparing our board we kept the following points in mind:

  1. Teams could not have a defined backlog as tasks keep on coming on adhoc basis.
  2. Team members’ dependency on stakeholders, SMEs for certain tasks.
  3. Many times, team receives high priority unplanned task.
  4. What should be the Definition of “Done”?

After several rounds of discussion, in true agile flavour, we came up with first version of our board which we sought to refine further in coming months.

  • We kept our sprint cycle short – just for a week because of ad-hoc nature of tasks. The short sprint cycle resulted in shorter feedback loops. So at the end of week we could see the results and also take corrective measures if things were not moving in right direction.
  • We created two boards- (a) Weekly Agile board which had all the tasks that team would be performing in the week. (b) Epic board which showed the bigger picture of our task which were broken down into smaller tasks and moved to our weekly board. Instead of User Stories we call these smaller piece of work as Tasks J.
  • Every week we plan and come up with a backlog based on the task priority. So all tasks, whether it’s a social media campaign / post, articles, Newsletter, or website work will now be driven through backlog. In upcoming months, we are planning to create horizontal swim lanes for different class of work. For example- a lane for social media campaign, another one for Newsletter and so on. This will help us in measuring the cycle time at the end of each sprint.
  • In case of requirement of any unplanned task during the week, its priority will be discussed and decided by our Product Owner. We will have a column for unplanned tasks in order to measure number of planned tasks that were skipped during the week.
  • Definition of “Done” is defined differently for different tasks. In order to accommodate different class of work, we have introduced columns such as Under Review, Waiting for, Blocker, Impediment. This enables us to move tasks to these columns in case the work is assigned or pending from other teams.  For example- if we are trying to develop a case study, then it will undergo several phases such as- requirement gathering, content development, image creation, review, feedback incorporation and final publish. In order to track the task progress better, we move them through columns sequentially- Under Review, Waiting for and finally to Done. But this may not be same for all the tasks. Some may undergo this cycle while others may not and can directly be marked as Done. So, Definition of Done is different for different tasks.

Our Daily Stand-up

Our whole team got familiar with the concept of daily scrum – every morning, we start our day with the daily scrum. Our entire team gathers in a room and all the team members share the task status of yesterday and what he/ she is going to take-up today and also if there are any impediments. We move the sticky notes from one column to another depending upon the current status of the task. As a practice we have each team members name on the sticky notes so that all members are aware of each other’s tasks. Though, initially it was difficult for each one of us to share our work, list down our tasks and be transparent, but soon all of us got accustomed with it.

What we achieved

  • Agile board facilitated visual management and made the communication flow fast.
  • It helped the team in organizing its work in a more coordinated manner which resulted in better collaboration and greater transparency.

Overall, the team is happy and we all noticed some remarkable improvements in the way we work and in terms of our output. It has injected a new sense of enthusiasm in our system and motivated us to improve further, thereby improving our throughput and productivity.


After few months we recognized that instead of Scrum we are actually doing Proto Kanban. We have not implemented an end to end pull system but we are in process where this partial implementation will mature and evolve towards a true Kanban system.

Next steps

In coming months, we are planning to have Retrospective meeting and also think of ways to predict our output.

Stay tuned… in our next post we will share more insights on measurement of our work output and our Kanban journey.

Leave a Reply

Your email address will not be published. Required fields are marked *