I built BoardBot with a team of 5 students in the final project of Principals of Engineering, in Fall 2017. We had 7 weeks to develop a project with non-trivial electrical, mechanical, and software components. You can see full documentation of the project, and how to build your own at scrumbledeggs.github.io.
For this project, my main learning goal was to develop my project management skills. On the technical side, I focused on embedded programming and laser cutter fabrication.
We split the project up into two week sprints, with a design review at the end of each sprint. We changed roles every sprint. Our roles were Lead of: Project Management, Software, Mechanical, Documentation. The lead was responsible for their category of tasks, and assigned them so that everybody worked on almost every part of the project. Changing roles necessitated knowledge transfer every two weeks, which was useful at reducing knowledge silos. It was also a good time to write down information (to aid in the explanation, and to have documentation). This helped me recognize what documentation was useful, and I quickly improved at writing documentation.
The timeline meant that we effectively had one and a half weeks to develop, and then two days to finalize integration and prepare for the design review. We learned that we had to iterate our product quickly in the first week, because integration/implementation took much more time than we kept budgeting. This rapid iteration drastically improved our final product, as it allowed us make mistakes early and often and then have time to try alternatives.
Two of our team members had already taken User Oriented Experience Design (UOCD), and have learned valuable teaming and product management skills in it. I learned a lot from them about how to keep a team’s goals unified, and new design tools for having effective software and mechanical design conversations.
As a team, our learning goals were mostly focused around the toolchains for enabling efficient work on a project. We used Onshape for collaborative CAD, which worked well. I learned the importance of maintaining a clean git repo, to improve productivity and help smooth onboarding.
The complete hardware. See a step-by-step process here.
We also focused on properly documenting of our progress and technical decisions. We kept a blog and status updates on our website, which were very useful references a few weeks into the project. Towards the end of the project we learned how to write blog posts and technical overviews more effectively.
Looking back, I wish that we had pushed ourselves harder to make a better functioning product (especially the software side). There was a lot of talent on our team, and I think we could have created a more polished demo. I really appreciate the efforts we put into documentation, because I learned a lot about what makes documentation effective, which is something I see missing all the time in OSS projects.
Overall, it feels incomplete to me (like all of my school projects), but this one was bigger and we were close to completing something usable and ‘cool.’