Being a product manager for my final year Software Engineering capstone project
University is a great opportunity to experience different strategies. As I conclude my undergraduate degree in Software Engineering at McMaster University, I am tasked with a full-year project for my capstone design course. The faculty of engineering promotes a technical and functional design course which combines the practical knowledge of computer science, ability of producing technical documentations and final implementation of a solution with real impact. In other words, one full-year course summarizing a student’s accomplishments with their academic studies. As I journey through the course, there are lessons to be picked up at every milestone, whether it be learning how to work as a team, how to pick up on new technologies and most importantly, how to deliver a solution in a complete and correct state.
To shed some context regarding our capstone project. I’m currently working with five other students in their final year to tackle on a widespread problem in which every student has faced during their time in school. As higher education is becoming more accessible, the size of lectures are rapidly increasing and sometimes create more barriers in order to provide an effective means of learning. From our experiences as students, the act of interactivity between lectures could play a great role in modernizing education with the use of smartphones and smart gadgets. So much so, that bringing your own device to school are already being encouraged to students at an earlier stage. To resolve the lack of interactivity within classrooms, the capstone project focuses on creating an application designed to enhance discussions with peers and instructors, provide a means of assessing a student’s knowledge and allow students and instructors to take part in feedback exercises.
One of the biggest challenges we faced initially was managing the team as a whole. As we began the process of drafting our initial requirements and outputs, it became evident that managing a team of six would be a challenging process, especially if everyone is a full-time student focused on school and other commitments. We decided to split the large team of six people into three sub-teams with a designated team lead that handles most of communications between the teams. The Android, iOS and Backend team all had two members that would coordinate with their corresponding team members. This turned out to be a perfect balance for development as well, since the corresponding tasks would be divided amongst the two members.
Working on a large scale software application, it became a common trend to find the team go off-track and work on problems that were not required for the upcoming milestone. This led to a lot of delays and last-minute implementations for the proof of concepts and demos that involved various stakeholders such the instructor and teaching assistants. After the team being burnt one too many times, we decided to take a charge on how this project should be handled. So at this moment, we introduced a product roadmap to highlight our high level milestones with an addition to a Trello board to keep track of our low level tasks. Immediately after these tools were deployed, the team had a better idea on what they needed to implement and was more motivated than ever to deliver a great product.
Roadmap
Developing a roadmap required a lot of discussions on what the end result should be. As a team, we opted for the features that we all loved and believed were the main reason for the application to succeed and be useful for our users. Our roadmap outlined a four week timeline of the high level milestones that needed to be developed, which included a buffer period till the final submission of the project. One of the interesting aspects of the roadmap was shown as the ability for the cross-platform teams to work independently without being blocked by another team.
One of the greatest outcome from introducing a roadmap was that it allowed the team members to meet once a week to discuss their accomplishments, concerns and gain insights on how they can approach their obstacles in a collaborative environment.
The roadmap provides a high-level view on where the development will be heading towards and how much work is required for completion.
Granted that the high-level milestones are defined, the next step in the process was to divide the milestones into sub-tasks that would be enough for a single developer to complete in the time allocated. This is where Trello comes in handy.
Trello
The use of Trello provided a clear image on the progress of the ongoing tasks throughout the remainder of the sprint. Knowing the tasks ahead of time was a great way to organize around the schedule of classes, midterms and assignments. The development teams had access to all the boards on Trello to allow transparency between teams and can assign tasks to other team members on different platforms.
The Trello board is made of tasks that have been broken down from the high-level milestones. The goal of the exercise was to continuously break down a large problem into a series of smaller problems that can be solved by a single developer within that team in the allocated time frame.
Break down large problems into smaller problems that can be solved by single developer in a given time frame.
In addition, each Trello card represented a commit in the project’s GitHub repository. Not only these commits were used to track our progress, but they helped differentiate each feature and how they can go about being tested in the pre-production stage. As a result of deploying Trello into our development, each team member was more aware of their tasks that they had to complete and count the impact they have made on the overall product in the time span of eight months.
Main Lessons Learned
- Planning starts from Day 1.
- Never assume that everyone knows what they are doing.
- Incorporate software planning applications early on.
- Find ways to optimize code throughput and remove barriers.
- Always include a buffer period (just in case).
Conclusion
The capstone design course was so much more than programming a solution. It was a combined exercise of solving a problem that we were passionate about and adhering to a path of learning, planning, documenting and programming. As a software developer, experiences like these shed a light on the overall effort it takes to make a product successful. The source code plays a big role, but it is also the ability to work with other people and accommodate resources in a timely fashion to ensure that the product is tested and actually solves the problem. Even through, the capstone design course comes to an end, I believe there is still lots to learn as we move into a phase of launching our application for our users.
If you enjoyed this article and would like to be notified when I release similar stories, follow me on Medium and Twitter. Thanks 😊
