Good morning, everyone. So just to tack on to what Gene said, we have had the privilege of getting exposure to the DevOps community. Pretty much, Rob's front and center here. He's our thought leader in this space and got us connected to Gene a couple of years ago, and John Allspaw as well, who's been a great resource for us.

But I think, you mentioned the connection with Target. It's like what I love about this community is you really get the opportunity to share, and it's genuine. I feel like we're all in this to learn from each other, which is kind of rare. So I think, just with that, I'm going to get into the presentation.

So from a Nordstrom perspective, just to give you some context around the company itself, we have about 63,000 employees, 1,800 of which are in our technology organization. We do about 12.5 billion in revenue. And so that's the lay of the land for Nordstrom. Gene mentioned the way that we're structured, probably not shocking, the customer's at the center of our universe.

But prior to really a couple of weeks ago, we were structured the way that you see on the left-hand side of the diagram. We had on the upper two boxes, that's considered our full price offering. We've got our brick-and-mortar stores, obviously, about 118 full line stores. Just opened our first one in Canada about a month ago.

And obviously we have nordstrom.com, and then we have an iPhone app and an iPad app in the Apple store. The bottom two boxes are really our off-price offerings. So we've got rack stores, 162 of those across the nation, as well as nordstromrack.com. And we acquired HauteLook in 2011.

If you don't know what HauteLook is, it's basically a flash site. So we've got a website and an app, a HauteLook app. But essentially that's how we were organized. Everybody's mentioned silos.

We definitely have those and continue to have those. But a few weeks ago, we organized our business leadership. So I have a peer in the business who has accountability for that full price offering, full stop, and then I'm his counterpart in the technology organization. So big win.

We all think from our perspective, our customer doesn't look at us as a channel-based offering. They really look at us as a seamless offering. So starting to make moves in that direction. So I'm going to back up a little bit to explain what was our burning platform and how did we start transitioning into not only adopting DevOps, but really looking at a culture of continuous improvement.

So 2011 is the year of the-- maybe we'll call it the year of the sharks instead of the shark visual. But essentially every year in June, our board of directors, they have basically an offsite, and they pick a couple strategic topics. In 2011, it was all about online growth. They were looking out at some of the traditional brick-and-mortar retailers who'd said, "Eh, nobody's ever going to use the web, and no one's going digital, stores are fine." And a lot of those companies aren't in business anymore.

And so the Nordstrom board and the executive team said, "We don't want to be one of those, so let's figure out how to expand our online offering." Up to that point, we had a website. We definitely had a presence in the web, but it was really treated as a steady state investment. We'd have capital and we'd do features, but we'd do them twice a year. So big batch, couple of releases a year, and that was pretty much it.

I'm actually not going to talk a lot about the website journey. If you get an opportunity, we did a case study as part of an O'Reilly publication, DevOps in Practice. Gives a lot of detail about what we did within the web world. I am actually going to talk about a case study in our customer mobile space.

But first, I'm going to give you the background around where our organization was at. So in 2011, we were optimized for cost, which a lot of these terms are not foreign to all of you in this room. Lots of shared services and annual planning cycle. Waterfall, that was our delivery mechanism of choice.

We did Waterfall for everything. Big batch releases. I mentioned the website twice a year. That was actually more frequent than I would say the bulk of what we delivered.

Usually, it was multi-year projects. However, based on that success criteria at the time, we actually had a great track record. Very predictable, delivering on time, on budget. Just tell a really short story.

We had a two and a half year project to rewrite our in-store clienteling application. It's something called Personal Book. So we kicked it off and I tell you this because the timing actually lined up really well with this story. So it started in, whatever, two and a half years before 2011.

So we delivered it in 2011, and by the time we delivered it, it was essentially irrelevant. It was not built for the customer, it was basically built for us. And by the time we put it into production, it basicallyIt didn't resonate. And so it was a big wake-up call for us as an organization that we had to figure out a way to deliver in this new context.

So then we said, "What does it look like to optimize for speed?" So speed to market, speed to value, however you want to define it, but we said we need to start looking at delivering differently. And so we did the, "Let's do Agile." And we essentially put a bunch of people together, mostly leaders, and said, "What's out in the industry? Are there any frameworks we can adopt? We're not the first company to say we should use Agile, so let's go out and let's find a way that makes sense." So we did that.

We established processes. We established roles. We did all the traditional things that we always do when we're going to make a change. And then we proceeded to implement that change in a very tops-down method.

We essentially said it's a one size fits all. Everyone will adopt the same standard, the same processes, the same roles. And as you can imagine, it had varying degrees of success. We had some people who said, "Of course, I'm going to do it because I'm getting told to do it." And we had some teams say, "I don't even know why I'm doing this." And then we have a leader on our team who said, "We're really good vocabulary engineers." So essentially we were doing Waterfall, but we were calling it Agile.

So it was a very interesting point in the company's journey. So we did have some thought leaders who said, "I think we need to do this differently." And what I don't want anyone to walk away with is that we believe in Agile, the principles. It was just the method in which we went about implementing it. But the one thing we missed that I think was the key missing was the part about it being team-led.

So we kind of regrouped and said, "What does it look like when we actually engage the teams that are doing the work and ask them to help us understand the best way to deliver value?" And so what came of that was value streams. How do we understand the value? How do we understand our cycle time? How do we migrate to a continuous flow and really embrace the improvement kata, and figure out how to deliver value, and understand how to move faster?

So with that said, I'm going to talk about our customer mobile app team because they were basically trailblazing for us, and it really started with the leader that we put in. Basically, they had been led by someone previously. We moved this leader into the role, and he really understood Lean and really understood a lot of the practices and techniques and principles that we were trying to adopt. So prior to him moving into that role, we had our traditional model.

So most of our technology teams, our programs, are divided into kind of two silos, I would say. One is delivery, so anyone who's basically putting a feature out. And then we have another team that's our production support team. So not even talking about, we also have operations teams.

This is within the development teams, we have this divide. So we have a lot of the folks that are actually producing the code are not the ones who actually fix the issues in production, so that whole accountability challenge. So when this leader went in to this team, he basically said, "I want to understand, how do we deliver value? What does it look like in this team?" But he didn't start with the principles, like the terms and getting the team educated on the principles.

He actually just went in and did it. And so the result was this, which looks real messy, and it's supposed to. But essentially, he was able to surface, how are we delivering value today? How many teams are involved?

Who do we leverage? Who are our suppliers? How do we move value through our team and through the system, basically? And it's kind of hard to read, and I'll show you a different slide in a couple minutes, but essentially, our lead time was anywhere from 22 to 28 weeks, which is an eternity in the mobile space.

But this made it visible, which I think is a really key theme around these practices, is that before that, we knew we were only releasing a couple times a year, but nobody really knew why. And this really highlighted what was involved in getting releases into the App Store and really made it visible, not only for the team, but for our business and for our stakeholders. So once it was visible, the team made changes, and I say the team because the team owned coming up with what would make sense and really drove the change. So one thing we did is we broke down that divide of dev versus prod support, and we created squads.

So we basically put people together to deliver value and put them all together in the same team. We also migrated to continuous planning. So in the previous context, we would have these huge ceremonies called release planning events, and we would pull literally hundreds of people into a room to talk about what's the next release going to look like. So we stopped doing that and instead moved to this concept of continuous planning.

One thing that kind of carried over into the Agile context from the Waterfall methodology we were using was this hardening phase. And we had it in every project. Essentially, it was a window between kind of testing, ending, and deployment.Where we were stabilizing the release. But really what it was, was kind of a catchall.

Like if a feature wasn't really done, you kept working on it. And essentially we said, "No, we should be building in quality up front. We shouldn't even need this hardening phase." So how do we eliminate it and actually do the right thing earlier in the life cycle? Then we moved to a single backlog of work.

So the business worked closely with us to make sure that we weren't just prioritizing features all the time, but we were actually looking at production fixes and defects and bugs all within the same backlog. So essentially work is work. So as a result, bugs went down and throughput went up. So this is a really good story from their perspective and from our business's perspective.

So that's one window into the data that we were able to gather and make visible as part of these changes. The other one, this is my favorite one. So our deployment and release frequency, so before, I mentioned we'd do releases twice a year. Now we can release monthly.

And frankly, we could release even more frequently if we wanted to. But the key is that the business decides, it's not technology. And we used to be the impediment to the releasing frequently. So we've actually found that monthly is pretty standard in the Apple store.

So we feel good about where we are, but I think it's just important to know that with this method of how we're delivering, the business can decide when they want features to go in. So I'm going to shift gears. When we focused on customer mobile, it made a lot of sense, especially when we said we want to be relevant in the digital space. In online growth obviously, having a compelling mobile experience is a key to that.

But what we learned as we went through this with the customer mobile team is that a lot of these methods for getting work done applied everywhere. It wasn't isolated just to the places that we wanted to have speed to market. It really was relevant in any team that was delivering value. So one of those teams is our restaurant team.

So if you haven't eaten at one of our restaurants, I encourage you to try them. They're fantastic. We have 210 of them, because some stores have not only a restaurant, but they also have a cafe and an eBar. So we've got three possible concepts within a single full line.

So this team, I'll talk to you about where they were at towards the tail end of 2013. We have this business request that comes our way. It's called a re-concept. And essentially the request will be, "I have a cafe in this full line store.

I want to rebrand it a marketplace." Which sounds really simple. It's like, okay, well change some signage and open it the next day. But that's not really what's involved. There's menu changes.

There are footprints within the actual restaurant where sometimes we'll add servers or registers. We'll do configuration changes. So it's pretty involved. So this team did 11 of those in 2013.

Our business team said we're going to do 44 in 2014. And at pretty much the same time, this team was also going through a pretty significant pain point around service interruptions. So they had elevated the visibility of the incidents in the restaurants to what we call a high impact. Just give you a brief how we manage incidents at Nordstrom.

Once something is categorized as a high, it becomes very visible across the organization. It usually means that we can't take a customer's money, which it's a big deal. So this team, prior to 2013, those incidents were not classified as high. They actually were medium.

So they really weren't hitting the visibility of a high, even though they really were. So within a two-month period, they had 30 plus of these incidents. So you can imagine what that felt like for them and for our stakeholders, and it was very visible. So I got a phone call from one of the business leaders in the restaurant division at the end of 2013, and basically, "We're going to open more concepts next year.

We're having all these service interruptions. You need to triple the size of your team. There's no way that your existing team can keep this up." And basically, my response was, "Well, that's one way to solve it. We could definitely throw more people at it." It's a go-to move for us, to be frank.

It's like, we must just need more people. Let's just keep adding more people. And then over time, we realized that that's not always the best solution. So since we had just done this value stream mapping exercise with customer mobile, it made it very easy for us to say, "Why don't we try this with this team?

Why don't we take them through this exercise? Let's understand what it takes to do one of these re-concepts, and then let's identify the waste and make some improvements, and let's see if we can actually not scale the team. Let's see if we can do this with the people we have." And so that's what they did. And the business participated with us as well.This might be kind of hard to see, but essentially, this team was able to take their cycle time and reduce it by 40% with just one improvement.

And it happened to be at the very beginning of the value stream, which, if you can find something at the beginning, that's a really big win, because it typically has a lot of downstream payoffs as well. But essentially, we were asking for a bunch of information at the beginning of this process. Some that we didn't need at all, some that we just didn't need then. And we were just iterating at the very beginning, and it was just creating a bunch of waste.

So the team streamlined that, and they took 40% of the cycle time out with that one experiment alone. And then the bottom graph is to show our trend for incidents. So once this team made the problems visible, they also went through the technique of problem-solving to identify root cause and come up with a countermeasure that they basically put together a business case, and we ended up funding new hardware for our restaurant division. And as a result, in the last two months, they've had three hardware incidents.

And we actually just completed the hardware rollout, so I'm excited to see what next month is. So far, I think we haven't had any. So it's a great story. The other thing that's exciting about now that this team is practicing this, we obviously have more work to do, because you can see there's this other bar where we're also having incidents, but they're for a different reason.

But the team was able to quickly get to root cause and figure out what we should do next. And the other thing about this team is when I first started supporting them, everyone wanted off of the team. They were all planning their exit strategy because it was so hard to be on that team at the time. And I had a hard time attracting people to that team.

It's the same team that went through the value stream exercise. They have stayed on the team. People want to be on that team because they see how they're doing their work differently. And it's actually one of the teams that is trailblazing in this space.

So they have been a model for us, recognized at some of our annual recognition meetings, and they've been able to really demonstrate that if you look at your work differently and you make things visible, that good things happen. So it's a good success story. So there's some things I want to leave you with. People, I think you've heard this theme from yesterday, too.

I talked about a lot of process, showed a bunch of data. It's very exciting. But what it starts with is people. If we're not engaging the people doing the work and we're not leveraging what they know and asking them to help, I just think it all falls down.

So we're a big people-oriented company, which is probably not surprising if you know Nordstrom. But I think it's important for us in our organization to treat our people like we treat our customers. The other thing is everything we build should be about the customer. We should always ask ourselves if the customer would value that.

I mentioned that personal book example. This would've been really compelling to do throughout that project. We should've been asking that question. I have a passionate belief in continuous improvement.

I think it's a critical component of how we'll get work done. And really creating a learning culture. I've been in the process of learning a lot of these techniques over the last year, and it's hard. And that's kind of the next bullet.

It requires discipline. As someone who's been at Nordstrom for over a decade, we're fixers. We love to be heroes. We're very optimistic.

In this world, though, it's important that we are disciplined in how we create value and really also making sure that we understand our capacity and that our teams feel supported and not overburdened. And I think this is a method to get to that. And then leaders have to evolve. And I'm going to go into detail about what I mean on the next slide.

But I know for myself, I've had to make changes in how I lead. And it has been a very good learning experience. But again, it definitely hasn't been easy. So Gene had asked me if I could wave my magic wand, which I was like, "That would be awesome.

I would love to wave a magic wand." What I would want for every leader in our organization, and number one is honor reality. We have a lot of assumptions that get made. We put a process in place three years ago. People should just follow it.

They just need to understand that that's the process. And often there's a reason. There's a reason that people are working around something. And it's usually not bad intent.

Often there's something to it. And I think especially in the areas where we're trying to maximize speed to value, we should be inspecting processes on a very frequent basis and make sure that we're not actually creating friction for the teams that are delivering value. The second comment is about becoming a student and go and see. This has been met with some resistance because some people translate this to micromanagement.

We're a big culture of empowerment, and one modification to this that we actually talked about yesterday is that it's not go and tell. It's not go to the team and tell them what to do. It's go and see.Ask questions, observe what the team's doing, genuinely engage, and ask how you can help, versus traditional sit in our offices and wait for the team to come to us. And then becoming a teacher.

I think the practice of problem-solving and the leader's role in that, helping the team get to root cause, making it important, giving them the time and the space to actually get to root cause, and then following up. Making sure that we're helping the team as they continue to go through the problem-solving exercise and the improvement kata. It's like understanding what it means to pick a target condition and figure out the countermeasures that you're going to use to get to that target condition. And I think it's important to practice it, but then the ability to teach it, I think, is extremely powerful.

We've talked about leveraging consultants and bringing people in that can help us learn this, but what's been the most powerful is finding leaders who understand it and embrace it and can then go teach it. It has a way more sustainable impact, and it's more credible. And then leading by example. So most people, when they see the improvements that have happened in these teams, they definitely will say they're in.

They love it. They want to do it, but because it takes discipline, sometimes the actions don't match the words. So I think it's extremely important that leaders are leading by example and making sure that their actions match their words. And then asking why and articulating why.

That's probably been one of my favorite experiments over the last year is somebody will make a statement, and I'll say, "Well, do you know why we're doing that?" "Well, no, I don't know why." We should find out why. We should always be asking why, and if a leader can't articulate why, then they need to go find out why. And so I think often we take things for granted, or we make assumptions, but really getting to the root and asking that question and being able to explain why. So what I could use help with.

We have been able to measure throughput. I know I showed the slide from customer mobile. We've been able to come up with some ways of doing that at a team level. We're really trying to figure out how to do that at scale.

How do we measure throughput, and what's the right metric? Because we want to make sure we get the behaviors and the actions for the right reasons, and I think measurement can always be that delicate balance between what you end up getting, depending on what measurement you choose. So that's a challenge for us. And then case studies, any stories, good or bad.

We're always looking for how can we learn from others, and how can we share our stories as well. So anything around that we could use help with as well. So that's it. I'm done.

Thank you, Courtney. We have two minutes. I think that's time for one question. First one.

Yeah. So great presentation. Thank you. I'd love to hear more about...

You shared with us kind of what I'll call a little bit more of a unicorn story as you're talking about getting out an app. Yeah. Can you tell us a little bit about any of your systems of record or more of those kind of Nordstrom enterprise systems that may be more traditional IT, how you apply that? Question.

Yeah. You told us an easy one. Tell us a hard one. Probably feels easy- Tell us about system of record ...

was not easy, but yeah. So we're still early in our journey. The restaurant example is one. I would not label them a unicorn.

They're on a very legacy platform. We don't own the code. It's a packaged app. And they have applied these concepts and have been able to demonstrate that they can maximize that speed to value in their context.

We have started, I've got someone here from our shared service organization. We've done this in some of those areas, which might not totally answer your question, but our enterprise service bus team. They've been able to adopt these techniques and actually automate how they provide and provision services. Our server provisioning team has gone through and said, "How do we understand the value we deliver to these other value streams and then automate processes to eliminate waste?" But we're still early in our journey, so we haven't yet gotten to some of the more back-of-the-house kind of teams yet.

Thank you. Point of sale restaurant systems, easy. Great. Thank you so much, Courtney.

Yeah. All right. Thanks.