[ieee 2009 39th ieee frontiers in education conference (fie) - san antonio, tx, usa...

Session T2C

978-1-4244-4714-5/09/$25.00 ©2009 IEEE October 18 - 21, 2009, San Antonio, TX 39th ASEE/IEEE Frontiers in Education Conference T2C-1

On the Use of Scrum for the Management of Practcal Projects in Graduate Courses

Luciano Pinto, Ricardo Rosa, Cristiane Pacheco, Christophe Xavier, Raimundo Barreto, Vicente Lucena Jr., Marcus Caxias, Carlos Maurício Figueiredo

[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

Abstract - The premises considered by this work are that projects development in graduate courses is important for knowledge consolidation. However, one of the prob-lems is that, usually, students are not prepared to man-age and to be managed. This situation causes higher effort waste and is time-consuming. Additionally, the quality is decreased due to poor self-management and inadequate division of activities. Such problems can be minimized if there is a management policy that provides a wider vision of the project’s course, allowing the prob-lems to be anticipated in such a way as to correct the flaws as soon as possible. This work proposes the adapta-tion of the SCRUM Agile Project Management Method-ology in the context of the development of academic pro-jects, both in undergraduate and graduate courses, where students are organized in small teams and execute the project in a systematic way. This method was applied during the practical part of the "real-time systems" course, whose project was the development of an auto-mated industrial production line with robot arms, using the LEGO NXT robotic kit. Therefore, this paper will show implementation aspects of the proposed method, difficulties and solutions, which parts of Scrum were effectively adopted and, specially, the learnt lessons. Index Terms – SCRUM, Agile Methodology, Academic Projects, Real Time Systems.

INTRODUCTION

One of the premises considered by this work is that projects development in disciplines is important for knowledge con-solidation. However, it is common knowledge that it is a hard task to manage academic projects, both from the in-structors’ and students’ point of view. Among the greatest challenges faced in such undertakings lies the handling of teams during the development process in projects of medium to large sizes.

Some problems were identified when applying projects in graduate courses: (i) students are not prepared to manage and to be managed; (ii) division of tasks among the group members is not made in a systematic way; (iii) teams may face doubts and difficulties which are not handled ade-quately by instructors; (iv) there may be misunderstandings on the scope of the project’s requirements, as most of the

instructors tend to simply assign the project specifications and let the students fend for themselves; and (v) students complain about the instructor’s evaluation criteria [1]. These problems may result in a great amount of wasted effort and time. Additionally, the quality is decreased due to poor self-management. For that reasons, instructors are often discon-tent with the final results.

Such problems can be minimised if there is a manage-ment policy that provides a wider vision of the projects’ courses, allowing the problems to be anticipated in such a way as to correct the flaws as soon as they appear. The idea is that such management policy needs to be efficient, effec-tive and, at the same time, grant the freedom needed for the adequate management of the team.

With this purpose in mind, an adaptation in the use of the SCRUM Agile Project Management methodology to academic context has been made, which can be applied in both undergraduate and graduate courses. The students are thus organised in small teams and execute the projects in a systematic way.

The proposal is that the instructor plays the role of Product Owner while the course monitors play the Scrum Masters. The Sprint is of short duration (in this context, usually one or two weeks), and the amount of tasks to be accomplished in each Sprint, called Sprint Backlog, is de-termined by the team, but the priority of each task is always made by the Product Owner. Consequently, at the end of each Sprint, a functional part of the project is delivered. The planning for the next Sprint is then done, where the next goals are set and a retrospective of the previous Sprint is made to identify strong points and faced difficulties. This process is repeated until the project is complete. In SCRUM, daily short meetings are held where accomplished tasks, future activities and challenges are discussed. This improves the quality and productivity and impacts positively on time usage.

In order to describe the proposed adaptation in the aca-demic context, this paper is divided into four additional sections. Section 2 shows a brief description of the SCRUM methodology. Section 3 presents the case study, where the used approach is described, along with the changes neces-sary to adapt SCRUM to academic use. Section 4 reports the achieved results, with the successes and pitfalls found during the adaptation of the methodology. Finally, Section 5 pre-sents concluding remarks and future works.

Session T2C


SCRUM: AN INTERESTING ALTERNATIVE

Several Agile Methodologies [2] were considered to be applied in this case study, including Extreme Programming [3] which doesn’t specify management practices [4], and other methodologies. However, the chosen one was SCRUM due to its increasing use in industry [5] and its focus on the management of the development process as a whole, includ-ing the development team [6]. As said in [1], “SCRUM en-forces individual responsibility, encourages the team mem-bers to set and achieve short term goals, gives the partici-pants a sense of ownership over the project, and helps them produce more work in the same amount of time”.

The participants on this methodology are: Product Owner (PO), SCRUM Master (SM) and Development Team (DT), which is composed by developers with the skills re-quired for the project. Additional parties can be invited by any member to provide further business or technology do-main information and advice, but they are released after such information is provided [7].

SCRUM relies, in its practices, on an interactive and in-cremental process framework. Such framework is shown in Figure 1. The lower circle represents an iteration of devel-opment activities that result in a functional product, accord-ing to the goals of the current cycle. The upper circle repre-sents the daily inspection that occurs during the iteration, in which the individual team members meet to inspect each other’s activities and make appropriate adaptations. Driving the iteration is a list of items to be developed, that compose the Product Backlog. This cycle is repeated until the project is considered completed by the Product Owner, or no longer funded.

FIGURE 1

SCRUM FRAMEWORK [7] The PO has as one of his activities the management of

how the DT views the product. He needs to convey his re-quirements as clearly as possible, not leaving any openings for double meaning or misunderstandings. He also raises all the funding necessary to the project, in connection with the stakeholders and founders, using as documentation an initial Product Backlog and later the sub-products released at the end of each Sprint. Another attribution is the project’s Re-turn of Investment (ROI). In other words, he also monitors

the project to keep track of the costs and see if it still justi-fies further investments.

He also updates and prioritises the Product Backlog to ensure that the functionalities with highest aggregated value are developed first. This constant control on the Product Backlog allows him and the DT to refine the requirements and measure the success vs. cost ratio. Another of the PO’s tasks is to manage the delivery, i.e., he decides when an official delivery should take place.

On the DT’s side, the Scrum Master also plays an im-portant role. He manages the whole process, i.e., he is re-sponsible for directing the whole team towards success by ensuring that the project and the organizational culture are optimised to fulfil the ROI demands. This involves the ar-rangement of planning and review meetings, as well as pro-tecting the DT from unwanted external influences. To ac-complish this, it is necessary the optimization of the daily meetings to avoid wasting precious development time, along with the removal of any impediments that might have risen along the way [8].

The DT also has the responsibility to manage the Sprint. They select the activities with the highest priority from the Product Backlog. Then, collectively, they expand the chosen activities and split them into smaller tasks, recording the results in the Sprint Backlog. Finally, they divide the work-load among the team members according to each one’s skills and strong abilities and start the development process. From this point on, each member manages his own work.

To summarise, the whole SCRUM process works as fol-lowing: the Product Owner lays down the requirements for the project. The Scrum Master, along with the Development Team, starts by breaking down the project into a series of Product Backlog items that need to be accomplished in sev-eral iterations, in this context called Sprints. Following this, each of these Sprints is planned and scheduled to be devel-oped in the time encompassed by a Sprint, ranging from one to four weeks. At the beginning of each Sprint, the team needs to arrange a Planning Meeting where they will decide what will be delivered at the end of the cycle. This planning should take into account the need to deliver a functional sub-product by the end of each Sprint. The Product Backlog items then have their complexities estimated and are all catalogued to compose the Sprint activities. This meeting generates the Sprint Backlog where the Sprint activities are recorded for development and follow-up. With this first stage finished, the DT then starts the development process and records all progresses in another document called Work Burn-Down Chart [9], where the remaining time for a task completion is accounted. At the end of a sprint the team reviews their work with the product owner and has a retrospective meeting [10].

Since it is natural to face difficulties during the devel-opment process, it is extremely important to be present in the daily meetings advocated by the SCRUM methodology, so that any problems found can be promptly addressed. The responsibility to address and find solutions to the problems that the DT members are unable to solve by themselves is

Session T2C


fully transferred to the SM, especially if it requires the inter-vention of the PO for any decision making or to supply any resource shortages that might come up. In such cases, the SM will deal directly with the PO, without involving the DT members.

These daily meetings, conducted by the SM, are kept short, typically under 15 minutes and the discussion is guided by three basic questions [11]:

• What did you do yesterday? • What will you do today? • What obstacles did you face?

At the end of each Sprint a Review Meeting is held, with the purpose of presenting to the PO and guests what has been done. The DT makes a presentation to demonstrate the deliverable. The PO then evaluates if the Sprint Goals have been achieved and makes any remarks he deems necessary, which, depending on the complexity and impact on the pro-ject, as well as on the costs and scheduling, may become new items in the Product Backlog [7].

The last event on a SCRUM Sprint is the Retrospective Meeting. This meeting represents the Inspection/Adaptation spirit within SCRUM. It is usually held only between the SM and the DT (however, if all members agree, the PO may be included), where the learnt lessons and difficulties found are discussed. With the SM guidance, the whole team tries to evaluate the following questions:

• What was good on the last Sprint? • What should be improved? • Who is in charge of that?

With this approach everybody involved in the develop-ment process is aware of the overall progress of the Sprint and can participate by giving suggestions and coming into agreement to possible solutions to the problems. This en-sures what is most characteristic of the SCRUM methodol-ogy: the focus on the people, not on the process itself. This reflects on the productivity of the team. This process has proved effective in the industry. However, when used, ipsi literis, in the context of academic projects, several difficulties were faced, which will be discussed in more details in next section.

THE CASE STUDY

The case study has been conducted as part of the final pro-ject of Real Time Systems course, with participant students from the Master Courses in Informatics and Electrical Engi-neering of Universidade Federal do Amazonas (UFAM), a Federal University in the Amazonas State, in Brazil.

The project consisted in developing a real time system to control an industrial production line scenario, using the Lego Robotic Kit Mindstorms NXT [12]. Two kits have been used to assemble this scenario. Initially, the idea of the scenario was to assemble the production line with one belt conveyor, three mechanical arms, three light sensors and

three product trays. Products of two different colours, in this case represented by blue and red balls, would be placed on the conveyor. Each robotic arm would be fixed in a particu-lar position along the conveyor belt and would be responsi-ble for picking up a product of a specific colour. As the products were being carried by the conveyor, each robot arm would identify the colour of the product in front of it and, if of the correct colour, pick it up and place it in the respective tray, leaving the other products of different colours to be carried away by the conveyor belt to be picked by the other robotic arm. The third arm would only be used as a fail-safe in case the other two arms had failed to pick their respective products.

Later, it was noticed that, to build this initial scenario, it would be necessary to use four NXT kits: one for the con-veyor belt and the other three for the robotic arms. Since there were not so many kits available at the time, the pro-ject's requirements had to be adjusted and reduced to the conveyor belt and a single arm that would be fixed at one side of the belt and would now be responsible for identifying the colour of the products on the conveyor, picking them up and moving them to their respective trays.

Since the SCRUM methodology has been used to man-age the development process, every person involved had a role to play, according to their decision making position. The course instructor was the Product Owner, i.e., the person who would dictate the project requirements and also the one who would approve the outcome product of each Sprint as well as the final product, by the end of the project. The Scrum Master role would be played by the course monitor, serving as a liaison between the Development Team and the Product Owner, along with supplying any needs the Team might have. And finally, the Development Team itself com-posed by five Master Course students. The Table 1 summa-rizes the team organization.

TABLE 1

SUMMARY OF THE TEAM ORGANIZATION Role Quantity Performed by Product Owner (PO) 1 Course Instructor Scrum Master (SM) 1 Course Monitor Development Team (DT) 5 Master Course Students

To begin the development process, the DT created User Stories to help identify the relevant activities. According to SCRUM, once these activities have been identified, they need to be estimated in terms of complexity, duration and priority. With this information in hand, the project was then divided into four Sprints that were planned so that the activi-ties were grouped according to the product intended to be obtained by the end of each Sprint. The first Sprint had as product a fully functional conveyor belt. The second had as objective to assemble the robotic arm and program its verti-cal and horizontal rotation movements. By the end of the third Sprint, the robot would be able to identify the presence of a product and pick it up. Finally, by the end of the fourth

Session T2C


Sprint the arm would have to classify the products by colour and place them in the correct location.

The whole development process was documented ac-cording to SCRUM specification. Although the methodology is quite flexible, a few key documents must be produced. Right at the beginning, the Product Backlog was created where all project requirements were recorded and where their current development status, priorities, estimates, and the Sprint they would be developed in were kept. Every change in the requirements that occurred during the flow of the project was recorded in the Product Backlog, adapting an existing Product Backlog item, or as a new one. Addition-ally, for each Sprint, reports on planning, follow-up, review and retrospective were created. To help manage the progress in the development process, Burn-Up and Burn-Down Charts were used. These charts allowed the team to have a broader view of the planned vs. accomplished activity ratio.

These were the aspects of the SCRUM methodology that were able to be applied in a straightforward way. How-ever, some things are better suited for a professional envi-ronment, where all participants are more or less following the same schedule, have a common working environment, and thus, can be more easily reached.

When trying to map these circumstances to an academic environment where people have different time-tables, work in different places and have other responsibilities that some-times become an impediment, it was noticed that the only thing in common that they share is their participation in the course in question. So it becomes much harder to comply with some of the SCRUM rules, such as daily meetings. Right at the beginning it was almost impossible to have these meetings and it was clear that would become a severe hindrance if a way to counter that was not found.

As a countermeasure the DT decided to start using internet messaging tools and e-mail as a means to communi-cate on a daily basis. And to allow the documentation to be available to all participants, groups and document sharing internet tools, such as Google Groups and Google Docs were used, as shown in Figure 2 and Figure 3, respectively. These tools have proved to be very useful as they allow the docu-mentation to be accessed and modified by several users at the same time, without loss of information, as well as instant communication, despite the physical distance of some of the DT members.

Another tool that was used to compose the set of docu-ments needed was LDRAW and its libraries [13]. This is a free Computer-Aided Drawing (CAD) tool specialised in Lego pieces that allowed the team to model and manipulate the components such as the robotic arm and the conveyor belt. This facilitated the accounting of the number of pieces necessary to assemble the parts that composed the final product, generating at the end a list of parts that was at-tached to the final documentation, as well as the steps neces-sary to successfully assemble the production line. Figure 4 shows the model made using this tool, while Figure 5 shows the actual production line.

FIGURE 2

GOOGLE GROUPS AS A COMMUNICATION MEANS

FIGURE 3

GOOGLE DOCS AS A DOCUMENTATION REPOSITORY

FIGURE 4

LDRAW MODEL OF THE PRODUCTION LINE

The software development for the product line was made using the visual programming tool called NXT-G, supplied by Lego with the NXT kits, but it has also proved to be a source of difficulties, due to the real-time nature of the project, as this tool is not very precise in terms of time management.

However, despite these difficulties, the team was able to have positive results in applying SCRUM to academic pro-jects, as will be shown in the next section.

Session T2C


FIGURE 5

ACTUAL PRODUCTION LINE

ACHIEVED RESULTS

All participants had already had, to varying extension, some experience with the traditional software development proc-ess. All could notice the advantages of using the Agile ap-proach, even in an academic context. To do so the team tried to follow closely the principles contained on the Manifesto for Agile Software Development [14].

The Review Meetings at the end of each sprint gave the DT a better view of the achieved results of said Sprint, while the Retrospective Meetings allowed the team to evaluate, in each iteration, the improvements necessary to the current development process, as well as what went wrong during that Sprint and why, which, in turn, helped to avoid repeat-ing the same mistakes in the following Sprints. Finally, the Planning Meetings at the beginning of each Sprint allowed the group to focus on the Sprint goals.

During the planning phase, the group noticed that each student had other unrelated activities besides the project, so the time allocated for the daily activities had to be kept to a minimum. And due to the fact that the project was not too big and complex, it was accorded that each Sprint would last a week, and that the time unit adopted to estimate the tasks would be minutes. Even with these time constraints, the work flowed more easily than if the group were using one of the classical approaches.

However, even though the team had identified satisfac-torily all the activities that had to be performed, during the execution of the first Sprint it was noticed that there still had unforeseen activities that had to be done first. This impacted on the time estimations that had been previously done.

For example, on Table 2 a description of Sprint 1 (Fully Functional Conveyor Belt) can be seen, along with the esti-mated time and the real amount of time spent on each activ-ity. It can be seen that task 1.2 – Electromechanical Project was not detailed enough to allow noticing the need to install and configure the LDRAW modelling environment that would be used to build the model for the project. For this reason, a new task had to be added to the Sprint Planning,

along with the time estimation, concerning this installation procedure.

This whole process was repeated every time there was a change in the requirements or when other unforeseen tasks appeared. Although all these changes, in a way or another, impacted in the project planning and estimation, the project itself was completed within schedule, because, according to [14], ‘to respond to changes is more important than to follow a plan’. By acting promptly upon the problems as they ap-peared the time spent on planning everything over again could be reduced.

TABLE 2

TASK LIST OF SPRINT 1 WITH TIME ESTIMATION

Since the daily reports were made electronically, the

time spent was less than what had been planned, and the communication among the team members was constant as most of them remained online most of the day. All they had to do is send an e-mail to the group or hail someone with an Internet Messaging tool, such as Google Talk or Skype. Since the tasks were interdependent, when a team member needed something that was not yet ready or was having some kind of difficulty, the other members would join ef-forts to speed up the process. Again the team could apply what is said in [14]: “Individuals and interactions over proc-esses and tools”. This aspect was also a key to this project’s success.

By the end of each iteration a functional product was re-leased that added more features on top of the one delivered at the previous Sprint, generating only the necessary docu-mentation such as source code, LDRAW electromechanical models, technical description and components list. Again, the DT followed the principles described in [14]: “Working software over comprehensive documentation”. This helped the team fulfil the time schedule without difficulties, with all Sprints completed within the period of one week, as can be seen on Table 3 and on the Burn-Down Chart depicted in Figure 6.

The course instructor, playing the role of the Product Owner, constantly made observations about the outcome product, which greatly improved the development speed, as any changes required were promptly addressed. Again it

Sprints Activity Estim Real Sprint_1 Fully Fucntinal Conveyor Belt 2850 2650 1.0 Planning 360 360 1.1 Technical Specification 240 120 1.2 Electromechanical Project 240 540 1.3 Assembly 240 460 1.4 Technical Details 120 60 1.5 Set up of Software Development and

Upload environment 240 80

1.6 Development of Control Software 180 45 1.7 Tests and Adjustments 240 120 1.8 Follow-up 450 325 1.9 Review 360 360 1.10 Retrospective 180 180

9

s[o

toththfvweo

Tfppbththhsupa

978-1-4244-47

shows how ben14]. In this pa

over contract n

Sprints Begi

Sprint_1 11Sprint_2 11

Sprint_3 11

Sprint_4 11

On the inst

o see the proghem the oppohemselves and

final result. It ivelopment teamwith different engage a moreoping, separate

BURN-DOWNPERC

CONCL

The SCRUM mfulfil the specipossible to planprocess throughby SCRUM. Thhe developmehemselves to b

had been plannstart developingusing the classproject, the finand according t

14-5/09/$25.00

neficial it is tarticular case itnegotiation”.

TABCHART OF SPR

inning End

1/04 11/10 1/11 11/17

1/18 11/24

1/25 12/01

tructor perspecgress of the taskortunity to lead at the same timis also possiblem, making it pprojects in a complex proj

ely, parts of the

FIGN CHART SHOWICENTAGE OF TH

USION AND

methodology hific needs of an and follow thh the use of chahrough the useent process, thbe more responed and not wg the project, asical approachal product wasto the specifica

0 ©2009 IEEE39th ASE

to adopt the pt says: “Custom

BLE 3 RINT DURATION

Product

Conveyor BeltArm makes verotation movemArm identifiesproducts Arm identifiesfies products

ctive, it has becks given to the

arn how to effme improving e to manage m

possible to taskmore controllect with differ

e whole.

GURE 6 ING THE ESTIMA

HE TASKS DEVE

FUTURE PRO

as been succesacademic projehe whole projearts and docum of this method

he team membonsible, followwaiting until thas usually happ. This way, bs delivered witation.

E EE/IEEE Fron

ractices foundmer collaborat

N

t fully functional ertical and horizonments s the presence of

s colours and class

come much ease students, giv

ffectively manathe quality of

more than one k the whole clled way or evrent teams dev

ATED VS. REALELOPED

OPOSALS

ssfully adaptedects. Thus, it wect’s developmmentation adopdology to manabers have sho

wing closely whe last minutepens with studeby the end of thout any distr

ntiers in EducT2C-6

d in tion

ntal

si-

sier ving age the de-lass ven vel-

L

d to was

ment pted age

own what e to ents the

ress

Baseven wSCRUMproved pected r

Theperimenmake it to say thbecameunder-ga more and witteams. Omethodwill undstructur

[1] ALSHScoCon

[2] ABRAWAVTT

[3] Extremhttp

[4] LINDAgiMan

[5] GLAZMikNot

[6] SHWASCR

[7] SCHWcoso

[8] SUTHin C

[9] AbouthttpMar

[10] JUDSpaHawPag

[11] SUTFirs

[12] LEGhttpcess

[13] LDrawar

[14] Agileber

Occation Confere

sed on the achwith the adaptaM to manage

to be a feasibresults, alwayse team intendsnt in new projeeven more eff

hat it would bee part of the Sgraduation courprofessional-lith the capacityOnce they rea

dology has on derstand the imred process, rat

HARE, Khaled A., tt, “How do we m

nference – Panel D

AHAMSSON, PekARSTA, Juhani, AgT Publications, 20

me Programming: p://www.extremepr

DSTROM, Lowell, le Software Develnagement, Summe

ZER, Hillel, DALTke, et al., “CMMI ote, Software Engin

ABER, K., BEEDRUM, Prentice Ha

WABER, Ken, “Agoft Press, 2007.

HERLAND, Jeff, “Complex Projects”

t SCRUM, “Work p://www.controlcharch, 05, 2009.

Y, Ken H., KRUMark Innovation in a waii International Ce(s):275b - 275b

THERLAND, Jeff, st SCRUM”, SCRU

GO Mindstorms, p://mindstorms.legosed on March 15, 2

aw: The Central Sire, http://www.ldra

e Manifesto, http:/2008.

ctober 18 - 21,ence

hieved results, ations made to

practical acadble and efficies guided by a ws to use what hects, adapting ficient and lesse a great advanSoftware Enginrses, so that thike behaviour, y to perform lise the benefithe end produ

mportance of uther than a rand

REFERENCE

SANDERS, Deanmanage student projDiscussion, April 2

kka, SALO, Outi, Rgile Software Dev02.

A Gentle Introducrogramming.org/,

JEFFRIES, Ron, lopment Methodoler 2004.

TON, Jeff, ANDEor Agile: Why No

neering Institute, N

LE, M., Agile Sofall, 2002.

gile Project Manag

“Future of Scrum: , Agile Conferenc

k Burn-down”, aos.com/about/bur

MINS-BEENS, IlioSmall to Medium

Conference on Sys

“Agile DevelopmUM Alliance, Octo

o.com/eng/Antarc2009.

ite for the LDraw aw.org/, accessed o

//www.agilemanif

Sessio

, 2009, San An

it may be asso the process, demic projectsent way to reawell-defined plahas been learnt whatever is ne

s error-prone. Intage if this meneering discip

he students couwith more resbetter when w

its the applicatuct of their prousing a well-ddom, ad hoc ap

ES

n, BURRIS, Eddiejects?”, CCSC: Ce

2007.

RONKAINEN, Juvelopment Method

ction, accessed on May,

Extreme Programmlogies, Information

RSON, David, KOot Embrace Both!”November 2008, p.

ftware Developme

gement with SCRU

Parallel Pipelininge, 2005 Proceedin

rndown.php, acces

o, “Using Agile Prm Sized Business”,

stem Sciences, Jan

ment: Lessons Learober 2004.

tica_dest/Default.a

Family of LEGO Con November, 14,

festo.org/, accessed

on T2C

ntonio, TX

sumed that the use of

s has been ach the ex-an. in this ex-

ecessary to It is worthy ethodology line in the

uld develop sponsibility working in tion of this ojects they

defined and pproach.

e, SIGMAN, ental Plains

ussi, s, ESPOO,

10, 2009.

ming and n Systems

ONRAD, , Technical 5.

nt with

UM”, Mir-

g of Sprints ngs.

ssed on

ractices to 40th Annual

n. 2007

rned from the

aspx, ac-

CAD Soft-2009.

d on Decem-

[ieee 2009 39th ieee frontiers in education conference (fie) - san antonio, tx, usa...

Documents