I have to make a confession: we’re not ready for agile.
I don’t expect anyone to jump up and angrily shout “of course we are! We’re doing agile right now!”, because, frankly, it is not about what we do that I worry.
Analytics loves Agile
When I was a developer, back in the late nineties, hacking away at C code for Palm OS, agile wasn’t mainstream the way it is today. No one in the Palm OS section of our industry talked about it, presumably because that machine had so little memory you couldn’t write anything big anyway.
Anyway, the only exposure I have had to agile was some research on Scrum because we are trying to use the best of it in our projects. Just to warn you that this is not going to go very deep.
What I like most about scrum is how the product owner can pretty frequently make choices about priorities, which in theory means that while they may not get what they originally wanted, they’ll at least get something that fits their needs given the situation.
This is the ideal way to run an analytics project, if you ask me.
First thing is that the requirements are changing all the time, as a principle. What I think I want to track now will highly likely not be the same in a year.
Second is that no one in your company knows what this analytics thing will look like. You have a learning curve ahead of you, and just like learning a new language or getting into a new framework, small steps work best in my experience.
What you want to track in a month or a year depends almost entirely on what you track right now. You learn to make informed choices, backed by a) data (of course!) and b) your experience with something easier you tracked a while ago.
Tracking your first campaign will tell you more about tracking campaigns than any training, consulting or blog ever could.
People love Agile
Let’s imagine we have a small but nimble analytics team. Your friendly marketer worked hard to get these people together, and she finally succeeded.
You have the analytics manager, Susan, a former sales exec. She is really good at managing the connection to all the stakeholders and she also has a knack for finding out what they really need. You have a data scientist, Maria. Maria hates the term “data scientist”. She has an MSc in maths and has worked with data all her life. Statistics are her thing. You also have Janet, who used to be a web analytics consultant. She does a lot of the strategy and also helps IT deploy the constant changes. Finally, you have Tim, your intern. He runs a lot of reports. He can also explain the data in the reports to stakeholders, at least most of it.
In terms of agile, we can clearly see how this team can work together to make absolutely everything possible. Susan plays the role of the product owner, keeping the back log and prioritising based on what she hears from everyone else in the business. Maria, Janet and Tim then build what she needs the way they see fit. Bliss.
But wait, you say, we don’t have such a team!
Truth is: almost no one has.
There are a few lucky people in our industry who can rely on such a group, but the vast majority either soldier along on their own, or they are massively understaffed and drowned with reporting requests. A lot of us do not have star employees like Susan, Maria, Janet, and Tim. We’re all just an average team.
I think that most of the work could still be done in an agile fashion. My guess would be that an average team profits from agile in the same way a star team does.
My problem is: what if your friendly marketer is not up for the product owner role?
And that’s where it all falls over.
If you have no product owner, preferably a really good product owner, you end up doing engineering-driven development, which in our case leads to engineering-driven analytics. I have seen countless times that engineering-driven analytics do not work.
Marketers and other stake holders must have skin in the game, otherwise you’re just a report machine that might as well not even send those reports.
It’s a sad truth. You cannot convince other people to use data that you think they need. Only they know what they need. And they will only ever accept what they want, not what you think they want.
Other People love Agile
If your company works with external consultants, the situation might be a bit less tight (they might do things you don’t have time for), but there will be issues with transparency and billing. The external team might not have access to all stakeholders, and you might not want to waste their time on daily stand-ups.
Those consultants will hopefully know what they’re talking about when it comes to analytics and digital marketing. They will hopefully also be good enough to be able to figure out needs and wants.
But it still won’t work.
I would argue that product owners have to be part of the company. They cannot be outsourced. I would also argue that they have to know what we’re doing, i.e. what this whole digital marketing is all about.
Agile in our line of business doesn’t currently work because we do not have enough maturity and strength to have really good product owners. Simple as that.
What do you think?
5 thoughts on “Agile? Not yet!”
Jan, you make an excellent and interesting point about needing a “product owner” for analytics. You’re spot on that without somebody driving the analytics agenda, it is easy to fall in to engineering-driven analytics. It doesn’t matter whether you’re using Agile or not; analytics programs need to be proactively managed.
But I disagree that we, as an industry, aren’t ready for Agile approaches to analytics program management. I’ve deployed this technique numerous times very successfully. Yes, we need to grow and mature our practice of Agile. But we’re ready for it. It isn’t magic or terribly difficult to do.
We should just focus on just the basics of Agile. Backlog, Active, Complete lists (I like the Kanban-style board for this). Daily stand-up, as short as possible, including everybody who is working on analytics tasks (including a representative from engineering if appropriate). Weekly kickoff and weekly retrospective. All told, you might have 2-4 hours of communication time scheduled. Any more than that and you aren’t Agile anymore… 😉
If you don’t have a large enough team to warrant the daily standup or weekly kickoff and retrospective, then schedule those meetings with yourself. Even if you’re a team of one, I’ve found that the Agile discipline works.
If you do have a team, but it’s too broadly distributed for the meeting cadence to work, then the product owner just schedules that time for phone, IM or email communication to accomplish the same things. Again, it’s the discipline of planning and follow-up and the principle of bite-size work units that matters.
Thanks Aaron, for the input.
My feeling is that in the US, you are probably at a point where POs can be successful, whereas in EMEA, we simply don’t have people with enough experience to fill that role. At least not enough of them.
We envy you guys 🙂
Ah. I hadn’t thought of the EMEA aspect…unfortunately, I think you’re right in that regard.