Вы находитесь на странице: 1из 7

Using Scrum to Teach Software Engineering:

a case study

Sergio Donizetti Zorzo, Leandro de Ponte, Daniel Lucrdio


Computing Department
UFSCar Federal University of So Carlos
So Carlos SP Brazil
{zorzo, daniel}@dc.ufscar.br

Abstract The diffusion of agile methodologies in software disciplined process paradigm would be more suitable for the
development makes them more mature for corporative still inexperienced students.
environment. However, teaching agile methodologies on the
academic environment poses many difficulties and limitations. We were facing the same dilemma in our university. We
This paper describes a case study where an innovative approach have a two-year lato sensu (specialization) graduate course in
for teaching software development technologies was adopted. In software development, which has been offered since 2003. As
this approach, the entire course was designed to fit Scrums the final part of this course, students must develop a large
principles, so that the students could apply them as they were project to put into practice the concepts they learn. Until
learning it. Also, the courses main project was to be developed in recently, they followed a traditional process, moving from
sprints, as proposed in Scrum. After almost two years using this requirements to the finished software product in a single
approach, in this paper we describe our experience and perform iteration. However, this model was causing problems, mainly
a critical analysis. We observed some positive points, such as the because of the lack of proper time management. Due to
practical nature of learning by example, and a better preparation different factors, such as limited availability of the students and
of the students regarding agile methodologies. As negative points, a long wait until they reached enough maturity to start
we highlight the impossibility of delivering complete products in developing the project, the delivery of unfinished and/or poor
earlier sprints, and some interaction and collaboration quality projects was very frequent.
difficulties. The main conclusion of this study is that, for the
approach to work in our academic scenario, a modified version An agile methodology seemed to be a perfect solution, as it
of the Scrum methodology was necessary. is a structured process, but that supports both creativity and
productivity in a team project. It also allows for flexible, self-
Keywordsagile methodologies, software engineering, controlled time and task management that enables students to
academic teaching, SCRUM react on the varying workload in their jobs [4]. So, as pointed
out by Schneider and Johnston [5], we asked ourselves: should
I. INTRODUCTION
we try to change the scenario, and introduce the practices of
The software market demands readiness for unexpected and agile methodologies in software development education?
quick changes, and the earlier software engineering
methodologies did not seem to be appropriate for many We decided to follow this path, by adopting a Scrum-based
practitioners. Agile methodologies, such as Scrum [1], are a approach to teach software development technologies and
response to this demand. As a direct consequence of this software engineering concepts. In the approach, some Scrum
evolution, there is an increasing need to place more emphasis practices, such as iterative and incremental development based
on teaching Scrum in order to prepare students for their on sprints, were integrated into the academic environment, so
professional careers [2]. that the learning itself could happen in an iterative and
incremental way. To fit this format, the entire course had to be
It is a known fact that teaching software engineering cannot reorganized so that the disciplines could deliver the necessary
be restricted to presenting concepts and methodologies as contents for the sprints to succeed.
abstract ideas. It requires the integration of applied
methodology and theory into the practice of software In this paper we present the approach in details, and also
development, otherwise students may fail to develop a deep perform a critical analysis after two years of experience with it.
understanding or appreciation of the most important ideas [3]. We highlight the main positive and negative points, and try to
For this reason, most software engineering courses have a large make suggestions to improve it in the future.
project, meant to be its final piece, also known as capstone The remainder of this paper is organized as follows.
project. Mahnic presents a discussion about the use of agile Section II presents the background and scenario of the study.
methods in capstone projects, based on different literature Section III presents the sprint planning for this course. In
reviews [2]. While there are many successful stories that favor Section IV we present our critical analysis and suggestions for
agile methodologies in these scenarios, Mahnic argues that the second version of the course. Finally, in section V we
there are some reports indicating that a more traditional, present some concluding remarks and future work.

978-1-4673-5261-1/13/$31.00 2013 IEEE


II. BACKGROUND an incomplete project in the end. It would also make them
The initiative described in this paper was conceived in the practice agile development in a mid-size project, reducing the
context of a lato sensu (specialization) graduate course, in the gap between theoretical software engineering teaching and
area of software development for the Web, offered at UFSCar practical agile concepts.
Federal University of So Carlos SP Brazil, since 2003. Next section presents the detailed course setup and
In this course, students learn different software development description of the course project, according to the agile
techniques and concepts, such as programming, modeling, approach.
database design, human-computer interaction, web
development and project management. The course has also a III. COURSE PROJECT
practical component, in the form of a mid-size software Initially, it was established that the course disciplines
project, where the students can put most of the theory in would be divided according to their applicability in the project.
practice. The course project was supposed to be developed in For this reason, the course started with an overview of Scrum,
parallel with the theoretical activities, in groups of six or less basic programming, requirements and analysis. More advanced
students. contents, such as database design and programming
But since the beginning of the offering, we observed that frameworks, were to be introduced later, and so on. This was
many projects reached the end of the course as incomplete, or done for the theoretical part of the course, which resulted in
with fundamental flaws that could not be corrected in time. We four phases, described next.
identified two main possible causes for this problem. The first The first phase had an estimated duration of 3 months, and
one is the fact that most students have a limited availability consisted in an introductory phase. It was also called pre-
because they have jobs and/or work in different areas. They Scrum phase, and was dedicated to the activities that are not
typically have 6-8 hours per week to work on practical related to actual development. In this period, there were
assignments, and this was causing many delays. teaching activities about the development process, environment
A second possible cause is the fact that many students preparation and basic programming. The disciplines that were
seeking this degree have little or no knowledge in computer part of this phase were:
sciences, while others have practical knowledge, but never got - Agile software development: studies about the software
a bachelor or engineers degree. We typically have 20% of the development methodology that would be used in the
students without knowledge in software engineering and 30% projects. In this course, Scrum was adopted;
of the students working in other areas. As a result, the classes
normally start with a very heterogeneous distribution in terms - Free software development platforms: preparation of the
of academic formation and practical background. Many environment to be used in the project. In this case, the
students do not reach a degree of knowledge that is sufficient students would have to work with CentOS [6], PostgreSQL
for the project to start until much later in the course. So the [7] database and Java IDEs NetBeans [8]; and
project normally started only after one year or more. - Java certification: a basic java discipline, intended to help
After many discussions, the course organizers came to the students get acquainted with the language that should be
conclusion that the solution to this problem was not to change used to develop the projects.
the course duration 444 hours distributed over two years The second phase, which had duration of 4-5 months,
but to better distribute theoretical and practical effort. involved the actual usage of the agile methodology. In this
Together with this observation, there was the fact that agile phase, the disciplines focused on requirements, analysis and
methodologies were already included in the course program, as design. The goal was to enable the analysis and design of the
a subject related to project management. But it was being project to be developed. But since the students should already
taught in an abstract way, leading some students to wrong be developing part of their projects, some software
conclusions or even boredom. development techniques were explored, such as web
development, mobile computing, and database activities. This
As a response to these two problems, the course was would allow them to deliver a few parts of the software that
reorganized to employ the concepts and principles of agile involved only basic programming. Other parts of the project,
methodologies. Because it follows the agile ideology [1], even that required advanced knowledge on database persistence or a
though it is not specifically tailored for teaching, Scrum was more complex framework, would be introduced later.
adopted as the model for the iterative approach to be followed
during the course. In the third phase, with duration of 5-6 months, there were
the disciplines that would provide most of the content of the
First, it was established that the project was to be developed course. Here the focus was on giving a complete coverage of
iteratively and incrementally. At short periods of time, or most recent web development topics, such as human-computer
sprints, students should deliver parts of the system, until it is interaction, object-relational persistence frameworks, service-
complete. In parallel, the theoretical disciplines of the course oriented architecture, reuse-driven development, test-driven
were reorganized to deliver the necessary content for each one development, among others. The content of this phase was
of these sprints to succeed. intended to be used by the students during most of the part
The expectation behind this proposal was that students when developing their projects.
could start development earlier, and have less risk of delivering
In the fourth and final phase, which was supposed to last To support these deliveries, the disciplines had to be
2 months, the disciplines involved advanced topics, to close the arranged to provide students with the necessary knowledge in
theoretical part of the course. Project management, advanced each sprint, in order to allow a logical evolution from sprint 1
development topics, such as data warehouse and optimization, to 8. So, early sprints have more focus on disciplines from the
and even scientific methodology, helped to give students a phase one of the theoretical part of the course. And late sprints
better understanding of which topics could be further explored have more focus on the disciplines from phase four.
later in their career.
There had to be some repetitions, as some disciplines had
These four phases characterize the theoretical part of the too much content. In these cases where the same discipline
course; however they were not applied in a sequential way. appears in more than one sprint, only part of the content was
Since we were following an iterative process based on Scrum, given at each time. For example, the agile software
the actual division of activities was different. The course was development discipline appears in six sprints, each time
organized around the project, and thus it was divided into eight introducing new concepts, starting with basic concepts and
sprints of three months each. At the end of each sprint, students ending with practical examples and guidelines. Object-
were supposed to deliver part of their projects, as working relational patterns and frameworks is another example,
software. appearing in three sprints, basic concepts in the first and

TABLE I. BASIC COURSE SCHEDULE

Sprint Disciplines Sample deliverables of one of the groups


- Agile software development
Pre-
- Free software development platforms None
Scrum
- Java certification
- Web programming
- Pattern-based software modeling - Class models
- User interface design and evaluation for the web - Database models
1
- Object-relational patterns and frameworks - Basic CRUD operations for users
- Agile software development - System authentication
- Database design
- Pattern-based software modeling
- User interface design and evaluation for the web - Advanced CRUD (different user types)
- Object-relational patterns and frameworks - Community creation
2
- Database design - Update in the system layout
- Mobile computing - Update in the documentation
- Agile software development
- Profile visualization
- Mobile computing
- Profile data update
- Web development frameworks
3 - Sharing of public messages
- Object-relational patterns and frameworks
- Timeline visualization
- Agile software development
- Pending issues in authentication
- Design for mobile devices
- Login/logout for Mobile
- Service-oriented architecture and web services
- Information visualization
- Reuse-driven software development
4 - Multiple timeline visualization
- Scientific methodology
- Basic CRUD for other information
- Agile software development
- Message posting
- Project mockup
- Test-driven development
- Service-oriented architecture and web services - Technical issues
5
- Reuse-driven software development - Visual adjustments in the interface
- Scientific methodology
- Reuse-driven software development - Image posting
- Performance optimization of Relational DBMS - Contact acceptance
6 - Images and visual effects in web applications - Search for contacts and communities
- Software development topics - Inclusion of contacts and communities
- Agile software development - Community visualization and adding
- Video posting
- Data warehouse - Invitation/inclusion of people in communities
7 - Scientific methodology - Administrative interface
- Reuse-driven software development - Access privilege control
- Community reports
- Project management in agile software development
8 - Technical issues
- Scientific methodology
practical knowledge in the end. they work also caused a great degree of heterogeneity and a
knowledge gap between the members of a group.
Although it may seem that these sprints take longer than
most sprints in industrial projects, which typically last between To minimize the negative impact of these factors, we
2-3 weeks, in terms of work hours the duration is defined that all groups, without exception, should work on one
approximately the same, because students were supposed to out of two possible projects. Half of the groups would develop
work 8-10 hours per week on the course project. project A, and the other half would develop project B. With a
regular class size of 35 students, this results in six teams with
Table I shows the basic course schedule, together with an 5-6 students.
example of the deliverables that one of the groups should
provide at the end of each sprint. The deliverables refer to a Two teachers would play the role of PO, one for each
system to help in the organization of scientific events, which project. They were supposed to help during the planning
was the domain of their project. In the next section more meetings and give technical support regarding the development
details about the project and the deliverables are presented. technologies and/or correct application of Scrum principles.
The students must complete a mid-size software project as Control during the process would be performed with the
part of their course. In our approach, this should be done help of an on-line sheet. In this sheet, students and teachers
iteratively, to reduce the risk of incomplete projects in the end. should include and maintain all the necessary information to
So, the students had to plan what should be delivered, in term allow a proper management of the development in each sprint.
of user stories [9,10], at the end of each sprint. Due to the
limitations of the academic environment, in comparison with Basically, when planning a sprint, the students would insert
an industrial project, in our approach students were allowed to the stories in the sheet, together with the activities to be
deliver incomplete products in some sprints. In other cases, performed. With all activities available on-line, each member
students could plan to deliver only enhancements or perform it. The Scrum Master (of that particular sprint) was
adjustments, instead of a product, in a sprint. Table I shows responsible for maintaining the sheet, and also making sure the
some examples of these cases in sprints 5 and 8. But every others keep it updated, so that he/she could follow the
sprint should include some form of deliverable. burndown chart [9,10]. In this sheet, the chart was
automatically updated each time an activity was marked as
There was a product owner (PO) [9,10] assigned to each completed. The following information was part of the sheet:
team of six students. The PO would be responsible for the
definition of the stories and for following the results of the - Product backlog: list of stories of the system, with a detailed
development. As this was also an exercise of Scrum itself, description and the acceptance criteria;
students had to practice the role of Scrum Master [9,10]. So, in - Sprint: stories of the current sprint and the tasks needed to
each sprint, a different member of the team should act as finish them;
Scrum Master, to put in practice the different concepts of the
method and also learn his/her responsibilities. - Kanban: repeats the tasks from the sprint part, and
includes a status column (to do, blocked, doing and
Another important point of the project setup was the done) and a task finish date column. Fig. 1 shows an
definition of the domain. We have observed that, in this course, example of this part of the sheet;
the groups almost always follow a pattern: normally, students
are professionals working on the software market, with little - Burndown data: based on the tasks table of the kanban
time to develop the activities. They also normally live in a sheet, this part keeps a comparison between the planned
distance from each other only a few groups are composed of dates and the actual dates; and
people living in the same city. The different areas in which - Burndown chart: graphical visualization of the burndown

Fig. 1. Example of a kanban sheet


data. Fig. 2 shows an example of this part of the sheet . software. For example, service-oriented architecture is only
introduced in sprint 4, so it was impossible for some groups to
implement a distributed part of the software in sprints 1, 2 and
3. More basic concepts, such as object-relational frameworks,
were introduced only in the final stage of sprint 1. Some
framework concepts were left to sprints 2 and 3, so many
stories could not be completely implemented in these sprints.
When interviewed by us, some of the students reported this
exact problem. Many complained about the mandatory
deliveries in the early sprints, arguing that they still had not
learnt the necessary concepts to implement what was being
Fig. 2. Example of a Burndown Chart planned. Those ended up delivering incomplete software or
software with conceptual errors. Of course, there were those
students that already had the necessary knowledge, because
they already work with development, but this is far from ideal.
IV. CRITICAL ANALYSIS A second problem we observed relates to inspection and
In general, the approach was successful, as both of its goals self-management, two central aspects of Scrum [9,10].
were achieved: Students reported that, because they are not physically close to
each other, and because many of them had other time-
1. All groups were able to deliver the complete project in
consuming activities, some of the interaction tasks required for
the end of the course; and
control in Scrum were not properly executed, or not executed
2. Students managed to put some of the agile principles in at all. One example is the interaction between the Scrum
practice, using them as they were learning them. This resulted Master and the rest of the team, which turned out to be very
in a better learning of agile concepts. difficult under these conditions. The physical distance and the
lack of responsibility and discipline of the other members of
There were also some additional positive observations. In the team made it nearly impossible for the Scrum Master to
our case, both teachers acting as POs had previous experience control task execution in a continuous fashion. This is a serious
with Scrum in practical scenarios, which has proven to be flaw, because personal interactions is a strong principle of
essential to provide a good alignment between the course Scrum and agile methods in general.
content and the principles of agile development. The presence
of these teachers as POs, and their constant availability, was Another issue is that, because there were only two possible
also a positive result, since it allowed students to clear their projects, shared by all groups, there was always some kind of
doubts without taking too much time. The fact that the POs comparison happening between the students. Some felt
were teachers, specialized in Scrum and technical development pressured to keep up with the most experienced students, while
concepts, and not business experts, did not result in a negative others, less experienced students, felt intimidated by the top
influence. This happened because the projects involved a groups, becoming even frustrated in some cases.
domain which they were actually very familiar with scientific We do not see any ideal solution for the first two issues, as
events. The rotation of the Scrum Master role was also we consider them to be innate to this particular academic
benefitial, allowing each student to play this part at least one environment. It is not possible, for example, to obligate
time. students to be physically present at the university all the time,
However, we observed many problems with the approach, since this is a postgraduate course, and most students have their
and we believe these could be addressed to provide even better regular jobs. However, we did identify some improvement
results in the future. possibilities, that we intend to test in a future version of the
course. These are described next.
A first problem relates to the gradual evolution of the
learning process in a normal course, and its contrast with the A. Changes in the second version of the course
incremental and iterative approach proposed by most agile A first change relates to the definition of the POs. In the
methods. There is a natural incompatibility between these two first version, two teachers acted as POs for all groups. This was
approaches, because each sprint represents a small, but not seen as a negative point in the first version, but only
complete, development iteration. This means that, in each because the projects involved a domain the teachers were
sprint, the development team must perform activities that are familiar with. As we wanted to change the domains, we
related to almost all software engineering disciplines, even if decided to use actual business experts as POs. We also defined
only a little part of them at a time. Although we attempted to that they should not be familiar with technical details. The idea
introduce these disciplines at the same time, much content was is to make the students experience what it feels like to deal
only really assimilated by students after two or three sprints, with potentially real customers, having to work harder to
after the discipline was finished. establish the communication and capture the POs knowledge.
This explains why most groups were unable to deliver A second change is that, differently from the first version,
complete software in earlier sprints, because they simply did where there were only two projects from which students could
not have enough knowledge to implement a complete piece of choose, in this second version there were more options,
allowing each group to work in a different project. This should - Self-management formalization, to help Scrum Masters to
reduce the comparison effect we observed earlier. deal with their teams. Currently, it is up to the team to
define how they should be managed. However, this has
Another change in this second version is related to proven to be problematic, because of the distance between
corrections and improvements made in the software, from one its members. A more formal process, requiring more rigid
sprint to another. In the first version of the course, we observed control, would force students to have discipline and an
that many groups were spending time in one sprint to correct active participation, specially in process control. Even if it
mistakes made in the previous one. This happened because of goes against the agile principles, we believe this could be
the irregular learning curve discussed in previous section. In benefitial in this particular environment.
this version, we made it possible for students to include these
corrections and improvements as valid deliverables. So, instead The experience, although in its first version and with
of delivering one complete piece of software in each sprint, a glitches and corrections to be made, forcing students to not
group was allowed to deliver an incomplete, or erroneous part only understand the concepts wrapped up the process, but also
of software, in one sprint, and plan its correction in a future to apply them and feel the difficulties faced by professionals
sprint. who choose to use the method, as both procedural and planning
relationship with the team.
The changes described here are being currently tested, in a
second offering of the Scrum-based version of the course. We It is felt that some aspects of the methodology, such as the
expect to observe improvements related to some of the issues closing of scope and delivery restrictions, sometimes must be
described in the previous section. adapted so that it becomes feasible to use the method in
practice academic environment. The vision of the labor market
V. CONCLUDING REMARKS AND FUTURE WORK and experience in agile methodologies presented by those
Although we observed many problems and issues, the involved was importance to design and optimized coordination
merging between teaching and an agile process has proven to of the course. Some strategies may not be considered agile, as
benefitial to students. It leveraged the overall experience, from the time between sprints and little interaction between the team
simpler theoretical classes, to a richer practical activity members. The time between sprints is necessary because the
revolving around actual development, simulating the real teams need learn how to do and do it. The increase of
challenges of this dynamic environment. Students were forced interaction between the team members can be made and we
to not only understand the concepts and principles of agile have recommendations how to solve it in the next experience.
development, but put them in practice and feel the difficulties In the next experience some points will be analyzed to
faced by practitioners. In particular, they had to deal with reduce the difficulty required to develop the full functionality
technical challenges, process enactment challenges, personal in the sprints with only part of knowledge, requiring only the
interaction and inter-team relationship. scope that has already been taught. The process for the
We perceived that some aspects of the methodology, such development of Sprint requires weekly meetings replacing the
as scoping and delivery restrictions, had to be adapted to make daily meetings of the original conception of Scrum. The
the experience viable in an academic environment. Some of meetings will relate the status of the worksheets and they will
these adaptations were aldeady made during this first show the progress of activities in parallel. These points will be
experience, while others are being tested in a second version. not abandoned and they are essential for the correct handling of
In either case, the adaptative nature of the course made this the use case, where someone can perform a checkpoint of these
experiment possible. activities during the sprints, assessing whether the performance
is occurring in the team. However, attention must be given up
Regarding the difficulties and problems that were observed, lest they undermine the progress of activities and the
we conclude that some can not be easily solved, such as those motivation of participants with a big load evaluation.
related to the physical distance between the students and their
lack of time and dedication. For others, we are currently REFERENCES
experimenting some changes, as described in previous section,
and we expect good results. Feedback from the teachers and [1] Rising, L. and Janoff, N.S. Jul-Aug 2000. The Scrum software
the students will enlighten our path, and possibly raise new development process for small teams, Software, IEEE , vol.17, no.4,
issues. pp.26-32.
[2] Mahnic, V. A Capstone Course on Agile Software Development Using
Besides these changes we already described, future work Scrum Feb. 2012. IEEE Transactions on Education , vol.55, no.1,
should deal with: pp.99-106. doi: 10.1109/TE.2011.2142311
- Better distribution of the disciplines alongside the sprints, to [3] Dahiya, D. 2010. Teaching software engineering: a practical
approach. SIGSOFT Software Engineering Notes, Vol.35, pp.15.
provide a closer alignment with the deliverables. Perhaps
[4] Schild, J., Walter, R., and Masuch, M. ABC-Sprints: adapting Scrum to
there should also be some kind of guidance during the academic game development courses. 2010. Proceedings of the Fifth
initial planning, in order to help students to start with International Conference on the Foundations of Digital Games (FDG
simpler stories; '10) ACM, New York, NY, USA, pp. 187-194.
[5] Schneider, J.G. ; Johnston, L. and Joyce, P. Curriculum development
- Better choice of projects, to only include those that are in educating undergraduate software engineers - are students being
amenable to a more logical division from simpler prepared for the profession?. 29 March-1 April 2005. Software
functionality to a more complex one; and Engineering Conference. Proceedings. 2005 Australian , pp.314-323.
[6] CentOs Internet: http://www.centosbr.org [Apr 02, 2013] [9] Singh, M. "U-SCRUM: An Agile Methodology for Promoting
[7] Welcome to NetBeans. Internet: http://www.netbeans.org [Apr 02, Usability," 4-8 Aug. 2008. AGILE '08. Conference , Proceedings, pp.
2013] 555-560.
[8] PostgreSQL: The world's most advanced open source database [10] Schwaber, K. and Beedle, C. 2002. Agile Software Devlopment with
Internet: www.postgresql.org [Apr 02, 2013] Scrum, Prentice Hall.
[11] Sink, E. "Stories from My Experiences Learning Scrum," 7-13 Aug.
2011. Agile Conference (AGILE), 2011 , pp.216-222.