Project and Team Structure

Contents

1. Project Structure
2. Building Teams
3. Individual Team Structure
4. Communication Between the Teams
5. Roles
6. Skills
7. Team Gathering

Project Structure

During the conceptualization phase of our project (described further below), we identified three different modules:

1. The Core module which provided the core functionality of the website, e.g. the user profile, authentication, notifications, etc.
2. The SmartPlanner module which implemented a calendar and task manager as well as an AI component that schedules tasks for the user.
3. The StudyBuddyMatch module which provided a matching framework to match different users with each other based on survey answers and other data provided by the user.

We created a group of repositories on GitLab containing four repositories, one for each module and one additional repository that contained only finished and tested features. This was done so that each module could work on their code independently, without interfering with other modules. Therefore, only finished features and functionality were merged into the final combined repository. The structure of the repositories can be seen in Fig. 2.

The topmost repository AI Higher Ed / SmartUni is also called the super repository since it only includes the deployable version of our project and serves as a master repository for all other repositories. The Core repository AI Higher Ed / Smart Planner - Core / Core forks from the super repository. It also acts as an intermediary between the super repository and the SmartPlanner and StudyBuddyMatch repositories, with the SmartPlanner AI Higher Ed / Smart Planner - Module / SmartPlannerModule and the StudyBuddyMatch AI Higher Ed / StudyBuddyMatch / StudyBuddyMatch repositories both forking from the Core repository.

To work on the three modules, we of course needed teams. The conceptualization process which led up to the selection and formation of those teams, and a description of how teamwork worked in SmartUni, is covered in the following sections.

Building Teams

1. Beginning with the General Topic of AI in Higher Education

In the beginning of our study project course “AI Support for Remote Learning Scenarios in Higher Education,” the title and basic information were introduced and the meetings led by Dr. Tobias Thelen, who established the study project.

With time, the organization, leading the meetings, and disseminating information was taken over by us, the students. During this process, the project topic developed from a broad overview of the field of AI in higher education to a more specific idea that we turned into our final product: SmartUni.

In the first two weeks, the meetings were held synchronously with a separate seminar course called “AI in Education.” To become familiar with the topic in general and the state of the art, we were asked to watch recordings of lectures on how learning might look in the future, with the goal of us becoming ‘an active, responsible, and creative part of tomorrow’s societies’ (Dr. Tobias Thelen) and learning what kind of ‘Future Skills’ might be needed. Besides the recordings, we brainstormed on several aspects of the future of higher education.

For this brainstorming, we used Mural, an online tool where people can collaborate on shared digital note boards. On an initial board, Dr. Thelen provided six different sections with the following questions:

• What do you expect from higher education? After graduating, I want to be able to…
• What do you think about today’s university? A necessary change about today’s university is…
• What do you think about today’s university? The future university has to keep…
• Where do you use AI in education already?
• What are hopes for AI in education?
• What are fears about AI in education?

Additionally to adding our own opinions to the respective questions, we used the comment function on the board to exchange our views with each other and start discussing.

At this point, after getting familiar with the topic in general and starting our own discussions on it, we as the study project group split from the AI in Education seminar group.

2. Project Brainstorming & Discussion Phase

As we did not know each other before and also had students joining only remotely, we introduced ourselves on a Mural board where we wrote about our diverse backgrounds. Furthermore, we exchanged what kind of experiences we already had regarding key skills like project management and programming and knowledge on subjects like AI, education and related topics. With this, we got a rough idea of who was with us and which backgrounds we could build on. To dive deeper into the topic, we were asked to prepare our most remarkable learning stories for the first meeting of our study project group. The following were the guiding questions for that discussion:

• At which occasion did I learn most?
• When did I learn something really surprising?
• How did I gain insights into my own learning processes?
• Which learning experiences proved to be especially long lasting?
• When did I have a lot of fun while learning?
• What motivated me to learn something in a remarkable way?

The expressed experiences were used as a base for further discussion about what kind of product might be helpful in the future and what we wanted to develop.

Virtual reality and language learning were focused on first, as there was a huge interest in these topics. Moreover, several members of our group already had existing knowledge in these areas. However, as there are quite a lot of intricacies involved with these two fields, such as the ability to properly account for all language rules in a language learning program, that would have made it quite hard and out of scope for a two-semester project, we decided against pursuing these two specific ideas further.

Thereafter, we had a look at our own learning experiences again, especially with respect to remote learning and its difficulties. Among those difficulties, we highlighted the challenge of not having a fixed schedule, as one can watch lecture recordings at any time, and the missing ease of organizing learning groups, as chatting face to face with each other before or after the lecture is not always possible with online meetings.

With these points in mind, we thought of creating a platform that assists students in remote learning with motivation, participation, and feedback issues. After discussion, we decided to implement a common core of a database and several modules that could be integrated into the platform. To faciliate brainstorming on this general idea, we used a Mural board again.

Several modules were introduced ranging from a “Cue and Aid” module, where urgent questions could be answered quickly, over “Crazy Break,” where one is motivated to take a study break in a crazy way, over a “Reward System,” where the user can collect points while studying, to a “Study Hall,” where students can connect and hang out together, and several more.

After collecting the module proposals, we had an online session where we met in breakout rooms in small groups to discuss the different proposed modules. We brought the insights gained there, and remaining questions, back to the main group, where final concerns and proposals were addressed.

With several iterations of voting for modules we wanted to keep, we finally ended up with the following three, for which a dedicated subteam was established for each:

• Core - The team for this module developed the basics of the website and also reviewed and approved changes submitted by the other two subteams before they were pushed to the super repository for deployment.
• SmartPlanner - The team for this module developed the SmartPlanner AI-powered scheduling and calendar application.
• StudyBuddyMatch - The team for this module developed the StudyBuddyMatch study partner matching service.

Besides these subteams, a project management team, consisting of two members, was elected by Dr. Tobias Thelen. The subsequent full-team meetings were then planned and led by them (see further information on the Project Structure.

3. The Concrete Project Idea

We stayed with three different teams, namely the Core, SmartPlanner and StudyBuddyMatch teams. After this was settled, everyone chose to join one of the three teams where they wanted to work in and contribute to.

Within each of the teams, a team leader was chosen.

For the further development process, we met weekly within our subgroups and also once a week with the whole group in so called “main meetings.” In the beginning of the main meetings, which were led by the project managers, the team leaders presented a short summary of what was worked on within the last week in their team. Everybody else was invited to ask questions any time for understanding or to raise suggestions for any procedure or issue. Additionally, some topics concerning the whole group were discussed and introduced, such as the use and procedure of usability tests and the options of licenses to publish our work under.

After the main meeting, specific issues not requiring the full team’s attention were discussed solely by the project managers and the team leaders.

The meetings of the subgroups and their further processes were organized individually. Below is an example of the team building process from the SmartPlanner module.

Example: SmartPlanner Team Process

After everyone was assigned to one of the 3 teams, the teams met individually. The SmartPlanner team created a Miro board, which is also a tool where people can work on projects collaboratively. There, all members of that team posted a short introduction about themselves. This included their background, what they were aiming for in the project, and an optional picture.

In addition to the team introduction section, there was a section about skills and values for successful group work.

The frame for the skills included the three categories ‘Python,’ ‘AI,’ and ‘Design,’ and every member could put their names in either the column of being an expert in that area, meaning they had experience and knowledge in the field, or of being interested in acquiring the skills needed in that area and developing those during the project.

This helped to get an overview of the skills in the SmartPlanner subteam and the focus the individual members wanted to set. It showed that a lot of the members of that team had experience in Python, but not in AI or design. The opposite was the case for the ‘interested’ column, as only two were interested in Python and almost the whole team was interested in AI and design. This amounted to a good foundation, as for every category they either already had experts or they had members interested in acquiring further skills in that area.

Another frame was created to address values for successful group work that the SmartPlanner team wanted to establish within their team. For this, they had the three fields of ‘communication,’ ‘participation,’ and ‘further,’ where they noted what was important to them in detail, e.g. letting other team members know when they cannot stick to a certain deadline, and in a broader sense e.g. “respect”.

In the next meeting, the SmartPlanner team talked about the collected aspects and agreed on them. In the further weekly meetings, the structure usually was that in the beginning every member reported what they did in the last week and how it went.

After that, they discussed remaining issues, e.g. which colors should be used for which items. In the end, the tasks for the following week were distributed.

Every two months, they had a Retrospective, where they reflected on the past workflow. With this, they adjusted their process and weekly structure, ex. with the reflection that they could have a better team spirit, they added ice-breaking questions at the beginning of their meetings. With these questions like, “What was your desired profession when you were a kid?” and “What is your favorite place in nature?” they got to know each other better. According to the retrospective, they kept what served them and improved what did not. But generally, they stuck to the structure established in the beginning.

Individual Team Structure

From the start of our work on SmartUni, the project management team elected to allow each of the three module teams – the Core team, the SmartPlanner Team, and the StudyBuddyMatch team – to organize themselves as they saw fit. This allowed each team to develop a structure which best suited the personalities and working styles of the members of that team. Some structure was provided from a top-down perspective, however. This included the organization of work in a central GitLab repository, the use of git as the version control and contribution proofing framework, and the establishment of one central team leader per team. For more information on GitLab and the git framework, see the Git Framework and Tools sections.

Organization in the Core Team

The Core team met for an hour weekly to discuss and plan for the major tasks which needed to be completed. To ensure the completion of these tasks, the team regularly split into smaller subteams which tackled the implementation of individual aspects of the base platform of SmartUni. Assignment of team members to subteams was handled by the team leader, with input from the team members about their preference and relevant skills. Subteams frequently worked in synchronous online meetings, but members often worked asynchronously as well. The team leader, in addition to working on a subteam themselves, maintained an overview of the needed pacing and remaining tasks and updated the team regularly on where the work stood in relation to the established timeline.

The weekly meetings allowed time to discuss identified problems and to brainstorm together about what tasks needed to be tackled next and how. When Coronavirus-related restrictions were lifted, some members of the team also began to meet weekly in the project’s dedicated offline work time (15:00 – 17:00 on Wednesdays). These meetings usually occurred in the library or in a project space provided by the faculty supervisor. It was not uncommon for multiple subteams to take advantage of the time to brainstorm together and enjoy a more social work environment while completing their work.

Towards the end of the implementation phase of SmartUni, team members also took on more minor issues on their own which did not require a full subteam’s attention.

Organization in the SmartPlanner Team

The SmartPlanner team followed a Kanban-based workflow more closely than the other teams. They held weekly meetings which lasted roughly 1.5 hours each. Work in the team was organized around a Kanban board and oriented towards addressing specific user stories, or statements about what functionalities a user might want from the service. Each week’s meeting opened with a report on where progress stood with regard to each user story in active development. The next week’s tasks were then discussed. No explicit deadlines were used but this overall structure maintained solid progress throughout the year.

For more information on the Kanban workflow and user stories, see A 4-Step Design Process.

Some meetings additionally included presentations from team members on various topics related to the project work or a retrospective about the overall team feeling.

Organization in the StudyBuddyMatch Team

The StudyBuddyMatch team met weekly for one to two hours. Since the first meeting, a general structure was mapped out for these meetings. This ensured a consistent and concise meeting where everyone spoke at least once, making the meeting interactive yet productive. There was a strong level of individual freedom when choosing issues, which were created using GitLab. The issues were organized into milestones so that the individual preferences and the overall progress on the module could come together.

The meetings always started with general project news, which often came from the summits (the main weekly SmartUni meetings) or the team leader meetings. Afterwards, there was a block which was labeled “scrum routine” in which each member recapped what they worked on in the past week and declared what they will work on in the coming week. This is the point where the team came up with software design questions which should be discussed. For small questions, this was done right away. For more fundamental questions, this occurred after the scrum routine. In the event that a person could not attend the meeting live, they would post their addition to the scrum routine in the Element chat and it would be added to the meeting minutes. The meetings provided a central place to bring the team together and form work groups for specific parts of the module.

Early on, the team opted for its own Element space within the overall SmartUni Element space. This allowed for topic specific discussions to take place in dedicated rooms rather than in the general team chat. The StudyBuddyMatch team used an Etherpad in their Element room as a master document where all other relevant links and routines were maintained.

Communication Between the Teams

The communication between the teams took place on a different level than communication within the teams themselves. The involved parties here were the project managers, the team leaders, and the team members themselves. There were two main places were the communication between the teams took place - the general SmartUni Element space, and the regular weekly summit.

The summit was held regularly every Friday at 12:15 pm. All project members were encouraged to join the summit. For this purpose, a reminder message was posted in the main Element room on Friday morning. The summit gave each team member the opportunity to understand first-hand the current state of the project on a global scale. To achieve this, the individual team leaders first gave a summary of the current events happening in their respective teams and the progress being made toward their milestones. After the team leader reports, the project managers updated the team on global project news such as upcoming deadlines, additional code conventions and procedural changes, and successful deployments.

Once after the reports of the team leaders and again after the report from the project managers, the team members were encouraged to ask questions or offer suggestions. This was also the point when points of discussion were discussed. In this way, the summit served as a forum where everyone was invited to raise their voice on current issues. The idea was to have a central place to keep the whole team in the loop regarding the project’s progress. This was meant to keep intrinsic motivation high by following and maintaining the vision the team worked toward.

The team leader meetings held by the project managers following the main summits focused the communication between the teams through the team leaders and concentrated on more specific decisions and discussions that were too fine-grained or otherwise did not require a full-team discussion or vote. While the team leader meetings were open to the full team, most of the time, all but the project managers and the team leaders would leave when this meeting began. The participants of the team leader meeting discussed the topics which were mentioned in the summit in more detail, discussing any hurdles which had or might come up, and how to deal with them. When one team required that something be done by another team, the team leaders would discuss the matter in this meeting. This ensured that problems were solved openly and efficiently, while respecting code ownership of the respective teams. Sometimes these questions came in the form of requests to other teams to implement or change a piece of code; other times, these questions allowed for cooperations between the teams. In the latter case, task forces were often built in which team members of different teams worked on a common global-level project problem. This was encouraged by the project managers to help the different teams benefit from the different skill sets available in the whole group. Often the task forces would come together in a new Element room and work one or multiple weeks on their task.

In general, the public Element space allowed and invited sharing knowledge and asking questions to peers. To encourage this exchange further, a dedicated Element room was also created specifically for technical questions. There, team members could receive help from each other with problems they were facing regardless of the modules the team members involved in each discussion primarily worked on. There was also a room for addressing the whole team on a general level. This was kept for questions and discussions by the team and announcements by the project managers. The team leaders also had their own channel together with the project managers which allowed for fast organization and resolution of issues, and also follow-up discussions after the team leader meetings.

Roles

During the conceptualization process of SmartUni, but also later in the development process, it was possible to contribute personal skills in several roles. The choice was between the roles of project manager, team leader, agile coach, developer, reviewer, and tester, some of which could only be held by one person at a time.

Project Manager

Since the project was to be entirely student-run and only loosely supervised by the faculty supervisor, two project managers were selected by the supervisor through an application process at the beginning of the conceptualization phase. The task of the project managers was to lead and document the meetings of the whole group, to moderate discussions, and to take care of the communication between the module teams and the supervisor. In addition, the project managers were also responsible for the super repository (see Project Structure) and the deployment to the server, and they performed some administrative tasks such as providing the repositories and maintaining the licenses. It was therefore a prerequisite for this role to already have good team leadership and organizational skills or at least to be confident in them. In addition, the project managers also worked as team members in the module teams.

Team Leader

Beside the project managers, a team leader was designated within each of the module teams. Their main task was to coordinate the team tasks and to communicate with product management and the other team leaders. To do this, they established an individual workflow in their respective team, prioritized the order of features, assigned team members to their respective tasks, and kept up to date with the development process through weekly updates. Since team leaders were the first point of contact for upcoming issues, a certain level of expertise in all emerging areas was required in addition to skills in team organization. However, this could be acquired over time and as problems arose. Nonetheless, it was also part of the team leader’s job to research certain topics and pass on knowledge to the team, for example about appropriate workflows, tools, or style guides.

Agile Coach

Even though there were no fixed roles except for project management and team leadership, certain, albeit changing, roles emerged through working as a team and contributing one’s own skills. In the SmartPlanner team, for example, an agile approach was followed in which an agile coach took over the moderation of the meetings to support the team leader and in general also cared for the well-being of the rest of the team. This was especially important to give the team leader a less dominant and more integrated role in the team through more open discussions. Retrospectives, team chat moderation, and team events also fell under the agile coach’s purview. While this role was shared among the team members in the beginning, it ended up being assigned to a specific person. This helped the other team members to focus on their developer role.

Developer

As a developer, one could choose between the role of designer, backend developer, or frontend developer for each new feature, with backend referring to all Django-related tasks and frontend referring to all user interface-specific tasks. Often, but not always, smaller groups of two or three people formed, which then worked together on the design, but then separately on functional and beautifying implementations. In addition, it was then the task of a developer to take care of any problems that arose during a merge request.

Reviewer

To ensure product quality, reviewers looked at the feature design or code after it was completed and revised it with the help of the developers themselves. The design review in SmartPlanner was usually carried out by the entire team, while the code review was handled by a single person. In the other teams and during the consolidation of code across the teams, code reviews were handled by several people (see Reviews and Merge Requests). Especially as a code reviewer, it turned out to be important to know the entire code base in order to understand correlations and not to discover errors only during manual testing.

Tester

Still, both automated testing through unit tests and manual testing were necessary for quality assurance. While the latter was often done by the whole team after a certain number of related features, the unit tests were either added by the developers themselves or by a specific person. Since unit tests on their own require a broader understanding of the Django source code, it was natural to have a single person take on this specialization.

Skills

Even before a concrete plan for the final project was determined, we evaluated within the entire group what skills were already available. This included areas such as general programming skills; AI-specific development; user interface and user experience skills like design and usability testing; and project, data, and software management. It also involved theoretical and practical foundations in education, psychology, and ethics. In addition, it was important which skills should be refined or newly learned in the context of the project. The resulting skills map was one of the decisive factors in choosing and evaluating the feasibility of the product created during the study project.

Later in the conceptualization process, AI and design skills for the two modules, as well as data management and web integration for the core team became the most important. Since a large part of the team had at least a basic knowledge of Python, this programming language was chosen as the programming base.

Even though some skills were already available in the respective teams, some additional skills could be newly acquired within the development process. For example, most of the participants had not been familiar with the Django web framework, nor had they known how to use the Figma design tool or a suitable Git workflow. In addition, some acquired knowledge of JavaScript, CSS and HTML for front-end design. Likewise, others dealt with the topic of unit tests and thus gained a better understanding of software testing. Overall, a classic learning curve could be observed throughout the development work. Thus, the development process took quite a long time at the beginning and was comparatively error-prone. By the end, however, even serious problems could be solved and fewer errors had to be fixed. Over time, the common understanding about the code base also increased, which significantly improved the speed of the individuals’ implementation process. Last but not least, of course, skills on teamwork itself could be acquired, e.g. team leadership and communication skills.

Team Gathering

Throughout our work, we tried to never lose site of the invaluable social connection element within our team as a whole. As our project was open for remote students, and we were still facing the Covid pandemic, most of our meetings were held online. To get to know each other better, we therefore planned a social team gathering at the beginning of the summer of 2022. For that to happen, we had a query asking all members about their time and activity preferences. In the end, we decided for a 4-hour gathering, coming together in a park with some self-brought drinks and snacks to chat and play games. It was a lively meeting, where after working together for several months already, everyone got a real impression of their teammates, who had before been only names in the online meetings.