Cadena de valor, fricción, impedancia y deuda en empresas Ágiles (II)

La impedancia es una idea que fue inicialmente planteada por Al Shalloway (director de NetObjectives), la que tiene cierto parecido a conceptos sugeridos en el pasado, pero ahora, incluyendo elementos de cuantificación. He decidido entonces basar éste artículo en su idea inicial, ampliándola y planteando algunos conceptos adicionales.

chessvsHuman

Humano menos inteligente + computador débil + mejor proceso
fue superior a
Humano más eficiente + computador potente + proceso inferior”

Del libro “Metáforas del Ajedrez, Inteligencia artificial y el cerebro humano”

Es así que podemos afirmar que buenos procesos (y sobre todo de mejora continua) nos darán mejores resultados que mejores herramientas pero… en general en muchas empresas con modelos tradicionales, ellos tienden a limitar a las personas o mejorar la tecnología en vez de apuntar sus esfuerzos a mejorar los procesos. Cuando un individuo comete un error, este es generalmente debido a un problema con la forma en que el proceso está planeado, en vez de estar relacionado finalmente con el empleado en sí. Por ejemplo, en un equipo donde sus integrantes no compartan los conocimientos, hay un claro inconveniente con los procesos que apoyan el trabajo diario y la comunicación. Ello a su vez puede ser causado originalmente por una mala selección, donde se contraten personas que deseen especializarse en una sola cosa en vez de ir hacia el modelo de aprendizaje en forma de “T”. Nuevamente el proceso inicial es el factor frágil de la cadena.

“La alta impedancia lleva al factor ´lotería´ (o camión) a ser 1. Esto es, el caso hipotético que personas de tu equipo saquen la lotería y dejen la empresa, comprometiendo así la fecha o entrega. Si el valor es 1, entonces tienes un riesgo muy alto”

Esto no quiere decir que se debería remover la importancia de las personas, pero sí apoyar un sistema adecuado para obtener mejores resultados y un ecosistema saludable. Lean tiene una aproximación estándarizada que permite lidiar con ello que se basa en 4 pasos:

1. Analizar el sistema y detectar sus puntos débiles
2. Buscar el motivo de porqué ellos están allí
3. Aprender de forma colectiva como cambiar el sistema
4. Sugerir un cambio pequeño que traiga gran impacto, implementarlo y volver al paso 1.

Como se puede ver, se debe omitir el tratar el hacer grandes análisis del problema en sí y deberá favorecer el tomar una pequeña hipótesis que tenga un gran impacto, ponerla en marcha y evaluar.

En mi artículo anterior (clic aquí para leerlo), vimos como la fricción puede frenar el desarrollo de software; ahora nos centraremos en la impedancia, la que es un fenómeno que tiene similar efecto pero debida a causas diferentes. Los siguientes elementos son factores a tener en cuenta al analizar la impedancia:

1. Como el trabajo a llevar adelante es seleccionado y por quién.
2. Tamaño y secuencia del trabajo a realizar
3. Estructura de la organización
4. Personas realizando el trabajo y sus interacciones

A mayor impedancia, mayor será la lentitud para desarrollar el software pero también se incrementará la cantidad de tareas a realizar.

Impedancia = Mayor lentitud + Más tareas

Decimos entonces que la impedancia es directamente proporcional a estos dos factores; a mayor impedancia, mayor será el tiempo necesario para realizar un conjunto de tareas. Esto implica nuevamente la creación de lo que en Lean se conoce como desperdicio; toda tarea adicional que no brinda valor al cliente pero que él tendrá que pagar indefectiblemente.
Imagínate un equipo donde las personas no compartan conocimiento (silos), ello aumentará indudablemente el número de desperfectos o “bugs” en el producto, ya que el resto del equipo no podrá revisar de forma efectiva el código, lo que creará a su vez un espiral de desperfectos, colas y costes adicionales para el cliente. Debido a ello, el cliente se negará a pagar más, lo que hará que los desarrolladores tengan que  trabajar “gratis” para cubrir los costes derivados de la falla de proceso.

“En Scrum a diferencia de las formas tradicionales, los procesos son constantemente evolutivos. Esto es, que la mejora es llevada adelante de forma continua por las mismas personas que hacen el trabajo, quienes los rodean o la organización en sí.”

En un equipo de Scrum, las personas comparten el conocimiento, lo que significa que cualquiera puede hacer casi cualquier cosa; se encuentran situados geográficamente en el mismo lugar y evalúan como mejorar su proceso de forma conjunta cada intervalos regulares, principalmente en 2 áreas de retro-alimentación.

1. Procesos grupales
Mejorar los procesos del grupo frente al desarrollo de software

2. Procesos de la empresa
Mejorar los procesos de interacción con la empresa y comunicárselo

Los silos no sustentan el flujo de trabajo; en muchas ocasiones ellos se deben a la estructura de la organización que no apoya a las personas para la entrega efectiva de valor a sus clientes. A su vez, esta casuística no apoya que todas las personas del equipo puedan comprender la experiencia de usuario, ya que los silos harán que algunos se centren en la implementación de la solución, perdiendo de vista la globalidad del problema que se está tratando de resolver.
Debemos recordar que aquellos equipos donde la información de la experiencia de usuario no fluye dentro del equipo en su totalidad (solamente hacia algunos roles que están encargados de ésta tarea), el foco será en terminar el trabajo pero no el ofrecer verdaderas innovaciones de mercado o lo que llamamos “disrupciones” del mercado.

Cuando se piensa y hace Scrum (pero no ScrumBut) esto debería ser diferente ya que los procesos se sustentan siempre y están enfocados hacia la experiencia del cliente, el cual es siempre la mayor prioridad. He visto en muchas empresas que olvidan éste último punto, lo que da como resultado una distorsión en los procesos y situaciones tan ridículas como competencias internas entre equipos que sirven a un mismo cliente o micro-silos dentro del mismo con separación de tareas por roles.

Hablemos de impedancia
La idea principal de la impedancia es la de tratar de identificar los desafíos que plantea la organización para mejorar la entrega de valor y cuantificarla. Al Shalloway  propone 7 áreas a evaluar para conocer la misma:

1. Tamaño y cantidad de trabajo en las colas de entrada de los equipos de desarrollo
2. Forma en que los equipos se encuentran organizados
3. Distancia entre integrantes de la empresa y a quienes le rinden cuentas o remueven sus bloqueos
4. Secuencia en la cual los trabajos son efectuados
5. Nivelación de trabajo dentro del sistema
6. Nivel de automatización logrado dentro del sistema
7. Cantidad de ciclos de retro-alimentación para verificar las acciones y asumpciones llevadas adelante (implementadas)

La idea es entonces identificar estos aspectos centrándonos primero en el equipo pero sin olvidar  la interacción con otros equipos y el resto de la empresa. Debido que Scrum inicialmente fue formado como un marco de trabajo aplicado a grupos de trabajo, muchos de los profesionales se olvidan que los engranajes van más allá y son en realidad un tejido complejo entre el mismo y las distintas partes de la empresa. La miopía a su vez puede generar la creación de procesos innecesarios (optimización local), o lo que es igual, desperdicio, lo que deberá ser atacado a tiempo y mediante la evaluación de la impedancia existente.

Incremento de impedancia
Teniendo en cuenta los valores anteriores, es posible cuantificar la impedancia en un flujo de valor (IFV o VSI en inglés). Las siguientes características pueden incrementar al IFV:

Relacionadas al trabajo
– Trabajo sin priorizar
– Lotes de trabajo extensos
– Más trabajo del que el equipo de desarrollo pueda gestionar
– Secuencia en la cual los trabajos son realizados. Suponiendo que análisis, desarrollo y pruebas se efectúan en etapas separadas, a mayor carga de una de ellas, mayor será la impedancia debido a la  disminución en la retro-alimentación y su consiguiente aumento del retraso.

Relacionadas a la forma en que el equipo está organizado
– Equipos que necesitan gastar mucho tiempo para integrar el producto luego de terminado el desarrollo
– Baja retro-alimentación sobre la calidad del sistema en su totalidad
– Silos dentro de los equipos (o micro-silos dentro del equipo, ej. UX y desarrollo)
– Compartir Roles dentro de Scrum.

Relacionadas a la geografía
– Equipos no residentes en un mismo sitio. A mayor distancia entre ellos, mayor será la impedancia.
– Roles diferentes que informan a distintos jefes.
– Factores culturales en la comunicación, de idiomas o costumbres

Relacionadas a la automatización
Menor automatización de pruebas, integración e instalación;  la impedancia aumentará debido a que:

  • Se tomará más tiempo para estos pasos, lo que enlentecerá la retro-alimentación por parte del cliente
  • Se tendrá que sacar tiempo de otras cosas para poder trabajar en las pruebas.
  • Se generará mas tensión entre las personas, lo que aumentará la posibilidad de cometer errores
  • Aumentarán las tareas tediosas, lo que influirá en la decisión de hacerlo cada menos tiempo, cosa que exacerbará el problema y bajará la autoestima del grupo.

Recuerda que siempre que se eleve el tiempo de los ciclos de retro-alimentación, se generará más impedancia, lo que a su vez aumentará el tiempo necesario para poder verificar si las hipótesis tomadas antes de crear el software son correctas. A su vez, esto último producirá que no se sepa si se está construyendo lo correcto, se generarán más hipótesis, se aumentará la cantidad de errores (bugs) y el coste de repararlos, entrándose en un peligroso círculo vicioso.

Disminución de Impedancia
Una vez que tienes clara  la existencia de la impedancia, es tiempo de trabajar en la disminución de la misma. Para ello tendrás que analizar los procesos, estructuras, forma de gestión de personas y todo aquello que la produzca. Scrum brinda un marco excelente de trabajo para su emancipación, siempre y cuando se lleva adelante de forma rigurosa. Veamos en que se basa Scrum para disminuir la impedancia:

Referente al trabajo
–  Utiliza incrementos pequeños de software
– Usa historias de usuarios pequeñas y medibles
– Utiliza prioridades claras (recuerda que cuando se reeplaza un nuevo requerimiento por otro, el dilatado se retrasará, haciendo que éste último sea más caro).
– Limita la cola de entrada del equipo de desarrollo a su capacidad real.

Equipo
– Crea equipos situados en el mismo sitio y de funcionalidad cruzada (cualquiera puede hacer casi cualquier cosa)
– Asegúra que los equipos cuenten con el apoyo de la empresa en la remoción de bloqueos y los conocimientos necesarios
– Emplea roles claros y bien definidos
– Modela equipos multi-funcionales donde todos pueden hacer casi cualquier tarea o al menos conocer como estimar las tareas o estar dispuesto a aprender como hacerlas

Secuencia del trabajo
– Utiliza TDD (no pertenece a Scrum pero está ampliamente aceptado)
– Emplea conceptos claros sobre cuando se considera una historia finalizada antes de comenzarla.
– Asegúra que desarrolladores, testers y UX (u otros) trabajan codo a codo con un objetivo común
– Limita la cantidad de elementos en la cola
– Enfatiza una cadencia estable

A su vez, automatizar todo aquello repetitivo y utilizar pruebas a diferentes niveles es una parte clave.

Medición de Impedancia
Sugiero realizar un dibujo como el siguiente, donde cada elemento que contribuya al aumento de la impedancia se plasme y se relacione. Una vez hecho esto, es una buena idea darle un valor numérico. En este caso utilizo fibonacci ya que a mayor cadena de elementos relacionados, mayor será la complejidad para eliminar la misma y su impacto.

impedancia2

El resultado final te dará un  punto de partida y cantidad medible que te permitirá cuantificar y posteriormente comparar si la impedancia disminuye.

A su vez, puedes dibujar un diagrama de de Ishikawa o de causa-efecto para ver donde se encuentra el problema.

Gracias por escucharme,
Erich,

Leave a Reply