En mis materias vengo utilizando la Guía Oficial de Scrum pero a partir de dos charlas distintas que tuve con colegas en la última semana he decidido dejar de usarla.
Resulta que una de las modificaciones «recientes» de la guía oficial de Scrum es que elimina los roles. En realidad no elimina los roles conceptualmente, sino que elimina el término «rol» y en su lugar habla de responsabilidades (accountabilities), o sea: «Scrum Master» es un conjunto de responsabilidades, «Product Owner» es un conjunto de responsabilidades, etc. Según me comentaban mis colegas expertos en Scrum (cosa que yo no soy) es para evitar la usual creencia de que las responsabilidades de Scrum Master deben ser tomadas por una única persona y que esa persona debe dedicarse de forma exclusiva a ello. Pero precisamente eso es un rol, «un conjunto de responsabilidades». Entonces si conceptualmente hablamos de roles pero no queremos usar el término roles, creo que lo que se está haciendo es una «precarización» del vocabulario y al mismo tiempo se genera ruido y confusión para aquellos que sabemos lo que es un rol.
Por otro lado tengo la sensación que la guía cada vez tiene menos cuestiones relacionadas al desarrollo de software, posiblemente consecuencia del uso de Agile/Scrum fuera de contexto de IT. Pero dado que lo que estudiamos en mi materias es desarrollo de software, estas nuevas versiones de la Guía de Scrum, me resultan cada vez menos útiles.
Es por esto que de ahora en más ya no usaré la guía oficial de Scrum como material de estudio sino (algunos de) los siguientes materiales:
- El artículo «Scrum Development Process» de Ken Schwaber de los años 90
- El libro «Scrum and XP from the treches» de Henrik Kniberg
- El resumen de Scrum de mi libro «Construcción de Software»
Blog de NicoPaez 
Gracias Nico por compartir estas cuestiones en tu blog.
Me parece muy pertinente este artículo y más aún la foto que lo acompaña (no sé si la elección de los elefantes es intencional o no, pero me parece adecuada).
Hace mucho que me resisto a las guías «oficiales» tan prescriptivas (cuando escribíamos nuestro libro lo dije varias veces), pero a mi juicio la Guía de Scrum de 2013 era una buena guía. Creo que a partir de allí, fue derivando en algo que a nosotros, que enseñamos Gestión del desarrollo de software (a lo sumo gestión del desarrollo de sistemas ciberfísicos, es decir, sistemas de hardware-software con el software guiando el resto del desarrollo), nos sirve cada vez menos. No digo que esté mal: al fin y al cabo, si Schwaber y Beedle quieren que Scrum vaya por ese camino, no soy yo quién para decirles que está mal. Sólo digo que me sirve cada vez menos, y en eso coincidimos…
Yo sigo dándole a leer a mis estudiantes la Guía de 2013, lo cual genera preguntas interesantes de responder (obvio que preguntan mucho por qué usamos una guía «vieja» habiendo versiones más recientes).
Quise decir Schwaber y Sutherland, perdón
Quiero agradecer al autor de este blog por compartir información tan valiosa sobre la ingeniería de software. Es un campo que realmente está en constante evolución y tiene un impacto significativo en nuestra vida diaria.
Me gustaría añadir que, además de las habilidades técnicas, la ingeniería de software también requiere una fuerte capacidad de colaboración y comunicación. Trabajar en equipo es fundamental para desarrollar soluciones efectivas y adaptarse a los cambios rápidos del mercado. ¡Gracias de nuevo por este espacio tan inspirador!