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.
Svpn's vision is to continuously build. Next generation of practitioners. And develop professional leadership within our global society at large.
Svpn's mission is to create a community of agile practitioners and leaders by offering hands-on collaborative experience.
From the trenches sharing lessons learned and best practices on products, projects. And portfolio management.
. 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.
The Silicon Valley Project Management LinkedIn page and ASVP. Meetup events like this.
Just the name of you. Our guest speaker today is. And we're honored.
HSVPM is honored to introduce our guest speaker, Dr. Nathan P. Cruz, PhD.
Nathan is an accomplished senior leader with comprehensive experience and is well known for delivering tech solutions globally.
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.
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.
And neurologistic programming. He holds a bachelor's in math, computer science, and MBA, and executive masters in technology management.
PhD and management information systems.
The title of Nate's talk today is Mastering Agile Systems Engineering for Agile Practitioners.
It's all yours.
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.
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.
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.
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.
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.
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.
We'll talk about some, some basic capabilities out there that can help augment this whole topic.
And then we'll talk about some frameworks that I've seen utilized here. Along the way.
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.
And, but I will answer all your questions as I told David, I am here for you today.
You can't have a better agility mindset than that, okay? So first of all, let's get going.
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.
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.
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.
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.
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.
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.
I've had over 55 certifications. I just went and did check that check that out on my LinkedIn account.
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.
So I'm a senior instructor and partner with Caltech. We go out and look for valued ways of coming up with customized instructions.
We'll talk to you about that later. I've been a systems engineer. I, MP certified and also at the program level certified.
I'm certified as a business analyst, a systems analyst. I am agile framework agnostic.
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.
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.
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.
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.
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.
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.
A banking. Did I forget somebody? Yeah, I did. Even software from its initial inception of how agility should been.
But you lies has expanded out to be very, very complex with many different partners. Along the way.
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.
Of looking at yes going fascinating value but stability too. And as we move along the spectrum between the 2.
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.
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.
Well, we look at those things associated with Scrum and Con Bond. Safe and less and all the different frameworks are getting things done.
But we also want to embrace change in iterations. And frankly, system engineering and agility does both.
But also as we going through this activities, we also have to be mindful of limitations that are not going away.
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.
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.
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.
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.
Okay.
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.
So that's one of the some of the great things that we'll talk about from agility standpoint.
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.
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.
Now, how do we do this? So the concept of agile system is the principle based off of designing, building, sustaining, and involving.
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.
And we say, let's do this. With a center node of situational awareness. What is the situation I'm dealing with?
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.
The concepts all the way around to developing the system. I'm doing a great job of marking this up.
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.
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.
Now one of the staples of doing agile, excuse me, system engineering development is the V diagram.
Hmm.
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.
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.
Then we put it into operation. So this has been a staple of how some complex embedded systems have been developed over time.
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.
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.
Also doing things in iterations allows for us to see Parts of decision as it's growing and evolving over time.
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.
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.
Okay.
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.
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.
Now what I've seen towards this is Dr. Douglas and I'll show you a copy of his book later on.
He's done a great job of introducing agility into The space of system engineering. But I think the balance on is looked off.
It's more. Dominate by system engineering. It's not really embracing all it could be.
From respect of agility and how agility can add in to get things done. It's more focused on practices.
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.
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.
We have regulations that we have to meet, whether we do agile or not, they still need to be put in place.
Now agility, yesterday one agility, yes, it's fabulous, but you still have to have these.
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.
Let's say those who were disgruntled with the heaviness of waterfall. And looked at a lighter way of delivering things.
It's still delivering a valid, a valuable delivery to your client. So, but it didn't really take in consideration of hardware.
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.
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.
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.
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.
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.
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.
However, there's a security compartmentation I don't have, we can't talk.
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.
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.
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.
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.
This one frameworks. Scrum, put in Scrum, all your problems go away. Put in combat or say.
No, it requires a very mindful, thoughtful way of looking what's out there. First of all, what is the problem?
That we are addressing here. How do we face that? How do we deal with it on a regular basis?
And the plan carefully on how to implement this, take into consideration. The level of knowledge of the stakeholders.
The culture. The willingness to accept experimentation sometimes in your more complex systems is like, you can experiment at home, not here at work.
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.
That takes a level of consulting and change aid to capabilities that need to be learned over the times of years.
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.
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.
Where the the The edgeile Systems Engineering lifecycle is about awareness of what the situation that is going through and what is the need?
What is the opportunity? Conceptualizing that and you can conceptualize that by using principles of system engineering and agile.
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.
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.
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.
And again, the agility and system engineering are each one of these inner tip activities we're doing are baked in.
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.
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.
We look at things by delivering by features and those features sometimes prioritized based on the voice of the customer.
We have a shared knowledge base of what has happened before so we don't stop our toe and get things done.
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.
Things like DevOps come into play here. We talk about commissioning teams to go and support things.
We're talking about development activities. We talk about decisions that come into play in all types of medical applications or.
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.
Frequent value to the custom.
Now, how do we do these things? Now, what is to take the classic V model and look at ways of at each level.
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.
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
leadership, to give insight on how to make this better. So we iterate within a model one way here.
Now one thing I am big in adding into what we'll talk about later on. Model-based system engineering.
That's what instead of taking a model of taking requirements and dealing with them as a static unit.
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.
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.
Along the way. So these are some things that could be chatted about talk about in a later, presentation.
So I want to dive too deeply into it because I want to stay within my time constraints and also keep moving along here.
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?
How can we make it faster? How do we make it nimble? How can we make this customer centric together?
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.
First of all, the question is, do I do agile development? Or do I do edge out integration?
What do I mean by that? Now I'm sitting here with a computer system here. I have a wide screen.
Curved, 42 inch. Screen i have a Mac Mini processor connected to a customized keyboard that fits my needs.
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.
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.
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.
But we add we have to ask the question. In the end we need to agile system so can we configure existing proven capabilities?
That work and testing them together and save time and money. So that's one question we want to do here along the way.
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?
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.
And supporting this, I believe, truly is model-based system engineering, which I will talk about in a few minutes.
It allows us to look at many different use cases and many dimensions of the requirements helps us to accelerate.
The development of our high-level design and do trade studies to help us come up with the specific component that satisfies that design.
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.
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.
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.
And their actual software's and I'm not gonna go into them called Sysml is the modeling languages.
And, very, different,
Model based system engineering languages that can go through here and help you. To go through and set the system in many different ways.
Hmm.
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.
The model goes to and gives us some conceptual ideas to look at. That could take days and months.
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.
Now DevOps, we have, once we deliver it, we have to have a pipeline to test it.
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.
DevOps is how after you built it, whether it's code, software, or a solution.
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.
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.
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.
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
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.
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.
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.
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.
Now we want to talk about agile system in a line developing frameworks. And to that point, I am agile agnostic.
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.
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.
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.
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.
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.
Now there is customer. Involvement as we go through these iterations and approval. And review as we go along.
So we don't leave them out to the end, but they are part of the acceptance criteria at the end.
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?
Why do I, why do I only refer to people as team members? Where does the product owner fit in?
So sometimes we look back at Precursors to scrum activities, we have incremental.
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.
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.
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.
As PNCC is the International Council for System Engineers and some of the things they advocate to do to be more agile.
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.
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.
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.
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.
And and and adding the acceleration of delivering the product by using those kind of things. And they have on site.
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.
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.
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.
To develop our complex systems. It looks at lean, it looks at, it has some thoughts about cloud and big data.
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.
And government activities. Now I'm not saying go safe. I'm saying it's an option.
For consideration as we go forward here. There are some other limitations around this. I mean, but it does integrate.
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.
And a lot of these things are baked into this model where I think will be advantageous.
In addition to that, if you have a question, you hold that to the end. There's discipline ad down.
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.
A decision model to get things if you could, that person.
Okay, Not yet, okay. For 5 more minutes. Okay.
I'm sorry, you're muted.
Hey, decision-making framework here by for each one of those items You could break it down and for this addressing risk per se.
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.
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.
I think it's a very helpful capability for us to add to our toolset if at all possible.
Now, if we're doing looking at hardware, there are people out in the industry. Which societies that came up with.
Modified agile for a hardware framework where they went through this process here of taking scrum and some of the benefits of its capability.
Collecting stories. Integrating that in. And bring it down those out to the non-functional and functional capabilities.
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.
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.
Hmm. Somehow I skipped out some other capabilities here, but.
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.
I got a job. I'm supporting this new wonderful group here that you've been introduced to here.
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?
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.
And how to do that. To understanding what system, thinking is about. Instead of looking at, at, outcomes, we're looking at emerging properties.
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.
So alarm those capability of of system engineering so that is part of your toolbox. Also learn the whatever the agility.
Framework of choices that works best with you. Then find out and brainstorm ways of combining them to a solution that works for you.
For each situation that you have. We will be willing to and find out can this system be a practice of delivering things.
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.
And evolve with that you can't lose. And then implementing a continuous integration pipeline such as DevOps along the way here.
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.
So with that, the getting off the stage here, and finally, I guess I would say we just go hit and just do it.
Nothing experience trumps everything. Now, few minutes that I have here left here, I want to explain who we are at Caltech.
We're down in Pasadena. We work remotely. We come up with customized unique training experiences for organizations.
We can do your standard PMP or your system engineering training. We can customize what you do around how you work.
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.
We can do things on site. We do one on one tailoring, whatever you need, we're here for that.
We support many different industries, mostly aerospace and defense. Communications and utility and life science and other government agencies.
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.
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.
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.
We also do the same thing for cloud and some other capabilities here. AI is another that we do one for.
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.
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.
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.
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.
I said, well, maybe I'll just check out the horses and the chickens and we'll worry about the other things later on.
But we have amazing instructors with great backgrounds and they've been able to transfer their knowledge to any different industry along the way.
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.
There's also another one from NASA, but I didn't want to. Overwhelming with that.
There's just a gentleman here, Dr. Bruce Douglas has been deep in agile system engineering.
He's come up with something in the ways of looking at modeling for agile system engineering.
We have another amazing partner with North of Roman and Dr. Sujet Johnson just came out with a book.
On industrial depths to build better systems that I really would. A recommend you have. Agile system engineering book.
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.
I'm trying to feel and and come up with ways of narrowing that. We have the lean Software, systems developers.
We have system engineering. Agile design methodologies and we always got taking consideration security and data and things that are making.
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.
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.
And it digestible level. For the stakeholders that you have.
So as we go here, and move forward here,
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.
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.
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.
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.
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.
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.
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.
Hopefully it's been a meaningful. Discussion with you and I look forward to your questions as we go forward.
Back to you, Don, I believe, to take over the rains here of the activity.
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.
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.
I know Apollo is collecting questions on the chat, but let me do this. Let me get this out of the way first.
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.
Paula, do you have some questions we can ask me?
I'll.
Okay.
Okay, let's do that.
Yeah, we have some questions now. Okay. Alright, first one from David. I wonder when you think a model-based approach should be developed.
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.
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.
Can be accelerated by doing models. Did I answer your question there? On that?
Yes.
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.
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?
Approach and how would you how would you
Well, yeah. So when you bring in modeling, obviously you're, you're, intentionally talking about investment of money, dollars, and resources.
So when is there there is a crossover point and I can't tell you what that point is.
There's a point where a smart group of people in a whiteboard could figure out all the different permutations.
For a very simple system. I will say then do that. Don't bring in a sledgehammer that you could could solve with.
Between your 2 fingers, right? So I mean, but there are a point where if you have Say 8 does 9 steps in here.
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.
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.
We're about helping you here along the way to get to where where you need to be at. Okay?
Thank you.
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.
Well, the first time, first of all, in general, the Angelus many, many years ago advocated this crazy thought and I call it crazy.
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.
Documentation is necessary. So what when it comes to agile. If you look at the tenants of the.
The manifesto, it talks about minimizing and eliminating. Comprehensive documentation. It's about right sizing the documentation.
.
Do I need to have a binder that's about 20 to stick here that ends up on my shelf collecting dust?
Or can I use frequently asked questions? Can I use videos? Can I use decision trees along the way here to get things done.
Can I repurpose wiki conversations? Can we have training along the way here to replace?
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.
It's how do we repurpose it? In our new environment, taking in, advantage of the soft copy capabilities.
I mean, wikis are an amazing way of of collecting intelligence along the way of development that could be repurposed into documentation.
Confluence is one that I I recommend using along the way. Okay.
Excellent, thank you.
Okay. Okay, the next question is.
From David, what types of contracting models can be used at any adult systems development?
Okay, okay. David is from you now. In order to do this, I'm gonna require something from you.
First of all, I haven't got a good indication of how happy you are. You're gonna put those glasses on for me?
Yeah.
Oh, I am. I tell you. I am very happy now.
Okay. Okay, good. So all right, good. We got him in a happy place.
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.
We make sure everything is documented now. Everything we're going to go do from the, getting to the end in a systematic way.
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.
Because as soon as you go through and modify things, you violated the contract and somebody's in trouble.
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.
Of work from various different specialty expertise. With the intent that it will lead at the end to a solution that's acceptable.
And sign off by the customer, but will evolve and change along the way.
Thank you. I asked the question because I've been a consultant for life.
Okay.
And contracting, especially in western atmosphere here in northern America is is the first step of.
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.
Bye.
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.
Thank you very much for directing us for Safe MSPC. 5.4. I have to update mine.
I also I also have a PDF on Antioch contracting I'll send to you and I'll send.
I'll see if I can find an article from Safe. Again, Safe has got some amazing.
Yeah.
White papers on contracts, AI, big data. Value streaming and they give it away as free as an offshoot of their site.
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?
So that's what we have here with that
Thank you. And I think I asked some of the question that Richard had in in mind, but again, thank you very much, Felicia.
And thank you, Dr. Cruz.
Without questions, man!
Okay, we have you're welcome. Yes, we have another question from Fernando. It's using the example of Tesla that you mentioned.
Even the company uses Agile to build all the car features. The final product is the one to be validated.
How do they handle? If the final prior, the car, hasn't met some criterias.
How does the company handle the change management?
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.
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.
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.
Yeah.
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.
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.
I appreciate that you you go a little bit forward about to the change management because it's something my mind.
Okay. Okay. Yeah. Okay, so the one thing, the one thing around, yeah, testing and validation.
Sorry.
It's imperative of the inclusion of automated testings in some fashion to help accelerate the testing here.
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.
And also there's robotic type tools that are used for the the testing. And manufacturing of capabilities of Tesla users.
Tesla, I took a class with Joe Justice. They even have soft hands. For small detailed work robotics that that can be done here.
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.
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.
Sales activities here.
Thank you.
Okay, great. We'll take one more question. I don't see anything in the chat, but does anyone else have a question?
Heather.
You're welcome.
Thank you, Felicia. And, thank you. Dr. Cruz for.
Your presentation today. I was curious, most developers like to sort of kind of work solo and some engineers are the same way.
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.
How would you encourage or advocate to get them to ask or do? More status updates and checkers continuously on their own.
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.
There's some people who are amazing coders that can work exclusively by themselves and work on things alone and do a fabulous job.
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?
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.
Delivering something myself. I put my home stank on it, you know, it's mine and it went into the system here.
But also the jubilant celebration of a team of people coming to a Come and go is far higher than that.
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.
That was done by many different mindsets doing different skill sets at the right time in certain circumstances together here.
So I would try to encourage them to give it let's pilot something out. Let me put you on something.
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.
If you want to quit going in and quit. But before you quit, let's talk about it.
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.
I see, by you making the choice that you want to work alone. Exclusively, limits your future.
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.
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.
But take that in consideration and I really want you to at least try at least once with me. Okay, how's that sound?
That sounds great.
Yeah.
Perfect. And I think, this is a time to. Any other questions or comments? Was that from my for my group?
Okay.
Collecting the questions, is there anything?
There are no more questions. Thank you everyone for your questions.
Alright, thank you. Thank you, Felicia.
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.
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.
If you have questions, Apollo, it sent you to distributed my email. My website, look at that.
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.
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.
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.
I can maybe it's the next time we'll do that.
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.
Question. So I just wanted to acknowledge and thank Nate. Nathan, thanks for being gracious and spending time with us.
And sharing your wisdom in mastering agile systems engineering for agile practitioners. I'd also like to acknowledge a few supporting donors this month.
Sharon Wright Sharon is a fellow HVP on volunteer and supports the SBPM scrum team program as a team mentor.
And the programs onboarding and training lead. We also have Kimberly Waifley.
Kimberly runs a consulting service that can help your organization strengthen leadership. Team effectiveness, innovation, and create inspired organizational cultures.
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.
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.
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.
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.
Other than that, thank you, and thanks again, our guests for joining us today. Any other questions?
Yeah.
No, a request. Do me a favor, turn on your cameras because I want to take a beautiful picture of you all.
Give me your beautiful smile, please. I wanna keep your smiles in my mind. Give me your beautiful smiles, please Thank you everybody.
Thank you for joining us today. It's been great.
No.
Being at your service. Thank you, Nate. Greatly thank you. From bottom of my heart and from our community leaders.
Thank you.
We just have a small request. Sorry, David. I just want to remind everyone to please take a short survey.
It will take just a few seconds of your time. So please be request you to give your feedback through that survey.
Thank you. Thank you for attending.
Thank you. Everybody for joining us. We'll talk to you later.
Thanks so much.
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.
Thank you very much for for sharing all of these knowledge and insights with me with us. Thank you, Dr.
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.
Okay, thank you everybody.
And if any one of you for any reason would would want any of our members agile and scale value project management team.
To react to your service, it all you have to do is just call us.
Yup.
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.
Let's do it together. Thank you very much.
Thanks again, Nate. Thanks, everybody.
Thank you, folks.
Okay, thank you, Dr.
Thank you, thank you. Bye.
Thank you.
Thank you, very good.
Thank you, Dr. Kruth. Great presentation.
Hmm.
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.
You got my cell number too? You got that? Or?
I don't drop me on the line. And you have my number, just text me.
If you would.
Okay, sweet. Alright, sir. Hey, folks. Thanks so much for this opportunity.
And.
I appreciate it
Good morning.
Thank you, everybody.
Doctor Need, I will be reaching out to you a little bit after this. Meet up.
So, please stay tuned for my email and I'll send you some more information in there.
Yeah, and if I give you that recording, that would be wonderful so we we can market that. Within our Caltech side.
Absolutely.
Okay.
We'll do that. We'll do that. Thank you everybody. Greatly appreciate.
Thank you so much. This is absolutely
Thank you, Doctor, Dr. Thank you.
Yeah. Thank you, my friend. We'll, we'll talk more if we go along here.
Thank you. Bye bye.