¿Qué es una metodología ágil y cómo puede ayudarme en mi asesoría?

¿Qué es una metodología?

Para lograr pasar de un modelo improvisado y reactivo a uno planificado y proactivo, necesitamos de una de las herramientas fundamentales para construir el sistema: los procesos. Como indicaba anteriormente, los procesos son los cimientos de nuestro sistema. Son la definición teórica de lo que habría que hacer en cada uno de los casos y en cada una de las situaciones que nos encontremos para ejecutar el negocio. Pero esos procesos teóricos e ideales que están escritos en un papel hay que poder aterrizarlos en el mundo real y  para ello emplearemos una metodología.

Una metodología es un conjunto de reglas y herramientas que me permiten aterrizar los procesos en la vida real, repartiendo adecuadamente los esfuerzos entre cada uno de los miembros del equipo y sabiendo cómo ajustar a cada situación y cliente esa definición teórica e ideal que hacen los procesos.

Por lo tanto, una metodología:

• Nos permite aterrizar los procesos en el día a día adecuándolos a las particularidades de cada cliente y cada ciclo de trabajo

• Nos permite asegurar un reparto equilibrado de los esfuerzos entre todos los miembros del equipo. Así no tengo personas que van desbordadas siempre y otros que prácticamente no tienen nada que hacer

• Nos va a proporcionar información operativa objetiva sobre cuál es el nivel de eficacia, desempeño y resolutividad de cada uno de los miembros del sistema para que podamos ir acoplando esa propia metodología a lo que nos vamos encontrando diariamente y a los aprendizajes que vamos haciendo a la hora de ejecutarla

En el mundo de la gestión de proyectos y equipos de trabajo, existen dos grandes tipos o familias  de metodologías:

• Metodologías predictivas, como puedan ser PRINCE2, PMP, PERT..

• Metodologías ágiles, como SCRUM, KANBAN…

Tras probar varios tipos de metodologías en asesorías he encontrado que la herramienta que mejor puede acoplarse a la casuística de este tipo de negocio, donde normalmente se trata de una empresa pequeña con recursos limitados, es una metodología ágil. Y dentro de las metodologías ágiles considero que SCRUM es el marco que mejor nos podía ayudar a conseguir estos propósitos. 

SCRUM para asesorías

SCRUM es un marco de trabajo que inicialmente nació para proyectos de desarrollo de software pero que se ha ido extendiendo hacia muchísimos sectores. De hecho, ahora mismo los bancos están implementando sus oficinas de AGILE y SCRUM para lograr poner en marcha todas estas metodologías. 

Lo que hemos hecho aquí es sintetizar todo lo que funciona de esta herramienta, ajustarla a la realidad de este sector y eliminar o reducir aquello que daba menos valor o no encajaba en el modelo de una asesoría. 

Las metodologías ágiles tienen su origen en la filosofía Lean. Filosofía que centra todo el desarrollo del trabajo en torno a tres pilares básicos:

1. La entrega de valor continuo, que se produce a través de los productos y servicios que proporciona nuestra asesoría a los clientes

2. Mínimo desperdicio posible, reduciendo los reprocesos a la mínima expresión. Recuerda que un reproceso es un proceso que debería haberse hecho de una manera determinada una vez y, a causa de realizarse de manera incorrecta, hay que repetirlo. Por lo tanto, un proceso en el que deberíamos haber incurrido en un coste, acabamos incurriendo en el doble, triple, o cuádruple, a causa de tener que repetirlo varias veces

3. Mejora continua. Aplicada a través de los equipos de trabajo y los procesos.

Otra herramienta en la que vamos a basar la aplicación de la metodología ágil es el ciclo de Deming. Dicho ciclo fue ideado por William Edwards Deming, un consultor que se desplazó de EEUU a Japón tras la devastación de la segunda guerra mundial para lograr reconstruir la industria. Este pionero desarrolló un excelente trabajo que, a día de hoy, todavía estamos aprovechando como estamos viendo en este ejemplo.

El ciclo de Deming habla de implantar la metodología de mejora continua como parte intrínseca del propio trabajo a través de ciclos de organización en los que seguimos el esquema PDCA.

El ciclo PDCA establece un esquema de trabajo para cada iteración planificada de manera que cuando voy a organizar el trabajo, primero, planifico qué es lo que voy a hacer dentro de ese ciclo. A continuación, ejecuto el trabajo dentro del ciclo. Al acabar el ciclo, compruebo que lo que he ejecutado era lo que había planificado. Y, por último, aprendo de lo que he hecho durante este periodo, no solamente a nivel técnico, sino también a nivel de desarrollo del propio trabajo, de los procesos o de la comunicación dentro del equipo. Por tanto, dentro de una metodología ágil, en lugar de estar trabajando en un continuo entregar de tareas voy a dividir el trabajo en ciclos y, dentro de cada ciclo, voy a usar el esquema PDCA. Planificaré lo que haré dentro del ciclo, lo ejecutaré, comprobaré que lo planificado y lo ejecutado coinciden, y aprenderemos de lo que hemos hecho reflexionando y tomando decisiones sobre qué vamos a cambiar para el próximo ciclo.

Normalmente el desarrollo de proyectos se ha llevado a cabo tradicionalmente mediante un modelo predictivo basado en considerar cuál es el objetivo que tenemos que alcanzar y, a partir de ahí, desarrollar en cascada hacia atrás, es decir hasta el día de hoy, todas las tareas, el tiempo que supondría su ejecución y la relación de dependencia que hay entre unas y otras para saber por dónde tendría que empezar hoy. Por lo tanto, en un modelo predictivo tradicional como pueda ser una metodología tipo PRINCE2 o PMP, lo que voy a hacer es, en relación al tipo de trabajo que tengamos que desempeñar, perseguir un alcance concreto, es decir, un objetivo a lograr. A partir de ese objetivo, voy a desglosar en tareas qué es lo que tengo que hacer para lograr la meta, aplicando el tiempo y coste que yo preveo que me va a llevar esa tarea de manera exacta en forma de cascada.

Lo que realmente ocurre es que el entorno en el que nos encontramos en el mercado está en constante cambio. Nos movemos en escenarios altamente cambiantes y esto hace que para lograr ese alcance exacto, fijo y determinado, esté siempre luchando contra el tiempo y el coste. Es decir, que trato de ahorrar el máximo tiempo posible o no desviarme de la previsión y ahorrándome el coste que pueda para quedarme dentro del presupuesto previsto.

En un modelo predictivo, el mayor reto que encontramos está en mantener bajo control el desvío que se produce por los cambios que van apareciendo conforme yo voy desarrollando ese proyecto. En cambio, un modelo ágil lo que busca es cambiar el paradigma. Darle la vuelta al concepto que tenemos de la gestión de proyectos diciendo: si realmente lo único que tengo fijo es el tiempo y el coste, porque al final tengo un personal en la plantilla de la asesoría y unos recursos determinados para lograr desarrollar el trabajo, lo que voy a hacer es enfocarme en lograr el máximo alcance posible, siempre y cuando dicho alcance esté mínimamente soportado por el mercado. Esto es es un término muy importante a interiorizar: mínimamente soportado por el mercado. En metodología ágil esto significa que el producto o servicio final que le estamos entregando a nuestro cliente cumple con los estándares de calidad que este mismo espera del mercado. 

Si tuviésemos un tiempo, coste o recursos ilimitados podríamos, probablemente, presentar un producto mucho mejor, pero aquí lo que estamos tratando de hacer es entregar el mejor servicio posible que seamos capaces de realizar en el tiempo y coste que disponemos, siempre y cuando esté mínimamente soportado por el mercado. Es decir, que cumpla con los estándares técnicos y de  calidad.

Así pues, una metodología ágil propone que en lugar de trabajar bajo un sistema que nos ancla a un diseño y planificación inicial que luego ejecutaremos en un medio o largo plazo (modelo predictivo), lo que vamos a hacer es una entrega continua de valor estructurada en ciclos más reducidos que el plazo máximo de entrega y en los que sigo el esquema PDCA para cada uno de ellos: planificación (plan), ejecución (do), revisión (check) y retrospectiva (act).

Por otra parte, la mejora continua es un elemento que únicamente se convierte en cambios tangibles y concretos cuando la institucionalizamos. Aunque esté pensando en cómo mejorar mi asesoría (algo que todos los asesores hacen cada día) mientras estoy en la ducha, esperando en un semáforo o mientras vamos por la calle, lo que ocurre es que esas ideas se acaban quedando solo en nuestra cabeza y apenas se traducen en cambios significativos en la asesoría. Sin embargo, si dentro del propio trabajo me fuerzo a parar y dedicar recursos a preguntarme cómo voy a trabajar mejor o qué es lo que voy a cambiar y, además, los implemento, porque forman parte del trabajo, cuando me he dado cuenta he conseguido implantar todas las ideas que han ido surgiendo en cada uno de esos ciclos. En consecuencia, en una metodología ágil la mejora continua forma parte de los ciclos de trabajo. Recordemos esa última parte del ciclo de Deming donde yo paro y me pregunto cómo logro mejorar mi forma de trabajar en el siguiente ciclo (retrospectiva / Act).

En resumen:

En una metodología predictiva tratamos de anclarnos a un diseño y planificación, donde iremos ejecutando en un medio o largo plazo, mientras que en una metodología ágil nos enfocaremos en la entrega continua de valor con un coste fijo y un alcance variable (siempre que esté soportado por el mercado), sin perder la visión.

Dado que la excelencia es un hábito, la repetición constante nos irá acercando hacia esa excelencia. Para asegurarnos de sacar el máximo provecho a cada una de las iteraciones que realizamos siguiendo esta metodología ágil; vamos a dividir el trabajo en plazos de ejecución más reducidos, que denominaremos iteraciones, y dentro de cada una de esas iteraciones iremos aplicando el ciclo de Deming. Así es como esa mejora continua se traducirá en cambios concretos y tangibles en nuestro día a día.

¿Cuál es nuestro negocio?

Recordar cuál es nuestro negocio resulta de gran ayuda para organizar adecuadamente las operaciones de una asesoría. Normalmente, cuando hacemos esta pregunta la primera respuesta que nos proporciona el sentido común y la lógica es la tarea que desempeñamos: «básicamente, mi negocio es asesorar a mis clientes, llevarles la fiscalidad de la empresa, gestionar todo su asunto o proyecto, materia laboral, llevar cualquier aspecto jurídico, etcétera”. No obstante, realmente ¿cuál es nuestro negocio?. El negocio no se encuentra en la tarea que desempeñamos, sino en el resultado que produce esa tarea. El cliente no nos contrata para que ejecutemos una tarea, sino que nos contrata para que le proporcionemos un resultado. 

Como nos enseña el reconocido gurú empresarial Peter Drucker en su libro La gerencia de empresas (Peter Drucker, Ed. EDHASA, 1991), si mi negocio fuese una fábrica de taladros yo podría pensar que mi negocio se encuentra en la fabricación de taladros. Ahora bien, ¿qué ocurriría si en el mercado alguien inventa un puntero láser que con solamente un toquecito hace un agujero perfecto, limpio, sin suciedad, sin ruido y sin dificultad en la pared? A partir de ese momento, probablemente, no vendiese ni un taladro más. ¿Por qué? Porque el negocio no se encuentra en la tarea que desempeñamos, sino en el resultado que producimos. Mi negocio no son los taladros, mi negocio son los agujeros en la pared. Por lo tanto, para asegurarme de que mi negocio es sostenible en el tiempo y lograr estar permanentemente adaptado a las necesidades del mercado, mi foco no tendrá que estar en desarrollar taladros, sino en cómo lograr cada vez hacer mejores agujeros en la pared. 

Este aspecto que parece de poca importancia, es vital a la hora de desarrollar una estrategia operativa de éxito: tenemos que asegurarnos de que nuestro producto y servicio sirve para cubrir la expectativa que tiene nuestro cliente con el mismo. 

Recordemos que nuestro cliente nos contrata únicamente por un motivo: para que seamos el vehículo para desplazarse de su situación actual a su situación deseada. El cliente, antes de trabajar con nosotros, tenía una situación determinada actual. Una situación que quería resolver, cambiar o mejorar. Nos contrata para que nuestro servicio le ayude a desplazarse a su situación deseada. Esa situación en la que tiene cumplidos una serie de objetivos, necesidades o deseos. Por lo tanto, mientras nuestro servicio sea efectivamente ese vehículo para desplazarse de la situación actual a la situación deseada, nuestra asesoría perdurará en el tiempo. En el momento en el que perdamos este foco, cosa que suele suceder con bastante asiduidad a la hora de prestar el servicio porque nos perdemos en ese día a día y en la ejecución de las tareas, probablemente nuestro negocio empiece su declive. Normalmente, cuando me he enterado de que existe un puntero láser que está haciendo agujeros en la pared, ya es demasiado tarde para dejar de fabricar taladros y empezar a pensar en fabricar punteros láser (quizá ese puntero láser ya exista como conoceremos en el capítulo de automatización y robotización).

SCRUM en una asesoría

Para la organización de las tareas, como adelantábamos anteriormente, nos basaremos en una adaptación para asesorías del marco original ágil SCRUM, que sigue el ciclo PDCA en cada una de las iteraciones que realiza. 

Todo el trabajo que vamos a realizar, lo vamos a clasificar en ciclos o iteraciones que denominaremos SPRINTS. Cada una de estas iteraciones tendrá una duración de 2 a 6 semanas. 

Mi recomendación es que se utilice la duración del mes natural. Haremos un sprint para enero, otro para febrero, otro para marzo, etc. Dentro de cada uno de estos SPRINTs seguiremos el ciclo  PDCA:

1. Plan: planificamos qué es lo que vamos a hacer ese mes.

2. Do: durante el mes ejecutaremos lo planificado.

3. Check: cuando acabe el mes revisaremos lo que hemos planificado, si lo hemos ejecutado de la manera prevista, y al acabar realizaremos la retrospectiva.

4. Act: La retrospectiva es ese ejercicio en el que nos vamos a preguntar qué es lo que ha funcionado durante el período y qué es lo que tenemos que mejorar. No tanto a nivel de cada tarea sino más bien a nivel de equipo y procesos.

Para clasificar las tareas que tenemos que realizar en cada uno de los clientes o proyectos que tengamos en marcha utilizaremos la pila del proyecto o pila de cliente. La pila del proyecto sería algo parecido a disponer de una bandeja en la que vamos a ir colocando las tareas, como si fueran folios o tarjetas, una encima de la otra. De forma que iremos agrupando en la parte superior aquellas tareas que vayamos a realizar en un plazo corto o medio y en el fondo de la bandeja, iremos acumulando aquellas tareas que ejecutaremos a largo plazo. 

Las tareas estarán adecuadamente detalladas y serán suficientemente pequeñas para que se puedan ejecutar de manera clara dentro de un sprint y, además, serán suficientemente grandes para que la unidad de esfuerzo, en la que prevemos que vamos a desarrollar esa tarea, sea entera. No podríamos tener en la pila tareas que requieran para su ejecución, por ejemplo, sprint y medio. En tal caso, las tenemos que dividir en tareas más pequeñas. De forma que todo lo que hay que ejecutar para un cliente lo tenemos acumulado en esa pila o bandeja. Dado que todavía no hemos desarrollado todos los procesos, la pila del cliente puede alimentarse todavía de lo que a día de hoy “sabemos” que tenemos que hacer para ese cliente. En un futuro cercano esta pila se alimentará en gran parte de los procesos que tendremos desarrollados.

Ahora bien, para mantener un orden y claridad, lo que vamos a realizar en el próximo sprint lo tendremos en otra “bandeja” separada que será la pila del sprint. La pila del sprint está compuesta por todas las tareas que yo preveo que voy a desarrollar dentro del ciclo inmediato, es decir, dentro del próximo mes (si queremos seguir la recomendación de utilizar los meses naturales como duración del sprint). 

En la reunión de planificación, que la realizaremos al inicio del sprint (el primer día de ese mes), cogeremos todas las tarjetas que están en la pila del proyecto y que queremos ejecutar el siguiente mes y las moveremos a la pila del sprint. Las  cambiaremos de bandeja. Además, durante el sprint utilizaremos una reunión diaria, o bien semanal, para hacer seguimiento del ritmo de trabajo que estamos llevando con todas estas tareas.

Respecto al esfuerzo, este nos va a indicar lo que nos cuesta completar cada una de las tareas. Utilizaremos puntos en lugar de horas o minutos. Empleamos unidades relativas porque, al tratarse de aproximaciones, SCRUM recomienda no emplear una unidad de medición exacta como es el tiempo, sino que utilicemos una unidad relativa como son los puntos. La estimación en nuestro caso la realizaremos empleando una aproximación por la que cada punto de esfuerzo equivaldrá a una cantidad aproximada de tiempo. Mi recomendación para una asesoría es que un punto equivalga a 10 o 15 minutos de trabajo. Si reducimos el tamaño del punto a 3 o 5 minutos, serán necesarias muchas tareas dentro del sprint. Sin embargo, si yo amplío demasiado la unidad de esfuerzo tendré poco especificadas o detalladas esas tareas y será más complicado llevar un adecuado seguimiento. Para asignar el esfuerzo vamos a utilizar la serie de Fibonacci. Emplearemos esta serie, creada por el matemático Fibonacci, donde cada elemento de la serie es el resultado de sumar los dos anteriores. 

De forma que empiezo en cero, de aquí paso al uno, luego al dos, a continuación al tres, después al cinco, sigo con el ocho, salto al trece, continúo con el veintiuno y a partir de ahí, la tarjeta será infinita. Una tarjeta infinita significa que tiene que dividirse en otras tareas para que podamos especificar mejor la duración de las mismas.

Usaremos Fibonacci porque conforme aumenta el tamaño de la tarea también aumenta el margen de error que tenemos al estimar el esfuerzo que va a suponer completarla. De forma que, cuando estoy estimando el esfuerzo de una tarea si tengo que elegir entre el uno o el dos, aparte de que la probabilidad de equivocarme estimando al elegir entre uno o dos es más pequeña, el desvío total que se produce si fallo en la estimación es mucho menor que si yo estimo la tarea en veintiún puntos y al final son trece o son más de veintiuno. Recordemos que si mi unidad de esfuerzo tiene una equivalencia de 1 punto cada 15 minutos, 21 puntos serán 5 horas.

Además, cuando tengo que elegir entre una duración de trece o veintiuno, generalmente resulta más fácil identificar si el esfuerzo está más próximo a veintiuno o a trece, que si tengo que elegir entre si me llevará uno o dos puntos.

En las estimaciones también utilizaremos el cero. El cero se utiliza cuando una tarea es considerablemente más pequeña de lo que supondría la unidad mínima de esfuerzo de un punto. Ahora bien, tengo que tener en cuenta que si tengo muchas tareas de cero puntos el esfuerzo total sumadas todas ellas puede suponer varios puntos. Por lo tanto, aunque puedo utilizar el cero para agrupar o tener pequeñas tareas que prácticamente me llevan una cantidad de tiempo o de esfuerzo notablemente inferior al punto, debemos tener precaución a la hora de agruparlas, porque pueden llegar a generar desvíos importantes. En tal caso conviene estimar la agrupación por el esfuerzo real que conllevará ejecutar ese conjunto de tareas.

Paso 1: La reunión de planificación

En la reunión de planificación lo que haremos será repasar esa pila del proyecto o cliente. En función de los objetivos que tenemos establecidos para cada uno de ellos en ese ciclo, es decir, qué es lo que tenemos que lograr o realizar dentro del sprint, cogeremos esas tarjetas de la pila del proyecto y las meteremos en la pila del sprint realizando una estimación del esfuerzo que conlleva cada una de las tareas planificadas. Además, nos aseguraremos que no tenemos a nadie con una sobrecarga de esfuerzo ni tampoco a nadie ocioso y por lo tanto, estemos desperdiciando la cantidad de esfuerzo disponible del equipo.

Recordemos que, frente a los modelos predictivos, en agilidad lo que es constante es el tiempo y el coste. Así que, lo que vamos a hacer es tratar de conseguir que el esfuerzo que dedicamos al sprint sea siempre fijo y mantendremos variable el alcance. Siempre cumpliendo con el valor mínimo que va a requerir el mercado. Osea, las tareas que sí o sí tienen que desempeñarse dentro de un sprint. Como, por ejemplo, cuando hay un vencimiento fiscal o completar las nóminas de un mes.

Por otra parte, usaremos lo que se denomina BURN DOWN CHART o gráfico de rendimiento, donde podemos ver la carga de esfuerzo que tenemos asignada dentro del sprint y el ritmo de avance que estamos planificando dentro del mismo para cotejarlo durante su ejecución con el ritmo real. 

Paso 2: ¡A ejecutar!

Durante el desarrollo del sprint llevaremos el seguimiento de la ejecución del mismo. Conviene que esto lo llevemos a cabo en el sistema de información que utilicemos. Hablaremos más adelante sobre este asunto. Además del sistema de información que vayamos a emplear para el seguimiento dispondremos de la herramienta de la reunión diaria o semanal, denominada SCRUM diario o SCRUM semanal en el marco original, con el objetivo de supervisar el ritmo de desarrollo de los trabajos que tenemos planificados en el sprint y facilitar la comunicación y proactividad dentro del equipo. Durante esta reunión, los participantes responderán a tres preguntas básicas:

1. ¿Qué hice ayer (o la semana pasada) para contribuir al objetivo del sprint?

2. ¿Qué voy a hacer hoy (o esta semana) para contribuir al objetivo del sprint?

3. ¿Preveo algún obstáculo que me impida entregar?

Esta reunión se realizará de manera diaria durante 15 minutos o bien de manera semanal durante un máximo de 45. De hecho, SCRUM recomienda que si es diaria se realice de pie porque así nos aseguramos que no se alarga en el tiempo.

Durante el sprint podremos utilizar el gráfico de rendimiento para supervisar visualmente el ritmo de desarrollo que llevamos completando tareas e ir verificando cada semana si esa previsión se está acercando a la realidad o nos estamos desviando y retrasando en exceso y, en consecuencia, tenemos que tomar decisiones para que al final, al acabar el sprint, tengamos completado el máximo trabajo posible. El objetivo de la agilidad recordemos que es mantener un esfuerzo constante y, por lo tanto, todo lo que yo he previsto que tenía que salir dentro del sprint, debe de salir. Así, sprint a sprint (ciclo a ciclo, mes a mes) nos vamos a ir acercando a ese objetivo final o a esa visión a medio-largo plazo que tenemos para cada cliente o para cada proyecto. En el caso de los clientes recurrentes el año completo de servicio. 

Paso 3: Revisión del sprint

Al acabar el sprint, comprobaremos el resultado que hemos obtenido a la hora de realizarlo. Es decir, qué hitos hemos conseguido y qué avances hemos logrado. Así que vamos a coger nuestra pila del sprint que inicialmente iba cargada con todas esas tareas que teníamos que desarrollar y comprobaremos qué se ha quedado por completar. Idealmente, no debería haberse quedado nada. Deberíamos tener las pilas del sprint completamente vacías y listas para que volvamos a hacer la siguiente planificación y cargar aquellas tareas que pretendemos ejecutar en el siguiente ciclo. Por lo tanto, cuando ha acabado el sprint, lo que revisaremos son aquellas tareas que se han quedado pendientes y decidiremos qué es lo que vamos a hacer con ellas: si las metemos otra vez a la pila del sprint para volver a estimarlas y planificarlas o si directamente las eliminamos porque ya no hay que hacerlas. Alternativamente podemos devolverlas a la pila del proyecto para estudiar su prioridad en futuros ciclos. También, en caso de haber quedado tareas sin completar, tendremos que aprender cómo evitar que vuelva a quedarse una tarea como esa pendiente.

Paso 4: Realización del ejercicio de retrospectiva

Llevaremos a cabo el ejercicio de retrospectiva tras revisar el sprint y antes de planificar el siguiente. El ejercicio de retrospectiva consiste en la aplicación institucional de la mejora continua. Consiste en decidir qué es lo que vamos a mejorar como equipo. Normalmente, este ejercicio requiere de una preparación del ambiente para entrar en calor y hacerlo de la forma más productiva posible. Podemos hacer algún pequeño ejercicio para romper el hielo, movernos un poco, y a partir de ahí, empezar a recolectar información. Conviene durante el ejercicio reconstruir qué es lo que ha ocurrido durante el último sprint. 

Idealmente ningún miembro del equipo debería asistir con las manos vacías a dicha reunión. Si llego un lunes por la mañana de septiembre, después de vacaciones, y tengo que pensar qué debe cambiar en las operaciones del día a día para funcionar mejor probablemente la única idea que aparezca en mi cabeza sea nada. Un consejo para lograr mejor rendimiento en las retrospectivas es tomar notas durante el mes de aquello que observamos que podría cambiar y mejorar. Acumularemos estas notas y el día de la reunión de retrospectiva las pondremos en común con el equipo.

Durante el ejercicio de retrospectiva vamos a realizar una tormenta de ideas. Pretendemos que todo el equipo lleve a cabo su aportación para ver qué es lo que tiene que mejorar y llevar un mejor desarrollo en próximos sprints así que una vez que todos hemos aportado al menos una idea decidiremos como equipo qué hacemos y qué no hacemos. Dicho de otro modo: qué es lo que se va a implementar y qué se va rechazar.

Por último, cerraremos el ejercicio poniendo por escrito qué es lo que lo que hemos decidido para que quede un histórico de las reuniones y lo podamos repasar de vez en cuando.

Una herramienta muy útil para desarrollar el ejercicio de la retrospectiva es el empleo de un modelo visual de estrella de mar. 

Esto se puede hacer en una pizarra en la que pintemos estos apartados o en un tablero digital. Aquí es muy importante que se haga con una aplicación individual de sugerencias de todos los miembros del equipo, o sea, que cada uno de los miembros coja una serie de post-it o tarjetas virtuales donde todos aportemos nuestras ideas. Si el ejercicio de tormenta de ideas se hace a voz alzada y únicamente se va añadiendo de forma colectiva información a cada bloque lo que tendremos dentro del equipo serán perfiles que siempre son los que hablan, se les escucha más y no tienen vergüenza ni problema en sugerir u opinar, y los que siempre están callados, son retraídos o les da vergüenza aportar. De esta forma, si queremos aumentar el número de personas que participan y, por lo tanto, la cantidad de ideas que pueden llevar a una mejor calidad en el proceso de retrospectiva, lo que nos aseguraremos es que durante el proceso de generación de ideas todos aporten como  mínimo una tarjeta a cada bloque. Es decir, cada uno de los miembros que componen el equipo tienen que proponer una o varias ideas de mejora en cada uno de los apartados del tablero.

El modelo de estrella se completa rellenando cada una de las partes que lo componen de la siguiente forma:

1. Empezar a hacer: Cada técnico, en función de lo que considere según su experiencia, tiene que decidir qué cosas vamos a empezar a hacer para funcionar mejor como equipo, como asesoría y como negocio.

2. Dejar de hacer: qué cosas no están funcionando y, por lo tanto, como no aportan valor, tenemos que dejar de hacerlas.

3. Hacer menos: qué cosas vamos a hacer en una menor cantidad porque aportan muy poco valor.

4. Hacer más: qué cosas vamos a hacer en mayor cantidad para poder trabajar mejor.

5. Seguir haciendo: qué cosas ya están funcionando y, por lo tanto, vamos a seguir haciéndolas.

Una vez aportadas todas las ideas y decidido qué vamos a implementar a partir de ahora podemos continuar la reunión con la planificación del siguiente sprint.

Aspectos clave de la metodología

1. SCRUM realmente es un marco de trabajo basado en la metodología Agile. Un marco dispone de un conjunto de herramientas y reglas que nos permiten gestionar un proyecto de una determinada manera.

2. Todo el trabajo de un proyecto lo dividiremos en iteraciones que irán en períodos fijos de 2 a 6 semanas. Recomendamos el mes natural. Dentro de cada iteración ejecutaremos el ciclo de Deming: Plan, Do, Check & Act.

3. En la reunión de planificación de cada SPRINT repasaremos la pila del proyecto para priorizar qué trabajo entrará en este SPRINT y qué trabajo quedará en la pila para posteriores planificaciones.

4. El esfuerzo es la capacidad de trabajo que puede completar un equipo dentro de un SPRINT. Lo mediremos en puntos y no en tiempo directamente.

5. El uso de puntos y Fibonacci en lugar de unidades de tiempo y estimaciones exactas nos ayuda a reducir el margen de error en las estimaciones.

6. Mediante las reuniones diarias o semanales agilizamos la comunicación, añadimos proactividad y nos auto-organizamos para conseguir el objetivo del SPRINT.

7. El Burn Rate (o % de completado) nos mide la efectividad de nuestra planificación. Su objetivo no es quedarnos por debajo ni por encima, sino cumplirlo. La filosofía de SCRUM, al contrario que las predictivas, no busca “estimar y ahorrar tratando de recortarle a lo estimado” dado que buscamos una entrega continua de valor y el tiempo y costes son fijos (el alcance es variable).

8. El Burn Down Chart nos representa el ritmo de ejecución que lleva el equipo en la planificación.

9. Al acabar cada SPRINT, paramos y empleamos el modelo de estrella para analizar “lo ocurrido” durante el SPRINT. Esto nos permite aprender no sólo del desarrollo técnico del equipo sino de la forma en la que estamos ejecutando el trabajo y crea una manera institucionalizada de aplicar la mejora continua.

10. Con cada iteración vamos aprendiendo a estimar mejor los esfuerzos y a adaptar el marco de la metodología a nuestras circunstancias y objetivos.

11. Durante las sesiones de retrospectiva es fundamental que todos los técnicos “aporten” al brainstorming. Para ello haremos un ejercicio de participación sobre la pizarra o board digital donde todos aportan sus ideas mediantes “post-its” o tarjetas virtuales sin que ninguna idea sea juzgada, en una primera fase, y priorizando aquellas ideas a implementar en una fase final.

Cómo usar la metodología en una asesoría

Recordemos los pasos que vamos a seguir para utilizar la metodología en nuestra asesoría. Estos pasos se realizan siempre en cada una de las planificaciones que vayamos a llevar a cabo mensualmente o en el ciclo de duración que hayamos decidido para nuestro sprint.

En primer lugar, para cada uno de los sprints, empezaremos con la reunión de planificación. Lo que haremos en esta reunión será revisar las pilas del sprint anterior. Vamos a repasar estas pilas, ver qué es lo que se ha quedado por hacer y decidir qué es lo que vamos a hacer con lo pendiente: si ya no importa y lo eliminamos, si ya lo decidiremos en otros sprints y lo mantenemos en la pila del proyecto, o si es importante y tiene que ejecutarse dentro del siguiente sprint. En segundo lugar, realizaremos el ejercicio de retrospectiva, como hemos explicado anteriormente. En tercer lugar, realizaremos el informe de gestión, que lo veremos en próximos capítulos. En cuarto lugar, empezamos con la reunión de planificación del siguiente sprint. 

Cuando empiece la reunión de planificación del siguiente sprint lo primero que haremos será calcular para este ciclo cuál será el esfuerzo del equipo disponible. Este cálculo lo llevaremos a cabo en función de:

• Las vacaciones que coge cada uno de los miembros del equipo dentro del sprint que vamos a planificar.

• Las ausencias previstas por  otro cualquier motivo a las vacaciones.

• El tiempo que debe descontarse de la jornada de cada técnico para desempeñar funciones que no incluiremos en la planificación del sprint. Por ejemplo, tiempo comercial.

• Las horas de trabajo que contemplan su jornada.

Posteriormente, para cada desarrollador, dividiremos su esfuerzo entre predecible e impredecible, siendo predecible lo que ya sabemos que va a tener que dedicar a actividades planificadas y que yo conozco de antemano en la propia reunión de planificación, e impredecible aquellas actividades que no sé si me van a aparecer o no y para las que tengo que reservarme un espacio de tiempo dentro de la planificación.

Seguidamente empezaremos a pasar tareas de la pila del proyecto o cliente a la pila del sprint, realizando la estimación del esfuerzo que supondrá la ejecución de cada una de ellas. Al terminar con todos los clientes revisaremos las pilas de proyecto para asegurarnos de que no nos hemos dejado nada y que está incluido en la pila del sprint todo lo que es prioritario para este ciclo.

Por último, comprobaremos que ningún miembro del equipo tiene una carga de esfuerzo asignada menor del 100% ni mayor del 110% con un objetivo individual de completar un mínimo del 90% de las tareas planificadas.  Recordemos que la estimación de esfuerzo la hemos realizado con aproximaciones de tiempo y usando Fibonacci, por lo que si el objetivo de cada técnico es alcanzar un 90% de tareas completadas y la asignación que le hacemos de esfuerzo máximo se encuentra entre el 100% y el 110%, tenemos un margen suficiente para que pueda considerarse una expectativa realista y razonable de rendimiento. Si alguno de los técnicos supera el 110% del esfuerzo previsto seguiremos los siguientes pasos para solucionarlo:

1. Si el esfuerzo global del equipo está por debajo del 110%, lo que significa que hay miembros del equipo a los que todavía se les puede asignar trabajo, comprobaré si alguna de las tareas del técnico cuyo esfuerzo excede puede reasignarse al técnico disponible, siempre y cuando tras la reasignación el que recibe las tareas no acabe excediendo el 110% de esfuerzo previsto. Si debido a las competencias técnicas del resto de miembros del equipo no puedo reasignar ninguna tarea proseguiré conforme al siguiente paso.

2. Si el esfuerzo global del equipo está por encima del 110% o no he podido reasignar tareas conforme al paso anterior:

1. Ampliaré la capacidad de esfuerzo del equipo incorporando más miembros al mismo y manteniendo los objetivos de tareas del sprint.

2. No ampliaré el equipo y repasaré las tareas que componen el sprint priorizando lo que debe salir adelante este sprint y devolviendo las suficientes tareas a la pila del proyecto, para volver a planificarlas en posteriores ciclos, hasta lograr equilibrar los esfuerzos del equipo.

Verificado el esfuerzo arrancaremos el sprint durante toda la duración prevista para el ciclo y durante el mismo llevaremos a las reuniones diarias o semanales de seguimiento hasta acabar el sprint. Entonces, empezaremos de nuevo a repetir este proceso.

En cuanto a los mecanismos de seguimiento que vamos a emplear, además de las reuniones diarias o semanales, emplearemos la métrica del Burn Rate y el gráfico de rendimiento, que nos van a ayudar visualmente a comprobar que lo que estamos utilizando en el día a día o el ritmo de consecución que tenemos es el adecuado para el alcanzar el objetivo del sprint.

Calcularemos el Burn Rate (o métrica de rendimiento si no nos gusta el inglés) sumando el esfuerzo completado y dividiéndolo entre el esfuerzo total previsto. Únicamente consideraremos esfuerzo completado al correspondiente a tareas terminadas, sin tener en cuenta el esfuerzo en curso. 

Por ejemplo, si he completado un esfuerzo de 100 puntos y la previsión para el sprint es de 200 mi burn rate ó rendimiento en la planificación será del 50%:

100 / 200 = 50%

Por otra parte, podremos apoyarnos también en Checklists de seguimiento, donde podremos ir identificando cuales son los ítems que tenemos que verificar a la hora de completar un trabajo, llevar el seguimiento de un cliente y que a ningún miembro del equipo se le escape ningún detalle para cumplir con los procesos. Los Checklists son herramientas de seguimiento que nos van a permitir asegurarnos que no se nos escapa ninguna tarea no definida en la planificación y que es importante para que nuestro sistema funcione. Pueden ser de dos tipos:

1. Mensuales, donde lo que hacemos es llevar un seguimiento de las actividades que tiene que hacer fuera de la planificación cada uno de los miembros del equipo. Por ejemplo, el responsable de finanzas: tiene que acordarse de enviar las facturas, verificar los pagos, hacer las llamadas de recordatorio en caso de que no hayan pagado, en caso de que se devuelva alguna remesa gestionar la devolución, etcétera. Cada uno de los miembros del equipo tiene un checklist mensual, donde lleva el seguimiento de este tipo de tareas que tiene que realizar.

2. Por cliente o por servicio. Esto significa que para cada uno de nuestros clientes o de los servicios que prestamos nos aseguramos que se cumplen una serie de cuestiones: tenemos la documentación necesaria del cliente, hemos realizado el proceso de onboarding, hemos verificado que tiene el certificado digital, que nos ha proporcionado X información, etc.

Resumen de aspectos importantes vistos hasta ahora:

En una asesoría, llevaremos a cabo una adaptación propia del marco SCRUM para el sector conservando los elementos que nos son de utilidad, eliminando los que no lo son e incorporando los que resulten necesarios para una mejor organización interna.

En la reunión de planificación, llevaremos a cabo la distribución de actividades en función de la priorización estratégica que decidamos para cada cliente o proyecto y el tiempo disponible del equipo. Durante el SPRINT ejecutamos lo previsto y llevamos a cabo la comunicación y seguimiento mediante las reuniones diarias o semanales.

Las herramientas que nos permitirán llevar a cabo un mejor seguimiento de todas las operaciones son además las reuniones diarias o de seguimiento: la plantilla de planificación, el sistema de información, los checklists, las métricas y el gráfico de rendimiento (burn down chart).

Predecible vs. impredecible

En la reunión de planificación, en su comienzo, habremos separado nuestro tiempo disponible en dos categorías: predecible e impredecible. Es posible que a estas alturas estés pensando que esta metodología es imposible de usar en tu asesoría porque no puedes predecir qué cantidad de temas te van a surgir a lo largo del día. Esta creencia es habitual, especialmente si tu modelo no tiene ningún tipo de sistematización. Sin embargo, recuerda que hay pocas cosas más impredecibles que el servicio de urgencias de un hospital y se trata de organizaciones perfectamente sistematizadas, puesto que cuanto mayor es la responsabilidad y menor el tiempo de reacción, más necesario es un adecuado sistema de trabajo.

Volviendo a la explicación de la metodología. Consideramos como predecible todo el trabajo que debe desarrollarse en un ciclo concreto de planificación y sabemos de antemano que deberá ejecutarse en ese mes. Por ejemplo, para un mes concreto, sabemos qué modelos de impuestos tendrán que presentarse, qué contabilidades tendrán que hacerse, qué informes tendremos que entregar, etc. El tiempo necesario para completar estas tareas será el “predecible”. Por otra parte, tendremos que atender determinados temas que desconocemos el día que realizamos la planificación del mes: si un cliente nos va a pedir una documentación, un informe determinado o si van a tener que venir a hablar con un asesor del equipo por una crisis que se ha producido entre los socios de una mercantil. El tiempo dedicado a estas tareas lo denominaremos “impredecible”. Será el histórico acumulado y el adecuado seguimiento de estos asuntos en nuestro sistema de información el que nos permitirá:

1. Saber qué tiempo reservar a tareas “impredecibles” a cada miembro del equipo en función del mes en el que nos encontramos y el puesto de la persona.

2. Saber el coste de resolución de cada uno de los asuntos para desarrollar estrategias de concentración, optimización o reducción de estos tiempos.

Por supuesto que el tiempo dedicado a impredecible podrá variar todos los meses. Será en la retrospectiva donde tendremos que elaborar estrategias y reunir ideas para adecuar cada ciclo siguiente a las necesidad de nuestra operativa. 

Recomiendo denominar a los asuntos gestionados en la categoría de imprescindible como “solicitudes”. Estas solicitudes se etiquetarán según el tema a gestionar en la misma: requerimiento fiscal o laboral, incidencia de pago, administración, consulta fiscal, consulta laboral, alta/baja o modificación censal, etc, y es conveniente emplear un sistema de gestión de solicitudes, incidencias o tickets donde podamos monitorizar el desarrollo de cada solicitud, el tiempo dedicado, el estado de las mismas y el histórico por cliente. Nuestro sistema de información o el conjunto de aplicaciones o herramientas de software que empleemos para construir nuestro sistema de información debería contar con esta funcionalidad.

Un adecuado seguimiento de los tipos de solicitudes, su relación con cada cliente y técnico del equipo y el tiempo dedicado no solo nos servirán para mantener controlada la rentabilidad sino que nos permitirá identificar causas y efectos que nos ayuden a optimizar ese tiempo impredecible y situarlo justo donde debe estar. Las solicitudes tendrán una estandarización de estados que nos faciliten también garantizar un adecuado nivel de servicio a nuestros clientes: pendiente de atender, en curso, en espera de terceros o cerrada.