We adopted SCRUM in our marketing team and here is why it works for us
answer: deviate from the theory to reflect context
In winter, we started adopting SCRUM accross all teams at Bondora, including marketing, the team I currently lead. I cannot say it was easy, but we started with implementing SCRUM “by the book” and then adopted the process to fit our needs.
Six months later, I need to admit that commiting to SCRUM was a right choice and I believe it allows us to achieve more than we’d achieve otherwise. This blog post is not about SCRUM theory, this blog post is about the changes or deviations from the theory that we made to make SCRUM work for us, and I hope this will help other companies.
Bondora is one of the leading European peer lending platforms, connecting private and institutional investors with creditworthy borrowers. We issue loans in four European markets, Estonia, Finland, Spain and Slovakia, and have active investors from over 30 countries.
The 38 members of the stuff are ogranized into three teams: 1) engineering, 2) loan scoring and administration and 3) marketing and we all are based in a single location in Tallinn, Estonia.
The company started adopting SCRUM across all three functions in late February of this year and I took over the leadership, or in SCRUM terms Product Ownership (PO), of the marketing team of 8 people on April 1, 2014.
Last important aspect not miss: we’re a technology startup, so we are required to achieve constant and rapid growth and we operate in a newly forming industry that involves high levels of uncertainty.
Our sprints start on Mondays end end on Fridays. Other teams within the company adopted different schedules, but for the marketing team we decided to close our sprints on Friday, so the team members can leave for the weekend without thinking about the tasks they were assigned to.
We found that having the sprints end on Friday really helps to get proper rest during the weekends and start new sprints with full energy. No thinking about the current tasks (the sprint has ended), no thinking about the upcoming tasks (new sprint wasn’t planned yet), just rest.
The marketing team is responsible for achieving quarterly targets, that are developed before the start of the quarter by the management and the Board of the company.
On monthly basis, during the last sprint of the month, we gather for a 2–3 hour session to brainstorm, prioritize and agree on the monthly goals that we will be working in the upcoming month and that will help us achive our quarterly goal.
Everyone on the marketing team participates in the brainstorming part of the session, but the Product Owner and the Scrum Master are excluded from voting on the priority of the goals. At the end of the session, 4–5 monthly goals are agreed upon based on the priority voting.
We didn’t introduce monthly planning sessions from the start, but I find that those planning sessions are probably the most important component that make SCRUM work for us! Our sprints are extremely intense (we’re a startup), so without clear goals that everyone committed to, it was really hard to see a bigger picture and stay focused.
Our weekly planning sessions consist of two parts: 1) brainstorming on the things to do, and 2) task prioritization and allocation. Each session takes about an hour. We tried to make them shorter, but it didn’t really work.
We took a slight deviation from the SCRUM theory: the theory suggests that the team members are not allowed to add tasks to the Development Log, and instead, add tasks to the Incidents log. Then it is up to the Product Owner, to decide, which items from the Incidents log make it to the Development.
Instead, we spend the first hour of the weekly planning session brainstorming together on the tasks that are worth including in the Development Log and will help us achieve our monthly goals. In the second hour of the sessions, the team votes on the priorities (again, no votes for the PO or the Scrum Master) and we allocate the tasks that scored high on the priority to individual team members.
That slight deviation, which we didn’t have from the start, was another critical point for making SCRUM work for us. Putting a task into Incidents log is easy, suggesting and deffending a task in front of the whole team is way harder. So only the tasks that someone on the team truly believes in (and will later lead the execution of) make it to the Development Log.
Weekly review and retro
We run weekly sprint review and retro on Friday afternoons, to understand which of the tasks where completed during the sprint, review the probles that we came accross during task completion and to discuss what we need to improve in the upcoming sprint.
We used to spend over an hour on sprint reviews, and the remaining time (we had a cap of two hours) on the retro. However, since introducing monthly planning and adjusting the weekly planning sessions, the sprint review time reduced to less than an hour and we have more time for giving feedback and discussing areas for improvement.
Perhaps, it’s a learning curve, but I believe that having a clear goal in mind (that comes from monthly planning sessions) and having someone on the team standing up for each task in the sprint (that comes from how we how we plan our sprints) really helps us complete most of the goals in each and single sprint, so there is nothing much to review on Fridays.
I don’t participate in team’s daily stand-ups that are run by the Scrum Master. This was a deliberate decision, as we wanted to dedicate stand-up meetings into active discussion between the team members on their tasks, rather than have mini-reviews with people reporting to me on the progress.
Instead, I participate in the daily stand-up meetings of Product Owners, three POs and the CEO, to update the rest of the management team on what we achieved on the previous day, and what we plan to achieve today. The Product Owner stand-ups is also a place where we discuss on how to achieve the goals that require collaboration between the teams.
As mentioned before, on Fridays we discuss the things we can improve and that includes the things we can improve about the SCRUM application in our context. Here are some of the things that we would like to improve:
- Capacity estimation: we don’t score tasks on their complexity and rely on the gut feeling and past experience when defining how many tasks make it into sprint. How do we determine if we operate at our maximum capacity each and single sprint?
- Routine tasks: some of the tasks need to be done regularly, such as reporting. They usually don’t fit any of the monthly goals and yet need to be done. How shall we make sure that such tasks make it into the development log and don’t hinder reaching monthly goals?
- Trainings: some of the trainings are obvious (i.e. “we need to learn this to achieve out monthly target”), but some training involve longer-term perspective (not even quartertly), so the question is how to fit them into sprints.
Hope this helps and feel free to ping me on Twitter (@jevgenijs) if you have any questions.
I can also read more about adopting SCRUM in marketing on OpenView Partners blog: “What Happens When a Marketing Department Adopts Scrum” (which was the initial inspiration for this blog post).