Development Methodology#
Our project employs an agile methodology with regular feedback loops, adaptability, and high levels of team communication. We use a flexible scrum-based approach, where every sprint is a week long, however, variance is considered. In the general case, sprints begin on a Monday and end on a Sunday. There is an emphasis on working very closely with the client as to deliver a product that closely resembles their vision. In order to accommodate all of our team members’ schedules and other needs we have no mandatory hours for working and no strict regulations on day-to-day workload equality, however equality of contributions will be sought at the end of the project.
Meetings#
The meetings are planned out in accordance with the weekly sprints mentioned in Development Methodology. Our schedule includes one meeting with the TA , one meeting with the client and one team meeting every week. After the midterm presentation, a second mandatory team meeting has been scheduled weekly.
Due to the client’s main representative being away during weeks 5, 6 and 7, the meetings during those weeks, as well as the midterm presentation, were held with a second representative.
Monday is the default day to carry out all meetings, as it is the beginning of the sprint period, however flexibility remains a core value and in some weeks meetings were rescheduled. The second team meeting has usually occurred on Thursdays and Fridays.
This structure has been chosen for the convenience it brings to all parties – the regularity allows for a continuous stream of information between the team, the client and the TA.
After the midterm presentation, we received valuable feedback for improving the planning part of our project. It was suggested to make our meeting agenda’s en notes more visible to the TA and other course staff, so we can better demonstrate our planning process and organizational efforts. Although we were already creating meeting agendas and notes since the start of the project, after this feedback we began using them more as the core of our meetings. To provide a clear overview, all agendas and meeting notes are now presented in the project’s GitLab wiki [t10c25], creating an accessible archive of our organizational workflow.
Communication#
Our team employs a variety of communication methods within the team itself and with the other parties involved in order to achieve full transparency and maximize the efficiency of communication.
Communication with the client was established outside of meetings to ensure their utmost satisfaction.
The team members have a WhatsApp group chat for communication with each other. That enables instant messaging, thus we are always informed when need be. That choice was also made for ease of use, as there is a standalone mobile application and not everyone is always active on other platforms. A Discord server was also created for online meetings. That decision was also made with efficiency in mind, as all team members are well acquainted with the platform.
For communication with the TA we have chosen to utilize Mattermost, as it is the official TU Delft communication service and it is secure and easily monitored. The TA was also included in the e-mails for scheduling the mandatory presentations.
For communication with the client we have decided to use the TU Delft email service as the client stated it would be most convenient for them. By making that decision we also ensure higher efficiency of communication as correspondence times would be much shorter since all parties check their email regularly.
For communication with the team coach, the TU Delft email service was also chosen since the relative communication quantity is much lower compared to the other stakeholders and cross-communication about the mandatory meetings with all parties involved is made easier.
Task Attribution#
For the task attribution we used GitLab’s planning features. Milestones follow the scrum-based structure discussed in Development Methodology. Issues were regularly discussed and opened in team meetings and irregularly opened during the development process. The task attribution is also available in Appendix B.