Building a Scheduling System as a Team: What I Learned

🔍 Summary

In this post:

• Built a scheduling system for a local music school as part of a university team project

• Led backend development using Spring Boot and MySQL

• Learned to collaborate effectively within Agile methodology

• Reflected on leadership, teamwork, and technical growth

---

A few years ago, I had the pleasure of developing a large-scale system as part of a team. We were functionally software engineers developing a web-based scheduling system for a local music school from scratch.

I was both excited and nervous about working in a team with other people. Up until that point, I was only used to working on assignments and my own projects alone. I was worried that my team wouldn’t work at the pace I had grown accustomed to, or they would know more than I did and I would feel stupid, or they wouldn’t have the same work ethic I had, and we’d develop something that wasn’t really high quality.

The first time I met my team, I was so pleasantly surprised. I could tell that we were all on the same page about wanting to develop something special and impressive. We immediately started suggesting stakeholders who needed something built for them. One of our teammates had experience working with a local music school and knew that they needed a scheduling system.

After we had all agreed on what we were building, we had to figure out our tech stack. Having recently done an internship as a backend web developer that summer, I had grown accustomed to Spring Boot and MySQL, so I suggested them as our backend and database. My teammates had told me that they weren’t familiar with Spring Boot and had never used it before, but they were all willing to learn. This made me really happy for two reasons: first, I had teammates who wanted to learn new things, so I knew they were as curious and as eager as me. The second was that I’d get to act as a leader for the backend of the system. I would get the chance to work on my leadership and communication skills, which I knew were extremely valuable.

We also decided that our frontend would be done using React. I hadn’t ever used React at that point, but I really wanted to learn how to use it, so I was really excited about that too.

We knew we were going to work in an agile methodology, which meant we’d have monthly deliverables that needed to be presented to our scrum master, sprints, and stand-up meetings. We had to set out goals for when we wanted each part of the system done by. Again, my team was honestly great, and I was so lucky to have had a team that was all on the same page. We all agreed on when we’d have everything done by almost instantly.

Before actually starting to work, we had to have a meeting with the stakeholders of the system. We needed to understand what exactly they were looking for in this system and the functionality they expected from it. They gave us a list of features and ordered them by priority of what they needed included in the system to ‘nice to haves’ but not immediately necessary.

The stakeholders listed the following features such as: an interactive calendar, a messaging feature, user profiles, email reminders before lessons for both teachers and students, and an admin god mode to name a few.

Immediately, we got to work. We had decided for our first deliverable that we’d come up with personas, user stories, and epics to truly understand the different roles that would use our system and what exactly they’d need the system to do. We also built a UML class diagram that mapped out the design of our system and how exactly it needed to be built so it could be functional. Looking back at it now, without doing these things, the system would never have been completed with the quality it was finished with.

We were lucky we had a big team; it allowed us to team up to tackle each of these specific features. On the backend, we knew we needed to start with the base features (i.e., scheduling lessons, canceling lessons, viewing lessons), basically all CRUD features for lessons and users. Since I’d had experience doing something similar to that before, I took the point on that.

I think I made a mistake here, though. I sort of did all that work myself and didn’t really collaborate. I didn’t give my teammates the opportunity to learn how to implement CRUD features on Spring, and that was something I recognized I should have done differently. I tried to be less hands-on after that and collaborate and give advice, and help my teammates as opposed to just doing everything myself without explaining to anyone what or why I was doing those things.

I feel like after I did that, our team was much more able to finish more, in a higher quality way, without wasting too much time. I was able to work on my leadership and communication skills whenever a teammate of mine didn’t really understand how to do something specific on Spring Boot. I felt like I did really well with those skills after that misstep.

One thing I really wanted to do was interface myself to React, and funnily enough, our whole team was struggling to connect the React frontend to the Spring Boot backend. I thought I’d give it a go and see if I could fix it. I even took a course on how to build a system with React and Spring Boot. Unfortunately, I wasn’t able to figure out how to do it either. Luckily, one of our teammates figured it out one night. That was a great night.

That was our system. We finished all the features that I mentioned above, except for the frontend of the calendar feature. We had noticed that we probably added too many features and that it would have been difficult to implement all of them on top of being full-time university students. We did, however, learn a lot and take away valuable lessons and skills from that experience. It’s not something I’ve forgotten, even two years later.