How can Scrum be adapted to an academic environment?

Question

I'm currently working with a professor at my university to develop new curricula for the Software Engineering and Capstone Design courses offered in my college.

Up until recently, both courses used the waterfall model exclusively, and thus students spent a majority of their time writing lengthy reports. After much pressure from me, my professor decided to include Scrum in the Software Engineering curriculum this past semester.

The first half of the semester was still waterfall-esque, with students writing 40-page design reports and software specification documents. Mid-semester, all teams were required to release a demo of their applications. At that point, the course switched to Scrum, with two 3-week sprints. We are now trying to figure out how to eliminate waterfall altogether and create an exclusively Scrum-based curriculum.

Unfortunately, we encountered a few incompatibilities between Scrum and the students:

• Daily Scrum meetings are nearly impossible for students. Even during the class itself, it's inconvenient for students to hold Scrum meetings since the professor is usually lecturing.
• Estimating points/hours is difficult, since students are inexperienced and therefore can't accurately predict how long something will take.
• Scrum works best with full-time, co-located developers, but students are neither. At most, students dedicate 15-20 hours per week to the course, and organizing work meetings can be extremely difficult. Teams can have up to 10 students (and there's always one or two slackers).
• Professors crave documentation! I haven't heard of any Scrum reports—just the backlogs and burndown charts (which I'm not sure will be enough to appease the academics).
• Students often assume that agile means "Jump right in and start coding without looking back". This leads to some of the most horrible code imaginable. Therefore, I'm looking for a way to enforce proper design without requiring a 50-page document or a pile of UML diagrams.

Given these problems, how do you think my professor and I can adapt Scrum to function in an academic environment (and should we even bother with Scrum in the first place)? Also, is there still value to teaching the waterfall model?

Thanks in advance for any feedback!

Answer 1

I would be hesitant to discard Waterfall across the board so quickly.

Although it is a flawed model for actually building software systems, it's not a bad teaching model to instruct on good practices for each stage of the lifecycle. Regardless of the process model that you apply to the project, you still perform requirements engineering, system architecture and design, implementation, testing, release, and maintenance (including refactoring and enhancement). The difference is how these phases are organized and conducted, but all of the activities still happen.

I'd argue that your transition from Waterfall to Scrum in the middle of the project is not the best idea. A key to Scrum's success is a long-running project. The first three to five sprints are the team settling in on a velocity, learning the process, and going through team development. Although you are doing through the motions, it's not really Scrum at that point. In addition, trying to create an exclusively Scrum-based curriculum is probably a bad idea as Scrum as not a silver bullet - it's better to teach best practices rather than a single methodology. In the workforce, not all projects are going to use Scrum. In fact, in some environments, Scrum would be detrimental to the success of the project.

You've already found problems with Scrum in an academic setting, and some of them are hard to adequately address.

The non-issue in your list of incompatibilities is that estimating is difficult. Yes, it is. But the only way to get better at estimating is to estimate and compare actuals against estimates. Students should be estimating size, time, and effort using various means (story points, source lines of code, hours, pages, person-hours) early so that they are more prepared to do so after graduating and entering the workforce.

The need for documentation is something that can be addressed from both the perspective of the professor and the perspective of the students. The Lean approaches tell us that documentation that doesn't add value to either the team or the customer is wasteful (in terms of time and cost). However, some documentation is needed to achieve some objectives of both the students and the professor (the customer/client) for various purposes. Overall, it sounds like an opportunity to teach process tailoring and quantitative project management (which does have a role even in agile methods).

With respect to Scrum meetings and scheduling, there are two ideas that come to my mind. The first is that this indicates that Scrum might not be the best process to use in an academic setting. There is no singular "best process model" for software projects, with factors such as schedule, staffing, visibility, and experience of the development team (among others).

Overall, I'd suggest emphasizing good practices, process tailoring, and process improvement over single methodologies. This will let you be the most effective to everyone taking the courses, and expose them to a variety of process methodologies and understand what the best practices are for a given set of conditions.

---

Since you're working to build a university curriculum, I'll give a high level overview of how the software engineering curriculum at the university I attended fit together.

The was an introductory software engineering went through the project in a waterfall model, with the lectures during each phase corresponding to different ways to conduct the activities of that phase. The teams progressed through the phases at the same rate. Having those clearly defined boundaries made fit well into the teaching model for a group of people with no to minimal experience working on teams to build software. Throughout the course, references were made to other methodologies - various agile methods (Scrum, XP), Rational Unified Process, Spiral Model - with regards to how their advantages and disadvantages.

In terms of the activities, there were specific courses to discuss requirements engineering, architecture and design (two courses - one focusing on detailed design using object-oriented methods and one focusing on system architecture), a number of courses focusing on designing and implementing various classes of systems (real-time and embedded systems, enterprise systems, concurrent systems, distributed systems, and so on), and software testing.

There are also three courses dedicated to software process. Software Engineering Process and Project Management that focuses on best practices for managing a software project with respect to multiple methodologies. A second process course teaches measurements, metrics, and process improvement (emphasizing CMMI, Six Sigma, and Lean). Finally, there's a process course that teaches agile software development (Scrum, Extreme Programming, Crystal, DSDM discussed) using a project carried out using the Scrum methodology.

The capstone project was a two-quarter project that was performed for a sponsoring company and run entirely by the student project team, with guidance from both the sponsors and a faculty advisor. Every aspect of how to conduct the project is up to the students, within any constraints set forth by the sponsors. The only university-mandated deadlines were an interim presentation half way (10 weeks) into the project, a final presentation at the end, and a quad poster presentation shortly before the end. Everything else was up to the sponsor and team to agree to.

Answer 2

When I did my master's in software engineering, there was a course called Software Process that dealt with XP, Scrum and other agile approaches. Essentially, the entire class formed a hypothetical software company and was instructed to develop a piece of fairly elaborate software during the time the course ran. The lectures were about things such as XP practices, doing stand-up meetings, etc.

Most students have heard about these techniques and are usually keen on applying them. Ofcourse there's no way to force the team to actually work iteratively, etc. But that was actually the point of the course: to itself become a motivation for holding lots of short meetings, working iteratively, doing continuous builds, etc. because you quickly discover it's simply the easiest and most reliable way to produce anything of value with a group of people and a small amount of time.

One thing to remember: make sure you play the customer well and change some key requirements halfway through. Or "forget" to mention them initially.

Answer 3

At that point, the course switched to Scrum, with two 3-week sprints. We are now trying to figure out how to eliminate waterfall altogether and create an exclusively Scrum-based curriculum.

Is the purpose to facilitate development, or to learn Scrum, or - my guess - both? I would consider shorter sprints to speed up the learning process.

•Daily Scrum meetings are nearly impossible for students. Even during the class itself, it's inconvenient for students to hold Scrum meetings since the professor is usually lecturing.

Perhaps you can replace daily stand-ups with a less stringent form, when it works best for the students. Also, not everyone needs to participate in every meeting.

•Estimating points/hours is difficult, since students are inexperienced and therefore can't accurately predict how long something will take.

Estimating calendar time is even more difficult, of the same reasons :-) With story points you don't estimate how long something will take: you estimate its relative size. Duration is derived.

•Scrum works best with full-time, co-located developers, but students are neither. At most, students dedicate 15-20 hours per week to the course, and organizing work meetings can be extremely difficult. Teams can have up to 10 students (and there's always one or two slackers).

Maybe try with smaller teams? 10 is on the upper scale for a Scrum team. I think you can succeed with non full-time distributed teams as well, but of course it's harder! Let that be a lesson in itself.

•Professors crave documentation! I haven't heard of any Scrum reports—just the backlogs and burndown charts (which I'm not sure will be enough to appease the academics).

Scrum does not dictate what kind of documentation is required. As a matter of fact, not even burndown charts are mandatory. This does not mean documentation is forbidden: the team should produce the documentation necessary, including the reports professors deem necessary.

•Students often assume that agile means "Jump right in and start coding without looking back". This leads to some of the most horrible code imaginable. Therefore, I'm looking for a way to enforce proper design without requiring a 50-page document or a pile of UML diagrams.

Not only students :-) Most Scrum teams use XP practices such as TDD (Test Driven Development) and refactoring: I propose you incorporate that in the curricula.

Also, is there still value to teaching the waterfall model?

Yes, of two reasons at least: First, it's not certain your students will use Scrum in their work life, and second, I imagine it is easier to understand the essence of agile development if you have something to compare it with.

Answer 4

It sounds a bit similar to a subject I took once.

Some thoughts:

• Would you really have a whole-team scrum meeting? Would subteams work?
• If "without looking back" means no refactoring, then assess evidence of refactoring?
• Assess reflection and documentation - get the students to maintain a blog of their activities. (This is actually a pretty useful skill for the workplace - far more so than most formal documentation)
• If estimates are bad, hopefully they're learning - can they keep track of variations between estimates and reality, reflect on differences, and demonstrate that they've learnt something?
• Are there less formal ways of documenting a design that would be appropriate?
• Would Skype or Gchat or something suffice for some scrum meetings?

Answer 5

My advice is to separate and isolate what you are trying to teach. If it's a course in software design or some other software engineering subject (algorithms or whatnot), focus on that. If involving SCRUM becomes a hindrance (as you hint at) then don't bother with it.

How we did this when I was in college was to have a dedicated course for agile methodologies. The course included a development project that was to be run according to either SCRUM or XP. The actual software that was to be delivered was trivial, as the focus of the course was not programming or design but process. The reasoning here is the same as why you should not mix "hard core" software development subjects with methodology subjects as one tend to eclipse the other and students are mostly not ready or skilled enough to handle both at that stage.

Course deliverables were things like sprint planning reports, weekly progress reports, retrospectives, burndown reports plus each week we had at minimum two sessions that included a group stand-up/scrum meeting where the TAs would circulate and listen in.

This course also included TDD (Test Driven Development) and that worked really well.

Also, is there still value to teaching the waterfall model?

It most certainly is. Many companies use versions of this model for their projects (PPS, RUP, PROPS, etc). Many find (correctly, in my opinion) that "pure" SCRUM is better suited for ongoing maintenance than projects. SCRUM (and Agile in general) requires a certain flexibility in scope and the possibility of negotiating requirements and delivery along the way. Not all projects work like that, they are binary: deliver X at Y point in time, all else is a failure.

Answer 6

The point of an academic Software Engineering course is to teach to fundamental stages of the software lifecycle - analysis, design, implementation, testing together with using actual software quality standards instead of regular homework quality code.

There is value in demonstrating the practice using a non-waterfall process, however, due to the reasons you meantioned SCRUM is not a suitable process - students take many courses per semester, many also have real jobs while studying, therefore you can not have 100% dedicated team members or conduct daily meetings.

Consider using a less-agile iterative process such as UP (RUP) instead.

To show the value compared to the waterfall process, change requirements between iterations. This will show the difference between UP and the waterfall and hint towards the value of using agile processes.

Demonstrating the waterfall after this will be redundant as UP covers all of the waterfall's stages.

Since the semesters are relatively short, 2 small iterations would be realistic.

Provide a broad framework for the students to use, as the emphasis of this course shouldn't be the depth of the implementation, there are other courses for that, instead it should emphasize coding standards and unit testing.

During the course lectures teach the theory of a few processes e.g. waterfall, UP, XP, SCRUM and Kanban (along with other topics e.g. writing requirements, UML, testing and etc.).

For students that completed the above course, consider a separate SCRUM workshop as an elective course which takes a full-time two week period during the summer semester.

Answer 7

Scrum works if you have a term/semester long project and the class is divided into 6 to 10 person groups. Then you could dedicate the last 10 minutes of class time to the scrum meeting.