Catherine Cartwright is currently a portfolio/ solution Agile Coach at CVS Health. After a few years as a Design Program Coach, she became passionate about solving for Design in SAFe, joining forces with Lys Maitland and James McElroy, as well as experimenting with others to enable human centered design practices to thrive in a scaled agile context.
Transcript
*transcribed using ai, please excuse any grammar and spelling mistakes
Luke Hohmann 00:04
Hi everyone, and welcome to our webinar asked me anything which is kind of different for a webinar because normally a webinars like we're just going to share a lot of information. In this case, we're going to let you ask us anything. And to frame this I want to kind of recap where we've been and where we're going. On the line with me I have James McElroy, who is in the design leader and design program at CVS have got at Lys Maitland who's in UX research and UX design at CVS. And I've got Catherine Cartwright whose title is extremely elusive to figure out because she seems to be doing lots of things everywhere. And I admire that because Catherine's, I think, an embodiment of the kind of people who add positive energy into systems that need it. And so she's just an energy generator, and I'm just gonna be excited about that. My name is Luke Hohmann. I'm a SAFe fellow. I'm the Chief Innovation Officer at Applied Frameworks. And I am delighted to share that I got to work with all of these wonderful people and the topic that we're going to talk about. In our first webinar, James gave us a really interesting and very powerful, I think, personal history of his relationship with SAFe and by closure. Catherine and Lys’s, and my myself and many of our relationships with SAFe when I got involved with SAFe, it really didn't have customer centricity and design thinking as a prominent part of the framework. And I was among the people who on the framework team worked to bring that forward. But we have more work to do. And the CVS team really helped advance this. Where we ended up in that first webinar was we kind of got a little rushed in our detailed exploration of how CVS really did extend the framework and integrate design, thinking and design practices into SAFe along with designers. And that's an important point. So what we're going to do today is we're going to take about 10 minutes to start with the approach of CVS that James had outlined. Let James kind of put a little bit more effort into that, and let you reset your own mind about where were we with CVS, and then we'll have about 40 to 45 minutes to do and ask us anything. And we mean that you could ask me about how to make a proper Margarita, I have a YouTube video on that. You get also asked me about things about agile and SAFe, I might know something there too. You can ask Catherine and about implementation of trains and large scale integrations and some of the finer details. And she might even have some bonus content that we may leverage. And of course, you can ask at Lys and James about design. So with that, James, I'm going to go ahead and share my screen or wanted to share your screen. I was gonna say let's pick up with the our approach. And when you want me to advance, just say next, and I'll go ahead and advance.
James McElroy 03:18
Sounds good, sir. Hello, everyone. So this slide was really kind of explaining that what we've done over the last several years, is really I would describe it as just kind of a slight extension of what SAFe has already been saying. And I think one of the things that Lys, Catherine I found is, while many people when you look at SAFe at first glance, the design is kind of hard to find, so to speak, the more we looked at this, we kind of realized it's actually there, it's just maybe not as apparent as we all might think. And so if you've gone through SAFe training, there's an entire article about intentional architecture. And it kind of it's really just the way I've described that is it's setting the case making the case for something that often doesn't exist in Agile, which is the idea of doing things that is not just cranking out code every minute of the day. I think it's very easy to misunderstand Agile to be, you know, if it's not code, it's it's not moving the ship forward, the train forward, I guess. And so we kind of use that as our foundation point. And intentional architecture is actually something we started talking about after we got questions about it. And, Catherine, I'm guessing we had some architects in our training that we were asked about that early on, I don't think I've ever been asked about that intentional architecture again. So it may have been that we had some ringers in our early audiences that were pushing us to get into that topic. Because I do find that sometimes people's eyes kind of glaze over we talked about that. But if we move forward from that, architecture is embedded in the SAFe there's entire training courses in SAFe about architecture. And really this middle column was kind of our our stand tear, which is say, hey, look, design is also a form of architecture just instead of architecting code, or architecting experiences and for many companies, ourselves included, that's not just software experiences, it's in store experiences, its call center experiences, it's, you know, increasingly, it's chatbot, and other forms of, you know, AI based technology. And then the third piece is kind of just our, our pitch in a sense, which is to say, SAFe already has these principles. They've been there all along, they tend to be written in terms of software, and we've just kind of explained without adding new principles to save, and just really clarifying the existing ones design actually has a really good home and safe and designers specifically. So that's kind of the approach that we took here. These are California if you'd want to add anything to that.
Catherine Cartwright 05:53
No, I think that's great. Just to add it, you know, we're also aware of, you know, Jomon tableaus work the human centered, agile and Bradley men, and I call it the research runway. So we think of very much using that in parallel the design and research runway as well, or with the idea of emergence as well as intentional design.
James McElroy 06:13
Yeah, I think that's a really good point, like many design teams we've talked to, outside of CVS have come up with very similar conclusions. So it's, it's not like we've come up with this miraculous invention here that came out of thin air, it's really if you, if you follow the principles, this, I mean, it's emergent, right? It actually kind of like, oh, wow, this totally makes sense. And then this is really where we put that into practice. So architectural runway. Again, this is directly out of SAFe articles, it's formatted a little bit easier to kind of see here in SAFe defines architectural runway in this way. And so we obviously are often looking for near term features like that's, I'm dealing with this right now, people are always eager to get features out the door, right. That's ultimately how you deliver things to your customers. But the idea of the architectural runway, is that you need to do you need to invest in the future for near term features to be able to get produced without redesign and delay is how SAFe terms it and so the architectural runway, as it's traditionally been defined in SAFe is code components and technical infrastructure. And the reason we invest in this runway is to have that foundation in the foundation you're building, you're building that runway, for business initiatives, or for new features and capabilities. And so in the next slide, what we just ended up doing here is saying, yes, we agree with this, this is typically a kind of a more software based point of view. And we're not saying that's wrong, we're just saying that there's other aspects to this. And so the next slide, what we show here, is if you clarify this, and you just extend this, this applies to design or UX, which is, you know, where Lys and I live, and then Catherine is one of our greatest supporters. And so, the code components are tattling infrastructure. Yes, if you're a software architect, that is the kind of thing you're building in runway, as designers at CVS, the things we're building it with runway, our discovery insights, and discovery is really about understanding what problem you have what users customers have that problem, user research findings. And so Lys’s team has an amazing repertoire of of activities that they can do to help us uncover various aspects of what our customers are trying to do. And then design deliverables are really the things you know, this is mockups, right? So if you're a UX designer, UI designer, this is the stuff that typically we're known for. It's the thing that people outside of design often think it's the only thing we do is draw pictures, essentially. And part of our point is for designers to explain, yes, we do draw pictures, that's part of our job, just like an architect draws a blueprint of the building. But just like an architect, a building, there's a lot of work that happens before you ever put pen to paper to design, that ultimate experience. And so that's the kind of thing we're doing. And then uses of enablers is, again, this is the SAFe definition. So if we click through this, that kind of shows, software review has this. And our clarification here is that in addition to infrastructure is like infrastructure for software, it might be you know, your code repos, it might be getting various technologies into place to make it easy to share code. On our side. We're doing things like discovering those needs validating hypotheses. One of the things I think Lys, Catherine have talked about a lot with SAFe that we love is the emphasis on validating hypotheses, it's acknowledging that we're making educated guesses. And so we try to structure our design activities. Based on its hypothesis, if we build this feature, this user experience addition to this product, what behavior will we see as result that if we can't answer that question, it really suggests we're not ready to try I have a new feature because we're not sure what we're trying to get out of it. So that's kind of how we're doing that. And then SAFe gave us these enablers already. And so what we just said is, okay, let's drill down into exploration enablers. They really describe what we do in design already. And we have adapted exploration enablers, because what we found is that discovery and design are two different design activities. And they're both critical. But we found our development and product partners often got confused, if we were carving out an enabler, which is a chunk of time and SAFe, right and a sprint, they kind of magically expected us to always come up with a mock up, no matter what we're doing. And so the reason we ended up coming up with the discovery enabler as a term was to say, hey, if we're not sure what problem we're solving, you don't actually want us to do a mock up, because we're just wasting time and money. Assuming that there's a problem to be solved here. That's instead spend that time and talk to our customers that are said, what problems do they really have, we may conclude that you know what, there's nothing for us to do here, let's move on. Or maybe it's the problem they have is a totally different one than we originally thought. So that was kind of why we did the two. And this is how we describe the difference. So discovery is all about understanding the problem. Design is all about how are we going to solve the problem. And we mentioned this last time, but to really re emphasize this, we're not saying you have to rediscover every time you do design work, there's many things that our teams work on, we have a painfully clear understanding of the challenge we're trying to solve, right? It could be a problem that's existed for years and years and healthcare or elsewhere. We're just saying if we're not sure, a little time spent there saves a lot of time and money in the long run, because we're not chasing solutions, and we don't understand the problem. And so that's kind of how we find those. And then business features. Of course, what we found in our environment is everything was kind of a feature early on enablers just kind of like, yeah, I read about that stuff. But it features where his hat, like we got to crank out code. And so we kind of put this slide together to say, yes, ultimately, we're doing business features, as well. We're partnering with our dev teams to get code out the door into our customers hands. This is how those three things fit together. And so from a design perspective, specifically, we're still doing some design work the business feature stage, but it tends to be really fine tuning the details. And so if you're coming at this, from a design point of view, we would say the majority, I don't know 80% plus or minus is of design work is happening and discovery and design. enablers that mix will vary depending on working on this, this feature may be all the design work if you're just tweaking a really minor piece. So it really depends on what you're trying to solve for. And then the famous double diamond, we loved that SAFe adopted the Double Diamond, we actually went back and looked at the original research, which is fascinating. If you haven't seen it from the UX Council. I think Luke inspired me to do this, because Luke is always going back to the original source for material. And we went back to the original sources, we found this is very often misunderstood. In the design world, you have triple diamonds, quadruple diamonds, diamonds with arrows and loops and everything. And it occurred to us that maybe people don't understand what this was meant to be. And if you go back to the source, all the double diamond is really meant to be as a generic description of how design works across the world, at any company in any domain hardware, or software, etc. And I think when we started to look at it in that lens, it's not meant to be a prescriptive, definitive, every single thing you do in design, it's really meant to be Hey, if you're trying to explain design to someone who doesn't understand it, this is a kind of good way to do it. And so that's what we use this for. So okay, let's not reinvent the double diamond and add diamonds and circles and squares. As we've seen other places, too. We just simply mapped those three concepts we had into the double diamond. So discovery enabler is roughly speaking, understanding the problem. Design is roughly roughly speaking, developing, development can be confusing and the design sense because that often implies code. But development in this sense is really meaning you're developing the design, you're developing the solution, you're exploring many different ways to do it, and then deliver for us. The bulk of coding, if you think about this, from a software perspective, typically happens in the business feature phase. We had
Luke Hohmann 14:08
been in this too, because one of the inspirations for the Double Diamond was going back all the way to pointless famous book, how to solve it, which was originally about math, but about problem solving in general. And the Double Diamond also is very aligned with cognitive psychology and Carl Wykes perspective of sensemaking. So the double diamond to your point, which I'm glad you brought up it, the deeper roots are grounded in just human psychology and human cognition and human problem solving. And what we find is that, as you said, when people had three or four or five diamonds, they're actually starting to hide behind the power of the simple structure. And you see the hexagon In the flows in the circles and etceteras. But there's also I think, a linearity to this process that is actually quite important for people to realize is that the the Double Diamond can be applied many times, but it's still a linear process in terms of their rigor. And yeah, of course, there's going to be some swirling back and forth, as I'm engaged in developing the solution, I might find I have to go back and do a little bit more discovery. But the reality is, is that we want to have this progression. So for everyone who's listening, if you have a question about the double diamond or that background, again, feel free to ask it because this is this is kind of one of those foundational structures within SAFe. And we did want to honor the original writing and the original work on the Double Diamond when we were working with SAFe.
James McElroy 15:58
Yeah, and then the other thing we've we've had a lot of discussion about internally is this whole sense of timing of enablers. And it was really interesting, when we first started getting these conversations, a lot of the pushback we got is, well, you're just going back to waterfall, you're saying I have to do this, before I do this. And we tried to really change that on a test said, Well, you don't have to do it that way. Like you can jump to a solution and plan out your entire dev work, before you understand what the problem is, if you want to do that. Sure, go ahead. But I think it was really interesting to try to, you know, rather than defend this, say, look, it's your business, you can do whatever you want to do, just realize that if you're making all these assumptions, you're potentially throwing away a lot of time and money by doing a plan that you gotta throw out when you realize, you know, what, we don't need to go after that problem at all. And so that's kind of the idea here. And it's really based on risk, right? Sometimes the risk is very low. And you might want to plan out par in advance, sometimes the risk is high. And it might make sense not to do that. And then this is our inspired by Luke will say about where designers sit and safe, this will be different for every company. And actually, this is different. When we presented this in the summer, it's not quite the same now. Right? You know, organizations evolve. And so if I was to draw this again, with, you know, with Lys, we would probably do it a little bit differently. But the gist of this remains the same, which is, in our scale, and this is where SAFe, really excels. And my experience is scaling to large organizations. Really all we did here say okay, how do we partner with our product Dev and architecture, folks to help them throughout the SAFe journey. And so again, the names here can be different. But the idea is that if you have a solution architect or Enterprise Architect up at the top here, we want to have someone for them to talk to you from our org. And it's going to be a different person than a designer on a team. But we're all linked together, we have a shared design team. And so there's that continued that continuity. And then these are the things that we found work for us. And again, you know, your mileage may vary. But what I think many of these are pretty universal. Partnering with product and architecture. It mean, no matter what flavor of agile, you talk about, this is such a critical part, right? Like the whole idea is collaboration. And working together that are enablers are aligned to there's the hypothesis and benefit hypothesis statements I feel like this comes straight out of it's a big part of the Lean UX book, it's a big part of what's built in the SAFe. It's one of my favorite parts. It's helping us remember that we're again, we're making educated guesses, and let's test those guesses before we spend a lot of time and money on them. You know, we talked about using enablers to reduce risk. And the whole idea that we talked about last time is learning fast, there's things we can do to learn, that don't require us to get code out to market, there's things you do need to get to market to learn. But there's a lot of stuff you don't need to get that far. Multiple time horizons is a really important part of design, you know, ranging from a text fix that we could make in a few minutes to redeveloping an entire workflow for our colleagues that might take years to fully work through. And then aligning our enablers with our architecture team.
Luke Hohmann 19:23
All right. Let's talk about how you put it into practice just to ground people in this and then we'll have a good amount of time for q&a.
James McElroy 19:33
Yeah, so this is a timely example. Because we're back into vaccine season again, I just used this app yesterday, actually to get my daughter vaccinated.
Luke Hohmann 19:41
My vaccines last week. There you
James McElroy 19:45
Yeah. So. So this was a crazy project. So if you've, if you go back in time, if we had little music and the wavy lines, if we go back in time to when COVID was was, you know, around the world and there was no vaccine. The federal government had a product called on a project warp speed with a four star general that was in charge of it, a general Perna, and the government was getting ready to, you know, to give huge quantities of vaccines to CVS and Walgreens and other large scale companies that could get it out to the, to the world as quickly as possible or to US as quickly as possible. And so in a way, you kind of argue like, well, this isn't SAFe at all, you've got, you know, you don't have any control over this project, you're being given, you know, essentially a deadline and other things like that. A lot of that was true, like we were being dictated in other companies to basically the White House was literally telling us, hey, you've got to do this by certain date, you've got to have these features, etc. So it was unlike anything else we'd ever done before. But at the same time, we had these principles, they're like, well, these principles still make sense, right. And so even though COVID was a brand new vaccine, we've been getting flu shots for years, right? So it's like, well, it's not brand brand new. It's just a different type of vaccine, different requirements, etc. And we had a design team that was already doing work. And so we basically set up a discovery enabler where we started with just working with our store teams, or the whole goal of vaccine schedulers, whether your us or our competitors, is essentially to minimize the burden of your store, your store staff, right, the store staff is generally really overburdened, they're staffing shortages, the less they can spend time doing paperwork, the more they can spend time giving people shots, which is really what they're coming to us to get. And so the service blueprinting was amazing. We sat down with people that ran our stores, and literally walked through every single step like walking into the store, like what happens, you walk into a store, where do you go, like who tells you to go to the back of the store, etc. And those service blueprints, Again, like in a, in a traditional agile process, we weren't doing designs, there's no design at all. We're literally just talking to the workflow. And I think in the past, we would have gotten pressured to not do that, like, well, you guys aren't doing mock ups, why aren't you doing mock ups, you know, go design mock ups, but we had tremendously supportive leadership that understood that if we didn't understand those workflows, it didn't matter. Like there's no point in doing this mock ups. And we actually did workflows for multiple different permutations, you know, back then we didn't know how many shots you would get. We didn't know a number of other things. And so we had multiple versions. It was interesting as this is exactly what the federal government did with the vaccine, it's very expensive to come up and try multiple things at the same time, like the vaccine obviously was very expensive. And one of the reasons it went so quickly is that there's multiple bets being placed at the same time, we basically did the same thing with UX design, we took the time and money to to do multiple different permutations, we normally wouldn't do that it's generally too expensive. But in this case, it was exactly what was needed. And then as we started to get those details flushed out, we're starting from scratch, like, okay, the government picks path one we're going to, we'll take up that now we'll translate its design. We did design and labelers. To create that into interactive prototypes. We actually shared that with, you know, people very high up in the government. And that prototype helped everyone understand like, Yeah, we actually have thought this through, we know how this is going to work down to the level of detail of how you sign up for the shot. And by the time we got up to the features, we had so much of this work done. And this is truly the benefit of enablers, we had basically done all of this work. So that by the time we started coding, we we had a much better sense, and we'd minimize that risk zone. And so if you go ahead, I think in the slide, it just kind of shows a screenshot from the scheduler, maybe it doesn't, if it's not, oh, I think I sent you the PDF sorry, in the PowerPoint that just scrolls. And so it, we had really good results to that, and got some great press for that. It was an I think the thing to really emphasize here too, is it was not the design team working in a silo, it was designed team working with engineering, working with product with research Lys’s team, like everyone that needed to be part of this came together. And it was an amazing project to be part of because the impact was was huge.
Luke Hohmann 24:00
Okay, cool. So we're at our point where we look at some challenges, and then we'll bring it home with the q&a. So some of the challenges that you faced were this notion of how do you communicate during things like safe rituals, the system demo? What your work is?
James McElroy 24:20
Yeah, and these are, these aren't exact quotes, because these go back years and years and time, but these are pretty close at paraphrases. Right? And the other context setting is we adopted SAFe in a roughly a year across a four to 5000 person, org. So what does that look like? What means a whole bunch of people getting trained and SAFe at the same time? We probably called like every safe trainer that was available in a 3000 mile radius, right, and we're doing it simultaneously. And so the challenge with that is we were having trainers that had just been trained themselves, right and so no fault of their own, but when you've just been trained you kind of go by the book because that's all You know, and so these are the kinds of comments we kept getting from folks and well intentioned, we, you know, we had nothing against them personally. But they were kind of saying things like, Okay, if we look at what's in italics here, the system demo, it's kind of like you have a substitute teacher and they go look in the book. Well, what's the answer? Well, the answer in the book is, it's a production like environment. That sounds like code. And so we had people saying, well, the book says, It's code, you can't demo stuff that's not code. And you know, we'd politely raise our hands like you would with a substitute name and say, well, actually, there's value into this. And so part of what we started to do is turn the discussion away from what the book says, literally, two, what's the intent behind the book? And so with demos, we kind of explained, well, you probably want us to demo what our experience is going to look like. Because that will help you answer questions before you write code. The next slide has similar objections that we had related to PI objectives. And so again, that italics is what people were kind of getting out of the book, so to speak. You know, PI objectives are summarized the business technical goals, it doesn't say design goals. And so again, we made a case like, well, design goals are important too. And actually, one of the best things for this is our leader started asking us, you know, hey, can you know, we had VPs of product? For example, say, can you talk about your design goals? And, you know, when your product partner is asking if he gets, you know, other folks say, Well, I guess the product wants to know, that must be okay. So the objectives that kind of goal, or that conflict went away. And then I think the last one was about readouts. And again, you know, designers can presented readouts. And again, there's nothing in the book that says you can or can't, but it was interpreted as it doesn't make sense for us. But it was really the more we did this, the more people wanted to hear from us. And so it was great, where it was no longer us lobbying to be heard. It was our customers, our product partners saying, hey, like, they're doing some enablers stuff there. Let's hear about it. Like, what are your objectives? What do you want to talk about in the readout, so you know, these objectives. And then the waterfall like waiting a PI to code will just slow us down. And the next slide is kind of our answer to this specific one. Again, like I mentioned this earlier, we, we said you like you don't need to wait PI, you can go right ahead and do it. But if you remember the deck that we talked about, for this whole talk, this whole idea of risks and assumptions. And so we really tried to explain the value of what we're doing in terms of minimizing those risks and validating those assumptions. And so it's really a way to go faster, it seems slower, because you're spreading it over time. But you're able to make much more efficient decisions with your time as you do this. And so for us these objectives, or objections, I should say, spaced out, I don't know, many, many months. And these were objections, really, on the CVS side, again, you know, Aetna had been doing SAFe long before CVS acquired them. And then this was really just how we wrapped up our summary from, you know, from the talk, you know, designers we believe, bring tremendous value to companies, we've been doing design for decades, obviously, you know, we're passionate about it, we do recommend embedding them in every aspect of SAFe if and that's kind of that picture that showed the designers around the big picture. enablers are really just a tool to do something designed to stand for decades, which is to learn quickly through experimentation and iteration. Lean UX, in our experience, fits really well with the principles of SAFe the focus on experimentation. And then just some tips, if you've, if you're in an org that doesn't have a designer, we found, you know, through first hand experience, and you just want to make sure, if you're in a big company, which is typically the case, if you're following SAFe, it can be an acquired taste for design, or some designers love the challenge of enterprise. Others do not there's nothing wrong with that. But we've learned to get pretty good about letting people know what they're in for when you come to do design at scale. It's very unlike a startup. And then agencies, of course, agencies often are in business to, to, you know, to get into your organization and never leave. And so what we recommend is you don't need to do that with design. There's plenty of designers out there. And there's there's agencies that will help you get to that state. And I've worked with companies like that in the past.
Luke Hohmann 29:03
All right. Well, the summary is that CVS and the design team were quite effective in enabling or not enabling I'm using the word enabling because it's on the screen and it's got me but they but they were they were extraordinarily effective at using the constructs and principles of SAFe to to more effectively bring design and Lys. And we've got some suggested reading Marty Kagan shout out to Marty. He lives in the same city. I do Sunnyvale, California. And he's a great guy. And Jeff Gottschall, and Josh Eden, Lean UX. Again, shout out to another great book, but I want to I want to add one more reading. We'll make sure that these are available, but I want to go ahead and and now I'm going to stop sharing because we're going to, instead of sharing our learnings, we're going to talk but at Lys I've got I've got A shout out for you right off the bat. And one of the questions that has come up. And this is selfish, because one of one of the people in my product management classes asked this, and you know how I love to have people in my classes, like really engage? But the question was this, from the design thinking community's perspective, what? And it's a two part question. What is the distinction between a service blueprint and a journey map? And do I need both?
Lys Maitland 30:37
That is actually a great question that we've been talking a lot around here. Service Blueprinting is a complete discipline unto itself, it is different than journey mapping service. And I'm not an expert in service blueprinting, I actually have somebody on my team who has a master's in service design. But one of the really, I can actually pull up a definition because we were trying to like make sure that we could really articulate this to our own our teams as well. But surface blueprints allow you to really look at the front of house and back of house interactions, which journey maps are usually about the users experience, not everything that's happening behind the stage, the systems and all of the different pieces that go into the interactions are some of the things that you might that you might encounter outside of the journey map. So when we're looking at those differences, journey maps, we're really looking at, not necessarily like the back end processes, we're looking at, like, what's the experience? What are the opportunities? What are the thoughts and feelings for those people? versus what is it that they're going through? What are all the touch points and what's happening behind the scenes for them as well, and I can pull up the definition that we actually just published recently. And that kind of talks about the difference to you know,
Luke Hohmann 31:50
I, the way I described it was a little similar. And I said, in my experience, service, blueprints are still in that more factual orientation. Whereas the customer journey map, you really are trying to understand the the emotions, the feelings, the opportunities, and the opportunities aren't, in the sense these cold business opportunities, but these opportunities to make something perhaps more comfortable for a customer or create a different experience. But now we got another problem, because we've got a third thing in this world in this interaction, and that's called the operational value stream. And so how if we if we look at the safecontractor, construct of operational and development value streams, we've got service blueprints and journey maps. So now, how would you extend this? And we can throw in Katherine or James, how would you expand extend this to include the distinction between a service blueprint and say, an operational value stream?
Catherine Cartwright 33:00
Oh, one piece, while James and Lys are thinking about it is like, we would love to see our agile release trains formed around our user journeys, and or clear, distinct products. So so that we can ask our, our experts or cross functional experts to have full ownership over products or experiences. So I'm not sure if that's where you're going. James or Lys, if you'd like to add?
James McElroy 33:23
Yeah, I mean, the the, the, the development value stream, of course, if I'm very much from an early terminology correctly, is really like how you deliver the products, the services to your trains, right. And to Catherine's point. I think we often see companies arrange those more on org structure, you know, rather than what what Catherine was just saying, which is more on the customer workflow. To me, the, the, and I always forget the name, the other one, the operational value stream, is that the right one? Does the development and operational I think, right, yeah, the operation one, I think is, is very similar to the customer journey map and or service blueprint that I think there's like, we have three different ways of describing some overlapping concepts, but we haven't maybe necessarily disambiguated that it. Maybe that's an opportunity, right, is to kind of do a little article on how they different how they're similar.
Luke Hohmann 34:24
Yeah, I think that would be useful. I, I also think that the when you look at the SAFe content, you'll see in the continuous delivery pipeline article. And it's definitely limited to say for limited in SAFe too, things like process mapping and steps and workflows. And I do think that that's where that service blueprint comes into play, right? Because it is this diagram that lists the service delivery the activities, but we can extend that to things like delays and our Lean thinking and percent complete, accurate and some of the other info that helps us design efficient systems that also serve our customers needs. Next question,
Lys Maitland 35:11
interject really quickly, I stuck our definitions in the chat about service blueprint and customer journey map. And I'd like to say that I think one of the really nice things about both these things is that it gives you a broader viewpoint, then what we usually end up with when we get into SAFe and we get into solutions, portfolios, teams, and all of the ways that we start to fracture down so we can actually perform the work, service blueprints, customer journey maps, go across the silos and allow you to think about the customer's experience holistically, instead of how are we going to deliver this, who owns this part of the product? Who owns these different pieces within the company and allows you to think about it in a more customer centric way?
Luke Hohmann 35:50
Yeah, and Catherine, I think, in an organization, as complex and largest CVS and by closure other larger, more complex organizations, I think it is a good goal to have ARTs and trains formed around solutions so that you can get this notion of a more complete ownership. But I think the reality is, is that I'm interacting with CVS in multiple roles and in multiple dimensions. And I'm not expecting as a consumer for CVS to have, you know, in The Lord of the Rings, one ring to bind them all. But I am expecting that there is a certain level of consistency. So I'm going to toss this back into the world of, of governance. And, and James and Lys and Catherine are because we've we've worked together they know that I'm a big fan of governance and how governance is actually not a restrictor, but an enabler. Because if I have the right kind of governance, I can further decentralize decision making with trust to the teams. So so for you three, could you talk a little bit about the role of governance, and its, and how it's emerging? As, as you further institutionalized design and safe at CVS? What, what kind of governance is are you finding useful? And how is that being manifested?
James McElroy 37:26
Catherine, I wonder if you want to start on this one. I feel like your team is doing a lot of great work in this area.
Catherine Cartwright 37:32
Yeah. I actually would love for to take it to the question around LPM. But James, I think that you and the design system and enablement team, from that perspective, do do an address some guardrails, and then I can talk about?
James McElroy 37:45
Yes. So I'm, so I was involved in the COVID vaccine thing several years ago. And now I'm focusing more on our design system. And so you know, design systems are basically reusable components of code and design. It's kind of the Lego blocks essentially that that build up apps and websites. And one of the things as soon as you get anywhere close to a design system is you realize that governance is it's, you can't separate it from standards, right? Because you're getting into who gets to decide what the standards are who, you know, who gets input into those standards, if you don't agree on the standards, who gets to weigh in on those. And so, we are actually working across multiple organizations right now. We've agreed that we want to unify our design standards, it just makes sense. Like, you know, why rebuild things over and over again, you can save time and money and focus on on more innovation. That's the easy part, I'd say the hardest part is figuring out, you know, how do we get alignment. And you know, with large companies, you often have many different standards. There's a great cartoon that I'm fond of, which is two people get together and say, Hey, there's 13 different standards in the world, we need to come up with the use cases, so we can get to a unified standard. And then there's a few spots of time go by, and then you end up with 14 standards instead of 13. Right? So there's, it's very easy to just keep coming up with more and more standards rather than getting people aligned. But LPM is one of the things that we've been looking towards. And so we've had a lot of support. Yeah, thanks, Peter for the cartoon. XKCD is great cartoons for UX folks. And so a lot of the ideas behind LPM have been really valuable. It's kind of making that case for why you want to get alignment at the top for certain decisions, like a design system. You know, you could have 15 different systems if you wanted to. And so it's something we're still I would say we're still maturing with but we've seen a lot of a lot of interest in those concepts.
Luke Hohmann 39:48
And I think that that's an important point about the role of leadership now. I I would actually say that I don't think of LPM as being the the right organizational construct to provide governance over either technical arenas, which I would more associate with the enterprise or system architect, or designer arenas, which I would associate with the design team that that hierarchy that you showed in how we integrate designers and design thinking and SAFe. I, I want LPM to kind of support that work, but I don't want them to be doing that work. And I think that that distinction is an important one. Now, in SAFe, enablers are things that create some form of a runway, and we've various kinds of architectural and technical runways. And enablers come in different sizes. They're the small enablers where, say a development team might upgrade their, their their testing infrastructure. There's the medium enablers where an ART might decide, collectively as an ART to upgrade or do some kind of technical thing. And then there's the really big enablers, which I would presume would require some form of portfolio awareness, if not approval. And that might be the when you were talking about the vaccine schedule, are we really want to understand and make an investment in the complexity of the different vaccines that are coming. So Catherine, we've got a question about how do you deal with the enablers regarding the LPM epic flow? If we're going to say that we have these enablers of the kind that we talked about? What place does lpm get involved in when should LPM not get involved?
Catherine Cartwright: 41:44
So so I'd like to qualify now that you're thinking of LPM across from its its ideal state. But in our example, we, the way we think about the epic workflow, something that has been really, really useful in our organization is this construct of epic teams, epic teams, you can think of this idea of creating cross discipline collaboration around a product into what Lys had said, the same value that service blueprints, create epic teams allow us to keep a radical customer centricity on a solution that might need across multiple trains. And so during when something because I see that Stephen had a question, when the work comes into reviewing and analyzing, we want to define the epic hypothesis as a hypothesis, and define our outcome metrics. But design might have a lot of experimentation to do in that space. And so that that would be it is discovery enabler. So those discovery enablers might even exist before we realize that we have an epic. And so that can be how discovery work, experimentation enablers. design artifacts, can can enable the refinement of an epic, and then connect those things together. But that doesn't mean that when the work gets to the train, that there's not still design thinking for the train to do in our local context. So so to connect it back to the idea about governance. If we put a design person on each epic team, and we're building something very large, we can then take those representatives and have a governance conversation around the experience between these multiple epics and their intersection points. So that's something that the design discipline would own architecture would own to ensure they're taking care to ensure that the right design principles, guardrails and design system components would be leveraged.
Luke Hohmann 43:46
Yeah, I think that that's an interesting answer. You the the curious look on my face is that you kind of threw me with the concept of an epic team. And sometimes crazy, SAFe can be criticized for oh, I got a team for this. And I got a team for that. What what challenge for a large organization is an epic team solving.
Catherine Cartwright: 44:13
So an epic team to how Lysmentioned that we have multiple different we can't always organize our agile release trains around a user experience. Sometimes we have capabilities such as chat or conversational AI. Those things need to be consumed in order to create a holistic user experience. Creating an epic team is something that we've really developed that I think that meets that need for a holistic solution development that crosses multiple value streams, and may need to consume multiple capabilities to deliver an end to end experience.
Luke Hohmann 44:50
Got it? I think usually, go ahead.
Catherine Cartwright 44:54
So one more piece we usually think of them as including the three legged stool design Engineering, Architecture and product analytics are also incredibly important because if we're going to instrument to measure outcomes, we want to include those folks.
Luke Hohmann 45:11
Well, Stefan is continuing the conversation with this, Catherine, which is really lovely. And that he they further requests that. So would you pull a enabler through the LPM flow at this stage? Or just do the invest in the Analyze stage? And so the supposition here is that someone is using a portfolio Kanban to help them manage their portfolio flow in their portfolio epics. Do you have a contract similar to a portfolio Kanban that's helping you manage these enablers?
Catherine Cartwright 45:45
Yes, and in some of our spaces, we're working on it in others. So to what you mentioned, Luke, you might have an enabler epic, that is temporary funding in order to discover possible ideas or future opportunity. And we do encourage the idea of Lean tests, lean experimentation as a way to validate the hypothesis, not necessarily always building production, quality software. But you're either you're funding experimentation with the clear expectation that you're going to maybe continue the work in a new epic, or continue the investment if the hypothesis is ready to move into something that we want to build as an MVP.
Luke Hohmann 46:31
Excellent. That was what I want to I want to field one quickly for everyone. There's a question from Peter. And he says is the concept of intentional architecture similar to opinionated software, and Peter, I'm known for having a pretty strong cup of coffee opinion on lots of things, especially technical architecture. And I'm going to feel this one with hopefully channeling a little bit of strong coffee, flavor and opinion. All software is opinionated. The idea that there's this new movement of opinionated architecture, or opinionated software is actually, to me much ado about absolutely nothing. Because all things are opinionated, all tools that humans have created. Since humans have been creating tools have an opinion, I have an opinion of the right way to strike Flint. That's why I built the tool a certain way, I have an opinion about the right way to screw a piece of wood together, which is why the screws are constructed a certain way. I have an opinion about why I should write a book in pencil versus pen, which is why pencils are made out of graphite with erasers often. So the idea of any software being not opinionated is daft. And it's just not a useful construct. Because all software has an opinion. And if people say well, you don't understand Luke, some software has has a single workflow. So it's more opinionated than software that supports multiple workflows with that doesn't help us either, because then the opinion of the software is that multiple workflows are good. So all software has an opinion all architecture has an opinion all design has an opinion, the real question is, is your opinion informed by research and insight? Or is it just your opinion, and there's a big difference between opinion that's informed by research, and then an opinion that's informed by just making it up? So James, and Lys Catherine, I'd like you to tell us a story. So I'm going to give you a time to warm up in your brain about a story because this is live, everyone they haven't been prepared, I want you to tell us a personal story of when your activities in design caused you to change your opinion, or the opinion that was embodied in your solution.
James McElroy 49:08
That's a good one, I can go well, I'm gonna go wait, I'm gonna pull one on the Wayback Machine, which is one of the very first products I ever designed to design or when I really didn't know what I was doing. And I had all sorts of opinions. I was in my late 20s, I had just scored a job at a prominent local high tech firm, or I was high tech, the tech firm and you know, is kind of the envy of my peers for scoring a job here. And I designed to products. And I remember myself and this amazing developer who basically thought in assembly language, he could just have an idea and just it would come out of his brain and go through his fingertips and you know, it would be built into the product. And we spent all this time coming up with crazier and crazier features. It's not like we're trying to outdo each other, right? Like, oh, what if we did this? It's like, oh, yeah, well, if you're gonna do that, why don't you do this and the product was So 500 are clock radio. And so the idea was you want to wake up to whatever music you love. This is the days of CDs. And so we're like, Yeah, we should be able to wake up to FM am or CD. This is way before all the other stuff we have these days. So we're like, alright, well, if you only have a CD, why don't I choose a track on the CD? Because maybe I don't like track one is track two. And then it's like, Well, okay, well, I'm gonna wake up to track two, maybe the opening passage is too abrupt, and you want to open to two minutes into track two, CD, blah, blah, blah. So we just kept going like this for hours. And it to this day, I have these things in my house. It does all these, our opinion was that these were amazing features. I can guarantee you, no one in the world knows how to use those features. I designed them, I don't remember myself. And we didn't use a research that showed no one ever even wanted those. And so yeah, and to Megan's point, no one cared. And so that was a very humbling experience to me. And because this was hardware, this design is baked into these products until they die like this isn't like you can flash them and update them. And so that was one for me like, and actually I went to school for design. And I had my grandfather test a usability test of this product, because I didn't have any money to pay participants. And watching my poor grandfather tried to figure this thing out was very humbling. It's like, okay, well, that was my opinion. And I thought it was great instead of my engineering pal. But turns out, we never talked to our customers, and they did not want that at all. So that was one of my favorite stories. So
Luke Hohmann 51:30
Lys Do you have the Oh, you're on mute? I think,
Lys Maitland 51:35
you know, I've got a bunch of them. But I've got one also kind of a Wayback Machine one. That was one when, when we actually were at the point in I've been doing design and in research for a long time in my life, I started out in design, moved more into my passion of research in the last 10 years or so. But I was in this role, where we actually were able to talk to customers. And I know that sounds shocking. Like we had all sorts of things I worked for this agency. And they started doing this big thing where we were kind of selling research as a loss leader sort of thing. I was both the researcher and the designer on it. And for me, one of my favorite things is always been disproving my own assumptions. I love that I love going and going, I have this idea. And then going to take it to a user and watch him shoot it down and tell me something better. You know, for me, that's, that's fantastic. And so I was working in this project, where basically, I can't talk exactly what it is. But it was a financing project for people that buy and sell used cars. And we had to develop a dashboard. And I, you know, read all the books on dashboards. And you know, I've done all these things, but I was able to actually go out and talk to people. And I was able to do usability on their current software that they were replacing. And I was able to talk to them about their problems and talk to them about what they were trying to accomplish and all their workarounds. And I was actually able to go back and confidently start a project for one of the first times having talked to 20 Different people who use the software daily, and what their problems were. And let me tell you designing that dashboard and redesigning that software was one of the easiest projects I'd ever had. Because I knew the design objectives of what I was trying to do. Because I wasn't just waiting to the end and doing usability, which is kind of like where it had been kind of previous to that. You got to go and talk to people find out their problems first. And the other designer that kind of came along later in the project. You know, when we were going in doing the dashboard, I'm like, No, this is what they want. This is what they need. Because there's ranked list of things that they're looking for the stuff they need surfaced. And we were both just like, This is so freakin easy. It was so much easier to make it and took so much guesswork out. And then when I took it back out and did usability testing on it afterwards. They're like, Yeah, great. You solved our problem. Fantastic. You know, and it was like one of the most gratifying things for me, because I know it's not exactly the question you ask. But it's one of the earliest parts of my career where we were able to talk to people before we started designing things, where we didn't just take some broken design to somebody and tell ask them like, hey, does this work for you? But we actually were able to find out their needs beforehand. And that was fantastic.
Luke Hohmann 54:25
Catherine, do you want to toss one in or should we move on to another topic
Catherine Cartwright 54:28
should move on? Can't can't do better than least?
Luke Hohmann 54:32
Well, I want to add one thing that that I remember the one of my own experiences was I had I had discovered design and I used to give a talk we some long time ago at conferences called gooeys with glue usability meets agility and creates happier users and I talked about paper prototyping and simulated execution. I was actually going through some files in my attic from years ago and I I found a mouse that I used to draw on a on a on a clear cellophane and people would move the cellophane and they'd say click to simulate clicking a button and Mark Reddick and his work on paper prototyping was really great. But I remember one time, we had built a system. And we've done all our research, and we build our story maps, and then the we put it into production. And this was over at Conteneo, the company, I ended up selling to Scaled Agile, and people were like, This isn't working. And we're like, we did the research. We showed you the prototypes. We it, you're supposed to act this way. And then they're like, Well, yeah, but now that it's here, it's really not what we need. And what we found. And so the silver lining, and this is the final thing I think I want to bring up with everyone is the silver lining was we had the right functionality in the wrong place. And despite what our users told us beforehand, and despite the modeling and the design during the project, it really did require the actual code that was put in place for people that click and move around and say, Yes, you've got the right functionality, but it needs to move over here. Because if you put them in here, then I can do that. And we're like, Oh, okay. And then that that acceptance, that kind of like, oh, I still did a good job. Even though I didn't hit that home run, like least you were talking about that home run, I did my work, I built the thing, and people go, yep, you solve my problem. My experience, maybe I'm not as good as you at this, my experiences, we did our homework, we build the thing. And then we needed to adjust. And that's what I want to bring this home. And that is when you're using SAFe, and you're looking at your feedback, we have to remember that we're never one and done in Agile. We're never just a release. And I'm not coming back. There is this notion of monitoring. And there is this notion of coming back. So in the last few moments, I'd like to you all to tell us about design after done, which is you put it into production, you have marked it is done. And then you have to come back to it. Tell us how that works. at CVS,
Lys MaitlandL 57:29
it is never done. Just as a personal thing, not a CVS thing, but it is never done. You never know how it's going to react in the wild, like even your coding sort of thing. So I just want to say that, like if you think you made a perfect thing, and you released it you never did.
Luke Hohmann 57:46
Or you're stealing one of my favorite codes, which is great software is never done. It's just periodically released and updated.
Lys Maitland 57:53
Yeah, yeah. And new needs come about, even if you solved all the needs, at that time, new things happen. COVID happened, we had to create a whole new scheduler thing, right,
Luke Hohmann 58:02
and your software changes the environment itself, right, you're releasing something that is perturbing the system, therefore the system has to respond. And then you have to respond. Once you're back in that
Lys Maitland 58:12
you might have one problem that was a massive problem for people, but then that just alleviates that problem for them. And then that just changes the priority of the next problems that you're dealing with, right. And you're also having to do all sorts of other things that maybe aren't solving people's problems, and that you are just business needs. And those things all exist. And I think the hardest part is that so many people have the thought that you can really sit in, it's done. And part of that is like the big education piece Luke that we did with you with our product managers. And part of that is like really helping people understand that you never really solve things you have to continually monitor, and you learn and you build and you adapt, and you bring things back in. And sometimes you scrap the whole thing and start over because what it originally was purpose built for is no longer the purpose that exists.
Luke Hohmann 59:01
I love that. And that's a great closing, I want to just say thank you from the bottom of my heart to my three friends who I admire. I've learned so much from I hope everyone can can see why they're such wonderful people in this interaction. And all of them you made two investments, right? Because webinars are kind of a pain, and you're taking time from your day. You've got lots of complex things going on at CVS. You're one of the world's most important companies. And you know that and you you take that responsibility. So I just I just want to say thank you for for you three and thank you for your openness and your willingness to share what's working and tackle these problems as a group.
James McElroy 59:52
Thanks for giving us the opportunity. I mean, we could go on this stuff anyways. Right? So whether it's the three of us hanging out over a Zoom meeting or Talking to people online outside of it. It's awesome to hear the questions. And we'd love to hear from folks. You know, if you've had similar different experiences, we're still evolving this ourselves. And yeah, so thanks so much. Yeah.
Luke Hohmann 1:00:15
All right. I, I actually wish that we could just spend the rest of the day. Right. I think the preference would be now let's, you know, go to the pub, but it's 9. I am in California, where I'm sitting, so I'm not allowed to go to the pub. So we're skipping
Lys Maitland 1:00:34
across the US. So
Luke Hohmann 1:00:37
you know, we don't judge we.
James McElroy 1:00:40
I mean, if you go globally, it's five o'clock somewhere. Right? That's always the same. All right.
Luke Hohmann 1:00:45
Thank you, everyone. And thank you. Yeah, we're clauses, I think it is time for a pub. But thank you so much. And for everyone, let us know if this format was enjoyable. Because the CVS team writ large is doing extraordinary work in Agile. They're doing extraordinary work in design. They're doing extraordinary technical work to I don't want to discount some of the powerful and useful technical innovations that are going on there. So Peter, yeah, Peter. Is my kids would say Peter is flexing right now. So Peter uflex, go get a beer and all of us will say thank you. And goodbye everyone.
