• No results found

Teaching Scrum - What We Did, What We Will Do and What Impedes Us

N/A
N/A
Protected

Academic year: 2021

Share "Teaching Scrum - What We Did, What We Will Do and What Impedes Us"

Copied!
2
0
0

Loading.... (view fulltext now)

Full text

(1)

Teaching Scrum – What We Did, What We Will

Do and What Impedes Us

Emil Al´egroth, H˚akan Burden, Morgan Ericsson, Imed Hammouda, Eric Knauss, and Jan-Philipp Stegh¨ofer

Software Engineering Division

Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg

{Emil.Al´egroth,H˚akan.Burden,Morgan.Ericsson.Imed.Hammouda,

Eric.Knauss,Jan-Philipp.Stegh¨ofer}@chalmers.se

Abstract. This paper analyses the way we teach Scrum. We reflect on

our intended learning outcomes, which challenges we find in teaching Scrum and which lessons we have learned during the last four years. We also give an outlook on the way we want to introduce and apply Scrum in our teaching and how we intend to improve the curriculum.

The results aggregated in this paper are a response to a crisis: we, a group of teachers and researchers at the University of Gothenburg (GU) and Chalmers Technical University have realized that the way we teach Scrum doesn’t align with the intended learning outcomes of our courses. These often include process knowledge, technical knowledge, and methodological knowledge. The intended outcome in the process area is the ability to apply the process and the agile prin-ciples in future development projects. We feel that the courses become unmain-tainable for us and put a lot of cognitive load on our students who learn Scrum in lectures and apply it in projects in parallel. While applying Scrum is key to understand it, the projects’ deliverables and technical aspects tend to shadow teaching goals and reflection on agile principles and practices. This causes stu-dents to feel like the process is “overhead” instead of being a possibility to struc-ture their work. Since we as teachers are necessarily mainly concerned about the outcome of the project and mainly interact with the students when they present deliverables, we also have very little opportunity to observe the application of the process and give direct feedback on it.

The Software Engineering division is a joint venture between GU and Chalmers. Apart from courses in different programmes at both universities, it offers a Bache-lor in Software Engineering and Management and a Master in Software Engineer-ing. Both programmes emphasise project-based learning and thus allow students to experience work in group settings with complex case studies and fixed deadlines. A number of these courses either include agile practices in their learning objectives or make use of them for the project work.

As teachers at the Software Engineering division we are responsible for teach-ing Scrum in four courses in three contexts – Software Processes (first term) and Software Architecture Project (third term) in the Software Engineering and

c

 Springer International Publishing Switzerland 2015

C. Lassenius et al. (Eds.): XP 2015, LNBIP 212, pp. 361–362, 2015. DOI: 10.1007/978-3-319-18612-2

(2)

362 E. Al´egroth et al.

Management bachelor program; Software Engineering Project (second term) for various engineering and IT programs as well as Agile Software Development in the Software Engineering master program. The project courses in the bachelor program and the course in the master program have a focus on technical knowl-edge whereas the Software Processes course focuses on theoretical knowlknowl-edge.

By sharing our experiences and our lessons learnt we hope to allow trainers and teachers elsewhere to benefit from our experience and to balance the cogni-tive load and to start the same alignment process in education and training of agile software development that has now begun for us.

To get an overview of how we teach and apply Scrum in our courses we collec-tively reflected on our experiences and, applying the terminology of Brookfield, evaluated our practices using a peer lens [1]. Following Sch¨on the reflection was

on-action [2] since our teaching is spread out over the academic year and the

course curricula are set for each course instance. This process led us to a number of insights and best practices that we want to apply in our future teaching. Two examples are:

1. Teaching Scrum needs to have a practical element: Scrum must be applied to know it. However, the more technically advanced the practical element is, the more the students focus on learning the platform instead of the process. The platform becomes an impediment for learning Scrum.

2. Stress is an impediment for learning Scrum since the students focus on delivering before the deadline instead of using a sound process. In a workshop setting the stress creates learning opportunities since the close interaction with the teachers enables immediate and detailed feedback. This resonates with what Babb et al. report from industry where the need to meet deadlines had a negative impact on the Scrum teams possibility for reflection-in action during the sprint retrospectives [3].

Our suggestion is to introduce Scrum using workshops and a platform with low technical demands. When students have been introduced to Scrum they can apply the knowledge in a project with a more technical setting, thereby balancing the cognitive load among the process aspects and technical aspects of the project. We have adapted our curriculum accordingly and now offer a Scrum workshop using Lego building blocks as part of the different courses to allow students of all semesters to experience Scrum this way. In the future, every student in the first term will participate in such an exercise and therefore be prepared for the use of Scrum in the second term Software Engineering project.

References

1. Brookfield, S.: Becoming a Critically Reflective Teacher. Higher and Adult Educa-tion Series. Wiley (1995)

2. Sch¨on, D.A.: The Reflective Practitioner: How Professionals Think in Action. Harper torchbooks. Basic Books (1983)

3. Babb, J., Hoda, R., Nørbjerg, J.: Barriers to Learning in Agile Software Devel-opment Projects. In Baumeister, H., Weber, B., eds.: Agile Processes in Software Engineering and Extreme Programming. Volume 149 of Lecture Notes in Business Information Processing., Springer Berlin Heidelberg (2013) 1–15

References

Related documents

Through the performed discourse analysis, four key elements of a company’s internal processes were identified to constitute an attractive employer image according to

Although consciousness has been studied since the beginning of the history of psychology, how the brain implements consciousness is seen as one of the last great mysteries. This

Torbjörn Becker, Director at SITE, and followed by a short discussion by Giancarlo Spagnolo, SITE Research Fellow and Professor, University of Rome II. Time will be available

The work with more focus on outdoor recreation monitoring and management activities in coastal and marine areas is not only an uphill process. In fact, the process can

Books, articles and essays con- cerning pottery in museums generally revolve around what the collections look like, what we can learn from them or what kind of pottery

This study has addressed this knowledge gap by investigating the impact of the rationalization processes—with a focus on the rise of professional management (managerialism) and

Genom att vara transparent och föra fram för allmänheten hur organisationen arbetar kring CSR kan företag enligt författarna bidra till att påverka

Number of cycle journeys times the length of journey = total distance cycled (cycle TA).. Is cycle