Agile Product Development in the Aerospace and Defense Industries – Transcript
I had the privilege of interviewing Jim Roche of CIMdata and Dale Tutt of Siemens Industry Solutions Software on Agile Product Development in the Aerospace and Defense Industries. (audio podcast)
Enjoy the transcript below.
Read the transcript:
Scott Salzwedel: Hello, this is Talking Aerospace Today. A podcast for the aerospace and defense industry. A place that brings the promise of tomorrow’s technology to the ears of our listeners today. And I’m your host, Scott Salzwedel. Welcome to a special episode of Talking Aerospace Today where we’ll be talking with our special guests Jim Roche of CIMdata. Of course, as always, my partner, Dale Tutt, is here too. This promises to be a fascinating discussion with two highly recognized industry experts. I’m excited these two have joined me.
Today’s podcast – “How Agile Product Development is Reshaping the A&D Industry” takes a deep dive into agile product development. What is agile approach anyway? Many of you, when you hear the term, might think of software development. Others might be thinking this is the process that finally replaces the waterfall approach. And what about manufacturing? How does agile impact aircraft manufacturing? With more innovation and increased levels of complexity, it’s no surprise companies are looking for new ways to develop their products faster, better, and smarter.
Jim, welcome. I’d like to start with you. Could you please tell our listeners a little bit about yourself and what you do at CIMdata?
Jim Roche: Sure, Scott. First of all, thanks for inviting me. My degree is in Physics and graduate studies in Materials Engineering. I spent my early career in Advanced Manufacturing Engineering, before transitioning into PLM. At General Motors, I served as Chief Architect for global engineering systems. This was followed by many years as PLM Practice Manager for various consulting firms, delivering strategy and solutions for several major aerospace programs, such as the F-18, the F-35, and the Rolls Royce Trent engine, as well as other interesting clients such as Proton Motors in Malaysia, Bose, Church & Dwight (the makers of Arm & Hammer products), and Medtronic Bradycardia. After a stint with Siemens DISW, I retired and then joined CIMdata ten years ago to begin delivering industrial consulting and help develop PLM strategy from an industry perspective. While I work with clients in many industries, my specialization is in aerospace and defense. And for the past several years, I have served as CIMdata’s Practice Director for this industry.
Scott: Wow… Impressive track record. Thank you. It’s an honor to have you here today. And Dale, could you please share with our listeners what you do at Siemens?
Dale Tutt: Hello, Scott! I’m glad to be here today. So, my background: I’ve been involved in product development for about 30 years in the industry, in a large number of engineering and program management roles. Prior to joining Siemens, I was the Vice President of Engineering at The Spaceship Company – we were working with Virgin Galactic on building spaceships for commercial space tourism. Before that, I spent about 18 years at Cessna Aircraft Company – or Textron Aviation now – working on a large number of programs. My biggest program, towards the end, was working as the Chief Engineering Program Director for the Textron AirLand Scorpion Jet, where we developed an all-new tactical fighter jet, in about two years – so, very, very productive there. And I had roles at General Dynamics Space Systems Division and Bombardier Learjet before that. But here, at Siemens, I lead the Aerospace and Defense Industry team, we develop the industry strategy as well as, really, advocate for the customer solutions for our product development within the company. And so, I represent the Aerospace and Defense Industry within the company and help lead the company and work with a lot of our product development and our sales teams all around the globe. So, thank you for having me today.
Scott: Sure, great… Thanks Dale. A wonderful, wonderful background. And I am just so pleased to have both you and Jim here today. So Jim, back to you. What’s going on at CIMdata these days?
Jim: CIMdata is a boutique management consultancy specializing in product lifecycle management. What we now call PLM has gone by various names over the years. Back when CIMdata was founded in 1983, the prevalent term in the day was “Computer Integrated Manufacturing” or CIM; hence the name CIMdata. The firm began by doing market research. Today, CIMdata tracks over 300 solutions and publishes an authoritative set of annual reports on the global PLM industry. The first expansion of the firm was into education with conferences and online and in-person programs. Today, in collaboration with Eurostep, we produce PLM roadmap and PDT conferences in the spring and fall each year. The next step of expansion was into consulting for industrial clients and for solution providers. We’ve been doing this for a couple of decades now. And today, that is the biggest portion of our business. CIMdata is technology agnostic. We do not sell software or implementation services. What we sell is our knowledge and experience; helping industrial clients to find ambitious and achievable future state solutions and practical roadmaps for getting there. And helping solution providers to better understand trends and customer needs, and how to best position their solutions providing unbiased expertise to both industrial customers and to solution providers. We position CIMdata as an honest broker for collaborative dialogue and action between these two communities.
Scott: CIMdata also launched the Aerospace & Defense PLM Action Group. Actually, you’re the one who started it. You gathered some impressive players, I must say. So, could you please tell our listeners the mission of this PLM Action Group? And more importantly, how’d you get everyone to play nice in the same sandbox?
Jim: Well, the trick was they wanted to do it on their own. This is really a conversation that matured over several years. And I remember the day well. In February of 2014, representatives from four aerospace companies stayed over after a PLM conference in Berlin. It was guidance from CIMdata to meet and define the mission operational guidelines and they started to list the research topics, from what on that day became the Aerospace & Defense PLM Action Group.
After decades of individual action, Airbus, Boeing, Embraer, and Gulfstream decided that their common PLM pain points could best be remediated through joint action. The membership has grown to a high of 11 in 2019, but with dislocations in the industry over the past year, our membership currently stands at eight. These companies came together not to stifle competition and innovation, but on the contrary, to shift their spend profiles, increasing resources available for investment in innovation by reducing redundant spending on common problems. Also, they’ve influenced the direction within their industry by speaking to the PLM solution providers with a single voice. Over the years, the A&D PLM Action Group has funded and staffed multiple project workstreams, resulting in publication and research reports, direction statements, and position papers on topics such as PLM technology obsolescence management, collaboration between OEMs and their design and supply chains, model-based definition, model-based systems engineering (MBSE), and multi-view bill of materials management. In 2020, the group reported on a year-long collaborative effort with leading PLM solution providers, including Siemens DISW, to benchmark the capability of commercially available technology to satisfy multi-view bill of material requirements. The benchmark evaluation was a culmination of three years of effort, and publication of the comprehensive position paper, and associated dependencies. These publications and others have been released to the public and have been now downloaded by thousands of industry participants via the group’s website.
This year, the group has kicked off a new exciting project workstream on the topic of digital twin and digital thread. We look forward to seeing how this develops over the next few years.
Scott: Indeed… Dale, I know Siemens has been engaged with the A&D PLM Action Group as well, what’s been your experience?
Dale: It’s been a really good experience. While we’re not an official member, we are a partner for the digital enterprise for a lot of these customers, so we really welcome an opportunity to work with the members of the Aerospace & Defense PLM Action Group. And it’s been a really great way for us to get feedback, really, on issues that matter the most in the aerospace and defense industry. So, we get to hear a common voice, and we get to help develop some of these new standard approaches that help the OEMs and the suppliers alike. So, we’ve engaged with the group on the topics that Jim has mentioned, such as the model-based systems engineering and multi-view bill of material. The multi-view bill of material benchmark that we did last year was really interesting for us. It was a bit of an opportunity for us to stress test not only our existing solutions but some of those things that we had in development as well at the time. So we were pleased that we were able to score very well in that benchmark and we have more confidence now that there are solutions that meet the needs of aerospace and defense customers. So, it’s really been a good opportunity for us to work with some of our customers in more of a partnership and kind of outside of normal business competition. So it’s really been a good experience for us.
Scott: You just mentioned MBSE, that’s model-based systems engineering, that’s very hot right now. Could you go into a little more detail on exactly how Siemens is involved in the MBSE?
Dale: With respect to the PLM Action Group, we partner with them as they have developed some of the reports, and we’ve had some follow-up discussions with them as those reports have come out. But we provide end-to-end solutions from the time that you get initial requirements and start your conceptual design as you do all of your system modeling and then as you do your verification planning and really closing the loop with the verification that those requirements were met. So, it’s software solutions that are really across the entire enterprise, and support the entire lifecycle of the product. And so, as the PLM Action Group continues to advance the work that they’ve been doing with the MBSE activities, we will continue to work with them and highlight some of the areas where we’re addressing the needs of the industry.
Scott: You also mentioned the multi-view BOM thing, that’s a pretty big deal as well. Could you go into a little more detail on that?
Dale: Customers always struggle with managing their engineering BOM into their manufacturing BOM and test article build of materials, etc. So there’s a lot of different bill of materials that need to be managed. And it really is part of the key activity around that helps you manage the configuration of your product. As an aircraft manufacturer, every tail number may have slightly different configurations depending on the customer’s needs. And so you’re always working to – how do you manage these large amounts of data in an efficient manner to provide the views that different users need? The engineering user needs a different viewpoint and a different way of looking at the data than say the manufacturing engineer does. But you need to be able to make sure that those are synchronized, that you’re maintaining that configuration control that the as-designed matches the as-built, and then the as-delivered and then actually the as-maintained. And so it’s about managing large amounts of data, and the traceability throughout the entire assembly tree of these products.
Scott: Some really good stuff, Dale. Thanks. So, listeners, if you want to learn more, there’s a comprehensive report now available from the A&D PLM Action Group. It’s an industry benchmark of sorts. In fact, there’s an entire blog dedicated to this very topic. I would say just google “aerospace defense community recognizes Siemens leadership” something like that, and you’ll get the blog. And more importantly, you’ll have the opportunity to download CIMdata’s benchmark report. Highly recommend you do that. So Jim, what’s the current state of affairs in the defense industry when it comes to the product development process?
Jim: That’s a really good question. It’s in a very exciting time. It’s the time of change and transformation, not just for the industry but within the industry, within the more established traditional companies that have really dominated the industry for so many decades. It’s broadly recognized by all parties in the A&D ecosystem, that means the industrial companies that produce solutions; there are suppliers that provide them with software, but also their customers. I would say at least at the senior management level, the old way, the waterfall approach, is not viable in the long term. And it’s increasingly recognized that the long term is not such a long term. So, it’s an immediate need and an urgency. The key deficiencies of the traditional approach are clear. The development cycles have tended to be formal and lengthy. Most programs use a phase-gate approach still in a waterfall development paradigm. During extended product development cycles, functional requirements and available technology can change. This introduces the potential for the need of a product development reset and repeat, or to accept a sub-optimal product design. Another consideration is it’s difficult to incorporate new capabilities and technology after the program go. And adjusting requirements or changing the solution technology during development further increases the overall program time and cost. For the major players in this industry, what promotes recognition of these deficiencies to an imperative for change is that new competitors have entered the market who are not bound by these constraints. Who are faster and less expensive. Who are agile. These new competitors have established themselves as viable. And those who are buying A&D products, facing their own competitive threats and budget constraints are beginning to demand the benefits of this new way of working.
Scott: The United States Department of Defense, the DOD, recognizes the need to move to a more flexible methodology.
Jim: That’s true. The DOD is under tremendous pressure. Each generation of weapon system takes longer to develop and is more expensive by a lot. They have determined that this pattern must be broken to keep pace with more nimble adversaries. The DOD recognizes the need for accelerated and incremental development and acquisition processes and is implementing a paradigm-shifting initiative to achieve those goals. The objective of the initiative is rather than just building better systems, it builds systems better. To respond to this initiative, A&D companies have recognized the need to adopt a different way of thinking about and executing product development. Successful, timely, and cost-effective development requires using a flexible agile development approach. While new entrants are well down this path, the larger, more established players are committed and moving. As we in CIMdata work with some of them, we are impressed by their firm commitment to making the investment in what for some of them is a two-generation leap.
Scott: Wow… Yes, indeed, it’s the agile product development approach. Now, there’s a perception out there that agile applies to software development only. While this might have been true once upon a time, there is now a bonafide approach to agile in aerospace and defense.
Jim: Yeah, Scott, that’s true. There is this perception that agile applies only to software development. But times are changing, and we’re seeing more and more application agile and broader product development. A critical aspect to agile is the ability to fully execute each of the sprints/steps: define, design, developer or build, and test. Verify that the design meets the requirements. One reason why agile has been applied so successfully to software development is the ability to carry out all of these steps effectively and efficiently. In many companies, the sequence of steps from design to develop to test is highly automated for their software products. Carrying out these steps from design to build to test for mechanical or electromechanical products, traditionally involves construction and testing of physical prototypes. This is not something that can be done within a process construct of sprints. The breakthrough for application of agile methods to the mechanical domain came with a digital twin. Digital twins and digital thread are, in fact, prerequisites now available to enable agile development in a broader product context.
Scott: Well, that’s a lot to take in. Thanks, Jim. I really appreciate that. What I’d like to do is get Dale in on the conversation now. Dale, building on what Jim just said, how does Siemens define agile product development?
Dale: I think Jim captured the needs and the direction of the industry very well. When we look at agile product development, it really is a different way of looking at a program. Digital solutions, as we’ll talk about today, really are enabling a new way of doing business – it’s really helping transform businesses and engineering processes. But when we think about agile product development, in the context of, say, an airplane, it’s it really starts with breaking the overall program down into more manageable elements or chunks, as we used to call it when I was working on airplanes. During the early design phase, we might look at the wing, one week; the fuselage, one week. And then what would be needed to support early rig and bench testing. And then as you move further and further, you start focusing on the prototypes and flight testing. But as you focus on these smaller sections of the airplane or these chunks of the airplane, the smaller team can focus all of their energy to mature that section of the vehicle. So, it really provides a lot of focus and a lot of collaboration. And as you go through this process of many sprints to develop the program, each sprint is maturing to configuration, it’s helping to set the baseline for the next sprint. And as you have changes that come out of one sprint or the next, or you have customer changes, now you can be much more responsive to these changes because you can incorporate them into your agile product development process. So, I think just last thing I’ll say before we move on here is that some folks tend to think agile is chaos. There’s this perception that it’s kind of chaotic and is not well organized. But in my opinion and my experience, it’s been really quite structured. It’s like graduate-level program management. It really requires a robust program management solution. It’s fully integrated in all the aspects of your program so that you can manage all these sprints to make sure that you’re meeting your overall objectives for the entire program.
Scott: We’ve talked about the sprints, and we’ve talked about the digital transformation. What I’d like to do now is just bring up the Product Design and Engineering thread – it’s a specific approach from Siemens. And I know this is a digital thread in and of its own. So Dale, could you go on a little more detail about the PD&E digital thread and how Siemens supports the overall agile product development process?
Dale: Yeah, absolutely. The agile approach normally would require testing in each sprint. When you’re talking about agile software development, you’ll do a software build and you can go test it, and then you can incorporate the changes. So it’s easy to manage sprints. And sometimes, I think, people struggle to look at that as it applies to hardware; you can’t go build a new airplane every sprint and go test it. So, it’s a much different process. So the key here then is virtual verification manufacturing. And you really have to leverage the comprehensive digital twin to verify that your product is meeting its performance and requirements during each sprint. And so using the digital twin, and simulation technologies, and analysis, it really enables these agile teams to quickly test and verify and identify any changes or any items that might need to change as they evaluate different design options. And this shortens our decision cycle, and it also shortens the sprint development time and reduces risk because you’re working in these small chunks, and then you’re virtually verifying it both from a performance and a manufacturing standpoint. Then you have a digital thread that really provides these agile development teams with access to all the information they need to use as part of their individual sprints or their scrums, as sometimes they’re called as well. So with the digital thread, you help manage your baseline, the overall configuration during and at the end of each sprint. You have your change management processes – the decisions that are being made between sprints about how you might adjust your plan based on new information coming in. And then as well as you have to integrate your program planning execution. So, you leverage the comprehensive digital twin to really support your virtual verification and virtual manufacturing, and then you use the digital thread to really help connect this information together in a usable way that’s transparent to all the personnel on the program. So, everyone that’s involved in the development process, they have more information, and they maybe even be a little bit less specialized in their thinking, they have a better awareness of those interdependencies that they have with other functional areas, really helping to break down some of those silos.
Scott: I would imagine agile product development addresses the challenges around what we’re seeing in the industry right now – the future of air mobility – whether we’re talking electric hybrid aircraft, even space exploration, or even the many vehicles associated with Urban Air Mobility (UAM).
Dale: With any innovative aircraft, like an air taxi, I think we’re going to see a lot of work now with reduced emission aircraft, especially over the next decades with companies now starting to put more focus, more emphasis on that, or even spacecraft. Each solution or each product has its own set of challenges. But when you think about Urban Air Mobility or electric aircraft now, you’re talking about how do you manage the power density, there’s a lot of batteries and there’s a lot of power that’s required for takeoff and flying at high-speed cruise and climbing out. So, you have to manage the power density. You have new systems like electric propulsion. With all this power going around the airplane, you have to worry about EMI, you also have to worry about thermal management because you’re generating heat loads with these batteries and with the electrical systems. You’ve got to integrate all these systems together including things like automated flight controls. And then you have to understand how to verify and certify these products – many of them are certainly different than what we’re certifying today. There are differences in the rules that you need to certify these products too. And then at the end, and probably the most important thing is to provide a passenger experience that is safe and reliable and comfortable. So, you’re really balancing a lot of challenges, and it really is a multidisciplinary challenge that you have to solve between structures and mechanical and electrical systems. So, really does bring a lot of challenges, and you really need to think differently than you do today when you’re designing these products.
Scott: It sounds like agile is perfect for where we are right now in the industry. Also, an integral part of agile are these sprints or scrums, both you and Jim have alluded to. For our listeners who are unfamiliar with the term sprint, could you please define the sprint?
Dale: Absolutely. I think as I mentioned earlier, when we talk about a sprint, we’re really talking about taking this large program and breaking it down into smaller manageable chunks that allow these teams to become very focused on an area, or as I said, a chunk of the airplane. So, if you’re talking about the wing, your team is working all aspects of the wing concurrently with each other; with the structure, the fuel system, the hydraulic system, electrical systems, the landing gear, all of these things can be worked at the same time so that the team is working together through a sprint. And so, as they move through a sprint, it’s kind of simple, there’s a few steps in each process but you analyze the requirements for the sprint, you have a plan for the sprint; “This is what we want to achieve, and this is when we want to achieve it by.” The team then goes through their normal design analysis cycles to help do this optimization, this multidomain optimization of the product. Instead of testing a real product, like you would do with software, you do virtual testing, and you verify that the requirements are met. And then concurrent with that, you want to do virtual manufacturing, really take an opportunity to identify if any of the design that you have completed to make sure that it’s manufacturable, and to identify if there are any design changes that are needed to support manufacturing, and that can be with the product or maybe with the tooling or how your assembly line is set up. So, it’s looking at all aspects at the same time but doing it in the virtual world, leveraging the comprehensive digital twin. And then the output of this, the deliverable of these sprints is really an updated baseline plus any changes that may need to be incorporated in future sprints, but you have that updated baseline that you can move forward. So, it really does maximize collaboration among the team – everyone’s working on the same set of priorities at the same time. And I think there’s an overarching mindset that changes, that the team focus shifts from working on discrete milestones to just meet the milestones that are in your waterfall program but to really focusing on effectively maturing the product content together. And I think the teams are really empowered when they adopt this agile product development methodology.
Scott: You mentioned some really good benefits. It’s all coming together. I do want to bring Jim back in. Jim, from your perspective, what are sort of the benefits do you see from this type of approach?
Jim: Dale hit on one of the key issues and he explained it really well, and that is the impact that agile has internally on the team dynamics. And that’s where a lot of the benefits materialize and then they manifest themselves externally in terms of the company’s performance. If you look at agile and what it does within the company, it tackles internal challenges and issues that have been long-standing within the traditional way of doing projects where you have teams assigned to tasks within the overall waterfall approach to doing the business. Agile is really about improving internal operations. Now, there’s not a lot of research but there are some interesting studies that are emerging. In fact, a study by Organized Agile – which is an EU organization – discovered and documented the top three benefits among organizations that have adopted an agile approach for product development with electromechanical products. And they are as follows. Number one is, improving flexibility and agility, which isn’t surprising, and that was true for 83 percent of respondents. The second was, improving financial results. So, this is measurable. And again, the majority of respondents responded with that dimension. And finally, the third major improvement was creating a more open and productive culture. So, what we’re finding – and the evidence is emerging to support it – is that often when you want to do a transformation within an organization, there’s resistance to change and it’s hard to get the user community to adopt a new way of working. And we’re finding the reverse is true with agile. Now, there is always some human nature aspect of caution and apprehension with change. But as people get exposed to agile, they find it a much more satisfying way of working, especially with a modern workforce.
Scott: What I’d like to do now is just dive a little bit deeper into the old way, or what we’re calling the legacy approach, and compare that to the new way, of course, the agile approach, Jim. So, could you describe the characteristics associated with the legacy approach? I know you’ve touched on those previously, but let’s go over that one more time just so our listeners are clear of what we’re talking about here.
Jim: Okay, Scott. Characteristics of the traditional or a legacy approach, the waterfall approach, whatever, Stage-gate waterfall. Characteristics of that approach to product development include the following. First, it’s a fixed program plan with what we’ve been calling the waterfall; you do the requirements, then you do the design, and then you refine the design, then you test out the manufacturing, etc. And even though there is collaboration in integrated product teams, it’s still basically a set of sequential activities. It’s difficult to incorporate new capabilities after program go, because everything is so structured in the sequential series of events that must occur and the dependency across them. The potential for a high volume of change throughout the program is another characteristic because of the length of the program, and the structure of the program, the challenge of being able to make changes. And last is the lightweight risk mitigation so that the program is progressing, and then toward the end, you take steps to mitigate the risk. So, those are the main characteristics. Looking at it as someone from a critical point of view, of course, there are many benefits; otherwise, the methodology wouldn’t have persisted for so many decades. But these are the highlight of what are the currently perceived shortcomings of the traditional approach.
Scott: Okay, great. Thanks, Jim. And Dale, when you compare agile to what Jim just described, what do you see?
Dale: A world of difference. I think that it’s amazing how much different it can be. About as Jim said, I mean, there are some elements of the legacy processes that continue to carry through as well. But characteristics of agile really include a structured, but flexible program plan. So, for any project that you’re working on, you’re still trying to work towards an end date. Whether you have a five-year plan for a large, fixed program or maybe a shorter program with a more agile approach, there’s still a multi-year program that really needs a good program plan with a good structure but that’s flexible and easy to change. You have sprints that have very executable scopes so that you can iteratively mature the product; instead of thinking, “Well, okay, we’re going to work on this for the next three years.” You’re now working on a smaller element or smaller chunk that is for the next two months. So it’s much easier to manage and I think easier for people to engage and work on it. Then you have customer focus with very easy incorporation of new capabilities because you’re being able to be more responsive to changes as you’re working through these different sprints, as you have new requirements, new changes coming in, you’re able to incorporate those easier. And as a result, you’re able to minimize and effectively manage this change that you have a way, you have an approach to do this. And then finally, I think, you have earlier risk mitigation and faster learning. And what do we talk about when we say that is in a more traditional approach, you do all your design work, and then you start building your large test articles. And then you start your flight test program. And all of your risk mitigation is put to the end of the program. And now with a more agile approach, we’re in greater reliance on virtual testing, you’re starting to see those learnings earlier in the program. And so it helps make your test programs later on more effective in a verification process instead of a discovery process where you identify some of the risks that normally would occur during a more traditional approach on a program.
Scott: From our discussion so far today, I think we can draw some conclusions around agile. First, agile can evolve to meet customer needs and changing forces in the marketplace. Second, it taps into the full potential of the workforce talent. Third, agile dissolves those pesky work silos. And fourth, agile transforms program management, so a more mature and robust content is delivered. Do I have that right Dale? Is that a good summary?
Dale: Absolutely. I don’t know that I could have said it much better. But it’s really about empowering these teams to be more collaborative. And I just want to emphasize that, really, at the end of the day, it’s about the people that are working the program; they’re able to work more efficiently and faster, and they’re going to be more responsive to changes while reducing overall program risks. Because as you said, it really does transform the way you view programs and what you execute on them.
Scott: Jim, is there anything you’d like to add in that regard?
Jim: Scott, I think you got to just right. I’d like to emphasize a few key points regarding the transformation that’s occurring within aerospace and defense. The aerospace and defense products have become ever more complex where requirements and technologies are evolving faster than traditional serial development process can be executed. And this is a condition that you could have heard people say this ten years ago, but it’s more significant than ever. And that puts more pressure to move to a methodology that has a timeframe and a cycle that is more in line with the evolution of customer needs and the capabilities of enabling technology. Secondly, it’s really important to recognize and accept that the U.S. DOD is moving to this new acquisition model that will require A&D companies to deliver solutions faster and within a construct of validated modules, similar to what Dale’s been discussing quite well. Now, A&D manufacturers have accepted this challenge to transform the product development lifecycle and empower agile development teams with the capability to define models and simulate digital twins of the products they are developing. So, this is real, it’s in motion. There are some companies that are well down that path, especially the new entrance. But the well-established major players, they’re moving really rapidly and we’re going to see a lot of change across the board within the next several years.
Scott: These are exciting times for sure. Well, the beauty with agile is that it can work in a number of scenarios. It’s extremely flexible, given different objectives or goals. Dale, can you touch on a few areas where agile can benefit an organization or company?
Dale: Yeah, I think so. I think there’s a variety of engineering and product designers that you can apply agile to. And a few of those that I’m thinking about in advanced design, early design, you’re looking at, you’re optimizing your product concept and your architectures. These typically are small teams anyway, but they look at a lot of different configurations. And so, again, this is maybe an area where you can really change your focus and go faster. In an area that is usually kind of fast-paced but small teams, you can accelerate that process. But as I mentioned earlier, with a digital thread, you can now also keep track of the configuration, help manage the baseline, and keep track of what you’ve looked at and evaluated so that you go back and look at it again. We see it as you move into preliminary to detailed design phases that this really is this multidisciplinary design optimization. I’ve talked a lot about it during this podcast where you’re doing chunk management during these time periods, and really maturing elements or parts or sections of an airplane or air vehicle all at the same time to really focus on maturing the product together, all of the systems, subsystems together. The virtual testing, I think, is super exciting, and how can lead up to product certification. Again, to really make that certification phase process much more of a verification phase to make sure that you minimize your risk of any discovery of any changes or issues that need to be addressed. And then once the product is out in the field, and you’ve been delivering product for a while. Now, agile can still apply, you have this baseline from the original certification, you have the digital twin and the digital thread that’s there. And leveraging the digital twin, you can develop new product options and derivatives. And as you look at the types of derivatives that you might have, again, you can apply agile to these areas. So, if you’re stretching a fuselage, or adding wingspan, or maybe adding new sensors to a product that you can use these same methodologies. And I think, again, the key is just having that digital twin, the digital thread available, and then being able to do it in a very collaborative design environment that’s very flexible and open and enables engineers and program teams to really move quickly.
Scott: I have to say, unfortunately, we’re getting close to the end of this podcast. So Dale, is there anything you’d like to share with our listeners that we haven’t touched on? I know we’ve covered a lot in the one key area that keeps coming to mind is the digital transformation. We’ve talked about the digital thread and the digital twin. But is there anything more along those lines you want to share with the listeners?
Dale: It’s been a great discussion so far. But it really is important to recognize the benefits of the digital transformation and what we can bring with the Xcelerator portfolio that enables companies and teams to go faster with solutions such as agile product development. And it’s the applications and the digital twin that really enables this virtual testing and manufacturing. We often say you want to be able to fly it before you build it. And maybe even sometimes you build it before you build it. And that’s what you’re getting when you use the virtual world and virtual technology to evaluate the performance of your product. And then being able to manage this on a digital backbone to really manage the product baseline, the data, and all the engineering workflows, the product changes in your raw configuration. So, really, a lot of keys there to helping customers move into this, transform their business to be able to develop new products faster.
Scott: We talk about this, and it sounds great. But what we really need to see is rubber hitting the road. So, Jim, can you cite a real-world example of agile in action?
Jim: Sure, Scott. One example which is becoming famous because it’s really a great example is the Boeing T-X program. And this is a really great example of the benefits that can be achieved by applying agile development in A&D. The T-X program is the United States Air Force Development and Acquisition Program for a new two-seat jet trainer to replace the Northrop T-38 Talon. Boeing used a new design of manufacturing technologies to win the contract with an all-new aircraft. The company also views the T-X as the proving ground for design and development approach you could apply to future programs. Boeing determined that using modern computer-driven design and manufacturing, they dramatically shorten the development cycle, saving time and money using 3D modeling, and precision manufacturing that would reduce labor and accelerate development. Now, I’m going to read from my notes because I think the exact quotes and statistics are very well-stated and I don’t want to diminish the story by imprecisely paraphrasing this information. The gentleman that ran the program, Mr. Paul Niewald was the chief engineer, and he said, “We adopted an agile mindset in a block plan approach to hardware and software integration.” He went on to explain, “This had us releasing software every eight weeks and testing it at the system level to validate our requirements.” So, this is right in line with what Dale has been talking about. By doing this in such a disciplined way, at a frequency that allowed us to reduce our software effort by 50 percent. Now, the benefits reported to date on this program using agile development include the following: 50 percent less program cost than the U.S. Air Force expected. This was one of those programs that went out to bid, and when Boeing came in with their bid – which was 50 percent less than what the Air Force was expecting – the other competitors just dropped out. Model-based engineering resulting in a 75 percent increase in first-pass quality. Agile software development resulting in 50 percent fewer software hours, and advanced manufacturing produced an 80 percent reduction in assembly hours. So, in statistics like that, it’s kind of hard to compete. With statistics like that on this type of program, it’s got to be pretty intriguing and motivating to investigate further. There was an article for the Royal Aero Society titled ‘Breaking the Mold’ by Mr. Tim Robbins, and he states, “The T-X approach to rapid design and development along with affordable support could have lessons for more complex and sophisticated aerospace projects, not just in Boeing but around the globe as companies and nations aim to break the mold on the spiraling cost of military aircraft.” And I think that statement from Mr. Robbins sums things up pretty well, as far as the message we’ve been trying to get across today.
Scott: Wow Jim, that’s a great example of Agile in the defense sector. I don’t know how are you going to top that, but Dale, what about in the commercial space? What do you have in the commercial arena?
Dale: The T-X is a great story; they’ve really done great things. And it’s a great example of really not just bending the cost curve for military programs but actually starting to break it. But in the commercial area, we’re seeing companies adopting this in very different places. But we see some smaller companies like Bye Aerospace. They’re doing great things with small teams really within a digital enterprise, and they’re moving very quickly, and they’ve seen great results when making changes. They’ve shared examples where they stretch the fuselage four inches to accommodate some changes for the requirements and how by having everything digitally linked, they’re able to do that in weeks instead of months. And in some cases, they’ve reduced some of their engineering hours by more than 50 percent. Just by leveraging digital solutions, I think the number actually maybe is 60 percent. And so, they’re able to execute these programs with really small teams, and they’re being able to be very efficient, effective as they do it. And I would say, as a result of these time savings, I’m seeing them starting new programs now; they just announced a larger eight-seater aircraft, which they’re now starting to work on, even as they wrap up certification on some of their existing products. And so this is allowing a company to accelerate its product development plan. And it’s pretty cool what they’re doing out there and they’re doing a great job.
Scott: Well, one of the keys to me to agile product development. It’s the continuous or the iterative process, and it all occurs within the digital environment we’ve been talking about. And it’s something that Siemens Xcelerator portfolio provides. I just want to mention Xcelerator, it’s part of Siemens, and it’s a flexible, open ecosystem of software and services. And this does include both the digital twin and multiple digital threads, including the product design and engineering thread that we discussed here today. So, with agile product development, you’re doing continuous verification and you’re managing and maintaining this configuration control with all artifacts in place. It means you have traceability through all of your digital threads. You have a very robust program management system where everything is synced together. Jim, Dale, it was a pleasure having you on the podcast. Thank you so much for your time today.
Jim: It was great to be with you and Dale. This was an exciting and important topic. And my thanks to you and Dale for the opportunity today.
Dale: Yeah, Scott. Thanks a lot. Again, it’s always good to join you on these podcasts. And Jim, thank you very much for joining us today, really brought a lot of great insight from your perspective at CIMdata and working with the A&D PLM Action Group. And so, really appreciate you joining us today. So, thank you.
Scott: A wonderful conversation. Thank you, both. So, listeners if you enjoyed this episode and you don’t want to miss upcoming episodes, please subscribe to Talking Aerospace Today on Apple iTunes, Spotify, or wherever you go to get your favorite podcast. We’re currently in season five with plenty of new episodes planned around zero-emissions aircraft, so you don’t want to miss that.
My name is Scott Salzwedel, and this is Siemens Talking Aerospace Today. I hope you’ll join us again for our next podcast. Until then, bye for now.
