PreprintPDF Available

Abstract and Figures

Learning processes within higher education programs increasingly focus on applying concepts rather than just facilitating the comprehension of concepts studied. Some of the curricular elements commonly used can be classified as project-based exploratory learning activities that usually pose unique challenges for students. Examples of such activities include theses or individual projects. To be successful in these tasks, students require more agility and flexibility in designing, managing and implementing their project. This contribution addresses those requirements by introducing introduces a concept that adopts the SCRUM methodology to facilitate project-based learning processes in higher education. It discusses application scenarios and benefits of a more iterative and agile approach called Agile Learning Loops (ALL), describes the new methodology in detail and addresses its application potential.
Content may be subject to copyright.
AGILE LEARNING LOOPS – COMBINING AGILE
APPROACHES IN HIGHER EDUCATION PROGRAMS
Karsten Böhm, Yvonne Unnold
FH Kufstein Tirol – University of Applied Sciences
Andreas-Hofer-Str.7, A-6330 Kufstein, Austria, e-mail: {karsten.boehm | yvonne.unnold}@fh-kufstein.ac.at
ABSTRACT
Learning processes within higher education programs increasingly focus on applying concepts rather than just facilitating
the comprehension of concepts studied. Some of the curricular elements commonly used can be classified as project-
based exploratory learning activities that usually pose unique challenges for students. Examples of such activities include
theses or individual projects. To be successful in these tasks, students require more agility and flexibility in designing,
managing and implementing their project. This contribution addresses those requirements by introducing introduces a
concept that adopts the SCRUM methodology to facilitate project-based learning processes in higher education. It
discusses application scenarios and benefits of a more iterative and agile approach called Agile Learning Loops (ALL),
describes the new methodology in detail and addresses its application potential.
KEYWORDS
SCRUM, learning framework, project-based learning, agile learning, learning loops
1 INTRODUCTION
Higher education should enable students to build advanced scientific and abstract thinking skills for problem-
solving that they can apply in their professional career after their studies in their respective subjects. Thus,
courses should not only provide an opportunity for the acquisition of knowledge. It is imperative that they
train students to apply this knowledge in chalenging and real-worldscontexts. Project-Based Learning (PBL)
(Chen and Yang, 2019) provides valuable learning opportunities to apply their knowledge, including
previously acquired knowledge or new insights that students discover as part of the project. Generally, PBL
activities are student-driven and involve limited supervision or guidance by lecturers. The open character of
PBL poses a particular challenge for students and facilitators because much flexibility is required to reach
curricula learning outcomes.
Learning Loops (Kolb, 2014) has been distinguished in didactic literature as an effective way to deepen
understanding and enhance skills via iterations that allow opportunities to learn from mistakes and
incorporate insights gained through feedback loops (e.g., iteration). However, due to the time and resource
constraints in many curricula, the provision of opportunities for circular learning is not always feasible.
In the realm of computer sciences, SCRUM (Schwaber, 2007; Srivastava, Bhardwaj and Saraswat, 2017)
has been established as a methodology to develop software systems in an agile way, using iteration in
individual development cycles to improve the process and to react to changed environmental conditions or
project goals. However, SCRUM methodology can also enable the implementation of learning loops for
specific projects. The present study's core goal is to demonstrate the applicability of the SCRUM
methodology for teaching purposes in higher education subjects that corporate PBL.
Surprisingly, research published on this topic is limited. There are a few papers on the use of SCRUM for
educational purposes in schools (i.e., Royle and Nikolic, 2016). In the realm of e-learning, SCRUM has been
used to manage the process of designing course content (Supangat et al., 2019; Vogelzang, Admiraal and
Driel, 2019). However, to the authors best knowledge, SCRUM has not yet been used for an educational
design in the area of higher education.
The paper is organised as follows: Section 2 describes the concept of Agile Learning Loops (ALL) as a
learning design framework with references to loop-style learning models and presents the ALL process,
including associate roles and activities. Section 3 elaborates on the current application of ALL in the context
of a higher education program, and section 4 outlines the present-day IT-tools supporting the implementation
of ALL. Finally, section 5 concludes the paper with a summary and an outlook on planned next steps.
2 THE CONCEPT OF AGILE LEARNING LOOPS
The concept of Agile Learning Loops (ALL) focuses on a methodological transfer of the SCRUM
methodology (Schwaber, 2007) and of the organisational concepts of loop-oriented learning models, such as
Single-, Double- and Triple-Loop-Learning (Argyris and Schön, 1978), as an organisational design
framework into the context of a learning situation in higher education, and, thus, into a learning design
framework for PBL. The intention of this transfer is to provide an agile supporting framework for student-
oriented tasks that (a) helps the learner structure the learning process while maintaining maximal flexibility
for the project and (b) affords coaching opportunities for the lecturer to assist the student throughout the
project with minimal interference in the learning process.
The aspects that are taken into account for this transfer include a) the roles, b) the activities, and c) the
process defined in SCRUM that need to be transferred in a meaningful way to the ALL methodology.
2.1 Loop Style Learning Models
The research on Loop Style Learning Models refers back to (Argyris and Schön, 1978), who primarily
studied organisational learning processes and developed several loop learning models, shown in figure 1,
namely Single-Loop-Learning (SLL), Double-Loop-Learning (DLL), and Triple Loop Learning (TLL).
Applications of these learning models are also relevant for higher education processes and can be applied to
our framework.
Figure 1. Association of the different Loop Learning Methods with increasing
reflection and learning impact process per (Argyris and Schön, 1978)
SLL refers to solving a specific problem and is usually the primary tool for building necessary problem-
solving skills in the first phases of higher education programs (e.g., by solving exercises). It represents a
simple control loop that provides a stimulus and a response which generates a positive effect when the right
solution is found. Learning also occurs when mistakes are identified on a repetitive execution of this loop
("trial and error"). Formerly, students were asked to find solutions on problems that are posed by the
professors and thus finding the right solution is the standard mode for most students. This type of learning
remains on the level of solving a specific problem and does not challenge the underlying assumptions or
norms. However, developing critical thinking skills ("asking why" attitude) is one of the core features of a
higher education program and reflected in DLL, which requires students to solve problems, question
underlying norms, and identify root causes. Students often struggle when transitioning from SLL to DLL
because the latter requires solving more complex scientific tasks. Support methodologies, like ALL, can
assist students with this transition.
The optimal learning methodology in higher education is Triple Loop Learning (TLL), which can be
described as transformational learning. TLL trains students to take the underlying context into account and
enables them to derive universal patterns that are valid independently of the specific application context
leading to a transformational change in the learner.
Actions Results
Assump-
tions
Context
(TLL) Triple Loop Learning
transformational l earning
(DLL) Double Loop Learning
challenging underly ing norms (SLL) Single Loop Learning
solving speci!c problems
2.2. The Agile Learning Loop (ALL) Process
The general SCRUM process is illustrated in figure 2 below. It already includes some slight adaptations to
the ALL methodology. The iterative nature of the process is organised into so-called sprints, each of which
addresses a part of the possible product features. Sprints have a typical duration of about 2-3 weeks and
reflect the stakeholders' project plan and development team's timeline of task sequence and completion.
When planing the project, tasks are divided into subtasks, organised via the Product Backlog, and assigned a
sprint phase based on relevance and complexity. The Sprint Backlog contains all planned activities for each
consecutive sprint. During a sprint, the development team holds brief daily meetings to plan the day's work
(Daily Scrum) and identify problems (impediments) that may affect the timely completion of tasks. The latter
is usually depicted in Kanban-style planning boards and progress charts. This process helps coordinate the
team and provides transparency among all stakeholders. Upon completion of a sprint, the team evaluates the
results and reflects on the lessons learned (a process called 'retrospective'). Then the cycle starts again.
Retrospectives provide an opportunity to evaluate the development process, the (current) product features,
and the productivity of the involved team members. Moreover, they enable the team to improve the
mentioned aspects by identifying and removing impediments from the process.
The ALL framework adopts most SCRUM concepts and integrates them into the context of a learning
framework. The product backlog can be adopted in a very similar way: the artefact of a product backlog
helps the learner organise and document the project tasks and determine the tasks' level of usefulness
(relevance) and difficulty in the planning phase. For the lecturer, this opens up another op portunity for
coaching and to give guidance on product backlog items. In contrast to other learning frameworks, the tasks'
detailed documentation makes the process much more transparent and specific for all stakeholders (student,
supervisors, and eventually peers).
Figure 2. Illustration of a Sprint within a SCRUM process with some adaptions to the ALL methodology
The user stories (the term used for functional requirement in SCRUM) in the backlog describe the
specific learning outcomes from the learners' perspective. The task of articulating their learning outcomes
represents the students' first step towards grasping the complexity of the problem; simultaneously, this
provides a coaching possibility for the lecturer.
Students complete the planned tasks during a sprint and reflect daily on their progress in their learners'
diary. This effort, which is usually executed by the development team, might initially appear redundant;
however, it serves two purposes in ALL methodology. (1) It encourages students to reflect on achievements
and upcoming tasks. When articulated in this way, project problems and overall progress become explicit
(e.g., adding problems to the impediment log) and can more easily be discussed with the lecturer.
Furthermore, (2) it helps students plan a clear daily timeline for their tasks. This is important, as daily
timelines help students stay on task when completing complex projects (such as a thesis).
After a sprint, students and lecturers hold a sprint review. They reflect on the perfor mance of the last
sprint, evaluate their progress in the sprint backlog and the impediment list. This re trospective phase is a
prime opportunity for coaching, as it highlights deficits and unresolved questions. Moreover, it helps
improve student performance on the next iteration (sprint). Without the backlog and impediment list,
effective coaching poses a challenge because lecturers are not involved in the sprint execution. Without
ALL, the situation lacks the transparency required for thorough analysis. In contrast, with ALL methodology,
progress is much more visible due to the framework structure. With every iteration, it becomes easier to have
an open reflection because the benefit becomes more obvious for the students. This also helps improve the
Sprint
2-3 weeks
Daily
Scrum
Students
Learners
Diary
Product
Backlog
Planning Review
Impediment List
Sprint
Backlog
relationship between the students and their lecturer, as students recognise that the lecturer is supporting rather
than judging their work's quality and progress. Well-executed retrospectives improve team performance and
create trust among the group (Paasivaara et al., 2013), (McHugh, Conboy and Lang, 2012).
An important aspect for the retrospective is a proper "Definition of Done" (DoD) within the ALL
methodology. It is a good way of discussing an outcome in terms of its relation to scientific work (rigour and
relevance). Moreover, it is much more useful from a didactic point of view because discussing important
aspects of scientific work is not abstract for students when it is closely related to their specific project or task.
This makes for a good learning opportunity. Table 3 summarises and compares the most relevant process
artefacts in SCRUM and ALL.
Table 3. Comparison of the most important process artefacts in SCRUM and ALL
Artefact SCRUM Methodology ALL Methodology
Product Backlog Planned product features Planned project activities
Sprint Backlog Features developed in the current sprint Activities tackled in the current sprint
Impediment List List of project impediments for the team List of project impediments for the
student
Daily Scrum Daily team meeting for coordination Individual reflection of the student on
progress
Learners' Diary (n/a) Brief documentation of Daily Scrum
outcomes
2.3 Roles in the ALL Methodology
Multiple roles must be assigned to implement SCRUM effectively, execute the overall process, and meet
specific sub-tasks and associated goals. While one role focuses on the capability to react to unprecedented
changes and unexpected challenges, another focuses on the proper application of SCRUM methodology.
SCRUM methodology is designed to be implemented without any changes or adaptations. However, in the
context of ALL methodology, some adaptations or interpretations are necessary.
The primary roles in SCRUM include the Scrum Master (SM), the Product Owner (PO), and the
Development Team (DEV). Table 4 provides a brief definition of these roles in SCRUM and ALL
methodologies.
Table 4. Comparison of the most important process aspects in SCRUM and ALL
Role SCRUM Methodology ALL Methodology
SCRUM Master
(SM)
A facilitator for the process that
supports the SCRUM process and
removes impediments for the team
A supervisor (lecturer) who guides
students in the agile process and sprints to
help them achieve their planned outcomes
Product Owner
(PO)
The stakeholder that is responsible for
the quality and functional requirements
of the final product and an expert in the
domain that the product is designed for
A 'shared role' between student and
supervisor (lecturer) with both being
accountable for different aspects of the
final result
Development Team
(DEV)
A group of developers that carries out
the product development tasks in an
iterative and agile development process
The role of the lead student. Potentially,
peers may be involved at given moments;
however, this role is not designed to be
carried out by a team.
In a higher education context, students assume two roles: the role of the product owner and the role of the
developer1. This is because the student is responsible for im plementing the project as well as for the final
result. For this reason, the DEV role is usually not designed as a team role in ALL methodology. Instead, it
is a role to be carried out by a single student who may be supported in this role through collaboration by
peers involved in the project or the project review.
1 We are using the role definition ‘developer’ here as it is defined that way in SCRUM. However, ALL is
not restricted to software developing projects, thus the developer-role can be understood as the role the
builder or creator of the various project artefacts.
In contrast, the lecturer (supervisor) primarily assumes the role of Scrum Master (SM), who is responsible
for supporting the overall process and serves as a liaison for other main stakeholders involved (e.g., an
external project sponsor). When applying ALL methodology, the SM's role is not limited to ensuring the
application of the methodology. Here, the role of SM also includes counselling and coaching students in the
field of scientific work. Moreover, the lecturer defines some of the formal requirements (e.g., scientific
rigour). Therefore, the PO's role is shared to some extent. In SCRUM, this could pose a potential source of
conflict as roles are usually not split in this methodology. However, when applying ALL, the shared role
allocation can serve as a specific coaching opportunity to improve the project result.
2.4 Activities and Artifacts in the ALL Process
Some activities and artefacts are central to SCRUM methodology and are used to support teams in executing
their development processes in an agile and efficient way. In order to integrate SCRUM activities and
artefacts with the ALL methodology for application in higher education, some important aspects need to be
adapted to suit the new context. Table 5 articulates the changes necessary.
Table 5. Adaptation of typical SCRUM activities & artefacts to the ALL Methodology
Artefact Description in SCRUM Adaptation for use in ALL
Product Increment The development progress between
different sprints
Used to measure the progress in the
project (reflection on learnings)
Velocity The amount of functional
requirements implemented in
comparison to previous sprints,
measured with Story Points;
represents the development speed of
the team over time
Only useful if stories are equipped with
story points, and the estimations are
correct; as the DEV is a person and the
project objective often of exploratory
nature, velocity will vary significantly,
and estimations may be more or less
correct
Story Point Estimation A measurement to express the
usefulness and the complexity of a
functional requirement described in a
user story
Used to quantify the complexity of the
tasks in the planning and the retrospective
phases; the supervisor could provide a
usefulness estimation
Definition of Done An agreement among the team on
the properties that an implementation
of a functional requirement must
meet to be considered complete
In an academic context, a project-specific
definition of rigour and relevance may be
a variable used to define the outcomes that
must be achieved in order for a task to be
considered done
Code Review Quality assessment of the resulting
code via peer review of individual
segments
As the DEV is not a team effort, this
aspect is of little importance for ALL;
might be used for specific feedbacks
Burndown Chart A chart listing the number of open
tasks in the backlogs over time,
presenting a graphic depiction of the
development speed
Could be used in later stages of ALL with
projects involving a large number of
stories and when story points are used
Kanban-Board A table listing the different activities
in a given sprint, reflecting their
current status; a primary method
used to coordinate DEV
Used to facilitate reflection and coaching;
serves to make the student-centric process
(more) transparent and to provide coach-
ing opportunities for the supervisor.
Backlog Grooming The process of reviewing the
backlogs for functional requirements
that are no longer relevant and can
be removed; carried out by the PO
Used as a part of the retrospective;
enables the supervisor to evaluate and
help to adjust the project focus
Story Writing
Workshop
An activity to formalise the
definition of work done in the
project; usually a team effort at the
commencement of the project or
sprint
Used to help students set up their project
and get started (assist in overcoming
potential writers' block)
User Story A description in layman's terms of Used to define project tasks and
the functional requirements so that
these can be understood by the
domain expert (PO) as well as the
team (DEV)
outcomes; can also be used to coach and
help improve individual stories
Epic An aggregation of different user
stories that have a close relation to
each other or represent a more
abstract description that is not (yet)
specific enough to be implemented
Used for pre-structured individual
projects, such as a final thesis, to provide
an initial and abstract structure for the
components that should be part of the
final product
3 APPLICATION OF ALL METHODOLOGY
The ALL methodology has shown to be applicable across the curriculum at the author's university as many
lecturers and courses now regularly integrate PBL-oriented teaching and learning. This trend is likely to grow
even further, given the increased focus on applied learning in our education programs across all subjects and
domains.
This study proposes that the new methodology be used for two primary purposes: (1) to facilitate the
supervision of final thesis projects (both in the Bachelor's and Master's programs), in which all students are
assigned a mentor for their specific topic, and (2) to guide Individual Projects (IP) associated with a
Bachelor's program.
An IP is a course that allows students to work individually on a wide range of topics while coached by
degree program faculty. In contrast to final thesis projects, IPs are introduced at the commencement of the
program and are designed to help students (a) build a scientific skillset and (b) provide an opportunity to in
the program to “fail without failing”2. Both settings require a learning process tailored to students learning
needs and progress. Thus, the support of the lecturer needs to respond to students' individual needs and
requires an agile teaching approach.
The ALL method provides a specific framework for the required coaching processes and retains
flexibility for addressing individual needs. Figure 6 illustrates the application of ALL over the course of one
semester (roughly three months). The four cycles planned for the individual projects are designed for a
duration of approx. three weeks each.
Figure 6. Relationship between the loops within a semester cycle and the distinct types of
loop learning occuring over time
In each cycle (or loop), students resolve individual tasks within the project under faculty supervision.
Initially, loops will be primarily problem-focused and constitute SLLs. Using ALL methodology, a transition
to DLL and finally TLL will occur over the course of the project.
2 Usually, courses and assessments are designed with the requirement to reach a successful result in a first
attempt. Such an expectation tends to discourage students risk-taking. However, when students are
allowed to make and reflect on errors and mistaken initial approaches these can constitute optimal
situations for successful and sustainable learning. Thus it is important that IPs provide a space for trial
and error, reflection and assessment.
Loop
#1
M0 M1 M2 M3
Loop
#2
Loop
#3
Loop
#4
Single Loop Learning (SLL) Douple Loop
Learning (DLL) Triple Loop Learning (TLL)
4 IT-TOOLS TO SUPPORT ALL METHODOLOGY
For the implementation of ALL methodology, tools designed to support the SCRUM process can be used to
help organise and facilitate the ALL process. Commercial tools, such as JIRA3 from Atlassian, may be used
for this purpose (Li, 2018); however, the author decided to use Redmine4 (Lesyuk, 2016) with the Agile
Plugin and the Boostmine Theme5. The reason for this tool choice is two-fold. For one, Redmine is an
extensible and stable open-source software system; it is hence user-friendly and free of charge in terms of
license fees. Secondly, students in computer sciences are generally familiar with the software from other
contexts of their studies, which reduces their learning curve.
Redmine applies the concept of ticket-based activities assigned to members of the project team. The Agile
Plugin implements a Kanban-style depiction of the different tickets based on status. The tool can be easily
adapted to different needs, e.g. the activity status, the implicit workflows that result from activites status
transitions, or the definition of custom attributes. Therefore, it can be effortlessly configured to meet the
needs of ALL methodology. To configure the tool for use with ALL, two roles must be defined (Student and
Supervisor). Moreover, the status of activities should include "New-SprintBacklog", "New-ProjectBacklog",
"InProgress", "Feedback" and "Done". Figure 7 provides an interactive Kanban chart that displays the current
activities together with their current status and the corresponding assignee.
Another important aspect of ALL methodology is a way to take notes on the individual project without
adhering to a formal structure. The note-taking function is needed for two purposes: collecting random ideas
and maintaining the research diary. 'Random ideas' are notes on thoughts that might not fit into a specific
project activity or do not serve a specific purpose. Usually, they are written down in an ordinary notebook;
however, the Redmine system provides the possibility to use the included Wiki-system for a quick and low-
tech way of taking these notes.
Figure 7. Kaban Board (left) to display and manage active tasks together with their status and
Workbook for ALL (right) based on the existing Wiki-functionality in Redmine
The system's note-taking function allows students to link random ideas to other parts of the project (e.g.
activities or documents). Figure 7 shows an example of such a wiki entry. The other crucial note-taking
purpose of the project workbook is the Research Diary, which student keep to report their daily progress via a
single-line entry. This daily routine provides an opportunity for students to reflect on the time spent on the
project and the specific progress achieved. Moreover, these entries capture the project process and can be
helpful when coaching or addressing (unexpected) challenges during the project.
3 The JIRA product is described here: https://www.atlassian.com/de/software/jira/scrum-boards
4 More information on RedMine can be found here: https://www.redmine.org/
5 More on the Agile Plugin can be found here: https://www.redmineup.com/pages/plugins/agile and the
used theme is documented here: https//bestredminetheme.com/boostmine/
5 Summary
This study outlines the methodology of Agile Learning Loops (ALL), a learning design framework inspired
by the SCRUM methodology, and shows how it can be applied to PBL-oriented learning situations in higher
education settings. Through minor modification and adaptation, SCRUM features can be integrated into ALL
to help students transition between the three Loop Learning Methods, from SLL to DLL and then to TLL.
Moreover, this approach strengthens students' problem solving and critical thinking skillsets and fosters
appropriate time and task management skills. Finally, this unique integration of methodologies enables
lecturers to enhance their mentorship in PBL, gives students relevant experience in project management, and
utilises tools established and proven effective in their career field.
The respective process, activities and roles of the methodology in a Higher Education setting have been de-
scribed and the application scenario and the tooling support have been outlined. The formal evaluation of this
learning design framework will be subject to further research, but first experiences from the ongoing
application of ALL will be reported at the conference.
REFERENCES
Argyris, C. and Schön, D. A. (1978) Organizational Learning: A Theory of Action Perspective. Addison-Wesley
Publishing Company.
Chen, C.-H. and Yang, Y.-C. (2019) ‘Revisiting the effects of project-based learning on students’ academic achievement:
A meta-analysis investigating moderators’, Educational Research Review, 26, pp. 71–81. doi:
10.1016/j.edurev.2018.11.001.
Kolb, D. A. (2014) Experiential Learning: Experience as the Source of Learning and Development. FT Press.
Lesyuk, A. (2016) Mastering Redmine. Packt Publishing Ltd.
Li, P. (2018) Jira Software Essentials: Plan, track, and release great applications with Jira Software, 2nd Edition. Packt
Publishing Ltd.
McHugh, O., Conboy, K. and Lang, M. (2012) ‘Agile Practices: The Impact on Trust in Software Project Teams’, IEEE
Software, 29(3), pp. 71–76. doi: 10.1109/MS.2011.118.
Royle, K. and Nikolic, J. (2016) ‘A modern mixture, agency, capability, technology and “scrum”: agile work practices for
learning and teaching in schools’, 3. doi: 10.30845/jesp.
Paasivaara, M. et al. (2013) ‘Teaching students global software engineering skills using distributed Scrum’, in 2013 35th
International Conference on Software Engineering (ICSE). 2013 35th International Conference on Software
Engineering (ICSE), pp. 1128–1137. doi: 10.1109/ICSE.2013.6606664.Schwaber, K. (2007) The Enterprise and
Scrum. Microsoft Press.
Srivastava, A., Bhardwaj, S. and Saraswat, S. (2017) ‘SCRUM model for agile methodology’, in 2017 International
Conference on Computing, Communication and Automation (ICCCA). 2017 International Conference on Computing,
Communication and Automation (ICCCA), pp. 864–869. doi: 10.1109/CCAA.2017.8229928.
Supangat, S. et al. (2019) ‘E-Learning Development as Interactive System with Scrum Methodology’, in. 2nd
International Conference on Vocational Innovation and Applied Sciences 2019, Wyndham Hotel, Surabaya.
Available at: http://icvias.com/ (Accessed: 24 October 2020).
Vogelzang, J., Admiraal, W. F. and Driel, J. H. van (2019) ‘Scrum Methodology as an Effective Scaffold to Promote
Students’ Learning and Motivation in Context-based Secondary Chemistry Education’, Eurasia Journal of
Mathematics, Science and Technology Education, 15(12), p. em1783. doi: 10.29333/ejmste/109941.
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
Context-based approaches aim at increasing students' learning and motivation. However, students perceive its complexity often as overwhelming, causing frustration and disengagement. Thus, there is a need for innovative teaching methods to scaffold students in context-based education. Two perspectives are used to argue that Scrum methodology, a project management framework, is a promising candidate. First, its features are described and subsequently connected to six well-known scaffolds from the motivational literature. This exploration showed that implementation of Scrum methodology might lead to improvements of students' motivation and an increase in cognitive and metacognitive learning achievements. Secondly, an empirical pilot study was conducted. Three experienced chemistry teachers implemented Scrum methodology in their chemistry lessons. Interviews revealed that Scrum methodology visualized students' learning process and progress. Two teachers reported stable and even better learning outcomes. In addition, they perceived that their students showed increased engagement. However, one of the participating teachers reported student resistance towards parts of the Scrum methodology as well as organizational issues. This teacher emphasized that Scrum methodology is in itself rather complex and that implementation is not an easy job. Although the pilot study suggests that caution is urged, its implementation might give new momentum to reinforce context-based approaches.
Article
Full-text available
This paper introduces a pedagogical method derived from agile work practices, particularly the scrum method of project based working. It will discuss how this agile method can be aligned with teaching and learning in formal schooling and project based learning developing an agile pedagogical approach which can lead to: greater agency for both learners and teachers; the purposeful integration of digital tools into practice; and the development of human capability and functioning through a change in learning design. It goes further in conceptualizing the teaching-learning dynamic as a " technology for learning " in so far as technology is definable as a purposeful process of knowledge creation.
Conference Paper
Full-text available
In this paper we describe distributed Scrum augmented with best practices in global software engineering (GSE) as an important paradigm for teaching critical competencies in GSE. We report on a globally distributed project course between the University of Victoria, Canada and Aalto University, Finland. The project-driven course involved 16 students in Canada and 9 students in Finland, divided into three cross-site Scrum teams working on a single large project. To assess learning of GSE competencies we employed a mixed-method approach including 13 post-course interviews, pre-, post-course and iteration questionnaires, observations, recordings of Daily Scrums as well as collection of project asynchronous communication data. Our analysis indicates that the Scrum method, along with supporting collaboration practices and tools, supports the learning of important GSE competencies, such as distributed communication and teamwork, building and maintaining trust, using appropriate collaboration tools, and inter-cultural collaboration.
Article
Full-text available
Agile software development involves self-managing teams that are empowered and responsible for meeting project goals in whatever way they deem suitable. Management are required to place more trust in such teams than under a more traditional development methodology. This paper highlights how the use of agile practices can enhance trust amongst agile team members. It also presents challenges that agile teams may now face as a result of using agile practices, which are based on the findings from three case studies of agile software development teams.
Article
Project-based learning is generally considered an alternative to traditional, teacher-led instruction. However, there is a noticeable lack of meta-analyses with regard to determining its overall effects on students’ academic achievement, and what study features may moderate the impacts of project-based learning. This study thus performed a meta-analysis to synthesize existing research that compared the effects of project-based learning and those of traditional instruction on student academic achievement. Forty-six effect sizes (comparisons) extracted from 30 eligible journal articles published from 1998 to 2017 were analyzed, representing 12,585 students from 189 schools in nine countries. The results showed that the overall mean weighted effect size (d+) was 0.71, indicating that project-based learning has a medium to large positive effect on students’ academic achievement compared with traditional instruction. In addition, the mean effect size was affected by subject area, school location, hours of instruction, and information technology support, but not by educational stage and small group size.
Article
The abstract for this document is available on CSA Illumina.To view the Abstract, click the Abstract button above the document title.
E-Learning Development as Interactive System with Scrum Methodology
  • S Supangat
Supangat, S. et al. (2019) 'E-Learning Development as Interactive System with Scrum Methodology', in. 2nd International Conference on Vocational Innovation and Applied Sciences 2019, Wyndham Hotel, Surabaya. Available at: http://icvias.com/ (Accessed: 24 October 2020).