“Let’s Experiment With Going Agile…”
In February of 2019, we ran an experiment to see if we could innovate the way we approached product development at Inertia – by applying Agile values and practices. We got inspired with the idea of going Agile while visiting our friends at Borg Warner in late 2018. Soon after our visit, we started to think about how we might implement our own approach to Agile at Inertia.
Our experiment was led by Dr. Felipe Luz, our very own certified scrum master and champion of all things Agile. It’s worth noting that although we’re always keen to improve how we approach our work we didn’t want to jump in with both feet right away. Instead, we wanted to test the waters with one project before deciding if, and how we were going to evolve our approach to developing products for our customers. That was the plan anyways. So much for best laid plans.
For those of you who are unfamiliar with concepts around the Agile, it’s a set of values and practices applied to managing projects and designing products that was originally used for developing software. It’s now really finding its foothold in physical product development. Agile depends on a series of short (2-4 week) highly iterative work sequences that are commonly known as sprints. When applied correctly, evidence shows that sprints can have a huge impact on innovation feedback loop, efficiency and productivity.
Here’s a 2 minute video that helps explain the fundamentals.
To kick things off, Felipe worked with one of our product teams to introduce the core concepts that define some of the practices and values around Agile. We were curious to see if, and how it might improve how we plan, communicate and deliver products for our customers – then something really interesting happened.
After about 2 months, ALL of our product teams voluntarily started to employ Agile to their projects. So much for our gradual approach. Witnessing all of the product teams organically adopting a new way of working was enough to suggest we go all in. So we did.
All product teams, all Agile…sort of. I’ll defer to some of our team (see below) to explain what we mean by “sort of”. It’s been about 8 months since we made the switch and although it hasn’t been all clear sailing, we have learned a ton and realized some serious efficiencies in how we plan, communicate and execute our projects.
We’ve also adapted how we apply Agile to better suit our needs. Agile was born in software development, and applying it to hardware development is a different beast. We know there are plenty of Agile purists out there that might scoff at the idea of bending some of the rules – and we’re okay with that.
A few members of the team shared a little more detail on their experiences so far…
Lisa, Product Development Engineer: “It’s hard to have an actual increment (tangible deliverable) in a reasonable time frame. We tried extending a sprint long enough to have a real increment and it did not go well. It dragged on too long and everyone lost sight of what the original goal was. Right now we’re pretty much planning week by week which is working well – but it means we rarely have an actual increment. That being said, I don’t think it really matters if we’re not doing real scrum, as long as it works, which it does! It has been very productive to get everyone reviewing the upcoming milestones on a weekly or bi-weekly basis. Pretty much keeping everyone in the loop makes people feel more accountable.”
Ethan, Product Development Team Lead: “Initially I laid out detailed tasks for everyone, with DoD (Definition of Done) etc. Then we would decide on difficulty or time as a group. Now I’ll put in high level tasks only, explain them in the sprint planning meeting, and people can break them down into more detailed tasks and estimate times by themselves. I would say this is faster and gives the team more ownership as laying out all the sprint tasks by myself was very time consuming. This has been the biggest learning for me I think. Trying to find the sweet spot of how much direction to give in the tasks.”
Gareth, Product Development Team Lead: “Our first approach on Scrum wasn’t good. We spent a lot of time planning, but then realized that we had to change the plan maybe every week as things changing. So, we started to take things more loosely and having shorter planning session but more frequently. That way I could respond to change faster and better. I feel like 90% of the benefit of agile is planning more. The team started to getting better at task definition and in terms of what everyone will work on every 2 weeks. I don’t need to tell the team what to do, I just tell them the big picture, and they create the tasks. They became better and better at it.”
Randy, Product Development Team Lead: “Its been a great task tracker. Most of my projects have been fairly contained and estimating time and tasks has been fairly easy. I would be curious as how this would work with projects where there is more exploration, trial and error type tasks. I’m still having a difficult time understanding how tasks are translated to time, we’ve evolved from tracking hours to points to percentages and now using an amalgamation of time and percentages… its getting better, but I think there’s still room to improve. Being able to show the client on a weekly bases a really high level progress of the project has been great. i.e. we are 80% completed… etc”
Ray, President & Founder: “Our retrospectives have really improved – especially as the teams are getting more comfortable at contributing to how each other works, how the process is working, and what could be changed to work better. The concept of demonstratable prototype has been a process of learning how to shift our mindset as to what constitutes a demonstratable prototype. This is probably one of the biggest challenges in adopting Agile for hardware. Some examples of demonstratable prototypes are obviously, 3d printed prototypes, design reviews, product testing programs, etc. Another big step forward since implementing Agile is including our customer teams (external) to our sprint management process. This helps align different disciplines and geographically disparate groups.”
Our journey down the Agile rabbit hole is far from over. Felipe has been working on a “How to / Roadmap” guide that reflects how we have adapted to use Agile for hardware development – which we’ll be happy to share shortly.
In the meantime, we’ve included the original post from back in February which includes our original guide on Agile for hardware and some helpful references.
Recently, one of our product teams at Inertia began experimenting with The Agile Framework to see if and how we could improve how we maximize innovation and manage our projects. I use the word experimenting deliberately, for a few reasons:
- First, because we need to see how the team here responds to the change.
- Second, it would be totally naive to assume that this change will work as we hope it will, without a whole lot of testing, feedback and adjustment first.
- Third, we need to assess the impact of this experiment on our business.
Will it make us more productive? More innovative? More nimble? Happier? More empowered to make decisions? These are all lofty outcomes and since Inertia’s bar is already set extremely high when it comes to quality and customer service, Agile has a lot of heavy lifting to do before it becomes established as our de facto way of doing things.
What Is The Agile Framework?
For those of you who are unfamiliar with concepts around The Agile Framework, it’s a particular approach to managing projects and designing products that was originally used for developing software. It’s now starting to really find its foothold in physical product development.
Agile depends on a series of short (2-4 week) highly iterative work sequences that are commonly known as sprints. When applied correctly, evidence shows that sprints can have a huge impact on innovation feedback loop, efficiency and productivity. ‘
Here’s a quick video that helps explain the fundamentals.
There is a ton of nuance in how you apply the Agile Framework. To kick things off at Inertia, our Project Engineer Felipe Luz (who is championing our experimental journey down the Agile rabbit hole) produced an AMAZINGLY detailed living document that captures how we’ll be working within the Agile Framework moving forward. We’re happy to share this with you, just click on the link or image below.
Why Agile, Why Now?
Designing and manufacturing physical products with a high level of success AND customer satisfaction is incredibly challenging. If you’re not nimble, really well organized, overly communicative and on point with your execution and quality control processes, you risk not making the right product for your customers. Not to mention that making mistakes in physical product development (which is a critical part of learning) can become very expensive to fix in the later stages of the design process.
As products become more and more complex and the bar for innovation rises – the processes used to drive their design & creation needs to become more nimble. Looking at how we can make improvements in how we go about managing our projects and developing products for our customers was a core motivation for starting Inertia 15 years ago. You can read more about our approach to our projects here. So in essence, our experimentation with Agile is more of an evolution VS a total sea change.
Examples of Agile in Physical Product Development
Excerpt from Procognita Blog:
The Wikispeed team, led by Joe Justice, is capable of delivering a new version of the road-certified car every week. Note the ‘new version’ words – it’s not another instance of an existing product assembled according to a predefined procedure, but a car with potentially different suspension, engine or the entire body.
Another great example is Solar Roof developed by 3M and Tesla. It took them five weeks from idea to installation on houses. The product is not just generating energy, but it is also more durable and competitive on price compared to regular roofs. And looks great.
However, the product I was most impressed by is a Saab Gripen fighter. It’s developed by four thousand people in short, 3-weeks iterations, tested and integrated at the end of every sprint. And its costs are about 18% of F-35, which is being developed with a traditional approach.
Over the next several months we’ll be blogging about our experiences experimenting with the Agile framework. If you have questions or comments, feel free to post them here on the blog or get in touch with us.