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?

 

 

Eficacia vs Eficiencia en Scrum

Llevo tiempo dandole vueltas

Ultima mente creo que estoy dando el mensaje incorrecto sobre Agile, que no persigue la eficiencia ya que waterfall es mas eficiente. Todo esto surge de una de las lineas que vi como propuesta del Manifiesto Lean Kanban. No hay sistema teoricamente más eficiente que el waterfall. Cada fase está realizada por un equipo especialista que, sin cambio de contexto, pasa todo su trabajo de una a la fase siguiente. Sin embargo waterfall falla en cuando hay cambios a mitad de proyecto, o cuando hay alguien que no hace perfectamente su trabajo. Cosas que ocurren el 100% de los proyectos. Sin embargo, un equipo que pasa de waterfall a scrum tiene sensación de perdida de eficiencia por las siguientes razones:

  • Reworking. Cada vez que se enseña el software al cliente existe la posibilidad de que toque rehacer algo. Implica cambiar cosas que has hecho en un sprint en el sprint siguiente. También para que el software sea entregable al fin de sprint muchas veces hay que hacer trabajo extra para dejarlo listo.
  • Tener que integrar en cada sprint hace que se tenga que cambiar el contexto continuamente. Si desde el sprint 1 el equipo está peleando con integraciones, a primer momento parece no ser tan eficiente como estar solamente desarrollando. Sin embargo, esto convierte el gran problema de la integración final en una molestia desde el primer sprint.
  • Reuniones de Scrum : planning, daily, review y el refinement. A los equipos a los que se les tradicionalmente se les da una lista de tareas sin mayor explicación, les parece que son innecesarias todas estas reuniones… «Era más productivo cuando se me daba la lista de tareas».

Sin embargo, aunque no lo parezca Scrum hace que un equipo pueda llegar a ser mucho más productivo. Como indica el titulo del libro de Jeff Sutherland, se puede llegar a entregar el doble de valor en la mitad de tiempo que con metodologías tradicionales. Aunque esto no se consigue por la metra transición a Scrum y mucho menos en el primer sprint. Lo que sí que permite es el marco para que el equipo consiga gran eficiencia. ¿Cómo?

  • Promoviendo que no se haga más de lo solicitado («make the right think done»). No se debe escribir una sola linea de código que no tenga que ver con el objetivo de la historia de usuario y no se debe hacer una sola tarea o historia que no esté dentro del objetivo de sprint.
  • Protegiendo al equipo de las interrupciones. El equipo está expuesto a interrupciones para hacer burocracia, explicar o documentar su progreso y hacer cosas que no tienen que ver con su objetivo de sprint. El Scrum Master es responsable de proteger a los miembros del equipo.
  • Focalizando las reuniones. Cada reunión Scrum tiene su objetivo y su ventana temporal. Esto hace que las reuniones mismas sean más productivas y permite que durante el tiempo en la que el equipo no está reunido (work time) no tenga que cambiar de contexto por culpa de ellas. Hay que detectar y minimizar o eliminar las reuniones sin foco y que no aporten nada al equipo o producto.
  • Mejorando la comunicación del equipo, haciendo que estén mas coordinados y tengan menos esperas y colisiones entre ellos.
  • Acercando el feedback y testing al momento de desarrollo. Esto hace que la corrección tarde hasta 20 veces menos que si se hubiera hecho semanas después.
  • Permitiendo al equipo pensar de qué modo mejorar a si mismo. Al juntarse en las retrospectivas les permite analizar cómo eliminar los impedimentos y desperdicios (waste) para hacer más y más puntos de historia cada sprint.
  • Permitiendo hacer experimentos de mejora durante un sprint y evaluar si seguirlo o no. Un equipo puede probar algo que parece una locura durante un sprint y evaluar en la siguiente retrospectiva su resultado. De este modo es posible encontrar modos ingeniosos de mejorar la productividad sin poner en riesgo el proyecto.

La proxima vez que explique Scrum, no olvidaré en contar ambas facetas (efectividad y eficiencia). Efectivamente se prima la efectividad ante la eficiencia, pero hay que transmitir que se puede conseguir mucha más eficiencia con equipo Scrum que en equipos tradicionales.

 

 

La importancia del término «software funcionando»

Uno de los 12 principios ágiles dice claramente «El software funcionando es la medida principal de progreso».  Esto puede parecer muy claro cuando se están leyendo los principios de inicio a fin pero tiene aspectos que deben tenerse en cuenta.

¿Qué significa «software funcionando»? Seguramente haya tantas respuestas como ingenieros tecleando código. Una forma de llegar a un consenso de equipo sobre los criterios que lo forman es hacer entre todos la Definition of Done (DoD). Estos criterios pueden contener aspectos como mínimos de cobertura de test, de validación de código según reglas de Sonar u otro analizador, de tests manuales realizados por un QC, etc .. y no servir absolutamente para nada.

Hace poco en un proyecto subestimé la importancia de lo que significa «software funcionando». Me di cuenta de que debe contener todos los criterios que hagan del sofware que se está produciendo una herramienta real y completa. Con completa me refiero a que de nada  sirve probar historias de usuario ejecutadas sólamente con datos moqueados porque los servicios web (que posiblemente haga un tercero) no están listos, tampoco sirve que estas pruebas se ejecuten en un entorno que no tiene que ver con el entorno real en el que se va a vivir la aplicación… Si en el proyecto faltan integraciones, fases de deploy o cualquier otro paso posterior  estamos desarrollando en un sistema Waterfall por sprints, no estamos en un proyecto Agile.

Si no vamos realizando todas las fases imprescindibles (from concept to cash) de todas las historias de usuario completadas, estas no serán más que papel mojado y al terminar «nuestro trabajo» entraremos en un entorno de incertidumbre sin saber cuándo va a funcionar de verdad todo eso que hemos estado enseñando en los Sprint Reviews. El cliente seguramente ya no creerá en el proveedor cuando le muestre el progreso en historias completadas y perderá la confianza en eso que llamamos Agile.

Para evitar estos problemas, asegurate de tener el entorno real (o como el real) lo antes posible, asegurate de integrar todas las piezas conforme se va construyendo el software.  Si no lo consigues porque está fuera de tus dominios, al menos, ten claro que ha dejado de ser un proyecto Agile.

 

A vueltas con el Manifiesto Lean Kanban

Hace un par de semanas vi este tweet de David J Anderson, creador de Kanban para desarrollo de sofware. Sé que hace tiempo que viene dandole vueltas a tener un manifiesto Lean Kanban y no sé si este será finalmente el que tomen pero sí tiene muchos puntos para reflexionar. Empieza así:

I believe in…
Empirical Process over Defined Process
Kanban, Scrum y otras metodologías ágiles están basados en el empirismo: transparencia, inspección continua y adaptación. Definir los procesos es necesario para estandarizar el trabajo y buscar mejores formas de hacerlo pero la situación real de cada momento es lo que manda.

System Thinking over Analytical Thinking
System Thinking se caracteriza por visualizar cualquier trabajo u operación como una serie de pasos interconectados que forman un flujo. Una vez definido y estandarizado este flujo de trabajo es posible ser ejecutado por más personas sin depender de un análisis concienzudo de cada petición de cliente por parte de dirección. Permite escalar una organización, buscar la mejora contínua y el empowerment de los que trabajan en ella. 

Effectiveness over Efficency
A esta le estuve dando muchas vueltas. Siempre se piensa en la eficiencia como algo que hay que perseguir pero, ¿es realmente lo más importante?. Pensando en cualquier sistema adaptativo, lo primero que hay que conseguir es un resultado de la manera más simple y lo antes posible con los medios y los conocimientos que se tienen en el momento de empezar. Por ejemplo, si el cliente piensa en tener un coche dentro de un año, nosotros le entregamos un monopatín en dos semanas. Realmente no es la forma más eficiente de trabajar ya que podríamos empezar a construir el coche sin tener que rehacer nada, pero podríamos fallar completamente buscando la forma más eficiente desde el primer momento. La eficiencia se busca poco a poco, historia tras historia, iteración tras iteración. Hazlo ya, vuélvelo a hacer de forma más eficiente, hazlo otra vez de forma aún más eficiente, y otra y otra…
Flow Efficiency over Resource Efficiency
Tradicionalmente se ha intentado aprovechar mejor los recursos individuales que ocuparse en el flujo completo de valor, desde la primera fase hasta la última. La gente de backend haciendo servicios a todo trapo sin que posiblemente los de front end tengan tiempo de integrarlos a tiempo. Es como si yendo un grupo de amigos en varios coches a un concierto cada coche fuera lo más rápido que pudiera sin pensar en el resto de amigos. Hacer esto no sólo no sirve para nada porque el coche más lento es el que define a qué hora entrarán sino que provocan problemas de sincronización que hace que vayan aún más lentos.
Small Batches over Big Batches
Trabajar en pequeños lotes tiene una serie de ventajas: se entrega antes trabajo terminado y se obtiene feedback antes, se obtiene progreso basado en software funcionando más contínuo, emergen los problemas antes, se reduce el stock de trabajo sin entregar, se puede controlar mejor la calidad… ¿Qué más razones necesitas?
Pull System over Push System
Base del sistema Lean. No hacer más trabajo de lo que necesitan las fases posteriores. Por ejemplo, no enviar a testing más de lo que puede manejar, no planificar más historias de las que se pueden desarrollar, etc.. Y por supuesto no hacer más producto de lo que pide el cliente.
Emergence over Command and Control
Las empresas están aprendiendo a cambiar su estilo de dirección reduciendo capas de jerarquía. En lugar de intentar dirigir todo top-down, se deja espacio a los trabajadores a que seas sus propios managers y resuelvan ellos mismos los problemas. De este modo se puede conseguir que empresas grandes y pequeñas respondan rápidamente a los nuevos retos que requiere la sociedad digital.
Problem Focus over Solution Focus
Es facil empezar a pensar en soluciones teniendo en consideración solamente la superficie del problema, los síntomas. Sin embargo hay que analizar más el propio problema, buscando las causas raices del mismo mediante técnicas como 5Whys o Fishbone. Una vez encontrado y estando centrados en el problema raíz ya podemos buscarle soluciones.
Omission Error over Commission Error
Preferimos quedarnos cortos y tener la posibilidad de hacerlo bien en un segundo paso que hacer algo erroneamente y tener que corregir, arreglar, deshacer y volver a hacer. Lo segundo generá más retrabajo que lo primero. Por ejemplo, sacamos de alcance la parte de una historia de usuario que no está clara para desarrollarla más adelante con máyor información.
Products Development over Project Execution
Cuando desarrollamos software es facil centrarse en los requerimientos del proyecto (plazo, cliente, necesidades solicitadas,..) sin pensar que estamos realizando un producto que tiene una vida mucho más larga que el propio proyecto, que puede usarse por varios clientes o incluso que el mismo cliente puede solicitar cambios grandes en el futuro. Esto hace que debamos prestar atención a factores como la calidad de código, la adaptabilidad y una buena elección de la tecnología.

14 años y 103 sprints

Tal día como hoy 29 de Julio ha sido mi último día en Video Stream Networks.
Pongo punto final a una etapa en la que he aprendido mucho como profesional y persona. He aprendido a desarrollar con la calidad que necesita un sector como el de broadcast (software de gestión y emisión de contenido audiovisual para cadenas de televisión), en el cual los programas deben funcionar 24 horas al día, 365 días al año y si falla aunque sólo sea un espacio de milisegundos, hay millones de personas que se darán cuenta al momento.
Es un sector innovador que a su vez necesita de integraciones entre muchos distintos componentes de distintos fabricantes. Un entorno en el que las fechas de “puesta al aire” van moviéndose por variables como tener el edificio listo, la sala de racks, ahora se inunda la sala de redacción, ahora se retrasa porque hay cambio de gobierno y ahora para dos semanas tiene que estar todo funcionando porque el presidente de ese país va a inagurar el canal en directo.
En ese sector he crecido y he descubierto el único sistema capaz de manejarse como pez en el agua entre tanta incertidumbre y riesgo: el Agilismo. Estoy bastante seguro que gracias a cosas como a una entrega iterativa e incremental por etapas, una buena cobertura de test y un equipo motivado y muy creativo, VSN ha conseguido ser referente de Innovación año tras año.
Pero ha sido el momento de decirle adiós a VSN. Empiezo una nueva época en GFT, cuyos valores ágiles se ven claramente en cada rincón de su página web y sus redes sociales.
En esta nueva etapa espero seguir aprendiendo y conseguir la perspectiva que me falta al haber trabajado sólo en una empresa. Empezaré como Scrum Master pero espero que pronto pueda dar mis primeros tumbos como Agile Coach. Mientras tanto… que se prepare el equipo con el que me asignen al empezar porque tengo muchos planes para ellos (Insights, Management 3.0, Kanban, Lean…).
Atrás dejo mucho amigos que lo seguirán siendo. Les deseo de todo corazón que consigan todos sus objetivos. Se lo merecen todos y cada uno de ellos.

Principios en VSNÚltimo día en VSN

Presupuestar historias de usuario sueltas

En la charla del viernes 27 de Mayo sobre Scrum en mundos imperfectos salió el tema de cómo presupuestar a clientes basado en historias de usuario. En ese momento no tenía una pizarra y no pude explicar cómo pienso que es la mejor forma de hacerlo por lo que voy a dejarlo plasmado en este artículo.

Lo primero es conocer la capacidad del equipo de desarrollo en puntos de historias durante un sprint. Ese sprint puede ser de una a cuatro semanas.Lo ideal es tener ya la capacidad de unos cuantos sprints para tener una media. Para nuestro ejemplo, en Baylor Enterprises, vamos a decir que la capacidad de desarrollo son 45 puntos por un sprint de 3 semanas. No está nada mal 😉

SalidaPuntos

Lo segundo es conocer qué costes tiene la empresa en ese sprint. Estos costes son la entrada necesaria en euros para producir los puntos de historia. Para calcularlo sumamos sueldos de desarrolladores, administración, alquileres, electricidad,… Puedes sumar todos los gastos mensuales y hacer una regla de 3 para conocer los relativos al sprint. Para la Baylor Enterprises, mi multinacional, los gastos totales relativos a un sprint son 10.000 Euros.

Como imagino que no trabajas en una ONG, querrás que la empresa tenga beneficios, por lo que tenemos que aplicar un multiplicador a los gastos, y entonces obtenemos los ingresos deseados por sprint. Como CEO de Baylor Enterprises, decidí aplicar un multiplicador de 1,2 y así  obtener 12.000 Euros de facturación deseada por sprint.

Facturacion

Ya lo único que nos queda hacer es dividir ese beneficio deseado por sprint por los puntos de capacidad. Esa división nos dará los ingresos deseado por punto de historia. Como en Baylor Enterprises queremos una facturación de 12.000  € por sprint y generamos 45 entonces 12000/45 = 667 € por punto de historia. Ya tenemos nuestro número mágico.

Ya puedes presupuestar para los clientesuna historia de por ejemplo  2, 3 ó 5 puntos.  Sólo multiplicando el número mágico de beneficio por punto por la estimación en puntos realizada. Para un Epic con varias historias hay que sumar los puntos de todas las historias que constituyen el Epic.

Nota: Si llega un momento que se consigue subir la capacidad del equipo sin que lleve a un mayor gasto tenemos 2 buenas opciónes: Mantener el mismo precio consiguiendo más beneficio para la empresa en cada desarrollo o bajar el precio por punto de desarrollo consiguiendo mayor competitividad.

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.

Las palabras del Daily Standup se las lleva el aire

Esto fue lo que había estado observando en un par de Dailyes. Un desarrollador podía decir a sus compañeros con pleno convencimiento: «Hoy voy a reticular los splines y fluzear los vértices del condensador» y al día siguiente decir que en el día anterior había hecho cualquier otra cosa sin inmutarse lo más mínimo. Lo más normal es que ni uno mismo se acuerde de cuales eran los objetivos que se había marcado el día anterior. ¡¡ Y mucho peor !!! Podía haber fallado completamente en cumplirlos por causas ajenas a su voluntad sin ni siquiera darse cuenta ni saber sus causas.

Otra cosa que había observado es que a veces se llega a los Dailyes sin tener claro cuáles van a ser los objetivos para ese día. Frases como «En cuanto termine esto ya veré con qué me pongo» o «Ahora miro el Kanban a ver que será lo siguiente». En VSN hacemos los Daily standup a las 10 de la mañana, lo suficientemente pronto como para que sea el disparo de salida del día y lo suficientemente tarde como para que todo el mundo tenga claro ya en qué va a trabajar. El problema de no tener totalmente claros los objetivos para el día puede hacer que se acabe trabajando en las cosas urgentes y poco importantes que siempre surgen. Lo importante y no urgente se acaba retrasando hasta que es demasiado tarde. Además esto provoca que se acabe el día con la sensación de que aunque no se ha parado ni un momento,  no se ha hecho nada útil.

Eisenhower Matrix
http://www.gsdfaster.com/blog/wp-content/uploads/2015/02/eisenhower-matrix.jpg

Para evitar estos problemas, hemos llevado a cabo un experimento que por el momento está saliendo muy bien. Para el Daily todos llevan preparada un pequeña hoja (10cmx10cm) con la fecha y su objetivo (o máximo 2) para el día.  Usando estas pequeñas hojas leemos  lo que nos pusimos como objetivo el día anterior, si lo hemos cumplimos o no (y por qué) , cuál o cuales van a ser los objetivos para el día y qué bloqueos pueden ocurrir o qué necesidades vamos a tener para cumplirlos. Los Dailyes son ahora más productivos porque no se divaga con cosas que no tienen que ver con esos objetivos principales. Reuniones, tests, atenciones a soporte dejan de ser centro de conversación a no ser que hayan sido la razón para no cumplir lo importante.

TarjetaObjetivos

En el resto del día esa pequeña hoja encima de la mesa recuerda a qué se debe aferrarse. Conseguir este objetivo con la ayuda de herramientas como la técnica Pomodoro, reduciendo interrupciones, revisando el correo a horas fijas, gestionando correctamente las reuniones y automatizando lo automatizable… es otra historia.

 

Sentándose un día con un desarrollador

En Lean cuando hablamos de Gemba, significa que los que están a cargo de un equipo o una empresa se paseen o estén donde realmente ocurre la acción. En las plantas de producción tradicionales estos lugares son los pasillos donde se elabora el producto. En desarrollo de software el Gemba sólo se puede realizar sentándose con el propio desarrollador.

Sin embargo, lo normal es que cuando un líder, jefe o responsable se acerca para ver cómo está trabajando el desarrollador, éste se ponga en modo inspección y empiece a explicar qué está haciendo y cómo lo lleva. Lo que ocurre en ese momento es el Principio de Incertidumbre, lo que se quiere estudiar cambia su comportamiento solamente por observarlo. También es normal que el líder, después de esta más o menos breve explicación se levante y vuelva a su puesto dejando que el desarrollador continúe para no interrumpirle más.

¿Es esto suficiente? ¿Se pueden saber así los problemas reales con los que se enfrenta y ayudarle a realizar mejor su trabajo? Mi respuesta es que no. Para hacer un autentico Gemba hace falta que el desarrollador trabaje como si no estuvieramos ahí. Para ello tenemos que ponernos en pair programming y sentarnos al menos un día completo con él para que «se olvide de las cámaras».  Trabajando juntos de este modo empezaremos a conocer sus problemas con el  framework, la arquitectura, lo que le cuesta un cambio de requerimientos, de datos de entrada, etc … . También en esas condiciones son en las  que podemos hacer coaching y enseñarle cómo organizar mejor el código, mejorar en TDD para desarrollar con mejor calidad y ayudarle a ser más productivo y ágil.

¿Cuánto tiempo hace que no te sientas un día completo con un desarrollador?

¿Incluyo el trabajo de documentación en la estimación de historia?

Esta es una duda que nos surgió este sprint y que seguro que surge en más de un equipo. Aquí viene mi análisis.

Opción 1) Si todo el trabajo del escritor técnico está incluido en la capacidad del equipo o es un porcentaje fijo y no  realiza historias aparte de documentación.

En este caso, todas las historias tienen su parte de documentación, más pequeña o más grande. En este caso, en circunstancias estables, el equipo al completo desarrolla a una velocidad estable. Es importante valorar bien la parte del manual en las historias de desarrollo porque podría pasar el no llegar a completar el número esperado de historias, ya que la parte del manual que corresponde se había infravalorado.

Si la documentación NO forma parte de la definición de DONE de la historia. Como se puede realizar la documentación en otro sprint, tendríamos que revisar el tamaño estimado de esa historia cuando no se va a realizar en ese momento la documentación.

 

Opción 2) Si sólo una parte variable del trabajo del escritor técnico afecta al trabajo del equipo.

En este caso recomiendo no incluirlo, ya que impediría obtener la capacidad de la parte del equipo que sí que aportan el 100% de su tiempo. Podría pasar que distintos sprints en las mismas condiciones se tuvieran velocidades distintas dependiendo de si tienen más o menos trabajo en el manual. Haría más difícil la planificación por la variabilidad de esta velocidad del equipo.

Si la documentación SÍ está incluida en la definición de DONE, recomiendo una doble estimación, la del tamaño del desarrollo y de la propia documentación. En este caso, el equipo que está en el desarrollo del producto puede planificar cuántas historias desarrollar en base a su velocidad como equipo y el escritor técnico tener en cuenta su aportación y tenerla en cuenta a la hora de planificar su propio sprint junto con otras historias propias.