¿La pila de producto y la de sprint se estiman en la misma unidad?

La estimación de la pila de producto se produce en la planificación de release y en la reunión de refinamiento, ambas reuniones conducidas por el Propietario del Producto. Lo ideal es utilizar la estimación relativa, si el equipo ya tiene un recorrido, lo mejor es estimar en comparación con otras historias de usuario que hayamos hecho en el pasado. La unidad en que estimemos el tamaño de las historias, puntos de historia, son una convención del equipo y representan el tamaño o esfuerzo(no el tiempo), de forma que los números representan la tamaños relativos entre historias.

Pila de producto (NOT SELECTED)
y pila de sprint (SELECTED)

Ahora bien, en la reunión de planificación de sprint el equipo desgrana las historias en tareas y estima estas, quizá en horas. Quiero dar la idea de que las unidades no tienen porqué ser iguales para las dos pilas, de hecho es mejor que sean unidades distintas, ya que acabado el sprint, la unidad en que se debe de utilizar para medir la velocidad del equipo es la de la pila de producto, no la de sprint, y con unidades diferentes se evitan confusiones.

Si somos capaces de establecer una unidad única que signifique lo mismo para todo un proyecto o empresa con varios equipos, todos los equipos serán capaces de estimar, si se les da el conocimiento necesario, con una unidad de tamaño común para todos ellos. Independientemente de eso, cada equipo tiene su propia velocidad, probablemente distinta de otros equipos. Así tendremos equipos más lentos y equipos más rápidos, pero todos hablarán el mismo idioma. Quiero resaltar que tener equipos de diferentes velocidades puede ser perfectamente deseable, un equipo de élite para lo crítico y un equipo de fondo para los trabajos más de molinillo y menos gratos.

Daré un ejemplo: Alexander hace 20 años programaba en un lenguaje que se llamaba Clipper (quizá a alguien de por aquí le suene). Entonces estimó una historia en 3 puntos de historia y tardó 9 horas en realizarla. Si ahora Alexander tuviese que realizar la misma tarea probablemente tardaría, bufff, ¿30 horas? (Dios no quiera que tuviera que volver a ello, jajaja). ¿Quiere eso decir que la historia de usuario ha crecido y ahora debería de ser algo como 9 puntos de historia? No, simplemente Alexander ha reducido su velocidad por haber estado ausente de la tecnología durante 20 años, el tamaño de la historia sigue siendo el mismo.

Os invito a leer un post mío relacionado: ¿Qué ocurre con la velocidad del equipo cuando las horas estimadas de una historia de usuario son inferiores a la suma de las horas estimadas en las tareas correspondientes de la pila de sprint?

¿Qué patrones de testing son posibles para evolucionar de una gestión clásica a Scrum?

Recordemos que los incrementos resultantes de un sprint solo están finalizados cuando cumplen con la definición de hecho (DoD), definición que incluye pasar todas las pruebas con éxito. Llegar a obtener incrementos con todo el testing realizado implica una gran madurez en Agilidad. Después de 50 años de ingeniería de software hemos llegado a la conclusión de que las pruebas son un buen lenguaje para especificar requisitos funcionales, y es por ello que los criterios de aceptación, que se traducen en pruebas, toman tanta importancia en las historias de usuario. La mejor solución hasta hoy en día para garantizar pruebas completas dentro de un sprint, son la integración continua y las pruebas automatizadas. Implementar esta solución, TDD (Test Driven Development) o BDD (Behavior Driven Development), tiene sus dificultades que requiere una madurez que no es fácil de alcanzar.

Recientemente fui co-trainer de Mike Beedle en uno de sus cursos y en este describió 6 patrones de pruebas, los 5 primeros con soluciones gradualmente más cercanas a las necesidades de Scrum.

1. Sprint de integración y estabilización: en esta solución se dedica un sprint entero a hacer el testing de varios sprints anteriores. Esta solución se parece a trabajar en cascada y por ello se le da los nombres de ScrumFall o WaterAgile. La desventaja es que el sprint de pruebas puede ser una auténtica bomba de relojería que puede destapar una avalancha de incidencias.
2. Un equipo de pruebas testea después de la planificación del siguiente sprint: de esta manera cada sprint tiene su fase de pruebas, pero tiene la desventaja de que las incidencias entran en sprints posteriores afectando a estos de manera imprevisible. Una avalancha de incidencias puede romper un sprint.
3. Un equipo de pruebas testea antes de la revisión del sprint: esta fase de test al final del sprint produce estrés adicional a la entrega y se produce un constante peloteo entre equipo de desarrollo y el de pruebas. El equipo de pruebas se queja de la mala calidad del equipo de desarrollo, y este, de que constantemente el equipo de pruebas está rompiéndoles con las incidencias su ritmo de trabajo, agravado por el sentimiento de que otro equipo está destapando los errores propios.
4. Build diario con un equipo de pruebas en otro turno horario: cada mañana el equipo se encuentra con las incidencias detectadas, tiene la desventaja de que el equipo se encuentra cada mañana con una pila de sprint cambiada y que también se produce algo de peloteo entre los dos equipos.
5. Build diario con un equipo de pruebas a última hora del día: tiene la ventaja de que se detectan las incidencias de forma muy rápida pero la desventaja de convertir los días del equipo de desarrollo en días muy largos, ya que seguramente poco antes de que tengan intención de irse a casa ya reciban incidencias del equipo de pruebas y se pongan a resolverlas.
6. Integración continua y pruebas automatizadas: se pueden realizar a petición docenas de pruebas automatizadas cada día. A petición, el sistema efectúa de forma automática el juego de pruebas completo y en cuestión de minutos el equipo de desarrollo tiene un reporte completo con las incidencias, pudiendo resolver estas en caliente con la mente aún inmersa en el código testeado.

En febrero asistí a un meetup en el que el Centro de Innovación del BBVA compartió sus experiencias con BDD y automatización de las pruebas. Allí vi de primera mano como una compañía había implementado integración continua y pruebas automatizadas.

Meetup "Cucumbeando, que es pepino" en el Centro de Innovación del BBVA

La herramienta que utilizan es Cucumber, un software de test que ejecuta las pruebas al estilo de BDD. La primera tarea de un desarrollador es escribir las pruebas en Gherkin, un lenguaje que usa Cucumber y se escribe desde el negocio, un lenguaje específico que permite describir el comportamiento del software sin detallar cómo se implementará ese comportamiento. Una vez escritas las pruebas el desarrollador empieza a codificar y cada vez que tiene una parte testeable lanza las pruebas automatizadas para probar su código. Cuando pasa todas las pruebas el sistema da garantías de un software sin incidencias, aunque no de que haga lo correcto.

Tengo la convicción de que dentro de 10-20 años todos trabajaremos con pruebas automatizadas y las personas solo efectuarán aquellas en que aporten valor como las pruebas funcionales complejas y las pruebas exploratorias. Muchas de las pruebas ejecutadas por personas serán para entonces prehistoria y anécdotas del pasado.

¿Cuál es la diferencia entre Lead y Cycle Time en Kanban?

En mi último curso expliqué los dos conceptos y una de las alumnas salta y dice: "eso es como cuando coges el metro, Cycle Time, o tiempo de servicio, es cuando subes al metro y piensas lo bien que funciona y que enseguida estás en casa, y Lead Time, tiempo de entrega, es cuando llegas al andén y ves como se va un tren, sientes la rabia de haberlo perdido y durante la espera piensas lo mal que va el servicio". Me pareció una analogía muy ilustrativa que me animó a escribir este post.

Imaginemos que tenemos un tablero Kanban con el que gestionamos el flujo de trabajo de las peticiones de nuestro servicio de mantenimiento y soporte. Lead Time es el plazo de ejecución que se inicia cuando el cliente hace la petición y que termina en la entrega. Cycle Time es el tiempo que se inicia cuando el equipo comienza el trabajo sobre la petición e igualmente termina en la entrega, realmente se trata del esfuerzo medido en tiempo:

Lead y Cycle Time sobre un tablero Kanban

• Lead time (tiempo de servicio): tiempo importante para el cliente ya que mide el tiempo de resolución de sus peticiones
• Cycle time (tiempo de entrega): tiempo de trabajo sobre la petición, importante para el proveedor ya que viene a ser una medida de la capacidad del proceso

En el contexto de los servicios de manteamiento suele haber un ANS o SLA (Acuerdos de Nivel de Servicios o Service Level Agreement) en que se mencionan los tiempos de resolución requeridos, usualmente estos suelen ser Lead Time. Si no añadimos nada más esto puede llevarnos a una situación comprometida, si nuestro cliente nos hace peticiones por encima de nuestra capacidad tendrá una percepción muy negativa de nosotros. Aunque nuestro Cycle Time pueda ser excelente, se nos acumulan las peticiones en la columna de "Pendiente" y el cliente percibe que no somos capaces de resolver a su ritmo.

Lo que aconsejo en este caso es limitar el WIP en la columna "Pendiente", buscando igualar lo máximo posible Lead y Cycle Time, y así conseguir que en el momento en el que nuestro cliente haga una petición, esta entre lo antes posible a "En curso". En este caso la percepción del cliente será muy distinta, percibe que tal como solicita nos ponemos a trabajar en ello. Los ANS o SLA no son solo para que nuestros clientes pongan sus condiciones, también los proveedores podemos poner las nuestras, y si un cliente paga por un equipo de tamaño determinado hemos de ofertar de forma proporcional a la capacidad de resolución del equipo. Encontrar el WIP adecuado no es inmediato, requiere cierto rodaje, por tanto un periodo de adaptación debería de ser tratado en el ANS.

¿Qué ventajas financieras aporta Scrum frente a proyectos en cascada?

Como coach ágil acabas moderando, formando y explicando Scrum a muy diferentes perfiles dentro de las compañías, y a cada uno de ellos hay que hablarles en un idioma adecuado, uno que cada uno de ellos pueda entender. Uno de estos perfiles son los directores financieros y para cuando tengamos que tratar con estos podemos utilizar este gráfico que muestra una comparativa de como se comporta el ROI en ambos marcos de trabajo.

Gráfico comparativa comportamiento ROI por Carlos Peix

En el punto "0", el origen de coordenadas, encontramos el punto donde se inicia nuestro proyecto. El punto "E" sobre el eje de abscisas representa deadline, el momento de la entrega del proyecto. En el eje de ordenadas por encima del origen de coordenadas se representan las ganancias (ROI), y por debajo del mismo las pérdidas (inversión).

Miremos primero lo que ocurre con la curva "B" que representa un proyecto con metodología tradicional en cascada. Desde el inicio del proyecto hasta su entrega tenemos una inversión constante, pagamos sueldos, recursos y todo lo que conlleve el proyecto. No es hasta que entregamos el proyecto cuando recuperamos poco a poco la inversión con los beneficios que este va reportando. En algún momento más allá de la entrega la curva se vuelve de color verde y dará beneficios a la compañía.

Ahora estudiemos la curva "A". Esta representa un proyecto bajo el marco de trabajo de Scrum. Con cada sprint, señalados con la letra "S", obtenemos un incremento instalable en producción. Ya en los primeros sprints vemos que la inversión da sus frutos, ya que el incremento puesto en producción, por tanto lanzado al mercado, ya empieza a dar beneficios y a producirse el retorno de la inversión. El ROI es moderado pero crece a medida que avanza el proyecto y mucho antes de la fecha de entrega "E" la curva se vuelve verde.

¡Un director financiero eso lo entenderá muy muy bien! :-)

Pero veamos que más beneficios aporta Scrum. Imaginemos que en el punto "I" se produce una interrupción del proyecto, no tanto por una cancelación, sino porque se hayan producido cambios significativos en el alcance derivados de las variaciones del mercado. En un proyecto en cascada es complicado cambiar, el proyecto se ha diseñado para llegar a "E" y lo más probable es que en "I" tengamos muchas cosas empezadas, cosas que

Gráfico de funcionalidades obtenidas, thanks to Silvana

habrá que finalizar o desechar. Usualmente esto pasa porque en proyectos en cascada se suele trabajar por capas horizontales, a diferencia de Scrum dónde se trabaja por lonchas verticales. Veamos ahora lo que pasa en Scrum. Scrum abraza el cambio, por tanto lo único que sería necesario es finalizar el sprint en curso, luego los cambios se incorporarán de forma natural al proyecto. Aún en el caso de una cancelación total del proyecto, lo construido hasta entonces, dado que está en producción, en el mercado, seguirá dando sus beneficios. En el gráfico a la izquierda se ve claramente la diferencia en funcionalidades obtenidas, en el proyecto en cascada no habremos obtenido nada, porque todo lo obtendremos en "E", en cambio en Scrum habremos obtenido la suma de funcionalidades construidas en los diferentes sprints "S".

Es interesante ver el comportamiento del riesgo "R", en cuanto la curva "A" se vuelve verde ¿hay riesgo financiero? ¡Podemos seguir desarrollando y no perdemos dinero! Uno de los beneficios de Scrum es que, al poner los problemas sobre la mesa en cuanto estos se producen, trae los riesgos al principio del proyecto.

¿Qué hacer cuando la fricción del ambiente hace que el equipo nunca cumpla con la pila de sprint?

Gráfico burn-down de un sprint con fricción ambiental

Partimos de la base de que tenemos un equipo formado y motivado, que lleva unos pocos sprints a su espalda y que ha alcanzado un cierto grado de autoorganización. Todo debería ir bien, pero la fricción del ambiente hace que con cada sprint se obtenga un gráfico burn-down con un patrón semejante al de la imagen de la izquierda.

Para que funcione Scrum y la Agilidad no sólo debemos de tener equipos ágiles, nuestros clientes y usuarios, los que entienden de negocio, también deben de ser ágiles. El grado de Agilidad de nuestros clientes también afecta, y cuando estos tardan en responder, en decidir o proveer, se produce lo que se llama la fricción del ambiente. En estos casos esta fricción es la responsable de que no se cumplan los sprints, los ciclos de respuestas de nuestros clientes son más largos que los sprints y por tanto la solución sería alargar la duración de los mismos para dar el tiempo necesario a los ciclos del cliente. Los sprints serán más largos y contendrán más historias de usuario, pero permitirán que los ciclos del cliente se acompasen con estos.

¿Cómo decidir a qué candidatos contratar para un equipo ágil?

Es una pregunta que se repite a lo largo de la mayoría de los cursos que doy, así como en los que asisto como co-trainer y alumno.

Contratado el candidato acertado

Los equipos ganadores, o de excelencia, dónde los miembros están integrados y confían unos en otros, están formados por personas con perfiles tipo "T", con las aptitudes necesarias para realizar su trabajo específico y a la vez con interés y curiosidad por todo lo que les rodea dentro del contexto del proyecto. Quién quiera saber un poco más sobre las personas tipo "T" y tipo "I" puede leer mi post ¿Cómo han de ser las personas que integran los equipos de trabajo?

Para encontrar perfiles tipo "T" podemos utilizar Killer-Questions como ¿Al integrarse en nuestro equipo como se ve usted, más como alguien que puede enseñar o alguien que puede aprender? 

Dentro del mundo en que vivimos, incluidas las TI, en que el cambio es constante, una persona tipo "T" comprende que ha de aprender para adaptarse y da la bienvenida al aprendizaje continuo. De hecho, si una persona no quiere formarse y seguir evolucionando, la compañía seguramente tendrá un problema en cuanto se acabe el trabajo de su especialidad... no habrá un lugar donde reubicarle. La contratación inteligente de personal pasa por fichar aquél que aprende más rápido, no tanto por sus aptitudes, sino por su talento. Podemos tener dos curriculums iguales pero las dos personas que hay detrás ser radicalmente opuestas en productividad, la diferencia es el talento y la pasión. La ingeniería de software es una industria que trata con el talento extremo, y el éxito, sea con metodología tradicional o métodos ágiles, dependerá de las personas más acertadas.

Simon Sinek - No contrates por aptitudes,
contrata por actitud, las aptitudes se aprenden

Mencionar también que hay que tener mucho cuidado con las personas tipo "O", son aquellas cuyas aptitudes cubren todo el espectro multidisciplinar, desde analista a desarrollador y a tester, es una persona que puede hacer cualquier tipo de trabajo del equipo, pero tiene una actitud de "Prima Donna", actuando de forma individual y egocéntrica como el máster del universo, pudiendo penalizar y hasta anular a un equipo que siempre ha funcionado bien. En Scrum no hay lugar para héroes, los héroes no suelen aceptar que su opinión no siempre es la que adopta el equipo, un héroe compite, no colabora.

Quién contrata suele ser el que paga, por tanto quién contrata suele ser quien representa al cliente y que a la vez está comprometido con el proyecto, puede que el Propietario del Producto. Si fuera el caso es muy recomendable que el Scrum Master acompañe al Propietario del Producto en la entrevista y dé sus sugerencias, ya que este tiene la visión social del candidato versus al equipo.

En caso de equipos ya establecidos también es recomendable la participación final del equipo, al fin y al cabo el nuevo candidato formará parte de este y trabajará con este, y será más fácil integrarlo si el propio equipo ha formado parte de la toma de decisión. Yo lo que hago es decirle al candidato al final de la entrevista que voy a enseñarle las instalaciones y a presentar al equipo con el que pudiera acabar trabajando. En complicidad con el equipo éstos tienen una breve charla de 5 a 10 minutos con el candidato, su veto es determinante, si no lo quisieran el candidato queda directamente descartado.

Quiero acabar el post con una frase de Emilio Duró:

Yo ficho a la gente por cómo sube las escaleras

La motivación y la actitud de las personas se lee claramente en como suben las escaleras, si lo hacen con energía se puede leer valentía e ilusión... candidatos ideales para equipos con los que hacer grandes cosas.

¿Existe alguna dinámica para las retrospectivas enfocada a interacciones?

Existen varias dinámicas, mi preferida y la que aplico usualmente para tratar las interacciones es una variante del triángulo retrospectivo. La dinámica original la encontraréis en el blog de Thomas Wallet en su artículo Dinámica de Retrospectiva: El Triangulo Retrospectivo.

Equipo votando las interacciones

Su dinámica está pensada para un equipo de 3 personas y en el caso en el que yo quería aplicarlo trataba de un equipo de 5 personas. Intenté imaginarme el tipo de figura geométrica que necesitaría para representar las interacciones entre 5 personas, ¡me resultó imposible! Finalmente se me ocurrió mantener la forma de triángulo y variar los vértices. Me decidí por los siguientes tres vértices: miembro del equipo, equipo y otros, dónde otros son el Propietario del Producto, el Scrum Master y los interesados. Las interacciones representadas, las líneas, son de un miembro al equipo, de un miembro a otros y del equipo a otros.

Los pasos para la dinámica son los siguientes (basados en los pasos del triángulo retrospectivo de Thomas Wallet):

• Se arma en una superficie plana un gran triangulo con cinta, y en cada vértice del triangulo se pone un post-it con los siguientes textos: "Miembro Equipo", "Equipo" y "Otros (PO, SM, INT)"
• Cada participante escribe en post-its las interacciones que vivió como miembro o como equipo durante el último sprint (1 interacción = 1 post-it)
• De a uno y hasta que se acaben los post-its generados, se repiten los pasos siguientes:



La retrospectiva resultante
(con un vacío de interacciones
en el centro)

• Cada participante explica uno de sus post-its
• Luego lo ubica en el triángulo: en el lado externo de la línea que une dos actores cuando es una interacción entre dos, o en el medio si es una interacción entre todos
• Si otro participante tiene un post-it similar o relacionado, lo cuenta, se pegan juntos y se reformulan si fuera necesario
• Se revisa el triangulo generado con el objetivo de descubrir interacciones faltantes y/o unir/agrupar varias interacciones
• Cada participante vota con color verde con un solo "1" un solo "2" y un solo "3" a tres de los post-its que asimila a interacciones que fueron positivas/fortalezas
• De la misma manera que en el punto anterior, cada participante vota con color rojo los post-its que asimila a interacciones que fueron negativas/problemáticas
• Se revisan los resultados de la votación:
• Entre los que suman los números rojos más altos se elige el o los problemas a analizar luego
• Entre los que suman los números verdes se repasan para conocer las fortalezas de equipo y de lo que se está haciendo bien
• Por último se revisa como de balanceados están los post-its, por ejemplo en la imagen de ejemplo el centro tiene pocas interacciones (en este caso no está la reunión de planificación de sprint, posible signo de que no se le esté dando la importancia debida)

La experiencia fue muy positiva, los resultados fueron similares a los de otras técnicas, pero la gamificación a través de la dinámica convirtió una actividad a priori aburrida en una actividad divertida en que todos participaron de forma muy activa.