Scaling Product Thinking with SAFe – The Secret Sauce for Meaningful Product Impacts

Webinar Transcript

Myriam: Welcome to our webinar today, Scaling Product Thinking with SAFe: The Secret Sauce for Meaningful Product Impacts. My name is Myriam Sanie and I’m with the Marketing team here at Cprime. So without further ado, I’ll pass the baton over to our presenters. Anne, take it away.

Anne: All right. Thank you Myriam and everyone. Welcome to the webinar on scaling product thinking and SAFe. So I have the great privilege of being joined today by David Laribee. Been a longtime colleague and a friend and overall great person. Dave, you want to go ahead and introduce yourself?

David: Hi. I’ve been in the business for a little over 20 years, come from an engineering XP and product development background. I was six years at Version One as a product development coach, so all agile, all the time, meta-agile stuff. Right now a kind of focus on breaking this DevOps and Product Dojo concepts that were pioneered at Target. So I’m in starting a bunch of Dojo programs all over the place and I’ve been kind of involved in the tech community kind of open source and engineering practices community in the past. So that’s me.

Anne: Awesome. Thanks Dave. And kind of what I bring to this conversation, my background was in development as well, although not nearly as hard core as a Dave and not nearly as recent. And then I spent about seven years in product management, kind of working at various levels from being team level product owner to being more of a strategic leader in that space. And I had the pleasure to spend the last five years working as a leader and a coach in agility and product thinking. And one of the things that really led Dave and I to collaborate on this presentation is we’ve been working with a lot of clients of late that are working with SAFe, that are pretty mature in SAFe methodology but maybe aren’t as happy as they’d like to be in terms of the impact or the ultimate value that they’re getting from that.
So we’ve been helping those clients just kind of unlock a little more power from that, by bringing in product thinking, a little more technical agility. And that was what led us to put this presentation together. So as we walk through this presentation, our intent is in no way to discredit SAFe. It’s really talking about ways to enhance SAFe and in some cases some myths or some places where we commonly see clients misinterpreting the intent of SAFe and that’s causing some struggles.
Anne: So this is what we’re going to run through with folks today. I will talk a little bit about the story of scaling, and kind of thinking about what scaling really means and approaches for that. Then we’re going to talk about value streams and products as value streams. Pull that into product thinking and how that fits within that SAFe methodology that you know and love. Then rolling that into, what does that mean for the PI Planning event, which is one of the places where kind of discovery or figuring out what to build collides with delivery. From there we’re going to talk about architectural runway and releasing outside the train. All right, so let’s jump right in here and talk for a second about the story of scaling, Dave.

David: We kind of think this is an interesting visualization and some places we find ourselves kind of collaborating and working in, might be starting their scaled agile journey. They’re large organizations, they have big platforms, big products, big issues, and kind of there’s this tendency to jump right in at level five. Right? And you know, so let’s focus on the scaling first before we kind of button down what our model platform or product is. So you kind of see like moving from left to right. You know, we think that it really begins with doing some early discovery in the products you kind of see desirability, you know, it’s one of those product manager kind of qualities, that they often are talking about.

David: They’re kind of pushing that up. And then we get into some of the engineering issues and we’re understanding how to deal with, or extract patterns or create some guidance around architecture to get architectures involved. And then you get all the way up to number four and we’re talking about shipping it, you know, maybe it’s a cut over, maybe it’s launching it to the market. Maybe we’re getting other departments, other groups, other disciplines like marketing, sales involved. And we’ve kind of achieved product market fit. This is an interesting model and is a good model for the kind of product first scale, you know, get the product sorted and then kind of approach scale. Right? So interesting visualization and start a conversation with. Anne?

Anne: You can apply this curve outside of just with respect to your product too, if you’re a company that’s new to SAFe or whatever methodology you’ve chosen in your, you’re looking to scale and to kind of spread that type of learning or different ways of working. This is a similar curve to think about too because you want to start with a smaller place and kind of validate and test and learn and then spread that as you’re kind of progressing along this curve. You know, one common thing we see is everyone wants to go all in all at once. But what that means is that first experience is the same experience for everyone in a picture like that. That first experience is just the baseline that we continue to learn from. And then the bulk of the folks as you go up the curve are going to actually have a better experience because of the learning of that few that are on the left side of this.

David: Exactly. I was recently at a client and it was less of a product management and product thinking challenge and it was more of a challenge of a modernization challenge. Right. So you see this kind of starting off with desirability. That client really needed kind of figure out what they were doing in terms of feasibility and learning. It’s very complicated like microservices architecture. So you know, the sphere that you’re looking at might be different depending on where you’re coming at, what your goal is, but still kind of starting with what is the kind of more important attribute to address up front is kind of key to getting scaling to work down the line.

Anne: Yeah, that’s super cool. But in that case with that group, those first few, you know, took some really hard knocks, but then from there, the greater group benefited as a result of it.

Anne: Awesome. Let’s jump into products as value streams for a little bit. I’m giving us the tagline product over plumbing. If we can riff on the agile manifesto a little bit. If we dig in a little bit to some of the scaled agile documentation, you’re going to find this definition of a value streams: value streams represent the series of steps that an organization uses to build solutions that provide a continuous flow of value to the customer. And when I first saw the statement, I kind of thought, ah, shoot, you know, the value stream in this statement to me really feels like it’s being defined as the process, the series of steps that’s needed to build that thing. But I don’t really want to think of value streams as the process we follow. I mean there is some value in having that and we need to have some sort of way of working so that we are able to deliver value, but the process alone is not the value unless you happen to be someone that sells process. Some of the places we go on, I don’t think this was the intent of SAFe in any way, but Dave and I have both seen this where they start to think that these value streams are actually the org chart, or the organization or the business we serve. So it becomes kind of this thinking of okay, value streams are certain lines of our business are value streams are a group on an org chart or potentially even an ART that isn’t a value stream either. Ideally you’re going to find your value streams, maybe you’ll map your organization to that. Not the reverse. I was working with a client recently, they took their org chart and they kind of blasted product on top of that and called that product called that value streams.
You can imagine some of the challenges that surfaced as a result of that. When you think of value streams and when you think of that plumbing, the value streams aren’t so much the pipe, but like in this picture with the value streams really are is they are the water. And the pipe is necessary to get the water from one point to the other. But the water is really the product and the product is the thing that’s bringing to value. And when we use the word product, throughout our conversation today, we mean by product is, that’s the thing that’s super technical term thing, that you build. And then it might be a service, it might be a softer product, it can be a blend of those things. But it’s a thing that you built that impacts people. That in the end is your product and batch your value that you’re delivering.

Anne: All right, so now that we’ve kind of set that stage, let’s pull that into SAFe and kind of talk about, all right, how do we bring that product mindset and that value into SAFe? First of all, before we go there, I want to talk just a little bit about cycle times and about building iteratively versus learning intuitively. And in this top kind of sketch here, I’ve drawn just a standard waterfall process where we are on a really, really long cycle time. we would do big bang requirements, design, build and test. And in this scenario there was really only one cycle and that whole cycle was the entire release, but what happened throughout this period of time is that goal that we were striving for would ultimately shift and change. So by the time we got to the end, that thing that we were building was no longer the right thing to build in the market.

Anne: And we didn’t really have a vehicle throughout all of this to learn and to adapt as things were shifting around us. You know, you want to go back 10, 20 years, that was maybe okay in most cases to have a six months or one year release. But now it isn’t. So of course, you know, as an industry we moved to iterative methodology, but a lot of what we did with respect to iterative methodologies was still kind of leave those discovery pieces if you want to call like requirements and design discovery, we largely left those discovery pieces still done upfront, sometimes these were even done by a different department, product management or the business. And then we started constructing the software iteratively and iterations. So delivery was looking a little bit more like agile, but discovery was still looking a lot like waterfall.

Anne: In this case it was better. We have better code quality. We were able to show things faster, but in a lot of cases it was still incredibly linear because the goal that we were striving for had been set up front. So again, this exact same thing could happen to us. And again, if we didn’t have a vehicle to shift and to change or the ability to let these requirements, these discovery pieces flow over time, again, we were falling into the exact same trap that we kind of did with waterfall. I kind of like to joke, Dave, about this is saying that, you know, this is like waterfall requirements stapled on iterative delivery.

David: Yeah, absolutely. You see it, you still see this even in kind of the thought leaders out there now kind of talking about service blueprints and kind of trying to nail down what the design is and design systems and stuff like that. I don’t think that they have to be that way, but I’ve run into situations where we’re just kind of calling that R&D phase up front and requirements and design phase these new fancy terms. So I kind of tend to like to probe a little bit or you know, do a little digging and figuring out what is really happening here. Are we building for feedback or are we building for kind of a more speculation like kind of a Hail Mary type pass.

Anne: Yeah, exactly. And if we kind of started to think about a PI and if a PI, you know, it’s going to have three to six sprints, a PI might start to look a lot like this picture. And if we really can only discover and build and release once a PI, we’re going to kind of work in these waterfalls and we’re going to talk for a bit about what that means. But what we’d really like to do and kind of that ideal again, is let’s shorten up this upfront discovery and let’s try to have that be a lightweight thing that’s going to help us to just gain a common understanding, make sure everyone’s on the same page of what we’re trying to do, tell the product story. And then from there, let’s link together discovery and delivery sprint by sprint or whatever that increment or that cadence happens to be. Then we’ll be able to actually shift and maneuver because discovery can feed delivery and delivery in turn can feed learning. We don’t have to work just straight down that straight path of that road that we had set up front. So then in this scenario, when we effectively do that and that the market will shift on us. Again, this is just an inevitable thing, but now we have the mechanism to shift with the market and the ability to learn and to change. I mean, that’s really what this agility that you seek is all about here. We’ll talk for a little bit more about this, but the big ticket item here is by blending discovery and delivery, we can get to that iterative learning versus just iterative construction.
All right, so let’s take that last picture and let’s kind of brand it in a SAFe world. I think one of the cool things about SAFe over say Scrum, for example, is there’s a lot more kind of recognition of the need to create the product backlog to understand the product backlog in this methodology than there are in some of the other ones. But it’s taken too literally and then maybe drawing too many conclusions from these pictures. it still feels very heavy, very upfront and very waterfall. So let’s start to kind of look at some of these places where we weave product into SAFe. The first one here is kind of at this beginning we start with epics in SAFe at that highest level of the backlog. They’re typically a fairly large initiatives, product ideas, those types of things. These might be things that are a bullet point on your roadmap or may even be higher level and totally linked to your product strategy.
We need a place in this portion of the picture to get from that idea, that thing that’s maybe just a few words on a slide and to get that broken down into those features that we’ll be able to take to our Pi planning. The picture gives us an opportunity to do this. It doesn’t exactly tell us how. So this is a place where we want to insert that early discovery that we talked about on this slide and say as we go from epic to features, this is really going to be about the team coming to a common understanding of what we’re building, why we’re building it, who we’re building it for, and then working through a process where we come to understand an idea, narrow and focus it and then the output of that early discovery is going to be sized and ordered list of features. That makes it so we’re ready then to kind of move into this next phase. Typically this next phase of delivery is going to be kicked off by some sort of PI planning event. So if you’re able to come to that PI planning event, we have the artifacts from the early discovery when we all came to that common understanding. And now we have that ordered list of features and we can start grabbing features off of the top of that pile, as the teams are working through that PI planning event. Then throughout the PI we’ll be able to blend discovery and delivery, again like we talked about on that last slide, sprint by sprint, we’ll be discovering as we go. Discovery can feed delivery, delivery, in turn, will feed learning. Now we have a mechanism to make adjustments even within the PI, but we’re still working in the context of that feature set. From there, and this is happening in tandem, it’s not linear as it appears in this picture, which is why we do these boxes overlapping, but actually being able to construct and having an automated pipeline, so that we can both be able to deliver code artifacts rapidly and be able to test and validate the stability of our code base along the way. Now that’s actually that delivery piece of the learning. And so the shorter those cycles that we can blend together, the more learning opportunities that we’re going to have and that’s going to give us that impact of pivot. So in the end, this is all going to circle back. It’s going to lead to product learning, which could fuel different epics to be queued up, different features to be queued up. If we look at this picture, it shows just kind of one cycle. But in reality, what you’re going to have or what you want to unlock is many cycles of doing this throughout the course of a PI.

David: Yeah, I think this is where the art of scale comes in play is like when you kind of get this sorted, think back to the, the curve that we opened up with, you know, when you kind of get those fundamentals down, you can start to open up and have multiple streams going on and really benefit from scaling when you get the rhythm there. The other thing I think is really interesting, for many years now I’ve kind of been focused on handoffs, right? And kind of finding those handoffs and saying, how can we make those more collaborative sessions or like transitions. So, you know, typical example is kind of inviting developers, inviting your engineers. inviting some of your Test and QA folks into that kind of discovery can really open up some really interesting ideas, right? So you’ve got smart people coming to the table with ideas. It can also open up some kind of more holistic in terms of how you’re shipping stuff. See we’re kind of trying to maybe flatten these value streams a little bit more and get folks to be a little bit aware of what comes before their particular skill set and what happens after their particular skillset.

Anne: Heck yeah. I mean we need those engineers at the table. We need those QA folks at the table that are going to ask all the what about questions? And we don’t want that PI planning event to be this hard line between like product management and the senior people versus the doers and the people that actually bring the product to life. We want these things to be connected as we go through discovery and delivery.

David: Yeah. It’s a real power. And seeing kind of like a discovery work side by side with delivery work. Think about like your demos and stuff like that, you know, that seems foreign to you, that’s something to kind of think about. What could we glean from even a demo. We haven’t gone out to see a customer as this kind of very, you know, internal feedback. What can we glean by presenting like discovery works artifacts side by side with delivery kind of stories.

Anne: Yeah. Super cool. We’d be able to see that come to life then on the next demo, and on the next demo, and that would be a lot of fun. All right. So we talk about kind of trying to reduce those cycle times. That’s going to give you the ability also to release more frequently. And you know, one of the myths of SAFe that’s out there is that you can really only release or you’re only supposed to release once a PI, and that being like a potentially full train release where all of that code comes together. But hey, there’s no hard and fast rule that says that. And actually if you were to release only once per Pi, then you only get to learn, you know, once and it’s going to take another full PI before you would able to adapt to the market based on that learning.
So if you kind of look at it and we want to talk about something like a mean time to pivot in this example here, six months, you would really only be able to learn and then correct that learning at once every six months. And the pace of change in the market right now is really kind of not tolerating a time like that. So as companies you’re going to want to look at of course, what you’re building and how you’re building it matters a little bit. You know, not every company is in a situation where they want to release a thousand times a day. But kind of be thoughtful about the cycle times and where you would like to get to in your organization. And if you’re one that’s maybe every three months right now, could you get to twice a quarter or something like that. Just start to get closer and closer to maybe being in a situation where you’re able to release every sprint or better yet. Be able to release when you’re ready to, not just based on a fixed calendar based in increments.
Alright. So as you are seeing this, hearing this and reflecting, here’s some things to kind of ask yourself to really measure your organization and how blended discovery and delivery are is how far ahead is your backlog prepared? If you’re in a situation where you have, say more than three to six sprints worth of ready backlog, you’re doing a lot of upfront discovery. Is that backlog keeping you from being open to shifting and just changing? I worked with a client recently. They said they had something like 14 sprints of ready, backlog prepared. So I was like 28 weeks of work that was all set in stone and you know, the ironic part of all of that was that was actually a team that was working on a mobile app. There is so much that can and should change in that timeframe, that investment in that backlog was significant, How far ahead of you committed to planned work? How fixed is your roadmap, how fixed are the expectations with leadership? , when something new comes up? Is it understood that we’re going to have to flow some things in and out.
How long does it take to deploy? So if you were asked to deploy right now, could you build? How long would it take to test? How long until you actually could move that into production and given your company’s policies and whatever constraints you might happen to have, all of these things are affecting how fast you’re able to adjust. So when you kind of add up these things that’s going to get you to asking yourself what really is our mean time to pivot? And what I mean by that is you’ve put something in the market, you’ve learned from your market. Now you want to put something else in the market. What’s the difference in that time? Alright, so Dave, we worked trhough discovery, we worjed through value streams and now we get to kind of one of those things about SAFe that everyone either loves or hates, and that’s that PI planning event.

David: I’ve seen all kinds of PI plannings. I mean from the, the red string experiment where you kind of are pulling out dependencies. I remember the first time I encountered this, I was walking by a big conference room. A bunch of people are in there. They had red string strung across from wall of wall. And the first thing I thought of is a kind of forensic blood spatter analysis, it’s a little morbid. I know I will say like when you’re kind of putting together a deck and you started googling that, you know, this is probably the least offensive or nauseatingly image I could find, but it kind of struck me as odd.
I get the point of it and I think they think it’s like sometimes early in a PI, where the teams kind of need to slow down and go through the motions and I understand that it’s what this practice is about. But when you find yourself doing this, you know, several PIs down the line, that’s kind of maybe a little bit of a sign that you’re not growing as a release train or as a product development group.
Anne: Yeah. And I think another thing that you really see in this picture is the families of teams may not be grouped in the most effective way or the breakdown of the work, the product alignment here, because you’re seeing so many dependencies. I wonder if in this picture of the teams are actually organized by layers at the tech stack or what is it actually causing so many dependencies for singular stories.

David: Yeah, this harkens back to Conway’s law, which states that the communication style, the organizational find way into the products that that organization creates. So here you have lots of dependencies, lots of switching, certainly not optimizing for speed here. You certainly probably creating architectural issues. These are kind of like hunches that, you know, when you’ve been around the block you kind of look at that and find. And to be fair, that is the point of this exercise is to kind of illustrate that. So what this image doesn’t show is what did this dude come around and do? What did the people in the room come around and do as a result of this? Did they reorganize? Were they able to spontaneously reorganize? That’s something that’s really hard and tough to do when you’re in a meeting situation. So if PI planning is where you’re kind of addressing those things in a committee, you know, we all know how fast a committee is, right? If you’re in an enterprise, you all know what it’s like and it can be a little bit painful.

Anne: But this definitely is a good visual of the challenge that these folks are facing. All right. if we kind of compare and contrast this visual on the left, as Dave and I talked about it, we talked about blood spatter, we talked about org structure, we talked about dependencies. One thing we didn’t talk about is what they were building or their product story. And there’s no way this picture on the left tells a real product story. I’d like to contrast that with a picture like this. And I can imagine coming into PI and coming out of a product discovery and early product discovery session where you’re showing a picture like this and what you’re seeing here is a number of different artifacts that are going to tell a product story for an increment of work that a team is about to embark on.

Anne: So kind front and center, you see a story map that’s based off of a persona that has a goal, and the orange stickies represent high level activities that that person needs to complete in order to accomplish their goal. And the yellow stickies represent different steps that they’re going to take to complete each of those high level activities with the sequence of steps going across and then potential variations of those going up and down. You also see kind of over here off in the distance, there’s a sketch of what that experience would look like. This happened to be capability for a mobile APP and there’s six different screens that the user goes through while they’re on this journey. And you can lay that next to the steps that are being taken.
And then another thing you see here is the concept of individual journeys or paths through this experience. This activity here is about being able to set a notification on your phone when the service becomes available. And here you’ll see there’s two different paths through that. One of them, this red one is to request a text notification, but another path is to request that same notification via email. And you can see how they touch different stories with different steps in this process. A lot of times when we break down our epics into features, we take a very hierarchical view of that. Basically kind of taking an epic, a big thing and saying, okay, how can I chunk that into smaller things? And a lot of times we might think of these high level activities vertically as those features, but I would challenge you to think of features more like these paths across or these journeys.
And when you do that, then you could deliver to the market, just this request by text message path and not have to do the request by email. This path could stand alone later. We could deliver requests by email later. We might even learn that you know what most of our users are using texts so we don’t even have to worry about requests by email. But if we have made it so that our feature was this whole thing, we would have had to complete all of these stories before we could bring this to market.

David: One of the things I really like about this approach too is from a tactical team level, it becomes very easy for your talent and folks that are building this thing engage with each other, right? They can start to see the whole kind of story of why we’re doing this and what it might mean to the end user. Right? And so like, think about a testing engineer or a tester, right? They can start to rate it from the get go, and anticipate where a longer exploratory tests might head. That kind of makes them shift left and DevOpsy and it kind of makes them shift left a little bit into a product management community. And this is where you get a little bit more back to that and how we can think of working this way.

Anne: Yeah, that’s absolutely right. And this team actually started to have some of those conversations too where they took that first journey and they started to think about, okay, what are our high level tests? So that was happening. And even left of a PI planning event. And I think that that is a pretty cool thing. Plus, you know what, this is the fun stuff and software shouldn’t be a relay race where we pass the baton. It should be a team sport, where we all get to start from the same starting line. And this makes sure everyone has the same information.
We just wanted to kind of challenge you as you’re thinking about SAFe and working in a SAFe environment. Language is always important, and as you look at some of the common language that we use in the industry, maybe challenge yourself and your colleagues on some of the thinking instead of calling it a program increment. What if it was like a product increment? I’ve talked to experts in the SAFe area that work with SAI and stuff or maybe the SAI leaders did at some point in time kind of have this conversation, but product increment was a term that Scrum had already kind of grabbed onto as the output of a single sprint but many, many product increments, many sprint increments are going to lead to a greater product increment that is also the output of a PI. I’d love to shift a lot of our conversations in corporate America away from planning to discovery. Let’s start to kind of embrace a culture of experimentation, a culture of learning. Human beings are really, really bad at predicting the future, especially with dynamic things. And software is an incredibly dynamic thing. We’ll never become perfect planners. But if we become continuous learners that are willing to be wrong and learn and adapt quickly, we’re gonna just really kind of kick back in the market and have a lot better return on our investment. This constant conversation of how much can we do? What are the estimates? How big is it? What if we kind of shifted that to what impact do we really want to have? At the beginning of every PI, we set certain objectives. Those objectives can be about impact. This was a quote that we stole out of some SAI literature and personally as someone who can be skeptical about process, I was so delighted to see the statement. An opportunity for just the right amount of architecture and Lean UX guidance. This is in the scaled agile framework. Sometimes I think we forget that or we use SAFe as an excuse to embrace long cycle times and to embrace upfront discovery. Let’s for real, do just enough, just in time, of these types of things and in a minute, Dave’s going to give us some real ways that we can apply that. And then lastly, as you think about commitments in ceremonies, let’s not have that be about just getting stuff done. You know, how fast did the crank turn, how many widgets did we produce this iteration, let’s make it more about selecting a place to start and learning and adjusting. All right, Dave, let’s start to geek out on architectural runway, dude.

David: This is a bit more of criticism of the SAFe literature. So just kind of re emergent design works extremely well as agile practices mature and are adopted by larger teams and teams of teams, which is emergent design. That’s kind of like bottom up design. I think to that as starting very simple. You know, the old school agilist, you know, XP folks where you start really simple and then you kind of tease things apart through refactoring.. One of the cool things about emergent design is that you kind of are staying real time with your design, right? And this kind of hearkens back to the early battle cries of Agile, which is, you know, big design up front or you know, is not what you want or just enough design.
And I think, you know, there’s a lot of room. SAFe is an evolving version thing. There’s a lot of room for some architectural guidance there that likely will come, I don’t track it that closely, but I think this is one of those gray areas where it’s really tricky and I see a lot of the folks that I’m working with, you know, you tend to either overdo it, like on one way they’ll just do top down design. Architects are fairly disconnected or they just try to stick with emergent design. And I think there’s something more to it. So skip to the next slide. This is just for our cute quotient here, but I’m kind of curious about whether or not we can scale emergent design and how far we can scale emergence.
There is certainly some precedence with this, with very succesful projects you’ve heard of.. Linux organization operates with a very flat volunteer base, although a lot of corporations are part of that foundation, but it’s a fairly decentralizes type in thing, right? It acts as large colonies of penguins do. Let’s skip to the next slide. This is an interesting thing. If you pull the slides after this, you can look this up, but you know, large colonies of penguins tend to stake out their little claims right? And this structure represents kind of a liquid and it’s really interesting organic nature that they arrive at, right? With some very simple kind of, you know, the rules of biology.
David: Back to Linux, we have 10,000 developers from a thousand plus companies over 13 years. Can you imagine the coordination nightmare that that would involve yet somehow it works and there’s some issues with the Linux community, especially the top leadership, but they do kind of run the Internet, right? This operating system runs the Internet. So we could look at that as inspiration, very senior kind of developers and engineers, very high skilled, very equal level of skill, that kind of thing. And looking at some of the kind of metaphysics or physics of the open source world, like if that’s something I’ve seen companies that are really operating at scale that are doing a really good job with things like DevOps and kind of emergent design are really embracing some of the moves from open source. Not only are they just using open source software, they’re internally acting as if they’re kind of an open source organizations.

Anne: Yeah. And I think that really speaks to trust too, because a lot of times I wonder if we fall into big bang design and architecture because we really only trust a small handful of people that make those types of decisions. But you look at an example of scale like this and there was certainly trust there.
David: So many things you think you just can’t anticipate your way out of. So not only are we doing product learning, not only we kind of learning about the user and the market and customers and stuff like that, but we’re also accumulating technical skills. We’re kind of learning about the terrain, especially if we’re breaking off a new technology. We’re doing modernization cloud native stuff, like all the stuff that’s happening. It’s this tech story of the tech industry, right? You’re kind of always learning something new. And so I think we want to kind of favor emergence. So what does an emergent team look like? And this is a team that I coached back back in the day at Version One and it’s really hard to describe, especially to folks that are maybe kind of on the product side or on a program side or you know, a little bit more kind of business inclined, what that looks like.

David: But I think this is a pretty good view. So what you’re seeing here is a tool called GOURCE and you’re seeing a team operating over a code base. This is Version One’s idea management. Not a shameless plug as I don’t work for them anymore. But you can kind of see the whole team kind of cruise over the code base, the branches, the splits here, these are directories, the dots are files and the zaps are commits. It’s a little hard to see here but those are commits. So now one of the interesting things to see is you have developers kind of working over the whole terrain. This is something we call an XP collective ownership. You have a lot of rapid changes.
David: This is kind of refactoring in small increments, tiny bitty commits. Up at the top you have Joellen, who was testing, Zarina up there, writing us some end to end tests. And then you see this big green flash. That is kind of a big design change. So we’re making changes and we’re very comfortable in making those changes, right? So you can do this, it requires a kind of concentrated effort, right? But it tends to lead to a more sustainable thing. Think about that first curve that we saw arching up. You know, very like hockey stick. Our cost of change curve tends to flatten out, right? So a few observations from this. I think architects, especially in larger environments, their behavior in this kind of foreign decentralized world is indicative of the longterm success.

David: And by that I mean the architects I’m working with, I think are successful at kind of creating leveling and in service of teams, are really not just working top down, not just working in isolation and say thou shalt create this, you know, adhere to this pattern. But they’re working embedded with the teams and they’re kind of playing with the team. So they’re kind of adopting some kind of coaching modes. And they’re working bottom up with the teams to build those skills and to learn from shipping and what works and what doesn’t. It’s really important when you’re breaking off new territory, I kind of see architecture moving into more of a social realm over time and becoming more of a skill set rather than a role. And you know, I did start to say we don’t need architects.

David: That’s just to say that architects are becoming more leaders in that kind of revolution. We see a number of job posts with that title go down.If you have architect in your title, embrace working alongside the team. Another thing we get at especially is kind of balancing some of our technical evolutions or technical desires alongside our business value. It’s very easy for organizations to get fixated on business value and for technical issues to come up. This is where I think technical debt comes into play where we just focused on shipping business value, ship, ship, ship, right? Are you kind of building up your technical skills as you go and kind of dealing with stuff issues as you move along?

And the last point kind of reinforces the third point. but it’s more of a flattening. I think it’s where are the technical learnings alongside of the product learnings, right? And achieving balance, kind of key to getting to all the goodness of emergent design. Another kind of thing that I’ve seen in some of the SAFe shops, is that releasing, we get good at releasing, you know, we get good at deploying to production multiple times a day by doing it right. It’s never easy in the beginning. It’s a matter of like repetition and it’s a matter of, you know, making it happen over and over again.
So I think this is a kind of a funny video. So, SAFe obviously has this term called a release train and with architectural runway, this is the perfect visual metaphor for that. This is some design student and Russia’s idea of transportation innovation. not maybe something I would necessarily want to get on. This is a little bit janky looking, but you have an airborne train, right? And it’s an awkward looking thing here. Maybe it would be a fun to be on, but I think, you know, there’s a bit of a mixed metaphor here. Is it a plane? Is it a train? Is it an automobile. So move to the next slide. I have a little more information on it.

David: So, when I mentioned on Twitter that I was going to do this presentation at Agile Day, one of my friends, John Cordy, who is a thought worker, an agile and engineering practices dude, send me a DM and he’s like, two big problems with SAFe measuring the wrong bloody things. I’m not even going to go there. And number 2; release trains increase system instability. And it kind of echoed like some of the anti patterns that I’ve seen, not in every team again, but some of them, you know, if you’re not kind of shipping frequently, are you necessarily building the skillset and the kind of working through the myriad problems that you’re going to find when you deploy and then have to roll back?

David: Aother kind of manifestation of this is, you can look at is kind of how technical debt is treated, right? If you save technical debt until the end of your PI and you one sprint where you deal with technical debt, you’re not necessarily building those skills that let you deal with debt in situ. This hearkens back to my emergent design, some of the underlying kind of techniques, a refactoring and kind of test driven and design in the small, right? So the idea that everything we do, we’re kind of running the same set of skills and not waiting until the end of the quarter to kind of address these in a more holistic fashion, means that we can build quality right in. And you know, that means at the beginning, that’s going to make you go a little bit slower, which is counter to the scale proposition. You know, scale is just one of the words in the SAFe acronym, but you know, kind of going slow being methodical, building those skills, that’s a lot of what we’re doing with the Dojo stuff that we’re doing, but that kind of means that you got to dial back the delivery knobs so that you can kind of build this muscle memory.

Anne: And I think it really comes down to Dave like building the right thing in the right way, because it isn’t just about go faster and you could use this exact same picture that you have here to talk about test debt. Because a lot of times it’ll be like, oh, we’re not going fast enough in the beginning. How do we make the team go faster? Okay, let’s quit writing automated tests. Yeah. It appears that there’s more velocity, but now you have more tests that you’re going to need a manual regression test cycle or you’re going to need to, you know, create those tests at some point in time. And now your curves are diverging just like you see in this picture.
David: Yeah. I mean, the goal is the bottom curve, right? The gray curve. You know, what we do is when we have a technical debt sprint, we’re really kind of at that red curve, right? If we don’t even address it at all we’re in the black, so the idea here is my experience kind of echoes this idea of that, but if you’re saving it; if you’re just doing it periodically, it’s almost as if you’re not doing it at all. So a few observations: you may have to start thinking outside of the ART, who is involved. This kind of harkens back to what Anne was saying with Value Streams, but who do we really need to get involved with in the release, the common thing is we can’t release it until marketing approves it or their software’s camera ready. And that’s not necessarily true. We could keep pushing that boundary, right? We can release the things with things like feature flags. We can release things and let marketing harvest the story for that. Quarterly releases don’t provide enough reps. So, you know, we want to kind of start encountering the pain especially like maybe in lower requirements, start there, of releasing by actually doing it. So stability is a function of repetition. I think in a lot of cases, especially, we when we start building interesting pipelines of automated testing and such. One thing to keep an eye on is all the DevOps stuff is great, but if you’re not kind of connecting your delivery, connecting your delivery, however automated, to some kind of feedback, whether it’s product analytics or you know, actually going out and seeing how customers are using it, you’re not really getting the full value CI/CD, continuous integration, continuous deployment and delivery as a feedback, right? Are you actually connecting that with learning? Are you actually able to measure? So shipping is great, but wouldn’t it be nice to know what folks do with this stuff we ship and you know, especially we kind of harken back to the blood spot splatter analysis thing. You know, there’s a network effect, right? When we start scaling, right, things compound and get even more difficult. So for step one, have teams kind of understand how can they can ship things and how they get to predictability and recovery and some of those things. And then, we can start to pile on with scaling, right? That becomes generally lasts We kind of master our craft first.

Anne: Allright. To bring it all together, Dave talk to us about product thinking in SAFe.

David: Okay. Skill learning. Now process. So it’s kind of ironic, but you know, it’s counterintuitive. We put learning first, we’re going to get some nice side effects, right? We’ll get kind of productivity, we’ll get those things. We’ll get the ability to predict what we’re doing. Those come after we go learning forward, right? And that’s kind of a tough road to hoe in some organizations, and making that pitch, but that’s a thing to focus on. Shifting the conversation from planning to product discovery. Knowing exactly what you’re going to ship up front is a thing I suppose. Right? But learning kind of as you go, that seems like everyone wants predictability, right? But you know, I think incorporating learning may minimize what you end up shipping, right? This is kind of agile OG stuff, right? We have this term we sometimes bandy around called product arrogance where you think this is the product everyone wants; you go off, you spend a year or two making it, you ship it and you find out there’s lots of issues in its fit, its product fit, its operational excellence, all kinds of things. So you want to kind of build that as you go. And in this cuts across from users and customers, it’s also the technical landscape. Emergent design at scale, call it evolutionary design. What can we kind of get from evolution that is a skill set that if you consider digital product or product development important to your organization you might want to tackle.

David: Otherwise you might kind of face a lot of like a crisis moments where you’re tearing systems around and doing lots of rewrites and that kind of thing that seems so endemic in the industry. Really challenge the big design up front. Test your designs through the act of delivery. This is what I encourage my clients to do. Don’t let your developers become human compilers. I had a developer once describe himself as a human compiler and it kind of broke my heart. I’m like, no, you know, you’re here to kind of engage as a part of the community. I mean, it doesn’t mean we’re locked up in a meeting doing it and just saying, I’m wanting to know exactly; I want to kind of know what you’re thinking about this product or what you’re curious about or what your ideas are; what refinements. I think making folks part of the product development story really kind of creates a nice humane work environment and energized environment cuts through some of the inertia we might see in big enterprise.

Anne: Dave, if I can jump in there, I think that bullet point, the two way street too, you know, I feel a lot of product people, they’re like, oh, they don’t need to know that; they should just do what I say. But I also hear developers say, you know what, tell me what to do and I’ll do it. I don’t want to know and I hope maybe that person’s just been beaten down by the aforementioned person. But, product developers are people that are curious, that want to understand the impact of what they do and how it’s helping people embrace that curiosity. And if your product person isn’t willing to answer why, don’t take “because I said so” as an answer.

David: In reality, if you’ve got a software development team, for example, you’ve got six, seven developers, two pizza team, like a classic agile team. Some of them may not really care all that much. They just want to, you know, they’re really techie. And that’s good. That’s a really important role to play. I’m just saying opening up that kind of door is really important to kind of create those flat teams. And lastly, you know, get good at doing things but doing things right. DevOps is a pretty big thing. Especially look at all the kind of tool chain stuff that’s involved. All the vendors, stuff that’s happening there. A lot of it can be confusing but you got to start somewhere. You got to kind of go for it. You will fall down. Failure’s a total option and will help you learn things. Just start confronting that rather than, you know, crossing your fingers and hoping, you know, six, nine, 12 months down the line that it’s all gonna work out perfectly because it won’t,
maybe it won’t be. Exactly. Yeah. Were wrong about time. We certainly want to learn that as fast as we can. , cause cause I learning breed success. , you know, it’s kind of interesting. The, Dave and I were preparing this presentation. We’ve st bled upon this quote from Jeff Bezos, say, I believe this is in the 2017 Amazon annual report. , and I, I love the words in this. , but I found it even more impactful coming from him, the leader of a company that is basically single handedly threatening, probably, you know, I don’t know 80% of the fortune 500 companies right now in some way. , so really, you know, if you’re, don’t let process the thing, don’t let process overwhelm your conversations, your energy, your efforts within your organization. Because if our focus becomes on trying to do the process, you’re trying to do the process perfectly, we’ve moved our focus away from what really matters and that’s the outcome. So for our clients, we’re bringing all of that together. We’ll take some questions, but before that, if you’re curious about more of this product thinking and how you can blend product, agile and DevOps together, check out www.cprime.com/productmanagement. It’s going to dig into some of this cool product thinking stuff that you can apply in SAFe and other agile methodologies. So we can start with the questions. Myriam?

Myriam: The first question is from Jonathan. So he wants to know kind of what are the specific failure scenarios that you saw in your or in the your client organization. I kind of led you to all of these insights that you presented to us today.

Anne: I’ll share one and then, I’ll let Dave share. I think one of the biggest ones that I see in almost all clients but it gets magnified in SAFe is that the backlog and the product story gets incredibly fragmented. And one of the reasons it gets magnified in SAFe is because there tends to be three levels of the backlog: epics, features and stories, where some of the other methodologies only have two, but if that product story or what we’re really trying to accomplish that, who, what, why is sitting at the epic level, it’s almost like we had this big boulder, we take a sledge, hammer it to it and it turned into features and then we take a sledgehammer to it. Again, it turned into stories and a lot of times that first set of stories that we start with ends up, you know, there’s still kind of too big and we would break them out again and again. And by the time you’re that person that’s sitting there developing and one of those stories, you have no idea anymore how it fits into the puzzle because there’s just this big kind of nasty hierarchy of breakdown of backlog. So I think one of the big traps is losing the product story. I’m losing it in the backlog and people kind of just not having the full concept context of what we’re building, why we’re building it and who we’re building it for and how this thing I’m doing right now fits into that bigger picture.

David: I think you did answer to that really. I don’t have a whole lot to add other than, when we start looking at these journeys and narratives, we can start asking questions in other dimensions. So we think of this as a map and a map having legends, right? And so when we look at a map, we see various features on the map. And especially in scaled environments, you’re going to have features such as dependencies. You’re going to have features such as, we’re going to encounter technical debt here and we’re going to encounter something we don’t know. So your journeys can kind of really stand out and not just to product delivery type things, but to journeys of learning, right? And learning our material, learning our material, learning our medium and our environment. So just a little bit from the trenches kind of point of view of what this approach is, where the value comes from.

Myriam: So we’ve come to the end of our session. And I’d like to thank our guests, David Laribee and Anne Steiner for really giving us some great insights on how we can incorporate product thinking into the SAFe framework. We’d like to thank all of you for taking time out of your busy day to learn with us and we hope you got value out of the session. We hope to see you again on one of our other webinars. We appreciate your time and enjoy the rest of the day. Thanks everyone!