Core77

[gregsonlucas]

almost every industrial design project that I work on used waterfall gantt chart system: brief> research> concept> development> manufcturing.
This can be tedious and long, the worst thing happen is that after we make the tooling we notice stupid problem that should be fixed during concept stage. we feel stupid.

I Stumble upon scrum - design sprint method and I found it interesting, quickly develop viable minimum product in a short time span.
Most Scrum/ design sprint often used in developing apps or digital products since its very quick to generate prototype.

I wonder is its aplicable for physical product project, have anyone have experience with implementing this?

Thanks

[Cyberdemon]

Scrum is just one method of Agile development, which does not really work verbatim when it comes to physical product because physical product has a tooling release, a production release, and hard deadlines that don't exist like they do in software that can be re-written and updated every 2 weeks.

The useful parts of the process which are applicable to ID are the core values of rapid prototyping, user testing, and iteration as a way to develop your best product faster. Which based on your model really looks more like:

Brief->Research->Concept->Research->Concept->Research->Development->Research->Manufacturing->Research

The other part of importance in this model is including engineering and product folks at every step of the discussion, to help inform what is feasible and desired by the market. This aspect tends to be left out in the ID world early in the process simply because most engineers are over-resourced on production projects and don't always have time for lots of concept activities - especially on smaller teams and companies. Large tech companies on the other hand invest tons of engineering early on to de-risk these technologies, sometimes spending years before something sees market. A great example is Apple's acquisition of Primesense - that acquisition happened in 2013, but the tech which powers the Face ID scanner didn't see the light of day til 2017 in the iPhone X.

[AVClub]

The company that I work for uses this and we are a non-digital product company. We have been implementing it for nearly a year now and it seems to be going well. I act as a "subject matter expert" but soon I will be scrumming daily with the teams. Depending on the projects and company sizes you need to have an employee just to help run the teams (scrum master) which also acts as a team member filling in when they can, ours is in an engineer by trade. I haven't fully developed my opinion of it yet, so more to come. I have visited alot of workspaces though recently that implemented scrum or a variation of it, and all of these companies were manufacturing or non-digital product companies. Its definetly made for software companies but there are alot of non software companies trying it out, im not sure if its just a trend that will fade or remain, we shall see.

[Cyberdemon]

It's easy to switch terms around, scrum master = project manager, product owner = product manager, release planning = engineering builds etc.

But theres still a fundamental difference in once your product is released what will happen to that team, and what your "Backlog" looks like compared to just tasks for the week and daily or weekly status meetings vs standups.

It's more "lean product development" where as much of the old documentation heavy methodologies get abandoned.

[slippyfish]

Our company adopted the Agile scrum process for interface design and programming in 2007. It was the hot thing then. We borrowed some of the elements for a somewhat complex and fast-track hardware product, including the morning stand-ups, stories, priority/workload ranking, and multi-disciplinary small project teams. We didn't have a dedicated scrum master. It worked very well, although it wasn't a full Agile adoption, more like 'best practices' that any product development group could implement.

Keeps everyone more accountable and engaged through the project, compared with the standard 'waterfall' where people can see 2 months of downtime ahead of them and thus do nothing.

[NURB]

morning stand-ups, stories, priority/workload ranking,

I would think these elements would be helpful for almost any work environment. Did you guys have someone (a consultant or "expert") come in to help you try to implement these methods, or did you just discuss it as a group and make the choice to do it? Asking for myself, because I would love to implement these things in my office...

[ralphzoontjens]

A scrum or sprint is more of a small scale development trajectory within a larger, industry-wide development process.
It is great for gaining a lot of motivation, developing a strong team and strong concepts as well as requires to do a lot of research and in my experience, doing extra hours. Especially for tackling complex problems, a scrum works great. Then to implement it you need to switch back to longer-term planning and co-operating with departments that work more 'A to B' style. For product design in my experience it is fruitful to do a pressure cooker/scrum once every 6-8 weeks with the rest being regular development work.

[Mr-914]

Nurb: when I was a director, I used to have a daily team meeting. Even if you are an employee, you can just kinda make these happen by asking everyone on your team what is going on. People tend to be nosy enough to dive in.

The priority / work load bit is harder. I tried this a number of times, but other departments were changing their priorities so much it was unmanageable. Having said that, near the end of my stay at that job we started to have a kind of scrum board for technical drawings and product QC. Basically, the stuff that it didn't matter who did it. It worked well for those tasks.

[slippyfish]

morning stand-ups, stories, priority/workload ranking,

I would think these elements would be helpful for almost any work environment. Did you guys have someone (a consultant or "expert") come in to help you try to implement these methods, or did you just discuss it as a group and make the choice to do it? Asking for myself, because I would love to implement these things in my office...

Not directly for the industrial design/product dev thing we were doing. They had an expert for a couple months getting the software/UX group comfortable with the process and we just osmotically tried to absorb how they did it. Sort of like, pick what works, without getting too bogged down in process that we didn't fully understand. The morning stand-ups, the way the 'stories' were written and assigned, and having a consistent meeting place around the magnetic whiteboard full of the little tasks were the most helpful parts.