Scrum. Taller práctico con Enric Lizondo

El pasado martes 25 de Marzo de 2014 tuvimos la oportunidad de ir a un taller práctico de Scrum de mucha calidad impartido por el gran Enric Lizondo, Scrum Master de tres grupos de trabajo en Sony PlayStation 4.

Agradecer a la Universidad de Alicante por esta iniciativa, a mi amigo Miguel Cazorla (director y compañero en Proweb) por invitarnos a esta oportunidad y a Juanma de Gesio por organizar el taller.

De hecho puede ser algo muy interesante para futuras ediciones del master que impartimos en la Universidad de Alicante: Proweb.

Scrum en nitsnets

En nitsnets habíamos leído mucho sobre Scrum e intentado ya hace casi cuatro años aplicar su metodología en la empresa pero siempre desde un punto teórico. Recuerdo como en este mismo blog hablamos de:

• SCRUM metodología de desarrollo de software ágil
• Reflexión: Metodología ágil SCRUM en Pymes. Donde planteábamos cuestiones que no teníamos muy claras. Cuestiones sobre si es aplicable Scrum a empresas de servicios al estilo nitsnets | studios donde una quincena de desarrolladores lleva a la vez entre 20-30 proyectos.

Muchas de estas incógnitas se clarificaron y no sirvió mucho para aprender de modo práctico qué es Scrum como veremos a continuación.

Sobre el formador Scrum Master: Enric Lizondo



Enric Lizondo es un prestigioso Scrum Master al cargo de tres grupos de trabajo independiente en Sony PlayStation 4. Se encarga a grandes rasgos de los ecommerce internacionales de SonyPlay Station.

Me impresionó lo profesionalizado que esta el sector de la ingeniería informática con la metodología de desarrollo ágil. Enric tenía los títulos de PMP, PMI-ACP, CSM, CSP y estaba a punto de conseguir el CSC y CST. Interesante para aquellos que os queráis dedicar a esto.

La verdad es que fue todo un privilegio recibir una formación de alguien tan experimentado y que su día a día es trabajar con Scrum, un curso que en el mercado posiblemente valiera un par de miles de euros. Siempre digo que no es lo mismo recibir formación de alguien que se ha formado que de alguien que su vida es esa materia 😉

Equipo de desarrollo: Las relaciones humanas



La filosofía de Enric, y de Scrum, era muy clara: Creer más en la parte humana, en el equipo, trabajo con personas. En definitiva las relaciones humanas como parte fundamental y prioritaria en el desarrollo del software. Los desarrolladores del equipo no son recursos son miembros; recursos es un ordenador, una mesa o una grapadora…

Principios básicos basados en el respeto al compañero, todo el mundo falla y todas las ideas son buenas. Recuerdo que nos comentó que como ejercicio los miembros del equipo salían a la pizarra y se les deletreaba una palabra en inglés y tenían que escribirla. Este ejercicio en inglés no es fácil y todos se equivocaban, prohibido reírse, ¡respeto!. Otro detalle o principio básico: nadie habla cuando habla otra parte del equipo. Durante el taller nos tuvo que llamar la atención porque de vez en cuando cuchicheábamos sobre el curso y nos enseñaba que justo eso había que evitarlo. Y cuando estábamos todos hablando y no se escuchaba al profesor la técnica era levantar el brazo (primero el profesor) y luego quien lo veía levantaba el brazo lo que provocaba un silencio completo. Curioso.



Por lo tanto había que formar equipos. Como éramos 15 personas se formaron tres equipos de 5 personas. Nosotros éramos PROWEB + 1: Anna, Miguel Cazorla, Alex Such, Josh Pina y yo; aunque también se podría haber llamado nitsnets + 2 o uanets :P. Lo de PROWEB + 1 es porque todos somos parte del profesorado del Curso de Especialista Proweb excepto Alex que está en el de Java.
Por otro lado el EQUIPO A formado por el personal del departamento como Domingo y Otto; y por último Gesio Team con los integrantes de la empresa Gesio.

Principios del manifiesto ágil

Se empezó leyendo los Principios del Manifiesto Ágil se nos hizo valorar en equipo que puntos considerábamos más importantes y cada equipo expuso sus tres puntos más votados. A mí personalmente me impactó el punto 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Enric comentó que su preferido era el 7: El software funcionando es la medida principal del progreso. Es decir, el valor del cliente es el working software. Si se corta el desarrollo de software a mitad proceso al menos podremos tener parte de las funcionalidades desarrolladas, si fuera un proyecto tradicional nos encontraríamos con una documentación de un software o algo que no funciona.

Scrum

Durante el curso se nos dió unos apuntes sobre Scrum basados en la Guía de Scrum que os podéis descargar para saber más sobre el tema. No obstante este artículo del post no intenta explicar Scrum (como ya hicimos en: SCRUM metodología de desarrollo de software ágil) si no más bien, contar la experiencia del taller. Por eso omitiremos explicaciones del método ágil y nos centraremos en detalles y curiosidades.

Scrum es un marco de trabajo relativamente nuevo (10-12 años), por eso nos comentaba Enric que una de las cosas que más cuesta es que directivos de empresas que tienen procesos de desarrollo de software tradicional cambien de mente. Una de sus labores era hacerles ver lo positivo que sería ese cambio de filosofía. El software en constante desarrollo y sprints.

Entre los pilares de Scrum existe la transparencia. Transparencia para todos, todos los participantes tienen el mismo lenguaje y todos ellos saben como esta todo.
Un artículo muy recomendable: The new new product dev guide



El entorno de desarrollo tradicional en la pirámide ALCANCE – COSTE – TIEMPO, el alcance es lo fundamental. Sin embargo en Scrum el concepto esta basado en coste – tiempo ¿que puedes hacer en este tiempo?

Ejercicio de las monedas


Para ver la utilidad del proceso de mejora hicimos un ejercicio: Cada miembro del grupo tenía que darle la vuelta a 10 monedas de 5 cts.
Todos los miembros del equipo (5 miembros) teníamos que darle la vuelta a cada moneda una vez.
Esta tarea se iba a iterar tres veces. La primera vez tenían que pasar todas las monedas de un perfil a otro. Antes de cada sprint teníamos un pequeño tiempo de 2 min para organizarnos y hablar de la estrategia a seguir.

• Iteración 1. En el momento que dio el pistoletazo de salida Miguel empezó a girar las monedas, Alex y yo enseguida dijimos juntémosla en una pila. Una vez en esa pila sólo girábamos la pila de monedas; se nos resbaló casi se nos desmonta sin poder asegurar que todas las monedas giraron todas las veces, etc… mucho riesgo para poco beneficio. En total en este primer sprint tardamos 60’’.
• Iteración 2. En el segundo sprint pensamos salir ya con las monedas agrupadas, tuvimos problemas de mecánica pero mejoramos muchísimo el tiempo 17’’. Es decir preparamos el material.
• Iteración 3. En el último sprint habíamos preparado una mecánica para el paso de las monedas de un miembro del grupo a otro y conseguimos 6’. Wow!!! Aún así el Gesio Team nos ganó con 5’ con un turquito que algún día contaré 🙂

Nos enseñó este ejercicio como estas iteraciones mejoraban el proceso de una forma rápida y ágil. Si hubiéramos planteado un único desarrollo y sólo hubiéramos girado las monedas una vez por mucho que lo hubiéramos preparado no habríamos tenido la experiencia de darnos cuenta donde fallaba, como lo podemos mejorar, etc… Scrum en estado puro.

Equipo de Scrum

• En el equipo debe tener un único Product Owner, responsable de maximizar el valor del producto y del trabajo del equipo. Es el único que gestiona la lista de requerimientos visible y transparente, ordena prioridades, etc. Eso sí, es una persona no un grupo de personas.

  Por lo tanto nadie inserta nada en el proyecto sin pasar por el Product Owner, ni siquiera el presidente de la compañía 🙂

  El cliente trata con el Product Owner (aunque el cliente puede participar con todo el resto del equipo Scrum por el principio de transparencia)

  Ejercicio palabras a gritos.
  Consistía en que tres miembros de equipo tenían que deletrear letra a letra una palabra y otra escribiría estas palabras en la pizarra. Empezamos el primer sprint gritando los tres a la vez nuestras letras y la cosa generó confusión. En el segundo sprint fuimos cada uno diciendo la primera letra, luego la segundo, etc… En la tercera interacción deletreamos de una a una las palabras. Primero habla uno y luego otro. ¿Lógico verdad? Por lo tanto un único Product Owner.

• El Development Team son los profesionales que desarrollan el software. Son autoorgananizados, no hay subequipos, ni roles, todos son desarrolladores. Si el equipo cumple y consigue un logro es para el equipo, no para el individuo. Normalmente Scrum se basa en que contamos con muy buenos profesionales.

  Los equipos de Scrum suelen ser grupos cerrados, no se cambian. Los perfiles puedes ser Especialistas, Generalistas especialistas, Generalistas, Superskills (saben todo de todo).
  Al final lo mejor son los Generalistas especialistas, es decir saben de todo un poco y mucho de su especialidad.

  

  Es interesante saber que no todo el mundo esta capacitado para pertenecer a un equipo que trabaja con esta metodología. Es extremadamente exigente. Es el equipo el que te va a preguntar día a día que has hecho en el proyecto, te va a ayudar y la responsabilidad del proyecto es del propio equipo. Los perfiles que no les guste esa responsabilidad es complicado que pertenezcan a un equipo Scrum. Es el propio equipo el que te puede dejar fuera del equipo.

  Por otro lado también me sorprendió muchísimo una técnica de programación que hay veces que se utiliza en Scrum, se llama Mob programming, la cual consiste en que se tienen que desarrollar unas funcionalidades. Un desarrollador programa 10 minutos y el resto supervisa en un proyector lo que esta desarrollando en tiempo real. Cada 10 minutos cambia de programador. Para que lo que salga sea perfecto y sin bugs. Me pareció muy curioso y sorprendente.

• El Scrum Master es el responsable de que el Scrum es entendido y adoptado. El perfil de Enric. Todo debe funcionar según la metodología Scrum. Se encarga de liderar (no lo que él dice), motivar (diciendo quien lo ha hecho bien), guía al equipo (dejando que fallen y se equivoquen a veces), conoce al equipo…

  No se puede tener la misma persona como Product owner y Scrum Master. Y no debe ser un Scrum Master un jefe tuyo 😛

Una vez aprendido los perfiles hicimos otro ejercicio en el cual teníamos que identificar en grupo un montón de tareas y asignarlas a los roles: product owner, scrum master o developer team. Algunas tareas eran compartidas entre 2 perfiles o comunes para los tres. Las que más debate surgieron eran:

• ¿Quién participaban en las demos del producto? La respuesta era todos
• ¿Quién asignaba las tareas a cada desarrollado? La respuesta era el propio equipo developer team, se autoorganizan por tanto se asignan sus tareas. ¿Cómo? Se van haciendo preguntas: ¿Quien sabe programar en Java? ¿Quién quiere coger esta tarea? ¿Has acabado, puedes ayudarme? Para esto Enric nos explicó una técnica que iba muy bien, todo por democracia. Puño en alto y con número de dedos 0-3-5 contestas a la pregunta. Ágil y letal.
• ¿Quién decidía la arquitectura del sistema? La respuesta era de nuevo el propio equipo. Aunque si es cierto que en algunas empresas grandes tienen un grupo de desarrolladores encargados de arquitectura exclusivamente.

Artefactos SCRUM

Lista de producto / Product Backlog es una lista ordenada de lo necesario para el producto. Cómo decíamos es el Product Owner el responsable de esta lista.




Será mucho más sencillo tratar tareas de 4 horas y menos margen de error que planificar una tarea de un año. Otro de los pilares fundamentales de Scrum.

Por otro lado están las Listas de pendientes del Sprint / Sprint Backlog, es decir, el conjunto de elementos de la Lista de Producto seleccionados para cada Sprint. En Scrum cada una de estar iteraciones es incremental. El Incremento es la suma de todos los elementos completados durante el Sprint.



Por esto el WIP, interesante también en Kanban, de 1 a 1. Mínimos requerimientos, normalmente Enric decía 2 semanas (por experiencia).

El Product Owner marca todo el listado que quiere hacer y el equipo engloba que puede hacer para el SPRINT: podemos hacer esto, se autoasignan tareas, etc…

¿Qué significa TERMINADO?
Cuando un elemento de la Lista de Producto o un Incremento se describe como TERMINADO todo el mundo debe entender que significa.
¿Qué significa terminado? ¿Código realizado? ¿Caso de test? ¿Code review? ¿Pruebas unitarias? ¿En preproducción?

Se debe definir este concepto con mucha claridad: terminado.

Eventos de Scrum

El Sprint es el corazón de Scrum. Es un bloque de tiempo como decíamos normalmente de 2 semanas para acabar con un incremento terminado.
Esto en el taller se nos quedó un poco cortos pero ya no teníamos tiempo para mucho más, llevábamos más de seis horas de taller.

Los Sprints consisten e:

• Sprint Planning Meeting. Reunión de Planificación de Sprint. Suele tener un tiempo máximo de 8 horas pero Enric decía que las planificaba en 4. Cada dos semanas se suele hacer una. Depende de la duración del Sprint. El Scrum Master se asegura de que el evento se lleve a cabo. Qué, cómo y compromiso.
• Daily Scrums. Scrums diarios. Suelen ser reuniones de 15 minutos en los que cada uno de los miembro del equipo explica qué hizo ayer, que hará hoy, si hay algún impedimento o complicación, si necesita ayuda… las tareas suelen ser de 6 horas como explicábamos. En equipos de Scrums avanzados estas reuniones suelen durar pocos minutos.
• Trabajo de desarrollo.
• Sprint Review. Revisión del Sprint o lo considerado como demo
• Sprint Retrospective. Retrosprectiva del Sprint. Es interesante conocer el perfil de Diana Larsen que es una de los mayores especialista en retrospectiva

Las tareas se definen en horas. 8 horas o menos, lo ideal es que no pase del día así que como máximo casi mejor seis horas. Esta definición de tareas en horas es un arte que se consigue con la experiencia.

Simulación de SCRUM. Ejercicio práctico

En el momento final vino la simulación en real de un ejercicio de Scrum. Fue algo divertido y entretenido.
El problema a resolver era que teníamos que preparar una cena para 6 comensales. Material con el que contamos: tijeras, celo, cartulinas de colores, etc… Cada equipo tenía que al menos utilizar cuatro colores.
Empezó el primer Sprint Planning Meeting donde vimos requisitos del sistema. Íbamos nuevamente a realizarlo en 3 iteraciones. Había en la cena vegetarianos pero alguno querría carne, dos comensales comían mucho, no había límite de dinero, no había alérgicos y era una reunión formal.

Nuestro equipo se encargó de preparar la mesa y la cubertería, otro equipo la ensalada junto con el postre y el último equipo los platos principales. Teníamos poco tiempo a pensar y nos organizamos. En cada Sprint aprendimos cosas que no hubiéramos visto si hubiéramos utilizado la metodología tradicional. Por ejemplo nuestra tarea parecía simple pero cuando el Product Owner dijo que los cubiertos tenían que ser recortados y no dibujados se nos destrozó el planning y requerimos de ayuda del resto de equipos. También vimos las dependencias entre los equipos, se hizo la ensalada y no teníamos previsto el cuento…


Un ejercicio simple donde pudimos ver alguna de las ventajas de Scrum.

Al final del curso se explicaron las preguntas que se habían realizado antes de empezar. La mia estaba clara: ¿Es aplicable Scrum a empresas de servicios donde hay proyectos de 3-6 semanas?. La respuesta fue que quizás para esos proyectos era mejor basarse en otra metodología como Kanban

Entrega certificados

Al finalizar el curso se realizó la entrega de certificados de formación y nuevamente como durante toda la sesión fue el propio equipo el que lo hizo. A cada integrante del taller se le dio una carpeta con el certificado dentro, luego uno a uno como en las reuniones de 15 min de Scrum íbamos abriendo la carpeta, recitando el nombre del compañero que nos había tocado y haciéndole la entrega del certificado. Nuevamente equipo.



En definitiva un taller increíble de mucho nivel y calidad. #gogogo