Clarification of “Why I still teach Scrum”

Teaching Scrum at University is challenging. Students are typically at the beginning of their career and don’t understand the challenges of communication and coordination in software engineering well. In a prior post on Why I Still Teach Scrum I had made a cryptic remark to that end and through various channels was asked to clarify the remark.

Scrum is a framework that needs tailoring for the specific situation at hand. The specific challenges of teaching Scrum at a University are, in no particular order, and most certainly incomplete:

• Comparatively little practical experience of students
• Widely differing capabilities as the gap between students can be large
• Transient teams as Scrum projects typically last only a semester
• Zero-Sum-Thinking by some students as to teamwork and grade

We have adjusted Scrum to fit these and other challenges, and you can read up on some of this on my University blog. It certainly is fun, but can also be laborious. We complicate our situation by involving companies as “customers”, that is, representatives from companies provide the project idea and engage in the typical customer review cycle with the student team.

One of the complaints I get, triggering the original blog post on Why I Still Teach Scrum, is from more experienced students: In their daily work at startups, they don’t see any of the elaborate Scrum processes and practices that I teach them (more or less) straight from the text books. Rather, startups (including my own research group) use a combination of Kanban and Continuous Deployment to close the feedback cycle and steer development. Throw in a strategic product manager (but no technical product manager, that is, no Product Owner), and the disconnect to Scrum proper becomes apparent.

However, as I explained, not everyone is that experienced, and many students benefit greatly from the detailed processes and practices of Scrum, even if it slows down some of the more experienced students.