Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo

“Nadie debería pasar su vida en un trabajo sin sentido”

Esta fue la primera oración que subrayé en el último libro del co-creador de Scrum, Jeff Sutherland, Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo. Esta simple oración habla de la razón fundamental por la que Scrum existe y sirve como la razón de ser para iniciar Scrum en tu organización: Nadie debe dedicar su vida a un trabajo sin sentido. Para aquellos que no están familiarizados con Scrum, este libro ofrece un argumento poderoso y persuasivo sobre la necesidad del cambio en términos sencillos y sin mucha jerga técnica. Para aquellos ya con experiencia con Scrum, este libro reavivará el sentido de propósito y dará una apreciación más profunda de la historia y los orígenes de Scrum.

El libro se organiza aproximadamente en tres secciones: Los orígenes de Scrum, las discusiones sobre los elementos clave de Scrum que hacen que Scrum funcione y los capítulos que ilustran por que las cosas deben cambiar en los negocios (y en el mundo en general). Ya que este libro no es el libro típico sobre Scrum, enfocaré mi revisión de las ideas que saqué al leerlo.

En el capítulo “Orígenes de Scrum”, fue interesante descubrir que una de las primeras inspiraciones de Scrum provino de la investigación de Rodney Brooks en el MIT y su creación de robots autónomos de seis patas. En su investigación, el Dr. Brooks no desarrolló un solo cerebro que coordinara el movimiento de las patas del robot. En su lugar, el Dr. Brooks y su equipo integraron reglas simples dentro de cada pierna y los robots, parecidos a insectos, tuvieron que aprender a caminar y navegar por el edificio a través de prueba y error. Cuando se encendía el robot, cada pata intentaba hacer su misión con resultados predecibles: no ir a ninguna parte, moverse con dificultades y deambular un poco. A través de un proceso de inspección y adaptación, las piernas aprendería como coordinar su movimiento paso a paso y comenzar a actuar como una sola unidad. Esta observación hizo que Jeff Sutherland realizara esta pregunta:

“¿Qué pasaría si pudiéramos crear un conjunto de instrucciones simples para que equipos de personas trabajen juntos como esas piernas?”

Cuando leí esta historia, me inspiré a pensar cómo escalar Scrum se parece mucho a los robots de seis patas que aprenden a caminar. Por su diseño, Scrum no tiene un marco de escalado, ya que las reglas básicas de escalamiento de Scrum están integradas dentro de Scrum. Los equipos autónomos, capacitados, proporcionan valor a cada Sprint mientras buscan formas de mejorar continuamente. Esta es la razón por la cual LeSS es tan convincente que se enfoca en permitir que esta mejora continua ocurra en una gran empresa. Poco a poco, a través del proceso de inspección y adaptación, múltiples equipos de Scrum aprenden cómo coordinar sus acciones y mejorar la entrega del producto. No se necesita un cerebro central para dirigir todo, solo un árbitro para recordar a las partes individuales lo que han aprendido colectivamente. Entonces, ¿Por qué tantos esfuerzos de escalado dependen de un solo cerebro para dirigir todo en un gran proyecto? En mi opinión, no confían en los equipos que hacen el trabajo y piensan que dirigir todo desde una fuente central es claramente más eficiente.

En el capítulo “Equipos”, Jeff comparte la definición de “Scrum Team” tomada directamente del artículo original de Takeuchi y Nonaka, “The New New Product Development Game“. De acuerdo con las investigaciones de Takeuchi y Nonaka, los mejores equipos de productos son trascendentes (un sentido de propósito más allá de lo ordinario), autónomos (autoorganizados, autogestionados y con el poder de tomar sus propias decisiones) y multifuncionales (todas las habilidades necesarias) para completar el proyecto. Entonces, ¿Cómo creamos un Scrum Team? Son multifuncionales, tienen una visión audaz y tienen tiempo y espacio para autoorganizarse en torno a la solución. ¿Por qué funciona esto? ¡Porque la investigación muestra que esto es más efectivo!

Lo más interesante en este capítulo fue la investigación que Jeff cita sobre el desempeño de los equipos. Es bien sabido en la industria del software que existe una diferencia de 10: 1 en la productividad entre los mejores contribuyentes y los peores. ¡Lo que Jeff señala es que la investigación muestra que hay una diferencia de 2000: 1 en la productividad entre los mejores equipos y los peores equipos! ¿Y por qué vemos tal diferencia en la productividad del equipo? Se debe a un sistema roto que les pide que realicen un trabajo sin sentido, les roba su autonomía y les pide que acepten la mediocridad en lugar de la grandeza.

El capítulo sobre “Felicidad” invita mucho a la reflexión. Muchos de los libros de Scrum tienen capítulos sobre los atrasos de productos, planificación, ScrumMasters, Product Owners, estimaciones, historias de usuarios, pero ¿Cuándo fue la última vez que un libro sobre Scrum incluía el tema de la felicidad? Este es el primer libro que he visto que dice que un equipo de Scrum debe centrarse en la felicidad. ¿Por qué? Porque la felicidad precede a los resultados importantes y es un indicador de prosperidad [resultados comerciales]. En su propio trabajo, Jeff ha observado que la productividad se triplica al centrarse simplemente en mejorar la felicidad de su personal. Jeff encontró que esta métrica de la felicidad es un indicador importante de los aumentos (o disminución) de la productividad.

¿Quieres probar tu propia métrica de felicidad para validar el experimento de Jeff? Estas son las cuatro preguntas de Jeff que hace durante cada retrospectiva:

En una escala de 1 a 5, ¿Cómo te sientes acerca de tu papel en la empresa?
En una escala del 1 al 5, ¿Cómo te sientes acerca de la compañía en general?
¿Por qué te sientes asi?
¿Qué cosa te haría más feliz en el próximo Sprint?

Ningún libro sobre Scrum puede evitar los temas de estimación y planificación, y Jeff pasa el tiempo repasando los conceptos básicos del capítulo titulado “Plan Reality Not Fantasy“. Para las personas experimentadas con Scrum, este capítulo es una revisión sencilla de historias de usuarios, estimaciones relativas, planificación poker, velocidad y conceptos relacionados. Para las personas que no saben mucho acerca de Scrum, esta es una excelente manera de introducir temas de planificación y estimación sin toda la jerga técnica. Lo que me llamó la atención en este capítulo fue la historia sobre la necesidad de enfrentarse la realidad de un proyecto en peligro.

El CEO de una empresa que cotiza en bolsa comprometió el negocio con un objetivo ambicioso que, de no cumplirse, tendría graves repercusiones en el precio de las acciones de la empresa y permitiría a los competidores introducirse más en al mercado. Este es uno de esos objetivos en los que la fecha podría moverse y la ejecución habría que ser impecable. Desafortunadamente, cuando Jeff llegó a escena, esta compañía había pasado seis meses de valioso tiempo planeando todo el esfuerzo y se dio cuenta de que iban a llegar un año tarde. Además de la complejidad del esfuerzo, había siete grupos distintos dentro de esta compañía, cada uno de ellos era dueño de una parte del sistema que se estaba desarrollando, un sistema complejo que tenía que funcionar perfectamente, y nadie quería hacer nada de manera diferente. Ah, y él tenía un documento de requisitos de miles de páginas y dos pies de altura sobre la mesa de conferencias.

Entonces, ¿Qué hizo Jeff? Les dio a todos tijeras, cinta adhesiva y les dijo que eliminaran todos los requisitos que debían cumplir para cumplir con el objetivo del CEO. Una vez que se completó, estas pequeñas tiras de papel se pegaron en la pared. Quiero adivinar cuánto quedaba en la mesa: el cincuenta por ciento del papel. ¡El cincuenta por ciento del documento de requisitos de dos pies estaba lleno de palabras basura, cosas que la gente nunca estaba lista y requisitos innecesarios! Imagínese si hubieran pasado tres meses anotando el cincuenta por ciento que realmente necesitaban y pasaron los otros tres meses validando sus suposiciones con pruebas de conceptos y desechando el código. Debe leer el resto del libro para ver cómo se salvó este proyecto.

En mi opinión, los capítulos “The Way the World Works is Broken“, “Waste is a Crime” y “Change the World” son los más inspiradores y convincentes. Hay un elemento que quiero resaltar del capítulo “Waste is a Crime” sobre el que no hablamos mucho en software, pero tiene un gran impacto en los equipos: Los imbéciles. Jeff define a un imbécil “como alguien a quien le gusta marear a otras personas y ponerlas nerviosas”. Crean una gran cantidad de residuos emocionales. En su opinión, estas personas están “simplemente complaciendo los aspectos negativos de su personalidad” e impactan seriamente el rendimiento del equipo. Jeff no tiene tolerancia con los idiotas y yo tampoco. Confrontar a estas personas es un trabajo duro y no puedo ofrecer respuestas fáciles para lidiar con los imbéciles. Mi única sugerencia es utilizar habilidades de conversaciones cruciales y ser firme en como deseas que cambie el comportamiento.