Lindsay Velecina: 0:03

Welcome to the Scrum.org community podcast, a podcast from the Home of Scrum. In this podcast we feature Professional Scrum Trainers and other Scrum Practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Dave West: 0:20

Hello and welcome to the Scrum.org Community Podcast. I'm your host Dave West, CEO here at Scrum.org. Today's episode is going to focus on a company success story. A success story which is always good. And it's a success story that I care deeply about being a being a man who shaves regularly and has no hair, Gillette. So we're going to be talking to Gillette. Well, obviously we can't talk to Gillette. We'll be talking to David Ingram, Vice President of Gillette in R&D. And he'll be taking us through how they use Professional Scrum in the development of a new razor. Welcome to the podcast, David. Thank you, David.

David Ingram: 1:03

Pleasure to be here.

Dave West: 1:04

Yeah, I'm excited to talk to you, I have to say just for our listeners, full transparency, I actually used the razor that was developed using this process, etc. Today - this morning. So as you can see, no, no cuts well, you can't see, but I do not have any cuts. So I have a vested interest in this story. So I'm very, very excited to be talking to you, David. So I guess to begin, tell the listeners a little bit about yourself and your role at the Gillette to give it a little bit of context for this story.

David Ingram: 1:39

Sure, Dave. So I'm Vice President for Research and Development. I'm based in our Innovation Center in South Boston, in Massachusetts. And really, my responsibility is to develop our new products for launch across any of our Gillette brands and the different products that we sell under the Gillette brand name.

Dave West: 2:05

So people have seen your products every time they walk down the razor or home kind of aisles in their local supermarket or CVS.

David Ingram: 2:14

Right, exactly. That's exactly right.

Dave West: 2:16

Yes. Excellent. So I guess many of our listeners won't naturally connect Scrum, with the development of new razor. So perhaps you can tell us where you were when you sort of started this journey. So what was the situation, give us a little bit of background about the problem that you then used Scrum to solve?

David Ingram: 2:41

And, you know, it's entirely true, Dave, to say that, we haven't tied Scrum to the development of our new products historically, we've really used the waterfall process. So, you know, the question you're really asking is, why did we choose in this particular case to use Scrum? You know, what were those factors. And really, if you look at generally, what happens for us with our new razors is we launch a new razor about once every five to seven years. And it's always a much better shave, than the last product that we developed. It's great Dave, you had a great experience this morning with our latest razor, the exfoliating razor. But really it's once every five to seven years, we launch a new product. However we found ourselves in the situation where we needed to launch a new product in a few years time, much less than the five to seven, we needed it still to be the best product that we'd ever developed. But also the world had been changing. And what we could see was, you know that no longer are - Is it very dominant for men that work to be clean shaven, or for really anyone to be clean shaven? So the question was, how do you appeal with a brand new wet shaving razor, to today's population of people that wet shave, but make it a better experience than you've ever created before. And the challenge that we were given was to do it in less time than we'd ever developed a razor in before. And really looking at that challenge, you know, a better razor in a different world circumstance with less time was what led us to look at this and say, for this kind of challenge that we've never addressed before. If we address if we tackle this using waterfall, we'll never make the timings and we're unlikely to develop the kind of product that we've been asked to develop. So let's look at using something different. We can't do the status quo here.

Dave West: 4:40

Wow. And that led you to Scrum, to Professional Scrum. Right?

David Ingram: 4:45

We did. I mean we first of all, I asked around within the company and looked at what were different ways that people were using to get work done. And you can imagine in a company with, you know, approaching 100,000 people, there are experiments happening all over the company. And we had some experiments happening in areas where you can improve your execution, efficiency and speed. But as we looked at the kind of challenge that we had, for our project, we really had a design stage challenge of how would we do the design of the product and the proposition as quickly as possible. And really, for us there, when we asked around within the company, what methodologies are best for design stage problems that led us to Agile and Scrum specifically. So really talking to the the experts within the company, they kind of confirmed- Yeah, your best bet here is to use Scrum.

Dave West: 5:42

And that's predominantly because of the heavy amount of communication human beings working together in teams, and solving a problem that sort of emerges, you know, multiple problems emerge during the lifecycle. I'm sure of developing an amazing new razor.

David Ingram: 5:59

Exactly. And, you know, you can imagine for a company like ours, with the products we sell, you know, we're developing hardware and multiple pieces of hardware. We're developing packaging. We're developing a marketing story. We're developing industrialization and manufacturing strategy. We're figuring out our cost, we're figuring out, you know, how many pieces we need to make. So if you look at the complexity of the problem, and the uncertainty, there are so many moving parts, but it really started to look like an iterative process, leveraging a Scrum would really be what we needed to bring all those pieces together.

Dave West: 6:42

That's amazing. So tell me a little bit. How did it look? You know, you tell me. Okay, you said we're going to do Scrum, which, you know, people are looking at you and say rugby here, why? And so suddenly, you've got a bunch of very different technical professionals. You know, you've got material scientists, you've got supply chain, you've got marketers, you've got all these very distinct disciplines. And suddenly, you're about to do Scrum. So tell me what happened from then you've decided to do Scrum. You got this large group of people, you know that using a different process historically? How did you how did you approach this? What happened next?

David Ingram: 7:22

Yeah, great question. So actually, the first thing was that there were two pieces of advice that we got within the company, the first one was, you know, use an agile methodology like Scrum, for the kind of problem that you have. The second one was, don't try and do it by yourself, you will not succeed if you do this internally. So candidly, the first thing that we did, Dave, was to go and look for an external expert that could help us. We're blessed to be here in Massachusetts. And we were fortunate enough to find our way to Agile Sparks. And to find a wonderful Agile coach called Yuval Yeret, who was available and who had a real passion for working on hardware projects with Scrum . And so the first successful thing we did really was find an external expert that could guide us and help us into how on earth to just get going with this. And that was a really important first step. The second thing that we had to look at, as you say, is, you know, we started to write down who was on the team. And you can imagine, I described some of the, the aspects to our project that need to be developed at the same time that we when we wrote down, okay, who's on the team? How many people do we have, we ended up with about 55 people that were on the team significantly, you can imagine that you look at that against, you know, the Scrum Guide, and it says you should have a maximum of maybe about 9 or 10 people. And it kind of didn't work so that the first thing that we needed to work through with you, how do we take a multifunctional team that is used to organizing by discipline, and split that team up into sub teams of a maximum of, you know, 789 people that are working on different parts of the proposition? And it was a very different thing for us to look at? How do we split our proposition up into elements that feel natural, but will also come together for a realistic proposition at the end. And so we divided the team up into those logical groups, you know, sub teams, and then really what we started to do then was think about how do we align all of these teams to a single backlog? That was our next most important thing you can imagine? And I'm sure you've you've seen personally and you know that in in companies where you run waterfall as a matter of course, you end up with quite long and quite functionally specific targets for the project and objectives. And it was really important for us to reframe how we were going to go after this to say, Yeah, you know, let's drop those for the time being. And let's focus on the overall holistic objectives for this project, what are the outcomes, we really want to get for this team as a whole. And that was incredibly helpful for us to strip out those few objectives that all of those sub teams needed to deliver against in their work and develop that backlog. And that was very transformational for us in terms of making sure that all of those teams were aligned against the very few goals that we had for

Dave West: 10:40

And I think I just want to riff on that for a the project. second - outcome based rather than task based, traditional waterfall project planning processes, decompose it into lots and lots of tasks, and farm them out to 1000s. Or in your case, 50 Something people, they all then work on them with the other 15 projects they're working on, or 20 projects, you know, and then somebody runs around trying to get everything together, what you shifted to was very outcome focused, allowing the teams to then define how they were going to deliver against these outcomes. And then bring that together in- Okay, let's review that we call it a sprint review, obviously, review the outcome, how did we do against the outcome? How we do it? And then what do we need to change next time? What have we learned as we go through it does that is that pretty much the essence of how you were working?

David Ingram: 11:34

Exactly, and it's a massive change, really, to put those overall objectives front and center. And to at every increment, if you like to compare, have we reached what we need to do in this area yet to pick, you know, to pick two simple examples. Two things that we absolutely need to do as a company, you know, is to come up with a product that delights our consumer, that people that are going to buy the product, and to create value for our company, I mean, that there are two straightforward goals that we need to create, by putting those front and center from the start and saying, Have we done these two things yet? It's just very different when that's the first question you ask, versus have we done this, you know, functional step that we always do at this point in the project, it really reversed where and changed where the team's focus was, as an integrated team.

Dave West: 12:32

I think that's it. That's a huge change. From the industrial mindset to this, whatever this thing that we're living today is that sort of focusing on the outcomes, focusing on the value focusing on the customer. That's the key stakeholders for that. And I think that is really interesting. And just as a consumer, and I don't know if this is a tool related, I was thinking about the razor this morning, because I knew that we had this this podcast. And as I was shaving, I was thinking what's different? Why have I moved from the other one because I've bought Gillette for my entire life? That has like it's orange and has like a battery. And it vibrates? Why have I moved? And, and I'm so thinking, because this is this exfoliating razor is so simple. And it almost the elegance of the device, and the fact it does a great shave as well. I don't know why. But it's kind of appealing. I wonder if that is connected to the result of the teams working on on outcomes. You're not kind of like trying to keep everybody happy anymore? I don't know if that is, but it just struck me this morning, as I add that as I had that shave,

David Ingram: 13:40

You know, it certainly helps you make choices. And always in any development project in any company, you need to make choices about where you spend your energy. And I certainly think that holding those few objectives front and center for the team allowed us to make those kinds of choices we had to make, always in service of the objectives, rather than finding that we were making choices that weren't so clearly connected to the objectives of the project. So I do think, you know, I can't second guess what we might have done otherwise. But I do think that having that very clear backlog allowed us to more easily make those choices about what would drive value for this proposition versus carrying in baggage about what we always do, or, you know, what, what, what, what habits we built up, so I think it was very, very helpful for us.

Dave West: 14:39

And I as a consumer, I'd like to applaud you for that. I enjoyed my razor this morning. So okay, so the end I'm conscious to keep this short and to the point for our listeners, and I think it merits probably other podcasts, but so tell me a little bit about the results. Tell me a little bit about the outcomes. Um, where did you, you know, obviously went to market there was a Superbowl ad that completely shocked me. I was like, Whoa, Scrum. I call it the Scrum razor. I know, that's not its official brand. I was like the Scrum razor is on TV. But how, you know, what were the results? How did it go?

David Ingram: 15:19

So I mean, so basically, we've launched in a few countries now, we launched in the US, the UK, the Netherlands, I think, is the latest country that we've launched, and others to come. You know, obviously, the product is fantastic. And we developed on the timescale that we hoped we would, which many people thought was impossible, at the time when we started, so I'm always happy to prove a few people wrong. So obviously, we succeeded there, I think, when you look at the associated benefits, though, looking at the process, what came out, the real benefits to us, number one, was this parallel creation, you know, if you look at a waterfall process, what you tend to do is develop the elements of the proposition sequentially. And what you're doing then is delaying tensions that you will discover later. So let's say you develop a product that's too expensive. If you only do your financial analysis, several steps later, you can become quite invested in a product, that actually is unaffordable at the end. So for example, the sooner you work these things in parallel, and you work, the total proposition in parallel, the sooner that you understand the tensions that you're sitting on, that's super important for us. Because in parallel, what we created was regular stakeholder engagement at the end of every Sprint. And so during the Sprint, looking at everything in parallel, we could uncover the tensions that existed in the team. And we could very, very quickly raise those tensions to stakeholders, you know, our CEO included, to say, what do we do? You know, we need guidance, what do we do here? So, so we uncovered the tensions very quickly. And we made decisions far more quickly than we would otherwise, recognize that in a waterfall process, we may have kept these tensions for six to nine months, before we appeared with stakeholders, or we may have waited till they got so bad that we needed an emergency meeting, when you can raise your attentions every month, and meet with your stakeholders every month, you can deal with them as an ongoing part of your process and very effectively. So decision making improved massively for us. And associated to that, then the quality of the execution that we developed, and the speed with which we develop that execution, because we weren't having to go back and redo months worth of work, based on tensions that we discovered later in the process. So those were really the main benefits for us for embracing Scrum.

Dave West: 18:05

How did the the people working on the project find out? Did they enjoy it?

David Ingram: 18:11

They did. I mean, it's not without its tensions, I would say that there's a there's a big feeling I think, for the people that work on it is this is a great new process to work on. We love this new process that the most difficult and our stakeholders, our CEO has said he loved being involved in this project and actually being a part of the development process. Where we run into problems though, is where the Scrum Team runs into existing processes, rituals that exist anyway in our organization. And there's almost things grind to a halt sometimes and you need to work through. Here's how we do it in Scrum. Here's how we operate for everything else. Now, how do we interface our Scrum Team with these existing systems that we have? And that for me, as you know, my level VP level that was one of my biggest challenges, if you like to go and work through was how to kind of tie together our Scrum system for this project, and our existing waterfall processes for everything else in a way that didn't create overbearing tensions for the team that was trying to get stuff done.

Dave West: 19:30

And it's led you to start making some fundamental changes to how Gillette works or R&D at Gillette works right?

David Ingram: 19:39

It absolutely has. I mean, working things in Scrum uncovers some of these tensions that exist in your organization. Anyway, it raises questions about what why do we do this? Is this adding value is this the most effective way for us to be doing that? So absolutely doing this one project with Scrum has absolutely launched us into was a much longer process to go in tackle our agility as a total organization. And how do we scale to become more agile over time? But that's probably another story that we'll have to cover another time.

Dave West: 20:14

Exactly. Well, we've come up to our time. I know you're a very busy, busy man. And I really appreciate you taking the time today. So ladies, gentlemen, to the listeners, that was today's Scrum.org Community podcast. We're very fortunate to listen to David Ingram, VP of Gillette R&D, talking us through the development of the exfoliating razor from Gillette Labs, which I didn't know about, it's changed my life for the best. So I recommend you try the Scrum razor as I'm knowing it as now, but don't quote me on that. Thank you. Thank you, David, for taking the time. Really appreciate it. And thank you to our listeners. And I think there will be another another podcast as we talk about your journey at Gillette. Thanks, everybody. Bye bye.

David Ingram: 21:01

Thanks.