Archivo de la etiqueta: scrum

A vueltas con el refinamiento deL PRODUCT backlog

Vamos primero a revisar qué dice la Guía Oficial de Scrum sobre el refinamiento

Definicion oficial del refinamiento de sprint

El refinamiento (refinement) de la Pila del Producto (Product Backlog) es el acto de añadir detalle, estimaciones y orden a los elementos de la Pila del Producto (Product Backlog). Se trata de un proceso continuo en el cual El Propietario del Producto (Product Owner) y el Equipo de Desarrollo (Development Team) colaboran acerca de los detalles de los elementos de la Pila del Producto (Product Backlog). Durante el refinamiento de la Pila del Producto (Product Backlog), se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo (Development Team). Sin embargo, los elementos de la Pila del Producto (Product Backlog) pueden actualizarse en cualquier momento por El Propietario del Producto (Product Owner) o a criterio suyo.

De la definición oficial lo fundamental a entender es que el Refinamiento NO ES UN RITUAL como así lo son el Sprint Planning, Review y otras. Tampoco obliga a que haya presente ningún rol en concreto sino que únicamente habla del equipo.

Personalmente he trabajado con muchas interpretaciones de cómo se hace un refinamiento. Empecé trabajando con Scrum sin hacer nada explícitamente que se llamara como tal. Prácticamente todo el trabajo de análisis del Backlog, estimación y demás se hacía con el equipo durante el Sprint Planning. Más tarde, en mis tiempos de consultora informática trabajando para bancos, un grupo de expertos en cada área como el arquitecto, los Product Managers, seguridad y demás rellenaban todo lo posible la información del elemento de Backlog en JIRA y el refinamiento por parte del equipo era una mera lectura de lo que ya habían refinado otros ( 0% de posibilidad de aportación por su parte, 0% ownership, 0% creatividad por parte del equipo) . En esta última etapa de trabajo en la que estoy, el equipo al completo se reúne con Product Owner, revisa el backlog, le añade información, lo aclara y lo estima. Aquí lo que nos encontramos muchas veces es que algunos miembros del equipo consideran improductivas estas sesiones de refinamiento ya que la discusión a veces se centra entre un par de personas. Otras veces surgen dudas que se necesitan aclarar e investigar y opinan que hubiera valido la pena revisarlo bien antes de que llegue al equipo. Esto último incluso, a veces, esto provoca que se salte el refinamiento de esa historia de usuario a una siguiente sesión.

A nivel de flujos de información, en la actividad de refinar detecto dos flujos principales.

1.- Análisis o incorporación de información hacia el elemento del backlog. Aquí el conocimiento del equipo junto con otras personas con información de negocio, entorno (legal, técnico, …) , arquitectura y resto de áreas confluyen junto con la creatividad del equipo en una definición de la solución técnica que hay que realizar.


2.- Difusión de la información hacia el propio equipo. El equipo necesita entender el trabajo que hay que realizar. Una buena forma de saber que el equipo conoce su alcance es mediante el ejercicio de la estimación en conjunto. Es un buen indicador de que todos tienen en la mente el mismo tipo de trabajo cuando el equipo al completo coincide en la valoración y en los criterios por los que se ha llegado a la misma. El último momento responsable en el que debería ocurrir esta difusión de información es durante el Sprint Planning, ya que es cuando el equipo se dispone a empezar su desarrollo.

¿Quién hace falta que esté presente en cada parte? En el segundo flujo está claro que debe estar todo el equipo. Si algún miembro no participa en la difusión de información es posible que no sea capaz de trabajarlo sin bloqueos cuando llegue el momento
en el sprint.
Es en la primera parte de análisis en la que no no lo veo tan claro. Si participan personas que no tienen el conocimiento para aportar información al Backlog Item, solamente escucharán discusiones entre otros miembros hasta llegar a la solución final. No digo que esta discusión no pueda aportarles información a estos miembros del equipo más junior y veo importante que puedan colaborar para conseguir ownership del producto por su parte. Sin embargo, dependiendo del nivel de maduración de cada uno dentro del equipo , puede haber otras formas más eficientes de conseguir estos mismos objetivos que sentándose juntos sólo a escuchar.

Mi propuesta es la participación de miembros de forma incremental y con un ángulo que depende de la maduración del equipo.
En equipos pocos maduros donde hay un líder que tiene mucho conocimiento, habrá mucho trabajo de análisis por su parte y este ángulo de colaboración hasta llegar a todo el equipo sería más cerrado. En equipos muy maduros, las fases de análisis y difusión se hacen de forma simultanea y eficiente, ya que todos pueden aportan a la solución y se enteran a la vez de qué hay que hacer. Aquí el ángulo sería muy abierto o casi inexistente.

Dentro de estas dos formas opuestas también hay matices o grises. Quizá los miembros que son más seniors hacen el análisis y después se revisa con el resto del equipo. Quizá puede empezar el Tech Leader con Product Owner y preparar un esbozo de la solución que se afine con el resto.
Independientemente de cómo se haga, veo importante,de vez en cuando, si se hace una sesión de refinamiento de equipo, evaluar cómo consideran los propios miembros del equipo cuánto ha sido de productiva la sesión. De este modo pueden aflorar síntomas de algo que no esta funcionando bien y podría mejorarse hablándolo en la siguiente retrospectiva. Inspeccionar y adaptar, la base de Scrum.

Las 5 disfunciones de un Sprint Planning

Hace poco facilité un Spring Planning en el que todo fue mal. Sólo un miembro del equipo se comunicaba con el Product Owner y el resto se quedaba callado protegido por el muro que ofrece la distancia y la audioconferencia.  Justo al terminar me llegó la información por parte de algunos miembros del equipo de que lo planificado en el sprint no tenía sentido, que no habíamos tenido en cuenta ciertas cosas.  Cuando lo escuché sentí que lo que de verdad no tuvo sentido fue la reunión en sí misma ya que no se pudo pactar el objetivo del sprint.

Hace poco me leí el libro de Patrick Lencioni sobre las 5 disfunciones de un equipo.  En este libro en forma de novela se tratan los problemas que suelen tener los equipos que no consiguen trabajar de forma colaborativa y estas disfunciones acaban viendose en los sus resultados. Estas mismas 5 disfunciones se dieron juntas en el propio Sprint Planning y voy a explicar por qué. Espero que  te ayude a identificar si ocurre lo mismo  en tu equipo Scrum.

5 Disfunciones de un equipo

Ausencia de confianza.
El equipo debe tener la misma confianza que tiene cuando se reune con sus amigos a hablar de fútbol. Debe poder ser capaz de preguntar todas sus dudas, levantar la mano  y decir lo que se le ocurra como «no lo entiendo» o «lo que dices no tiene sentido»  y hacer estimaciones sin miedo a represalias. Yo he participado en Sprint plnnings en los que además de los miembros del equipo Scrum había varias personas de la PMO (Project Managemenet Office) monitorizando y atendiendo a todo lo que se iba diciendo. Esto no ayuda a que el equipo se sienta cómodo y seguro en la sesión. Hay que estar atento a estas personas como por ejemplo algun lider técnico que reprocha cualquier intervención de sus compañeros con aire de superioridad
Mi compi de GFT @fedcasabianca como apertura de un curso sobre retrospectivas nos pidió valorar «¿Cuanto de seguro te sientes sobre dar tus opiniones?». Esto es muy importante evaluarlo antes de empezar un Sprint Planning. Además identifica si hay gente conectada de forma remota o asistiendo en la reunión que no han sido invitados por ninguno de los miembros del equipo Scrum. Preguntadles cuál es su rol para la reunión de sprint planning. Recuerdales el objetivo de la sesión y que quizá lo dificultan con su presencia (Principio de Incertidumbre). Sí notas que afecta al equipo y está dentro de tus posibilidades, intenta que no asistan. Lo importante es el propio equipo y que se sientan seguros .

Temor al conflicto
Cuando el equipo no se siente seguro en la sesión de planificación no surgen conflictos. No se discute nada.  El Product Owner dice cómo lo quiere o todo lo que necesita que esté en el sprint y el equipo asiente sin discrepar. O el considerado lider técnico da una valoración o una solución técnica y el resto la asume sin ponerla a juicio. En una sesión de Sprint Planning debe haber mucha comunicacion entre todos los miembros del equipo Scrum, incluyendo sobre todo quien es la voz del producto. Toda persona que no discuta un tema lo más seguro es que no lo haya entendido bien y tenga que preguntar qué hacer o cómo hacerlo a mitad de sprint, poniendolo en peligro.
Como herramientas en las planificaciones que ayudan a disminuir esta disfunción se viene usando el Planning Poker. Precisamente se usa porque al poner las cartas todos boca abajo y darles la vuelta a la vez, todos dan la estimación sin conocer la del resto. Cuando un miembro del equipo da una estimación que discrepa de las otras, debe hablarse (generarse el conflicto necesario) para que su opinión se tenga en cuenta o al menos se escuche y evalue. La persona que ha dado esa estimación distinta debe quedarse con la sensación de que al menos se ha escuchado su criterio.

Falta de compromiso
Según la guía de Scrum cuando termina el Spring Planning, el equipo y el Product Owner acuerdan un objetivo de sprint. La palabra «acuerdan» es muy importante. No es una imposición al equipo por parte del propietario de producto.  El equipo es la unica entidad que establece la cantidad de trabajo que puede asumir. Sin embargo, en muchos equipo no es así o los propios miembros no lo ven así. La tradicion waterfullista de agendas apretadas ha calado durante muchos años y algunos equipos esperan que les impongan los backlog item a meter en el sprint sin tener en cuenta lo que realmente pueden hacer. Esta imposición provoca que los que van a desarrollar no sientan que ese objetivo les pertenece y no lo asuman como propio.  Cuando esto ocurre puede pasar que finaizar el planning y alguien diga  «Eso no lo hacemos ni de coña». O peor aún, se asuma de forma silenciosa independientemente de cómo acabe todo.
El equipo debe sacar a la luz cuánto de realista el es objetivo de sprint antes de dar el objetivo del mismo por pactado. Para ello una herramienta que se usa es la votación con el puño de cinco.  Se les pregunta a los miembros del equipo de desarrollo cuánto de realizable es el objetivo del sprint con valores entre 0 – «Ni de coña» y 5 – «Lo hacemos con la patilla».  La votación de cada uno lo tienen que mostrar en conjunto levantando la mano por encima de la cabeza sin verse influenciados por el resto.  Si se está en remoto se puede usar una herramienta tipo planning poker remota para esta votación. Es importante que quienes pongan valores bajos expongan sus razones. Quizá saben algo que el resto no.

Evitación de las responsabilidades
Cuando el equipo siente que el objetivo del sprint ha sido impuesto, lo trabaja sin sentirlo como suyo. Eso hace que por ejemplo cuando se ve acercarse el final de sprint y se detecta que quizá no se puede entregar todo, no les importe y no tengan el compromiso de colaborar entre todos para conseguirlo. Con esto no estoy hablando de hacer horas extras. Con esto quiero decir que el equipo  no tiene el sentimiento en que en parte se han fallado a ellos mismos y no sienten la necesidad de mejorar como equipo sprint tras sprint. Sin esta sensación no tienen la motivación suficiente para llegar a convertirse en un equipo de alto rendimiento.
Para detectar y mejorar esto, en las retrospectivas al final del sprint se debería evaluar las razones por las cuales algo ha salido del objetivo.  El Product Owner, aunque sin llegar al reproche, sí debería transmitir la importancia de intentar cumplir el objetivo pactado, sobre todo si el no cumplirlo es algo que ocurre de forma frecuente. El alto rendimiento debería ser objetivo de todos y si a nadie le importa que no se entregue todo, el equipo puede llegar a la autocomplacencia y estancamiento.

Poca atención a los resultados
Todas estas disfunciones concluyen en que el equipo no siente el producto como suyo.  No sienten los triunfos del resultado de su trabajo como suyos. Por ejemplo no les imporata cuando se consigue que el producto llegue a hitos como una alta tasa de descargas o uso por millones de personas. Tampoco sienten como suyos problemas que afectan al producto como por ejemplo el no haber conseguido activar la campaña de Navidad a tiempo y perder muchisimas ventas. Cuando estos problemas ocurren puede ser normal en un equipo disfuncional echar la culpa a elementos externos como «a quien gestiona el proyecto», a «negocio» o a otras partes implicadas.  Sencillamente es un equipo que va «fagocitando» historias de usuario del backlog y convirtiendolos en software funcionando sin mayor visión. Esto puede ocurrir independientemente de si se usa Scrum, Kanban o Waterfall como metodología.
Para detectar esta disfunción es tan fácil como ver si al equipo le importan metricas de producto como número de usuarios, funnels de tendencias de uso, las opiniones de los usuarios, etc.. Hazte preguntas como: ¿Le suelen preguntar al Product Owner sobre cosas relativas al uso del producto? ¿El Product Owner les comparte el avance del producto, a dónde quiere que vaya en medio largo plazo y para el equipo es algo que le interesa?

He creado este formulario de Google  para recordarme y ayudarme en los Sprint Planning a recabar esta información sobre estos problemas. Espero que en dos o tres sprints haciendo esta evaluación y usandolo como dato en las retrospectivas  me ayude a identificar estas disfunciones y estudiar entre todos formas de mejorar. Feel free de copiartelo o adatarlo.

Día 1 en la Conferencia Agile Spain 2017 en Sevilla

Keynote de Ramón Cabezas.  @RamonCabezas
Human & Digital Transformation
Ahdalid.com Kaps.es

Estuvo hablando de la transformación digital y la importancia de tener al cliente en el centro.  Enseñó un par de sus productos que se diseñaron teniendo eso en cuenta. como un pulsador para que te llame alguien para gestionar un accidente y el usuario no tenga que buscar los papeles del seguro o a quién llamar.

 

Jerónimo Palacios.  @giropa832
Scrum Studio

Habló de Scrum Studio, un framework diseñado por Scrum.org. Es una célula de trabajo totalmente independiente de la empresa y con los elementos imprescindibles para que pueda trabajar de forma autonoma y ágil. Va tomando proyectos poco a poco de la empresa madre y haciéndolos de forma ágil. Tiene la autoridad para  tomar y echar gente de sus equipos. La idea es que vaya fagocitando poco a poco al resto.

Tanto es su potencia que puede ocurrir el caso que le ocurrió en la que el CEO de la empresa acabó terminando la célula ágil.

Frase: Culture eats Agile. Al final, las personas de poder que no quieren perder su autoridad acaban por destruir los intentos de implantación de cualquier sistema ágil a escala.

El CIO  se transforma para dar Leadership services, lo que necesita esa celular para funcionar como una empresa autónoma: RRHH, contable, …

Hay que cambiar la visión de proyectos (algo que cuesta dinero) a producto (algo que genera valor y dinero por ende a la empresa)

La gestión se hace mediante Evidence based management (Scrum.org).  Basado en el triángulo MEASURE, IMPROVE, DIAGNOSE.

Existe un Scrum Development Kit que miraré  bien 😉

 

Toño de la torre. @adelatorrefoss
Discusiones y decisiones: herramientas para la efectividad

Primero hizo un disclaimer que todo venía del libro de Gamestorming y retrospectivas. Habló de conceptos básicos del gamestorming como los juegos de apertura para generar ideas, de exploración para categorizarlos y formar ideas procesadas y juegos de cierre para acabar con una decisión. También estuvo explicando varias dinámicas de gamestorming para trabajo colaborativo .

 

Israel Alcazar.  @ialcazar
Equipos de alto rendimiento

Matriz de autoridad de Richard Hackman. Parecido a la matriz de delegación de Jurgen Appelo pero más alto nivel.

Auto-organización. El equipo decide la forma de trabajo
Auto-diseño. El equipo decide qué necesita miembros o ya no.
Auto-gobierno. El más alto nivel, como si fuera una cooperativa de socios

Alto-rendimiento es una suma de resultados satisfacción y motivación. Es importante tener objetivos claros, entorno seguro y  responsabilidad compartidas.

Habó de las 5 disfunciones del equipo, del libro de Patrick Lencini

Jerarquía es como comunicación padre-hijo como trata el Analisis transaccional. Tratando al trabajador como un padre que trata al hijo hace que el hijo se comporte como rebelde o apagado.  El equipo necesita autonomía y responsabilidad.  Lo cual se trabaja con una combinación de confianza, delegación y feedback. Un entorno de confianza es el que se debe conseguir como mínimo en las retrospectivas. Comentó que se encuentra con que en las primeras retrospectivas los miembros sólo «sueltan mierda» porque tienen muchos problemas acumulados que necesitan decir y las retrospectivas es la primera oportunidad.

Las herramienta de evaluacion de equipo deben ser usados por los propios equipos. Conflicos/Cohesion/Eficacia

La evolución se hace mediante una serie de pasos en espiral con varias iteraciones. No necesariamente en el mismo orden

  1.  Proposito
  2. Conexión (empatía).  Aportación como persona
  3. Acuerdos (Roles, Reuniones, Formas de trabajo)
  4. Seguridad a trabajar en las retrospectivas
  5. Autoconocimiento (capacidades)  funcional, llegar a identificar los Roles de Belbin (explorador, investigador, coordinador..)
  6. Consciencia
  7. Autonomía
  8. Responsabilidad

Jose Ramón Díaz. @joserra_diaz
Taller de Liderazgo para la transformación. 

Empezamos haciendo una definición de liderazgo entre todos. Salieron conceptos como capacidad/habilidad, conocimiento referente, personas, sigues, empatizas, objetivo/visión, moviliza gente, forma consciente/inconsciente

Cuando una persona tiene autoridad se la da poder, principalmente para que aporte una dirección, de orden y protección. En sociedades democráticas está asignación ocurre de abajo a arriba y en empresas normalmente de arriba a abajo.

Cuando es autoridad formal se asigna a una persona por parte de la dirección. Cuando es autoridad informal ocurre a través de la confianza.  Cuando son distintas las personas que tienen ambas ocurren los conflictos.

Después idenficamos las características de un buen seguidor. Identificamos características como  empatía, ser crítico, autonomía, fidelidad .., Después se nos pidió identificar cuales de esas características no corresponde con las de un buen lider, descubriendo por nosotros mismos que no las había. Son las mismas características.

¿Para qué necesitamos un lider?

Hay ciertos problemas que requieren conocimiento técnico como puede ser lo que ocurre cuando un médico de urgencias pide y ejecuta todo lo necesario ante un paciente que llega con una parada cardíaca. También hay problemas de tipo adaptativo que tienen que ver con el trato a personas y gestión de conflictos y que requieren un líder con valores.

Definición Liderazgo: Process of mobilizing groups to engage its challenges developing its skills for their progress and well-being.

Las conversaciones normalmente tienen un umbral de conflicto (con su nivel máximo y mínimo) que representa la zona de aprendizaje. Es importante para el líder hacer que los conflictos se mantengan en esta zona, sin que esté por debajo y no permita aprender o por encima y el conflicto tenga consecuencias negativas.

Un reto conlleva a tomar acciones lo que lleva a estar en la zona de conflicto.  ¿Cómo se sabe que está en la zona correcta?  El líder va girando entre  Observar, Interpretar y Actuar. Debe proteger el liderazgo que surge en estas conversaciones para no parar el proceso en si mismo y el propio liderazgo expontaneo.

Terminamos definiendo acciones para un reto elegido entre todos e identificando si las acciones requirieren de un líder más técnico , si requiere autoridad por parte de la compañía o un líder con valores.

 

Marta San Martín. @MartaSanMartin
Introducción al coaching. Cómo tener conversaciones diferentes

Marta nos enseño la técnica del Mirroring en la que se escucha a la persona que tiene un problema sin darle soluciones ya que normalmente esa persona tiene todo el conocimiento necesario. Hay que hacerle preguntas abiertas tipo «¿Cómo’, ¿Cuándo?, ¿Quién?, ¿Dónde?. La pregunta de «¿Por qué ?» no es recomendada porque normalmente crea en la persona que explica el problema una justificación que puede crearle incomodidad. Una cosa que sí se puede hacer es interrumpirse y refrescar para hacerle ver que se está escuchando con atención.

Hicimos el ejercicio de Mirroring en parejas, al final de cual explicábamos el uno al otro cómo nos sentíamos tanto el que explicaba el problema como la persona que hace de coach. Entre uno y otro hicimos un ejercicio de mindfuldness aprovechando que Marta es certificada y experta en el tema.

 

Keynote de Marta Pinillos. @pinillos_marta
La voz, la clave del éxito en tu comunicación

En este divertido e increíble keynote de despedida, Marta explicó la importancia de la comunicación ya que es el más usado. Realmente la comunicación cara a cara es un valor ágil por lo tanto hay que darle importancia a la voz para transmitir correctamente los mensajes.

  • Ritmo: el ritmo correcto debe ser entre 130 a 150 palabras por minuto. Si es menos el emisferio derecho que el que procesa de forma rápida se queda «dormido».
  • Volumen. Hay que manejar el volumen, bajando en las partes importantes más que subirlo para no parecer una verdulera.
  • Tonos: Hay que tener 5 tonos de voz distintos y saber manejarlos.
  • Modulación. Manejar la modulación haciendo cambios de riemo. No debe haber un ritmo constante para mantener la atención.
  • Dicción. Saber marcas las consonantes en las palabras importantes
  • Pausas. Hacer 4 ó 5 pausas ¿por minuto?
  • Entonacion. Saber marcar las palabras
  • Respiración. Tener una respiración diafragmatica y un tono no agudo porque aporta seguridad y credibilidad.

Con esto terminó el primer día. Muchas cosas descubiertas y a tener en cuenta.

SPIKES de investigación para reducir incertidumbre y estimar mejor con Scrum

En los equipos que se usa Scrum, es normal enfrentarse con integraciones con otros sistemas (PlugIns, servicios, SDKs,..)  de los cuales no se tiene suficiente conocimiento para poder estimar con precisión cuánto se va a tardar. Planificar una historia de usuario que incluya esta integración puede hacer variar el total de puntos realizados al final del Sprint, según haya sido más fácil o más difícil esa integración.

Para resolver esa incertidumbre, lo que hacen algunos equipos es añadir un SPIKE al Sprint previo a la propia historia de usuario. Un SPIKE no tiene puntos de historia asignados sino un deadline de término. Una vez resuelto el SPIKE y sabiendo cómo se hace esa integración, se puede estimar en el siguiente Sprint de manera más precisa.

Sin embargo, a esta aproximación le veo dos problemas y es la razón por la cual no suelo usarla.

  1. Al planificar un Sprint en el cual hay SPIKES sin puntos asignados, no se puede equiparar el numero de puntos del Sprint anterior (o la media de los últimos) . Ese SPIKE puede ocupar una parte significativa del propio Sprint y al final se completarán más o menos  puntos de historia según ese SPIKE acabe siendo más o menos costoso.  Por lo tanto, creando un SPIKE previo sólo estás retrasando la incertidumbre de la integración al Sprint anterior del que se desarrolla la propia historia de usuario que  usaría ese componente.
  2. Para resolver la investigación y desenmascarar todos los posibles problemas, normalmente se necesita trabajarlo tanto que su inclusión en una historia de usuario es casi directo. Por lo tanto personalmente prefiero que todo este trabajo que se ha hecho se vea reflejado en una historia de usuario, aunque sea sencilla, y permita el feedback del usuario/Product Owner al término del propio sprint sin tener que esperar uno más.

¿Qué opinas? ¿Usais SPIKES de investigación previa?

 

 

Charla sobre Scrum en mundos imperfectos

El viernes 27 de Mayo estuve dando una charla sobre Scrum en mundos imperfectos como parte de las actividades de AgileAlicante. Fué en las instalaciones de Sistel en Alicante, ofrecidas gustosamente a la comunidad para la celebración del evento.

Hablé de los requerimientos que tiene Scrum y que hacen que sea un framework hyperproductivo. Sin embargo estos requerimientos no son siempre fáciles de conseguir pero ello no quiero decir que cualquiera no pueda beneficiarse del agilismo y usar parte de lo que propone Scrum.

Hubo 15 apuntados (llenado el aforo) y como me gusta a mí, la conversación posterior fue muy interesante. Los asistentes comentaron sus dudas y problemas, sobre todo relacionados a la estimación y el presupuestar a clientes en base a proyectos, sprints o incluso historias separadas. Al no tener pizarra no puede explicar bien cómo propongo hacerlo pero haré un artículo en breve sobre ello.

Las diapositivas de la presentación puedes verlas aquí.

Quizá repita más veces el formato de mini-evento para que la comunidad AgileAlicante se conozca un poco más y que no quede solamente el University Day de Octubre.

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama «Variación de causa común«. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama «Variación de causa asignable«. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

Planificación estratégica Ágil mediante Releases

Definición de Release

Scrum y Agile en general trabajan con timeboxes. Estos timeboxes permiten trabajar al equipo o empresa aun ritmo constante entregando software iterativamente y siendo muy fiable en las fechas de entrega. Los Sprints se suelen hacer de menos de un mes y este tiempo es suficiente para el departamento de desarrollo en analizar, desarrollar y probar el software a entregar. Sin embargo, cuando estamos hablando del trabajo asociado con este software hecho por toda la compañía, el periodo de Sprint queda muy pequeño y se hace necesario hablar de peridos más largos llamados. En VSN estos timeboxes más largos que el sprint los llamamos Releases. Estos Releases los componemos de cuatro Sprints para así hacer cuatro al año.

Ventajas del Release

Un Release permite una definición estratégica del software más allá de lo que se puede preveer para un sprint. Se pueden definir uno o dos Objetivos de alto nivel y en base a estos se definirán los Epics e historias de usuario más importantes. Esta definición estratégica permite un trabajo sincronizado de todos los departamentos de una empresa. Los comerciales saben cómo enfocar sus ventas, los de Marketing pueden preparar la web y la información comercial, los de Operaciones pueden decidir con qué configuración de hardware funciona mejor,…

Definición de epics que constituyen el release por parte del Product Owner

Antes de comenzar el periodo del Release propiamente dicho, el product Owner debe decidir qué objetivo u objetivos tendrá el release y a partir de estos definirá una serie de Epics o historias priorizadas. También puede haber caracerísticas que no encajen con los objetivos pero que sean igualmente importantes para su trabajo con el resto.

Ponderacion de los epics por parte del equipo

El primer día del Release el equipo de desarrollo se reune para hacer una ponderácion de los epics e historias. Se puede usar el Planning Poker pero se puede usar cualquier sistema de estimación ágil. En VSN, usamos el siguiente método: Se preparan en columnas ponderadas con la serie de Fiabonnacci y bajo ellas distintos epics que se hayan ajustado a estos tamaños. Se hace una definición de cada característica a desarrollar, se escribe el titulo en una tarjeta y por turno rodado cada miembro pone la tarjeta junto a la que más se parece en tamaño. Explica sus argumentos para esa ponderación  para que el resto las entienda. Cada miembro cuando llega su turno puede ponderar una caracteristica nueva o modificar una ponderación anterior. Cuando todas se hayan leido todos los epics deben tener su tamaño relativo.

Encajamiento en Sprints

Una vez ponderadas los nuevos desarrollos hay que encajarlos en Sprints. Esto lo puede hacer el equipo en conjunto. Se recomienda poner en los primeros sprints las historias o epics más grandes y complejos. Estas historias que tienen un interfaz importante nuevo o que requieren investigación. De este modo, si algo de lo desarrollado en estos primeros sprints no se corresponde con lo esperado o hay que cambiar de tecnología, existen sprints antes del fin de Release para ajustar los problemas encontrados. En los Sprints finales se harán las historias pequeñas y que no ponen en riesgo el objetivo estratégico. Es importante conocer la disponibilidad de los desarrolladores (vacaciones en medio) y el nivel de historias o puntos que normalmente se usan para corrección de bugs o desarrollos urgentes. A partir de esta disponibilidad del equipo y la parte de cada sprint que se puede usar para Release se hace este encajamiento.

Feedback y reajuste de sprints siguientes

En cada final de Sprint se hace una demo de lo desarrollado al resto de la empresa y se muestra la lista de historias resueltas y las que no han podido resolverse. Con el resultado de lo desarrollado y teniendo en cuenta el trabajo pendiente para el release se puede reajustar el encajamiento de los sprints sucesivos. Es muy útil tener una forma de visualizar los bloques trabajo  que se retrasan para el sprint siguiente y los que se prevee que no entrarán finalmente en el release.

Retrospectiva Fin de Release

En el último día del Release es muy recomendable hacer una retrospectiva que incluya a todos los departamentos implicados en el Release. En este se pueden mejorar el modo en el que se ha hecho las entregas y la comunicación interdepartamental para mejorar y no cometer los mismos errores.

No estimes, rompe el trabajo pendiente

Estimar el trabajo pendiente es algo que se considera necesario para poder planificar el tiempo y los recursos de cara al futuro. Si trabajas con Scrum seguramente al principio del Sprint planificarás con tu equipo los puntos de historia que vais a meter en el sprint y también quizá las horas de las tareas. Gracias a esta planificación podemos tener «mas o menos» un sprint con una cantidad de trabajo controlada y una posible planificación de más a largo plazo en un release plan.

Si embargo, el trabajo de estimación realmente no es un trabajo que aporte valor al producto final. El que estimes con una precisión del 100% o del 20% no hará que el cliente obtenga más o menos valor y seguro que no pagará más por ello. Según la propuesta Lean debemos intentar reducir o eliminar aquellas tareas que no aporten valor al cliente y esta tiene pinta de ello. Entonces… ¿intentamos trabajar sin planificación del sprint o del producto sólo por esto?

Por otro lado, siempre se recomienda trabajar con historias lo más pequeñas posibles. La teoría de colas indica que con un tamaño de paquete de trabajo menor conseguimos una velocidad más constante que con tamaños muy dispersos. Además, desarrollando historias pequeñas, acortamos el tiempo de feedback y esto conlleva una reducción de errores. Muy bonito pero … ¿Cómo nos puede ayudar el tener historias pequeñas con el problema de la planificación?

Cuando tenemos historias más pequeñas conseguimos una homogeneización de los tamaños de las mismas. Esto es, hay poca diferencia entre la historia más grande y más pequeña que metemos dentro del sprint. Con un tamaño más o menos constante y una capacidad de desarrollo fija obtenemos una capacidad basada en historias por sprint. Según trabajamos así, Sprint tras sprint vemos que obtenemos un número más o menos constante de historias.  La misma precisión es la misma que se obtiene cuando estimamos por puntos. Esta cantidad fija de historias nos permite planificar el sprint y, si además rompemos mediante análisis las historias que componen el producto más allá del sprint, planificaremos los tiempos de entrega de producto.

Cuando el desarrollador se pregunta «¿Qué voy a hacer hoy?»

Esta pregunta se pueden hacer muchos desarrolladores todos los días cuando entran al trabajo. Hay mucho trabajo por completar pero.. ¿qué es lo más eficiente que se puede hacer?

Cuando se intenta tener un sistema Agile/Lean es muy importante que el flujo de trabajo sea llevado mediante sistema PULL. Para conseguir esto las tareas deben atraerse hacia las ultimas fases del desarrollo. También hay que intentar reducir la cantidad de Trabajo en Curso (Work In Progress,WIP) por lo que antes de empezar nuevas características hay que intentar completar antes las que estan en curso.

Para conseguir todo esto, y con el apoyo de un tablero kanban fisico o virtual, los desarrolladores pueden decidir qué hacer en base a estas preguntas.

1.- ¿TENGO ALGUN TEST FALLIDO QUE DEBO ARREGLAR?  –> ARREGLARLO

Muchas veces los tests fallidos se acumulan y sólo se arreglan al final de sprint. Esto provoca que haya una acumulación de desarrollos y tests que pueden hacer que el deadline o fin de sprint se retrase. Debería ser la prioridad principal el completar los desarrollos ya hechos arreglando esos fallos que se han encontrado antes de otra cosa.

2.- ¿EL NUMERO DE TESTS PENDIENTES HA ALCANZADO SU MAXIMO? –> PASAR UN TEST

En VSN, el equipo de desarrollo ha definido cómo número máximo de historias esperando el test a 3. Si en el daily stand-up se ve que ha alcanzado ese número, se reparten 2 tests entre los desarrolladores para aliviar esa saturación. Naturalmente, ningún desarrollador testea lo que él mismo ha desarrollado, sino lo que ha hecho otro.

3.- ¿TENGO ALGUN DESARROLLO EN CURSO? –> CONTINUAR CON EL DESARROLLO

Naturalmente, una buenísima manera de avanzar es seguir con la historia y las tareas que había en curso.

4.- ¿PUEDO AYUDAR A TERMINAR ALGUNA HISTORIA EN CURSO? –> AYUDAR CON ESA HISTORIA

Si hay desarrolladores a los que se puede ayudar hay que hacerlo llegado este punto. Puede ser mediante el pair-programming, puede ser haciendo alguna tarea que se puede paralelizar, puede ser invesigando algo en Internet que necesite. Lo que se pueda hacer para ayudar a terminar antes con las historias que ya están en desarrollo.

5.- EMPEZAR HISTORIA LISTA EN ORDEN DE PRIORIDAD

Si a las anteriores preguntas se ha respondido NO pues no hay mayor problema. Se elige una historia por empezar siguiendo el orden de prioridad  establecido y a desarrollarla

La parte impredecible de una estimación

¿Cuanto vas a tardar en terminar esta tarea? Esta pregunta puede resultar muy fácil de responder y hacer una respuesta con una precisión absoluta, o tambien puede resultar muy dificil y dar una respuesta que nada tenga que ver con lo que al final se termina tardando.

¿De qué depende?

En tareas como las que solemos hacer los desarrolladores de software, el resultado de nuestro trabajo no es solamente el código generado sino tambien se genera conocimiento para el propio desarrollador. Para identificar qué parte del tiempo se ha utilizado para generar la funcionalidad y qué parte del tiempo se ha utilizado para generar el conocimiento sólo hay que hacerse una pregunta:

¿Qué tardarías ahora si tuvieras que repetir la misma tarea?

Ese tiempo que responderías corresponde con el tiempo usado en la generación del producto y el resto fue el usado en la generación de conocimiento.

KnowledgeGeneration

En entornos en los que el lenguaje de programación es muy conocido y el tipo de producto final se ha hecho muchas veces, hay poca generación de conocimiento y el tiempo que se tarda se puede predecir facilmente.

LowLearning

Sin embargo en entornos de innovación continua muchas veces el tiempo de generación de conocimiento es la mayor parte.

HighLearning

Realizando pair-programming se reduce el tiempo impredecible ya que la en la tarea sólo se genera el conocimiento que no tiene ninguno de los dos componentes de la pareja.

PairProgramming

Este tiempo de duración desconocida puede llevar al traste cualquier deadline. En proyectos tradicionales waterfall puede provocar que no se llegue a tiempo y en proyectos Scrum provocan que los sprints se solapen, estando varios días del siguiente sprint terminando tareas retrasadas. Una manera de minimizar su impacto es reducir la cantidad de  trabajo en curso, reduciendo el tamaño de las historias y focalizando a todo el equipo en la consecución de la misma en lugar de tener muchas historias abiertas.