Audrey Pedro
Transcript (Translated)
Hello everyone, thank you for being here to listen to my presentation on agility in a marketing department.
I’ve attended quite a few presentations since this morning. It’s true that agility is something that comes up a lot in the IT world. So, the consulting firm where I implemented JIT in marketing is a company that does software development, but we focused on applying it to a department that manages events, the publication of various white papers, etc., which handles marketing communications, press relations, etc.
First of all, the screen is huge, so it makes for a very, very large photo of me. Audrey Pedro, I am a Product Owner, Product Manager at Tiga today. I have an engineering background and quickly moved into the Product Ownership field.
And I’ll explain this again later, but I was led to become the marketing manager at Xebia. And so, to deploy a bit of the entire digital marketing strategy for a consulting firm.
So, a quick word about Tiga. Tiga is a company that specializes in product ownership, product management, and product coaching. So, it revisits some of the themes that were discussed this morning, for example, during the Outcomes over Outputs session. The idea is really to build the right product in an agile and relevant way.
Tiga is part of the Xebia alliance. This will help connect the dots as to why Xebia’s marketing exists. So, the Xebia alliance is actually an alliance of several companies with a common DNA, namely excellence. So, in different fields, Xebia, Software Development done Right. Xebians are passionate developers. Their mission is to create applications of exceptional quality. Xebia Labs, which offers the Diploïd tool. So, oh, sorry, a small microphone issue. I’ll avoid moving my arms.
UX Republic, which offers user experience, and Tiga for product management.
So, let’s get to the topic of this afternoon. Once upon a time, there was a marketing department in a consulting firm called Xebia. Which was quite rudimentary. Xebia has existed in France since 2004, and the marketing department was created in 2012 with the goal of improving the company’s institutional communication since it had significant viral marketing but little presence in the press, at major events, etc.
So, in January 2012, one person took over the department and realized after a few months that, in the end, they didn’t really know what they wanted to do but had still launched a number of projects. At that point, I was offered the position part-time, in addition to the product ownership role I had at the time at SFR. So, I arrived, and we had started to build things, but we had somewhat left things as they were. That is, there were 4 or 5 large-scale projects, including the complete overhaul of the company’s visual identity, the website redesign, content, offers, etc. Or even the Tech Trends. Tech Trends is a magazine about upcoming technological and agile trends. There was an Agility Tech Trends that came out around the time of Scrum Day last year. The idea is for Xebians to take a stance on what they believe will be the future of agility, big data, cloud, etc. The company’s various areas of expertise. So, all these projects were started in parallel, but that’s about as far as they got.
Once I arrived, I had a part-time role to advance these topics, and we clearly questioned whether to maintain this marketing and communications department due to the limited results it had produced in a year.
So, a small action plan regarding this. We need to combine marketing, communications, and why not agility. I am a product owner by trade, and I’m still on a mission for SFR, and I thought, in the end, okay, a feature isn’t an event, but why not leverage agile principles to deliver marketing outputs? So, to revisit some agile principles, it’s about saying we want to bring the most marketing value to the company—how do we do that very quickly? How do we continuously improve our processes and be responsive? Because it’s true that if a consultant has a great idea for an article, a small event, etc., and they know it will take a year before marketing has the capacity to support them in their event, they’ll think, 'Okay, I’m less inclined to contribute.' But if they see that the department can be responsive and act quickly with them,
it will create momentum within the company and also allow marketing to rely much more on all the consultants.
So, there you have it—I revisited the three agile principles that seemed most important to me when I started asking questions about this marketing department. So, satisfying the client by delivering features quickly will mean producing deliverables quickly that provide high added value for sales teams with clients and for recruitment with candidates.
Changing needs—yes, it’s possible that sales teams may no longer want the event to be specifically for decision-makers but instead a more open event. It’s possible that a new method came out last week, and we had prepared everything around SAFe, but now there’s a new framework. We need to be responsive. And finally, the team—initially just me, but it’s already a start—thinks about how to improve the way we work to be even more effective. So, once I had... a bit extracted the principles that seemed, in quotes, applicable to marketing. The second step was to try to implement them. So, we had a set of existing projects, all already in progress.
The first thing was to clear the table of all that and say, 'Okay, I want to create a prioritized marketing project backlog.' The most complicated part was prioritizing.
We gathered around the table with all the stakeholders at Xebia—the president, the operations director, the head of coaches, the cloud offer lead, etc. In short, all the people who had expectations for this department. And we said, 'Okay, let’s prioritize, let’s really try to say this project is the most important, etc.' So, we ended up with... A prioritized backlog in the making. We stopped there because after two hours, we couldn’t prioritize anymore, and everyone had a headache. In reality, there were still plenty of actions left, but as we know in Kanban, we don’t need an infinite backlog—what matters is having enough to move forward. So, the most important thing was, of course, the website redesign and the company’s visual identity. Which had been started. And then there were smaller actions that moved up in priority. We had the score. Scrum Day—I’ll come back to that later. It’s true that the priority of an event is also a matter of timing. Scrum Day is in April. Well, it’s not a question of it being a priority over offers, but it’s also that we have a deadline that can’t be moved. After all, reducing time to market doesn’t necessarily make sense. On the other hand, if we’re ready three weeks after Scrum Day, we’ve somewhat missed the project’s goal. I’ll come back a bit to this notion of fixed dates vs. cycle time and that sort of thing. The first point helps to situate Xebia for those who don’t know it.
It was to launch a website, since Xebia’s website was 4-5 years old at the time. And you should know that 4-5 years in the digital world is a very long time. As a result, the site no longer necessarily reflected the company’s image. And it hadn’t been changed in a long time. For example, it was changed again at the start of the school year, a year and a half later, which is a more typical cycle. So, this first project was an opportunity to put into practice the very familiar aspects of agility that I knew, namely managing software development, since there were two developers working on the site and myself in the role of Product Owner, as well as a designer.
So, we made progress on this first project. It was a good introduction. So, it’s true that for a marketing department, if POs have the opportunity, or developers have the opportunity to work to help the team, tying into IT projects is something that also demonstrates all the benefits of the method, since we ultimately launched this site in a month and a half, whereas they had been trying to move the project forward for over a year.
So, once you’ve succeeded with a first thing, expectations generally increase, which is quite normal. And you have to start asking yourself how to improve and see how the department can evolve. So, not stopping at this first victory and not resting on your laurels.
So, gently, there was a... So the website is done. I could have put it there, by the way.
I was a bit pessimistic by forgetting the work accomplished. So we had a number of topics to address. It was mid-February 2013, with the Scrum Day approaching. And so, I had a part-time position.
And since I'm not Superman, unfortunately, we decided to hire people to strengthen the marketing department, so that we could... address a bit all these projects we had identified together. So, two people arrive, and I switch to full-time, we are three. And then we say, yippee, we're going to do everything at the same time. That way, we'll move fast.
So, of course, for all those who know the precepts of Kanban well, that doesn't work. When you start doing everything at the same time, you get a bit scattered. And so, as has been repeated often today, you need to limit the work in progress. But at the time, I wasn't a Kanban expert at all, and I still am not, but I've learned a little along the way. And so, that was kind of the first time I thought, OK, limiting WIP makes sense.
Let's go back and take it topic by topic. Given that we were three, then we were four, then five, then six,
we put in place a fairly simple system to limit the work in progress. It was just a system of sticky dots per person. And there was no more than one sticky dot of each color in the WIP. That is, each team member couldn't work on more than one task at a time.
I know there are plenty of ways to calculate WIP limits. Since I'm not an expert, I preferred to stick to the simple method. And it worked very well. Today, I believe it still works that way in the department. So there you go.
Now, the other issue that ended up causing problems—so we were limiting the WIP, everything was going well. However, people started to see that the marketing department existed and that it was producing things. So, everyone started having lots of great ideas. Which is very positive since the company provided us with phenomenal material to market the brand. The problem is that when a first person comes to you saying, 'This needs to be done for tomorrow, and that should have been done for yesterday, and that should have been done for the day before yesterday,' well, we start to panic a bit and think, 'OK, we still have WIP limits, how do we handle this?' And so,
we implement snow lines. So, the second learning by experience of how things can improve. We created a fast lane. Later, we created different priority levels. For the fast lane, we had one spot. Everyone came to us saying, 'This is the most critical thing.' We sit around the table and think. There is one spot to add something express now that was needed for the day before yesterday.
So, these were the first learnings of the team. And it allowed us to enter a slightly calmer cycle, where we were less in a state of permanent urgency.
But we still asked ourselves how we could improve. And so, as Renaud would say, to improve, you have to measure. Measure the current state to know where to go and what needs to be improved.
So, we implemented KPIs. So, does anyone have ideas for KPIs to track an event project, for example? Press now, which is for the day before yesterday.
So, it was a bit of the team's first learnings. And that allowed us to enter a slightly calmer cycle, where we were less in a state of permanent urgency.
But we were still asking ourselves how we could improve. And so, as Renaud would say, to improve, you have to measure.
Measure the current state to know where to go and what needs to be improved. So, we implemented KPIs. So, does anyone have ideas for KPIs to track an event project, for example?
The number of participants, exactly. The number of participants.
The quality of the addresses, that kind of thing. So there’s the number of participants, the rate of our shows. For example, for an event we organize ourselves, it’s something we track very closely, because for free events, it’s easy to sign up. However, to attend, you still need the motivation to go. The email addresses collected, the quality of the email addresses too—personal addresses, professional addresses, etc.
For the publication of a Tech Trends, it will be the number of clicks on download. It could be a bit more qualitative tracking, but tracking on Twitter regarding an event—what were the positive and negative mentions of our event, who mentioned the event.
That kind of thing. So we started listing a few indicators that would allow us to track the different projects.
And we also implemented systematic retrospectives for each of the projects. For example, we organize an event or for the Tech Trends, we release the Agile Tech Trends, all the authors who contributed.
Come to the office, and we’ll spend two hours saying, OK, what worked well, what worked less well?
For the Agile Tech Trends retrospective, it’s easy. We had plenty of coaches to facilitate the retrospective. So we did retrospectives in various formats. And the idea is precisely to take these improvement actions seen from the people who worked with us to try to be... better. So, some actions worked, others less so. In any case, we were always asking ourselves how to do better.
Up to this point, nothing exceptionally new.
It’s Kanban, agility, applied to a slightly different context. So, I wanted to focus a bit on what changes when dealing with marketing projects versus a digital product. What are the real points of attention if you want to change a marketing department?
I listed what impacted me the most from my experience. I think there are many other points that could be highlighted, and it clearly depends on the companies and the experience of the person implementing it.
When we talk about software, we often talk about a product. We need to release a product that addresses a user problem. When we talk about the marketing of a consulting firm, we’re talking about a brand. We want to ensure that the brand of our company has a good image, that events and publications are of high quality. So we try to explain to clients that we can address a problem.
So, another very important point that I will really focus on... Focus on because I know there are debates about whether you can always prioritize. Sometimes in marketing, you can’t. There are two events on the same day or at least the same week. You have to be at both events because it’s the core business of the company. You can’t prioritize. What do you do?
The dependency-adherence aspect is true in development teams. For example, as a product owner in companies today, in a team that only does back-end, we have a lot of adherence with the front-end team.
In a marketing team, we have dependencies in the sense that content is written by people who are not on the team. The content is provided by external people. So it’s really a very strong dependency, in the sense that the marketing department doesn’t function without these people.
And finally, there are parts of the process that are not agile at all. In software development, this can also be true—having testers who are a bit reluctant, a very cyclical job, etc. But we know, we’ve seen in some companies, it’s possible to make the entire chain agile. At Spotify, etc. We manage to do DevOps, as we saw earlier at Les Furets, they do continuous delivery, etc. It’s possible.
In a marketing department, when working with a printer, the printer turns on their machine for 500 prints. They don’t turn on their machine for two prints and ask you, 'Is this OK for you?' And then, we do loops. Once it’s gone to the printer, 500 copies will come out, whether it was good or not. So there are entire parts of the process that cannot be made agile. And so the question is, in that case, what do I do?
So, first of all, Product vs. Marketing. I took an example that has nothing to do with software development, precisely to highlight the difference between the two topics. A product, for example, deodorant—what makes it solve your problem? The deodorant will allow you to not smell bad, to feel comfortable, to feel good when you give a talk in front of 50 people. And so, you’ll buy it again because it solved your problem. After that, do you take this brand or another brand? It will rather be about emotion, about mood potentially as well. But in any case, you know that there are several brands that can solve this same problem.
Similarly, Apple—I have a Mac because I know I need a computer to work. After that, why do I choose Apple? Because I have a connection to the brand, which is that I consider their products easy to use, that I won’t get too many viruses, etc. I could have taken a PC. So the difference between the problem to solve and the fact that we are... and several companies to solve the same problem.
After all, Xebia has a number of competitors in the market. And the idea is to explain to clients that we are the best at solving these problems, even if we’re not the only ones who can solve them.
So the topic of Release vs. Events, which also ties into Product vs... vs. Marketing, in fact, I wanted to focus on a specific point. So, a release. So I took the agilists' triangle directly; I didn’t take the fool’s triangle. Quality is not negotiable, but you can play with scope, costs, or deadlines.
When we talk about an event, the deadline is not negotiable. After that, it depends—you might have a lot of influence, but personally, I’d have a hard time explaining to Devoxx that this year, it would be good to postpone it by two weeks because I have other projects to manage and it would be more convenient. So the deadline is not negotiable, but you can manage cost, content, facilitation—though in reality, I think it’s more than a triangle; there are many things that come into play—but it’s a fundamental difference. In the sense that if you’re not ready, the event still takes place.
If we haven’t thought about that date, we’ve failed—we can outright consider the event a failure. So the main indicator for an event is really this notion of time. And we’ll rather think in terms of a reverse schedule. After that, since we’ll have, for example, several events, we’ll need to manage multitasking, but we’ll come back to that later. We’ll rather think in terms of a reverse schedule than really saying, 'I’m starting today, and the idea is that I’m done tomorrow or the day after, in any case as soon as possible.' We’re not looking for this notion of reduced time between the start and end of a project.
So, a concrete example. In April 2014, at Les Grandes Joies, three events the same week. Otherwise, it’s too simple. Devoxx, a major Parisian Java conference. Java is the core business of Xebia. Scrum Day, the major Parisian agile conference. Agility is part of Xebia's DNA. And French Tech Safari, well, that might seem a bit more exotic, French Tech organized a safari where the idea was to offer people who had participated in a start-up challenge the chance to meet companies that could technically help them develop their products. So we were contacted by French Tech so that Xebia could be among those companies that could potentially help people bootstrap their projects, launch an MVP, etc.
So the first question is, do we do all three? A legitimate question. When thinking about prioritization, we should say no, we choose one and do it well, rather than doing all three haphazardly. The problem is that, while we could have skipped the French Tech Safari, That’s debatable. But Voxxed and Scrum Day, that was... Like saying, I’m cutting off one of my two legs. They’re both pillars of Xebia, and we couldn’t afford not to be present.
So after the long discussions about... Between coaches and developers arguing, 'No, no, my event is the most important, no, mine is!' And we end up with, 'Okay, both are important.' What do we do?
What do we do? Well, either we take the whole team—at the time, there were four of us—and work a bit on both topics. Or, option two, which we chose, we dedicate a leader for each of the two projects, who is responsible for moving things forward. And the others still keep an eye on things but remain focused on their own project. This creates silos because, as a result, two of us were working on DevOps, two on Scrum Day, and in the end, we no longer really felt like a team. But this ties into a principle I’m currently experiencing again on a mission, where I have the same team working on two products, It doesn’t work. It’s better to split the team for the time needed to complete the project than to try to do everything at once.
So we can refer to agile best practices on topics like managing two events in parallel.
The issue of dependencies.
So, as I was telling you, 80% of the content
used in a marketing department isn’t produced by us. Because we don’t have the expertise to know all of Xebia’s business, since technically, these are quite complex fields that require deep understanding. We have a surface-level understanding that allows us to grasp what the consultants are talking about, but I wouldn’t be able to go into the details of the Big Data offering today and explain why Hadoop is better than Couchbase or MongoDB.
From there, we need to involve those people who, in addition to their real jobs, are on assignments so they can produce the content needed to market the Xebia brand.
At first glance, this was really the hardest part from my point of view.
Because when these people help you, they do so between two committees during their assignment. So we need to find a way to involve them. And so the solution is precisely strong involvement of people in the team so that, in the end, they become part of an extended team. In the same way that when you want to do DevOps, you need to ensure that developers... and ops feel like they’re part of the same team and actually are part of the same team, you need to make your contributing consultants feel like they’re part of the marketing team. And a sign of success in this regard is that when I left Xebia’s marketing department, one of the consultants told me, 'Oh, you’re leaving the team.' So, he wasn’t physically with us, but he really felt like an integral part of the team. In order to transform strong dependencies into adherence, since we can’t completely eliminate them. For example, we regularly need creative work. So there’s a person who does creative work and is here two days a week.
We need printers, etc. So, we have dependencies with people outside the team, but we’re no longer completely blocked. And in fact, that’s the biggest risk for a marketing department in a company like Xebia: ending up with no content. A well-oiled machine, but nothing to produce. At least no relevant content. And that can really cause your projects to fail.
And finally, the issue of the V-cycle in certain parts of the process. I used the printer image for book printing because it was the first issue I really faced. We released the Tech Trends Agile for Scrum Day. And when you publish a book, you obviously need to write the content.
You need to format it and then have it printed.
And that’s what they explain to you.
We do a content writing phase. Then, we do a formatting phase with a creative studio and a printing phase. So we end up with a nice V-cycle. At the same time,
It’s normal, I don’t know any printer willing to start up machines that cost an arm and a leg, etc. For five copies. It’s the very model of Taylorism and all that is industry. It’s about saying that these are machines that cost a fortune, which are amortized over years and years. These aren’t changing environments. So agility doesn’t make sense there.
It’s just an aberration. They tell us, 'Yes, but I want to see first.' Well, no, you provide something, and then you’ll see what it looks like.
But that doesn’t require doing all of this part. In a V-cycle.
And the takeaway from my experience is really to limit these V-cycle segments to the part that is truly mandatory due to industry, your supplier, etc. And in fact, what we did was make this part iterative. We wrote the content, formatted it, revised the content, reformatted it. For the illustrations, same thing, we really created a huge feedback loop here. We had it proofread by recruitment, by consultants, etc. So that here, in the end,
we’re no longer afraid of the small V-cycle. At least, less afraid. I’m still very afraid when I see something to print, despite the risks we reduce. It’s always the moment when you think, 'Oh no, I left a spelling mistake, I’m doomed.' But in any case, we really gathered as much feedback as possible here. And we limited this area. So all this to say that it’s not inevitable. Yes, there are things that aren’t agile. And at some point, you have to accept that and not try to force things. However, that doesn’t mean you should give up on the rest.
So today, continuous improvement is underway. At least, I hope so. Now, I’ve been gone for a few months. I still see the exchanges on Twitter, etc.
The department is responsive in the sense that when a request comes from a consultant, the sales department, etc., we’re able to handle the request quickly, and people don’t feel like they’re hitting a wall.
To be continued now by the person who has taken over. But in any case, it was a great experience to ask these questions about the specifics of this profession and to reflect on another way, another form of agility that isn’t, therefore, that of product development.
Thank you very much. There’s still a little time for questions.
And for more information,