Would be really nice to see a timeline of new coming features being worked on.

mcconnell113

One of the things I really liked about fusion 360 is that they inform their followers on what's next. This tends to keep things more exciting. Being in the dark is no fun and it makes it harder to commit yourself to learn something if it may not be what you hope it will be down the road. Thoughts?

brucebartlett

Yes this would be good, even if the dates blow out a bit. Being informed is the key here.

kevin_quigley

Hmmm not sure. After many years of building up a head of steam awaiting promised features from others, I tend to like the occasional surprises OnShape brings. Autodesk have a timeline...but..well..slip sliding away..

mcconnell113

Kevin Quigley said:

Hmmm not sure. After many years of building up a head of steam awaiting promised features from others, I tend to like the occasional surprises OnShape brings. Autodesk have a timeline...but..well..slip sliding away..

You have to remember that software is a lot of hard work to accomplish and set a time frame on it, so it's always likely for dates to be rolled back. It's nice to know the intent of the team though before hand. That way you can decide if the target they are aiming for is the target you're hoping they set for themselves. It's hard to tell yourself yes, this will be the software that I follow and learn more than any of the others if 5 years from now is when we will see drawings implemented, or for me personally I'd really like to see the CAM side of the fence. Partnerships have been announced but that doesn't really mean that I'll be part of onshape within the next 5 years. It's really cool to see new things coming, just would be nice to know the intent.

spiked3

I've seen more damage done showing a roadmap, and then failing to deliver. Sprints are good by me. I trust you guys know what needs to be done. I know a lot would like the info to plan by, but that is exactly the kind of thing that leads to disappointment and bad blood when it does not happen for an unforeseen reason.

john_rousseau

We're following an agile process at Onshape. This means that we frequently look at what users are asking for and use that to reprioritize what we work on next.

This doesn't mean that we don't have a list of important features that we're working on this year, but being responsive to our users means that priorities can shift. We care a lot about how you interact with features, how they look, and how they scale with thousands of users hitting them all at once. All of this takes time. We're more than willing to make a feature wait until we get it right.

On the flip side, we're also willing to put a feature out with basic functionality and see how people are using it (or misusing it) and work to improve it across multiple releases. Your feedback here in the forums and through support really does influence the direction we take, so let us know what you think! 

pete_yodis

The longer I've been in product development, the more unhappy I've been with approaches other than the Agile mentality.  I wish the physical product companies would understand this more.  Can't tell you how many times I've been stuck working on details on something that shouldn't happen because its on a pointy hair's gant chart.  I think the maker community very much gets this.  We need more doing and getting hands dirty up front and less gant charts and pontificating on details that soon become irrelevant.  Sometimes the business engineering mindset can be it's own worst enemy.  Kudos to you guys.  In the end we users will get better features and sooner because you stick to your guns on this one.

caradon

Pete Yodis said:

The longer I've been in product development, the more unhappy I've been with approaches other than the Agile mentality.  I wish the physical product companies would understand this more.

That sounds extremely intriguing...
Do you know any examples of HW companies that embrace Agile development?

In my company too, for the vast majority of projects, classical project planning just DOES-NOT-WORK. We do try: we have operating plans, project plans, milestone plans, traffic lights... However, these tools do a very poor job of helping me to focus on solving real problems. I think people sometimes forget these planning tools are just that... tools, not some sort of religion.
Requirements can (and do often!) change at any time and sometimes with great repercussions on previous decisions. The tools we use are quite bad at capturing/tracking such 'detours'.
I like iteratively refining my designs. It's my most natural state of being and how I perform best.

Dries

kevin_quigley

Interesting. I work primarily for smaller companies, who by their nature have limited resources. I can honestly say most of our design work is "agile". It changes day by day, often hour by hour, depending on feedback. Ive worked on big projects as well on long term projects run by a PM using some online PM tool or MS Project...as has been said, Gantt chart design. And it doesn't work that well UNLESS the PM is a designer who knows the development process inside out.

most are not. most cannot understand that product development is a non linear process. If you want a mediocre outcome, drive a project like it is an accounting exercise.

Contrast this approach with the SME where the person driving the project may be the person making the product/selling the product/dealing with customer feedback. Totally different, faster, more archaic, harder work but ultimately more rewarding.

my biggest annoyance-by far- is when a small company employs or brings in a consultant who has big company process mentality...like it is some magic bullet to nirvana. What works for IBM works for IBM because they have the resources and scale to operate a process. It does not work in a 20 person company on one site.

so, a bit of chaos is good. 

caradon

Kevin Quigley said:

...
so, a bit of chaos is good. 

+1 for chaos!

Dries

pete_yodis

DriesVervoort_Caradon said:

Kevin Quigley said:

...
so, a bit of chaos is good. 

+1 for chaos!

Dries

And the welcoming of a bit of chaos is even better!

pete_yodis

Kevin Quigley said
my biggest annoyance-by far- is when a small company employs or brings in a consultant who has big company process mentality...like it is some magic bullet to nirvana. What works for IBM works for IBM because they have the resources and scale to operate a process. It does not work in a 20 person company on one site.

@Kevin Quigley  It's even worse when they refuse to see that it's not working, blaming people in the wake.  It becomes an object lesson of how not to do things.  Reminds me of this quote ...  "The more the plans fail, the more the planners plan."

pete_yodis

DriesVervoort_Caradon said:

Pete Yodis said:

The longer I've been in product development, the more unhappy I've been with approaches other than the Agile mentality.  I wish the physical product companies would understand this more.

That sounds extremely intriguing...
Do you know any examples of HW companies that embrace Agile development?

In my company too, for the vast majority of projects, classical project planning just DOES-NOT-WORK. We do try: we have operating plans, project plans, milestone plans, traffic lights... However, these tools do a very poor job of helping me to focus on solving real problems. I think people sometimes forget these planning tools are just that... tools, not some sort of religion.
Requirements can (and do often!) change at any time and sometimes with great repercussions on previous decisions. The tools we use are quite bad at capturing/tracking such 'detours'.
I like iteratively refining my designs. It's my most natural state of being and how I perform best.

Dries

Unfortunately I don't know of any @DriesVervoort_Caradon

They must exist for sure.  I'm naturally inclined this way and I understand that others gifts may be more organizational and that's why they tend approach design this way.  But design is not like manufacturing where you know all the steps involved and what's needed each step of the way.  I often like to work on things I know will be needed at some point, it gives me more time to understand a problem and think about it more freely without an artificially imposed timetable.  I think the best ideas come this way, almost serendipitously - our brains literally continue to work on the problems subconsciously while we go about other things.  I have been softly reprimanded for  continuing to develop something for next year because its not in the current schedule - yet when the schedule affords there's never enough time allocated to do it like it really should be done.  That's maybe not even Agile, but is in my opinion much needed and not encouraged enough in the manufacturing realm.

lougallo

@McConnell113 This is not an uncommon request. I completely understand this desire and as much as I would love to just show you our issue tracker, as @John Rousseau said, we are continually measuring feedback and where the needs are, re-prioritize to try to achieve those goals and move forward.  

This is why our support and product development/UX team is one group.  We want to truly understand how you are using the system, what workflows are jammed and how to improve while still achieving the bigger, long term goals.

murray_1

In my last role (where I was engineering director), we developed products that had significant electronics, mechanical and software content. The software team started out using a Scrum (agile) approach, then moved to Kanban with Jira task / bug tracking. The Kanban / Jira method was then implemented across the board by the whole engineering group. It worked very well in that context, giving the benefits of flexibility with open and clear communication. The classical Gannt timing chart was still required at a higher level of course, as the real world was waiting out there but I’d recommend it internally if the program can support the less conventional behaviours and reporting format – some customers, internal and external, can’t work with it, often for perfectly valid reasons. The hardware teams didn’t struggle with it at all, as it was a great improvement over issue tracking spreadsheets and Gannt charts.

A problem many engineers (particularly software) have with agile methods is the conflict between flexibility (ie which tasks are best executed next or possibly even which tasks to abandon) and the absolute need to meet timelines (customer promises, key production dates, test and development builds etc). Classical program managers (using Gannt charts, Microsoft Project etc) often won’t or can’t adapt to reflect the changing needs of the business or the market – instead sticking to them religiously just because that’s what was signed up to a year ago. Flexibility mustn’t be confused with tolerance of slipping timescales but it very easily is. The planning sessions are key to this.

In this instance, there is surely nothing to prevent the publication of a provisional roadmap that reflects today’s view, with periodic updates as the vision is refined and the product features delivered. In the real world of business, there are various stakeholders (not least the shareholders and other investors) who have been promised certain outcomes for their investment. Unless there is no budget, resource plan, timeline etc, then surely there must be some idea of how the various features will be “rolled out”(yuk) over the currently authorised and resourced phase of development.

On a lighter note, it’s amusing to be told by evangelists about new program tools emerging from software circles that promise to transform program delivery (with names like Agile, Lean and Kanban). Often they seem to have little or no awareness of the origin of these words and the philosophies behind them but come to believe that they are so powerful that they could even be applied even beyond the software environment. Just so!

berne

I'd love to see a timeline...

3dcad

I'd like to see just rough status for new features like 'Under review' 'Planned' 'On progress' 'Jammed' and so.. So it would be easy for new and existing users to check what's allready coming and what should be requested - unless you wan't many requests for same features to set the priority?

mcconnell113

I'm not saying ouline detail for detail, but a broad overview of what you're most excited about implementing could be beneficial. You'll actually end up with a lot of feedback on what we think directly rather than trying to guess. I do however think you guys at onshape are doing a wonderful job and would like to let you make the decision on whether or not to clue us in on future development. Heck if you decide to have a timeline just title it Flexible Timeline.

lougallo

There are pros and cons for publishing a list.  While in Beta, we are very interested in what users request without having a list that we publish that might influence what is really important. We will do our best to communicate what we can.  As I have mentioned, what we are going to try to build is a way for our community to post their improvements and vote them up.

andrew_troup

Interesting, Lou. That makes sense to me.

People talk about political polling being a bad thing in the run-up to elections.

 I think they overlook that most of the bad outcomes arise from the results of the polls being made public, instead of simply making them available to the policy-setters and campaign managers.

And the damage, such as it is, tends to be invisible to those who focus on how humans SHOULD behave rather than how they do behave.

It's always an interesting problem to measure an organic process without unduly affecting it.

pete_yodis

driesvervoort_caradon said:

Pete Yodis said:

The longer I've been in product development, the more unhappy I've been with approaches other than the Agile mentality.  I wish the physical product companies would understand this more.

That sounds extremely intriguing...
Do you know any examples of HW companies that embrace Agile development?

@driesvervoort_caradon ; I've been doing some reading... For some reference... https://en.wikipedia.org/wiki/EXtreme_Manufacturing

And to give a shout-out to Oleg Shilovitsky
http://beyondplm.com/2014/07/03/who-will-make-plm-for-extreme-manufacturing/

@murray_1 ; Can I ask what you liked more about a KanBan and Jira approach over the scrum based approach?

pete_yodis

http://www.scruminc.com/scrum-papers/
http://www.amazon.com/dp/0470548681/ref=cm_sw_su_dp
http://techcrunch.com/2015/07/05/how-old-school-management-kills-work-culture/#.hnq6ht:fQxj

pete_yodis

We should mention that Onshape is positioned to work really well in these manners because of the Full Cloud platform they are on.  They knew this when they set out to create something different.  Great work!  I hope the product world catches on.  It's sorely needed....

pete_yodis

Just piling my thoughts on.... Ultimately 3D models should be the essence and full conveyance of design information and not a separate 2D drawing that is semi associated with the model.  This is agile based 3D product design and manufacturing.  Other spheres of manufacturing need to come around to more intelligently use the models instead of treating models as second class citizens.

philip_prendeville

murray_1 said:

In my last role (where I was engineering director), we developed products that had significant electronics, mechanical and software content. The software team started out using a Scrum (agile) approach, then moved to Kanban with Jira task / bug tracking. The Kanban / Jira method was then implemented across the board by the whole engineering group. It worked very well in that context, giving the benefits of flexibility with open and clear communication. The classical Gannt timing chart was still required at a higher level of course, as the real world was waiting out there but I’d recommend it internally if the program can support the less conventional behaviours and reporting format – some customers, internal and external, can’t work with it, often for perfectly valid reasons. The hardware teams didn’t struggle with it at all, as it was a great improvement over issue tracking spreadsheets and Gannt charts.

I'd be very interested in finding out a little more how exactly the design engineers used Kanban / JIRA. I was under the impression JIRA was just used for working on and sharing code?