 I do have to tell you that what we're about to share might not represent the views of Starbucks, but we are excited to share our personal experience in the journey. We heard yesterday there's no DevOps without sharing, and we are really honored to share today and we're looking forward to learning about this journey with you guys. So we just heard from Jez, I love that message. You don't have to be a startup or new technology to be DevOps. How many people have really complex systems trying to do this? Yeah, many of us. How many people have monolithic architectures, all of those things, cultural issues that don't align with DevOps? We are going to tell you about how we face some of those challenges. More about that, Suzanne? Yep. People here are trying to figure out, where do I start this journey? Come on, raise your hands. There's a few of you. It's okay. It's okay. You haven't started. We tried to figure out the same thing and we really started a few years ago and we started with our transition, our transformation from waterfall to scrum. The big question to you, how do you persist? What happens when things get tricky? What happens when you get pressures, outside pressures, and how do you keep the team excited? Because you will fail along the way. How do you keep celebrating that and moving apart from each other? All right, so I have been in technology for the majority of my career. I have always had some piece of lean in my experience and information that I've been part of. I went through a multi-year DevOps transformation that is one of the case studies in the DevOps handbook. This is my second. I was in an engineering leadership role previously in that transformation and I'm taking a totally new role in this one. All right. I'm Suzanne. Sarah and I are both native Seattleites. I'm even a West Seattleite. I was born and raised there and I live back in the house I grew up in. That's kind of weird. I know. I also, my whole career has been in IT. I started out as a developer and I've been at Starbucks the last 20 years. I think you've probably all heard of Starbucks by now. I was going to say, how many people stopped at Starbucks before they came here? Well, if you didn't, you could just get it in the lobby too. I did both. You might have too. We're obviously a global company. We have over 330,000 people that work for us. Partners is what we call our employees. Starbucks. We're here kind of talking about our journey that we've had our point of sale team on. The point of sale, if you're not familiar with it, I try not to call it POS team because my husband has told me some people don't know what POS means. Or they have a different meaning. You should say you work on point of sale systems. It's not just the cash registers. It's all of the different devices in the store, the labelers, the ticket printers, the pads you stick your card into. It's a pretty big system and it takes about a team of 80 people to support it. My team is just one of those teams, one of those sub-teams. I have two teams. We have two adult teams. They had fun naming themselves. We have one cross-puma, which is like a cross-eyed puma. The other is team Jedi. It's a mix of folks, one to two people on each of the positions you see here, so kind of a pod moving towards more of a full-stack type of DevOps team. I mentioned we started our transition to Agile a couple years ago. I saw a couple people here yesterday from the talent lab at Starbucks. You guys still here? Caroline or Kathy? We have an amazing talent lab that really helps focus when there's transformational journeys to happen. They started this a while ago and we're looking for volunteers to take their teams through an Agile journey. Myself and another leader at Starbucks in the POS team said, we volunteer our teams. I'm not sure how happy our teams were about that at first, but they're doing pretty good now. We were super excited to start their journey because we've been hearing about Agile. It's been around for quite a while. It was new to some parts of Starbucks and it was new to our team. We were excited to start it. Part of what we're going to tell you is it's a great journey. It is bumpy at times, so it's really great for your team to be aware of that and for leaders to share that with your team that it is going to be bumpy and it's okay. You're going to learn and change. Starting the journey, in the beginning, it's all about the team forming and storming. On the right-hand side, everyone's probably seen some version of a change curve. Any big transformation, people are going to be changing, learning a lot. They're going to go through those kind of phases. People at different stages are going to feel what it's like to go through, learn new things. It is a big transformation. It's important to focus on change management and let people know that that's coming. The first things we did, we took our team. We sent them off-site to a multi-day Scrum boot camp. That was great to get everyone to the same level of understanding what Scrum is, how to do stories. We had a dedicated Agile coach from our talent lab to help them bring back to the team, set up all of the daily routines, your ceremonies for daily stand-ups, the planning, grooming, retrospectives, and also take the team through another full-day education around. What's the team want to do? What is their focus going to be? What is their team vision? What are they going to call themselves? It's really great to start the team off with some of those bonding activities and get everyone on the same page. We had some key learnings here. I mentioned the change management. The other thing, again, as a leader, make sure your team knows that it's okay. They're going to be learning new things. You need to be there to support them. You need to listen to what they're going through and just help them along that journey. The other thing, super important, commit and fully stay the course. I made the mistake of telling my team this is going to be a trial. We're going to try Agile and see how it goes. As soon as we hit those first bumps, people are like, okay, well, the trial wasn't so good. Let's go back to Waterfall. I would just say, if you're starting this journey with your team, commit to it. Make sure the team understands this is what we're going to do. We're all going to learn. We're going to continue and commit and stay the course. All right. I think I skipped one. Moving to the curve. There we go. After the team has done probably like six months or more of that storming and forming, you finally get to the point where they are norming and performing. They've moved through that second half of the curve. They have the routines down. They're doing their daily stand-ups. They get it. They're working on the stories. Their velocity is starting to increase. We were doing demos pretty regularly with our business, which was pretty exciting. We also moved from quarterly releases to monthly releases. I know monthly still sounds like that's still monthly releases, but from quarterly to monthly, it was a really big deal. The business owners, business groups started to see the changes and we were able to deliver faster. It was great. They were excited. The team are out. It was a really big step. The learnings here, I think. Who's read the Phoenix project out here in the audience? All right. Some of the learnings, and we talked, I think Scott, a few other people have talked about it. Really kind of that cross-skilling, upskilling of your team is important. This is kind of where, when you get to this point, if you haven't already, you discover your brand, like in the Phoenix project. You find out who's your bottleneck. Who has that silo of knowledge that we haven't really been able to break down, spread across the team. This was a key point that this comes apparent and you need to encourage the team to share their knowledge. They can cover each other and learn more and break out of their traditional roles. Start focusing on that T-shape. Yeah. And again, failure is okay. We're still going on this journey. We've been doing it for a while, but you're still learning. You're going to have failures. It's okay. You're not being measured on the number of bugs you have or the time of your cycles, the cycle time, and it's okay to fail. And if you're not having some failures, you're probably not doing it right. So, there's Courtney. Hi, Courtney. So, Courtney, if you've been to a few DevOps days or presentations before, you probably are familiar with Courtney. So, at the time I was having some personal and professional aha moments was about the same time Courtney had joined our organization. So, after about a year where the team had gone through like the norming, storming, they're performing, I had been hoping with this journey. And I woke up in the morning and it was like, wow, what's happened to my job? Half of my job is gone because I used to be the one that worked with the business to take all the requests in and do the prioritization. And then I would delegate my team out to do the work. Well, now we had a project owner who was doing all of the gathering of those intake requests, doing the prioritization. And the team had become self-managing. So, they were doing all that. And I was like, half of my job is gone. What am I going to do? And Courtney was awesome. I talked to her. I doubted whether I should go into my new VP's office and tell her, what am I doing with half of my job? It was a little scary moment, but she was great. And she said, we talked about it. She's like, after you've taken your team through this agile transformation, that's what happens. Half of your job is gone and that's okay. It's to be expected. So, thank you, Courtney. And what she also brought is she had brought and been sharing her DevOps knowledge and practices with us. And so, we talked about what is next for me to help bring my team along to the next transformation. So, that really was great. And that's what I focused on. It's like, okay, I have a lot more to learn. How can I best support my team and help bring them along on that transformation? A few key learnings we had at this point were we had talked about co-locating the team. We had, you know, the analysts in one area, the QA team in another area, and the development team in another area. We decided after many people weren't too excited about moving, we decided it was time to move. And this actually was key. So, we had kind of been finding it for about a year after we co-located the teams together. It probably took two or three weeks and people were just going, this is awesome. You could just see the collaboration. They were working daily sitting next to each other. So, it was a huge improvement in collaboration and teamwork. So, I would encourage you, if you haven't done that with your teams, to co-locate them. And then I talked a lot about Courtney Leadership Support. So, without the support of your leadership to be able to know that, it's gonna take time to make the space for your team to do DevOps, to transform into those next phases. There's gonna be learning. Things might slow down for a while. You really need that support and the space people to do that. If you don't, I think we've seen a lot of data yesterday and today that will help, you know, prove some of the successes that DevOps allows. And then also, Sarah had joined our team a few months before then. She was our Scrum Master, Agilead. And we also realized, I realize that, I realize that I need someone to help me take my team further because I'm still really learning. Sarah had gone on this journey before through lean and DevOps transformation. And so we allocated her to be kind of my full-time partner in learning and taking the team through the journey. So that was very critical, too, to have that support and the person dedicated to that role. So when I joined the team, I spent a lot of time trying to understand where they were. Where were they in their journey, what was working, what was not. And through the retros after I resprint, we had two key pay points that just wouldn't go away. They kept coming up. We had the reality of production. And so continually, the team would make their plan. We'd reserve time for production issues, but they weren't making the sprint goal over and over again. What was happening was they were working on what our customers and what our business needed them to work on. So it's a really terrible place for the team to be in where they're working on what they should be working on. They're doing the highest value thing. But then they're like, wow, we're always having to change this plan. We also had part of our definition of done. We have our development team. We have multiple integration teams that flow after that. Part of our definition of done was we need to do knowledge transfer. We need to do demo with those downstream teams. They're already testing something that we finished a Sprinter two ago. And so we're like, hey, come into the lab. Let us do this demo. Let us have this knowledge transfer. And they're like, I can't even think about that right now. I'm testing this other thing. So we're causing relearning, context switching, all kinds of things just to satisfy this definition of done, which really wasn't serving anybody. And through these retros, I already knew we were going to be doing a value stream, which we'll talk about soon. But I was trying to expose the team to different ideas. And a big part of this evolution is let the team be self-managing. Let them decide their own course. They made the decision that they wanted to be working in flow. And they're like, that sounds awesome, but what does that mean? What does flow mean? And so Suzanne and I met, and this is where with her role evolving, it's less about handing out tasks, but more of the strategy about how do we support the team and setting up those guardrails for the team. This is a really cool point for the team, too, because up until this point, we had really been, I had been and Sarah had been taking the team through this journey and they'd been learning. And this was the first time that they had really stepped up and said, hey, we want to try something different. We want to do this. So that was a very nice step in the process. So what does flow look like? The way we started this experiment was we said for the next three weeks, which was the duration of our sprint, we're not going to do any sprint planning. We're not going to make a plan. We're going to go into this. We need to stick to these rules. At the same time, we decided to change things up and bring on a new tool. We brought on Jura, which is really exciting. We, and not just for this specific development team, we said anybody on our point of sale team, if you're doing a thing, all the things have to be in Jura. So that was a big change for the whole team. And don't forget your change management. Yes, change management. Yes, new tools need that change management, too. Yeah, there was a slide yesterday talking about there's so many new tools, so many change that we shared that the team empathized. The second rule is whip limits. So work in progress. This was not a negotiable thing. This was, if we're doing this, we're sticking very, very tight to whip limits. So we had our top priority or swim lane open for any production or release support issues. The following two were new development, new stories or potentially a spike research kind of things. This has been an interesting one. So I was pushed almost every day for about four months. Can't we have more whip? We're just wasting our time. The thing I would tell you is when you start holding to whip, it's painful. But in that pain of having the team idle at that moment, it's like stopping that line, stopping that end on chord. You need to take those tasks that you might not be able to do. You're ready to do the next thing. The whole team rallies around and moves that. And we've had a huge change in thinking, just in the last month, people are like, actually we're not ready to take on a new story. Let's hold tight. Let's rally around this thing. And we realize now when we have less, we move faster. Cycle time was also our measurement. We've been measuring velocity on the development team. But again, it's important to remember, this is just one piece of our value stream. So we need to look at this from the whole perspective, from the time we start manipulating code until we deploy that out to all stores. We also wanted to say, how do we know we're working on the right things? Everything we work on has to have a value score. And the final two were really fun collaborations. This is where Suzanne and I work a lot together. We knew that the team was going to be doing a value stream. And I think we'll just give you a disclaimer as we talk about our journey. We've done many things. We might not say this is the best order to do them in. I'd probably do a value stream before you switch to flow. But we said that they need to own their value stream and continually improve it. So this is continuous improvement in action. And then also making sure the team knew we will be studying and practicing lean principles. This is a long-term vision. This is a long-term roadmap. So we were moving into that next phase. And also I can't state enough about the whip limits. It was really interesting to see the team go from, we'd still have a bunch of tasks done on one story. They'd want to bring more stories, tasks not done. And they'd want to bring another story in. It happened for months and months before we went through that. And then I think finally they switched and said, no, we don't want to bring more stories in. We're all going to huddle and we're going to swarm and get these things done. So that was really important to do and a great turning point for the team as well. Okay. So when we started our value stream, we wanted to be very, very intentional that this is not a one-day workshop. How many people built a value stream in the room? How many people seen that get rolled up in a corner somewhere? Okay. Nice. It's common. You know, people came and they're like, oh, yeah, I've done this before. I've done this at a workshop before. And I've participated in value streams like that. But we wanted to say we're not here for the day to have some team building, throw some posters on the wall. That's not what this is about. This is step one. And when we talk about value stream, when we first kicked off the team, I think the leadership team had done a high-level value stream, which is great, just knowing where the things were. But something that came up in stand-up almost every day was teams didn't understand what was happening upstream or downstream, task-wise. Like, why is it taking them so long? I don't get it. And so we said, we're going to all sit in the room, everybody that's involved. And we're going to say, here's all the things we're doing and how long it takes. What's our processing time? What's our lead time? All that good stuff. And this was to show the team. We're going next. We're doing this today, but here's our long-term. And we're going to refine those. We're going to take a look at every one of those steps and understand what is the customer value in that. That was our reliable method. After that, we were going to be doing line balancing to find our bottlenecks. So that's adding up the time on every one of those cards per role in the lead time and making sure that we're actually focusing our work, where we should be doing that to make the greatest impact. And then we used a lean problem-solving tool, A3 problem-solving, also a plan to check adjust. And then just do items. There were plenty of those. We were going to be very focused on metrics. So we're using cycle time. We will take a look at our tack time, use control charts, and really take a look at all the unplanned work that's happening. What are our time stealers that are happening? The bottom swin lane is just kind of a brief overview that we will be continually learning and studying together. So we're going to go deep on those principles. We're going to practice Kaizen. And the end is my favorite. We are never done. This is something that we will be working on and continuously improving always. So the first step of that, this is our actual value stream. Part of it up there. You can see some of those cards. We had everybody there. They were working together in new ways. I think a really key thing was we had, again, leadership support. I can't underscore that enough. We had Courtney come in and talk about her experience with past value streams. Suzanne was, I was the facilitator of the session. So every person in that room was somebody who worked on this process. We didn't have anybody that was like, you know, one day facilitator. We all had skin in the game. We had to do this better. And that was a huge difference from past value stream sessions that I participated in. It wasn't just my team. It was also the other teams that we touched. So the business teams, our product owner, the QA team that we ended up past, you know, before it was like hand off, hand off, hand off. So the QA team, the environment management team, the release management team, deployment team. So this was the first time we kind of brought other teams into this process. So what did we get out of that out of that? We learned we have 187 steps in our value stream, which was shocking to everybody. And one thing I tell you as you're going through this, it's really hard to not immediately say, I want to tear half of these off. I don't want to be doing this and that. Hold yourself back from doing that. We also had eight distinct handoffs. And what I mean by that is they were actual cards that said we're going to hand off to X team, X person, however that's happening. We know that there's a slew more in there that we need to improve upon. And cycle time, we had started measuring cycle time. We set a goal for the team. We said we will reduce our cycle time by 20% by the end of our fiscal year, which is in September. And this was just a big aha. We unveiled, we're at 84 days. That's how long it takes for us to get something out to all of our stores. And the team had been measuring velocity on their scrum teams. They were under the assumption they were delivering in around 20 to 25 days. But when you stopped and you really thought about it, the customers don't get it at that point. They don't get that value. And so this was just a fire under the team of like, they weren't happy with 25. And then I tell them it's 84. So that really motivated the team to kind of keep moving. I think it was really eye-opening, too, for all the teams working together to see 187 tasks to get something from beginning to end. And they really saw then what are all those other teams doing. So instead of it was like, well, we do this and then we hand it over to QA and they take X amount of weeks and then it goes to the deployment team and they take X amount of weeks. It was really the first, I think, point where the teams were like it's not kind of us and them, it's really like, oh, we see what you do. We feel your pain. People started having empathy for each other and really kind of came together as more of a one big team. We were all in this together. Absolutely. Okay, so a little retro on our value stream. Do you want to talk about homework? Sure. So Sarah talked a little bit about we had this one day value stream. Well, we also set up to let the team know it wasn't just this one day exercise. I set up sessions every week. I set up never ending two hour a week sessions to continue the work on a value stream and the improvement process. So we were using those sessions for some education and other things and then we also came out of the value stream and we kind of gave our team homework to go do some of the more detailed documentation on the reliable method to outline all the different steps in our value stream tasks and what the business value is. So we tried for a few weeks to kind of get the team to go do that on their own, but it's like, you know, your job at that point you haven't really integrated this continuous improvement into your daily job. So we weren't real successful there. So we said we're going to use those weekly collaboration sessions to bring the teams together and do that. So that was an important learning. It's like especially when you're new moving into these routines, use the collaboration sessions to have the team work together. And we did use writer driver method for that. So if it was your process, you weren't allowed to document it. Somebody else had to document that. And there were a lot of amazing questions and just discussion that really happened in that. And at that point we saw some cards moving from our value stream of like, oh actually that's not really happening anymore or oh it's longer than I thought it was. So it was a great learning, but it took us a while. Nobody wanted to do it. The next one is there's no place in your value stream for aspirations, fantasy, all your hopes and dreams of the way that you want your process to go. Keep it reality. Please check that over and over again. People have a tendency, especially if they're bosses in the room, of like oh here's the stuff I know I'm supposed to do, but are you actually doing it? Maybe not. So really check that. And then timing is important too. Yeah so we had started our value stream right before the holidays and we discovered that it's really not the best time to start some new process because we didn't give the team enough time again to kind of build some of those habits, make it real. So people went on vacation, the holiday came back and we really lost the momentum. So if you're going to start one of these exercises or any kind of new journey or transformation I would say make sure you give yourself at least a month or two before there is some type of big holiday or break or something going on that's going to take you away from that. Yeah even though the team was begging to do the session just pause. Alright so I wanted to bring you back to where we are today. Again remember we did our value stream, we had that first session in December. So it's still very new. But looking at this long road map we sped through the first four steps. We are currently at the A3 problem solving and that's a, really would just refer to the paper size, but it goes through root cause analysis on what that is and where we've been focusing that work is we did our line balance so we found out where the bottleneck in our value stream was. And we have a large group working together. We broke them into three different teams representing functions from all of those teams and said you guys get to go and experiment now. This is the fun part. We've had a lot of energy there. People are attacking that bottleneck and coming up with countermeasures that they want to do. Some of them have been around. We're going to try to improve our architecture because that's a blocker for us. We're going to experiment with all these different things. So that's been fun, but we have to remind the team like we're going to be here for a while. We're going to be in this space for probably one to two years and to keep that motivation and learning happening. We'll continually check our line because maybe hopefully we reduce our bottleneck fast and we attack whatever's next. That's where we are today. This is a really fun phase to be in because as we went through that value stream and people saw the 187 steps there was a lot of anxiety and frustration around that and people wanted to attack it right away. So it took us a couple more steps to get there but then when we had the first session of identifying what are the things that we think are the biggest things that we can make small bites, improvements on. People got really excited and the team came together and collaborated, came up with some great ideas and so that's a very exciting part, I think, of the journey. Yeah, and that's why I can't stress enough. It's so important to do these steps to understand where you are driving your experiments from. They should be driving it at reducing your bottleneck instead of any part that's passionate. People are passionate about on your value stream because you're just not going to see those results. You don't want to inject chaos into your system by having 100 experiments running because if we had just said yes to everything there would probably be 100 experiments running. So I can keep that limited. And some of the ways that we have found to really keep team engagement up and what's been working for us and that we're continuing to work on is our early adopters. And I can see, when I went to the DevOps Summit forum last November in San Francisco I came back super jazzed from that so that really built excitement so I think these types of events are great for people and I tried to encourage my team. Read the Phoenix project, read the DevOps handbook. Here's some different other learnings you can do. So I think that's really important for leaders to do is to make sure that you're allowing time for your team to learn these things. So make that space. Make the space and try to make space for that in your daily work. I mean it's great when a few of us can come here and be in this amazing room where we're all like, yes, I want to learn more and yeah, there might be free beer. You don't have that in your office maybe every day. So it's something like look for those people who are genuinely excited. Find ways to involve them. Help them grow, invest in those people and people are attracted to results. So every time you can use data to say, hey, here's improvement that we've had people will come, people will notice when these changes are happening and it will help grow your movement. Okay, so we've been at this for about four months of data. We had 187 steps in our value stream and we are now down to 133. Yay! That's really exciting and that continues to come down. So there's continual experimentation happening on that and the team's pretty just about it. The next one is our distinct handoffs are now down to six. This is an area where we can really look to improve in some big ways. Some of this is really due to the rules that we've set up for our team. So we're starting to take a hard look at that of how can we influence that. And our cycle time, we are trending down. We don't release a huge number of features. So like math, it takes so long to move that number. I know our recent features that we have completed, they've been around 50 to 54 days. So the team is feeling really, really good about the progress that they're making. So that's looking great. Where we go from here, we're continuing our journey. So we are in that A3 problem solving piece. We have three very pretty big experiments happening right now around refactoring, around team changes and communication. So that's been exciting to see. We've also had the fortune of being able to get a Dora assessment, which is amazing. If you guys have the opportunity to do that, we got our results from the coal forescreen a few weeks ago. So we have time set up I think next week. Can't wait to do that. And then walk through the team. Yeah, through the team. The team completed some assessments on that, answered questions. And then that gave us data back to say, what areas can we make movement on and influence to see the greatest change in our organization quickly. So we'll be doing that with the team next. So hopefully we've given, hopefully between Jez and our talk, we've given you some faith. If you have these big, complex systems, we do too. You can do this. You can do this. Let's do this together. And if you're asking where to start, if you haven't already gone through the Agile journey, that's definitely a great foundation. To move further in DevOps, you kind of really already need to be at the Agile state. Yeah, and it's, please keep moving, commit, and say that you're staying in the course and reach out for help. It's not DevOps without sharing. So we look forward to figuring out together. Thank you.