Mes: enero 2014

1. Invierte dinero solamente en los proyectos que te permitan generar ganancias en el corto plazo.

2. La mejor solución a un problema es la que cuesta menos hacerla, incluso si cuesta más en el largo plazo.

3. Mantén controlada la deuda técnica en cualquier decisión que tomes y trabaja constámente en reducirla.

4. Las opciones que resuelven un problema rápido tendrán preferencia a aquellas opciones que ofrezcan soluciones superiores a largo plazo (tener en cuenta el punto 3).

5. Mantén la excelencia de calidad en tus productos y trátala como un elemento no negociable.

6. Reutilizar o reciclar conocimientos o materiales es mejor que adquirir algo nuevo.

7. Fomenta activamente las conexiones entre personas y motivación en los equipos y brinda el entorno adecuado para aumentar la creatividad. Incluso si no hay dinero, se pueden siempre encontrar opciones creativas que no cuesten a la empresa.

8. Ofrece liderazgo con transparencia total y expone la totalidad de las opciones claramente a todos los niveles de la empresa para brindar una meta concisa. Utilizar pensamiento sistémico es una buena opción para analizar la repercusión de cada meta.

9. Reduce la cantidad de informes que no producen valor y quédate solamente con aquellos que apoyan la toma de decisiones y son comprendidos por la totalidad de la empresa.

10. Analiza el flujo de trabajo y centra a cada individuo de la empresa a que ayude a elimina el desperdicio (todo aquello que no produce valor a tu cliente) y reducir las colas.

Prueba los 10 puntos, mejóralos, y vuelve al punto 1.

Gracias por escucharme,
Erich.

En la parte anterior te expliqué de forma práctica el pensamiento sistémico y su relación con las metodologías tradicionales, ahora quiero ahondar más y ver patrones no tan obvios, así como también su relación con Agile y Scrum.

Pensamiento sistémico y Scrum/Agile
Comencemos viendo el primer enunciado del manifiesto Ágil, el que imagino habrás escuchado en reiteradas ocasiones y artículos:

«Individuos e interacciones sobre procesos y herramientas»

La visión que tiene un practicante principiante de Agile es que debe poner a las personas sobre los procesos. Esto aunque es correcto, es tan solo una pequeña parte del iceberg. Practicantes más avanzados suelen tener una visión más amplia y complementaria.

Propiedades emergentes y conexiones
Como indiqué anteriormente, el sistema de pensamiento sistémico y modelos complejos elige una aproximación que radica en que se deberá entender al sistema en su totalidad comenzando por las personas y sus interacciones (conexiones), para así poder predecir su comportamiento.

«Una vez que vemos la relación entre estructura y comportamiento, podemos comenzar a entender como funciona el sistema, que le hace producir resultados pobres y como modificarlo para obtener un mejores patrones de comportamiento.» Donella Meadows

Si se desea influenciar o modificar una caraterística del sistema, se tendrá que atender a la totalidad del mismo en vez de un elemento en particular (el equipo como tal en vez de las personas en particular). Para ello existen dos reglas adicionales que derivan del pensamiento sistémico:

1. Dividir un sistema en partes para analizarlo destruye al sistema que se está tratando de entender. Esto va de acuerdo con la idea de que todo está interconectado y que si se destruye la conexión se modifica o elimina el sistema. Querer analizar el comportamiento de un perro cortándolo en 2 partes destruirá toda posibilidad de análisis.

2. Los sistemas muestran características que no son propiedades de ninguna de las partes que lo constituyen. Por ejemplo, auto-organización es una propiedad que no está asociado con la persona como entidad única.

Imagínate que te vas de vacaciones con 3 amig@s y deciden alquilar una bicicleta. Pese a diferencias de peso, fuerzas actuando en diferentes direcciones (entre las cuales se encuentra el rozamiento y el viento), engranajes y otros factores, se pondrán casi automáticamente de acuerdo y la bicicleta comenzará a rodar.

Este sistema muestra una capacidad que no corresponde con ninguna de las 3 personas, lo cual es una propiedad emergente: la auto-organización (aunque existen más propiedades emergentes en el ejemplo ¿Las puedes ver?).
Ahora comienzan los 3 a dar pedal y encuentran que todas las fuerzas se ajustan hasta lograr un balance. He aquí una propiedad emergente exclusiva de los sistemas auto-organizados: ¡el equilibrio!
Mas adelante como la carretera no está en el buen estado que creías inicialmente, se topan con el primer bache. Aquí pueden ocurrir 2 situaciones, pero omitamos por ahora el caso donde los 3 terminan en el suelo :-).
Lo que pasaría es que de manera conjunta, estabilizarán las distintas fuerzas (incluyendo la velocidad) hasta encontrar nuevamente un equilibrio.
Eso que parece trivial se da como resultado de la auto-organización. Organismos no conectados no podrían alcanzar este estado.
Es por ello que existe una característica que emana de los organismos auto-organizados que hace que los mismos puedan realizar los ajustes (autocorrección) necesaria para volver a un balance.

«Los organismos auto-organizados buscan pueden auto-corregirse luego de un cambio en el sistema «

Para el caso que el bache sea muy grande, entonces se podría terminar en el suelo, lo que es a su vez otro estado de equilibrio.
Piensa ahora esta situación con los equipos de Scrum. Eres un mentor y el equipo encuentra un problema, ¿Deberías resolverles el problema por ellos o presentarlo ante el grupo para que su auto-organización pueda actuar, realizar los ajustes y encontrar nuevamente un estado de equilibrio?

«Instruir al equipo de como ser auto-organizado», Oferta de trabajo en Infojobs.net

Esta última frase corresponde a la descripción de una oferta de trabajo de Scrum Master ofrecida en Infojobs esta semana. ¿Crees ahora que es posible que alguien instruya a un equipo sobre como ser auto-organizado?

Hay entonces 5 preguntas que te pueden guiar hacia el pensamiento del modelo sistémico:

1. ¿Qué estímulo obtiene que resultado?
2. ¿Afecta el resultado consistentemente cada vez que se emplea el mismo estimulo?
3. ¿Qué variables hay y cual es su relación?
4. ¿Los efectos son inmediatos hoy hay un retraso?
5. ¿Cuales son las variables emergentes y su connotación local y global?

Los sistemas de pensamiento evitan caer en la trampa de partir el sistema para su análisis y aceptan que ellos deberán ser evaluados en su totalidad como un todo (veremos luego como bajar de nivel sin perder la perspectiva global). Ello preserva todas las conexiones en el sistema y permite que surjan las viariables emergentes.

Hay que entender que todo se baso en el concepto de relaciones que tienen una causa y un efecto y que los modelos resultantes pueden ser muy complejos. Ello es lo opuesto a la creencia o el forzar un circuito cerrado donde todos los resultados pueden ser planeados por adelantado y predecibles.

El pensamiento sistémico asume que existen relaciones entre los eventos en el sistema que pueden ser medianamente conocidas y debido a ello, predecir el comportamiento global del sistema. La idea fundamental es que si llevamos adelante un conjunto de procedimientos, entonces podremos saber con más exactitud sobre los efectos.

Esta aproximación no es nada nueva, ya Aristóteles hace 2400 años nos decía:

«Todo aquello que conste de un conjunto de partes, y que no solamente sea la suma de sus partes como una pila de elementos no relacionados, existirá como un todo más allá de sus partes e invariablemente tendrá una causa»

Agile ofrece el enunciado visto anteriormente el cual puede ser malinterpretado por un practicante novato. Un practicante de Agile más avanzado verá una implicación más profunda donde conocerá la diferencia entre ser Ágil y practicar Ágil. Esto último implica que el marco de trabajo no puede funcionar correctamente en el largo plazo si no se tiene un pensamiento Ágil.
Muchos equipos y empresas intentan utilizar Scrum aplicando tan solo sus prácticas, infravalorando el pensamento sistémico o de causa-efecto, lo cual da equipos disfuncionales y fracaso en el corto plazo.

«Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.», principio Ágil

Por otro lado, el modelo de pensamiento sistémico implica que la gran parte de las cosas a controlar hace de forma indirecta. Un ejemplo claro de ello es la auto-organización de los equipos Scrum ¿Funcionaría la auto-organización en un equipo porque existe una órden de la compañía que indica que hay que trabajar de esta forma? o ¿Habría que presioanar otros «interruptores» para obtener este resultado?
Estos otros interruptores podrían ser: la motivación, el entorno adecuado, confiar en ellos, brindar un entorno adecuado, etc.

«Respuesta ante el cambio sobre seguir un plan», postulado Ágil

La única forma de enfrentar en un modelo sistémico a un nuevo elemento que desestabilice al sistema (o caos) es mediante una respuesta a los cambios que consiga un nuevo equilibrio.

«Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.», principio Ágil

Como Ágil se basa en un modelo sistémico, apoya la  característica emergente de los elementos auto-organizados  que consiste en buscar constantemente a un estado sostenible.

Debes tener en cuenta que en un sistema de muchas partes inter-relacionadas, la simple explicación de causa y efecto no es suficiente. La naturaleza sistémica de las influencias y otros factores que contribuyen, tales como contextos dentro de otros contextos, adicionan complejidad adicional a la visión general.

Lo que si es claro es que no se pueden pensar más como flujos lineales o gráficos con flechas de unos a otros, ahora tenemos que considerar varios bucles y las dinámicas ocurriendo en las distintas partes del sistema como un elemento vivo.
Esto se logra viendo a los procesos como movimientos cíclicos (grandes bucles) y dinámicos moviéndose e influenciando el uno al otro.
Para ello el pensamiento sistémico ofrece los llamados modelos causales, los que permiten plasmar mediante formas especiales de bucles las dependencias entre los elementos, así como también su comportamiento. Una vez realizado el esquema global, se puede alimentar el mismo con valores y ver su resultado.

En el modelo sistémico el comportamiento de un sistema emerge de la estructura de sus bucles de retro-alimentación. La raíz de las causas no son nodos individuales (como en el modelo orientado a eventos). Ellas son el resultado de las fuerzas que emergen de de un bucle particular.

Esto se puede efectuar con lápiz y papel y el aprendizaje de la creación de los bucles causales no lleva más que un par de días y sentido común, tiempo y esfuerzo. Los modelos causales pueden servir también como forma de alinear a un grupo y buscar puntos de conexión entre las personas.
Una cosa que suelo hacer con los equipos de desarrollo es mostrar mi modelo causal de una situación y pedirle a los integrantes que dibujen el suyo. De esa forma podemos conocer los diferentes puntos de vista de un problema y buscar una solución basada en la fusión de los distintos dibujos.
El siguiente articula el efecto del estrés en un equipo de desarrollo. La letra «S» indica que si el elemento al inicio incrementa(+), el que está en la punta también(++). «O» por su parte indica que si el elemento del principio se incrementa(+), el de la punta bajará(+-). Para el caso que el del comienzo baje, entonces se deberá invertir el signo del final para hacer su evaluación (-+).

Corresponde a mi diagrama mental (¡que puedes no estar de acuerdo!) que indica que si las estimaciones son más precisas (+),  bajará los costes del cliente, a su vez la confianza del equipo aumentará, lo que disminuirá los conflictos y la presión sobre dichas personas, dejando más tiempo para la investigación y desarrollo.
Si la precisión de los estimados baja, el coste al cliente aumentará, la confianza del equipo bajará, lo que incrementará los conflictos, disminuirá los tiempos para investigación y aumentará la presión. Como ves es un círculo que puede ser vicioso o virtuosoy se pueden emplear vínculos no medibles en otros diagramas como ser la presión o confianza del equipo. Este diagrama contiene un bucle de retroalimentación y 2 que lo potencian.
Los diagramas entonces contienen bucles causales, en los cuales las interconexiones de causa y efecto se expresa como una red de bucles de refuerzo  que o exponencia el crecimiento o declive (en el ejemplo 1 bucle y 2 de refuerzo). A su vez se cuenta con bucles de balance, los que actuan para contrarrestar la energía de los bucles de refuerzo. Sumado a esto se adicionan variables de entrada (y salida) las que alimentan los ciclos y la velocidad de rotación.

Estos mapas mentales te pueden ayudar a conocer de antemano los resultados posibles en una modificación de contexto, por ejemplo, la pérdida de motivación de un equipo Scrum, nuevo miembro del grupo, cambio en la empresa, nueva política, etc, asi como también detectar ciertas restricciondes que esten frenando al equipo o compañía ne producir más y darte una idea de que áreas atacar/eliminar.
Esto último no es muchas veces intuitivo, ya que por sentido común se realizaría lo contrario.

Si se desea ir un paso más allá, puedes transferir el modelo a una herramienta de software, la que te permitirá verificar los posibles resultados de un cambio o detectar una restricción de forma dinámica (alterando valores).

El comprender los modelos de bucles, interacciones y propiedades emergentes ponen claridad a varias características que hacen que Scrum funcione y son un paso importante y necesario para cualquier practicante Agile.

La creación de los modelos causales puede resultar en comportamientos dinámicos muy complejos, que hagan dificil predecir el futuro. No obstante, la idea es el comprender plenamente el pasado para actuar en el presente e influenciar el futuro tanto como sea posible.

Te recomiendo una lectura sobre pensamiento sistémico detallada (Systems Thinking and Complex Systems en Inglés), lo que sin lugar a dudas te redituará en un crecimiento exponencial en la comprensión de Agile y aumentará las posibilidades de éxito de tu empresa.

Lee la última parte del artículo aquí.

Gracias por escucharme,
Erich.

Pensamiento sistémico es un área que no se incluye en los cursos de Scrum Master, Propietario de producto, o metodologías tradicionales y considero que  su exclusión está intimamente relacionada con el fracaso de varios proyectos de software.

El pensamiento sistémico y los modelos complejos son el nucleo para todos los que deseen realmente ser asertivos con la implementación y utilización del pensamiento Agile y particularmente del marco de trabajo de Scrum/DSDM. A su vez, puede ser una herramienta de principal apoyo a aquellos individuos que empleen marcos de trabajo más tradicionales.
Podrías por ejemplo llevar adelante Scrum, pero su resultado sería sin lugar a dudas menos efectivo si no conoces los modelos de pensamiento sistémico y como analizar su complejidad.

Pensamiento sistémico y el modelo tradicional
Imagínate por un segundo que tiras una moneda al aire y quieres predecir de que lado caerá. En realidad, la probabilidad de que aciertes será bastante alta.
Imagínate ahora que trabajas en una empresa que emplea metodologías tradicionales y que te solicita documentes el proceso y protocolo. Esto se podría ver algo así:

1. Se obtiene una moneda
2. Se tira al aire empleando una fuerza moderada que a su vez estimule su giro
3. Se espera a que la moneda caiga
4. Se estima que la moneda caerá aproximadamente un 49.5% cara, 49.5% cruz y 1% en el borde.
5. Se repite el proceso

Podrías predecir que el resultado final será de +- 50% cada lado; a mayor número de tiradas más será la exactitud de tu predicción. A su vez, si la empresa te solicitase dibujar un plano de una máquina para tirar monedas, ella podría desarrollarse y verificarse con los resultados aproximados descritos en el documento. El proceso podría verse algo así:

1. Análisis y caso de uso (lo realizado anteriormente)
2. Construcción del prototipo
3. Validación de los valores de resultado con estimaciones previas (49.5,% 49.5%, 1%)
4. Instalación de la máquina en donde el cliente solicite
5. Mantenimiento y reparación para el caso que algo falle
(el fallo se detectaría si la moneda no es lanzada o cuando no exista una relación entre los resultados estimados. Esto podría darse, por ejemplo, debido a que la misma ya no es lanzada con giro y aterriza siempre en la misma cara).

Imaginemos ahora otro escenario:  trabajas en una empresa y te solicitan que reduzcas el precio de un producto en 1%. Evidentemente sería posible documentar los pasos pero… ¿Podrías hacer lo mismo con las consecuencias?

Si bajas el precio del producto, esto podría traer como resultado un conjunto innumerable de consecuencias, desde un aumento de la venta, una guerra feroz con la competencia, clientes que sospecharían que la reducción implica también una bajada en la calidad o sientan que el producto no es más exclusivo, tiendas de bajo coste queriendo venderlo o de alto rechazando al mismo, etc. A su vez, esto quizá afectaría a otros productos de tu compañía, lo que podría terminar en una venta mayor a la esperada o la empresa dando quiebra unos años mas tarde. En el primer caso, podrías obtener un ascenso, lo que aumentaría tu sueldo y te permitiría comprar una casa y darle empleo a un conjunto de persona;  en el segundo, que tuvieseses que buscar un nuevo trabajo, lo que quizá te daría tiempo para estudiar sobre pensamiento sistémico y aplicarlo en tu futura posición.
Como ves, un simple y único evento acarrea un número inimaginable de consecuncias y escenarios, aunque podría también no pasar nada -aunque muy improbable-  y es otro resultado.
¿Cuál es la diferencia entre el primer y segundo ejemplo? ¿Son estos eventos totalmente impredecibles o existen reglas que permintan «domesticar» sus posibles resultados?

Cuando tiras una moneda, este evento te involucra a ti en primera persona y se realiza en un ambiente «controlado«. Cuando bajas el precio, la situación es completamente diferente ya que existe un número elevado de entidades inter-relacionadas.

«Un sistema es un conjunto de elementos interconectadas de tal forma que produce sus propios patrones de conducta»

Los clientes están conectados con el precio, competidores al valor de tu producto y margen de mercado disponible, prestigio de la marca, el gobierno a las regulaciones de mercado antimonopólicas, etc. El efecto de las consecuencias factibles es claramente ilimitado.

El modelo de pensamiento sistémico
La pregunta evidente es… ¿Porqué es esto así?
Obviamente se da como consecuencia directa de la conexión entre las partes involucradas. Si no hubiese una conexión entre ellas, el ciclo de causa-efecto pronto se dentendría de la misma forma que una rueda a la que no se le da más impulso dejaría de girar. Es interesante tener en cuenta que el ciclo de causa-efecto es a su vez retroactivo, esto es, existe un conjunto de causas que dieron como resultado la bajada de precio en el presente, por lo que la misma iniciará consecuencias en el futuro, haciendo la expansión de ellos en el tiempo y espacio.

«El ciclo causa-efecto es siempre retroactivo»

(c) 2011, Ishan Arora

Es importante destacar que el requisito indispensable por lo que ello ocurre es porque se trata de un sistema abierto, y es esa exposición la que genera la causalidad de hechos.

«Para que un sistema tenga una energía constante, el circuito debe estar abierto, ya que la energía debe ser importada del exterior, desde el exterior de sus límites .»

Déjame ponerte un ejemplo de la importancia del sistema abierto… imagínate un equipo de desarrollo de un producto de software donde no exista una retroalimentación por parte del cliente. Evidentemente la motivación y el «feedback» externo que es la energía que hace girar la rueda se irá perdiendo poco a poco hasta el punto donde los integrantes del proyecto no estén interesados en continuar adelante o hayan finalizado con todas las tareas.

«Parte de la energía es almacenada para impedir la desintegración futura, otra parte es transformada por y para las necesidades del sistema.»

Se podría adicionar más energía al sistema y así girar la rueda incrementando el salario del empleado, pero una vez que el mismo se acostumbre al monto, el proceso iría en declive hasta frenarse nuevamente. Es por ello que hay que no pasar por alto cuales son los motivos que apoyan a un equipo de personas.

Pensamiento sistémico y modelos parcialmente abiertos
En las metodologías tradicionales se tratan a los modelos como  parcialmente abiertos (una rueda con pocos agentes externos que la muevan o en ciertos momentos). Las causas suelen tener una sinergia al comienzo del proyecto y congelarse tanto como sea en etapas posteriores. Ello se logra documentando diferentes variables al inicio, como ser los requisitos y riesgos.

Ello se llevará adelante mediante la evaluación de los problemas (efectos) vistos en proyectos anteriores, esto es, que la idea de que caiga un meteorito y destruya el servidor conteniendo los códigos fuente o haya un ataque extraterrestre (mas allá del suceso del cine)  sea una posibilidad remota, por lo que se descarte.

Para el caso de aparecer un riesgo documentado durante la vida del proyecto, se seguirán los pasos articulados inicialmente en el documento. Es importante entonces preguntarse:

¿El modelo tradicional resulta efectivo cuando se trabaja con elementos inter-relacionados?

A mi parecer, la causa-efecto de un modelo medianamente cerrado tiene varios inconvenientes: un cliente podría descubrir por sí mismo nuevas formas de resolver un problema mientras se encuentra el software en etapa de desarrollo, las cuales no podrían ser fácilmente adicionadas a la aplicación por tratarse de un sistema medianamente cerrado o controlado. Cualquier adición o cambio podría introducir o abrir nuevos caminos, lo que este tipo de metodologías trata de mitigar.
Por el otro lado, podría haber riesgos no documentados y tener que interrumpir una etapa para buscar una solución o dejarlo para el final del desarrollo por no haber personas disponibles para atenderlo.
Adicionalmente, la base de las metodologías tradicionales tal cual se conocen se basan en un modelo semi-estático de piezas (o recursos) que se encajan o remueven para el fin de satisfacer una demanda (modelo Tayloriano). Esto queda claro cuando se emplean los gráficos de GANTT, en donde se adicionan o remueven personas u otros elementos a un proyecto sin evaluar su causa-efecto. El proceso funciona en base a saciar necesidades, esto es, se asocia una persona a un determinado proyecto porque tiene los conocimientos requeridos para llenar la necesidad.

Ello aunque es correcto, implica solamente una visón parcial de la situación donde no se analiza la repercusión o efecto del cambio en la cadena de conexiones en el sistema en su totalidad y su causa. Es importante preguntarse entonces:

¿En una empresa de software, la creación de un producto se parece más al ejemplo de la moneda o al de la bajada de precio?

El pensamiento sistémico ofrece una forma diferente de aproximar las situaciones, y aunque es la base del pensamiento Agile, las técnicas pueden ser empleadas en cualquier forma de trabajo.

En la segunda parte de este artículo iré más allá mostrándote porqué el nucleo de Agile y Scrum es sistémico y considero su desconocimiento puede ocasionar el fracaso de uno o más proyectos de software.

Gracias por escucharme,
Erich.

El tema de un Scrum Master a tiempo parcial es una de las inquietudes que más he encontrado al hacer consultorías, en los cursos de certificación que he dictado o en mis trabajos previos como Scrum Master.

¿Debería ser el pusto de Scrum Master de jornada completa o puede ser un role compartido?

Parte de la respuesta lo abordé en las entradas anteriores; detrás de esto está la suposición implícita que el Scrum Master no es un role de jornada completa. La mayor parte de las conjeturas se basan en la idea que el fusionar dos roles puede hacer un ahorro sustancial de dinero y así incluir las responsabilidades de ambos en una sola persona.

Es casi inmediato el comprender que un un miembro del equipo de programación es de jornada completa porque sin el no habría software posible, se le puede ver escribiendo código, se lo ve sentado enfrente del computador y ello implica su necesidad. El Propietario del producto es otro ejemplo, se pasa todo el día planificando las características del producto y trabajando en el mapa de ruta, negociando con las partes interesadas, priorizando, descomponiendo historias de usuario, etc. Sin embargo, es difícil para las personas que recién comienzan con Scrum el imaginar un Scrum Master como de tiempo completo.
He trabajado como Scrum Master por mucho tiempo en diferentes empresas y paises, desde pequeñas hasta muy grandes.Es un trabajo muy dificil ya que requiere de muchas habilidades y energía y debo decir que la mayor parte de mis días comenzaban temprano en la mañana, transcurrían muy frenéticamente y finalizaban siempre con mucho trabajo.

Por otra parte, las empresas que recién comienzan también piensan que es el grupo quien dicta lo que se hará y nunca el Scrum Master. Esto en realidad no es tan así, ya que este último puede indicar que se necesita mejorar un área, por lo que se debería probar una técnica por 2 semanas. Luego el equipo tendría que evaluar si funciona, y de ser así incluirlo.

En mi criterio, quienes se preguntan que hace un Scrum Master de tiempo completo no conocen lo que este hace en realidad. Raramente en las empresas que trabajé como Scrum Master tendría tiempo para «compartirme» entre dos grupos. Estoy de acuerdo con Bernd Schiffer sobre las tareas que debe hacer un Scrum Master y he complementado ellas con otras que han ido surgiendo con el paso de los años:

1. Facilitar cualquier reunión del Equipo; incluyendo preparar, moderar y procesar posteriormente los resultados de la reunión

2. Organizar y moderar las retrospectivas.

3. Asesoramiento individualizado a los miembros del equipo

4. Mediar en conflictos que surjan durante el desarrollo del rpoducto

5. Ayudar al equipo a tomar decisiones

6. Fomentar la auto-organización del equipo

7. Mediar en el conflicto general entre los objetivos del Equipo y los objetivos del dueño del producto (alta
calidad técnica vs. más características).

8. Continuamente aprender, leer y reflexionar sobre cualquier cosa con respecto a Agile (por ejemplo, visitar grupos de usuarios, asistir a conferencias, leer libros, escribir blogs, etc)

9. Dar soporte a los miembros del equopo y a la organización con respecto a todo lo que es Agile.

10. Ayudar al Equipo a crear radiadores visuales.

11. Dar retroalimentación al equipo.

12. Fomentar el uso de prácitcas de ingeniería dentro del equipo de desarrollo

13. Desafiar al equipo con innovaciones de gestión Agile.

14. Intercambiar constantemente puntos de vista, técnicas y experiencias con otros Scrum Master de la empresa a través de comunidadades de práctica.

15. Ayudar al Equipo y Propietario del producto a escribir y separar las historias de usuario

16. Ayudar a las partes interesadas y dueño del producto a comprender como escribir y separar las historias de usuario.

17. Ayudar a las partes interesadas y propietario del producto a crear una visión del producto.

18. Ayudar al propietario del producto a comprender como organizar los elementos de la pila y enseñarle técnicas.

19. Ayudar al Equipo de desarrollo, dueño de producto, partes interesadas a con la entrega de la planificación

20. Estar familiarizado con el producto y el trabajo del equipo

21. Reunir a personas que deberían hablar entre sí pero no lo hacen

22. Estar en contacto con las partes interesadas regularmente

23. Ayudar al Equipo de desarrollo y al propietario del producto para que proporcionen información significativa, apropiada y puntual a la dirección.

24. Ayudar a promover la comunidad de Scrum y Agile dentro de la organización

25. Organizar eventos de intercambio para los miembros del equipo, propietario del producto, partes interesadas de la organización

26. Facilitar e implementar la diseminación de conocimiento en el grupo, por ejemplo organizando las sesiones «Brown Bag»

27. Compartir perspectivas por toda la compañía

28. Ser la persona de contacto para todo el mundo, tanto sea el Equipo de desarrollo, partes interesadas, etc sobre Scrum/Agile

29. Dar oportunidades de aprendizaje a las personas en la organización a través de charlas, talleres de trabajo, u otros foros y dejarles que aprendan conceptos importantes sobre Agile.

30. Ayudar al equipo a identificar y deshacerse de los impedimentos

31. Sugerir nuevas métricas para que el equipo de desarrollo las use como catalizadores para el cambio.

32. Reflejar los valores de Agile y Scrum al equipo.

33. Recordar al Equipo de desarrollo sus disposiciones, normas y políticas

34. Ayudar continuamente al equipo de desarrollo a mejorar sus procesos

35. Plantear cuestiones a las personas de desarrollo a través de la observación desde una visión de fuera del Equipo.

36. Realizar preguntas abiertas [poderosas].

37. Comprobar todos los modelos que el Equipo utilizasa (Sprint Backlog, métricas, etc. y demostrarles las diferencias entre el modelo y la realidad.

38. Ayudar al Equipo a centrar la atención actuando como un amortiguador entre las distracciones exteriores y el equipo.

39. Ayudar al equipo a mantener las herramientas de Scrum (Pizarra de tareas, Tablón de acciones, gráficos, pils, etc.)

40. Ayudar al equipo y al propietario del prodcuto a establecer una definición de hecho apropiada.

41. Preveer el futuro, como quiere el equipo trabajar la próxima semana, el próximo mes, año…

42. Construir y articular un objetivo o meta común para el equipo.

43. Ayudar al equipo a construir un grupo de valores que lo identifiquen.

44. Colaborar con futuros aspirantes de Scrum Master.

45. Ayudar al Equipo a mejorar sus habilidades sociales, especialmente con respecto a conversaciones constructivas.

46. Establecer las actitudes positivas y re-afirmarlas

Puede que me haya olvidado de alguna, pero a grandes rasgos están la mayoría.
Nuevamente la pregunta hay que tener en mente que se considera un equipo de alto rendimiento y cual es el principal motivo para eliminar este role.
Realmente te recomiendo como buen punto de partida interiorizarte con los Sistemas de pensamiento y Sistemas complejos para así poder entender la repercusión de un cambio de este tipo.

Esto finaliza la entrega de 4 partes de porqué un Scrum Master no debe ser de tiempo parcial o compartido con otro role de Scrum.

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

Quizás la aseveración de que un Scrum Master no genera valor esté fundamentada en discusiones antiguas sobre el role. Lo cierto es que un buen Scrum Master siempre incrementa el valor entregado al cliente, por ser una persona exclusivamente focalizada en ayudar a mejorar el proceso. La mejora de un proceso genera un aumento en la entrega de valor al cliente.

Los 3 frentes del Scrum Master
El Scrum Master trabaja esencialmente en 3 frentes para mejorar el valor:

1. Con el propietario del producto
Enseñándole formas de trabajo dentro del modelo Scrum y asegurándose que la interacción con el equipo sean óptimas. Es muy común que el PO esté muy ocupado y tienda a descuidar al equipo o intente utilizar técnicas que no concuerdan con los valores de Agile.

2. Con el equipo
Remover impedimentos y realizar experimentos con los procesos del equipo para descubrir nuevas formas de hacer las cosas.
Es importantísimo destacar que hay un trabajo previo del Scrum Master cuando se conforma al equipo, en donde encausa el mismo a definir su identidad de grupo y reglas de trabajo (paso fundamental, muchas veces olvidado).

3. Con el cliente
En algunos casos, el Scrum Master puede asistir al propietario del producto en explicarle a los clientes sobre el marco del trabajo; también tiene un role fundamental en las reuniones de revisión del producto, asegurándose que se realice de la forma adecuada y se encause efectivamente.

Sinergia de los procesos
La sinergia de estos 3 procesos generan a su vez 3 ciclos de retroalimentación:

1. Hacia el equipo
Mejorando sus procesos y formas de hacer el trabajo y eliminando cualquier desperdicio.

2. Hacia la empresa
Haciendo que los procesos que impiden el tener un producto más rápido puedan ser optimizados.

3. Hacia el producto
Tratando de obtener aquellas funcionalidades que son realmente importantes y descartando el resto.

El role de un buen Scrum Master requiere conocimiento de técnicas en diferentes campos, tales como:

1. Motivación
2. Descubrimiento de valores y énfasis
3. Resolución de conflictos
4. Técnicas de negociación.

Esto hace que para cubrir este role se requieran conocimientos específicos ya que de lo contrario se tendrá un sistema sub-óptimo (ver mi definición en mi entrada anterior); el rotar a este role u otra modalidad se pueda hacer pero no es recomendable.

Normalmente las empresas que le quitan importancia al role de Scrum Master son aquellas que se focalizan menos en mejorar los procesos. ¿Un sistema con personas y computadores más inteligentes pero un proceso inferior son más efectivas que lo contrario?

Humano menos iteligente + computador débil + mejor proceso
fué superior a
Humano más eficiente + computador potente + proceso inferior”
Del libro “Metáforas del Ajedrez, Inteligencia artificial y el cerebro humano”

Esto último se dió como derivado de un largo estudio científico. El proceso es siempe el rey.

La creencia del incendio
He visto esta idea en muchas empresas de Latino América y España de cuando hay un incendio todos deben dejar de hacer sus cosas y focalizarse en apagar el fuego. En mi creencia, es que esta forma de pensamiento radica en hábitos que se arrastran
y tienen su origen en las metodologías tradicionales.

Ello además de provocar un daño en la moral de las personas y los grupos, genera inestabilidad en el sistema, lo cual aumenta la imprevisibilidad, cosa que termina generalmente bajando la calidad de una aplicación de software y destruyendo al sistema en si.

La aproximación de Scrum
Scrum se basa en una aproximación diferente, la cual consta de la creación de un sistema lo mas estable posible. Ello se logra -entre otros- mediante la libertad de un equipo a decidir responsablemente sobre que características será capaz de absorver y desarrollar en un ciclo de tiempo fijo. Para el caso que haya un problema, se deberá re-negociar con el propietario del producto el alcance en vez de apagar el incendio. Esto brinda mayor estabilidad al sistema, lo que permite entre otras cosas estimaciones mas certeros, aumentar la confianza del cliente sobre las fechas de entrega y disminuir el estrés del equipo.
En mensajes anteriores se mencionaba también el caso de SM rotativos. Este es otro ejemplo que agrega inestabilidad al sistema.

La estabilidad del sistema
Los miembros de un equipo deben ser tan estables como sea posible. Como dije antes, el proceso es el rey; esto es correcto y apoya a los valores de Agile y Scrum en su totalidad. Todo proceso en Scrum y cualquier metodología Agile debe apoyar al 100% a las personas y ayudar a entregar la mayor cantidad de valor posible al cliente. Es muy común cuando se comienza a utilizar Scrum en empresas más tradicionales que la parte gerencial no entienda el funcionamiento del marco de trabajo e introduzca procesos que no apoyen a las personas, equipo ni entrega de valor.

Por ello, el proceso es el Rey. Scrum nunca podrá funcionar si los procesos no apoyan a las personas ni a la entrega de valor.

Lee la tercera y última parte aquí

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

La idea de Scrum es ofrecer un marco de trabajo que promueva un flujo contínuo.
Básicamente, podríamos imaginarnos un sistema donde no exista fricción representado por un valor 0 y valores positivos si hay elementos en este que puedan frenar el flujo de trabajo.
El modelo de Scrum trata de minimizar la fricción dentro del sistema de varias formas. Algunos factores son técnicos (fricción) y otros del proceso (impedancia). Estos factores incluyen:

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 fricción e impedancia, mayor será la lentitud para desarrollar el software pero también se incrementará la cantidad de tareas a realizar (o lo que es igual a mayor coste).

¿Qué pasa al tener 2 roles en 1?
Al tenerse 2 roles en 1, la persona no será capaz de realizar ambas a la vez, lo que generará una cola. Esto quiere decir que habrán tareas que deberán hacerse primero y otras después de los distintos roles. Este tipo de conductas adiciona mayor impedancia al sistema (sub-óptimo), lo que hace que el desarrollo sea más lento.

Ahora bien, se podría argumentar que ambas tareas no son realizadas al mismo tiempo, pero la realidad indica que cualquier situación que implique tener que elegir cual efectuar primero de distinos ámbitos estará dilatando la segunda, lo que generará una o mas colas.

El efecto de las colas
La cola influye no solamente sobre un proceso, sino sobre cualquiera que dependa del resultado. Si un equipo necesita que el SM ayude a remover un obstáculo pero este no está disponible hasta que no se haga otra tarea del role complementario, entonces se estará en esta situación.
Las colas aunque parezcan pequeñas, hacen que el sistema nunca pueda ser óptimo y derivan en un sistema sub-óptimo.

A su vez, para hacerlo aún mas complejo, si hay conflictos entre los roles como mencioné anteriormente, ello aumentará la complejidad de forma innecesaria en el sistema generando mayor desperdicio.
El desperdicio le cuesta dinero al cliente, por lo que existen dos opciones:

1. La empresa absorve dicho coste
2. Lo transfiere al cliente

Estas variables son solamente algunas de las que pueden alterar el sistema, haciéndolo más caro. En situaciones más extremas, el sistema podría volverse inestable. Por ejemplo, si el SM se va de vacaciones (o se enferma), se estarían perdiendo 2 roles, que podrían ser asumidos por otro miembro pero generaría inicialmente desperdicio, colas y un posible período de inestabilidad del sistema.

La inestabilidad de un sistema afecta directamente a los estimados de un equipo. Un Scrum Master reemplazando temporalmente a otro S.M. en un caso así generaría menor impedancia.

Es por ello que Scrum propone un modelo ideal donde la fricción e impedancia sean lo más cercano a 0.

Proponer desde un comienzo un sistema sub-optimo es para mi un error.

Lee la tercera parte aquí.

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

No, ya que podría haber un conflicto entre los valores de Scrum. Los roles en Scrum no se deberían compartir.
¿Cuál sería la motivación para hacer esto? Un motivo podría ser el pensar que se ahorrará dinero, no obstante, esto es una permisa falsa ya que este role incrementa las ganancias mediante el aumento de la productividad del equipo.
Cualquier otra mezcla dará como resultado un aumento de los conflictos y una disminución del valor de negocio entregado al cliente.

El conocimiento empírico y Ágil
Ágil esta basado en conocimiento empírico que se ha ido acumulado durante años, creado por cientos de cabezas que han probado diferentes aproximaciones. Si lo empírico no te convence, hay modelos matemáticos que demuestran que es la mejor organización para un equipo. Esto tiene sentido (y es de sentido común) ya que compartir roles aumenta el riesgo y la posibilidad de colas y bloqueos en el sistema.

He trabajado en empresas enormes y el compartir un role siempre trajo como consecuencia una caida en la entrega de valor y otros conflictos directos o indirectos, como ser la pérdida de confianza y baja moral de los miembros del equipo. Por ejemplo, si hay presión en entregar más valor y se comparten los roles de Scrum Master y Propietario del producto, ¿Se dará prioridad a presionar al equipo o a conservar la cadencia adecuada del mismo?

¿Cuál es el motivo para mezclar roles?
Si se quiere hacer Scrum se debería hacer de la forma recomendada, de lo contrario, se puede llevar adelante otra cosa pero no se le debería llamar Scrum.

Algunas personas pueden a su vez indicar que han probado el role de Scrum Master a tiempo parcial o compartido. Creo que hay que comprender que aunque un conjunto de actividades se lleve adelante por período extenso de tiempo con buenos resultados, ello no implica que sea la mejor forma o la más óptima. Raramente un equipo con un role compartido puede tener un altísimo rendimiento. Ello radica en las limitaciones de funcionamiento al compartir el role que conlleva a que el grupo cuente con obstáculos tanto sean de bloqueos o posturas personales.
Un ejemplo de ello es donde se tienen planteamientos opuestos dentro del mismo role, en general, si se llevan por la misma persona se elegirá una postura determinada, pero no se entablecerá una conversación. Al ser llevado por individuos diferentes, se entablecería una charla, mediación y resultado final.

Equipos senior y Ágil
No obstante y dicho esto, los equipos senior podrían llegar a compartir el role o tenerlo ausente por un corto tiempo, sin embargo, el crecimiento del equipo en sí se vería altamente comprometido en el mediano plazo por lo que no lo recomiendo.

Lee la segunda parte aquí

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

Hace unos días, en un grupo de Linkedin se formó un debate sobre si el role de Scrum Master debía ser exclusivo. A mi parecer sí; es un requisito necesario para que los equipos mejoren ininterrumpidamente su rendimiento (a perpetuidad). Hablaré de ello en un par de semanas. Hoy quiero darte 8 consejos rápidos para hacer su vida más fácil si eres un Scrum Master. Muchos de ellos pueden parecer sentido común, pero son fáciles de olvidar en el día a día.

1. Desde el día 1 del equipo, procura que tu equipo tengan reglas claras sobre las normas de convivencia. Por ejemplo, lo que no está aceptado en las reuniones (ej. no teléfonos celulares, no interrupciones, respeto constante, etc) o se espera del producto (visión) y las métas que se desean aprender (pruebas de misión) y pégalas en visibles antes de comenzar con tu trabajo. Si hay posteriormente una ruptura del «protocolo«, recuerda las reglas (o señálalas) y observa al equipo o persona. Siempre refuerza las actitudes positivas del grupo.

2. Cada reunión, dinámica o actividad tiene un propósito particular y un conjunto claro de resultados tangibles, por lo que la pregunta «¿Porqué hacemos esta reunión?» debería haber una respuesta clara y ser comprendida por los integrantes antes de comenzar la misma. De ser necesario, informa a las personas con anterioridad sobre el fin y pregunta al comienzo de la reunión para aseegurarte que todos se encuentran alineados.

3. Interviene y modera al comienzo de una reunión o dinámica  para mostrar los valores de Agile o Scrum o como encaja lo que harás con las formas de trabajo y da un paso atrás para que los miembros puedan aprender lentamente a auto-organizarse o mejorar su interacción.

4. Utiliza el poder del silencio como herramienta para promover la comunicación.

5. Interrumpe al equipo siempre que te parezca correcto, pero sigue la regla de que hayas pensado premeditadamente sobre sus beneficios y repercusión y valga la pena el desafío.

6. Observa el lenguaje corporal de las personas y asegúrate que todos intervienen de igual forma. Para el caso que esto no sea así, emplea un indicador de interacciones  (ver aquí) o cualquier otra técnica que empodere la comunicación y colaboración.

7. Asegúrate de alejarte del contenido de la reunión y centrarte en la facilitación. Es fácil tomar partido y perder el foco; piensa siempre en mejorar las interacciones del grupo como meta principal. Una interrupción fuerte puede ser tolerada si alguno de los miembros rompe un valor de Scrum o Agile o las reglas pre-establecidas o el tema de conversación ya no corresponde con el punto 2.

8. Asegúrate de realizar observaciones/preguntas poderosas o abiertas o plantear desafíos o experimentos para que el equipo pueda crecer. Puedes también emplear dinámicas para mantener la cadencia de la reunión.

Siempre puedes decir «como Scrum Master me gustaría hacer un experimento por X tiempo y veremos los resultados en Y tiempo». Ayuda siempre a las personas a que salgan de su círculo de comodidad… ese es tu trabajo.

Finalmente… nunca estes a más del 70% de carga de trabajo, ya que sino serás un bloqueo en el sistema en vez de un facilitador.

Gracias por escucharme,
Erich.

PD: Por más recomendaciones para mejorar las reuniones, lee mi artículo sobre la técnica de las 7P.

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.

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.

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,