Scrum at Lightyear: Using Scrum to Develop Solar Electric Vehicles - Part 2

In this episode of the Scrum.org Community Podcast, Dave West continues his discussion with Willem van den Corput, VP Engineering at Lightyear and Michelle Siau, Agile Coach about how Scrum is used at Lightyear to develop Solar electric vehicles, managing complexity and adapting to growth in their organization.

Transcript

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

Dave West  0:20  
Hello and welcome to the scrum.org community podcast podcast from the home of Scrum. In this podcast we feature all sorts of interesting people, including professional scrum trainers, Scrum, practitioners and organizations that are on this journey to professional Scrum and agility. We hope you enjoy this episode. I'm your host, Dave West, CEO here@scrum.org And today on the scrum.org community Podcast. I'm here with Michelle Siau and William Vander Corput from Lightyear. This is actually the second podcast around this topic, which is really, really exciting. The first podcast concentrated really on an overview view of their journey light years journey. If you've not listened to that, please do spoiler alert. lightyear is a solar paneled car. Yes, that call light years first product is sort of in the process of hitting the streets at the moment. And they've just come back from amazing Consumer Electronics Show in Las Vegas where my Twitter feed was full of people saying lovely things about them. So, you know, it just proves that agility engineering can work brilliantly together and deliver amazing products. But today's podcast is very much focused on some of the questions we didn't really get to, in that in that initial podcast, we're going to be talking around the challenges of Scrum, agile with engineering, and particularly engineering of one of the most complex products in the world cars, right automobiles. So welcome, today. Well, I'm Michelle, to part two of the podcast. Yeah, it's awesome. I'm very excited. I'm a little bit as we talked about earlier, a little bit geeky about this stuff. So this is, this is a present for the new year, as it were to have this opportunity to talk to you about. So let's just jump in, we don't need to talk about any of the context setting. Let's just get in. That's, let's talk about the biggest question that I get posed when talking about the use of agility with many auto manufacturers. And as you well know, I spend a lot of time with them. And that is around this sort of like, how do you partition the work? How do you manage the dependencies? How do you keep teams focused? How do you get everybody not to overlap and get into meeting hell? Because it takes a lot of people to design, build and manufacture a motor vehicle. So talk a little bit I don't know. Well, I'm if you want to start on this, on your journey to where you are now with looking at this and the disciplines of building out a motor vehicle.

Willem van den Corput  3:14  
Yeah. It was it was a journey. Yeah, they, because it's, it took us already, I think we are now five, six years all along the way before the first customer is getting his skis in there in a couple of weeks. And that guy, the first guy that could be produced already, and is currently I say, is on a road trip through the US. So as he assets was there, the first number one car, and the customer says in your course getting into key. So it's really, really exciting in that sense. But yeah, we learned a lot. We had, we had a challenging last couple of years, because the last three years we did last bits of the developments. And three, four years ago, we we set up those teams and we started building those teams, but also the car and how we developed it. We started indeed from system engineering point of view. So in the system engineering thinking systems thinking, we set up and we we broke down the vehicle, the product actually in, in multiple systems where we, we didn't go with the current automotive way. So I'd say the conventional one. We split it up in systems that are for lightyear feasible to build. So an energy data platform, we had a client experience platform, we had a driving experience platform, so we split them into three big micro blocks. And from there on we started thinking okay, how our sort of garden work because everything client experience is around the exterior, the interior, and then we start focusing cross functional teams on that and start working on it and start building the teams. So hiring experts from the market, also very difficult in these times because all the experts are pulled into this huge explosion of startups in the world. Last year, I heard more than 700 Plus startup vehicle companies. So OEMs, in essence, and they also pulling along those experts clear clearly, we have found quite some interesting a players as we call them, and sell them into into the system teams. And they are starting to build firstly requirements, but also dieting just best baseball we showed I think we talked about it last time as well. And with wood and crates of beer and update, making sure that we that we have this car in in place, how would you feel the ergonomics were big? Would it be an learn sighting to make CFD models throw in virtual reality reality, doing 3d printing on small scales, they're building up virtual reality glasses, making sure they can get test fast and

adapt. And yeah, I think that there were the biggest steps that we were taking.

We organize ourselves based on those systems, but the people were always allocated in knowledge teams, as we call them domains, the electrical engineers were in the domain of electronics, care engineers were in the CD domain. And those pools were growing. So they were mono disciplinary. They were deployed into the project to the systems and they're a multidisciplinary cross functional.

Dave West  6:43  
Okay, so So you sort of had this, it's almost a bit like the Spotify model, just to use it, where you've got these chapters and guilds as it were, which are the mechanical, electrical, CAD CAM, you know, etc, where they draw on expertise, where they do professional development, where they sit down and go, Oh, my God, I had this problem. Have you seen that before? You know, but then they may this may be an individual on a team in a Systems team that's actually delivering that subsystem that is a combination of those skills. Is that pretty much how you organized?

Willem van den Corput  7:18  
Yep. Okay, please go the valve the proposal team that delivers the motor and the propulsion of the vehicle. They they develop the product of the motors in the controllers and software and everything around so they are cross functional and delivering the product in the end, but only delivering the product for Lightyear. Zero, that team has nothing to do with anything because also allows you to see as alleged to that theme is not in there. So we'll we'll deconstruct the theme, and we'll build up again. Currently, that's that's for the likely to win in that sense.

Dave West  7:51  
Obviously, they're very focused on this particular their product goal to use kjellson scrum type term terminology. As the Agile coach in this podcast. Their product guy was very much focused on on lightyear zero that that first that first that first product, as it were, how big were the teams? Well, if you don't mind me asking

Willem van den Corput  8:15  
the teams, I think, three years ago, we were with 100. Engineers, currently we are 350. So we're thrilled 50 In total, now we have engineers and we will develop finally likely zero into the production. Part of their are split into teams of proposals like 50 or 60 people. We are body and chassis interior. So it's in big, big chunks, and then they will split up in smaller teams to work together. So roll down to like 1015 Max in in Scotland.

Dave West  8:49  
Okay, cool. I want to come back to that in a bit more detail. But I'd love Michel, your perspective, you're an Agile coach, you're not as into cars as me, though you've become quite into it. How did you sort of were dropped into this bunch of very technical, very geeky how, what did it what's your perspective of, of the teaming and the sort of dependencies initially, and then we'll talk obviously, about the future and as you grow, but I'd love to get your perspective here.

Michelle Siau  9:22  
Well, I mean, initially, I indeed it, it's all about the people, you know, it's all about the teams and the people and they're all individuals. And what I saw was that because like yours got such a clear mission on this idea of the lightyear Syrah was so crisp and clear and everybody knew exactly what they needed to do. That alignment came quite naturally. So that that was really nice to see. And I think that that is one of the things that really connected those teams and You could also see that there were teams for software and hardware that have the same objectives. So for example, the exterior team were hardware exterior, but there was also a software exterior team. And they were talking, they were talking together a lot. The same goes for TMS. So thermal management system, because this is so important, within Lightyear. This is really from lightyear itself. They're also there's a lot of the team is actually combined software and hardware into one bigger team for TMS, because it's so crucial. So the teams themselves the systems themselves, they looked at, okay, what are the skills, what's the expertise that we need, actually to be able to release the system or these functions within the system. And they were able to manage that across across themselves and with each other. And that, that I saw was, you could see real kind of, you know, like a kumbaya kind of feeling, you know, when you enter a company, and you're like, Yeah, we're all going for that one goal. It was, yeah, almost that feeling like putting a man on the moon or something, you know, that kind of feeling you had.

Dave West  11:19  
I mean, it is building a new car with new technology in a completely different way that serves is like putting somebody on the moon. In fact, some would argue this is, this is more than that, because we've been to the moon, this is this is brand new. And it's much harder than rocket science. So just want to drill a little bit of that mission. And I want to come back to some questions. Well, that came out of what you described. So how often did you bring you talked about hardware and software being separate in this particular, the exterior team, as it were this in this particular example? You know, the software to move? Mirrors and all that kind of stuff? I assume and do all that kind of interesting stuff. So how did you How often did you bring these? How often did the teams look at dependencies re align? Did they did you have a consistent one increment that brought them together? Or was it that they had separate increments, but they just communicated a lot?

Michelle Siau  12:18  
On a daily basis? It depends on the teams, obviously, depending on how many dependencies there are, and what the impact would be if they wouldn't be aligned for a bit. And also, with regards to the milestones coming up. So if we would have an increment or we would have a planning, which we would do as a whole company, which was also one of the things that we introduced, having a planning as a whole company towards very clear objectives, very clear goals for that quarter, that made that there was alignment on on the plan on the goals and on when it was going to integrate. And that's very, very important on that moment. But throughout the Sprint's and throughout the days as well, they have daily alignments, especially for in this case exterior. And if Yeah, if you have the teams within your own, if you have the multidisciplinary narrative in your own team, then yeah, of course, it could be that you use separate items within euro or a separate view, because it's just easier because one uses a different different flow to another one and needs different tests. But they would still communicate on a daily basis and resolve their impediments on a daily basis.

Dave West  13:43  
And you would incur it, you'd basically integrate frequently, whatever that meant, depending on the work that you would do.

Michelle Siau  13:50  
Yes, I think that that is one of the biggest learnings that we learned pretty quickly, because we had it was quite funny that there was all of a sudden this marketing event popping up. This was before marketing was actually in, in the lightyear zero project. So to say, they weren't actually involved like in inside of it, which was one of the learnings that we picked up later. But there, yeah, all of a sudden, there was like, Oh, this is this marketing event. And we need a certain dv, and it was like, oh, no, and it had to be expedited. Because we definitely couldn't miss that moment. That opportunity. And then yeah, you could see some frustration, you could see people were not very happy about that the plan had to shift. But that was the I think the best thing that happened to us because all of a sudden, everybody needed to work together towards that milestone and towards integrating and towards testing and getting everything ready for this marketing event. And I think that that really, I mean, a lot of work was done and I don't think that people look back on that, how it went in a really nice way. But what actually came out of it, you should have seen how proud everybody was. It was it was amazing. I think people would still get goosebumps, you know, working towards that Ballston, that was a real big improvement also in maturity on agility, and then collaboration that helped us a lot.

Dave West  15:21  
Awesome. So, alright, so we've got these cross functional teams aligned to the, to the ultimate systems that that light years decided comprise this, this this vehicle regard, you know, these bigger teams, which then break down into sub teams, we integrate frequently. You, you incrementally release, zip version zero, I find it hard, same version zero. But yeah, the first release of the product. You have, like catalysts, like this marketing event, hopefully go a little bit better than the test, I'm reminded of the Tesla one with a cyber threat when Elon Musk broke the windscreen because maybe marketing wasn't quite as involved. They wrote the demo, and it didn't clear it with the the engineers probably, but it certainly got impressed. Right, which is, you know, at the end of the day, what it's all about, I guess. So you've got these catalysts that make you realign look at the organization, look at dependencies, look at Oh, my God, maybe we can work a bit better. It's sort of like, brings everyone together and gives them a sort of kumbaya moment. So what happens next, as you start bringing more and more engineers, and now we've gone from 100 or so, to 350? Does this still work? Do you? Do you have, you know, is the product that I'm going to buy, hopefully, in two years, going to be built the same way? How does it work next? Well, um, what happens next?

Willem van den Corput  16:54  
What's next, to do to stay so the growth maybe to make it one step back. So if you saw the, the, yeah, the triple or quadruple growth that we went through, we also were building an organization next to it. So we also building the agility in there, how we would work themes, how we should communicate with teams got to get bigger and bigger. And the next challenge related to that we already launched or at least, presented partially, the team will even be bigger. So I think that the team would go grow to five 600 People in the end, including external partners that will help us develop it, where the girl would cut up in 40 4040, what phases and systems and then the cross functional teams, it seems that the issue that we start running in is starting to be cramped, so to say it's not flexible enough anymore. And then we tried to reach out, you mentioned that before, if you look to other companies, how did they do? And how can we learn from others? How can we combine bits and pieces to to make it into lighter flavor? We want to move into more to have the word bring to people. So our themes is now total themes already being arranged that like, like you mentioned, Spotify, that the guilts, and adapters now the setup, we also trying to see if we can implement more extreme manufacturing, if you see hardware, and they just see in that sense, how could we bring that into more speed, faster delivery, faster prototyping, and learning faster that sense. So we're bringing more teams in expertise centers, and having those teams be responsible for the full products, or parts of the product, or bits and pieces or, or other developments as well, that we can start building knowledge in in in a bigger broader way. But also develop faster. If we can develop faster, we can bring the also the car, maybe even faster the market i Let's hope at least the current plan is very challenging, but will will will we will be able to manage this. But with the growth you also need to train people and bring them on board. So if the crew the teams is is already stable, you can add small people, better pieces, people do it, then the stable team can can grow even faster and more. Organic in essence,

Dave West  19:39  
so just a word a bit about that about skills because this is a universal problem. Obviously it's it's probably more extreme in the in the domain that you're in because of the complexity of the product that you're building. I mean, the beauty of the product you're building is in some levels. It's you're keeping that complexity managed. But but if you are Anchor a pharmaceutical or whatever you've got these, you know, skills versus how do you keep skit? Or the guild's or chapters or the disciplines like electrical etc? are they responsible for ensuring this the the capabilities of the people that come into the teams? The skills are the people? Is that their responsibility? Or is it responsibility of the teams to actually train up and to empower Is it a bit Bove? Tell me a little bit about onboarding new people as

Willem van den Corput  20:31  
you grow? It's joined GA, so we have the domain experts or the subject matter experts, as we call them in the market, they are responsible for it for for the specific knowledge, at the depth of the knowledge. And they are also being responsible together with the teams to hire new people together. So and they, they are both inside the interviewing sequence in order to see okay, do we attract the right skills and experience into the team that is needed. So that's part of the recruitment phase. So to say so and also the phase how to select the right persons, the players or the right person, the right spot and the right date that's been joined EFA at the point that the person that arrives we have, we do kick start meetings, we in the first week, we'll have a lot of onboarding efforts from our onboarding team from HR, but also inside the teams will have bodies in order to manage the data and all the rights for the right tools and equipment startup. And the last year, and we're still developing this one, because the last year for our Finally, with sudden growth, our bodies ran out because the body wasn't ready, three, three months in and then new person should start. And that's also a learning phase we went through. And we tried to digitalize that what the so we can do more elearning that all teams have their own elearning paths that they can the new people can follow you as gen one when you go on will likely go on then you go into teams, one that you can start exploring for a couple of weeks already maximize, maximize the amount of knowledge that you can get a grasp on it before you can start in order to get them a warm start the persons to when they when they come in. But also then we'll be joined into these domains that they also being pulled into the domain meetings that they can use the domains or electrical inside the electrical team, and visa versa.

Dave West  22:44  
Wow. It I mean, it sounds awesome. I, you know, in my career, I've always wished that I had both somebody that cared about the things that I'm passionate about, which for me was software engineering. And it turns out cars now increasingly, but that's a different thing. And then somebody that was helping me make sure I was adding value to the to the team at cetera. And, you know, historically, it's always been one person. So it's great to see those two things coming in. Yes, I suppose it's been popularized by things like Spotify and the Spotify model, but it's really, really cool. So Michelle will talk a little bit about agile,

Willem van den Corput  23:20  
sorry, to interrupt,

Dave West  23:22  
no, no, no pressure.

Willem van den Corput  23:24  
So so we talked about the teams and then ended the race and knowledge. But we also added another flavor that is like the people manager, so the group leaders, that's still a person that maintains a one on ones and by that rules by the person's make sure that they do the personal development, what they want to do if they want to learn something else, or they want to move to a different team. So that's, that's a third layer, the dimension in that way we are answering that that holds people through that mentality that we will, that we that we, that we that we have at least one of our values, to keep that strong. And

Dave West  23:59  
I think that's something that I can't say unique, because I've not been to every single automotive organization, or certainly next generation automotive organization, or 600 of them or whatever it is in the world at the moment. But one thing that I think that likely is doing really well is that you want to build a humane environment, to build amazing products that change the world. Meaning that you care very deeply about the people that are part of this team giving them audacious goals. Yes, challenging goals, incredible, but you also care about them. And you built a support that cares about well being, I suppose one to a better name for it, whether that's career progression, whether that's, you know, how happy people are, whether there's there's things that are challenging in their personal life that gets in the way of professional development and their contribution whether, you know, having that HR or people side is something that we I haven't seen so much I see Do you know yes, there's a HR department, but they just don't want to get there, their responsibilities just not to get sued really, you know, we're wrongful dismissal, etc. And it's really nice to see that you you've got these three, sort of like homes for any human being that works at IBM. So that's really, really, really, really good. I was going to ask, so thank you for bringing that up. Because I even though it's on my list, I forgot to mention it, which is, which is embarrassing. I want to talk a little bit about the role of agile and agile coaches in this organization. So, Michelle, you know, you, you were part of that, that group talk a little bit about, if you don't mind, I'd love to hear your, your perspective on that.

Michelle Siau  25:49  
Yeah, so I think with regards to the Agile coaching at lightyear was really interesting. When I, when I just joined, I noticed that the company was actually already agile. And then I noticed that I needed just to coach on the structure. But when when I was there, there wasn't many there wasn't really an Agile coach, there were more Scrum Masters. And they were all kind of they had their own. Well, just their own way of working, which is great. But I always like to make a lot of impact. So basically, we organized when I told William, I said, William, look, we've got three goals, is that okay with you, we're getting for alignment, autonomy, and like your values. And obviously those people first well we just talked about, that's one of the five lightyear values. And yeah, alignment, we just get across the goals across all the teams and get more autonomous teams. So autonomy there as well, taking into account the alignment on the goals, which are our number one priority. And it was already all there. All I needed to do was just tell all the Scrum Masters, these are the three goals work on them. And then we had our community of practice, we had our roadmap set out. And we basically made sure that within each system, there was at least a scrum master, if not a dedicated one, then one scrum master who, who does multiple systems, and that that really worked because they were able to bring the systems to a kind of maturity state in which this they were able to do their own improvement. And they had a way of working that worked for them. And that's the funny thing, when when Willem talks about organic teams, and it flowing and maturing organically as well, you could see that the more relaxed the teams were with each other, or within the team. And the more mature they were, they could also say, look, we've grown too big, this is not working, we want to split, and they take ownership of that themselves. And it was really great seeing that, you know, you can really see, you know, and it helps to have them a scrum master for the same team. So there is still kind of interface with the teams and the learnings are still learnt and they talk so to the same people. So those kind of things we used. Were also if there was a system that wasn't doing great at a certain thing, but there was a different system, which was really great. Then we made also sure that they had the same scrum master, for example, the product owner would switch or something like that, you know, for a session or for for one of the events. And yeah, it was really nice to see how it grew. And basically with the limited Scrum Masters, we were able to serve quite a numerous amount of teams to be fair. I'm not sure about the figures. Exactly. But I think definitely with the Yeah, it was it was a I don't think we had really any real agile coaches. It was more the Scrum Masters who took on the role as an Agile coach and as a team coach as well. So So yeah, we worked on that.

Dave West  29:14  
Oh, that's awesome. I think that was a little dig on, by the way, you know, more Scrum Masters. I get it. But I think it's you. I love those three things. I think having that clarity of your the accountabilities of the Scrum Masters, and the bringing those together really helped to do many of the things that William talked about in terms of organic growth, clear sort of like deliveries, the three different responsibilities that help a human being I think that just makes everything sort of fit together.

Michelle Siau  29:50  
Yeah, I think the the main basically the main accountability for the scrum master is the team activity. And if you want to do that via training or coaching or mentoring, you need all those skills, you need to have all those stances, you need to be able to be a coach as well. So when you talk to me about agile coaching, I really like the teams, as well as part of that. And that is the domain of a scrum master. And, you know, we just focused on getting getting as much in that toolbox as possible. So not only Scrum, but also team coaching, also, Team maturity assessments, management, 3.0, delegation, poker unit, everything that they might need. And we did that within to vision and knowledge sharing. So we had a lot of a lot of that, because we just need to build up the skills. And if in your toolbox, there's only a hammer, you'll think everything's a nail. So, you know, I always think fill up your toolbox, and you'll be able to handle any team. And yeah, it really works.

Dave West  30:59  
That's awesome. Thanks, Michelle. And we're coming to the end of today, it seems like we've only been speaking for a minute, but we've been speaking, we try to keep these podcasts relatively short. Thank you so much, both of you for spending the time today. I can carry on this conversation, I guess. If if anybody's listening to this in, in the sort of automotive manufacturing complex manufacturing base, if there's anything that you would leave them with a review that might be really interesting. What would be what would be the sort of like the parting words, I didn't put you on the spot, but Well, I'm What do you think

Willem van den Corput  31:40  
would have been? So interesting question, I think we have vision that we will we will we do is to be trying to create the most efficient car, or we started from scratch from nothing. We just started to create a group of people that are joined together, at least that I can find each other. And that's to get the human resources. So that's what you want what we mentioned before, we can get that and people can be in their role that they can like and be happy and work,

how you say it, if a person does what he likes to do, he can deliver more. I think that that's that's for me, the essence of of being.

Being a leader in this kind of group. If people are in the right spot, they can deliver what they what they like to do. And also in that space together for for the calls with the company.

Dave West  32:46  
I love that I love that message. It's all about the people, right? Delivering solving the most complex problems in the world isn't about the problems isn't about actually the technology. It's about the people, bringing them together, providing an environment where they thrive, giving them clear direction, all the things that you've done, like Yeah, which is delivering amazing, world changing technology every day. And that's, you know, I feel blessed to have met you and spend time with both of you about this. So thank you for that. Michelle, you've got something to add, I'm sure.

Michelle Siau  33:19  
Oh, I mean, I would just want to leave it at it's, it's all down to the people. But of course. Yeah, I think the two things which made up were made that was very successful at lawyers. One thing is have a very clear goal, exactly what William said, efficient car, you know, the amount of kilometers to one charge. That was the kind of clear goal, you know, and everybody knew exactly what that was. That was number one. And yeah, I think the other one is, in an engineering company, you can often over engineer, which might, you know, stagnate the company and not help and freeze. And yeah, get one of these marketing guys to come up with a marketing event to expedite things, you know, that really helped a lot in terms of not wanting to over engineer but really going for an MVP. So that would those be my Yeah, two tips. But yeah, I like the one William said, it's all about the people.

Dave West  34:36  
Thank you for that. And imagine that having an engineer so it's all about the people. That's just it's like the world has got stopped, Hell is freezing over. It's brilliant. It's brilliant to hear that and thank you so much for spending the time. I'm really excited to keep to watch you guys and what's going to be happening. And for our listeners, I just recommend that you take the time and Go and look up lightyear and what they're doing, because that's really interesting. And you will see the value of the people that are delivering this amazing technology every day. And you'll see those as you subscribe to their blog and then see the evolution and maybe at some point by one of their amazing, amazing cars. So thank you, once again. I'm sure that will probably in the future, I'd love to drop in and hear how it's going. So let's, let's make sure we do that. And I'm sure our listeners will as well. So thank you, everybody. So just to remind everybody, this is the Scrum.org Community podcast, Dave West. I'm here with Michelle and Willem, I'm talking about lightyear and their amazing journey and how agility helped. Thanks, everybody.