WEBVTT 00:00:18.000 --> 00:00:31.000 Crim team program is run by volunteer professionals. As a platform for volunteer professionals to learn and experience scrum fundamentals and other agile frameworks and practices through the process of immersion. 00:00:31.000 --> 00:00:43.000 Svpn's vision is to continuously build. Next generation of practitioners. And develop professional leadership within our global society at large. 00:00:43.000 --> 00:00:51.000 Svpn's mission is to create a community of agile practitioners and leaders by offering hands-on collaborative experience. 00:00:51.000 --> 00:00:58.000 From the trenches sharing lessons learned and best practices on products, projects. And portfolio management. 00:00:58.000 --> 00:01:14.000 . Team program the SVPM scrum team program is the program that supports the ongoing functions and operations of the Silicon Valley project management website and blog post. 00:01:14.000 --> 00:01:20.000 The Silicon Valley Project Management LinkedIn page and ASVP. Meetup events like this. 00:01:20.000 --> 00:01:24.000 Just the name of you. Our guest speaker today is. And we're honored. 00:01:24.000 --> 00:01:31.000 HSVPM is honored to introduce our guest speaker, Dr. Nathan P. Cruz, PhD. 00:01:31.000 --> 00:01:39.000 Nathan is an accomplished senior leader with comprehensive experience and is well known for delivering tech solutions globally. 00:01:39.000 --> 00:01:52.000 He is a tech instructor for Caltech and you see extension programs. Nate coaches corporate clients worldwide including Acatel Lucent, ATT, Chevron, Boeing, and more. 00:01:52.000 --> 00:02:09.000 NAT is an enterprise business agility strategist. And a certified transformation. Leadership coach with expertise in team performance coaching executive coaching organizational development coaching life and spirit coaching. 00:02:09.000 --> 00:02:20.000 And neurologistic programming. He holds a bachelor's in math, computer science, and MBA, and executive masters in technology management. 00:02:20.000 --> 00:02:25.000 PhD and management information systems. 00:02:25.000 --> 00:02:31.000 The title of Nate's talk today is Mastering Agile Systems Engineering for Agile Practitioners. 00:02:31.000 --> 00:02:33.000 It's all yours. 00:02:33.000 --> 00:02:44.000 Okay, well thank you very much, I appreciate, you give me that wonderful introduction and David for thank you so much for inviting me to this awesome crowd here that you brought together here. 00:02:44.000 --> 00:02:56.000 So how's everybody doing today? So my goal is over the next 45 min is to go through and give you a presentation on what I call agile system engineering. 00:02:56.000 --> 00:03:13.000 It's a topic that I've been delving down into here recently because I think agility has gotten to the point where it is not only surfacing just software, it's hurt servicing hardware, services, the way people work. 00:03:13.000 --> 00:03:26.000 And having a framework and the discipline of system engineering integrated with it as a partnership, I think brings it to a place of extreme increase in value to our customer set. 00:03:26.000 --> 00:03:36.000 So again, thank you very much for allowing me this time to talk with you here today. So I want to talk about a background after I kind of go over. 00:03:36.000 --> 00:03:50.000 You know who I am of what the current landscape looks like. And then we'll talk about a background of agility, a little bit of background, a system engineering, kind of meld those together and talk about what's agile system engineering is. 00:03:50.000 --> 00:03:57.000 We'll talk about some, some basic capabilities out there that can help augment this whole topic. 00:03:57.000 --> 00:04:03.000 And then we'll talk about some frameworks that I've seen utilized here. Along the way. 00:04:03.000 --> 00:04:12.000 And then we'll have some questions and answers here along the the session here. If you could be kind enough to hold off the questions to the end to give us a flow. 00:04:12.000 --> 00:04:16.000 And, but I will answer all your questions as I told David, I am here for you today. 00:04:16.000 --> 00:04:23.000 You can't have a better agility mindset than that, okay? So first of all, let's get going. 00:04:23.000 --> 00:04:27.000 Who am I? I'm just a guy. You know, a guy that grew up in outside of Philadelphia and Chester PA here who's done a lot of things. 00:04:27.000 --> 00:04:40.000 So I've had a 43 year career. That I've gone through. 23 years have been working DOT type project here where we did. 00:04:40.000 --> 00:04:58.000 Development on things. Such a satellite systems and defense systems for the government very very structured very disciplined and I learned to embrace and appreciate that and I had roles such as a soccer developer, a system integrator, system engineer. 00:04:58.000 --> 00:05:10.000 Product leader project manager and in the program management in that role. Then I got on fire with the agility about, 20 years ago, took my first agile class and started learning about that. 00:05:10.000 --> 00:05:22.000 And I said, this is an amazing way of getting things done and working. And it seems like the one element that I always found missing from system engineering was it seemed to be fun and had an ownership element to it. 00:05:22.000 --> 00:05:36.000 So I got all in on that, took a lot of certification. So I've also taught a lot of classes internationally and personally got to meet a lot of wonderful people here, taught many hours of quality instruction. 00:05:36.000 --> 00:05:43.000 I've had over 55 certifications. I just went and did check that check that out on my LinkedIn account. 00:05:43.000 --> 00:05:50.000 In one way, he said, wow, in other ways, is it man? This guy does not get out much and that probably does quantify who I am. 00:05:50.000 --> 00:05:58.000 So I'm a senior instructor and partner with Caltech. We go out and look for valued ways of coming up with customized instructions. 00:05:58.000 --> 00:06:08.000 We'll talk to you about that later. I've been a systems engineer. I, MP certified and also at the program level certified. 00:06:08.000 --> 00:06:15.000 I'm certified as a business analyst, a systems analyst. I am agile framework agnostic. 00:06:15.000 --> 00:06:18.000 So I know discipline agiles, say scrum combine, but I don't come with you with one of those as the hammer of solution delivery. 00:06:18.000 --> 00:06:31.000 I listened to the customer to understand what's your problem, what you need, what's the circumstance and environment you're working in to get things done. 00:06:31.000 --> 00:06:48.000 Also, again, I've, was able to get a master's degree in technology management for Morton and also my recent I call it blood letting by my 10 years of going through to get my doctorate in management, organizational development and system engineering. 00:06:48.000 --> 00:06:59.000 I've been known if you come out to the clubs in Manhattan Beach to come out and sing a little bit of karaoke from time to time, but that's how I keep myself sane instead of staying inside all the time. 00:06:59.000 --> 00:07:07.000 So let's go here and start talking about this. So those of us who've gotten to agility and system engineering, we support many different industries. 00:07:07.000 --> 00:07:17.000 And a lot of them have been talking about the topic of a jury. And a lot of these things in transportation, automotive, medical, defense. 00:07:17.000 --> 00:07:24.000 A banking. Did I forget somebody? Yeah, I did. Even software from its initial inception of how agility should been. 00:07:24.000 --> 00:07:30.000 But you lies has expanded out to be very, very complex with many different partners. Along the way. 00:07:30.000 --> 00:07:45.000 So I advocate and have been diving in and doing research that agility by itself is fine and has a lot of great elements for empowering teams and things getting things done but we also have to go in a constant decision space. 00:07:45.000 --> 00:07:54.000 Of looking at yes going fascinating value but stability too. And as we move along the spectrum between the 2. 00:07:54.000 --> 00:08:12.000 We have to always take into consideration of risk and how risk is influenced by the faster we go. Can influence other stable products and services we deliver and how to keep that in balance so we're giving a seamless delivery of customer rapidly to our customers. 00:08:12.000 --> 00:08:17.000 So why system engineering here? Well, IA lot of the things, agile system engineering, well, we take advantage of agility of the flexibility and adaptability of the core capabilities of agility. 00:08:17.000 --> 00:08:33.000 Well, we look at those things associated with Scrum and Con Bond. Safe and less and all the different frameworks are getting things done. 00:08:33.000 --> 00:08:41.000 But we also want to embrace change in iterations. And frankly, system engineering and agility does both. 00:08:41.000 --> 00:08:42.000 But also as we going through this activities, we also have to be mindful of limitations that are not going away. 00:08:42.000 --> 00:09:03.000 We have to have a resilient stable systems that also have to take into account of delivering on time and also delivering within cost parameters and I also think that when we look at system engineering the discipline of setting up the structure adds a more comprehensive risk component. 00:09:03.000 --> 00:09:17.000 In agility we say by doing things in smaller increments and learning and through progressive elaborations we mitigate risk but risk becomes more prominent as we look at more and more complex solutions as we go forward. 00:09:17.000 --> 00:09:31.000 So, I look at agility, it's, it's about the whole transfer of being, and, more than just Doing agile doing agile would just be doing the practices that gives you a little bit of, improve value. 00:09:31.000 --> 00:09:46.000 Embracing the mindset, the values and principles and aggregate them as a value delivery system puts together more comprehensive expansion of that. And it's about delivering things in increments. 00:09:46.000 --> 00:09:47.000 Okay. 00:09:47.000 --> 00:09:59.000 And and getting feedback on the cover and all stakeholders on how you're doing and having the ability not only at the end to deliver functionality if requested we can deliver incremental deliveries by the customer if they feel like you start getting value from that immediately. 00:09:59.000 --> 00:10:05.000 So that's one of the some of the great things that we'll talk about from agility standpoint. 00:10:05.000 --> 00:10:13.000 But then when we talk about system engineering, it is a methodical way of looking at complexes. Satellite systems, transportation systems, energy systems, even finance system with some of their complex. 00:10:13.000 --> 00:10:41.000 Derivative calculations can be a complex activity for us to take in consideration here. So sometimes we need a little discipline in how we engineer upfront, maybe a little bit more than agility, but also take in a agility and feedback principles into Cal as we're delivering out to our customers. 00:10:41.000 --> 00:10:49.000 Now, how do we do this? So the concept of agile system is the principle based off of designing, building, sustaining, and involving. 00:10:49.000 --> 00:11:02.000 It, in an environment of uncertainty. So we go through and start out and take the very linear sequential way of delivering things from concept, all we down to retirement is what we take take an account with system engineering. 00:11:02.000 --> 00:11:09.000 And we say, let's do this. With a center node of situational awareness. What is the situation I'm dealing with? 00:11:09.000 --> 00:11:20.000 Does that always take constant? Probably not. So let's use that as a note of having to be make able to make decisions and move around, yet go through the process of doing. 00:11:20.000 --> 00:11:21.000 The concepts all the way around to developing the system. I'm doing a great job of marking this up. 00:11:21.000 --> 00:11:39.000 Then supporting it and at some point realizing it no longer has value to get things done. So Along the way, some of the elements of agility come into play early in the conceptual development. 00:11:39.000 --> 00:11:54.000 Faces of making sure we get the value deliverable in place on the system correctly and then some of the ways of managing or evolving the system of system engineering come into play later on as we go through the process. 00:11:54.000 --> 00:11:59.000 Now one of the staples of doing agile, excuse me, system engineering development is the V diagram. 00:11:59.000 --> 00:12:00.000 Hmm. 00:12:00.000 --> 00:12:17.000 So to V diagram takes us to the process of a a defined mission of some large organizations. They go through and do some feasibility studies, is it possible, come with a concept of operations which is used as the basis to build your system requirements of many levels. 00:12:17.000 --> 00:12:26.000 Your high level design to detailed design, a software design, and then we go up the other side of testing it from a unit all the way up to the system point. 00:12:26.000 --> 00:12:36.000 Then we put it into operation. So this has been a staple of how some complex embedded systems have been developed over time. 00:12:36.000 --> 00:12:46.000 Does we go through and look at this here? Some of the benefits of, of agile system engineering is we, look at the edge our principles. 00:12:46.000 --> 00:12:52.000 Scrum is a very favorite way of doing it. Kon Bond is another. There's others we could look at here and talk about later. 00:12:52.000 --> 00:13:00.000 Also doing things in iterations allows for us to see Parts of decision as it's growing and evolving over time. 00:13:00.000 --> 00:13:09.000 So it's not a situation where we are looking at it at the very end. And then realizing, yeah, we built it up to the requirements, but it doesn't. 00:13:09.000 --> 00:13:39.000 Meet the current mission of our Our current constituency in the stakeholders. User collaboration at all points we want to have user collaboration and feedback what's going on when you currently that we need to change and evolve how we're doing on this to become it more valuable when we finally deliver. 00:13:43.000 --> 00:13:44.000 Okay. 00:13:44.000 --> 00:13:49.000 And then cross functional teams with different mindsets that all have a voice in this and as we have a cross-functional team, we implement them hopefully to be self-organizing, we have some kind of facilitating role like a scrum master that comes in and helps us to stay on track but works with us along the way. 00:13:49.000 --> 00:14:01.000 And embracing change and allow to do this. So we're using some of the discipline of system engineering and some of the flexibility of the agility, melding them together along the way. 00:14:01.000 --> 00:14:04.000 Now what I've seen towards this is Dr. Douglas and I'll show you a copy of his book later on. 00:14:04.000 --> 00:14:16.000 He's done a great job of introducing agility into The space of system engineering. But I think the balance on is looked off. 00:14:16.000 --> 00:14:22.000 It's more. Dominate by system engineering. It's not really embracing all it could be. 00:14:22.000 --> 00:14:29.000 From respect of agility and how agility can add in to get things done. It's more focused on practices. 00:14:29.000 --> 00:14:45.000 Versus the embodiment of cross-functional team so I'm trying to do some research in studies that will eventually lead to to papers, classes, talks, and maybe even a book or 2 with the right kind of supporting personnel. 00:14:45.000 --> 00:14:55.000 Some of the challenges that we run into here, if we have larger systems, particularly those that affect health, life, and things that happen, particularly in aerospace industry. 00:14:55.000 --> 00:15:01.000 We have regulations that we have to meet, whether we do agile or not, they still need to be put in place. 00:15:01.000 --> 00:15:06.000 Now agility, yesterday one agility, yes, it's fabulous, but you still have to have these. 00:15:06.000 --> 00:15:20.000 What I call limitations. Also large scale systems have a complex situation complex customer relationships along the way. And agility was born out of software by what I. 00:15:20.000 --> 00:15:25.000 Let's say those who were disgruntled with the heaviness of waterfall. And looked at a lighter way of delivering things. 00:15:25.000 --> 00:15:35.000 It's still delivering a valid, a valuable delivery to your client. So, but it didn't really take in consideration of hardware. 00:15:35.000 --> 00:15:48.000 So hardware is a different animal. It's not as. Pliable as software. If I have a defect on the shroud of a spacecraft, I can't go through with my eraser and kind of scratch out the defect. 00:15:48.000 --> 00:15:57.000 I have to develop that whole Stroud over again. That could be millions of dollars of waste. That's why the discipline of system engineering comes in place. 00:15:57.000 --> 00:16:10.000 Luckily for us though. Lean manufacturing, agile manufacturing has looked at some of these cases and looked at ways of becoming agile in a hardware environment and we want to integrate that into. 00:16:10.000 --> 00:16:26.000 And safety as we're looking at aircraft systems come into play too. So as we're going through and try to accelerate the delivery of things, we have to accelerate the right rate to to incorporate the stability of a safe system as we go forward. 00:16:26.000 --> 00:16:34.000 We also have to deal with legacy systems. They don't go away and some of those legacy systems are those that we have to support as we go forward. 00:16:34.000 --> 00:16:48.000 We also have a complex relationship of suppliers and customers that are ever changing. Some as we get into our defense customers, we have security elements where I may have some amazing knowledge to support you on your project. 00:16:48.000 --> 00:16:52.000 However, there's a security compartmentation I don't have, we can't talk. 00:16:52.000 --> 00:17:07.000 So we have to find ways of getting around that. And then we have complex stakeholder relationships. The end user might be The pilot of a cup, a very complicated stealth aircraft. 00:17:07.000 --> 00:17:12.000 Well, but the in user that I talked to might be a minor or aerospace corporation that is the intermediary for that pilot and they talk to them and then talk to you. 00:17:12.000 --> 00:17:21.000 That is the intermediary for that pilot and they talk to them and then talk to you. These kind of relationships and challenge is to talk to them and then talk to you. 00:17:21.000 --> 00:17:30.000 These kind of relationships as challenge as to how we integrate agility into the space. Now, any way we look at this, we can't look at integrating agile or system engineering and say, hey. 00:17:30.000 --> 00:17:36.000 This one frameworks. Scrum, put in Scrum, all your problems go away. Put in combat or say. 00:17:36.000 --> 00:17:44.000 No, it requires a very mindful, thoughtful way of looking what's out there. First of all, what is the problem? 00:17:44.000 --> 00:17:46.000 That we are addressing here. How do we face that? How do we deal with it on a regular basis? 00:17:46.000 --> 00:17:55.000 And the plan carefully on how to implement this, take into consideration. The level of knowledge of the stakeholders. 00:17:55.000 --> 00:18:07.000 The culture. The willingness to accept experimentation sometimes in your more complex systems is like, you can experiment at home, not here at work. 00:18:07.000 --> 00:18:19.000 But some of those are experimentations is one of the tenants of being agile. So we have to look at a mindful way of implementing this and come up with tailored solutions, their best service to clients along the way. 00:18:19.000 --> 00:18:22.000 That takes a level of consulting and change aid to capabilities that need to be learned over the times of years. 00:18:22.000 --> 00:18:37.000 Some of you have probably learned it already, so I'm not asking you to learn something new, but you just bring that into the tool set that we go for and deliver forth with. 00:18:37.000 --> 00:18:41.000 So as we look at this lifecycle of agility, we're not taking anything away from either side, but we're asking it to look at a different framework. 00:18:41.000 --> 00:18:54.000 Where the the The edgeile Systems Engineering lifecycle is about awareness of what the situation that is going through and what is the need? 00:18:54.000 --> 00:19:03.000 What is the opportunity? Conceptualizing that and you can conceptualize that by using principles of system engineering and agile. 00:19:03.000 --> 00:19:14.000 Either together or exclusively. We develop the requirements that are made and looking at the requirements in many different ways is used cases or user stories or just regular requirements. 00:19:14.000 --> 00:19:31.000 We produce and validate and build the solution. And then we transition it into operations and then we were actively with the end of in client to make sure that we maximize or find tune the solution to deliver. 00:19:31.000 --> 00:19:37.000 For the customer. And then as any system goes for it, we make sure we support it. And then we at some point when it comes time to retire systems we have a measured way of retiring the system. 00:19:37.000 --> 00:19:51.000 And again, the agility and system engineering are each one of these inner tip activities we're doing are baked in. 00:19:51.000 --> 00:20:02.000 We'll talk about that at the next level down, but this is the highest level of how we want to have a disciplined way of delivering the complex systems that our customers are looking for. 00:20:02.000 --> 00:20:09.000 And again, this is just another way of looking at it. Some of the skill sets that we bring in an agile and system engineering. 00:20:09.000 --> 00:20:17.000 We look at things by delivering by features and those features sometimes prioritized based on the voice of the customer. 00:20:17.000 --> 00:20:23.000 We have a shared knowledge base of what has happened before so we don't stop our toe and get things done. 00:20:23.000 --> 00:20:33.000 We have integrations that have a continuous pipeline of delivery to deliver as quickly as possible to our customer, yet always being mindful, there has to be a value delivery. 00:20:33.000 --> 00:20:40.000 Things like DevOps come into play here. We talk about commissioning teams to go and support things. 00:20:40.000 --> 00:20:47.000 We're talking about development activities. We talk about decisions that come into play in all types of medical applications or. 00:20:47.000 --> 00:20:59.000 Transportation applications or defense application and always be situational where and have the systems available and nimble to address those outliers situations and still deliver. 00:20:59.000 --> 00:21:03.000 Frequent value to the custom. 00:21:03.000 --> 00:21:10.000 Now, how do we do these things? Now, what is to take the classic V model and look at ways of at each level. 00:21:10.000 --> 00:21:22.000 Iterate have feedback along the way so we're getting feedback and not just going down The line here directly If we iterate here within each one of these. 00:21:22.000 --> 00:21:45.000 Tears up at our concept level. Iterate and get feedback. How's that doing? When we look at Dcod ops, when we look at the requirements document of the system of systems and the other system or subsystems, we iterate the development of all these activities so that we were using agile, we're using cross functional teams, we're giving voices to everybody in the process, not just the 00:21:45.000 --> 00:21:50.000 leadership, to give insight on how to make this better. So we iterate within a model one way here. 00:21:50.000 --> 00:21:56.000 Now one thing I am big in adding into what we'll talk about later on. Model-based system engineering. 00:21:56.000 --> 00:22:01.000 That's what instead of taking a model of taking requirements and dealing with them as a static unit. 00:22:01.000 --> 00:22:12.000 Of something of a need of the customer we model against it to help us clearly identify what is possible with this requirement as far as delivering value by using it. 00:22:12.000 --> 00:22:20.000 The power and the capabilities of computers to iterate to get things done. We also take in consideration many different architectures along the way to get things done here. 00:22:20.000 --> 00:22:27.000 Along the way. So these are some things that could be chatted about talk about in a later, presentation. 00:22:27.000 --> 00:22:35.000 So I want to dive too deeply into it because I want to stay within my time constraints and also keep moving along here. 00:22:35.000 --> 00:22:49.000 So let's now we talked about this system engineering again is the partnering of a complex discipline engineering approach of delivering high value systems or complex embedded product with agility. How can we add value? 00:22:49.000 --> 00:22:52.000 How can we make it faster? How do we make it nimble? How can we make this customer centric together? 00:22:52.000 --> 00:23:01.000 And make a powerful combination here. So what are some of the techniques? Well I want to talk about some techniques to support it first of all. 00:23:01.000 --> 00:23:08.000 First of all, the question is, do I do agile development? Or do I do edge out integration? 00:23:08.000 --> 00:23:13.000 What do I mean by that? Now I'm sitting here with a computer system here. I have a wide screen. 00:23:13.000 --> 00:23:26.000 Curved, 42 inch. Screen i have a Mac Mini processor connected to a customized keyboard that fits my needs. 00:23:26.000 --> 00:23:38.000 I have a mouse that I have here along the way. Now I could have developed this but and going to when and done a development or I could use cots commercial off the shelf or government offshelf capabilities. 00:23:38.000 --> 00:23:51.000 Integrate those 2 common interfaces and come with an agile system. So at a later date, I need a different mouse, a different storage system, you disconnect from what you have right now, identify a proven. 00:23:51.000 --> 00:24:03.000 Good point that works for you. And integrate that in through a common interface. Now I would tell you doing agile system development is more difficult and more customized and more tailoring to some of the situations. 00:24:03.000 --> 00:24:12.000 But we add we have to ask the question. In the end we need to agile system so can we configure existing proven capabilities? 00:24:12.000 --> 00:24:18.000 That work and testing them together and save time and money. So that's one question we want to do here along the way. 00:24:18.000 --> 00:24:29.000 That's one of the first questions I asked in this system engine activity. Do you have to build it or do you have to evolve a valued system? 00:24:29.000 --> 00:24:41.000 Now as we look at these approaches here, we want to go through and design it. As part of the design, you have to have some upfront, behavioral and requirements analysis of what needs to be done. 00:24:41.000 --> 00:24:47.000 And supporting this, I believe, truly is model-based system engineering, which I will talk about in a few minutes. 00:24:47.000 --> 00:24:53.000 It allows us to look at many different use cases and many dimensions of the requirements helps us to accelerate. 00:24:53.000 --> 00:24:59.000 The development of our high-level design and do trade studies to help us come up with the specific component that satisfies that design. 00:24:59.000 --> 00:25:12.000 And it also gives us some first case attempts at what some of the test cases could be. All of these automated things by the computer based off of our known information that we collect. 00:25:12.000 --> 00:25:25.000 Excel rates how we can Expand the look of a certain capabilities, but also. Accelerate delivering of them of the customer and give them a more comprehensive quality system. 00:25:25.000 --> 00:25:32.000 So model based system engineering is about taking the source requirements and then looking at it from the standpoint of the functional behaviors, their architectural behaviors, and the design validation systems. 00:25:32.000 --> 00:25:42.000 And their actual software's and I'm not gonna go into them called Sysml is the modeling languages. 00:25:42.000 --> 00:25:46.000 And, very, different, 00:25:46.000 --> 00:25:56.000 Model based system engineering languages that can go through here and help you. To go through and set the system in many different ways. 00:25:56.000 --> 00:25:57.000 Hmm. 00:25:57.000 --> 00:26:03.000 And come up with some powerful realizations that we can discuss. So we're not always starting from scratch and going to the whiteboard and figuring things out. 00:26:03.000 --> 00:26:11.000 The model goes to and gives us some conceptual ideas to look at. That could take days and months. 00:26:11.000 --> 00:26:21.000 It provides that for us for our consideration to modify and tailor. I'm a big fan of model based system engineering as part of this agile system evolution. 00:26:21.000 --> 00:26:26.000 Now DevOps, we have, once we deliver it, we have to have a pipeline to test it. 00:26:26.000 --> 00:26:37.000 And put it out for the customer to deploy any one at 1 point that we want to have here. So with this comes in the whole concept of DevOps and it's many different ways and components of doing that. 00:26:37.000 --> 00:26:42.000 DevOps is how after you built it, whether it's code, software, or a solution. 00:26:42.000 --> 00:26:54.000 Need to be tested put into a delivery environment. That's maintained by our our team but also is the customer has access to and that's one of the enabling capabilities of agility. 00:26:54.000 --> 00:27:11.000 And system engineering. We also have to think about lean thinking. It would be amazing if you go through and look at the existing systems that we have right now and did a lean thinking approach and lean out took out the waste and the redundancy of what they see along the way. 00:27:11.000 --> 00:27:31.000 This takes out a lot of cause quickly. It also is a good selling point for agile system engineering because if you can see that putting in the time to investigate to look at these things can easily help us come up with the funding necessary to fund later activities. 00:27:31.000 --> 00:27:58.000 Now AI is everywhere. So the knowledge that we have here, particularly with a large body of the baby boy retiring, trying to get that knowledge into a base we could utilize going forward so we don't have knowledge leaking and we have deep learning and using cloud based activities here in bots and you know chat GBT seems to be taking over our world and it's caught us by surprise but it's something that we have to go through 00:27:58.000 --> 00:28:10.000 and live with as we go forward here. Also data analytics one of my mentors, Scott Amler who was big into the development of discipline agile has been diving down into agile data analytics. 00:28:10.000 --> 00:28:21.000 Cleaning up the data, supporting the finance industries here. And this data will be in most systems we have of any level of complexity and having a way of harnessing that. 00:28:21.000 --> 00:28:34.000 Cleaning it. Exploiting it. And forecasting what the needs are of the future will be a dominant capability as we look at this agile Cincinnati space. 00:28:34.000 --> 00:28:41.000 So now let's, now I've gave with some, basic techniques along the way and I could have spoke of many more but that was just a few. 00:28:41.000 --> 00:28:49.000 Now we want to talk about agile system in a line developing frameworks. And to that point, I am agile agnostic. 00:28:49.000 --> 00:28:58.000 If waterfall works fine, if Strum works if safe works. It's all about what the customer needs is the way that I advocate going here. 00:28:58.000 --> 00:29:11.000 But let's look at some that I think to have some really reasonable capabilities look at. First of all, out of the Encosit group, they came up of looking at looking at how we could go through and do a standard delivery process. 00:29:11.000 --> 00:29:22.000 Where you do this with more agile in mind where your planning team comes up with a back backlog of the requirements here and you have your architecture team that doesn't pre planning. 00:29:22.000 --> 00:29:42.000 And as we go through and start doing the development. The architecture team, the and the development team the implementation team and the integration and test team works in tandem aggressively to develop the first iteration to its intended goals and solutions from iteration one. 00:29:42.000 --> 00:29:54.000 2, 2, to in. But, to n minus one. But in, we get to the point where we bring the planning team back in to verify and validate that we have delivered what the customer wants along the way. 00:29:54.000 --> 00:29:57.000 Now there is customer. Involvement as we go through these iterations and approval. And review as we go along. 00:29:57.000 --> 00:30:16.000 So we don't leave them out to the end, but they are part of the acceptance criteria at the end. 00:30:16.000 --> 00:30:26.000 Now, there are incremental ways of spiral development. Some organizations really don't embrace the concept of strong because Well, where do I find scrum masters? 00:30:26.000 --> 00:30:28.000 Why do I, why do I only refer to people as team members? Where does the product owner fit in? 00:30:28.000 --> 00:30:38.000 So sometimes we look back at Precursors to scrum activities, we have incremental. 00:30:38.000 --> 00:30:52.000 Spiral development, which has some of the iteration activities it goes through here and goes to an iteration and uses some of the activities that you would have through a normal delivery process of a complex system, but do them in iteration over time. 00:30:52.000 --> 00:31:02.000 So we have phases which could be considered your sprints or your incremental time periods, then we would do things along the way here to get things done. 00:31:02.000 --> 00:31:10.000 So we could have an incremental way of doing committed spiral model is one of the things that is advocated in the in COSI space. 00:31:10.000 --> 00:31:20.000 As PNCC is the International Council for System Engineers and some of the things they advocate to do to be more agile. 00:31:20.000 --> 00:31:35.000 We also could do all things on a feature based capability and we and there is a framework called feature FDD, design capabilities that can be done from agile standpoint. 00:31:35.000 --> 00:31:53.000 But it also looks at the features are necessary and having subject matter experts that are aligned to each line of things where you have a special team associated with requirements, modeling, coding, or you may have that you may have special teams associated with the deers, the motors, the wheels. 00:31:53.000 --> 00:32:00.000 Of a final product. Have them evolved in a work on this sit on a system and get them up and running as quickly as possible and then integrate that into their lean product. 00:32:00.000 --> 00:32:23.000 In Tesla, has really taken advantage of this they have very aggressive feature teams they're looking how to to quickly evolve the battery capabilities and the chassis capabilities and the mode how to quickly mold out the frame of the car itself. 00:32:23.000 --> 00:32:29.000 And and and adding the acceleration of delivering the product by using those kind of things. And they have on site. 00:32:29.000 --> 00:32:40.000 Creditors there so after they pull a new concept they can quickly get it validated and verified to be implemented and then quickly integrate that into their value chain of delivering to the products. 00:32:40.000 --> 00:32:50.000 So this is one way, feature, feature based product line architecture is one way of coming up a way, a way of streamlining the development of getting things done. 00:32:50.000 --> 00:33:02.000 Now, say, I think in my mind safe as a It's not the solution for everything, but it has taken into account a lot of things necessary. 00:33:02.000 --> 00:33:10.000 To develop our complex systems. It looks at lean, it looks at, it has some thoughts about cloud and big data. 00:33:10.000 --> 00:33:25.000 It looks at AI as components. If It has this accordion effect where you can support it at a program level all the way up to your entire organization and you could build it out as high as you need to and contract it down and it supports your enterprise activities here. 00:33:25.000 --> 00:33:32.000 And government activities. Now I'm not saying go safe. I'm saying it's an option. 00:33:32.000 --> 00:33:41.000 For consideration as we go forward here. There are some other limitations around this. I mean, but it does integrate. 00:33:41.000 --> 00:33:51.000 We see up here it takes into account big data. We look at value streaming. These are all things that will help us at the enterprise ofility delivery level. 00:33:51.000 --> 00:33:57.000 And a lot of these things are baked into this model where I think will be advantageous. 00:33:57.000 --> 00:34:01.000 In addition to that, if you have a question, you hold that to the end. There's discipline ad down. 00:34:01.000 --> 00:34:26.000 So this one, agile, is not so much a agile delivery framework but if a decision-making framework that takes the best of all the different capabilities, combat, scrum, steel, agile list and figures out and even waterfall but figure out what is the best one of those things by having a decision model in all these various areas to go through and make decisions. 00:34:26.000 --> 00:34:27.000 A decision model to get things if you could, that person. 00:34:27.000 --> 00:34:38.000 Okay, Not yet, okay. For 5 more minutes. Okay. 00:34:38.000 --> 00:34:43.000 I'm sorry, you're muted. 00:34:43.000 --> 00:34:55.000 Hey, decision-making framework here by for each one of those items You could break it down and for this addressing risk per se. 00:34:55.000 --> 00:35:00.000 Options on identifying how to look at risk and also tell you the pros and the cons of each solution here so you're making an informed decision along the way. 00:35:00.000 --> 00:35:14.000 That's one of the things where since we're making a Taylor decision in most cases here, you discipline agile as a way of doing that. 00:35:14.000 --> 00:35:20.000 I think it's a very helpful capability for us to add to our toolset if at all possible. 00:35:20.000 --> 00:35:27.000 Now, if we're doing looking at hardware, there are people out in the industry. Which societies that came up with. 00:35:27.000 --> 00:35:37.000 Modified agile for a hardware framework where they went through this process here of taking scrum and some of the benefits of its capability. 00:35:37.000 --> 00:35:46.000 Collecting stories. Integrating that in. And bring it down those out to the non-functional and functional capabilities. 00:35:46.000 --> 00:36:03.000 Integrating those. Into a framework of delivery. Then, then deciding what goes into what iterations and they frame their iterations as iPad, iPad stands for integration, prototyping, alignment, and customer engagement. 00:36:03.000 --> 00:36:19.000 This is another framework if hardware is part of your capabilities for consideration as a framework to use in addition to the main ones that we know that are scrum and Oh, and I jumped to hit here. 00:36:19.000 --> 00:36:27.000 Hmm. Somehow I skipped out some other capabilities here, but. 00:36:27.000 --> 00:36:37.000 Well, let's keep moving with this thought in mind here. Now, I talked about Mastery of these activities and you said, Nate, man, you've been hitting me with fire holes of information here, man. 00:36:37.000 --> 00:36:43.000 I got a job. I'm supporting this new wonderful group here that you've been introduced to here. 00:36:43.000 --> 00:36:50.000 I got children, I got families that want to have some fun. Can you condense it down to some things I can do to help me to master this? 00:36:50.000 --> 00:37:00.000 Okay, these are Nates each. Mate 7 in the final one is sort of like a reference to Nike First of all, understanding the fundamental system engineering. 00:37:00.000 --> 00:37:11.000 And how to do that. To understanding what system, thinking is about. Instead of looking at, at, outcomes, we're looking at emerging properties. 00:37:11.000 --> 00:37:25.000 Of bundling together certain capabilities together it has emerging capabilities such as if you have a motor of a car the chassis of a car the wheels of the car the steering and breaking they emerged to provide the capability of transportation. 00:37:25.000 --> 00:37:35.000 So alarm those capability of of system engineering so that is part of your toolbox. Also learn the whatever the agility. 00:37:35.000 --> 00:37:44.000 Framework of choices that works best with you. Then find out and brainstorm ways of combining them to a solution that works for you. 00:37:44.000 --> 00:37:53.000 For each situation that you have. We will be willing to and find out can this system be a practice of delivering things. 00:37:53.000 --> 00:38:03.000 Incrementally, always be user or customer centric. You can't lose. If you are focused at from a perspective delivering from what the customer needs. 00:38:03.000 --> 00:38:11.000 And evolve with that you can't lose. And then implementing a continuous integration pipeline such as DevOps along the way here. 00:38:11.000 --> 00:38:27.000 It is seek, mentoring and training. So I'm a training organization, but I'm a big advocate of bringing in Those coaches at all level the organization that could distill the information, simplify it so that you understand what's going on. 00:38:27.000 --> 00:38:34.000 So with that, the getting off the stage here, and finally, I guess I would say we just go hit and just do it. 00:38:34.000 --> 00:38:41.000 Nothing experience trumps everything. Now, few minutes that I have here left here, I want to explain who we are at Caltech. 00:38:41.000 --> 00:38:48.000 We're down in Pasadena. We work remotely. We come up with customized unique training experiences for organizations. 00:38:48.000 --> 00:38:53.000 We can do your standard PMP or your system engineering training. We can customize what you do around how you work. 00:38:53.000 --> 00:39:03.000 We've done it for slumber J. We've done this with John Dear. We've done it with North of Grumman and Boeing so that the education is tied to how you would do things. 00:39:03.000 --> 00:39:11.000 We can do things on site. We do one on one tailoring, whatever you need, we're here for that. 00:39:11.000 --> 00:39:15.000 We support many different industries, mostly aerospace and defense. Communications and utility and life science and other government agencies. 00:39:15.000 --> 00:39:33.000 Now as far as agile we're about coming up with certificates in agile project management tools and techniques and also how you be As with respect to your business capabilities. 00:39:33.000 --> 00:39:41.000 We also have the capability of rolling out and doing things with respect to DevOps. So we have a DevOps program that you can sign into. 00:39:41.000 --> 00:39:54.000 We partner up with simply learn to come up and do a online capability of learning how to become better at system in DevOps here along the way. 00:39:54.000 --> 00:40:00.000 We also do the same thing for cloud and some other capabilities here. AI is another that we do one for. 00:40:00.000 --> 00:40:06.000 It's very similar. You also have model based system engineering. We have some of the finest instructors of model based, engineering in the world. 00:40:06.000 --> 00:40:20.000 And some of the smartest too, I mean, through working with them, we got one lady who's a deep engineer, but she also is one of the major planners of the Rose Bowl Parade. 00:40:20.000 --> 00:40:26.000 I think I'm be able to get in there and hang out with her. Doing the next Rose Bowl, but I've got my fingers crossed on that. 00:40:26.000 --> 00:40:33.000 We got another gentleman who's one of our amazing instructors here. He's got a home with chickens and horses and He said, come on out here and I got a bee plant where we were coming up with honey. 00:40:33.000 --> 00:40:42.000 I said, well, maybe I'll just check out the horses and the chickens and we'll worry about the other things later on. 00:40:42.000 --> 00:40:51.000 But we have amazing instructors with great backgrounds and they've been able to transfer their knowledge to any different industry along the way. 00:40:51.000 --> 00:41:00.000 Now when it comes to system engineering, there's many books out on that I would advocate. One is to system engineering handbook from in Cozy. 00:41:00.000 --> 00:41:05.000 There's also another one from NASA, but I didn't want to. Overwhelming with that. 00:41:05.000 --> 00:41:10.000 There's just a gentleman here, Dr. Bruce Douglas has been deep in agile system engineering. 00:41:10.000 --> 00:41:15.000 He's come up with something in the ways of looking at modeling for agile system engineering. 00:41:15.000 --> 00:41:24.000 We have another amazing partner with North of Roman and Dr. Sujet Johnson just came out with a book. 00:41:24.000 --> 00:41:31.000 On industrial depths to build better systems that I really would. A recommend you have. Agile system engineering book. 00:41:31.000 --> 00:41:41.000 This has been around for a while. I would say it's more gives It's about like a 80 20 split, 80 towards system engineering, 20 towards agile. 00:41:41.000 --> 00:41:50.000 I'm trying to feel and and come up with ways of narrowing that. We have the lean Software, systems developers. 00:41:50.000 --> 00:41:58.000 We have system engineering. Agile design methodologies and we always got taking consideration security and data and things that are making. 00:41:58.000 --> 00:42:06.000 Towards the center of this I put design thinking because you are going to have to be You own chef to deliver the system here. 00:42:06.000 --> 00:42:17.000 You need to be able to distill all these inner individual capabilities. Understand the existing legacy systems and then figure out how to embed these capabilities at the right time. 00:42:17.000 --> 00:42:24.000 And it digestible level. For the stakeholders that you have. 00:42:24.000 --> 00:42:31.000 So as we go here, and move forward here, 00:42:31.000 --> 00:42:43.000 And I start, I think I have 5 min left here. System engineering, agile system engineering is approach it combines agile methodologies with system engineering. 00:42:43.000 --> 00:42:57.000 Flexibility, acceleration, yet. An eye on discipline for complex systems. By combining the 2, we have a stronger approach that Provides consistent value to the customer. 00:42:57.000 --> 00:43:04.000 And also as we do this, we need to recognize there's no one solution out there. We have to tailor a solution at the end. 00:43:04.000 --> 00:43:10.000 As I get off here, thank you so much, member of this group. It's been amazing to have the opportunity to speak with you. 00:43:10.000 --> 00:43:18.000 As I told David when I came onto this conversation, I'm looking to start this relationship as a member or any way I can. 00:43:18.000 --> 00:43:28.000 Also if you need me even I'm not selling for monetary verses. I'm selling to help everybody become better and myself to become better here. 00:43:28.000 --> 00:43:36.000 So along that as I get off the stage, I want to thank you so much for this opportunity. To go forward here and thank you for you for coming here this morning. 00:43:36.000 --> 00:43:43.000 Hopefully it's been a meaningful. Discussion with you and I look forward to your questions as we go forward. 00:43:43.000 --> 00:43:45.000 Back to you, Don, I believe, to take over the rains here of the activity. 00:43:45.000 --> 00:43:55.000 Okay. All right, thank you. What I would probably like to do is just let me make some announcements and then we can go into Q&A and stick around. 00:43:55.000 --> 00:44:06.000 For about 5 to 10 min if we need to. Nathan was gracious enough to offer to stick around for a as much answer as many questions and as you have here. 00:44:06.000 --> 00:44:13.000 I know Apollo is collecting questions on the chat, but let me do this. Let me get this out of the way first. 00:44:13.000 --> 00:44:18.000 We like the, well. Let me make some announcements. Well, listen to this. Let's go in the Q&A and just check with Apollo. 00:44:18.000 --> 00:44:25.000 Paula, do you have some questions we can ask me? 00:44:25.000 --> 00:44:28.000 I'll. 00:44:28.000 --> 00:44:29.000 Okay. 00:44:29.000 --> 00:44:30.000 Okay, let's do that. 00:44:30.000 --> 00:44:41.000 Yeah, we have some questions now. Okay. Alright, first one from David. I wonder when you think a model-based approach should be developed. 00:44:41.000 --> 00:44:52.000 Well, I think there is a lower limit on it where If I'm in developing a website, where problem model based system engineering is is too heavy for that. 00:44:52.000 --> 00:45:10.000 But anything where you have an exchange between customers, you can document it in a process flow of activities, begins the use of model activities here because then trade studies that you cannot synthesize in your mind or on a sketch of paper quickly. 00:45:10.000 --> 00:45:16.000 Can be accelerated by doing models. Did I answer your question there? On that? 00:45:16.000 --> 00:45:17.000 Yes. 00:45:17.000 --> 00:45:26.000 Yeah, there's a lot of information in modeling, especially when it comes to, mathematical modeling of things that we do in especially when it comes to processes. 00:45:26.000 --> 00:45:44.000 And techniques and how to model using any any mathematical approach algorithm is going to change tremendously the outcome of what we're doing and that was I was wondering Oh, when is appropriate for any model based? 00:45:44.000 --> 00:45:45.000 Approach and how would you how would you 00:45:45.000 --> 00:45:55.000 Well, yeah. So when you bring in modeling, obviously you're, you're, intentionally talking about investment of money, dollars, and resources. 00:45:55.000 --> 00:46:00.000 So when is there there is a crossover point and I can't tell you what that point is. 00:46:00.000 --> 00:46:04.000 There's a point where a smart group of people in a whiteboard could figure out all the different permutations. 00:46:04.000 --> 00:46:14.000 For a very simple system. I will say then do that. Don't bring in a sledgehammer that you could could solve with. 00:46:14.000 --> 00:46:22.000 Between your 2 fingers, right? So I mean, but there are a point where if you have Say 8 does 9 steps in here. 00:46:22.000 --> 00:46:35.000 We have you can document it in a swim lane that has multiple departments affecting and you have exchange between those departments is when you start your thinking about modeling capabilities here along the way. 00:46:35.000 --> 00:46:45.000 And if any of you get stuck in the situation, you're trying to figure out. I mean, my contact me just to say, Nate, shoot me an email and I can contact you with some other great people here. 00:46:45.000 --> 00:46:52.000 We're about helping you here along the way to get to where where you need to be at. Okay? 00:46:52.000 --> 00:46:53.000 Thank you. 00:46:53.000 --> 00:47:10.000 Okay, the next question is. I wonder how this is from David. I wonder how documentations and rules and techniques would work along any agile systems engineering. 00:47:10.000 --> 00:47:18.000 Well, the first time, first of all, in general, the Angelus many, many years ago advocated this crazy thought and I call it crazy. 00:47:18.000 --> 00:47:30.000 We don't need no darn documentation, right? And I think that's a fool's perspective because many different systems you would leave, you may get hurt, you and the system still needs to go on. 00:47:30.000 --> 00:47:38.000 Documentation is necessary. So what when it comes to agile. If you look at the tenants of the. 00:47:38.000 --> 00:47:49.000 The manifesto, it talks about minimizing and eliminating. Comprehensive documentation. It's about right sizing the documentation. 00:47:49.000 --> 00:47:50.000 . 00:47:50.000 --> 00:47:55.000 Do I need to have a binder that's about 20 to stick here that ends up on my shelf collecting dust? 00:47:55.000 --> 00:48:05.000 Or can I use frequently asked questions? Can I use videos? Can I use decision trees along the way here to get things done. 00:48:05.000 --> 00:48:10.000 Can I repurpose wiki conversations? Can we have training along the way here to replace? 00:48:10.000 --> 00:48:23.000 So it's right sizing the value of documentation. We do not eliminate here. So we look at what because documentation can be a major sucking of assets for money along the way, but is not something that throw away. 00:48:23.000 --> 00:48:29.000 It's how do we repurpose it? In our new environment, taking in, advantage of the soft copy capabilities. 00:48:29.000 --> 00:48:39.000 I mean, wikis are an amazing way of of collecting intelligence along the way of development that could be repurposed into documentation. 00:48:39.000 --> 00:48:45.000 Confluence is one that I I recommend using along the way. Okay. 00:48:45.000 --> 00:48:46.000 Excellent, thank you. 00:48:46.000 --> 00:48:53.000 Okay. Okay, the next question is. 00:48:53.000 --> 00:48:58.000 From David, what types of contracting models can be used at any adult systems development? 00:48:58.000 --> 00:49:03.000 Okay, okay. David is from you now. In order to do this, I'm gonna require something from you. 00:49:03.000 --> 00:49:10.000 First of all, I haven't got a good indication of how happy you are. You're gonna put those glasses on for me? 00:49:10.000 --> 00:49:11.000 Yeah. 00:49:11.000 --> 00:49:12.000 Yeah. 00:49:12.000 --> 00:49:13.000 Oh, I am. I tell you. I am very happy now. 00:49:13.000 --> 00:49:17.000 Okay. Okay, good. So all right, good. We got him in a happy place. 00:49:17.000 --> 00:49:32.000 Now, the thing is contracting is The bait of existence around agility work because one it is basically contracts are in place for people that don't trust each other right They worried about ended up in a legal situation. 00:49:32.000 --> 00:49:39.000 We make sure everything is documented now. Everything we're going to go do from the, getting to the end in a systematic way. 00:49:39.000 --> 00:49:48.000 Well, agility is about evolving. So we have to have different types of contracts. I mean, a fixed price contract is the death of a jilly word. 00:49:48.000 --> 00:49:54.000 Because as soon as you go through and modify things, you violated the contract and somebody's in trouble. 00:49:54.000 --> 00:50:18.000 So we have to look at contracts differently. I would direct you to some of the writings on this from say this is why I advocate safe if they ever writing on capabilities based contracts instead of saying contracts they have deliverable it says for this phase you the development we are contracting you for this amount of hours. 00:50:18.000 --> 00:50:27.000 Of work from various different specialty expertise. With the intent that it will lead at the end to a solution that's acceptable. 00:50:27.000 --> 00:50:34.000 And sign off by the customer, but will evolve and change along the way. 00:50:34.000 --> 00:50:36.000 Thank you. I asked the question because I've been a consultant for life. 00:50:36.000 --> 00:50:44.000 Okay. 00:50:44.000 --> 00:50:54.000 And contracting, especially in western atmosphere here in northern America is is the first step of. 00:50:54.000 --> 00:51:11.000 Prior to even project charter is hard to deal with with clients. And what they want and how we can put in writing so we can abide. 00:51:11.000 --> 00:51:12.000 Bye. 00:51:12.000 --> 00:51:21.000 By deliveries off from both end. This and it comes to system in Julia in me talking about n number of vendors involved and that requires a huge contract. 00:51:21.000 --> 00:51:29.000 Thank you very much for directing us for Safe MSPC. 5.4. I have to update mine. 00:51:29.000 --> 00:51:36.000 I also I also have a PDF on Antioch contracting I'll send to you and I'll send. 00:51:36.000 --> 00:51:46.000 I'll see if I can find an article from Safe. Again, Safe has got some amazing. 00:51:46.000 --> 00:51:47.000 Yeah. 00:51:47.000 --> 00:51:52.000 White papers on contracts, AI, big data. Value streaming and they give it away as free as an offshoot of their site. 00:51:52.000 --> 00:51:59.000 That's why I give them a thumbs up. Now they're not my go-to person, but I gotta Games got a respect game, you know what I mean? 00:51:59.000 --> 00:52:01.000 So that's what we have here with that 00:52:01.000 --> 00:52:05.000 Thank you. And I think I asked some of the question that Richard had in in mind, but again, thank you very much, Felicia. 00:52:05.000 --> 00:52:11.000 And thank you, Dr. Cruz. 00:52:11.000 --> 00:52:12.000 Without questions, man! 00:52:12.000 --> 00:52:16.000 Okay, we have you're welcome. Yes, we have another question from Fernando. It's using the example of Tesla that you mentioned. 00:52:16.000 --> 00:52:23.000 Even the company uses Agile to build all the car features. The final product is the one to be validated. 00:52:23.000 --> 00:52:31.000 How do they handle? If the final prior, the car, hasn't met some criterias. 00:52:31.000 --> 00:52:40.000 How does the company handle the change management? 00:52:40.000 --> 00:52:48.000 Well. As we go through and have these presentations here. A smart man told me one time. Talk about what you know and defer what you don't know. 00:52:48.000 --> 00:53:00.000 So I really don't know exactly what their change management strategies are, but I am willing to take an action item to look into that and provide you data afterwards. 00:53:00.000 --> 00:53:12.000 Instead of sitting here and slinging together something that Probably is not truthful. Is that acceptable to errors and whoever sent the So that question, I will take the action. 00:53:12.000 --> 00:53:13.000 Yeah. 00:53:13.000 --> 00:53:16.000 Let me, was me actually, first of all, Dr. I really like your presentation. I can tell that you are professor, just the way that we speak. 00:53:16.000 --> 00:53:22.000 But I feel like, there's many questions, main points that you bring to these presentation that are probably going to dig into a little bit more. 00:53:22.000 --> 00:53:30.000 I appreciate that you you go a little bit forward about to the change management because it's something my mind. 00:53:30.000 --> 00:53:33.000 Okay. Okay. Yeah. Okay, so the one thing, the one thing around, yeah, testing and validation. 00:53:33.000 --> 00:53:42.000 Sorry. 00:53:42.000 --> 00:53:50.000 It's imperative of the inclusion of automated testings in some fashion to help accelerate the testing here. 00:53:50.000 --> 00:53:59.000 So using auto made it testing tools and the agile space has many supporting tools to do that to help do your acceleration of software development. 00:53:59.000 --> 00:54:09.000 And also there's robotic type tools that are used for the the testing. And manufacturing of capabilities of Tesla users. 00:54:09.000 --> 00:54:16.000 Tesla, I took a class with Joe Justice. They even have soft hands. For small detailed work robotics that that can be done here. 00:54:16.000 --> 00:54:29.000 So there's a lot of capabilities in place. I just can't speak to the way Tesla gives you the roadmap of how Tesla does it, but I can look it and get that back to you here, but testing is a very important and how that evolves over time. 00:54:29.000 --> 00:54:43.000 I would say whatever testing methodology should be. Part of your continuous delivery pipeline of DevOps though, You verify that this one product even to the car is what it should be before it goes out to the factory for. 00:54:43.000 --> 00:54:44.000 Sales activities here. 00:54:44.000 --> 00:54:45.000 Thank you. 00:54:45.000 --> 00:54:51.000 Okay, great. We'll take one more question. I don't see anything in the chat, but does anyone else have a question? 00:54:51.000 --> 00:54:55.000 Heather. 00:54:55.000 --> 00:54:56.000 You're welcome. 00:54:56.000 --> 00:54:59.000 Thank you, Felicia. And, thank you. Dr. Cruz for. 00:54:59.000 --> 00:55:06.000 Your presentation today. I was curious, most developers like to sort of kind of work solo and some engineers are the same way. 00:55:06.000 --> 00:55:19.000 They like to be left alone until they reach a complete product. So in or their build that are not much in favor iteration but are flexible to make changes let's say during a sprint cycle. 00:55:19.000 --> 00:55:27.000 How would you encourage or advocate to get them to ask or do? More status updates and checkers continuously on their own. 00:55:27.000 --> 00:55:38.000 Okay, so That's a very complex question here and I'm glad you asked it here. So for first and we have to first of all we don't want to push aside or negate the people with those thinking. 00:55:38.000 --> 00:55:44.000 There's some people who are amazing coders that can work exclusively by themselves and work on things alone and do a fabulous job. 00:55:44.000 --> 00:56:06.000 Without checking in. So we there's work for them outside this adult space we give them. Now some of those though you may want to sit down and and have a discussion with them for from an agile standpoint the first question I would ask them Are you open to try something new? 00:56:06.000 --> 00:56:16.000 And then I would tell them a storytelling in my experience in the jelly. I said, you know, it was just where you were and heads down and then there is a certain appreciation and value. 00:56:16.000 --> 00:56:23.000 Delivering something myself. I put my home stank on it, you know, it's mine and it went into the system here. 00:56:23.000 --> 00:56:34.000 But also the jubilant celebration of a team of people coming to a Come and go is far higher than that. 00:56:34.000 --> 00:56:45.000 I mean, if you you looked last night on TV because I watch TV in baseball. You looked in the Texas Rangers in their celebration and they're hugging around coming into common goals to the World Series. 00:56:45.000 --> 00:56:52.000 That was done by many different mindsets doing different skill sets at the right time in certain circumstances together here. 00:56:52.000 --> 00:56:58.000 So I would try to encourage them to give it let's pilot something out. Let me put you on something. 00:56:58.000 --> 00:57:03.000 Let me and and work with it and I'll be available for you if you get some frustration and I'll give you a space of psychological safety. 00:57:03.000 --> 00:57:10.000 If you want to quit going in and quit. But before you quit, let's talk about it. 00:57:10.000 --> 00:57:18.000 But the thing is, give it a try. If not, there is a space for you to work on, but I also have to be honest with them. 00:57:18.000 --> 00:57:27.000 I see, by you making the choice that you want to work alone. Exclusively, limits your future. 00:57:27.000 --> 00:57:42.000 Most organizations are going the way of agile. Most of teams are working more collaboratively. If you are not a player that can fit to their prior down easily when it comes times for layoffs for pay increases and promotions you do not. 00:57:42.000 --> 00:57:50.000 You do not, very, very well in those circumstances. So I let you, I will support you for any decision that you want to do. 00:57:50.000 --> 00:57:59.000 But take that in consideration and I really want you to at least try at least once with me. Okay, how's that sound? 00:57:59.000 --> 00:58:03.000 That sounds great. 00:58:03.000 --> 00:58:04.000 Yeah. 00:58:04.000 --> 00:58:09.000 Perfect. And I think, this is a time to. Any other questions or comments? Was that from my for my group? 00:58:09.000 --> 00:58:10.000 Okay. 00:58:10.000 --> 00:58:13.000 Collecting the questions, is there anything? 00:58:13.000 --> 00:58:16.000 There are no more questions. Thank you everyone for your questions. 00:58:16.000 --> 00:58:18.000 Alright, thank you. Thank you, Felicia. 00:58:18.000 --> 00:58:29.000 Yeah, if I could get feedback too from you. I mean, I did some navigation issues with my charts here back and forth here and I recognize that but I want to make this better and better from you. 00:58:29.000 --> 00:58:47.000 Each one of you individually, I look at you and I find an amazing spectrum. Of diverse companies and diverse beautiful faces in front of me as I look through here and to do this to this kind of audience just touch me at the heart level and I'm willing to help you out in any way I can. 00:58:47.000 --> 00:58:52.000 If you have questions, Apollo, it sent you to distributed my email. My website, look at that. 00:58:52.000 --> 00:59:12.000 I'm in LinkedIn. If you have questions, schedule a time or send me a question in either of those different of ways and then in addition to that if you want some time to sit down for a half hour an hour and just talk through a problem that you're facing in your way. 00:59:12.000 --> 00:59:27.000 Just just contacted me. I didn't get to where I'm at right now. Some of the most Agressive leaders and prestigious leaders have given me time without charging and it's my obligation to give back to you any way I can as we go forward here. 00:59:27.000 --> 00:59:34.000 But I did expect a few more questions though. I mean, David said I'll be proliferated with tons of questions and we will run out of time, but that's okay. 00:59:34.000 --> 00:59:37.000 I can maybe it's the next time we'll do that. 00:59:37.000 --> 00:59:40.000 Well, let me make some announcements and give people time to think about it and we can stick over on a little longer if you do come up with the last minute. 00:59:40.000 --> 00:59:56.000 Question. So I just wanted to acknowledge and thank Nate. Nathan, thanks for being gracious and spending time with us. 00:59:56.000 --> 01:00:08.000 And sharing your wisdom in mastering agile systems engineering for agile practitioners. I'd also like to acknowledge a few supporting donors this month. 01:00:08.000 --> 01:00:11.000 Sharon Wright Sharon is a fellow HVP on volunteer and supports the SBPM scrum team program as a team mentor. 01:00:11.000 --> 01:00:22.000 And the programs onboarding and training lead. We also have Kimberly Waifley. 01:00:22.000 --> 01:00:27.000 Kimberly runs a consulting service that can help your organization strengthen leadership. Team effectiveness, innovation, and create inspired organizational cultures. 01:00:27.000 --> 01:00:44.000 Kimberly is also a distinguished member of the board of directors of the SVPM organization. Most of all, SVVM would like to thank you, our guest, for joining us today. 01:00:44.000 --> 01:00:57.000 We hope. The knowledge and wisdom they shared with you today was meaningful, informative, and provide you with many takeaways to help you improve the performance of your professional career growth. 01:00:57.000 --> 01:01:13.000 There are, ASBTMs next event will be in November. So take a look and check on our read-up page even better register so you can communicate and stay informed about all our upcoming events. 01:01:13.000 --> 01:01:22.000 At this point, we're at the end and we're 5 min past, but we'll, I'll do that one last ask and see if there's any other questions. 01:01:22.000 --> 01:01:32.000 Other than that, thank you, and thanks again, our guests for joining us today. Any other questions? 01:01:32.000 --> 01:01:33.000 Yeah. 01:01:33.000 --> 01:01:36.000 No, a request. Do me a favor, turn on your cameras because I want to take a beautiful picture of you all. 01:01:36.000 --> 01:01:47.000 Give me your beautiful smile, please. I wanna keep your smiles in my mind. Give me your beautiful smiles, please Thank you everybody. 01:01:47.000 --> 01:01:53.000 Thank you for joining us today. It's been great. 01:01:53.000 --> 01:01:54.000 No. 01:01:54.000 --> 01:02:04.000 Being at your service. Thank you, Nate. Greatly thank you. From bottom of my heart and from our community leaders. 01:02:04.000 --> 01:02:05.000 Thank you. 01:02:05.000 --> 01:02:11.000 We just have a small request. Sorry, David. I just want to remind everyone to please take a short survey. 01:02:11.000 --> 01:02:18.000 It will take just a few seconds of your time. So please be request you to give your feedback through that survey. 01:02:18.000 --> 01:02:21.000 Thank you. Thank you for attending. 01:02:21.000 --> 01:02:25.000 Thank you. Everybody for joining us. We'll talk to you later. 01:02:25.000 --> 01:02:26.000 Thanks so much. 01:02:26.000 --> 01:02:39.000 Great topic, excellent topic. So many information and that I'm going to look back at the presentation and there's so many things in it that I want to review them. 01:02:39.000 --> 01:02:46.000 Thank you very much for for sharing all of these knowledge and insights with me with us. Thank you, Dr. 01:02:46.000 --> 01:03:02.000 Yes. As David said, a copy of this recording and the Nathan will provide us the presentation. Slides so we'll have those available to you at our SBPM scrum team, project management website. 01:03:02.000 --> 01:03:04.000 Okay, thank you everybody. 01:03:04.000 --> 01:03:16.000 And if any one of you for any reason would would want any of our members agile and scale value project management team. 01:03:16.000 --> 01:03:22.000 To react to your service, it all you have to do is just call us. 01:03:22.000 --> 01:03:23.000 Yup. 01:03:23.000 --> 01:03:34.000 Any one of you. And will will help you and your team. I'm we put all the all the pressure on our shoulder to move the mountains for you. 01:03:34.000 --> 01:03:38.000 Let's do it together. Thank you very much. 01:03:38.000 --> 01:03:39.000 Thanks again, Nate. Thanks, everybody. 01:03:39.000 --> 01:03:40.000 Thank you, folks. 01:03:40.000 --> 01:03:41.000 Okay, thank you, Dr. 01:03:41.000 --> 01:03:42.000 Thank you, thank you. Bye. 01:03:42.000 --> 01:03:43.000 Thank you. 01:03:43.000 --> 01:03:44.000 Thank you, very good. 01:03:44.000 --> 01:03:46.000 Thank you, Dr. Kruth. Great presentation. 01:03:46.000 --> 01:03:47.000 Hmm. 01:03:47.000 --> 01:04:00.000 Great. And I'm like, you know, I'm going to reach out to you. Nate, as, we talked and we'll see what we can do together. 01:04:00.000 --> 01:04:03.000 You got my cell number too? You got that? Or? 01:04:03.000 --> 01:04:09.000 I don't drop me on the line. And you have my number, just text me. 01:04:09.000 --> 01:04:10.000 If you would. 01:04:10.000 --> 01:04:12.000 Okay, sweet. Alright, sir. Hey, folks. Thanks so much for this opportunity. 01:04:12.000 --> 01:04:14.000 And. 01:04:14.000 --> 01:04:15.000 I appreciate it 01:04:15.000 --> 01:04:16.000 Good morning. 01:04:16.000 --> 01:04:17.000 Thank you, everybody. 01:04:17.000 --> 01:04:18.000 Doctor Need, I will be reaching out to you a little bit after this. Meet up. 01:04:18.000 --> 01:04:25.000 So, please stay tuned for my email and I'll send you some more information in there. 01:04:25.000 --> 01:04:31.000 Yeah, and if I give you that recording, that would be wonderful so we we can market that. Within our Caltech side. 01:04:31.000 --> 01:04:33.000 Absolutely. 01:04:33.000 --> 01:04:34.000 Okay. 01:04:34.000 --> 01:04:35.000 We'll do that. We'll do that. Thank you everybody. Greatly appreciate. 01:04:35.000 --> 01:04:37.000 Thank you so much. This is absolutely 01:04:37.000 --> 01:04:42.000 Thank you, Doctor, Dr. Thank you. 01:04:42.000 --> 01:04:48.000 Yeah. Thank you, my friend. We'll, we'll talk more if we go along here. 01:04:48.000 --> 01:04:52.000 Thank you. Bye bye.