At the Lean Kanban Benelux 2015 conference Jeroen Molenaar shared his experiences working as an agile coach with the Dutch solar car team that has won the world solar challenge in Australia.
InfoQ interviewed him on how he coached the team and how the team has applied Scrum, how coaching a solar team differs from coaching software development teams and what are the similarities, and what he learned from coaching this team of students.
InfoQ: Can you briefly explain how you coached the Nuon solar team?
Molenaar: The team makes a new car every other year. The students who join this project change every year. They step out of the official study for a year to run the race team as a proper company. That brings a lot of challenges in running the company while learning the whole spectrum in one year. While doing that they also need to build a car. So there’s enough to be challenged with.
So this is how we approached it: We started with a brief training at the start of the year in agile and lean principles. That covers some theory and then we just tailor their process so they can start with the practices and principles the next day.
I worked with them every other week to improve and facilitate the improvement of their process and cooperation. I applied retrospectives and helped them with building the team (feedback and also cooperation agreements). Things I could also help with is how to transfer the knowledge to the next team, which still is a struggle. I found out that students can be a bit theoretical so one of the things I coached on is trying/experimenting more instead of calculating.
InfoQ: Can you give some examples how the team applied Scrum for developing a solar car?
Molenaar: Scrum and agile was a very important tool for them. They were so used to the big upfront plans and had a very nontransparent planning which one person was responsible for and therefore lacked team support. What we created was an agile and Scrum way of working where they applied a lot of visual management. They had sub teams and used a Scrum board and a stand up for each sub team. They did weekly sprints and ended every week with an internal demo which was succeeded by a retrospective. It was very enlightening for them to share results throughout the whole team. One of the most helpful parts of information was how many race minutes 1 sub team had won that week.
The retrospectives alternated between having a team focus in one week and a personal focus in the other week. This way they had to focus on either the team or the individual every week. The benefit is that every team member gets feedback from the whole team every other week. This prevents the elephant in the room; annoyances under the surface every one sees but the team is not ready to handle in a team retrospective.
Things I added was a overall planning board which we called portfolio wall. This highlighted the milestones which are very important (more important than in software) when building a car. Obviously a software legal deadline is important, but we can play with what we deliver by then. A car without a body on a race they is somewhat impossible to drive with. So those deadlines are less flexible then the ones we create with software development teams.
InfoQ: How does coaching a solar team differ from coaching software development teams? And what are the similarities?
Molenaar: When coaching these guys you find out that engineers are a similar kind of people; a little bit introvert and somewhat "binary". That makes it very fun for me to coach them. The difference is the domain knowledge. You have to understand that hardware is NOT software. You have to learn new things that are important in their world; calculating, predicting, names of parts. So especially the technical side of agile coaching of software teams is different since the same concepts just do not apply.
InfoQ: Can you share some of the learnings?
Molenaar: So what did I learn from this as an agile coach? The number are not scientific BTW :)
- Young people and engineers in a race are twice as stubborn; Think of yourself without any real life working experience; add to that the extraordinary smartness of these guys and you should get the picture.
- They also learn 5 times as fast as I know in software teams. The software teams I know always have to deal with legacy; that holds them down. These guys treat their world as a total greenfield oblivious to history. This also has its challenges in keeping it real for them.
- Hardware is not software
- testing wise you will need to adapt; you can’t simply test whether a million Euro carbon fiber body will hold up in a crash.
- experiment wise you need to adapt; you simply can’t make a new body when it crashes. What we found out using trial and error is that there are things that can be tested sooner. The assumption that you can only test breaks when they are on a running car seemed untrue. That is why they created a testing cart to build new parts on, so they could test as soon as possible.
- Being pragmatic and agile is applicable everywhere, see the example above. Cooperation (over specialties) is hard everywhere. So getting a team in the winning mode and have team members take over stuff when its important for the team seems to be hard (electronic guys doing structure work)
Al in all it’s a very insightful experience for me as well as for the teams. I can recommend every agile / lean coach to help a race team out for a year. What you will learn yourself is hard to explain but it’s so helpful to reuse it in every other agile organization.
InfoQ: Do you have suggestions for applying Scrum with non software development teams?
Molenaar: My suggestions especially when you have experience in the software domain are: Know that it is different; speak their language and don’t fall back on your software experience too often. My main and most important tip would actually be: Just do It!