Eu hesitaria em descartar o Waterfall de maneira tão rápida.
Embora seja um modelo defeituoso para a construção de sistemas de software, não é um mau modelo de ensino instruir sobre boas práticas para cada estágio do ciclo de vida. Independentemente do modelo de processo aplicado ao projeto, você ainda executa a engenharia de requisitos, a arquitetura e o design do sistema, a implementação, o teste, a liberação e a manutenção (incluindo refatoração e aprimoramento). A diferença é como essas fases são organizadas e conduzidas, mas todas as atividades ainda acontecem.
Eu diria que sua transição de Waterfall para Scrum no meio do projeto não é a melhor idéia. Uma chave para o sucesso do Scrum é um projeto de longa duração. Os primeiros três a cinco sprints são a equipe que decide a velocidade, aprende o processo e passa pelo desenvolvimento da equipe. Embora você esteja fazendo os movimentos, não é realmente o Scrum nesse ponto. Além disso, tentar criar um currículo exclusivamente baseado em Scrum é provavelmente uma má idéia, pois o Scrum não é uma bala de prata - é melhor ensinar as melhores práticas do que uma única metodologia. Na força de trabalho, nem todos os projetos vão usar o Scrum. De fato, em alguns ambientes, o Scrum seria prejudicial ao sucesso do projeto.
Você já encontrou problemas com o Scrum em um ambiente acadêmico, e alguns deles são difíceis de resolver adequadamente.
O não problema em sua lista de incompatibilidades é que a estimativa é difícil. Sim, ele é. Mas a única maneira de melhorar a estimativa é estimar e comparar dados reais com estimativas. Os alunos devem estimar tamanho, tempo e esforço usando vários meios (histórias, linhas de código-fonte, horas, páginas, horas-pessoa) com antecedência, para que estejam mais preparados para fazer isso depois de se formarem e ingressarem na força de trabalho.
A necessidade de documentação é algo que pode ser abordado tanto da perspectiva do professor quanto da perspectiva dos alunos. As abordagens Lean nos dizem que a documentação que não agrega valor à equipe ou ao cliente é um desperdício (em termos de tempo e custo). No entanto, é necessária alguma documentação para atingir alguns objetivos, tanto do aluno quanto do professor (cliente / cliente), para diversos fins. No geral, parece uma oportunidade para ensinar alfaiataria de processos e gerenciamento quantitativo de projetos (que também desempenham um papel nos métodos ágeis).
Com relação às reuniões e agendamento do Scrum, há duas idéias que me vêm à mente. A primeira é que isso indica que o Scrum pode não ser o melhor processo para uso em um ambiente acadêmico. Não existe um "melhor modelo de processo" singular para projetos de software, com fatores como cronograma, equipe, visibilidade e experiência da equipe de desenvolvimento (entre outros).
No geral, eu sugiro enfatizar boas práticas, adaptação de processos e melhoria de processos por meio de metodologias únicas. Isso permitirá que você seja o mais eficaz para todos os participantes dos cursos e os exponha a uma variedade de metodologias de processo e entenderá quais são as melhores práticas para um determinado conjunto de condições.
Como você está trabalhando para criar um currículo universitário, darei uma visão geral de alto nível de como o currículo de engenharia de software da universidade em que participei se encaixou.
Foi uma engenharia de software introdutória que passou pelo projeto em um modelo em cascata, com as palestras durante cada fase correspondendo a diferentes maneiras de conduzir as atividades daquela fase. As equipes progrediram nas fases na mesma proporção. Ter esses limites claramente definidos se encaixou bem no modelo de ensino para um grupo de pessoas sem experiência mínima trabalhando em equipes para criar software. Ao longo do curso, foram feitas referências a outras metodologias - vários métodos ágeis (Scrum, XP), Rational Unified Process, Spiral Model - com relação a suas vantagens e desvantagens.
Em termos de atividades, houve cursos específicos para discutir engenharia de requisitos, arquitetura e design (dois cursos - um focado no design detalhado usando métodos orientados a objetos e outro focado na arquitetura do sistema), vários cursos focados no design e implementação de vários classes de sistemas (sistemas embarcados e em tempo real, sistemas corporativos, sistemas concorrentes, sistemas distribuídos etc.) e testes de software.
Existem também três cursos dedicados ao processo de software. Gerenciamento de processos e projetos de engenharia de software, focado nas melhores práticas para gerenciar um projeto de software com relação a várias metodologias. Um segundo curso de processo ensina medições, métricas e melhoria de processos (enfatizando CMMI, Six Sigma e Lean). Finalmente, existe um curso de processo que ensina o desenvolvimento ágil de software (Scrum, Extreme Programming, Crystal, DSDM discutido) usando um projeto realizado usando a metodologia Scrum.
O projeto capstone era um projeto de dois quartos que foi realizado para uma empresa patrocinadora e executado inteiramente pela equipe do projeto do aluno, com orientação dos patrocinadores e de um orientador do corpo docente. Todos os aspectos de como conduzir o projeto são com os alunos, dentro de quaisquer restrições estabelecidas pelos patrocinadores. Os únicos prazos estabelecidos pela universidade eram uma apresentação intermediária a meio caminho (10 semanas) do projeto, uma apresentação final no final e uma apresentação em pôster em quadriciclo pouco antes do final. Todo o resto dependia do patrocinador e da equipe.