Holoseat

Review

Claiming Done

• V04-27: Order at quantity any parts where we have high confidence and a reasonable discount
• V04-16: Place order for replacement components on the v0.4 BOM for confirming suitability
• V04-49: Implement python serial library for accessing new version of HSP
• V04-60: Design Rest API in seperate thread that is running using serial protocol
• V04-50: Implement foundation of desktop app in flask
• V04-51: Implement Serial Monitor feature
• V04-71: Branding on keycap
• SME-02: Split social media accounts out into a seperate folder
• SME-03: share only the social media folder with Jazmint
• SME-01: Get Jazmint signed up for Lastpass so we can share passwors securely for social media
• SME-07: Publish at least one blog post in December

Not Claiming Done

• V04-14: Select tone ring based on ease to adapt, costs, identical or faster response times, improved single step
• V04-13: Test the tone rings against the behavior of the existing 12 pole 3D printed design (at least same performance, but looking for faster response times and improved single stepping)
• V04-15: Adapt test rig to use the new auto-adjusting cadence firmware
• V04-26: Assemble a test Wings to verify design (on proto-wing)
• V04-24: Have layout double checked by a volunteer with layout experience
• V04-52: Figure out how to stabilize the TRRS jack when using female header
• V04-30: Test prints of both housings to confirm they will work
• V04-28: Design a housing in Fusion 360 for the sensor and TRRS jack (Sensor Housing)
• V04-29: Design a housing in Fusion 360 for the Feather and daughter board as well as the LED button and TRRS jack (Controller Housing)
• V04-59: Design scheme for checking the hardware version so the software can find compatibility
• V04-58: Implement hardware versioning system that can be detected by Holoseat software
• V04-47: Develop and document outline of new version of HSP
• V04-48: Implement new version of HSP in controller firmware
• V04-61: Implement v0.4 required REST API methods for HSP
• RAT-12: Ask legal aid about collecting health data and verify requirements for data security
• V10-01: Have a volunteer familiar with injection molding review the Sensor Housing and make suggestions to allow the design to be usable for both
• V10-02: Have a volunteer familiar with injection molding review the Controller Housing and make suggestions to allow the design to be usable for both
• SME-11: Publish overview of gamification and gamification of exercise
• SME-06: Publish at least one blog post in November
• SME-10: Research gamify exercise competition (e.g. Pelaton and Virzoom)
• SME-13: Research exerfy games competition (e.g. PC Gamer Bike and Hack a Day DIY projects)
• PIC-01: Submit application to Crowd Supply to see if they would be interested in Holoseat

Retrospective

What went well?

• All component level updates have been completed and verified (still need to verify a couple of assemblies using new components)
• New software architecture is completed and verified at firmware and software level
• Engaged with a lawyer, finally
• Engaged with Roanoke Small Biz Dev Council

What did not go well?

• Too many PBIs not done
• We did not attend all stand ups, or even virtual stand ups
• Did not do a job of engaging with volunteers
• Spent too much time in this and last sprint trying to engage DC biz dev center
• Got overly ambitious (just too many PBIs period - again!)
• Set unrealistic goals for Alpha delivery and have still not accepted what it will take to finish the Alphas
• Not prioritizing communication enough (especially outside of core dev team)
• Personal feelings of not doing a good job of personal time management and task list

What can we do better?

• Find additional volunteers (especially CAD and Marketing)
• Move "will do"s from stand ups each week to personal task list (on phone)
• Develop a metric for determining the size of a planned sprint and select an initial cut off point for max size of sprint work (to include how we address outsourced work)
• Avoid running short sprints in the future, and when we have to run short sprints, the total size of the sprint needs to be reduced from normal
• Reexamine how we address blocks so they are about what is preventing us from making progress
• Address lack of time to commit in how much and what goes into "will do" for a stand up (not treat as blocks)
• Prioritize handling real blocks to remove the thing preventing progress/recognize if block means PBI needs to be dropped from sprint
• Develop cookie-cutter set of external communication templates that are triggered by specific types of content/events (aka poor man's communication plan)