Scrum in Industrial Design?

I am starting a new series of more technical posts which came after reading many books, entries and courses where I have learnt Scrum methodology, which [almost] always is linked to the digital development world. My thoughts have always gone around generalising its application to any other design project and, more specifically, now I want to get deep into my discipline: Industrial Design. I have never read something in between both worlds, so everything I am about to write is mere speculation and I am looking forward to increasing my knowledge along this path.

For those of you who are less experienced in this matter, Scrum is -very roughly- a framework inherited from agile methodologies which breaks with traditional project planning, focusing importance on value-based prioritisation, in team self-management, in fluid and effective communication and in a continuous user validation of the hypotheses about the product.

It works especially well in the area of coding and digital development because these iterations (called “sprints”) allow to release updated versions of the product on a regular basis so you can receive almost instant feedback and thus, in the next sprint, work on the improvements to be implemented on the new version.

Although Scrum has its “game rules”, for several years I have tried to put into practice its essence adapted to the different projects in which I had the opportunity to coordinate a team and, in the case of those of Industrial Design, we faced several problems that we can not overlook. (Another day we should talk about Scrum for events).

Scrum lives on the concept of MVP or Minimum Viable Product. It is often explained with the example of many websites which, on their antediluvian versions, already satisfied their original needs and, from then on, they were redesigned until the current success cases. As we already have seen too many versions of the paradigmatic example of the car used when explaining lean startup, I felt inspired to create my own version. It basically shows how, if someone has the need, for instance, to write a document, it does not have to be accomplished by a computer since the very first prototype.

Or does it? If we are developing a product, is it coherent to develop similar products that satisfy the service but that are not projectually comparable? And even more: can that product be tested in the same way? Let’s imagine that we want to design a hammer. Yes, we want to cover the service of hitting stuff. We could design an infinite number of objects that can be used to hit, from a baseball bat to a shoe or, indeed, a hammer, but then we have to face validation. Does the existence of a sprint imply that we can actually create a cardboard hammer as the first prototype?

I don’t want to seem simplistic about digital development but, when the user has to test a new version from an app or a website, it is enough for that person to get access from their mobile phone and, from there, to immerse themselves into the digital world where the whole experience will happen (always with a pursuit, of course). However, when testing a service or product where the real world gets involved, there are brand new factors appearing onto stage: more context, body interaction, matter itself… Can I test a hammer if I do not have a nail to hit? Does my arm get tired after an hour hammering? Does this short test guarantee to me that it will continue working so neat after months of use? How can I repair it if it breaks?

Research area deserves further mention; the use of quick work sprints means that research sometimes (or maybe all the time) does not reach the depth and maturity level it should, due to the urgent need to develop prototypes as soon as possible so we have to investigate at the same time or even after the development. Actually, this is not an exclusive feature for the physical product because it can relate to many other design areas.

Something that it’s pretty clear at first sight is that manufacture times with a physical product are inexorably higher than those from “manufacturing” a digital product. In fact, in a certain way both of them are being “manufactured” during the design process, with the difference that the physical product needs a final leap to make it a reality.

Let’s suppose that manufacturing technologies based on rapid prototyping or short industrial pre-series are enough to develop a product that solves that problem (too much to suppose). We still need, at least, logistics and transport times, and we can even think of having thousands of internal components that we have to search one by one.

Once, I heard about sprints in a “lagged” way depending on the expertise of each member in the teams created. I know that departmentalising an agile methodology may make you cringe, but there are times when it may be the only option. Let’s imagine that we have created a development-oriented team and another research-oriented team, both of them working in parallel but with a lag (“al tresbolillo” I would say in Spanish), so that, although a sprint has not finished yet, you can take advantage of the manufacturing idle time to start developing the next. This is a contradiction considering that we would have to test the product, gather feedback and create a new changes backlog to be able to start working on it, but it could be adjusted if we make a first functional prototype through digital manufacturing -quicker- and we carry on next with more complex prototypes where we can apply this system. Let’s go even further: could both teams be the same, constantly changing their masks back and forth in both phases?

Anyway, the product backlog would be a very unique artefact, since we would have to release improvements not only in an incremental way but also noting the required fixed times.

Time is money and everything linked to the time factor has a related cost. Not only the time from design or engineering, which is something easily integrated into the framework, but manufacturing and logistics time. Digital manufacturing starts with the advantage of reducing costs, but more quality finishes will require better machines. If we talk about manufacturing with molds, numbers get insane and scale economies appear, so scrum collapses quite a lot. Because when we spend 15,000€ (falling short) in a mold that will manufacture hundreds of units for months… are we leaving room for user validation to correct future versions? I’m afraid to say not, so maybe we can only be agile thanks to digital manufacturing and a very fine estimate of logistic costs.

Needless to mention that our product will not be appearing and disappearing almost instantly through your computer, so we need to take into account all this transportation, which, as we can imagine, also requires an extra cost for urgency issues.

One consequence or possible solution to reduce persistent production costs is that theses sprints maybe have to be longer than expected with a digital product. This is, a not totally full product backlog cannot compensate a new iteration and it is necessary to “overload” it with improvements so that the shipment to the factory really compensates, in terms of costs and in terms of increment.

Another option would be to divide the type of revision in two: emphatic and technical. Thanks to the first, we evaluate acceptance and adaptation to users -as in a digital service-, but with the second we perform toughness tests, structural optimisation and other parameters that will have to match with the feedback for next iteration. Obviously, it is always expected to make a review in terms of quality but, as manufacturing costs are so high, we should put special attention to this aspect.

Finally, we have the option of separating the sprints into two categories: important ones (actually all of them) and really important ones, depending on whether we are going to manufacture a prototype using more flexible and cheaper technologies or, on the contrary, some more advanced and expensive. First kind of sprints can be focused on user validation and second kind of sprints also on this validation but together with technical validation.

**********

We have encountered a lot of divergence and many issues but I really do not want to attach to any conclusion. There are innumerable thoughts I have had and I will keep having about whether it is possible to standardise in some way the rules of Scrum for Industrial Design and perhaps everything has to pass through a segmentation of the different (and infinite) cases of Industrial Design projects we can undertake. It’s not the same a unique functional prototype, an exhibition design with defined deadlines or large-scale industrial manufacturing.

By this moment I have no extra objectives other than to write about all these approaches and to complete my posts with new ideas that I consider worth sharing.

Written originally in Spanish at dllamas.es