El bloc de notas de un Agilista Jedi

Regresar Scrum

El primer libro de Scrum del mundo

26 de abril de 2023

El primer libro de Scrum del mundo

“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”. Así es como introducen Ken Schwaber y Mike Beedle por primera vez el evento Daily Scrum en el libro “Agile Software Development with Scrum”, el cual fue el primer libro escrito en la historia de la humanidad sobre el marco de trabajo Scrum, por allá del año 2001.

Hace unos días estuve releyendo el libro “Agile Software Development with Scrum” (Desarrollo de Software con Scrum), el cual es conocido en el mundo de la Agilidad como “El libro negro de Scrum” por su característica portada. Es una joya histórica por ser el primero de miles y miles y miles de libros que se han escrito sobre Scrum a lo largo y ancho del mundo.

¿Te ha pasado alguna vez que una película o canción que “te gustaba mil” cuando eras adolescente, cuando la ves o escuchas 10-15 años después… como que ya no “conecta” contigo?

De igual manera, cada que leemos de nueva cuenta un libro lo vemos con una perspectiva distinta, puesto que somos una persona “diferente” de cuando lo leímos por primera vez (nuevas experiencias de vida nos han llevado a nuevos modelos mentales, nuevos paradigmas, nueva ideología, nuevas prioridades, etcétera).

En este caso, después de releer “El libro negro de Scrum” no puede ser más cierto que lo veo desde una perspectiva distinta, no solo porque yo he evolucionado como persona… sino que Scrum, como marco de trabajo, también ha evolucionado (a verdaderos pasos agigantados) desde que lo presentaron al mundo oficialmente en 1995 sus co-creadores Jeff Sutherland y Ken Schwaber (quien es, por cierto, uno de los co-autores de este libro).

Aquí te comparto varias ideas sobre Scrum tal como fueron concebidas originalmente, así como una comparativa con el enfoque actual. Lo interesante es que, si lo vemos con las gafas o lentes de hoy, a 21 años de la publicación de este libro, muchas de sus ideas pueden considerarse como disfuncionales o incluso antipatrones… Entonces, ¿está mal el libro? ¡Nada de eso!, solo recordemos que estamos en la “tierra del empirismo”, debemos de crear para enseguida inspeccionar y adaptar. Así que el hecho de que Scrum haya evolucionado de la manera que lo ha hecho (y lo seguirá haciendo), es una muestra clara del empirismo aplicado a su máximo potencial. ¡Poderosísimo!

Sin más rollos, aquí van algunas de estas comparativa de ideas acerca del “Scrum del primer libro” y el enfoque actual:

1. El Daily Scrum es una junta de estatus… que solo debe de llevar ¡el Scrum Master!

1.1 “El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”
1.2 “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum. El Scrum Master mantiene el Daily Scrum breve, hace cumplir las reglas asegurándose de que las personas hablen brevemente.”

Si un Scrum Master llegara este 2023 al evento internacional Scrum Day y dijera que el evento Daily Scrum es una junta de estatus, una muchedumbre con antorchas y trinchetes lo acusaría de anti-Agilista.

Imagen de WikiSimpsons (https://simpsons.fandom.com/es/wiki/Turba_furiosa)

Me sorprendió ver que al Daily Scrum se le concibió inicialmente como una junta de estatus. Todo esto ha evolucionado, actualmente el Daily (así se le conoce en el medio, Daily “a secas”) no es para entregar estatus, tiene como propósito generar transparencia, que en equipo se inspeccione el progreso hacia el Objetivo del Sprint y adaptar según sea necesario.

Respecto a la segunda idea del libro, “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum”, la evolución nos ha llevado a buscar el enfoque en la autogestión del equipo, es decir, que sean capaces de gestionarse sin necesidad de que un Scrum Master lo haga por ellos, por esto actualmente el Daily es un evento de los Desarrolladores para los Desarrolladores, ellos mismos inspeccionan su progreso hacia el ya mencionado Objetivo del Sprint, el Scrum Master no dirige la sesión, y, de hecho, puede no asistir y el evento no se detiene.

2. No es un Marco de Trabajo o Framework… es un ¿Método?

En la introducción del libro, Mike Beedle (co-autor) menciona: “Tuve la buena fortuna de leer un mensaje de Jeff Sutherland y reconocer que era de hecho información muy importante. Él anunció que junto con Ken Schwaber estuvieron trabajando en un método llamado Scrum

Este punto me llamó mucho la atención, pues es añejo el debate sobre Scrum sobre si es un Framework y por qué no es una Metodología, pero antes de este libro nunca había visto que lo llamaran método.

Para aquellos que ya conocen Scrum, disculpen que lo vuelva a mencionar, pero siempre partimos de aclarar que Scrum es un Marco de Trabajo o Framework, pues proporciona una serie de eventos y artefactos con los que se debe de trabajar, indicando 3 roles (Scrum Master, Product Owner y Desarrolladores), con esto se identifican los resultados que se desean obtener, pero no entra en ningún tipo de detalle sobre la manera en que esto debe de hacerse, es decir, deja “espacio abierto” a los propios equipos para sean ellos quienes decidan la mejor manera de hacer esto, el “cómo” hacerlo, en su contexto particular.

Eso es un Framework, en tanto que un Método es un modo ordenado y sistemático de actuar o proceder para llegar a un resultado o fin determinado. Siendo muy simplistas podemos decir que es un procedimiento que se sigue para conseguir un objetivo. Un Framework deja más espacio a que las personas definan la manera de hacer las cosas, fomenta la experimentación y el empirismo, pues solo es una base para resolver un tipo de situaciones.

3. Enfoque en Proyectos y más Proyectos

3.1 “Cada proyecto es diferente […] Diversas tácticas ayudan, pero sin Scrum esos proyectos fueron eventualmente abrumados por la complejidad inherente en proyectos de desarrollo de sistemas”
3.2 “La gerencia debe de negociar de las cuatro variables [costo, fecha, funcionalidad y calidad] con los clientes “

Es oficial: Scrum inició como un enfoque para gestionar proyectos de manera ágil. Esto ha evolucionado en el último par de décadas y el enfoque actual no es hacer proyectos, sino productos. Esto quizá pueda sonar contradictorio, pues un producto puede ser el entregable que se genera al finalizar un proyecto, un resultado único. Esto es cierto, vivimos en un mundo de proyectos, pero la enorme diferencia es el enfoque… un proyecto se centra en entregar “algo” dentro del tiempo, costo y alcance definido, en tanto que, desde la perspectiva de producto, nos centramos en el impacto que este “algo” que entregamos produce para el usuario final. Buscamos construir productos que resuelvan algún problema del usuario/cliente, que hagan su vida más fácil. Un producto define su éxito en base al V-A-L-O-R que proporciona.

P.D. #1

Personalmente siempre he creído que debemos de ir un paso más allá… un producto que resuelva un problema lo puede hacer cualquiera, debemos enfocarnos en ¡crear productos que enamoren!

Estas son solo algunas de las ideas del “Scrum del primer libro” que plantean Schwaber y Beedle, la verdad es que hay mucha tela de la cual cortar. Es de esos temas profundos que dan para largas conversaciones acompañadas de un buen café, té, mate o la bebida de tu predilección (en mi caso, me inclino por el té verde). Por esto, y para no hacer un artículo tan extenso, en una próxima entrada de Blog continuaré con la segunda parte de “El primer libro de Scrum del mundo”. ¡Nos vemos en el capítulo 2!

P.D. #2
Mike Beedle (1962-2018), co-autor de este libro y firmante original del Manifiesto Ágil, fue mi primer maestro de Scrum. Con él tuve el enorme gusto de tomar mi primer curso de Scrum por allá del año 2014, una experiencia súper chévere!

Pero, por favor cuéntanos: ¿Conocías la esencia original de Scrum? ¿Qué opinas sobre la forma en que Scrum ha evolucionado? ¿Qué te pareció?


autor

Leonel Zapien
Apasionado de la Agilidad: Consultor & Facilitador.

Conoce más sobre mí

Comparte este articulo

Seguir leyendo sobre Scrum