In the lead up to the release of ExchangeBuddy, our team has spent countless sleepless nights rebuilding the web application (to support a REST-ful application), while trying to promote it through various means (like setting up booths in NOC related events and N-house events). We are planning to launch our application tomorrow. Having worked in a high-pressure software engineering team in the past 10 weeks (OMG IT HAS BEEN SO LONG??), what I would like to touch on today is something slightly different from the project itself, more to do with how to be an effective software engineering team managing such a project.
First and foremost, I feel that in such projects, everyone’s motivations should be aligned. In this sense, everyone should know the urgency of the project, relative to what each team members expectations are of the project, as everyone definitely has an endless list of commitments to fulfill, and if different group members experience different levels of urgency in a project, it becomes tough to work together. Such things should be worked through from day 1.
Secondly, I believe that everyone should have a vested interest in the project, and the team should come together and set the project requirements clearly from the start. Having experience being a front-end developer, I feel that it is easy to confuse this role with that of a project manager, as this job role will typically be the one driving the product and owning the development of the product.
However, in this regard, everyone on the team should have a clear idea on the direction the team is moving from the beginning and how the product fulfills it, so as to be able to critique on the way the UI/UI/Frontend person presents the product based on the agreed upon direction, rather than the UI/UX/Frontend person driving these considerations from the beginning. This would aid in developing a more focused product, where everyone in the team would have a vested interest in the ideation process.
The above thoughts on direction also leads me to this point. I feel that to be an effective software engineering team, each team member should have clearly defined roles, but should also be willing to cover up for other team members depending on the urgency of the project relative to what is expected from the team member (see the point on Motivations). I have recently been interested in how professional software engineering teams organise themselves, and have been reading up on agile methodologies like SCRUM, which I feel addresses the issue of direction / roles in a team effectively (assuming that everyone is equally motivated in delivering the product).
In the SCRUM methodology, there is a SCRUM master who focuses on making the software team effective, and the product manager who focuses on making a good product. These 2 roles effectively shields the software team from thinking about these concerns for each iteration, and let them only be concerned about churning out new features for the product, within the agreed upon sprint deadline (which is usually 2 weeks).
Coming from a background in CS2103 and CS3216, I know the deadlines of the project and manpower in each group dosen’t allow the use of SCRUM very effectively, but we could potentially take these ideas to SE projects and apply them through small ways, like having a development + product backlog, have daily quick updates on the progress, cover up for each other’s roles when the time comes for it, et cetera.
Finally, I acknowledge that everyone has different working styles, and that every team is different. Adopting software methodologies are ultimately a choice, and it depends from team to team if they are suitable for these methodologies. I appreciate the chance having had the chance to work with 3 talented groups of SE through my 3 SE projects in CS3216, and would like to also use this experience working in these groups to better manage such projects in the future, hence this quick reflection.
On another note, I’m hopeful our launch goes smoothly tomorrow 🙂