Resumen Scrum

Resumen Scrum by Jeff Sutherland


Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había recomendado mucha gente. Y no me he arrepentido.

Es una gozada leer la esencia de Scrum, sus principios y valores, explicados de la mano de uno de sus autores, Jeff Sutherland. Leer cómo se gestó, y por qué está contruido de esa manera. Y no solo quedarse en la teoría, sino dar ejemplos concretos de casos de éxito, en el software y fuera de él.

Tanto si no tienes ni idea de Scrum como si llevas tiempo en el mundillo Agile, su lectura te sorprenderá y te ayudará.

Si todavía no tienes el libro y quieres comprarlo, puedes hacerlo en el siguiente enlace de afiliados. A ti no te costará más y me ayudarás a mantener este blog.

A continuación te dejo mi resumen “Scrum. The Art of Doing Twice the Work in Half the Time”.

Scrum libro Jeff Sutherland

1.Cómo trabaja el mundo no funciona

FBI, proyecto Sentinel, primer intento con waterfall, 170M$ en 3 años, proyecto se para.

Segundo intento con waterfall, presupuesto de 450M$ y 4 años, tras 5 años y 400M$ invertidos y el proyecto al 50%, se adopta Scrum.

“Lo más poderoso de Scrum es el feedback en las reviews”

En 2 años y con la mitad del equipo se puso en marcha para todo el personal con éxito. Hoy todavía sigue el equipo, añadiendo funcionalidad con Scrum.

2.Origen de Scrum

Equipos o personas son sistemas complejos. Para cambiarlos es necesario inyectar energía cuando se encuentran en un estado estable. Tras un tiempo de caos, el sistema vuelve a un nuevo estado estable.

Como los robots, para coordinar N cabezas pensantes lo mejor es darles un conjunto limitado de reglas y feedback continuo.

Sutherland en Eisel, en su búsqueda de una mejor forma de desarrollar software, da con un paper de Takeuchi y Nonaka llamado “the new new product development game”. En él apunta a una nueva manera de hacer producto más eficaz, dando autonomía y propósito a los equipos, los managers actuando sin decir qué hacer sino eliminando impedimentos.

SCRUM se basa en algo que inventó Demming (estadounidense) y que desarrollaron los japoneses, el ciclo PDCA, y que mejora cualquier proceso ostensiblemente en unos pocos ciclos.

La forma de aprender SCRUM es parecida a la de las artes marciales. Shu-Ha-Ri:

  • Shu: Repites movimientos (forma) para interiorizarlos
  • Ha: Introduces variaciones propias
  • Ri: Abandonas la forma, has interiorizado la esencia

3.Equipos

Características de un equipo de alto rendimiento son:

  • Tienen propósito
  • Son autónomos y autoorganizados, management marca las metas y objetivos pero es el equipo el que decide cómo
  • Son multidisciplinares. Se necesita una comunicación efectiva entre todos de toda la información para minimizar las trasferencias

Para construir un equipo así son necesarias transparencia y mejora continua. La transparencia a menudo va en contra de los intereses individuales de los managers, ya que la información les da poder. Priorizan su propio interés y a corto plazo.

Los equipos debe ser pequeños, 7+-2. Ley de Brooks, si añades más gente a un proyecto retrasado lo retrasarás más. Esto es debido al tiempo que tardan en coger velocidad y al número de comunicaciones que deben existir (n×(n-1))÷2.

Scrum Master (no manager, sí líder servil y coach) tiene 3 funciones esenciales:

  1. Facilitar las sesiones de Scrum
  2. Asegurar la transparencia
  3. Eliminar lo que frena al equipo

El Scrum Master es responsable junto al equipo de la productividad.

Resumen Scrum Roles

Error fundamental de atribución: Sesgo por el cuál juzgamos a los demás como víctimas de su carácter y emociones y a nosotros en cambio como víctimas del entorno y de las circunstancias. Ej. Milgram demostró que cualquiera sucumbe a la autoridad incluso para torturar a otras personas, como es otra persona la que ordena no nos hacemos responsables y culpamos a los demás. Ej: En una fábrica de coches con empleados saboteando la producción cambiaron la directiva y la forma de dirigir a los mismos trabajadores y la productividad se disparó. Hacemos lo que hacemos por el sistema donde nos encontramos, Scrum lo que propone es no culpar a los individuos y mejorar constantemente el sistema.

4.Tiempo

Respetar los timebox, generan ritmo. Sprint = timebox de 2 semanas donde el equipo se compromete a hacer algo en 2 semanas y nadie de fuera del equipo varía ese compromiso.

Daily Standup = timebox diario donde el equipo responde que hizo ayer, que hará hoy y que obstáculos tienen. El objetivo es que todos sepan si se completarán las tareas a tiempo y si hay oportunidad de ayudar a un compañero con algún obstáculo. Cuanto más sabe la gente lo que hace el resto mejor va el equipo. Para ello la comunicación debe fluir y no tener especialistas ni títulos en el equipo.

Resumen Scrum Daily Standup

Las reglas del Daily Standup:

  • Debe estar todo el equipo
  • No puede durar más de 15 minutos, si hay algo que deba discutirse se anota y se habla inmediatamente después
  • Todo el equipo participa

No debe ser un reporting, debe ser una conversación sobre cómo avanzar en las tareas.

Ejemplo de aplicar Scrum en remodelar una casa entera con una cuadrilla de trabajadores. Resultado, con Scrum la mitad de tiempo en hacer el mismo trabajo que de la manera tradicional.

Con Scrum el tiempo pasa de ser lineal a ser cíclico.

5.El desperdicio es un crimen

Scrum genera ritmo. El ritmo es algo natural al ser humano.

La mayoría de nuestro trabajo es desperdicio, no produce resultados (hasta un 85%).

3 tipos de desperdicio (Taichi Ono):

  1. Muri, desperdicio de lo no razonable. Estudios demuestran que no podemos pensar en 2 cosas a la vez, ej. conducir y hablar por el móvil. Al paralelizar proyectos aumentamos el desperdicio por los cambios de contexto. Los proyectos son más costosos, se entregan más tarde y con menos calidad. Ejercicio de escribir números del 1 al 10 en números árabes, romanos y letras de la A a la L, 1° en filas y después en columnas (en columnas la mitad de tiempo aprox.).
  2. Mura, desperdicio a través de la inconsistencia. Huimos de las tareas a medias (work in progress) o del producto que aún no se usará (inventario).
  3. Muda, desperdicio a través de los resultados. Hacer las cosas bien y a la primera. Si se detecta algún bug corregirlo tan pronto se detecta (experimento demostró que se tarda 24 veces más si lo dejas para días más tarde). Ejemplo de Toyota vs Mercedes o BMW, el 1°tarda 1/3 parte y con 1/4 de los fallos ya que cualquiera puede parar la línea y corregir vs tener testers.

Hacer más horas de lo normal es contraproducente, reduce la productividad, la calidad y la capacidad de tomar buenas decisiones.

Resumen Scrum Paralelizar Proyectos

6.Planifica realidad, no fantasía

Caso de Medco, el CEO anunció a Wall Street que tendrían un sistema para servir prescripciones por mail en una fecha. Tras 6 meses de análisis se dan cuenta de que en el mejor de los casos acaban un año más tarde.

Jeff mete a todos los involucrados en una sala con la documentación impresa y les pide que recorten los trozos de documentación que tengan las cosas que realmente hay que hacer (aportan valor). Después les pide que las estimen. En menos de un día tienen una idea clara de lo que tienen que hacer. También escriben lo que debe cumplir para que cada tarea se considere finalizada (Definition of Done). Finalmente decidir qué debía hacerse primero (priorizar por valor). Ahora ya podían empezar a trabajar.

A medida que el proyecto avanza puedes cambiar el plan, por ejemplo eliminando elementos del final de la lista (ordenada por prioridad).

Somos realmente malos estimando tiempo, pero somos muy buenos comparando tamaño. Para estimar asignamos puntos historia, números de una secuencia de Fibonacci, 1,2,3,5,8,13… El cerebro no puede percibir con exactitud diferencias más pequeñas entre medidas. Además es más fácil crear consenso con esas diferencias grandes. Mejor consenso que precisión.

Planning poker: Cada uno elige la carta con el número de la secuencia que mejor representa su estimación. Si las estimaciones son cercanas se hace la media. Si son lejanas los que han elegido la menor y mayor puntuación comparten sus razones y vuelven todos a puntuar.

2 factores más a tener en cuenta al estimar:

  • El efecto de arrastre o cascada de información es el hecho de obviar tus propias razones cuando ves que todo el mundo piensa lo contrario, te “subes al carro”.
  • El efecto halo hace que percibas mejor una cualidad de algo o alguien por el hecho de tener otra cualidad no relacionada muy desarrollada. Ejemplo, creer que alguien es experto en algo porque comunica muy bien.

Las tareas no son solamente tareas, son historias. Debemos saber a quién estamos aportando valor y para qué, cuál es el propósito y la motivación para hacer un buen trabajo.

Las historias deben estar Ready y saber cuándo estarán Done. Una regla conocida para el Ready es INVEST: Independiente, Negociable, con Valor, Estimable, Pequeña y Testable. La velocidad se multiplica por 2 si las historias están Ready y por 4 si al final se cumple el Done.

Para planificar fechas primero debes conocer tu velocidad = puntos por sprint.

En Medco, pidieron 3 Sprints para conocer la velocidad y los impedimentos que habían. En una semana los 3 principales impedimentos se habían eliminado y la velocidad disparada más de un 400%. Tras eliminar backlog y eliminar los impedimentos más culturales se llegó a la fecha.

7.Felicidad

Los escaladores no solo son felices cuando consiguen la cima, también durante el camino, aunque estén al borde de la muerte. Hay que celebrar los pequeños logros y cuidar la felicidad de la gente, y la primera que debemos analizar es la nuestra.

La gente más feliz es más exitosa. La felicidad precede al éxito.

El momento de medir la felicidad es en la retrospectiva. En la retro el equipo analiza cómo ha ido el sprint con el único fin de mejorar, no de acusar. Para que ello se produzca necesitamos un ambiente positivo y de confianza. Buscamos dentro del equipo pero no culpables, sino oportunidades de mejora.

Happiness metric, ejercicio en la retro donde el equipo responde:

  1. Del 1 al 5 ¿cómo te sientes sobre tu rol en la compañía?
  2. ¿Ídem sobre la compañía en general?
  3. ¿Por qué te sientes así?
  4. ¿Qué haría que el siguiente sprint fueras más feliz?

Tras compartir con todos las respuestas, encontrar lo que más impacto tendría y planificarlo para el siguiente sprint.

La transparencia precede a la motivación. En Scrum todo el mundo puede ir a un daily o review, los indicadores y backlogs son públicos, etc.

Otros pilares son la cooperación y la comunicación.

En Zappos, cuyo lema es “entregando felicidad” tienen claro que si quieren clientes felices deben tener empleados felices. Lo inyectan en su cultura corporativa por ejemplo con un boot camp de 4 semanas que todo empleado pasa al entrar en la compañía. Las conexiones que se producen en ese boot camp se mantienen durante años.

La felicidad debe ser en el presente y en el futuro, es decir, debemos asegurar que estamos bien ahora pero también garantizar que seguiremos estando bien más adelante.

Felicidad no es complacencia, sino sentirse realizado mediante un trabajo bien hecho. La complacencia y el desdén no caben en la cultura de Scrum, y debe eliminarse rápido para no contaminar al resto. El feedback debe ser rápido y directo. La medida de felicidad debe estar conectada con la medida del éxito.

Especial cuidado con los equipos que tras mejorar con Scrum llegan a una burbuja de felicidad de la que no quieren escapar, y dejan de experimentar y de mejorar. Es muy común y hay que evitarlo, la mejora continua es continua.

Para evitarlo o combatirlo, el Scrum Master debe continuamente hacer las preguntas difíciles y sacar la verdad de los resultados a flote.

8.Prioridades

El Product Owner debe crear y mantener la visión de producto:

  • Qué puedes construir
  • Qué puedes vender
  • Qué te apasiona

El backlog de producto debe reflejar esa visión. En él estará la lista completa de funcionalidades, pero ordenada por lo que tiene mayor valor y menos coste primero.

El encargado de crear el backlog y de identificar valor es el PO. El PO representa a los clientes, entiende lo que necesitan y es capaz de transmitirlo. Es responsable de traducir la productividad del equipo en valor para el cliente.

Características de un PO:

  1. Debe conocer el dominio, conocer el qué se debe construir.
  2. Debe tener poder de decisión
  3. Debe estar disponible para el equipo
  4. Deben exigirle como resultado crear valor (ejemplo, medir cuánto valor genera por punto historia)

El ciclo del PO es:

  • Observación, desde un punto de vista objetivo, visualizando el todo
  • Orientación, hacia un nuevo estado al que nos queremos mover
  • Decisión, hipótesis de qué hay que hacer para lograr avanzar
  • Acción llevada a cabo, y vuelta a empezar

El PO prioriza dejando arriba el 20% de funcionalidades que da al cliente el 80% del valor. La priorización se va revisando con una frecuencia adecuada, ya que es dinámica. No se puede priorizar todo a la vez.

MVP, Minimum Viable Product: Versión del producto a enseñar a los usuarios lo más pronto posible. No aporta valor todavía , pero nos provee de feedback muy valioso. Este proceso se puede repetir, es iterativo.

Contratos “Money for Nothing, Changes for Free”: El cliente acuerda un alcance y coste, si se quiere cambiar el alcance se cambia siempre y cuando el tamaño del backlog no varíe. Por ejemplo, se puede poner una historia nueva de 20 puntos y eliminar 20 puntos del final del backlog. Si el cliente cree que ya tiene el valor que necesita y decide parar, el proveedor recibe un 20% de lo que queda por terminar.

3 tipos de riesgo:

  1. Riesgo de mercado, ya que el cliente no sabe lo que quiere hasta que lo ve y lo toca. Antídoto: Entregar y fallar rápido.
  2. Riesgo técnico, si lo que queremos hacer se puede hacer. Posible antídoto: prototipado.
  3. Riesgo financiero: Si va a dar beneficios. Antídoto: Feedback rápido del cliente.

Consejo: Empieza ya con Scrum. No hace falta tenerlo todo super claro y atado, simplemente comienza ya, sé transparente y mejora continuamente.

9.Cambia el mundo

eduScrum es una iniciativa que aplica Scrum en institutos de Holanda. Los estudiantes se organizan en equipos y se autoorganizan para desarrollar la materia sin la participación activa del profesor (que se convierte en un facilitador). El resultado: estudiantes más comprometidos y motivados en clase, y un aumento de la nota media en un 10%.

En Uganda también se usa Scrum para que los granjeros compartan información y se autoorganicen en su trabajo. Resultado, el doble de producción vendida al doble de precio. Una ONG también usa Scrum para maximizar el trabajo que pueden hacer sus voluntarios y por tanto la ayuda que llega a las personas más desfavorecidas.

En el gobierno también se usa Scrum. En IT al principio y después al resto de proyectos, en contra incluso de la propia legislación waterfall.

La transparencia, efectividad y motivación de Scrum poco a poco va conquistando todos los lugares y contextos.

Valve, una compañía de videojuegos, tiene una estructura totalmente plana, sin reporting. Cada uno es libre de tomar las decisiones que crea convenientes y de iniciar proyectos de cualquier tipo. Tú eres el responsable de reclutar dentro y fuera de la compañía la gente necesaria para el proyecto. Y les va muy bien.

Apéndice

Cómo empezar con Scrum:

  1. Escoge a un Product Owner, un equipo de desarrollo y un Scrum Master.
  2. Confecciona un Product Backlog
  3. Priorízalo y estímalo
  4. Planifica el primer Sprint
  5. Utiliza la velocidad para tener una idea de lo que te llevará construir todo
  6. Haz el trabajo visible con un tablero Scrum
  7. Haz dailies para coordinar al equipo

 

Hasta aquí el resumen del libro “Scrum: The Art of Doing Twice the Work in Half the time” de Jeff Sutherland. Si todavía no tienes el libro y quieres comprarlo, te recuerdo que puedes hacerlo en el siguiente enlace de afiliados. A ti no te costará más y me ayudarás a mantener este blog.

También te puede interesar...

Cómo definir criterios de aceptación Los criterios de aceptación nos permiten definir una historia de usuario en un producto agile. Pero aprender a escribir buenas historias de usuario y ...
Cómo iniciar tu primera comunidad de práctica (II)... En el artículo anterior definimos las comunidades de práctica como un espacio abierto en el que cualquiera puede aportar y participar. En un entorno c...
Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *