Value Delivered - From Fingerprints to Frameworks: NEC's Agile Journey with Scrum and Kanban

 

In this episode of the Scrum.org Community podcast, Steve Lizotte, VP of Engineering at NEC, and PST Yuval Yeret are interviewed by Dave about the practical implementation of Scrum and Kanban practices at NEC as a part of our Value Delivered series. They explore the importance of collaboration, continuous improvement, and maintaining a customer-centric approach. Steve shares insights on separating program teams from product teams, finding the right balance between custom solutions and standardized offerings, and managing the tension between empowering teams and cognitive load. The discussion also touches on the evolution of Automated Fingerprint Identification Systems (AFIS), the complexities of managing agile delivery in challenging environments, and the critical role of Product Ownership and accountability in driving successful outcomes.

Transcript

Lindsay Velecina  0:03  
Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Dave West  0:20  
Hello, and welcome to the scrum.org community podcast. I'm your host, Dave West CEO here@scrum.org. Today's podcast, it's one of my favorite topics actually, it's about customer success or customer case studies. We're going to actually hear about a real live USE IT professional Scrum and agility in the in the real as it were in the wild. So I'm excited to have Steve Lizotte. And your value that from talk to us today. Steve's VP of Engineering for advanced recognition systems of any see America. So for the people that have been in trouble with the law, you're probably used his system. But we're not going to talk about that. So don't worry about it. And obviously, some of you may have heard you, Val on this podcast. Before you val is one of our amazing professional scrum trainers based in Boston, Massachusetts. So welcome to the podcast, gentlemen. Thank

Unknown Speaker  1:17  
you, Dave.

Yuval Yeret  1:17  
Thank you, Dave. Great to be here again. Awesome.

Dave West  1:20  
So it's, we've got lots to talk about. Can we start though, uh, Steve, tell us a little bit about what advanced recognition systems does the NSA.

Steve Lizotte  1:31  
So what we do is we develop products and services that are used primarily by state and local law enforcement agencies. It's used for, for two purposes, the primary purpose is in the pursuit of criminal investigations. So lifting fingerprints from a crime scene, for instance, ingesting them into the system and trying to see if there's a match somewhere, if we've identified if a law enforcement agency has identified a potential suspect, and that goes, you know, state and local all the way out through federal agencies like the FBI. That same basic technology is also used for enrollment in background checks. So if you've ever had to be fingerprinted, as part of a new employment offer, you know, you have to pass a background check, go get fingerprinted. We process that type of case as well.

Dave West  2:24  
That's awesome. So actually, yeah, when I became a citizen to this amazing country, a few years ago, I had to give in to do fingerprints. So I'm sure your system was involved in that, or thank you, thank you for not finding that I was a match with some crazy person somewhere else. So I really do appreciate that. Okay, so I from what you're saying, Steve, advanced recognition at NEC has been around for quite some time, right? Sure.

Steve Lizotte  2:51  
Dave, NEC of America actually was incorporated only in 2006. But the backstory is really interesting. And it goes, it goes much further back. And so the origin actually starts in the 1960s when computing was just in its infancy. And one of the core problems that people in this area had was how do we automate the process of matching fingerprints. Up until then it had been literally a manual process, right? So you're picking up you know, one and looking at the other and trying to manually determine whether or not there's there's a match or not. And so in the 60s, there were a number of efforts that were initiated to start automating this using computers. One of those initiatives was by NEC, also around the same time, there were a couple of RFIs that were released. One of them was from the FBI in the US, but another one was in Japan, and that was from the National Police Agency of Japan. And he see obviously gravitated towards that one, it worked about 10 years with that agency to develop an automated system. And they actually deployed the system there in 1982. That was the first large scale deployment of an APHIS system by NEC. Once that was deployed, they started marketing it to the US. And in the US, they were able to latch on and secure a deal with the city of San Francisco. And so the first US based deployment by NEC was in San Francisco City size system that followed very shortly afterwards with the first statewide system in California. And I think that that is now the California Department of Justice. Now, the interesting thing about that, one is that it was instrumental in solving the knightstalker case in Los Angeles in 1985. So a fingerprint was listed lifted from a from a crime scene. It was matched to the suspect who had a previous record, and it ended up being the Nightstalker who was Richard Ramirez and And so he was arrested within days because the agency was able to identify him, and then send his photograph out alert the public that we're looking for this guy, we think he might be the Night Stalker. And lo and behold, they, they caught him really quickly. So that's the backstory kind of kind of long, it goes way back. But that's the origins of how NEC got into the law enforcement business, and started being one of the pioneers with this technology. Another interesting anecdote, just about matching, and you know, being in the law enforcement business is that we do upgrades all the time, right, we're constantly working on whatever up to a dozen upgrades of systems, either either new deployments, or upgrades to existing customers. And with those upgrades, comes improvements in the algorithms, right, that original algorithm back in the 1960s, has been evolved, like every six months, they come up with new and better ways and faster ways of matching. And so when we complete a an upgrade for a customer, they rerun all of the cold cases. And invariably, they will find matches that weren't previously able to be matched. And so it's really, it's so cool and rewarding as an organization, to hear from these law enforcement agencies when they get a match or get a hit on a cold case. And so it's part of the reason why we do this, right, as part of our core being and motivation for, for why we do this is to, you know, help improve the safety of law enforcement and the general citizenry. So it's pretty cool stuff.

Dave West  6:37  
So very successful business, or, you know, keeping this this country secure in catching bad guys, and girls. So why would you? Why would you need to do Agile and Scrum? Tell me a little bit about the problem that brought you to working with you? Well,

Steve Lizotte  6:53  
yeah, the I mean, the the initial problem really was the business had been very successful. Even going back to the pre COVID period, which wasn't that long ago, it was a very, very successful business generating a lot of op. And then COVID hit. And, you know, for whatever reasons, the organization started doing things maybe a little bit differently, and just ran into some execution problems. And so I had known, you evolve from my past experience at another company, we started working, I think, in 2018, maybe 2019, on a in a very similar environment. And so when I got to NEC of America, I was really hired in part to bring in a lean agile culture into, you know, to break some of the silos that existed within the teams and to provide some structure. And so I reached out to, to uvala, pretty quickly, I started in May of 2022. And I think I reached out to him that summer, we started internally, splitting the teams up, you know, between product and program, everybody previously had been all part of the same pod. So we separated product development from program delivery. And we created Scrum teams on both sides. And we probably ran through, I don't know, three or four sprint cycles, before we reached out to evolve in started putting together formal training. And the reason for that was I wanted to have experiences with the teams failing, right, I wanted them to have some experience, trying to use things getting familiar with, you know, the vernacular and the overall process. So that when you've all came in with more formal training, we would have some problems that we could throw at him, right? We tried to do this and it's failing, or this is the way I'm doing it, am I doing it properly, versus just going cold turkey, having somebody come in and saying this is Scrum, here's how you should do it. And then we go off and start after the fact. And it's been very successful. I mean, you've always a great trainer in especially in that context, dealing with real world problems. Okay, I'll get

Dave West  9:02  
to you your veil in a minute, I just need to lean into this a little bit. So that's a really interesting and really good pattern actually trying something and actually getting some experience of it. And then during training, it's a little different to perhaps most customers do, which is great to hear that this experiential sort of driven approach because then ultimately, you can come to a training with with lots of real experience, which maybe good maybe bad, but, but But it's, it's very useful. So you're out you you came in, started and started helping me see what was your observations when you arrived? Steve

Yuval Yeret  9:45  
kind of talked through the separation of product and program maybe to elaborate on that a bit. This is the sort of organization which struggles this divide between we need to build our product and continue to build the product. But also each agency that wants to use our product, it's not as easy as you take it off the shelf. And it just works. You need to integrate it into their systems, you need to maybe customize it to the local laws. So there's a lot of delivery work that these teams are doing. And one of the things that we were seeing was both, you know, going to the scrum value of focus. As Steve mentioned, teams were struggling with focus, they were struggling with focus, both from the perspective of how do we balance juggle, and they were really juggling the work on building the future of the product. As well as working on multiple programs of implementing the product for multiple agencies. The business was so successful that there were a lot of programs in flight, right? That's the sort of business that cannot, or does not say, No, does not know how to say no to, you know, California coming in asking for, you know, for a system or in the car scheme for, for a system. And I don't know if those are the real estates just coming up with something, I don't want to even talk about the real estates in organizations that use this. But that's something that we were seeing, we started applying focus at multiple levels. One was, like Steve said, defining teams that focus on products versus teams that focus on programs and then trying to create teams that can own a product, but also limit the amount of programs that the team was focused on, all the way to using Scrum, and sprint planning to make sure that the teams don't take more than they can, which is a real struggle when they have project managers, program managers, business people, all wielding milestones and dates that the teams weren't part of figuring out. That's a classic pattern that you know, Steve and I were dealing with in that previous organization as well. So we had some, some battle scars from from that those types of experiences. You mentioned, the real world. This is agile in the real world, people that come in and say, we'll just pull whatever makes sense into the sprint plan and ignore everything else out there, no roadmaps, etc. That doesn't work. I mean, you could build an organization around that. But you need a very different business model, business people and conversations around that. And you need to understand that that's not necessarily the reality that you're in. And you need to figure out how to use the Agile principles in that environment. And that's what we set out doing, using some combination of the scrum values, principles, practices, as well as some elements of Kanban and flow to help the teams both improve how they're doing, as well as gain an insight on where are the constraints, what's going on.

Dave West  13:23  
So I do want to you talked about the separation of program teams from product teams. So obviously, I know nothing about this situation. But that instantly makes me feel that you're separating the same stuff. Because from my experience, the greatest product teams are ones that are dealing with the actual customers, because otherwise they become insulated. And they create something ultimately, that customers don't want. However, the challenge that you highlighted when you do that, and I ran, you know, five engineering teams in my previous in this startup, I was working, and we we kept it together. But the challenge was money talks, and the priorities of the roadmap, which of course, we got VCs to support, and everybody was, was, we're always down priorities to, you know, BMW, or, you know, Volvo or whatever customer that we were working with at that time, saying, This is what I need now. And this is we need to implement this and oh, my gosh, there's this issue that we've found, etc. So you generated them. Can you talk a little bit, maybe see if you can talk about the balance of how you kept the product teams in the real world, and then also kept the, the, these these other teams, these program teams for not like creating completely custom, you know, adding new things that weren't ever going to be part of a product roadmap? How did you balance those?

Steve Lizotte  14:58  
Yeah, so good question, David. Just to set the table a little bit. And to follow on with what you've all was saying just a moment ago, this operation is kind of like a systems integrator, right? So think of a systems integrator where you have, you know, a core set of products, and the reality is in the field, you're putting them together, you're configuring them to solve, you know, custom problems that that particular jurisdiction has. And it at a point in time, the organization kind of became all one group, right. So we had multiple programs going on, that required multiple different features. And so we had feature teams embedded with the teams that were actually doing the program delivery. And it got to the point where each customer basically had their own branch of the code, right. And so we really tried to split that for that reason, we want it to have standard product offerings that could be configured. And those two functions are different, right? The product development team is working on the core product, core sets of features. And the delivery team is out there working with the customer, configuring it, there may be customer requirements that require something to go back to the product team, right. But we wanted to separate that. And we wanted to have a core product was standardized, had been hardened, fully qualified, you know, no defects that the delivery teams were then taking and running with, versus kind of doing it all together on the fly.

Dave West  16:33  
And I knew well, you know, what, how did you navigate this when you you know, sort of went in? What was your first observations?

Yuval Yeret  16:42  
I mean, it's, it's an ongoing struggle. For me, it brings, but it brings up conversations around team topologies, for example. So when you look at the topologies, there's the pattern that you want to see, being streamlined, being the product team that really delivers the value end to end, they're empowered to run. But there's also the cognitive load if you're asking the team to do too much. And there's a place for having a platform, right? The question is, how do you slice, think about our world, Dave, you can see a situation where professional scrum trainers just go out there and build trainings on the fly. And every time you know, we need something, we just create our stuff, which of course, adds value, because we're making it specific and real world context. But you know, there's also value in the consistency in having a platform that's shared in bringing together the insights, but that creates the struggle of how do you do that? How do you bring all of the knowledge, the insights from our CSDs connecting to the customers to the courseware team? That's building the platform that we all use? That's, you know, that's your headache? Dave? It's kind of similar. I think

Dave West  18:11  
it is a headache. Thank you for sharing that with our audience. And, you know, obviously, we have tried many different things, including and sort of like an internal open source model. With primary committers. We've tried all sorts of things. The the You're right. And obviously, we have the validation element on top, which means if they get out of sync too much, it goes horribly, horribly wrong, as I'm sure, Steve, you have, because you've got governance, you've got compliance, you've got rules. And those rules aren't, are consistent, aren't consistent across these different agencies. There is the government so they're, you know, appropriately confusing to ensure maximum slowness. Which was probably a good thing. So why did so you ended up you've sort of you're always managing that balance? Is that the sort of the sort of learning from that?

Steve Lizotte  19:09  
Yeah, I mean, you know, I think one of the one of the key takeaways here is that, you know, we separate just going back to that product versus program, it's kind of easy on the product side, right? You have a roadmap, you can kind of lay things out and, you know, in structure is almost inherently there. Once you have a roadmap. on the delivery side, it's just chaos, right? Because the customers start and stop. You could have a customer that's been on pause for three or four or six months waiting for something to happen on their side, and then all of a sudden, they come back and boom, they want you to pick up where you left off. And so we have, you know, in I don't want to say that we have have it nailed here. There's still some difficulties we have in managing customer expectation. ations when those type of things happen, and I think we still struggle with, how do we say no, right? How do we say no, we've got four things going on in a team right now, I can't add a fifth, right. And I think that the, the teams are very, very much their heads are in the right place in terms of wanting to do the right thing. And so sometimes we have to pull them back a little bit and say, No, four is enough for this team. In fact, it may be one too many. So how do we negotiate how do we get back and properly set customer expectations, so that we can, you know, we can operate and preserve some of the values that we're trying to really push on around flow and, you know, work in progress and things of that nature?

Dave West  20:44  
So I, how did the leaders deal with this, because when you've got the organization that you changed from, was the ultimate flexible organization in their perception, because all the resources, the people could be applied to a particular customer, if they came online again, and you could stop all the other stuff. And then, whereas now you've got more, you know, separate responsibilities and concerns. So how did the leadership take that the change

Steve Lizotte  21:12  
the leadership, meaning my leadership, or your

Dave West  21:15  
leadership, the people that are making the commitments, the people that are like, if we keep California, people get Utah, you know, or whatever, I have no idea what the dynamics of the market are. But you know, what I mean?

Steve Lizotte  21:26  
Well, you know, one of the one of the things I love about Lean agile in this whole, you know, process and, you know, set of mechanisms is transparency. And I think that transparency, it kind of goes both ways, right. And I think a lot of times teams look at transparency as Oh, they're trying to get up in my shorts and trying to control what I do. And, you know, I've got a software background, I developed code for the first half of my career. And I think that, in instances leadership didn't really know what was going on in the trenches, and therefore couldn't make the best decision. So I think the transparency in this case, that we've been able to provide, using this mechanism, has enabled leadership to understand more of the problems and the dynamics that are going on at the team level, right. And if we can, if we can highlight those, then leadership can jump in and help us to manage the customer, and maybe help with prioritization and so on. So I think that's kind of the key thing, from my perspective, this transparency, it goes both ways.

Yuval Yeret  22:34  
I fully agree, I think the other interesting pattern that that was interesting to work on and I think helped the viewer as well, was the concept of product ownership. We talked about the program. But even in these programs, we leveraged product ownership to to help with some of what the teams were facing. Maybe Steve, you can talk to who were we thinking would be the product owners and hang out there?

Dave West  23:07  
Just to be clear, so product owners at both the program, and at the product level as well? Is that right?

Steve Lizotte  23:16  
Yes, yeah, we have interesting, two different sets really at the at the delivery level, right, working with the customers and the programs, the product owners are the technical team leads, right, they have the domain experience, they've been doing this for 1520 years, they understand the customers, the dynamics, and so on, and so forth. And they're in a really good position to be able to accept stories and kind of lead the path, right help with the high levels, with the sprint themes and so on. On the product side, it's more of a partnership with product management. I wouldn't say the product management today is, you know, fully singularly the product owner, but it's a shared responsibility between product management and the team leads of the individual product development teams.

Dave West  24:03  
I mean, it isn't accountability, obviously, the the most effective implementation and accountability as a single human being but as you transition to that, or look at that, I think that's, that's really interesting. And it's really interesting that you highlight at the delivery side or the program side, you have that accountability, clearly defined because making those trade offs for the customer, you can get into these cycles of despair, you know, you're like we do this oh my god, what about that and what about somebody has to make a decision and break the cycle and having somebody that's that gets both the you know, the technology and the business, which is ultimately what the product owner is, in that situation is incredibly powerful. Exactly.

Steve Lizotte  24:48  
Yeah. And these systems are fairly complex you know, in there are a lot of you know, unique workflows. When you get down to, you know, a state system or a county systems there's legislative require I mean, in many instances that dictate that they need to operate in a certain way, because the state legislature has made a law, and you're mandated to do it this way, whereas another state or another jurisdiction, could have a, you know, a different way of doing the exact same thing. So, there's a lot of nuances here in these leads, it's really hard for somebody to come from the outside and be a team leader. It's not like, you know, you know, your your typical Software Factory, you know, where you can bring a guy in, or a girl in who's got 15 years Java experience really good cloud native this in that and can hit the ground running, there's a lot of nuance around the domain here. It takes a long time for people to get to that level. So once we get them, we really want to, you know, unleash them and really empower them to make these decisions on the fly. product ownership

Dave West  25:53  
is the hardest job in the world, in my opinion. But that's my opinion. Your Well,

Yuval Yeret  25:58  
yeah, I think one other element that makes it even harder in this context is it's not just the technical challenges, but it's also that they need to juggle multiple business needs multiple project managers that leveraged program managers on the business side that are asking for things for different jurisdictions for different programs, each one of these delivery teams, works with multiple programs at times, multiple ones of them, you know, have demands needs that have some time bound aspect to it. So managing opportunity cost, cost of delay making some tough choices and what to focus on what we can afford punting on. You know, that's a really, really what what I saw was, they have their work cut out for them that that's like a really tough job. And it requires a lot of partnership and ability to influence and educate, you know, the business people on the impact of things, the sort of stances that we want to see in effective product owners.

Dave West  27:14  
Yeah, I think that's really interesting. I mean, transparency, managing stakeholders, managing value as well. I mean, not that. I mean, all your customers are awesome, Steve, I'm sure but there's certain situations that merit more focus than other situations. And that's, that is a very political complex. The loudest the loudest salesperson is not necessarily the most important or is right, in a situation. So it's complex. So it's been going a while you're seeing improvement? Is everybody kind of seeing this value being delivered? Steve? Yeah, it's,

Steve Lizotte  27:55  
you know, I would say that we're, we're probably mid mid flight with this transformation. I think we're practicing scrum pretty well, right now. I think everybody's gotten into the routine. I'm seeing some cultural changes starting to emerge. And primarily around just how the teams are communicating both, you know, when they're doing sprint planning, or as a team, or, you know, communicating with other teams. In when we first started it, I would characterize the communications as really being driven by one or two people within a team, you know, and it was you jump into a sprint planning meeting, and boy, it's really quiet. And there's only one or two people doing the talking. And more recently, I've jumped into them. And it seems like everybody is really engaged, right. And so for me, that that was huge to see. Right? I think that there is no trust issues on the team, the team is really open, encouraging people, people are jumping in and doing things without necessarily being assigned a task. They're seeing something that needs to be done, and they're moving forward with it. So I think we're at that point there. Now, having said that, I think we need to make a little bit of a step function seems like we've plateaued a little bit, in some of the things we're starting to look at, and how to measure and how to really just get us to the next level are around, you know, flow in looking at where work is queuing and, you know, Theory of Constraints, you know, the whole Phoenix Project, you know, set of problems, right? Automation, really trying to drive and in mature our automation or pipelines, or testing and so on. So, I'm very encouraged that we'll be able to make that next step. Because, you know, the team seemed to be seem to have embraced all of the processes and the in the culture is now starting to change a bit.

Dave West  29:48  
Yeah, for my experience, you definitely need that baseline of agility there I call it that, and then flow metrics and the things that you're talking About become useful if you start with those. Yeah, you haven't got an organization that can adapt to the information that's being presented to it. So I think that that's, that's, that's really interesting, we

Steve Lizotte  30:14  
totally changed the metrics that we're tracking. And we started out, we had dashboards that had, you know, the burn downs, and the velocities and all of that stuff. And, you know, frankly, we reached a point where, okay, you know, we can see that the teams are now practicing Scrum. They're collecting these metrics, great. But work was still queuing up, there were still silos in the organization, there were still all of these issues, you know, in that, those are the problems we were really trying to solve from the get go. So we ditched a lot of those classic metrics. And we get together now once a month with each of the teams. And we go over just, you know, flow and how, what was the last retrospective? Like, what were the problems that you identified? And you know, do you need any help overcoming them, and we actually had a very good conversation with a few of the teams this past week around, you know, build environments, you know, the builds are too slow. You know, it takes us an hour and a half. But between the time we press the button to compile, and we have something that we can test, like, Okay, well, wow, that's a problem that sounds relatively straightforward. And something that we can solve for you that would really save a lot of time and improve productivity and efficiency. So those are the types of discussions now that we're starting to engage in. Wow.

Dave West  31:34  
So I just took me back to my my misspent youth of products like build Forge and the like, where I, I spent a lot of time worrying about C++ compiler systems and how and build velocity as it well build speed. So that thank you for that, Steve. I haven't felt that young in years. Yeah, what about you? What's, what's your perspective of, of how it's gone? And the success that that NEC is gleaned from this program.

Yuval Yeret  32:06  
The one thing I'll add here to what Steve described, as you know, me, I really like the move away from some of the classic, you know, metrics people associate with Scrum, to you know, what, let's call it evidence based metrics that we're talking about. I think flow is a great start. And it's fascinating the the conversations I've had with Steve and you know, some of his leadership team around how does Theory of Constraints play in here, there's the whole thinking around, you know, applying it there. That's been fascinating. And there's a lot to do in bringing TOC together with with Scrum. I'm thinking that Steve and I need to have more conversations about evidence based management, because I think there's some good stuff that we could take beyond flow metrics to talk through what's currently, you know, an impediment to this team's ability to innovate to their time to market? And would it be interesting to look at the current value of the things that they're delivering? And what's, what are some gaps? So that's definitely a conversation we'll have offline.

Dave West  33:27  
It is a pattern that we that I say a lot where as you build the capability than the muscle memory, the the capability of actually delivering value, and then suddenly, it's like, what are we actually delivering? How are we prioritizing? Where does you know what most of this stuff is? Just keep the lights on? Where's our innovation really happening? You know, what is time to market really is measured? Is it the ability for a product to have it? Or is it the ability for one of your program teams or delivery teams to pick it up and use it? Is it how fast are customers using these features, all of that stuff becomes becomes really relevant, but it only becomes possible because of the great work you've already done, Steve.

Steve Lizotte  34:11  
That's, listen, we've come a long way. And you've always been a great coach. For for me and for the whole team. And you're really looking forward to this next phase. We just, we haven't talked too much about safe, but we just started trying to implement Pei planning. Back in January, we had our first one, we had a second pie a couple of weeks ago. And trying to do the same thing. Let's try and get it going fail a little bit. And then you know, bring somebody like you've all in to set a straight and maybe here's some of the problems and the pain points that we're going through. So in addition to flow you volunteer don't throw that on your on your backlog.

Dave West  34:52  
Yeah, I think you know, long as you've got great teams with clear alignment to outcomes, and things like pie planning and save, compare really good tool. Otherwise, it just accentuates the bad practices you have already in your organization in a very efficient way, which is always, which is always a bit of a bit of a worry. Alright. So, last question. I have to ask this. And I'm sorry, we could talk for days about this. I'm, you know, I think that the journey that you went on, Steve is, is a really interesting one, and something that I think many of our listeners can can learn from, but we have to call an end to it. But I do have one last question. If so, I'm sitting, maybe standing or maybe walking and listen to this podcast, you know, a lot of people I know, you've all always listens to podcasts while moving, you know, that they're listening to it. And they're thinking, they're in a similar position. You know, they've got customers that have got needs, they've got a massive of teams and services and capabilities, and they want to get better, what would be the one or two things that you would say, Hey, this is what you should focus on. This is where you should start. I'd love to hear your perspective, Steve.

Steve Lizotte  36:05  
Well, that's a good it's a good question, Dave. I mean, I don't know. Let's see, yeah, I think you're very generically speaking, I would say don't try to bite off too much. I think my advice would be start small, find a problem that you have in the organization, and then go backwards and figure out whether it's safe or just, you know, the, the basic agile, the basic scrum handbook, see what the solution is that's prescribed? Start small, try it, if it doesn't work, then try something different. But don't just try to go, you know, cold turkey and stop what you're doing and try something completely new.

Dave West  36:43  
Right now. Yeah,

Yuval Yeret  36:45  
I think, you know, it might be interesting to reflect back on how we started this journey, and how we kind of chose to use professional Scrum and use the scrum guide, and, you know, visual scrum with Kanban. At NEC, Steve used safe, we use safe that, you know, a previous engagement, because, you know, we had this scale where it made sense. And there were some valuable aspects of safe that we use there. But we made a conscious decision, when we were thinking about it here at the NEC that, like Stevie saying, it might be too much, especially upfront for teams that have no, no idea how to use the agility. So said, Okay, what is important? What's the baseline foundation that they need to understand. And, you know, it was pretty obvious to me and, you know, I brought Steven the team on board that that's professional Scrum, and combined with the flow perspective that professional scrum would come and provides. And, you know, we managed to create teams that can really own something that's, you know, we talked about the program and product, we created a situation where we don't need to scale, we actually scaled a lot of the issues. So most of the concerns happen within teams. And, you know, there's some level of collaboration that is needed, we do want, you know, some the right level of collaboration between the product people and the program people and maybe across different programs. And now, you know, Steven, the team now that they have a solid base of professional Scrum and flow and understand why they're doing this, now's the right time to start to pick some stuff from, you know, other other patterns, scaling patterns now there, they can safely go and take a look at the Scaled Agile Framework site and, you know, take some stuff from there that works in their context that may be works in their context. That's

Dave West  39:03  
awesome. That's great advice. Gentleman, thank you for taking the time out today to share your story of our listeners to share it with me. I certainly learned a lot and I really do appreciate you taking the time.

Steve Lizotte  39:17  
No, thank you, Dave, and good talking to you again. You've

Yuval Yeret  39:20  
all Thank you, Steve. pleasure as always, they've

Dave West  39:25  
okay, you heard it today you heard an interesting story about advanced recognition systems have any say in their journey to agility and how they incrementally started took it, building that professional scrum capability, adding flow and now we're looking at at scaling and the next step, the separation and programming with delivery teams from product teams and the challenges of product ownership and how valid and useful that though the accountabilities are, even at that delivery team level. I've certainly learned a lot today. Hopefully you did. And thank you for listening. If you liked what you heard, please subscribe, share with your friends and of course come back and listen to some more. I'm probably the luckiest person in the world because I get the opportunity to talk to these variety of guests we heard today from many see, and the journeys that they've been on, I always learned something that pragmatic but valuable use of professional Scrum and how it connects with things like flow metrics, EBM and even safe so thank you for listening. And hopefully we'll get to talk again or listen again, by by and Scrum on