Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Transitioning from Waterfall to Agile with Onshape: Experiences and Insights
euan_dykes
Member Posts: 16 ✭✭
Onshape's capabilities are impressive, often surpassing the average comprehension of typical organizations. This raises an interesting point: the adoption of Onshape isn't just about technological enablement; it's fundamentally a mindset shift.
I'm curious if the availability of such advanced tools has organically driven teams towards more agile ways of working together. Specifically, has anyone experienced a shift from waterfall to agile methodologies in product development simply by adopting Onshape?
I'd love to hear your experiences, without needing to share professional details.
- Is this transition a common occurrence?
- Over what period of time did the shift happen?
- What key moments or events catalyzed this change?
Looking forward to your insights!
Comments
There are a few Onshape success stories talking about their Agile work flow. The most impressive I've seen is Ocado - they are doing some really cutting edge stuff with their hardware development.
https://www.onshape.com/en/resource-center/videos/ocado-technology-uses-onshape-to-boost-agile-product-development
1. Software concepts (like Agile, branching development, CI/CD pipelines, etc) are slowly making their way into the hardware world and as a consultant I'm seeing them become more common. I am getting more requests for things like CI/CD pipelines, which are parts of the process that are really only possible with Onshape.
2. Most changes I see happen on a "project" time scale. Companies will start with a single project with the new method, one with either lower stakes or a bit more wiggle room for timeline - work out the kinks, and then slowly push out to all new projects. If you are a company with 2-6 month projects, you'll adopt much more quickly than a company with 4 year projects (its like inertia - but business practices).
3. Theres always resistance to change, a key factor is having someone become a "champion" of the change. That key moment is someone in the company getting that spark and taking action.
I totally agree with you that moving to Onshape can be a "mindset shift". There are some process changes that are only possible with things like FeatureScript, Branching versions, the API etc, and it requires seeing Onshape's value as more than just another CAD. I get really excited when I meet with companies who have this vision and are using it to accelerate forward. Based on your questions - sounds like you have a vision.
Custom FeatureScript and Onshape Integrated Applications
A lot of the pieces are there in Onshape, but the big challenge is that certain parts of the development process of real products is only so agile. Quick turn prototyping has gotten better and better, but when you get to the point where you need to test things with production level processes (injection molding tooling, custom ICs, regulatory testing/approvals, etc) the lead times and lack of integration of those suppliers makes it more waterfall.
Maybe a better question is what do you mean by agile? What kinds of projects are you interested in?
Perhaps a quick explanation of agile waterfalls?
It's a bit of project management geek talk, I wish every professional understood the difference.
Waterfall is called waterfall because effort flows like water down stream and the waterfall is like the delivery of that effort to the next stage.
Agile on the other hand is about the entire project team sprinting to short finish lines, reviewing the outcomes, adapting and then setting up for the next sprint. Waterfall is great for copy past projects: This is how we did it last time, here's the template, repeat and exe. Have regular meetings to check in on status until completion. Agile in contrast is better for projects that haven't been done before. Uncharted seas. You really only want to do agile for high reward projects, because the risk of getting lost at sea is high. Trying to use waterfall on such projects usually results in projects going over budget and time. Inversely using agile for a copy paste project, can result in reinventing the wheel and getting behind, producing pointless solutions.
Waterfall is the easiest to understand. And Gantt charts can be done in Excel. It's also easier to crack the whip so to speak with a waterfall project, set KPIs etc. Therefore I believe there's a bias towards waterfall over agile, simply because it's more prevalent and easier to understand. Agile requires resilience to accept there's still unknown unknowns and sponsor trust to sprint away to discover all the critical aspects. As we head into more disruptive economic environments, the companies that survive will likely primarily do agile. Onshape is enabled for agile. Yet you can still use it in a waterfall method. Many other CAD systems almost force teams to work in a waterfall way, or at least it's cumbersome to do agile with.
Not sure if that makes sense or not.