Chasing Agile: Deviniti Marketing’s Story of Grit, Grace, and Second Chances
This is an excerpt from a speech I delivered at the Jira Day 2022 conference in Warsaw, Poland.
---
I’d like to tell you a story of the team I helped build and still belong to.
Its title refers to a book by former NFL player Leland Melvin, who became a NASA astronaut despite his injury during his football career. I found it not just another reference to space, which is how we think about Deviniti as a company.
Here's an excerpt from a review by Neil deGrasse Tyson that’s relatable to everyone who has ever gone through an Agile transformation:
Agile marketing at Deviniti: business context
When I joined Deviniti 6,5 years ago (which was called InTENSO back then), there wasn’t such a thing as a marketing department. I was one of 2 or 3 people doing marketing-related jobs at a company that had already been on the market for 13 years and had 150 or so employees.
Within 2 years, a couple of separate teams emerged around the company, each doing its own thing. One day, we all sat in a meeting and decided to join forces to take care of the whole company.
Shortly after, we realized we were a bit in trouble. In fact, we brought to life an in-house agency.
6 different business units across the company became our internal customers. Supporting the C-suite and HR, as well as internal and all-hands projects, were a nice addition to our workload. We were a fresh-baked team of 10, merging from different parts of the company, so we had just a little idea of what was going on.
At the moment, Deviniti already had around 200 employees. Each business line was doing something different, supporting our customers’ digital transformation in unique ways.
(That’s why we came up with the space-themed brand design in the first place, by the way. We felt there was simply no better way to visualize everything we do.)
On top of this, things were changing rapidly. The company was experimenting a lot in its growth phase, so we started and ended new partnerships, delivered PoCs of new products, and made a lot of custom development for our clients.
We asked ourselves: what are the chances that we won’t be buried under all this work to do? And that's how Deviniti Marketing's Agile journey started.
Chapter 1: Liftoff
We asked our Atlassian Services team for help. We wanted to implement a simple process that allowed us to break the incoming stream of work down into smaller pieces and release deliverables quickly. We also needed an integrated space for our ongoing tasks, the long-term backlog, the products of our work, and reports from our analytic tools.
The first thing we created was the marketing service catalog. It turned out pretty big, so we divided it into multiple categories in Jira Service Management. We wanted it to be branded as well, so we added a Customer Portal theme powered by our own Theme Extension app. On the back end, we had multiple queues for tracking the incoming requests.
The core of our work environment was the dedicated project in our company’s Jira Software. It had a super simple workflow with one acceptance stage and two identical boards with different sets of quick filters - one per assignee and the other per stakeholder, which we stored in a custom field attached to every issue. We modified the board filter to include the requests from our Service Desk so we didn’t have to sync or move issues.
The other part was the Confluence space which we made public. It wasn’t just a knowledge base but also the home base of all our ongoing work. We were drafting blog articles, writing down meeting notes and internal manuals, storing collaterals and templates available for download, and uploading campaign reports. When we needed to share something outside Deviniti (like sending out a press release or reviewing a case study with a customer), we moved it to Google Drive and used an integration app to embed it back on a Confluence page and thus keep it searchable.
And of course, we set up a sprint reporting dashboard in Jira. Just a couple of gadgets that could show our burndown and break down the tasks in customers and statuses. A click on each number opened a filtered list of tasks so our stakeholders could easily check what was going on in “their” part.
Every two weeks we had a big planning meeting with all our stakeholders. We discussed the sprint results and reviewed the Service Desk queues to sort out the new requests and get more detailed briefs. Then we came back to our team and groomed the backlog, set priorities and due dates, and prepared for the new sprint.
This workflow was pretty simple and easy to use, so we could get to work really quickly. And it was good enough to plan and deliver for quite some time. But there were as many cons as there were pros.
- Sprint completion rate and burndown were the only efficiency metrics available. That's far from ideal, as they are easy to manipulate and don't reflect the value of the work done.
- Due to the 'planning by committee' process, we had almost no control of the incoming work stream. Only 30% of our tasks were commissioned by the Marketing team. We actually became a bottleneck as the number of incoming requests increased over time.
- A 2-week planning horizon is a myopic vision in itself. It disabled any 'project' or 'strategy' perspective on things, so we had to focus on a campaign-based approach.
- Our scopes and timelines didn't take external contributions into account, such as SME input or review. We often had to wait for those to happen, so our tasks were moving in and out of sprints like crazy.
Chapter 2: Waterfalling the Agile
Our next question was: how can we adapt this quick delivery to stretch the campaign-based model?
At this point, we had some knowledge about our business portfolio and tested a thing or two about reaching our target customers. In many cases, we could propose a broader strategy and stick to it for a longer timeframe to see how it impacts the business.
We came up with a hybrid approach and introduced marketing projects. The goal was to build content 'funnels' that work all the time and not just for a couple of months. We wanted to plan the work by ourselves and align our action plans with the company’s business goals. We needed to be more precise with our estimations, control the marketing budget, and clearly see the outcomes of our efforts to be able to optimize.
The issue is that most marketing projects are strictly sequential. We can’t move the stages sideways and expect the same result, as they are highly dependent on each other’s outcomes. But if we start small and build up gradually while learning lessons along the way, this cycle becomes an Agile loop that takes a good couple of months to circle back.
Of course, this is a simplified model - in reality, there are multiple loops like this going on at the same time inside different Scrum teams of our Marketing department.
The hybrid approach gave us a much longer time perspective than just a 2-week sprint with an endless backlog. We knew exactly what we’d be doing in the next 6 months or so, excluding some unexpected turns and twists that always happen in our job. We stopped taking on projects that didn’t fit the already planned schedule. However, we did quarterly checks with each stakeholder on their business priorities and possible level of engagement in collaboration so that everyone knew what to expect.
We took what's best from both worlds - waterfall and agile - and made them work together:
- strategic approach + focus on delivery
- yearly goals and quarterly planning cadence + breaking down into 2-week sprints
- sequences with dependencies + iterative growth and continuous improvement
- the team knows where we're heading + is motivated to deliver
Futureproofing: what's next?
But of course, this posed the next challenge right on our heads.
We became a team of 20, and the project documentation appeared to be everywhere across Confluence and Google Sheets. We had to update all the plans and roadmaps manually, which took a whole lot of time. We also had to create Jira issues manually during sprint planning, which could easily be a more productive time at work.
Also, we’ve changed our processes but not the tools’ configuration. The way our Jira project was built didn’t suit our operations anymore, let alone the stakeholder requirements. We needed a more refined workflow and issue structure, as well as a couple of new features to make our work easier and more transparent.
It's fascinating how neverending this story is. Each time we make improvements, we see room for more.
But that’s basically what Agile is all about, isn’t it?
---
Read on to see how we implemented agile marketing project portfolio management in Jira Software.
Have a similar story or challenge? Share your experience in the thread, or find me on LinkedIn to connect.
Was this helpful?
Thanks!
Dzmitry Hryb _Deviniti_
About this author
Marketing Manager
Deviniti
Wrocław, Poland
3 accepted answers
2 comments