Aalborg University

A
Part A. Best practice activity
Giraf project
Part A. Best practice activity

Giraf project

Key data

  • Student cohort: 60
  • Location: 100% online (after 6 weeks)
  • Duration: 1 semester (4 months)
  • Date delivered: Feb-May 2020
  • Activity type: Curricular project
  • New / existing: Existing activity
  • Hands-on element: Code development
  • Cross time-zones: No
  • Case study approved: March 2021

Distinctive feature

Exposing students to uncertainty and complexity in their problem solving

Abstract

Activity overview

Giraf is a group project for students to develop an app for autistic children experiencing profound language barriers.  Taking a highly student-led approach, it requires the full cohort of 60 students to work together on the app’s development: students themselves must organise the cohort into a network of inter-dependent teams and manage their collaboration and app development throughout the semester.  The app has been progressively advanced by each new year-group of students enrolled in the project; incoming cohorts are asked to assess, refine and build upon the existing code developed in the previous year. 

Independent review

The Giraf project exposes students to complexity in two dimensions: in team organisation (the cohort-wide network of groups must work together to deliver a single product) and in problem construction (students must advance and improve an existing product, rather than start from a blank slate).  The move to online ‘emergency teaching’ early in the semester was seen to amplify existing challenges faced by students engaged in the project with respect to intra-cohort collaboration.

Activity details        

Giraf is a group project taken by undergraduate Software Engineering students in their third year of study.  As with all group projects at Aalborg University, students dedicate half of their curricular time to the project, which lasts for a full (four-month) semester.  At the project launch, students are provided with access to the existing code, advice from the previous year-group and an introduction to the ‘customers’: teachers at local specialist schools for children with autism.  The focus and structure of much of the rest of the four-month project is almost entirely led and directed by the students themselves.


Activity overview

Giraf is a group project for Software Engineering students to develop an app for autistic children experiencing profound language difficulties.  The project is designed to simulate the conditions, constraints and interdependencies of a real-life software development project, with a real world client.

The Giraf app (standing for Graphical Interface Resources for Autistic Folk) is designed to help autistic children manage their daily routines and provide them with entertainment.  Since its establishment in 2011, the app has been progressively advanced by each new year-group of students enrolled in the project; incoming cohorts are asked to assess, refine and build upon the existing code developed in the previous year. 

To determine the priorities for the app’s development, students must gather and review feedback offered by two groups.  The first group is the previous year-group of Giraf students, who provide a report and oral presentation on the strengths and weaknesses of both the code they developed and their approach to the project’s management.  The second group is the project ‘customer’ – teachers and speech development therapists from a local school and kindergarten for autistic children – who offer advice on the constraints of the existing app and priorities for future development. 

The entire cohort, comprising around 60 students, is required to work together to produce a working app at the close of the semester.  The faculty member coordinating the project intentionally offers minimal scaffolding and guidance to the cohort, to allow the product development and project management to be almost entirely student-led.  While regular group facilitation is provided, the students must self-organise into operational teams and manage the process of the app’s development, testing and delivery themselves.  In recent years, and based on advice given by previous year-groups, students have typically adopted an ‘Agile’ management approach.  Guided by this approach, students formed a network of interconnected groups: one group interfaced with the customer, one group managed the project and the remaining groups developed different aspects of the code. 

Reflecting authentic software development practices in industry, Giraf students are dependent on others to ensure the successful completion of the project: dependent on the work of previous student year-groups and dependent on the work of other groups. A number of interviewees noted that this interdependence is critical to building students’ adaptability and resilience in their problem-solving: “everything they do when they leave here is dependent on other people, there is uncertainty.  That acceptance of being part of a network of people that are co-creating is part of being both adaptable and resilient”.

Emergency teaching was introduced at Aalborg University in March 2020, six weeks into the spring delivery of the Giraf project.  For the initial six weeks, the students worked face-to-face within their project rooms; thereafter, all work was conducted online. The student-led nature of the project meant that very few changes or interventions were put in place by faculty to support this transition: students were expected to navigate and manage the online pivot with minimal external support.


Independent review

Distinctive features

The feature that sets the Giraf project apart from peer problem-based learning (PBL) experiences worldwide is the level of complexity and uncertainty students encounter as they tackle this activity.  

Giraf forms one element of a wider drive at Aalborg University to broaden and strengthen students’ PBL Competencies (see Box 1) as they advance through their studies, progressively exposing them to projects and problems of increasing complexity and interdisciplinarity.  As illustrated in Figure 1,  it starts with engagement in ‘single discipline’ projects (as shown in the lower left quadrant) in the early semesters of their undergraduate degree, and incrementally introduces variations in the types of projects and/or problems they are asked to tackle.   As Figure 1 indicates, complexity can be introduced in (i) interdisciplinarity; and/or in (ii) complexity of team or problem construction.  The building of complexity culminates with an opportunity for students to participate in one or more MegaProjects: complex projects that are tackled by interdisciplinary networks of teams.  The ultimate goal is to equip university graduates with the competencies, and the adaptability, to tackle any type of challenge facing society, regardless of the problem complexity and the project construction.

Giraf is scheduled at a mid-point in the combined bachelor and master Software Engineering programme.  As such, it represents a stepping stone in the incremental progression in students’ exposure to project and problem complexity.  It is characterised within Aalborg University as a ‘multi-project’: while it only spans a single discipline, Giraf exposes students to complexity in two dimensions:

  • complexity in problem construction: students do not start their project from a blank slate at the start of the semester. Instead, they must develop, redesign and restructure existing code, as provided by the previous year-group of students that worked on the Giraf app.  
  • complexity in team organisation: the full student cohort must work together, as a network of groups, to deliver a single product.  The construction and management of these groups must also be organised by the students themselves such that, by the close of the semester, they deliver a working product that meets the needs and constraints of a real client.
Figure 1. Variation in project interdisciplinarity and complexity as students progress through their studies

Box 1: PBL Competencies, Aalborg University

The PBL Competencies are divided into four interrelated categories: problem-oriented competencies (relating to students’ ability to identify, analyse, formulate and solve authentic problems); interpersonal competencies (relating to students’ ability to collaborate in problem-based work, including relationships internal and external to the group); structural competencies (relating to students ability to organise and manage problem- and project-based work); and metacognitive (or reflective) competencies (relating to students’ ability to reflect professionally on the learning process itself).

Success factors

One of the most striking features of the Giraf project is the extent to which it is almost entirely student-led – organised and managed independently by the students – despite the complex nature of the problem and project construction.   Although communication challenges were apparent (see Section 2.3), the pivot to emergency teaching did not derail the project’s progress or delivery.  The resilience of the students and the project’s design to this online pivot appeared to be underpinned by three factors:

  • students’ PBL experience and training: the Giraf project builds upon students’ training in PBL and two prior years (four semesters) of increasingly complex projects.  Interviewees suggested therefore that students came to the project, and the online pivot, with an important skill set already in place: they had confidence in and a familiarity with strategies both to define and analyse problems and to manage multi-faceted projects.  Such competencies were understood to facilitate students’ capacity to translate the principles to a new, in this case online, setting.
  • learning across year-groups: since its launch in 2011, the Giraf project coordinator has refined its structure and design to maximise students’ autonomy.  With iterative reductions in the project’s scaffolding came an increased focus on learning from the experience of foregoing cohorts: encouraging students not just to build on the code developed by previous year-groups, but also to take on board their lessons learnt in the project’s management.  The robust approach taken by the 2020 cohort, and its resilience to the pivot online, undoubtedly benefitted from this inter-year-group advice and experience.
  • student engagement and connectivity: a number of factors that boosted students’ commitment to the Giraf project also appeared to help sustain engagement beyond the online pivot.  For example, the Giraf project has long been viewed by students as a mechanism to broker new inter-cohort networks.  Following the online pivot, where students were otherwise physically isolated from peers, the opportunity to foster such connectivity was therefore particularly valued.  Student engagement was also clearly strengthened by the authenticity of the experience, both through developing a solution to a real social need and through working within a team environment that mirrored those they would likely encounter in industry.  

Challenges faced

The major challenge experienced by Giraf project students, be they engaged face-to-face or online, is that of collaborating effectively across the network of groups.  Prior to the online pivot, all Giraf students were co-located in a single corridor on campus, working for much of the day within dedicated group project rooms.  Despite working face-to-face in these shared spaces, each new cohort would experience what was termed “a steep learning curve” as they built the competencies needed to navigate the intra-cohort relationships.  The pivot online in March 2020 was noted to amplify these challenges, particularly within the three major routes for intra-cohort collaboration, as outlined below:

  • scheduled meetings: in recent years, and based on the Agile management method, scheduled meetings have been held for the full cohort at the beginning and end of each one-month ‘sprint’ (or development period).  These meetings are designed to allow students to present and discuss progress, issues and future plans.  When held face-to-face, it was noted that the cohort would often “naturally drift into sub-groups to have side conversations” around particular issues or ideas raised in the meeting.  Moving such large-scale meetings online proved problematic.  Online presentations were often delivered to “silence, with no faces to look at [due to web-cams being turned off] and no response from anyone” with few students “having the guts” to ask questions in such a public forum.  Identifying common themes of interest arising from these group discussions also proved difficult, as did sub-dividing students by interest theme in online ‘break-out sessions’.  As a result, online meetings often became “long and quite boring” and structured around a sequence of presentations, with most students playing a passive role.  
  • ad-hoc meetings: prior to the online pivot, students would simply “knock on the door” of peer groups to ask questions or exchange information as and when issues arose.  Following the move online, these interactions were typically replaced with scheduled meetings (which often postponed the exchange) or requests were relayed via brief text messages.  These online interactions were often characterised as being transaction: “it would be formal, straight to the point”. The use of text messaging in particular was also understood to be the source of some misunderstandings and inter-group conflict which affected some cross-group relationships.
  • informal and social interactions: intra-cohort networking and social interactions have long played a key role in the Giraf project, with ‘release parties’ at the end of each ‘sprint’ becoming a regular fixture.  The online pivot put pressure on these informal interactions.  Although some intra-cohort social gatherings were attempted via Discord, the practicalities of bringing together 60 people on a single call led to what was described as “forced and unnatural” interactions which many students soon abandoned.  

Many of these challenges remained unresolved throughout the project.  However, student interviewees noted that their subsequent reflections on these issues would allow them to offer robust advice to future cohorts that were engaged online.  Their major piece of advice was to engage with peers in regular face-to-face video calls, within and across groups, rather than rely on voice calls or text chats. 


Activity details

Giraf is a group project taken by Software Engineering students in their third year of study.  As with all group projects at Aalborg University, students dedicate half of their curricular time to the project, which lasts for a full (four-month) semester.  

At the time of writing, the Giraf project has been delivered twice since ‘emergency teaching’ was first introduced at Aalborg University: once in February 2020 and once in September 2020.  On both occasions, student groups were initially able to work together face-to-face (albeit under social distancing conditions) within dedicated project rooms before all operations were pivoted online mid-way into the semester.  Both cohorts of students therefore had the opportunity to meet and interact face-to-face before group working moved online; all subsequent interactions were remote.  

Structure of the activity

As summarised in the table below, the four-month project was delivered in three broad phases.  Phases 1 and 3 (focused respectively on introducing the project and assessing its outcomes) were the only elements of the activity that were pre-set by the project coordinator.  These only occupied the first week and final two weeks of the project.  Phase 2 (comprising the planning, development and delivery of the Giraf app) was almost entirely student designed and led.  

Phase 1
Weeks 0–1

Project framing

In the first few days of the semester, the Giraf project coordinator provided students with an introduction the project’s focus, objectives and final deliverables.  As is standard for group projects at the university, the cohort was then asked to self-divide into groups of roughly six.  It should be noted that, although the group membership was agreed at this stage, the roles assumed by each group were not yet determined.

The project coordinator provided students with access to the existing code for the Giraf app, the project web-page and all group project reports from the previous year group; each student was encouraged to read at least two of these reports.  Two sets of contextual presentations were then delivered to the cohort:

  • from the representatives of the previous year-group who participated in Giraf: these representatives outlined the progress made by the year group and described the current status of the app (including any omissions and errors in the code).  They also offered advice on how the new student cohort might manage the project;
  • from the ‘customers’ (representatives from local specialist autistic schools): they outlined the daily routines of their children; the strengths and weakness of the existing Giraf app and their priorities for its future development.

The project coordinator then made clear that (apart from weekly group supervisions) the project thereafter would be entirely student-led and managed.  The cohort was subsequently left alone in the lecture room to decide the project’s next steps.

Phase 2
Weeks 1–14

Project planning, development and delivery

Taking advice from the previous year-group, the 2020 Giraf students decided to adopt an Agile management approach.  This called for specific roles to be allocated to each group.  This included one ‘Product Owner’ group (to interface with the customer and convey their needs and priorities) and one ‘Scrum Master’ group (to support the development team and cross-group communication).  All other groups were allocated various coding roles in the app’s development.  

In line with the Agile approach, the four-month project was divided into four discrete month-long ‘sprints’; for each sprint, the cohort agreed specific development goals and subsequently developed, tested and released the updated app.  The first of these sprints focused primarily on rectifying any errors in the existing code.  Subsequent sprints focused in areas such as improving the project documentation and prototyping a new communications function for the app.

The cohort also agreed the protocol for scheduled meetings: a daily meeting for each group, a weekly meeting that brought together one representative from each group, and a meeting at the beginning and end of each ‘sprint’ for the full cohort. Additional ad-hoc meetings would also be held between groups as needed.  After the online pivot, most meetings were held using  Discord voice chat.  The Product Owner group also met regularly with customers to capture their priorities, discuss developments and undertake useability testing of the app (which was conducted via Zoom calls, using a ‘screen share’ function).  

Phase 3
Weeks 14–16

Finalisation of group project report and assessment

In the final two weeks of the project, each group focused on completing their project report, which was used to inform the subsequent oral exam (see Section 3.4).   Each report contained a chapter offering advice to the next year group of Giraf students.

The brief and the deliverables

The brief given to students at the start of the semester was “to create free software for people with autism that works as a communication tool and as a teaching and entertainment environment. The project should be available on all relevant platforms”.  By the close of the semester, the student cohort as a whole was asked to deliver a functional product.  

Each group was also asked to produce a report charting their activities, achievements and reflections on the project.  Group reports were required to contain: 

  • one chapter outlining the role of the Giraf project in their undergraduate studies;
  • one chapter per development cycle (or ‘sprint’) documenting the stages of analysis, design, refactoring, implementation and testing;
  • at least one ‘topic’ focused chapter, in areas such as project management, useability or prototyping;
  • one chapter outlining the groups’ reflection on their project learning, including advice for future year-groups of students.

Learning goals/objectives

The project goals, as stated in the study regulations, are: “that the student acquires knowledge of and skills in analysis, design, implementation and assessment of complex software systems in a larger development environment”.

Supporting this overall goal are learning objectives centred on three domains, as listed below:

  • knowledge: document knowledge of and overview of key techniques in the work of developing software that solves realistic problems; 
  • skills: analyse, design, program, and test applications that are part of a complex organisational environment; 
  • competencies: delineate and implement a solution to part of a major software development problem using appropriate techniques.

Team and cohort assessment

In line with all group projects at Aalborg University, the Giraf project was assessed on the basis of a group oral exam, from which each student was assigned an individual grade.  The oral exam drew heavily on the report written by the group, and asks students to explain, validate and reflect upon both what was written as well as their experience during the project.

Oral exams were undertaken with all group members assembled together with their supervisor and an external examiner.  Each group member first gave an individual 10-minute presentation on their project from a common slide deck shared by all group members.  This was followed by approximately four hours of discussion, with breaks, where the examiners addressed questions to the group members.  The maximum duration of the oral exam equated to 45 minutes per student.  Special dispensation was given to hold oral exams at Aalborg University in person in June 2020.

The teaching team

The teaching team comprised:

  • the project coordinator, who designed and developed the Giraf project;
  • six project supervisors, each supporting up to three groups via weekly supervision sessions; 
  • the project ‘customers’: teachers and speech development therapists from a specialist school and kindergarten in the Aalborg Municipality.

Participants and project groups

60 students participated in the Giraf project in the spring of 2020, working in 13 groups.  As described in Section 3.1, two groups assumed project management roles (that of the ‘Product Owner’ and ‘Scrum Manager’), with the remaining groups working on code development. 

Participants were third year students enrolled in the Software Engineering programme at the university.

Technology used

The following applications and technologies were used in the 2020 Giraf project:

  • project information (such as the schedule and study regulation) was housed on a Moodle system;
  • a dedicated wiki (GIRAF Wiki) was used to organise the code development and provide background information for project groups;
  • building on the existing code, the Giraf app was developed in Flutter (Dart) with the backend written in C#;
  • group interactions with supervisors and customers moved from MS Teams to Zoom mid-way through the semester, following the university’s decision to make Zoom its approved video conferencing software; 
  • students chose to use Discord for communication within and between groups.  Many groups kept their Discord voice channel open throughout the day, to allow groups-mates to interact and ask questions as and when they arose;
  • students also chose to use Trello and GitHub to replace physical ‘scrum boards’ (the Agile approach to project management) for project organisation and to assign tasks to groups.

Source of evidence

The case study for Aalborg University (including Part A, this review of the Giraf project, and Part B, the review of the ‘institutional context’) drew upon one-to-one interviews with 13 individuals: the Vice-Dean of Education in the Technical Faculty of IT and Design; the Vice-Dean of Education in the Faculty of Engineering and Science; one department head; two research leaders from the UNESCO PBL Centre; three undergraduate students; one external collaborator from a specialist school working with the Giraf project; one project coordinator; and three engineering faculty. The interviews were conducted between November 2020 and February 2021.

Further information about the methodology for development of CEEDA case studies is given on the CEEDA website About page.