Agile Management: A Teaching Model Based on SCRUM

Ž. Požgaj*, N. Vlahović* & V. Bosilj-Vukšić*

* Ekonomski fakultet Zagreb, Trg. J. F. Kennedyja 6, Zagreb, Croatia zpozgaj@efzg.hr; nvlahovic@efzg.hr; vbosilj@efzg.hr

Abstract – Work presented in this paper is based on the notion of creating a teaching model based on the principles of agile management. Developed and described model is based on Scrum, one of the most widespread agile methods. Since Scrum is primarily a framework for managing software projects and software applications development, during the development of the model it was crucial to negotiate the differences between Scrum and the teaching process itself. Teaching model in this paper covers the whole teaching process from first lessons to the final exam. Model consists of three separate units: (1) presentation of theoretical knowledge; (2) practical knowledge and student projects; (3) exams and admission of grades. Each of these units represents a Scrum that results with particular „products“. Basic characteristics of Scrum like incremental development, iterations, roles and artefacts are implemented in the teaching model using the same principles as in the original Scrum even though their content is adjusted to the specifics of the teaching process. Model is implemented in the Managerial Informatics master study course “Business Application Development” at the Faculty of Economics and Business University of Zagreb.

I. INTRODUCTION

One of the topics within the curriculum of the course Business Application Development (cro. Razvoj Poslovnih Aplikacija) is “Agile software development methods“. In order to familiarise students with knowledge and skills within this topic more closely, we intended to organise the teaching process according to principles of agile management. The selected method was Scrum. Scrum represents a framework for software product development. Final goal of Scrum project is to create a product that complies with intended requirements. Teaching process aspires to reach the same goal as a Scrum project. Project, in this case, pertains to the organisation and conduct of the teaching process in current academic year according to requirements defined in the curriculum of the course, with the final goal –successfully complete teaching year. Analysis of teaching process in described manner has shown that teaching process can be compared and affiliated with any other process, even with software development process. Scrum is a typical software product development method.Characteristics of the method are described in detail in this paper through the presentation of the proposed teaching model. Teaching model is achieved through three separate Scrums; each Scrum containing three phases. Teaching process is developed in the same way as software product using all the stages of the software process life-cycle,

where different roles are assigned to different actors, specific artefacts are used, respective activities and iterations. From presenting theoretical knowledge in the first Scrum, through presentation of practical knowledge and skills during the development of student projects in the second Scrum, until the finalisation of the teaching process with the student exams in the third Scrum. Students work on their projects in accordance to agile work organisation (including teamwork, pair-programming, presenting features as stories, weekly meetings, etc.)

Review of current literature indicates several attempts of implementation of Scrum in the teaching process. In most of the available cases Scrum is implemented only in the segment of the teaching process concerned with the organisation of student projects. As expected, courses where Scrum is used in this way usually cover the topic of software engineering [10]; [5] even though there are a few examples of using Scrum in courses dealing with other topics [4]; [1 ]; [6].

The rest of the paper is organised in five separate chapters. After the introduction, in chapter 2, Scrum methodology is introduced with descriptions of its basic characteristics. Chapter 3 is the central part of the paper where developed teaching model based on Scrum is described in detail. Chapter 4 indicates possible improvements of the organisation of the teaching process. Finally, Chapter 5 summarizes the key points in the conclusions.

II. SCRUM METHODOLOGY

The emergence of novel, so-called lightweight agile software development methods, evolved in the mid-1990s. The main characteristics of agile software development methods are iterative and incremental development, agility, flexibility in requirement definition, collaboration, self-organizing teams etc. Creators of these methods join the Agile Movement that publishes Agile Manifesto in 2001. Agile Manifesto details the philosophy and principles behind agile methods [8]; [9].

In 1995 Ken Schwaber and Jeff Sutherland present astudy where they describe a new software development method and call it Scrum. The term scrum is derived from rugby, where a scrum restarts the game after the ball has gone out of play. Applying the interpretation of the term scrum to software projects, a software scrum gets the team

MIPRO 2014, 26-30 May 2014, Opatija, Croatia

893

back together and gets everyone moving in the appropriate direction [1].

For Schwaber and Sutherland [7] Scrum is a process framework that has been used to manage complex product development. It is not a process or technique for building products; rather, it is a framework within which one can employ various processes and techniques. Speaking in terms of agile management, Cervone describes Scrum as an agile, lightweight process for managing and controlling software and product development predicated on a team-based approach [2]. It consists of three groups of phases: Pregame, Game (or Development) and Postgame (Fig. 1.).

Detailed description of activities and artefacts in each phase of Scrum is given in the rest of the paper.

According to 7th Annual State of Agile Development Survey for 2011. 54% software developers use Scrum.Scrum together with Scrum variants methodologies is used by 72% of software developers which makes Scrum the most popular agile methodologies being used [12].

III. TEACHING MODEL

Teaching is a process, teaching process is a project. Every project, including teaching projects, has its own respective goal (for teaching projects, according to the curriculum, the goal is to provide students with particular knowledge and enable them to master particular skills), its starting point and its ending point (during the semester). Complex projects, such as teaching project, require teamwork, mutual collaboration and cooperation. This can be seen through the relationship of teachers and students.

Following the ideas of agile approach to project development, Scrum methodology was used for the creation of the teaching model for the Business Application Development course.

Due to undeniable differences between teaching process and software process Scrum methodology had to be adjusted accordingly. First of all, every Scrum represents a complete wholesome processing unit that results with a particular product. This methodology is to be used to cover the complete teaching process of the

course, from the introductory lectures until the final exam and admission of the grades. Three separate integral units were detected: (1) presentation of theoretical knowledge;(2) mastering practical skills through student projects; (3) exam and admission of grades. Each of these units represents a separate Scrum process and each of these deliver a specific outcome - product or several products. Consequently, teaching model for the Business Application Development course consists of three Scrums, or three Scrum units.

A. About the course Course Business application development is an

elective course in Managerial Informatics master study at the Faculty of Economics and Business University of Zagreb. This elective course consists of 20 hours of teaching (10 hours of lectures and 10 hours of practical work in computer lab). During the course students use software tools for UML diagrams, eDraw UML Diagram, and programming language Visual Basic, Visual Basic 2010 Express Edition. Workload of the course is expressed using European Credit Transfer and Accumulation System (ECTS) and the course is worth 4 ECTS credits. As we can see the number of course hours is relatively small and the number of ECTS credits is quite substantial, students are expected to work in teams outside the supervised part of the teaching process. Therefore students have additional time reserved for their independent teamwork in the computer lab, and they can choose from three different two-hour periods during the week. Teaching is provided by two lecturers, one for thetheoretical topics and the other one for the practical part of the course. In the academic year 2013/2014, 33 students chose this elective course. They were allowed to organise themselves into working teams and, as a team, negotiate and define their project assignment topics.

B. Roles, sprints and artefacts in the model Basic roles in the teaching model are Scrum Master

and Scrum Team [7]. Teacher takes on the role of the Scrum Master. Scrum Master is the person responsible for the entire Scrum process and in this case Scrum Master is responsible for the realisation of the complete teaching

Figure 1. The Scrum phases [3]

894

process. This is why the role of Scrum Master includes the organisation of lectures and exercises, student consultations, advising students during project assignment topic selection, monitoring student progress and providing additional help during the development stages of student project assignments, grading of completed projects assignments, preparation and conduct of examinations, admission of grades, and so on. Role of Scrum Team is assigned to each student team. Students form teams by themselves and together as a team define project assignment topic. They delegate particular tasks among themselves during the development of the project, they communicate and consult with the Scrum Master, they observer the deadlines, write project documentation and present the project work when done. Role Product Owner is assigned to the team leader. Since student teams for the course Business Application Development consists of only two member, this role is not intended in this particular teaching model. In teaching processes where this role exists, Product Owner coordinates teamwork, takes care about the details pertaining to the project development progress and communicates with the Scrum Master. Product Owner represents the middleman between team members and Scrum Master. Soria et al. [10]recommend introduction of the additional role of Agile Coach in situations where students develop projects. According to [10] the Agile Coach encourages the teams throughout the Scrum process by cleaning the team's obstacles and emphasizing the use of tools. Designated Agile Coach represents the middleman between team members and Scrum Master and this role would be appointed to the lecturer that delivers the practical part of the course topics and exercises conducted in the computer.

Sprint represents a set of activities that are sequentially executed during each iteration of the development phase. In the teaching model, types of activities that will form each sprint are directly dependent on the Scrum unit the sprint cycle belongs to. For example, in the first Scrum unit activities within the sprints pertain to elaboration of theoretical knowledge about the topics of the course. In the second Scrum unit activities within the sprints follow the stages of the life cycle of the software product development.

Artefacts of the teaching model are specifically related by their content to the Scrum unit within which they are used. For example, in the first Scrum unit Product Backlog list, and later on Sprint Backlog list also, relate to requirements defined by the process of studying the theoretical knowledge about the topics of the course,while in the second Scrum unit both Product Backlog and Sprint Backlog lists relate to requirements defined by the project assignment topics i.e. particular software product being developed by the team. Project Topic Registration is also an artefact that is submitted by the student teams to the Scrum Master and it is only used in the Postgame phase of the first Scrum unit.

C. First Scrum – Theoretical introduction Pregame phase contains activities that will enable

students to participate in the upcoming Scrum units of the teaching model while successfully accomplishing and meeting the requirements that are continually requested

from students during the teaching process. Activities defined for the first Scrum unit are providing students with the information about the course, presentation of theoretical knowledge about the topics of the course and preparation of students for the upcoming phases of the process. Key artefacts of this phase are Planning, Product Backlog list, Environment Architecture. Activities associated with the mentioned artefacts are performed by the Scrum Master. Artefact Planning involves creation of the teaching process agenda (possible innovations in the selection of the course topics in relation to the existing curriculum, determining scope of lectures for each topic by dates, planning the dates of midterm test and examination tests, defining methods of examination, determining primary and additional literature, determining dates for computer lab exercises, selection of software tools that will be used, and so on…) Product Backlog list contains features important for lecturer and students. So Product Backlog list contains each topic title, each weekly date for each lecture and corresponding topic that the lecturer will present, dates for the exam tests, instructions for the submission of student project assignment topics, deadlines for each activity, and similar information. Environment Architecture defines the required presentation equipment, lecture room features, computer equipment and corresponding software that is required during computer lab exercises and project development.

Game phase in the proposed teaching model spans over five weeks and in this period the teacher presents all of the theoretical knowledge topics as defined in the curriculum of the course. Product Backlog list is the basis for the creation of the Sprint Backlog list. Sprint Backlog contains a list of tasks to be completed during the Sprint. This is an ordered list of topics that the lecturer needs to present and they follow the stages of the software product life cycle. As topics are presented students gain required knowledge to be able to come up with project assignment topic for their own software product prototype during the second Scrum unit. List of basic and fundamental topics is enriched with topics such as software project management, software product quality metrics, and so on… List of tasks in Sprint Backlog that are to be completed by the students includes forming of project teams, completion of the Project Topic Submission forms, and similar activities.

Central part of this phase is dedicated to Sprints, i. e. incremental approach to completion of the tasks given in the Sprint Backlog list during separate iterations. Since the final number of hours of lectures for this course is ten, and there are two hours of lectures per week, model presumes five Sprints (5 x 2 hours). Each Sprint deals with one lecture. With the end of each Sprint, teaching processadvances its progress in accomplishing the goals given in the Sprint Backlog list. Each lecture starts with the weekly „meeting“. The meeting agenda includes revision of topics presented on the previous weekly meeting, introducing students with the basic characteristics of the topic (or several topics) that will be presented during lectures and, finally, students get assignments for activities they should perform until the next weekly meeting (familiarise themselves with the content of a particular paper, retrieve particular information using Internet and similar…). Fifth

895

Sprint is different from the previous four since the location of the lecture is not in the lecture room but in the computer lab. Topic of this print is the modelling of business processes so the theoretical foundations are complemented with the drawing of particular UML diagrams using appropriate software tools.

After all of the items from the Sprint Backlog list are achieved, final phase of the Scrum unit begins – Postgame phase. For the lecturer this means that all of the required topics have been presented to the students. For the students that means that project teams are created, project topics determined and Project topic registration forms completed and submitted to the Scrum Master.

D. Second Scrum – Practical skills Second Scrum unit of the teaching model is the most

similar to typical Scrum that is originally defined as agile software development method. Since during second Scrum unit students develop their own software applications, Scrum is used as a framework for managing software applications development. Students develop their applications using Microsoft Visual Basic 2010 Express edition. Exercises are performed exclusively in the computer lab. Even though the primary part of this Scrum unit is dedicated to the development of software applications, basic information about programming in Visual Basic as well as the tutorial for the usage of the Integrated Development Environment is also covered. This is why in the Game phase during first three Sprints students are provided with necessary theoretical information after which exercises are performed using typical problem assignments that are similar to requirements in their project topics. Final two Sprints are dedicated to project work and the development of the software applications themselves.

In the beginning of the Pregame phase activity plan of the second Scrum unit is created. Product Backlog list is updated with the agenda of the practical part of the lectures. During planning Scrum Master is involved with defining the dynamics of presentation of programming basics by the topics and particular dates, defining practical examples of case studies related to specific lecture topics,defining required perquisite knowledge required for successful mastering of particular programing problems, defining deadlines for student projects and so on… Since in the previous Scrum unit 18 student teams submitted Project Topic Registrations, in the Product Backlog list only teams and their topics are entered in order to track basic features of student projects. This is why each Scrum Team compiles its own internal Product Backlog list. In these lists features of the software projects being developed are entered as well as corresponding requirements.

As mentioned earlier during the first Scrum unit, requirement for the particular software tools is defined as artefact in the Environment Architecture. Now, the testing of the installed computer resources is performed, and possible corrections are made if needed. When the final verification of the computer equipment is successful Game phase is ready to commence.

Game phase consists of five Sprints. After first three Sprints students were able to master the basics of programming and acquired required skills they are ready to start with the development of their projects. Final two weeks of the semester are allocated for the development of the projects, which corresponds to the last two Sprints of the teaching model. Scrum Teams have absolute autonomy over the organisation of their work on the projects, but within the limitations set by the rules of Scrum. This means that Scrum Teams compile their Sprint Backlog lists, define activities for each Sprint, define goals of each Sprint, delegate work tasks among team members, estimate timing and deadlines for particular Sprint activities, and so on… Since the amount of lecture hours in this period is reasonably small, Scrum Teams spend additional time and effort doing teamwork outside Sprint teaching model. This is why weekly meeting have pronounced importance during these two Sprints, since Scrum Teams report their progress from the previous week to Scrum Master. They report of what has been achieved in the previous period but also activities that they have planned for the next Sprint. This allows Scrum Master to follow the dynamics of the project development for each Scrum Team, giving them appropriate advice for the next Sprint, and so on… Each Scrum Team develops their project according to requirements given in the Sprint Backlog list, consequentially through the activities of each Sprint (Analysis, Design, Evolution, Testing, Delivery), iteratively using adequate number of Sprints and incrementally until all of the requirements are reached and the final version of the software product is developed.

Organisation of the work done during student projects is aligned with the recommendations of agile development of software products [9] and Extreme Programming (XP) [8]. Some of these recommendations include pair-programming and pair- process modelling using driver-navigator approach [11], writing stories (describing features and requirements) within the Product Backlog list and weekly meetings.

In the Postgame phase Scrum Teams continue their work by creating and compiling project documentation. Project documentation contains detailed description and disposition of the project assignment topic, UML diagrams (namely, decomposition diagram, use-case diagram at the system level, activity diagram and sequence diagram for a particular segment of the software product that was developed as a prototype), description of basic functionalities and characteristics of the software application, description of user interface, source code, course of testing activities, and final conclusions. Integral part of the project documentation that Scrum Teams attach to the documentation itself is the software product in both source code and executable form. All of these are submitted to the Scrum Master.

E. Third Scrum – Examination Third Scrum represents the finale of the complete

teaching process. By this Scrum everything that was set out by the curriculum of the Business Application Development course is completed. All of the topics given in the curriculum are presented, practical part of the course in the computer lab has been completed as well,

896

Scrum Teams have developed their software applications along with the appropriate project documentation and they have submitted the resulting work (project documentation and software applications) to Scrum Master. The last thing that remains in the teaching process to complete the course is the organisation and realisation of the examination. Third Scrum is concerned with examination on a particular date that is carried out as one complete unit. Final product of this Scrum for the Scrum Master is the conclusion of the exam date (project assignments are graded, exam is conducted, grades are registered) and for the students, grades are admitted in their indexes while the course Business Application Development has been successfully passed.

Pregame phase

In the Product Backlog list main properties for the examinations are registered: planned date of the examination, requirement that students that want to take the exam need to register for it, requirement that students need to have their index with valid entry noting that they have applied for the course in the beginning of the academic year. One of the most important artefacts that is entered in the Environment Architecture is the list of rooms that are reserved in the appropriate time when the examination is planned to take place. The method of publishing examination details is organized at the level of the Faculty and thus is not a part of the model.

Game phase

Sprint Backlog list contains the information about the exam date, including precise time and place where the exam will take place, as well as the list of students that have applied for the examination. Duties of the Scrum Master at this point are to compile exam questions and exam tests and prepare adequate number of test. Students are expected to take the test at the published date, time and place of the exam, while providing their indexes for inspection.

Since the model covers only one exam date, Game phase consists of only one Sprint cycle. Sprint lasts for a predetermined time period after which students submit the completed tests and after Scrum Master grades the written exams, students that have achieved minimum requirements and passed the test continue with the Postgame phase of the Scrum unit. Rest of the students are returned to the Pregame phase of this Scrum unit and are referred to the next exam date as it becomes available.

Postgame phase

In this phase for the students that have successfully passed the written exam Scrum Master calculates the final grade for the course where the final grade is structured as follows: 50% of the final grade is made from the grade of the written exam, 40% is contributed by the project assignment grade and the final 10% is contributed by the student activity during the course. The final grade is admitted in student index and registered in the exam list of the Faculty Information System.

IV. FURTHER IMPROVEMENTS IN COURSE ORGANISATION

The presented teaching model introduces a number of advantages and benefits for the students but it also faces a few challenges that need to be overcome and allow for improvements. Limitations of the model do not influence the structure of the teaching model but influence the suboptimal improvement of the teaching process quality. Some of the most prominent limitations are:

• Restrictive number of hours of lecture and exercises for the rich content of the course topics defined by the curriculum

• Limited background knowledge of the students that take this course that may require additional effort from the students to successfully finish their project assignments

• Relatively small number of students that creates challenges while forming student teams.

In order to improve the quality of the teaching process and resolve at least some of the limitations for the Business Application Development course an increase of the number of hours was proposed. From the current 20 hours additional 10 hours were suggested. This proposal was accepted by the Faculty bodies, so the next academic year there will be 10 hours of lectures reserved for the theoretical introduction to the course topics and 20 hours allocated for the practical part of the course that covers the development of student projects as well.

Next possible improvement pertains to the organisation of student project topics. The key idea here is that entire generation of students would develop the same complex software application and all of the Scrum Teams would make their contributions. They would still be independent self-organising and self-managing, but each Scrum Team would have 3 to 5 members. The project assignments would be given by the Scrum Master to the Scrum Team leaders. Scrum Team leaders would beassigned with the role of Product Owner according to the model described earlier in this paper, and each Product Owner would be assigned one segment of the software application that would be developed my their respective Scrum Team. The only restricting factor in this case would be the complexity of the student projects since there is limited background and prior knowledge of the students about course topics and programming. This limitation can be somewhat alleviated by the increased number of hours of practical work in the computer lab and Visual Basic.

V. CONCLUSION

Paper clearly shows how teaching process can be customised according to methodology initially planned for realization of completely different kind of processes. Scrum is chosen due to its specific advantages in comparison to other agile methodologies: (1) Scrum is presented as an integral part of the course in the topic „Agile software development methods“; (2) teaching process, as well as Scrum, is achieved through the incremental development: through presentation of theoretical knowledge, practical work and student project

897

as well as examination; (3) theoretical knowledge and practical skills are presented and thought iteratively: topic by topic; (4) student projects are organised and developed according to Scrum methodology: roles are assigned; required computer equipment is defined as a part of Environment Architecture; features of software products being developed are entered on the Product Backlog list; software requirements are defined according to Product Backlog list and the team member responsibilities are delegated through the Sprint Backlog list; software product is developed incrementally and iteratively through a number of Sprint cycles until final version is developed;(5) project documentation is created and compiled.

In this paper some of the limitations and possible improvements of the teaching model are given that could further raise the quality of the current teaching process.

LITERATURE

[1] M. Broussard: The J-School Scrum: Bringing Agile Development Into the Classroom, available at: http://www.pbs.org/mediashift/2014/01/the-j-school-scrum-bringing-agile-development-into-the-classroom/

[2] H. F. Cervone: Understanding agile project management methods using Scrum, available at: www.emeraldinsight.com/1065-075X.html

[3] Development process, ProfIT Labs Ltd – Custom software development company, available at: http://www.profit-labs.com/development-process/

[4] M.E.Grimheder: Can agile methods enhance mechatronics education? Experiences from basing a capstone course on SCRUM, available at: http://www.sciencedirect.com/science/article/pii/S0957415813000044

[5] V. Mahnic: A case study on Agile Estimating and Planning Using Scrum, available at: http://www.eejournal.ktu.lt/index.php/elt/article/viewFile/372/318

[6] R. Pope-Ruark, M.Eichel, S.Talbott, K.Thornton: Let's Scrum: How Scrum Methodology Encourage Students to View Themselves as Collaborators, available at: http://teachigandlearningtogether.blogs.brynmawr.edu/archived-issues/may-issues/lets-scrum

[7] K. Schwaber, J. Sutherland: The Definitive Guide to Scrum: The Rules of the Game, available at: https://www.scrum.org/scrumguide?gclid=CPS9gJ7XubwCFUT3wgodv1gAag

[8] Scrum available at: http://en.wikipedia.org/wiki/Scrum _(software_development)

[9] Scrum Alliance, Core Scrum – Values and Roles available at: http://www.scrumalliance.org/why-scrum/core-scrum-values-roles)

[10] A. Soria, M.R. Campo, G. Rodriguez: Improving Software Engineering Teaching by Introducing Agile Management,13th Argentine Symposium on Software Enginneering, ASSE 2012, available at: http://www.41jaiio.org.ar/sites/default/files/271_ASSE_2012.pdf

[11] R.L. Upchurch, L. Williams. “In Support of Student Pair Programming.” ACM SIGCSE. ACM Publications, March 2001.

[12] VersionOne, 7th Anual Survey: 2011, The State of Agile Development, Full Data Report, available at: http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf

898