What is PLM?
Product Lifecycle Management (PLM), and PLM software specifically, enables the creation of the digital thread that connects the data and processes integral to the design, engineering, manufacturing, sales, and service of a product across its entire lifecycle.
How is a PLM transformation different from traditional software development?
There are two major differences. They’re not really unique to PLM, per se, but they’re commingled.
First: At this point almost no one is building their own PLM solutions for internal use. There are well-established industry leaders that provide PLM and adjacent solutions like CAD, ERP, and integration tools. So Moog wasn’t building software from scratch. Instead, the primary activities were developing processes and then configuring those tools to facilitate the new processes. In some ways configuring COTS software is simpler than building from scratch, but in other ways it’s more complex since each tool has its own configuration SDK’s, CI/CD pipeline tools (or not), and platform expectations. It can also be a lot more challenging to set up test automation with some of these prebuilt solutions.
Second: PLM isn’t a solution that’s going to be sold as a product by Moog. From a Value Stream perspective, it’s either a part of the Operational Value Stream for (custom) Customer Projects or it’s part of the Development Value Stream for off-the-shelf manufactured parts. Either way, the final activity in delivering value is Organizational Change Management rather than Go To Market. The initial rollout (which included Deployment, OCM, and Release) was underway when Moog adopted SAFe, and it was managed in a more traditional manner, so we had to get creative in how we integrated the rollout and OCM work with the development and update work. The good news is that Moog has a very engaged user base and stakeholders, so feedback loops are short compared with market-oriented solutions.
Transcript:
0:00 Alright thank you everybody for joining us um we’re uh happy to have you here today. We’re going to be talking about PLM and agile and we’re going to be talking about a real case study with one of our customers. My name is Chris Ruch, I’m the CEO of Agile Rising.
0:24 I’m joined here with Paul and Josh who are going to be doing the main presentation today and we always like to talk about and share our experiences here at agile rising and it’s always particularly special when we get to do
0:41 that with one of our customers uh sharing some real stories on real experiences and with that I’m going to turn it over to Paul Kaiser for you to introduce yourself and tell us a little bit more about Moog great all right thanks very much Chris, Julia, Josh, Russ I appreciate it thanks.
1:02 Thanks for having me today so my name is Paul Kaiser I’m the PLM program director at Moog.
1:08 I’ve been a consultant full-time employee at Moog currently obviously a full-time employee. I joined in that capacity in Spring of 21 and I was a consultant from around 2016 through 2018 so on and off about seven years at mozier questions and we’re also joined by Josh Kite who’s one of Agile Rising’s senior transformation Consultants who’s been working with Paul and Moog.
1:38 Hi everyone my name is Josh Kite like Chris said I’m a senior transformation consultant with Agile Rising, I’ve been working with Paul and the folks at Moog for about two years now so it’s really kind of uh fun to be able to see where we are at this point in their progress versus where we were when we got started looking forward to telling you about it today.
1:57 Paul can you kick us off by setting the stage and telling us a little bit more about Moog and and what led you on this journey yeah absolutely um for anybody that’s not familiar with Moog it was started in 1951 by Bill Moog and his brother for three thousand dollars and since then we have grown to about three billion dollars in uh uh 26 different countries with around 12 000 employees so whenever I introduce Moog I
2:27 always like to tell this whole anecdote that I heard from our our former CEO and he put it like this
2:33 at Moog we do incredible things in 1969 we steered all three stages of the
2:41 Apollo 11 Rocket that put the first man on the moon and today right now we are working on the systems that are going to put the first woman on the moon in the next few years so across our company every day we have brilliant people working very hard and coming together to solve the most difficult challenges for our customers so a truly incredible company so we do more than people realize um at Moog we support four broad Industries space and defense group that is one operating group serving both space of course and
3:18 defense um we have commercial and military aircraft uh support as well and Industrial Products so our space and defense group develops and delivers orbital maneuvering vehicles and missile steering systems weaponization of air land sea like you can see here on the screen power and data transmission High Performance Motors um a fun fact on one of our little infographics is that Moog products have been to every planet in the solar system um with our aircraft growth we design we
3:50 manufacture and we integrate flight Control Systems world class in that market both Military and Commercial If you flew in the last 30 years we helped you arrive there safely so every major airport in the world is filled with our with our products an industrial group solved the world’s motion control problems is a very big very diverse group um a fun one is the Wimbledon
4:16 retractable roof that is something that we helped enable we do work for Formula One wind and power autonomous robotics you name it so um binding a lot of the data together at Moog certainly with space and defense group and our aircraft group is our PLM Department we have been building and rolling out a new connected data foundation for mode for certainly two of
4:41 the three operating groups here and by the end of the year we’ll have a totally new foundation in place and that’s enabling our digital thread and vision for model based engineering so a bit of History just to kind of set the stage I think Josh and I had to tell a story here in 2017 we kicked off this New Foundation we’ve had PLM for quite some time but we needed to modernize and and had some objectives and we defined a Year’s worth of requirements and we started out with an iterative waterfall approach and we planned out that first
5:17 year so you can see in this graphic there we defined all those requirements and then started doing these these Loops these plan develop and test these do loops and we went through that we managed this entire first year with earned value management system um it was not uh not my idea but that was the uh trusted system where incredibly good at doing that with uh
5:41 our traditional contracts for product development so it was felt um best to continue that with PLM so we started down that road um we were Highly Successful by the metrics we did very very well and built a really good team Moog is best in class with with people and culture we have an incredible team built a really good Rhythm but we did find out about 11 months in that
6:08 you could say that some of the business Dynamics had changed there’s another department that was helping us out with the security model um and their schedule had shifted we weren’t as closely connected as we could have been or should have been and so we had a a end of the year realization that we weren’t actually ready to do some piloting when we thought we would be so just a That’s a classic case study on its own um from agile versus waterfall
6:36 so differing priorities budget capacity Etc with different departments so the big picture is we had some mixed success we had really good success here but ultimately for one of our goals you know you could say that that was not successful so we had a delay there um and um I’m sure there’s some people listening that are nodding and have experienced this on their own um PLM is a hugely valuable but never
7:01 easy Endeavor so um in some respects we were successful in other areas we knew we had to do some improvements so Moog has an outstanding culture as I mentioned it’s really um one of our greatest assets but um we’re Best in Class I think with continuous Improvement and we defined it at the end of the year as a case for Change and to find some objectives for that continuous Improvement so 2018 we thought you know we have to learn to fail fast and that became a term and kind of like a mantra around the halls of the program anyway we didn’t want to wait 12 months for business input or we
7:43 wanted that fast feedback so that was a that was a biggie for us and then incremental business value delivery how can we avoid building something for a full year and then deploying it because like the case I mentioned a moment ago if you have you know even a slight delay there now you’ve got shelf where it wouldn’t be ideal so you’re kind of delaying some valuable insights there um and then we wanted to be scalable of course and adaptable you know PLM um is an evolution and a journey in any
8:13 company so um we wanted Moog Inc to benefit from whatever we uh changed to if we were going to switch our program management Paradigm that’s got to benefit moganic not just this project and then we end the project and it’s done so um and eventually you know a PLM program when you’re developing it’s going to become a sustaining uh so we wanted this to be able to continue and live on and to sustaining so and then number four you could easily say is really number one for anything but it had to be a good fit with our culture that’s something as you’re getting a sense I keep bringing this up we um take that very seriously
8:50 so it had to be a good fit for our corporate objectives and our culture so SAFe ended up being fit for purpose for us we looked at various options and that was really something that would fit and blend wonderfully with these objectives here so um Josh I think maybe you’ll share some about safe for anybody who’s not initiated sure so if by chance you’re here and this is the first time you’ve heard people talking about the scale Dodge framework and you’re looking at this picture and your response is wow
9:25 that’s that’s a lot to take in why isn’t it simple like all those other agile Frameworks that have just you know the single graphic that I can understand uh let me kind of break this down for you a little bit uh kind of walk through some of the challenges that safe is trying to address and you’ll also I think see that we’ve been able to use that to help Moog quite a bit so safe is a combination of principles values competencies and practices and it allows us to start by focusing on the customer and understanding who the customer is what the cost customer wants what they need and the kinds of value that we can deliver to that customer we can then
10:01 that take that information and start up at the top of the organization from take an Enterprise View and think what are our strategic themes what kinds of okrs and kpis do we want to achieve and based off of that that guides our budgeting approach and so safe has some guidance on how to build budgets and to move away from a traditional project budgeting or to work within say program level budgeting but to use those those funds to fund
10:31 long-lived agile teams you may be familiar with the concept of an agile team typically eight to ten people maybe a little bit more maybe a little bit less typically using scrum so we’ve got the specific roles of scrum master or team coach as well as a product owner and working in two-week Sprints for a safe calls and iterations where we go through the typical pdca cycle of planning out the work for the next two weeks meeting on a regular basis usually daily wrapping up with the review and the retrospective and then repeating that cycle but what safe does it’s different from a lot of other groups is it’s designed to build really really large complex solutions that one or two teams working together can’t deliver and so that is what save calls
11:15 the Agile Release Train which is a team of teams you’ll hear us call it an art you’ll hear us call it a train it’s just a team of teams with its own uh group of leaders uh we’ve got what we call the release train engineer that’s the chief scrum master or the the sir the leader who serves the team and we’ve got the product management group as well as some system architects and it has its own Cadence where the five to twelve teams on that art will get together periodically typically uh 10 to 12 week Cadence we’ve we’ve adopted a 12-week Cadence with Moog and they plan out the next 10 to 12 week cycle just like we do at the scrum level
11:53 only up at a higher level so we have a an event that we call Pi planning so planning interval planning where we plan out that next 12-week cycle uh and we have some meetings throughout the pi where people will get together and make sure we’re in sync and we wrap up the pi with its own Pi system demo and its own inspect and adapt Workshop which looks a lot like a large retrospective and uh and and a demo to wrap up that Pi inform the next one we try to mentally make changes at the boundaries if at all possible and that lists of teams focus and actually deliver work keeps them from overloading the work in progress or changing
12:32 priorities constantly but we also know that uh on a standard Cadence we only have to wait another 10 to 12 weeks before we would make a change so we know that we’ve got these pivot Points built in naturally and that provides the organization with business agility so we can make sure that we’re constantly aligned with the organizational needs but we also can change as Market demands or business conditions require so that we can continue to serve the customer and prevent uh provide them with customer Delight
13:04 so it’s just a high level of the framework and now Paul’s going to tell you a little bit about their process in adopting that framework all right thanks Josh so continuing this story here in in late 2018 early 2019 scaled agile was introduced to the program and that Journey really started and began with education so it was a training from um top to bottom from the leadership all the way down through everybody on scaled agile and and just you know education and taking classes people were reading books doing research online but it was essentially one large team just divided by disciplines and skills so we you know
13:46 moving on through this little curve here adopted an agile tool as your devops is something that we use today so that was adopted and all of those requirements I spoke about before and everything that had been built up in the balance there was imported as one big backlog so one giant backlog um and then we adopted scaled agiles planning intervals we used to call it program increments from the the previous safe five I believe so we started beginning to plan out those 12-week chunks that Josh was just explaining there so six prints
14:20 we struggled with the details it’s very new it’s a totally different system it was a different Cadence in a different language for us so struggled with the rigor there a bit sometimes 12 weeks became you know 14 16 18 things there were slips there wasn’t you know sticking to these to these 12-week chunks I’m describing really constant change so the program had you know gone through
14:49 that first year I was described then we had to adapt as things were different than we expected at the end of that year and then we started adopting scaled agile and people are training so it really was this constant change condition we had a brand new RTE didn’t have any seat time uh we didn’t have a coach at that time but we had brilliant people very smart Engineers and when you take just Brilliance and people studying something new you tend to study anything new and you get this picture from training of the mature state of the end State and you start to visualize the end State and when you’re at the beginning and it
15:28 doesn’t look like the end it’s really confusing so you get into you could maybe say analysis paralysis But ultimately just any human being anywhere doing this much at once it’s change fatigue it you start slipping dates you shift priorities you’re constantly trying so hard to do the right things and you get into some role Clarity issues a little bit of declining morale that you could say that as frustration and um people not understanding you know I’m on this side of the program but what’s that side doing and what how does my contribution connect to the overall big picture and there were some of these
16:05 challenges so in early 2021 as a whole program took a step back slowed down assessed ourselves and we defined again some improvement objectives for just refining and how do we get better here so um some of the objectives were certainly first and foremost let’s increase team confidence let’s get rid of some of that ambiguity and let people understand what their contribution is and start to see the big picture start to see the small picture what they’re working on how they
16:34 directly relate but then how that fits improve Communications throughout the program and increase predictability senior leadership really wanted to see predictability but um we had to solve all of these in order to get any one of them so fast forward in 2021 we’ve relaunched the program and what that means to us and I think that what it would mean to explain anybody when you’re when you’re
16:59 taking the sign is relaunching program culture so we rebranded this as a relaunch we talked about it as a relaunch we talked about it as new this is exciting and encouraging we are taking a step towards the future and we’re going to be successful and this is what that’s going to look like so scaled agile after going through it it really is a cultural implementation
17:23 that’s what you’re putting in you know first and foremost so it’s it’s shifting to team directed that means it’s got to be people first the people have to be supporter they have to be heard that to be valued so consistent with that for this first at the time program increment planning we in our on our relaunch we brought 80 people together face to face flew people in some from around the world certainly from around the country we brought in senior leadership we had a CTO two vice presidents our business owners were there and the whole program and we all spoke I showed a photo of my son saying I want my son to work at this world-class company one day and I want us to be best in class with this and get these new systems out there so we talked about what this can mean to us and how important it is and this the CTO and the VPS did a brilliant job setting the context setting how valuable and let everybody see that from top to bottom
18:20 this is this is what we’re going for and this is the value that you’re organizing around and you’re going to deliver to this company and we brought in a safe transformation coach this was absolutely key to us it’s why I’m sitting here today this was very successful so we looked around the industry we engaged with Sim data a leader in in PLM guidance and talk to them about other scaled agile companies and we ultimately land on Agile Rising so we I wanted to attach some expert guidance right to
18:52 leadership write to myself and my two partners in our our pmo and um and just have somebody that walked it and done it and has the experience in the room so um new program leadership moving on here uh new structures top down we had uh put in monthly c-suite briefings 2bi-weekly stair steering committee stericos we say uh daily PML meetings and we wanted to make sure we was visible and accessible in an Open Door um virtually because mostly virtual and then a big differentiator for us was putting in a strategy of the aggregation of marginal gains that became our new team strategy for improving incrementally across time we’ll talk
19:36 about that in a few slides but small changes everywhere easy changes things that are simple to do that are simple to understand things that are achievable and things that are measurable and then in time and in aggregate you get a very large change so that was something very successful for us and then team directed decision making as well so from the bottoms up we need to clear roles and priorities we put in our racy and started just really focusing everybody on exactly how they com how they um deliver and what their role is and what they’re doing um we we talked openly about the famous Steve Jobs quote higher brilliant people
20:13 and let them tell you what to do and then we Road mapped everything we Road mapped our program our development road maps but again that maturity road map as I touched on a moment ago that was that was huge for us now Paul just talked about road maps but you know what what do we mean by that and and how is that different from a vision so the vision is the description of where we want to go what we want to deliver typically on from a solution perspective years from now in the case of Moog they’re looking at really a vision that’s about 10 years out uh that eventually they want to have a model based Enterprise and in order to get there from a roadmap perspective that means they’re going to have to to have a model based engineering and in order to
21:01 achieve that they’re going to need model based design and PLM lays a foundation for all of that so I just laid out right there a multi-year roadmap for for what they want to achieve in terms of a model based Enterprise now we recognize that the technology is going to change if we were to try to explain all of that right now it would not make a lot of sense because over 10 years a lot of things will be very very different so we’ve got the sense of where we want to go recognizing that we’ll we’ll move throughout and won’t be exactly like we want want it to be from
21:31 a roadmap perspective we can go all the way down to what am I doing today what am I doing for these next two weeks what are we doing over the next eight to 12 weeks at that Pei level and then what are we going to do for the next six to nine months and so we plan this stuff out we know that we might tweak it a little bit we know some things will take longer some things we might be able to get done a little bit shorter but we can apply this to what we’re going to build from a development and Technology
21:54 perspective and really really really critical as Paul just said to apply this to a transformation if we were to try to do everything and and Implement all of the concepts that we wanted to do all at once it would probably be a disaster so instead we’re going to try to take things over time and say we’re going to work on this part now we’ll layer this stuff on and it allows it to be much more successful
22:25 so that team maturity road map as I called it and Josh’s lead in here that’s really the strategy of aggregation of marginal gains that’s that’s how we talked about it but we implemented it here this little icon on the top right of your screen there that’s the image that we use to define it use any image you want that’s not the important part but um having those small achievable goals showing the team what they can achieve what they need to focus on and how narrow that is and celebrate those successes it’s really similar to coaching a sports team or learning something having a personal trainer gotta get core Foundation elements down pat before you can build on that so improving fundamentals transformation coach was huge for us
23:13 Josh was very prescriptive I’ll never forget at um our first relaunch planning interval Josh giving us a little speech about how he’d uh he’d be mad at them why don’t you run through that real quick yeah so what I said I stood up in front of everyone and said okay here we go I’m going to tell you exactly how to do things for a little while and if I come back in three weeks and you’re not doing exactly what I told you to do I’m going to be really really mad at you but then if I come back nine months from now and you’re still doing it exactly the same way I’m gonna be mad at you and and here’s what I meant by that I’m obviously I’m not gonna be mad at anybody but the the point is if you if you ask me to come in here and and help assess what you’re doing and and help pick help you pick the right practices to implement you don’t know enough about them to start tweaking them right away so let’s follow some some really clear guidelines and I’m going to lay out up some things for you to do right now and it’s going to feel like I’m micromanaging a little bit but but just do that for a bit learn it the right way first and then over time and once it
24:22 makes sense to you and you’ve kind of got that down please then take over please start to make changes as it makes sense for your organization because I don’t know everything about your context but you don’t want to start to do that up front uh and and what we saw before I got there was people were trying to figure out things that they should do and tweak the process before they knew the process and they kept trying to perfect it and that led to that analysis paralysis that Paul described so I came in and just cleared some of that analysis paralysis said go do this it’ll be good enough for now and then you can tweak it later and that seems to unstick a lot of things yeah that was very very effective for us
25:00 having a veteran in a space in the room amongst veterans in their space I think is the key Secret Sauce there but this middle box here uh predictability metrics it’s just measure what you need to improve right what gets metric it’s improved so starting to be able to show back to the program here’s where you’re at and here’s where you’re measuring an important element of that is why I’m not measuring for performance reviews I’m not measuring for an individual we’re measuring for teams and the art and we’re in a learning and
25:33 Improvement a continual Improvement phase um managers separately work with their direct reports this has nothing to do with that this is just about an effective art and effective teams so acceleration that’s natural byproduct as you climb this little this little ladder here but focusing on consistency working on role refinement and just getting better at our fundamentals so we can start to pick up some some momentum and accelerate but in short I think high level this is orienting the team in time
26:05 saying the maturity you studied that’s way out here you are back here so at this moment in time this is your orientation you’re focused on that leading them proactively through a maturity game and then just through that process building the momentum and the capacity so this is another one this was a biggie to me as somebody that has decades in waterfall that transitioned worked a few years in iterative waterfall and then truly into scaled agile pis are a game changer for program management just period pausing to reflect I say it as a true Lessons Learned traditionally when you’re leading a program following you know PMI standards and the traditional Paradigm you’re supposed to document lessons learned throughout but then you
27:01 put that all together at the end and deliver it back to your program management office if there’s some mythical book that contains all of these you’re supposed to bring out at the next program I never see that well done with scaled agile and with agile in general like pausing to reflect you get Collective input on efficiency gains
27:23 just for the past 12 weeks it’s it’s ripe fresh in everyone’s mind and it’s actually effective and then taking this 30 000 foot program view it’s easy to lose sight of progress and to be able to reorient everybody to okay here’s what you’re doing well today here’s the metrics today here’s where you’re at here’s how far you’ve come look back at where you were you know 12 weeks ago we still do that today and it’s very helpful I think for everybody just to step back come high level and take a look at it really helps us reset and take back off again and then fine-tuning morale
28:02 when you never stop and it’s a continuous Pace without a pause certainly you can do that but it just feels a little bit more disruptive this one as a realization for me personally I put this quote at the top in leadership you’re always looking for those organic teachable moments if you see something going wrong and something happens in leadership you almost get an excitement like okay we can learn from that I need to make a point to have a conversation with a team or the whole art or an individual about this when you pause and reflect and everyone engages it is talking openly about pluses and minuses it’s natural you can have open dialogue in it in a safe and candid sense so that continual Improvement when you’re new it can be difficult this makes it so much easier those organic moments so it’s a gift for morale and for trust relationships so we host team building exercises whenever we bring people together face to face we try and do something we engage our HR we engage external sources and have a team building exercise that just fits really well in with the with the whole ritual let’s say um so it’s been hugely hugely successful
29:12 on many different fronts for us it’s easy to think about that that retrospective that happens at the end of the pi and and think that we focus on the what went bad what are we going to improve this time but really that Pi system demo that happens right before the retrospective is a big chance to celebrate because you’re able to show what you’ve gotten done in the last 12 weeks and it’s easy to forget in the day-to-day you know or you know throwing more bit of code out there I’m getting one more configuration done we step back
29:42 and look at what you and all of your teammates have gotten done that’s really really big especially when you have the stakeholders or your customers in there who can look at what you’ve done it’s really kind of exciting uh and and the retrospectives often times that would inspecting an app Workshop oftentimes has a huge list of goods shout outs and and yell you know celebrations of thank you for so-and-so for getting this done look at the improvements we’ve made it’s a great thing and then when you get into
30:06the pi planning event itself uh it’s not just about planning the work the creative problem solving that takes
30:12place is immense it’s it’s kind it’s very exciting a little chaotic if you’ve not been to one but it’s it’s very
30:18exciting to see people when we’re face to face kind of running around the room grabbing somebody standing at a
30:23whiteboard having a deep conversation and going okay we’ve got this but it’s also really neat and credit to to Paul
30:31for leading this the rest of the leaders at Moog they’ve also invested heavily in trying to have roughly half of the pi
30:38planning events face to face and so this not only gives that excitement but it also has built that
30:44Social Capital that has made remote working very very successful that chance
30:49to get to know somebody face to face to read their body language as you hear their tone of voice and then so next
30:56time that you’re in a meeting with them and you hear somebody you know whether they’re being serious or whether they’re being a bit of a jerk uh you you
31:03understand that now and less likely to misread them it lets us give each other more grace throughout that time when
31:09we’re not face to face we’re able to be more successful as we work together and collaborate really really powerful uh
31:16very very successful oh
31:22and and all of that explains why some of these case safe customer case studies
31:27have been so true and and why they’ve been so successful uh safe says said by
31:33the book right that they’ve found their research syndicated 30 happier more motivated employees and while we’ve not
31:40necessarily backed that with data what I’ve seen and observed shows that people seem to be much happier than they were
31:46when I got there productivity has definitely improved uh so it’s really
31:51kind of good to be able to see that yes the hypothesis that this is going to improve things is coming true
31:58uh one interesting aspect here this is all about you know uh the the
32:05agile uh value of individuals and interactions over processes and tools
32:11functional hierarchies who reports to who your manager is really really important uh and may feel like a process
32:17and tool thing but a lot of times we’ve built a good relationship with somebody or even if not we kind of know how to manage our manager right so coming in
32:24and and having this idea that we have to get HR involved and restructure the organization if we’re going to adopt
32:31safe can feel very threatening we didn’t do that at all here I don’t think HR was involved at all at least not at first as
32:38we were kicking this off because all we were doing was overlaying the the safe
32:43way of working on top of the existing functional hierarchy so functional managers still existed uh those folks
32:50are responsible for HR functions for performance reviews and for helping to
32:55guide other people in their career progression and we even kept manager or kept titles so if you’re a specialist
33:03yesterday you’re still a specialist today specialist four because that’s important or you’re a project manager
33:08too that that’s okay we don’t touch any of that to be able to get started but we did introduce some some project roles
33:15that we brought in from safe but we also had a little fun with them right Paul yeah absolutely
33:20um what are foes and so’s is something you might ask now uh we have a feature
33:26owner which is synonymous with a product manager and scaled agile and we have a
33:32story owner which is synonymous with a product owner in scale agile so
33:38um product as a term for a world-class product development company was confusing and uh largely we’re a group
33:48of Engineers and so that just became a sticking point and we struggled with it we got some really good coaching from
33:54Josh to make it your own and we came up with this new term so now it’s feature owner and story owner which we have
34:00shortened to faux and so um so we get to have foso sinks today and it’s um it’s fun for everybody but
34:07it’s been that little change has absolutely stuck with us and people try
34:13and read some of the uh updates or take you know updated training as we always do with scaled agile and they have to
34:21kind of now their mind is trying to shift back to wait a minute product owner product manager because we’re so
34:26uh just embedded added with our own Foe and so terms so
34:32all right one of the very important project roles or program roles is that of the release
34:38train engineer I mentioned this earlier very very important role uh this is the
34:43the leader who serves the art uh sort of kind of just makes sure everything is is moving forward and progressing Paul why
34:50don’t you tell us a little bit you’ve got a great RTE yeah we have one of the best
34:57um we are absolutely um just blessed to have somebody absolutely fantastic here but RTE is the
35:04key role and I think of it as probably the role so the advocacy here at the
35:10bottom of the screen very clearly is Choose Wisely it’s not a selection of
35:15convenience so this assumes of course that you are starting up new and you need to select a new RTE this is not one
35:21of convenience it’s it’s deliberate um you may have to advocate for the right person very likely the right
35:28person you need to pick is busy and booked and somebody wants that person he
35:33or she supporting their program so as we say it’s not uh Sally is available and
35:39you just go get that person so Sally this mythical Sally might be amazing it might be amazing at waterfall might not
35:47be amazing as an RTE and so to ensure that it’s the best fit for that person
35:52and the best fit for your program for your art consider these notional
35:57percentages we put up there just to illustrate the point um 30 and 35 percent are people focused
36:06um so it’s not what engineering departments typically key in on for resumes whether that’s an internal or
36:12external review of a resume um it’s often best to promote from within here if you can
36:18but think about that the people smarts and the coaching and mentoring mindset
36:24um it’s you just want to be very deliberate is the best way I can put this and Choose Wisely with your RTE
36:30I’ll point out too in case uh you’re not familiar with safe when we say the release train engineer here we don’t
36:36mean engineers in like a release engineer or a senior engineer we’re using the North American or actually the
36:42distinctly United States term as Engineers the one who drives the train so it’s that sort of person who’s
36:47keeping things on track making sure we’re moving in the right direction at the right speed this person is really
36:53really important because you may bring someone like me in and and think of me as a transforming coach my
36:59responsibility is to help you identify your big changes and then to help like make those happen uh but people like me
37:06also if if you keep me around it might be a little exhausting because we’ve got all these big changes we bring in more
37:12changes um and so while we can bring in that outside perspective and and help you get
37:18out of the analysis paralysis ultimately uh what we want is for me to work myself
37:23out of a job and either go help launch another train or move into higher roles
37:29and higher advisement in the organization or eventually to bring our engagements to a happy ending but
37:36someone needs to stay behind someone needs to continue that change leading that change and the RTE is that person
37:43so I think of them as the sustaining coach they’re responsible responsible for the evolutionary change and helping
37:49everyone to figure out what they should do uh in the future and they do this by starting to learn those underlying
37:56principles and values that the framework has has embedded uh and to make sure the changes we are are making are in line in
38:03keeping with those this is a person who’s here for a very long time and so they’re they’re core to both delivery
38:10and to Improvement an important thing for them to grasp and and I think uh Moog has found this is to
38:17make these changes at a sustainable Pace because there is definitely a reality of
38:23transformation fatigue we can we can exhaust people with a lot of change especially lots of big change so trying
38:30to get just enough up front and then to progress down that maturity roadmap uh
38:35at a sustainable pace very very important for your people
38:42now save as a framework it is not a methodology and and what I mean by that is it is not as predicted or not as
38:50prescriptive as a lot of people may feel it it will give you some general guidance uh but it’s also huge so we
38:58viewed this as a giant toolbox we didn’t try to implement everything nor is our goal to implement everything there is uh
39:04no picture anywhere where we have a view of of this with little check marks and x’s on it saying congratulations you
39:11have adopted 75 percent of the framework that’s not the goal the goal is to find the components here that serve the
39:18program so what we have found valuable were scrum in this two-week Sprints or
39:23iterations that I talked about earlier Pi planning that getting together every 12 weeks to plan out what we’re going to
39:29do over the next 12 weeks and crew and collaborate and creatively solve problems to make that happen
39:35visualizing all the work so no hidden work all the work that everybody’s working on goes up on a kanban board you
39:42can see a kanban board here and as long as everyone is has a the same need to
39:47know we’re not talking about uh you know showing stuff that maybe is security
39:52related that we shouldn’t know but as long as everyone’s in the same uh same realm of knowledge radical transparency
40:00no hidden backlogs this next one’s really really important Force rank
40:05prioritization we made the priorities crystal clear all right Paul Pop Quiz
40:10when I said Force rank prioritization how many ones are there in a forced ranked backlog
40:16one one one one how many twos are there and a force ranked backlog a single two
40:22and in one dot ones zero one dot A’s zero
40:29all right you passed okay thank you good it it seems easy here right when we talk
40:37about it in in a vacuum getting there was really really hard it’s true and and
40:42we even had a time if I recall correctly Paul where someone said this is definitely number one
40:48but then they also said But I really want you to do this other thing first and and so it took a while to really get
40:57used to it at one Pi planning event we stopped all work and made the the leaders stand up in front of the room in
41:03front of the projector and finally agree on the ranked order um but you could see the tension
41:09leaving the room as that happened and people went okay I’ll do this first I
41:15know what I need to do I’m going to put that off until the next Pi it really really helps everyone relax
41:21uh we also document a work in features and user stories features being the size things that are designed to fit roughly
41:27in a pi and stories fit roughly in a in a two-week Sprint typically one to three-ish days and the retrospectives
41:34have been really really valuable so our starting advice is pick the things that
41:39you find useful out of the framework get started with those get moving forward and then change based your changes on
41:45core principles right so
41:51um some of our next steps here moving forward um Josh continues to Mentor our RTE now
41:57we’re at a very good stage of maturity so um I think as you mentioned earlier kind of works himself out of a job here
42:04the job today is I always call it a red phone those edge cases it’s a safety net
42:09if the RTE runs into something challenging that you know she thinks gosh you know that’s an that’s a very
42:16unique condition Josh is there to be able to help us out of that and kind of work through it and then targeted
42:22training to our team where needed that’s something we’ll always do you know continual training and education
42:27um our RTE is certified to provide some of the training and some of the other training that she’s working on or hasn’t
42:34done yet we give assistance from Josh so we’ve got that that red phone to help us out with that as well
42:40um but continual education I’m sure like all the listeners we all recognize that as hugely valuable uh the Lessons
42:45Learned best practices um in scale Dash we want to really share
42:51that out with the rest of the company so um a core value at MO is We’re All in This
42:57Together Moog invested in scaled agile and we want to distribute that value everywhere
43:03we can so we’re very dedicated to that um and then continual improvements in
43:08general just completing a new foundational rollout here at the end of the calendar year we’re very excited about that
43:14um and now we’re deploying new uh functionality and capabilities on top so
43:19we rolled out a new platform deploying now on top of that so building longer Range Road Maps is something we’re very
43:26focused on uh laying a foundation for automations now into the future and we
43:32really just have our site set on that future Road mapping so
43:37all right so I won’t read off the slide my own version of summary here is I
43:44imagine if you’re watching this webinar you’re probably planning to adopt scaled agile if that’s in your future just
43:50think about people and culture first choose the right people and then support that team give them objectives give them
43:57priorities and then move out of the way the first agile Manifesto and a Manifesto principle was individuals and
44:03interactions over processes and tools you saw Josh talk about that one a few slides ago that is first for a reason at
44:10Moog we say trust is a must and that is very important so people and culture first is what I would be focused on as a
44:17program manager starting off on a New Journey with scale the agile and then kick start your team with a
44:23transformation coach honestly that worked extremely well for us that’s why I’m here today again
44:28um I will share what worked well for us so shortcut that learning curve get an expert in there to guide your new way of
44:35working your new way of thinking your new processes it is much faster just to accelerate out from from zero out so
44:42roadmap your team’s maturity we talked about that today not just the program that’s the stuff that’s obvious but the
44:49aggregation of marginal gains was massive for us create a chain of successes build momentum and then
44:54celebrate and recognize all of your successes incrementally at each planning
45:00you know boundary and then increase your scope as your team matures increase the scale bring
45:06more value to your company as I mentioned in our next steps and above all else always just keep improving and
45:12Foster that continual Improvement uh mindset at your company and at your program
45:21 all right so I really like to thank uh both Paul and Josh for sharing your experiences and I and I think you know for me the takeaway um is really your focus on the outcomes and the improvements and and I think watching the interaction of of you and Josh right the leader executive with the transformation coach really highlights what it what agile coaching is right I think so often we hear about agile coaching and it’s just focused on the mechanics of Team level scrum and and ceremonies right and the things that are transformative is that mindset it’s the culture it’s um it’s being focused on improving so thank you very much for sharing your experiences we do have a couple minutes left here if there are any questions that the audience has you can put those into the Q&A I saw there was kind of one about the history of Moog that we handled uh asynchronously during the the talk do we have any other questions for Paul or Josh?
46:48 Right if there are no questions then I’m gonna thank both of you and thank you all of you for joining us for this webinar and have a great rest of the day. All right thank you all, thank you everyone, have a great day!