La Heurística en SCRUM | Deloitte España

Heurística, ¿qué es la heurística? Yo personalmente pasé unos cuantos años de mi vida adulta sin saber el significado de esta palabra, y todavía ahora cuando es utilizada por otras personas a veces me causa cierta confusión. 

Una forma que se me ocurre para explicarlo es mostrando acerca de nuestro día a día en los proyectos. Y más concretamente en un proyecto Agile.

Empezaré exponiendo un caso real, con un cliente que utiliza técnicas Agile, equipos Scrum y dónde yo ocupaba el rol de Scrum Master.

En ese proyecto teníamos diferentes problemas, y obviamente nuestra intención era solucionarlo. No sólo intentábamos corregirlos, sino que también aplicábamos un método.

Un par de ejemplos de los problemas que nos encontrábamos inicialmente eran:

- No llegábamos a realizar tanto trabajo como el que nos habíamos comprometido al principio del Sprint, ni tan solo al 80% que habíamos prefijado como aceptable.

El Sprint Burndown era “prácticamente” plano durante todo el Sprint

Al finalizar el sprint como siempre hicimos el Sprint Retrospective, la ceremonia de Scrum que entre otras cosas se dedica a identificar problemas e intentar diseñar una solución para ellos.

En mi rol de Scrum Master, propuse una dinámica consistente en realizar el método A3, método heurístico para la resolución de problemas, por ejemplo: “Trabajo completado insuficiente” y el de “Burndown plano”

Como su nombre indica, el método A3 consiste en escribir sobre un papel tamaño A3 los siguientes apartados (pueden ser diferentes en función de la organización, lo importante es que cada organización tenga identificados sus propios pasos para solventar sus problemas): 

1. Establecer el título del problema
2. Definir el problema si se desglosa
3. Establecer el estado deseado 
4. Definir las causas que son la raíz del problema
5. Proponer diferentes planes de acción
6. Implementar el plan de acción elegido
7. Especificar cómo se medirán los resultados del plan de acción ejecutado

A través de este método detectamos que:

• Para el problema del “Trabajo completado insuficiente” teníamos un cuello de botella en la capa de QA que era externa al equipo de desarrollo y teníamos muchas “User Stories” bloqueadas porque teníamos una dependencia con otro equipo que no estaba finalizada.
• En referencia a “Burndown plano” detectamos que al principio del Sprint no se introducían en el Sprint Backlog todo el commitment y durante todo el Sprint se incorporaban User Stories, hasta por encima del commitment del equipo.

Para el siguiente Sprint, creamos las tareas definidas en el plan de acción que acordamos en las hojas A3:

• En lo que respecta al “Trabajo completado insuficiente” decidimos incorporar las personas de QA al equipo, que atendieran a las ceremonias y fueran uno más en el equipo
• En la parte del “Burndown plano” se pidió que el Product Owner incluyera desde el principio del Sprint todas las User Story que le permitiera el commitment y que, si introducía una tarea o una User Story una vez empezado el Sprint, que lo hiciera quitando alguna User Story del mismo valor que no estuviera aún comenzada, siempre que fuera posible.

Al finalizar el próximo sprint validamos los resultados:

• En el “Trabajo completado insuficiente” vimos que se había mejorado, íbamos por el buen camino, pero el problema no estaba resuelto, así que decidimos hacer otra hoja A3.
• Finalmente, en el “Burndown plano” se vio que el problema había desaparecido, pero en su lugar había surgido otro, las User Stories se quemaban casi todas al final del sprint, en lugar de ir haciéndolo paulatinamente. Así que decidimos crear otra hoja A3 con este nuevo problema.

Con el resultado de las soluciones encontradas, bien documentadas, se puede ayudar al resto de la organización a encontrar soluciones más fácilmente. 

Los consejos resultantes fueron:

1. Incorporar las personas de QA dentro de los equipos
2. Introducir en el Sprint Backlog todo el commitment desde el primer día del Sprint
3. Si se introduce una User Story en mitad del Sprint, quitar otra del mismo valor que aún no esté empezada

Los problemas con el tiempo y con paciencia se van solucionando, pero siempre aparece uno nuevo, o la exigencia se vuelve mayor, y el proceso de mejora a través de la heurística se vuelve continuo.

Definición de heurística: 

En ingeniería, una heurística es un método basado en la experiencia que puede utilizarse como ayuda para resolver problemas de diseño, desde calcular los recursos necesarios hasta en planear las condiciones de operación de los sistemas. Mediante el uso de heurísticas, es posible resolver más rápidamente problemas conocidos o similares a otros conocidos. 

https://es.wikipedia.org/wiki/Heur%C3%ADstica#Ingenier%C3%ADa

Método How to Solve it de George Pólya:

https://es.wikipedia.org/wiki/Heur%C3%ADstica#Ingenier%C3%ADa

Heurística Agile por Deloitte

Deloitte tiene una muy amplia experiencia en proyectos, por lo tanto, ha podido crear una metodología y unas herramientas, Enterprise Value Delivery (EVD), que le permite implementar proyectos rápidamente porque ya tiene un catálogo de soluciones con instrucciones y herramientas.

Aun así, siempre hay situaciones nuevas en las que nunca nos hemos enfrentado, en ese caso el método heurístico nos ayuda. La experiencia de los profesionales de Deloitte y su aplicación de métodos heurísticos ha generado los siguientes consejos:

Consejos para los procesos

1. Minimizar el tiempo de feedback
2. Crear ritmo a través de cadencia
3. Realizar predicciones a partir de datos, no adivinar
4. Hacer visible lo invisible, transparencia
5. Reducir el Trabajo en Marcha (WIP, work in progress)  
6. Reducir el tamaño de los lotes de trabajo (de desarrollo a QA, por ejemplo)
7. Localizar la responsabilidad y el empoderamiento más cercano al trabajo

Consejos para la arquitectura

1. Usar antes que reusar
2. Simple mejor que complejo
3. Aplazar las decisiones costosas a revertir durante el mayor tiempo posible, pero no más tarde
4. Elegir la tecnología que se ajuste a la forma en que queremos trabajar, y no al revés

Consejos para la de ingeniería

1. Automatizar las pruebas
2. Automatizar los despliegues
3. Integrar lo antes posible
4. Hacer explícitas las suposiciones
5. Poner más de dos ojos en cada línea de código
6. La práctica hace la perfección, cuantas más releases se realicen más bien se harán
7. Eliminar código (no necesario)