Projects/Geometry Nodes/Sprint12

= Sprint 12 =


 * Start: 2021/03/22
 * End: 2021/03/26


 * Goal: Finish the documentation of the previous sprints (modifiers, everything nodes).

Time

 * Jacques: 3 days
 * Pablo: 1 day
 * Hans: 4 days
 * Simon: 1 day

Impediments
-

Sprint Review
For this sprint there was no retrospective. Instead the team did a retrospective for the entire 1st and 2nd cycles of this project.

What went well

 * Working in a team in a single problem with focus, regular feedback sections and shared responsibilities (#1).
 * Very directed building of a feature (#1).
 * Validated the design and worked as foundation for further development (#1).
 * Give the proper time it requires to build the right solutions (#2).
 * Emphasis on re-validation of priorities without overhead/constraints of format (#2).
 * Getting to a better design and focus with the problem well defined ahead of time (#1).
 * Having a cycle to polish the foundation managed to get a lot in Blender (#2).
 * Community involvement, aligning with community, design ahead of patch (#2).
 * Splitting the project in two cycles.
 * More closed/focused and then another with more community involvement. (#1 #2)
 * Focused-single themed sprints (#1)
 * Quality of the deliverables was very high and polished (#2).
 * Cut down the time for meetings that didn’t require everyone (#2).
 * Kickoffs helped the team feel like working together (#1, #2)

What didn't go well

 * Too many rigid targets (#2).
 * Too many things that needed to be designed (#2).
 * Design weeks lacked work ahead of time (#2).
 * Having a bottleneck like design conflicted with pre-established rigid deliverables.
 * Design throughput was a bottleneck (#2).
 * The footprint of working with daily kickoff and other meetings is high (#1).

Improvements

 * Cutting down the number of targets (#1 vs #2). Separate projects into multiple projects if needed, to help focus.
 * Communicate to the world ahead of the project that the project will happen, where to find updates (e.g., weekly notes) and how to get involved.
 * Dedicate more structured time for design.
 * Make sure the hand-over is planned as part of the project.
 * The project itself can include time for handover.
 * A subsequent project can be proposed only to handle that (e.g., nodes task-force)
 * The project teams should be able to be involved in the module after the project.
 * It helps if it is clear what is expected as part of a hand-over.