The geometry nodes project will soon make its debut in the upcoming Blender 2.92. Dalai Felinto made a presentation with an overview of the project process so far, with emphasis on what the team learned from it.
To change a development culture takes time. However, most of the outtakes from this process are nothing new to Blender. Design-driven development and close collaboration with artists is at the core of what makes Blender so successful. The most recent challenge, however, is to find ways of handling this at scale.
Working with multi-faceted teams is a answer to some of those questions. And while the specific framework is secondary, the principles of agile development serve Blender well.
This team-based and design driven development will be reproduced in other projects for this quarter:
- Library overrides (proxy replacement, review and documentation)
- Asset browser (local asset browser and pose libraries)
- Geometry nodes (polishing, attribute workflow, tools)
Related Links:
Very useful presentation! I’m new with Blender.
@dalai Really enjoyed the presentation (and penguin story), and mirrored a lot of my own experience in product design and development, and adopting scrum/agile processes (FYI, I’m a designer / developer not a manager). IMO, I think most bad experiences with these development strategies happen when they are driven by managers / teams who don’t understand why they are useful or the problems they are meant to address ( I have definitely experience that too, and it’s worse than no process at all ). I think that bad vs good scrum experience really mirrors the OUPUT vs OUTCOME definitions you brought up, that is to say, the goal is not meetings, ceremonies, backlogs and charts, it’s transparency, ownership, efficiency, and value delivery, etc.
At the end of the day my golden rule for well implemented and useful scrum / agile (or whatever you want to call it) is, “If it’s not working for the team, evaluate and CHANGE IT! (and repeat)”.
Also, want to whole heartedly agree on the importance of a good design document for directing and developing the the right set of features. I could write a page on that, but I’ll just stop at hearted agreement :D.
Anyhoo, would love to see more of this kind of content, and insight into how the team’s design / development process adapts and grows. Maybe when you’re back in the office Pablo can make a documentary on the design / development of a new feature :D (I would personally love that).
Would also recommend checking out Jeff Patton / Story Mapping (if you haven’t already), as another toolbelt technique for mapping user goals to development features (can be implemented in mural https://www.mural.co/templates/user-story-mapping).
@Ichabodcole Definitely, it’d be great to see more about the inner workings, maybe also get some snippets of the more camera-shy developers. :)
Hi Ichabodcole,
Thanks for sharing your experience. To understand the difference between output and outcome (and have the language to tell them apart) was one of the biggest eye opener I had when I started to read about product.
I have a “agile” mentor who is helping me personally throughout the way. One of the main things he brought up right from the beginning is the emphasis on evaluation/reiterate/change. Strict cerimonies and a solid retrospective goes a long way.
As for Story Mapping, I’m a big fan of Jeff Patton’s work. I read his book last year and is a most-read. I gave it already for two friends, and have been recommending it to most of my colleagues.
I also attended his online course on Passionate Product Leadership last year which gave me a few tools to navigate those waters. It goes a bit beyond Story Mapping and expand over everything product related (risk assessment, prototype, dual- tracking [ aka product and scrum ], sense/focus/discovery/delivery, …)
PS: If you ever feel like writing said page on the importance of design send it my way ;) I would love to read it.
Definitely not here to disrespect or criticize, but as interesting as a lot of these generalized theories are, they are made by managers for managers. Many of them are not proven to have a positive impact on productivity/motivation, often times it’s the contrary (from scrum over open offices to obscure motivational theories).
I’ve seen many developers get discouraged and eventually move on because of pointless routine standups and management techniques taken from bestsellers.
I sincerely hope it works out for you guys.
Hi Dan,
Thanks for your feedback. Maybe I failed to communicate this effectively, but we did not follow this “8 steps program” to structure the project. Instead, I found about it only after the fact.
I knew there was something I wanted to share about the journey so far, and this book gave me the language and the framework to better understand what we went through.
As a matter of fact I had a presentation drafted the week before which was a bit long. (it went over, geometry nodes current design, agile/scrum, and the future of the project). Then on Monday I decided to finally pick up this book. It resonated so much with me that I used it as a reference to re-do the presentation for Thursday (this was an internal presentation first, and then re-recorded for youtube, to reach a wider audience).
Whether or not this can help future projects is yet to be seen. But, as biased as I may be, I believe this mental model can help.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.