Blog&Artículos

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,

Hay 3 padecimientos que la mayoría de las personas de la industria de software experimentan a diario en la cadena de valor (esto es todas las etapas y personas necesarias desde la idea hasta la materialización de la misma), pero que pasan desapercibidos por estar intrínsecamente arraigadas en la cultura o formas de trabajo, lo que hace que sea difícil su eliminación; estos son:

1. Fricción
2. Impedancia
3. Deuda técnica.

Me centraré en los primeros dos.

Recuerdo cuando era joven y me enseñaban física, me indicaban inicialmente como calcular la velocidad de un objeto que bajaba por una pendiente. Era un escenario ideal y sin fricción. Luego, a medida que avancé en mis estudios, me mostraron como adicionar la resistencia del viento y la fricción con otros elementos.

Las ideas eran complementarias, pero la fórmula se hacía más compleja a medida que se adicionaban nuevos factores.

Lo que ocurre con la física también pasa con el software, pero a diferencia, al estudiar en la universidad se aprende mucho sobre lenguajes y tecnologías pero poco sobre la existencia y repercusión de la fricción, impedancia y deuda técnica en las empresas de desarrollo. Debido a ello, los profesionales desconocen mayoritariamente como lidiar con estas últimas, aunque experimenten sus consecuencias en su día a día.

La fricción, impedancia y deuda técnica son factores que frenan la velocidad del desarrollo de software y que muchas veces no son tenidos en cuenta en los proyectos, o al menos, en su totalidad.

Todos ellos pueden ser considerados desperdicio desde el punto de vista del pensamiento Agile o Lean, esto es, tareas que raramente agregan valor al cliente pero que le cuestan dinero.

He llegado entonces a clasificarlas bajo estos 3 conceptos, lo que creo facilitará que lo entiendas:

Fricción – Todo aquello eliminable que está relacionado con las tareas técnicas y específicas del desarrollo de software y que disminuye su velocidad.

Impedancia – Aquellos factores humanos tangibles que impactan en un proyecto de software y repercuten en el tiempo de entrega.

Deuda técnica – Todas aquellas decisiones de implementación tomadas para acelerar la entrega en el corto y mediano plazo pero que aumentarán los tiempos de programación en el futuro cercano.

Esta agrupación hace fácil entender a cada factor como consecuencia de un efecto diferente, lo que permite un tratamiento mas claro.

Es importante tener en cuenta que ellas pueden verse agravadas cuando por ejemplo existe estrés o presión de la compañía en entregar un producto. El ejemplo típico es una fecha fija de entrega.

«Fricción, impedancia y deuda técnica son una oportunidad para mejorar el proceso»

Fricción
Cuando tratas de estimar una tarea, a no ser que hayas realizado algo similar en el pasado o tengas conocimiento específico del área en cuestión, entonces se obtendrá una versión simplificada del problema, que ignorará la fricción y resistencia.

Por ejemplo, cuando se comienza un nuevo proyecto en un área de conocimiento no indagada anteriormente, se tendrá forzosamente que realizar un primer análisis. Ello implica invertir un número más elevado de tiempo para hacer funcionar los primeros engranajes y conocer las herramientas en cuestión.

Podemos considerar esto como fricción de arranque, de la misma forma que cuando pones un motor en marcha éste comienza de menores a mayores revoluciones.
Las cosas simples llevarán más tiempo ya que desarrollar es una tarea de descubrimiento más que una fórmula matemática y las primeras conclusiones siempre se extenderán. Aparecerán escenarios típicos del aprendizaje, donde luego de conocer como efectivamente resolver la tarea e implementarla, se observarán atajos, lo que llevará a una re-evaluación de lo ya hecho de forma muchas veces retrospectiva. Veamos entonces 3 tipos de fricción:

1. Tareas repetitivas
Aquellas tareas manuales que se hacen una y otra vez. Normalmente las personas lo hacen sin realmente evaluar su impacto global en tiempo. Pueden ser desde tareas minúsculas dentro del editor de código hasta las más macro, que involucren por ejemplo una tarea técnica dentro de una historia de usuario que se repita una y otra vez a lo largo de los ciclos Sprint. Al descubrirlas se deberá siempre evaluar una posible automatización del proceso para así ahorrar tiempo. Tenemos aquí 3 áreas a considerar:

• Monetaria (cuanto cuesta)
• Que tiempo va a ahorrar
• Que fuerza de trabajo está motivada para implementar la automatización y entiende el problema.

La aproximación que muchas personas inicialmente efectúan es «me llevará 5 minutos hacerlo pero 60 horas automatizarlo». Habrá entonces que tener en cuenta cuantas veces al día/semana/mes se realiza la acción para ver si tiene sentido implementarla de tal forma que sea rentable y libere al equipo de desarrollo para que puedan hacer otras tareas.

A mayor liberación, mas cosas se podrán hacer en los futuros ciclos Sprint.

Mi recomendación es que siempre tomen los equipos una tarea en cada Sprint, que acelere la velocidad de estos a perpetuidad.

2. Infraestructura (lentitud)
Cualquier tarea que consuma tiempo considerable, bajando la eficiencia del equipo debido a la lentitud de factores tecnológicos «externos». Por ejemplo, un desarrollador puede querer fusionar las fuentes locales (check-in) con sus cambios en el repositorio maestro. La consecuencia podría ser dada debido a que los miembros del equipo no realizan actualizaciones regulares, lo que da como resultado que al intentar fusionar las fuentes se requiera de mucho tiempo para resolver sus inconsistencias.

A su vez, un recurso remoto (de red), una compilación inefectiva o la complejidad para poner en producción podría ser otro factor de fricción. Éste último es un punto común en organizaciones que comienzan su camino hacia la agilidad.

3. Problemas con el código o donde se requiera re-aprendizaje
Emplear muchas herramientas de software diferentes, trabajar con código donde no se han seguido estándares claros/dispares o código difícil de entender por haber sido escrito por otra persona o por uno mismo en el pasado o no se hacha hecho refactoring como tarea habitual es un problema. En estos casos será necesario un proceso de re-aprendizaje, esto es, tener que somatizar nuevamente algo que en su momento del tiempo era claro.
La industria del software sufre de este síntoma en mayor medida, ya que la inconsistencia y la no utilización de estándares claros, hace que haya que aprender nuevamente algo que en su momento parecía una tarea sencilla.

«La fricción, impedancia y deuda técnica impactan en el desarrollo de software de forma negativa»

La fricción que vimos puede frenar en mayor medida mientras que otros tipos de fricción pueden ser más benignos. Esperar por ejemplo por una base de datos a ser construida podría bloquearte por semanas a diferencia de unos minutos que llevaría la fricción de aguardar por un compañero de equipo a realizar una revisión de tu código.

Afortunadamente, el marco de trabajo de Scrum ayuda constantemente a eliminar la fricción, esto es, mediante la forma sistemática de centrarse en un objetivo común. También contribuye al final de cada iteración cuando se inspecciona las interacciones en la retrospectiva.

Ello permite detectar los desperdicios de los procesos o relaciones personales que han impactado sobre la velocidad o velocity para adaptar o mejorar.

Finalización de un proyecto y automatización
A mi criterio, todo proyecto que se dé por finalizado requerirá algún tipo de mantenimiento, incluso aunque esto no se crea en una primera instancia. Es por ello que aquí hay que considerar que cuanto mayor tiempo pase desde la finalización hasta que se solicite el cambio, mayor será el coste económico de realizar el mismo.
De acuerdo a un estudio de Microsoft, un defecto que se repare dos semanas después de haberlo introducido en el código llevará una media de 35 veces más de tiempo que si se hace enseguida.

                t? Coste = Cambio

Siendo (t) el tiempo que eleva el cambio a la potencia.  Esto es así ya que pese a no existir futuras capas de software que adicionen complejidad, los tiempos de re-aprendizaje serán mayores a medida que se distancie la modificación del momento de la finalización del proyecto.

De forma similar a los defectos, un cambio o acción a ser realizada tan pronto se terminó el proyecto será infinitamente más barato que llevarlo adelante unos meses más tarde.

A su vez, las personas que trabajaron en un proyecto podrían haber sido re-asignadas a otros, lo que complica aún más el panorama.
Es así que para bajar los futuros costes de mantenimiento de un producto, se debe siempre pensar en automatizar tanto como sea posible en ciclos tempranos del proyecto.

En la segunda parte escribiré sobre impedancia, esto es, los factores humanos tangibles que impactan en un producto digital y repercuten en los tiempos de entrega. Veremos también algunas técnicas pioneras para visualizar y cuantificar la impedancia en tu empresa.

(puedes encontrar la segunda parte aquí)

Te invito también a conocer más sobre mi libro, que ahora también se encuentra en español:

Gracias por escucharme,
Erich,

Hace unos pocos días atrás Ken Schwaber, que es uno de los padres de Scrum, publicó un interesante artículo sobre valor en Agile y su diferencia con las metodologías tradicionales. He decidido tradudir el mismo para que puedas tenerlo a tu alcance, pero antes deseo que comprendas porqué la metodologías tradicionales no son la mejor opción para gran parte de los proyectos.

Metodologías tradicionales
Hay algo claro a tener en cuenta en con respecto a las metodologías tradicionales: hacen pagar mucho más por un producto de software al cliente y raramente pueden obtener un alto nivel de satisfacción ya que  parten de 5 premisas:

1. Congelar los requerimientos al comienzo del proyecto.
2. Realizar pocas evaluaciones parciales (ciclos de reto-alimentación bajos)
3. Considerar como valor a las entregas que no son software
4. Penalizar los cambios.
5. Medir lo que se considera correcto

Congelar los requerimientos
El mayor problema en congelar los requerimientos al comienzo de un proyecto es que la premisa no considera como probable que un cliente puede aprender y encontrar una mejor forma o solución a un problema. Lo que inicialmente era una excelente idea, el proceso de aprendizaje de un cliente puede llevarlo a que madure al cabo de semanas y tenga una mejor respuesta. De esta forma, no obtendrá lo que considerará como la opción más óptima y no estará feliz de recibir su producto.

«En las metodologías tradicionales el aprendizaje del cliente no es parte de la ecuación»

Realizar pocas evaluaciones parciales
Debido a que no se incluye como premisa que el cliente puede aprender, entonces raramente tiene sentido la evaluación parcial de los resultados, y si se muestra un producto no terminado, es solamente para verificar que se encuentre la funcionalidad completa y cobrar un monto prestablecido, pero no se toma como un ciclo de aprendizaje y retro-alimentación.

«Las evaluaciones parciales tienen como objetivo que el cliente cumpla su objetivo contractual de pago»

Considerar valor a las entregas que no son software
Las metodologías tradicionales consideran las entregas de, por ejemplo, un documento que explique como será la aplicación o como serán las pantallas y ello se considera como una entrega de valor. En realidad, la única medida de valor que existe es software funcionando, el resto no aporta valor alguno ya que no soluciona en ninguna medida el problema del cliente. Una trampa fácil de caer.

«El entregar un documento no soluciona el problema del cliente y por lo tanto no tiene valor»

Penalizar los cambios
Ya que se congelaron los requerimientos al comienzo, es difícil realizar modificaciones, sobre todo si el proceso de análisis se ha terminado. Debido a ello, se le penaliza a los clientes por cualquier cambio que soliciten, así sea uno que es obvio y que se dió como resultado del aprendizaje o maduración de un problema por parte del cliente. Este último punto evidentemente corroe la confianza a mediano y largo plazo, lo que hará que éste deba cerciorarse de las futuras intenciones de la empresa contratada mediante extensos contratos entre las partes, lo que se traduce en mayor tiempo y dinero. A su vez, se destruye el concepto de equipo hasta el punto de elaborar el modelo de «ellos vs. nosotros». Es común ver este tipo de acciones en licitaciones, donde las empresas ofertan el precio más bajo posible (a veces tan bajo como 1 euro) pero penalizan altamente por la adición de cambios. La trampa se basa en que los clientes querrán modificaciones y tendrá que pagar por ellos un alto precio o de lo contrario, se quedarán con la opción original. Ambos escenarios son desfavorables y destruyen evidentemente la confianza, terminándose con el producto no deseado.

«Los cambios son una penalización y en muchas ocasiones una trampa»

Medir lo que se considera correcto
Muchas empresas tienden a medir lo que se considera correcto a primera vista, como ser las horas que trabaja una persona en una semana, el porcentaje de utilización, lo que el empleado ha sido capaz de finalizar en determinados días o que tan ocupado éste estuvo durante un período de tiempo… en definitiva su «productividad» con el fin de realizar micro-gestión. En realidad, los informes deben aportar un valor tangible que apoye el trabajo en equipo y la claridad de los resultados. Los informes deben ser siempre una herramienta para mejorar el proceso de forma continua y nunca para penalizar personas. Veremos en el artículo de Ken Schwaber que se debería medir y su relación con el índide de Agilidad (puedes leer también mi artículo «10 reglas de oro para medir un proyecto Ágil«)

Es por ello que las metodologías tradicionales ofrecen una baja satisfaccion de los clientes, raramente brindan lo que ellos desean y hacen que los mismos paguen más por algo que a su criterio no es la solución adecuada. A su vez, ellas ofrecen estructuras pobres de colaboración, ya que este es otro aspecto fuera de su ecuación. Hay otra forma de trabajar con Scrum y Lean y está a tu alcance.

Veamos ahora el artículo de Ken Ken Schwaber sobre Valor en Ágil.

Gracias por escucharme,
Erich.

---

Valor en Ágil

(Ken Schwaber, Diciembre 11, 2013, Agile Retrospectives Blog on Scrum.org
Traduccion: Erich Bühler)

Cada año, las organizaciones gastan de entre un 4 a 10% de sus ingresos en sus departamentos de software (I.T.). Se espera obviamente un valor de retorno a cambio de dicho gasto.

En estos casos, el valor se define como el beneficio económico que una organización recibe por el gastos. Al medirlo, el valor puede provenir de toda la organización o estar limitado a una sola división o línea de producto. En todo caso, este siempre debe abarcar las zonas afectadas por este gasto.

Valor es entonces una medición que comprende en un momento determinado del tiempo:

Los ingresos por empleado	Los ingresos (producido) brutos por empleado.
Satisfacción de los empleados	¿Qué tan satisfechos están los empleados? Luego de haber invertido en ellos, los mismos pasan a ser un activo importante y una ventaja competitiva.
Satisfacción del cliente	¿Los clientes están más o menos satisfechos que en el pasado? Encontrar un nuevo cliente es mucho más costoso que satisfacer a los clientes actuales.

Una organización puede cambiar el VALOR mediante:

• Los productos y servicios que entrega y vende.
• Sus sistemas, tanto manuales como automáticos, a través de los cuales entrega sus productos y servicios.

Nos centramos en este último.

Philips Iluminación

Philips Iluminación es una división multimillonaria de la corporación Philips que completó recientemente un proyecto para «acelerar» la creación de VALOR. El proyecto abarcó todas las operaciones desde cuando un presupuesto era dado a un cliente hasta que la empresa recibía finalmente el dinero. El proyecto constaba entonces de dos componentes:

• Los procesos de negocio revisados, integrados en un nuevo flujo de operaciones creados a pertir de un mapeo de la cadena de valor (value stream mapping) y su exhaustiva eliminación de desperdicio.

• Nuevos sistemas de software, basados en productos de la fuerza de ventas, que apoyaban consecuentemente los nuevos procesos de negocio.

Cada componente requiere entonces del otro para su éxito. La mejora de las operaciones del área de software (I.T.) no tendrían ningún impacto en el VALOR de la organización si la empresa no los pudiese utilizar eficazmente.

Mediciones de valor

Hemos ideado una métrica que trata de captar los dos aspectos de la capacidad actual de una organización para crear y entregar valor; ellos se componen de:

• Mediciones operacionales (que miden la eficiencia de una organización). Estas métricas están fuertemente orientadas hacia la parte de software (I.T.), tanto el desarrollo de software como la implementación de la misma en la organización. Esto incluye: el flujo, tiempo de ciclo, estabilización, calidad, tasa de re-utilización y el tiempo ciclo de entrega. La eficiencia operativa del negocios no está incluida en estas medidas, pero se hará  en 2014 como parte del programa internacional Kotter (John Kotter) Accelerate!.

• Mediciones de organización (miden el impacto de que la eficiencia de dicha inversión en el mercado y el valor que la organización acumula). Estas métricas son por ejemplo, los ingresos por empleado, satisfacción de clientes y empleados y la relación de coste del producto/sistema.

Los dos indicadores se combinan en una sola métrica: Índice de agilidad. El Índice de agilidad es un número que indica la agilidad relativa, de 1 a 100. Se orienta fuertemente hacia el valor de la organización. Es decir, una organización puede ser muy competente, pero si no se deriva un valor de mercado por su eficiencia, el Índice de agilidad entonces será bajo.

Se espera que esta medida aumente cuando la organización gasta  dinero en software, proyectos y el mejoramiento del negocio.

Criterios tradicionales de medición de un proyecto

Un proyecto tradicional evalúa una necesidad y define un conjunto completo de requisitos para satisfacer la necesidad original. A partir de estos requisitos, se establece una fecha y un presupuesto de entrega. Una vez estos  establecidos, los cambios se ajustan tanto como sea posible. Las metricas o indicadores se acumulan en contra de este tipo de proyectos; el Valor no entra como parte de la medición.

Criterio	Éxito
Requisitos	Todos los requisitos establecidos al inicio del proyecto se han cumplido
Presupuesto	No se ha superado el presupuesto asignado al inicio del proyecto
Tiempo	No se ha superado la fecha de finalización del proyecto

Criterios de medición de un proyecto Agile/Scrum

Los proyectos Agile/Scrum son diferentes a lo visto anteriormente. El objetivo se establece: este es el impacto deseado y su objetivo. Una fecha y su financiación pueden ser estimadas en base a experiencias pasadas o surgir por conocimiento a medida que el proyecto avanza. Todo el esfuerzo se dirige a lograr la mejor solución posible para el objetivo planteado. Esta iniciativa se considerará completa cuando se cree la solución, o se determine razonablemente un determinado momento que no se puede crear más.

En un proyecto ágil, cada Sprint o iteración es un proyecto completo. Tiene necesidades, presupuesto y fecha de entrega; al final se tiene un conjunto completo de funcionalidades de software. En base a lo finalizado en la última iteración, otro proyecto podrá o no ser iniciado, añadiendo más funcionalidad a las características que se acaban de completar; cada Sprint entonces se mide de forma independiente.

Criterio	Éxito
Confianza de los inversores en el valor	Confianza de las partes interesadas, dueño del producto y desarrolladores de que la mejor solución posible fue creada para el objetivo o meta establecida en la iniciativa, con la inversión de dinero disponible.
Satisfacción de los inversores	Voluntad de las partes interesadas, dueño del producto, y los desarrolladores para llevar adelante este tipo de iniciativas nuevamente.
Confianza en la utilidad del software creado	Confianza de las personas que utilizan el sistema o producto que el mismo ofrece una forma mejor (que antes) de llevar adelante su trabajo.
Satisfacción de los clientes	Grado en que los usuarios buscan con interés la próxima solución para ayudar a hacer su trabajo mejor.

---

Puedes encontrar el artículo original aquí.

Los dos indicadores se combinan en una sola métrica, Agilidad Index. El Índice de agilidad es un número que indica la agilidad relativa, de 1 a 100. Se inclina fuertemente hacia el valor de la organización. Es decir, una organización puede ser muy competente, pero si no se deriva de valor del mercado de la eficiencia, el Índice de agilidad es baja.

Como organización gasta fondos en TI, proyectos y el mejoramiento del negocio, cabe esperar que esta medida aumentaría.

Hay que reconocer que a algunas personas de la empresa les gusta el cambio mientras que otras prefieren tenerlo lejos y si es posible tan distante como verlo en otra empresa. En mi entrada sobre como introducir cambios comenzé a hablarte sobre como iniciar y gestionar un cambio en tu compañía, sin embargo, ahora quiero ir a algo bastante más específico que es lo referente a cambios y tipos de personalidades.

Resistencia institucional y cambios hacia Agile parte 1 y  parte 2

A grades rasgos, podemos ver que las personas usualmente se pueden englobar dentro de las siguientes 4 categorías:

1. Los que lideran el cambio
2. Aquellos que quieren conocer el porqué del mismo
3. Los que no tienen problemas en seguir cualquier cosa que se plantee
4. Aquellos que quieren divertirse experimentando el cambio

Ahora bien, las personas son individuos con una vida muy rica y no estoy sugiriendo que se encajonen todos ellos, pero comprender las divisiones te ayudará a comunicar cualquier cosa que desees de forma efectiva e inteligente.

Cada tipo de personalidad (que veremos a continuación) requiere una estrategia diferente de comunicación e ignorar esto puede disminuir el liderazgo y aumentar los problemas presentes y futuros. Scrum Masters y otros tipos de líderes mecesitan tenerlo presente si quieren ser eficientes, mejorar los resultados y generar menos desperdicio y conflictos en la empresa.

Tipos de personalidad
Imagínate un día en tu empresa, observa a las personas que tienes a tu alrededor, ¿Puedes ver alguna diferencia entre las formas en las que ellas se comunican y realizan las tareas? Ahora detente por un segundo y pregúntate… ¿Si envío un mensaje será comprendido por todos de la misma forma?

Evidentemente no, y por ello deseo que conozcas los distintos tipos de personalidades y una herramienta que te ayudará a liderar mejor. Cada una de ellas no solamente digerirá la información de distinta forma, sino que también los tiempos y vías de comunicación serán diferentes. Tenemos entonces 4 tipos de personalidades:

1. impacientes
2. Super sociables
3. Confiables
4. Detallistas

A su vez, las personas pueden ser una mezcla de ellas, pero el comprender el tipo específico te ayudará a preparar una estrategia efectiva siempre que desees introducir un cambio en la empresa.

Los impacientes
Son aquellas personas que son firmes de carácter, de alguna forma comercialmente agresivas, que no tienen mucho miedo del riesgo y que sienten comodidad en plantear nuevos escenarios o salirse del círculo de comodidad. Generalmente son líderes que tienen cierto control e influencia y les gustan las cosas terminadas.

Los super-sociables
Estas personas suelen ser divertidads, siempre con buenas intenciones, populares y les atrae el interactuar constantemente con otras personas. Normalmente les gusta mucho hablar, se reunen en la cocina u otro espacio común, conocen todo lo que está pasando y los rumores pero no así en lujo de detalles.  Ellos tienen gran capacidad de comunicación, pueden influenciar a muchas personas y son un grupo esencial a la hora de convencer gente sobre las ventajas de un cambio.

Los confiables
Suelen ser callados y reservados, poco se sabe de su vida privada, les gusta hacer bien su trabajo y terminarlo antes de irse a casa. Tienen gran lealtad hacia la empresa y normalmente son muy observadores. No les gusta tomar decisiones y prefieren no verse involucrados en una confrontación. Este tipo de personas prefieren la estabilidad al cambio.

Los detallistas
Ellos aman su trabajo siempre y cuando sea bien estructurado y necesitan ser convencidos con hechos que les demuestre que realmente se requiere un cambio que modifique su rutina del día a día. Son muy metódicos, están orientados a la calidad y les lleva mas tiempo digerir la información y los cambios que a los demás.

Estratégias a seguir
Como te comenté anteriormente, el no tener en cuenta a los tipos de personalidad puede hacerte caer en la trampa de querer introducir un cambio en la empresa emplando un modelo único de comunicación, lo que pude traer en sí resultados desastrosos.

Visualiza ahora a las personas que hay en tu organización y trata de imaginarte a cada una de ellas con un valor de cero a 100%; por ejemplo:

Juan
Impaciente…10%
Sociable…….100%
Confiable……0
Detallista……0

Ahora piensa en como te comunicas o como lo hiciste en las últimas veces que planificaste un cambio y verifica si tu estrategia fué la correcta.

Los signos de las personalidades
Existen otros signos que pueden ayudarte a distinguir los distintos tipos de personalidades y así planificar mejor la estrategia:

Super-sociables
Son aquellos que se escuchan primero en una reunión (ej. retrospectiva de Scrum), se ven en la cocina o hablando con otros grupos, se mueven mucho y tienden a dar siempre su opinión cuando incluso nadie se las pide. En general son los que se comprometen a terminar cosas imposibles o mas grande de la capacidad actual y en muchas ocasiones no lo hacen.

Confiables
Están en general en su lugar de trabajo, no bastante conservadores, tienen sus escritorios organizados, no les gustan los riesgos y se vuelven incluso menos comunicativos cuando las cosas andan mal o hay perspectiva de que algo no funcione como se espera. Observarlos es una buena señal, por ejemplo, indicarle a un Scrum master que hay un problema de fondo que no se está abordando.

Impacientes
Generalmente se aburren cuando hay conversaciones largas y les gusta ir al punto, tomar una decisión y seguir adelante. No les importan los rumores, quieren ver resultados. Puedes hablarles y tratar de convencerlos, pero ellos están orientados a los resultados, única consa que los convence.

Detallistas
Se visten de forma conservadora, son tranquilos y reservados, suelen ser buenos en los puestos donde se requiere análisis. Les gusta discutir los temas en profundidad y prefieren realizar un buen análisis o investigación antes de dar una opinión. Pueden sentirse inicialmente incómodos al comenzar a aplicar el marco de Scrum, sobre todo por su aparente falta de planificacion.

Cuando planeas un cambio, los super-sociables son los primeros que deben ser convencidos o informados de los beneficios del cambio, a los impacientes deberás convencerlos con los resultados que se obtendrán del cambio, a los confiables planificar una ruta de trabajo que pueda de forma gradual modificar su forma de trabajo pero permitirles de alguna forma mantener la satisfacción de terminar sus tareas e ir a casa. Por último, a los detallistas se les deberá brindar información adicional, quizá asisitiendo a más reuniones, teniendo la oportunidad de analizar el cambio y siempre escuchar sus puntos de vista.

Mejorar la introducción de cambios en una empresa es quizá una de las cosas más dificiles cuando se desea crear una cultura de mejora contínua. Las personas deben asimilar la costumbre de constantemente ser capaces de examinar los procesos, cambiar y restructurar ellos, para luego empezar a trabajar nuevamente en el próximo cambio. Un buen lider deberá siempre:

1. Emplear una estrategia de comunicación
2. Reafirmar las acciones o aspectos positivos
3. Ser confiable y transparente
5. Emplear retrospectivas a todos los niveles
4. Reafirmar las ideas y repetirlas siempre de diferentes formas

Recuerda, si hay que dar noticias no gratas, es siempre importante que lo hagas de forma transparente y apuntes a cada grupo con la estrategia adecuada. Si por ejemplo las personas tienen un miedo importante, atacarlo, si se corren rumores, hacer un email de preguntas y respuestas que clarifique y dejar las puertas abiertas a todas aquellas posibles consultas. Una vez, por ejemplo, que las personas comiencen a tener miedo de perder su puesto de trabajo, la batalla para introducir los cambios serán siempre una tarea cuesta arriba.

Recuerda…. gestionar el cambio y liderar está relacionado con gestionar las expectativas y emociones de las personas cuando hay periodos de incertidumbre.

Los resultados a esperar
Ten siempre en cuenta que cambiar comportamientos lleva mucho tiempo. No puedes esperar que las cosas se modifiquen de la noche a la mañana, sobre todo si las personas lo han hecho de la misma forma por años. Pueden haber temores, resistencia, inconsistencias y comodidad personal, la que puede llevar a una negativa inicial.

El cambio sin cambio
Si el cambio no es introducido adecuadamente, en muy posible que en pocas semanas las cosas vuelvan a ser como eran antes.

Hay algunos factores que te podrán dar una pista temprana sobre el cambio de estrategia; apenas los veas actúa.

• Encontrar que las personas duermen menos por el estrés generado, se sienten cansados y bajan su rendimiento.
• Cambian sus hábitos de comida, lo hacen más rápido, en su escritorio y consuman más azúcares para tener más puntos altos.
• Se ven más inquietos y ejercen presión sobre otros, lo que generará más estrés y la posibilidad de una bajada en la calidad de las actividades (desarrollo, testing, etc).
• Enfermárse más, no sentirse bien o no estar motivados a venir a trabajar.
• Fumar más, lo que hará que estén menos tiempo en sus puestos de trabajo.
• Tener desbalances emocionales, lo que puede también poner a los clientes nerviosos, sobre todo si ellos trabajan en el sitio del cliente.
• Personas que llegan tarde (por dormir mal) y se van temprano, lo que generará una atmósfera de trabajo delicada.
• Personas tomándose vacaciones más frecuentemente, lo que cargará a los restantes miembros del grupo para terminar las tareas y de esta forma aumenta más el estrés.

Como ves, puede darse el peor escenario que es un círculo vicioso donde los niveles de estrés aumenten exponencialmente, degradándose las actividades, aumentando el riesgo de no entregar en tiempo, destruyéndose la confianza con tu cliente y finalmente aumentando la posibilidad de acusar a una o varias personas de los resultados por la falla global (entre los cuales puedes estar tu).

Lo que deberás tener en cuenta
Planifica la comunicación y presta atención a los roles en tu empresa basado en los tipos de personalidad.

• Qué comunicar y como
• Explicar porqué el cambio es necesario
• Identificar los beneficios
• Ofrecer transparencia y detalles para aquellos que lo soliciten
• Involucrar a las personas siguiendo mi recomendación anterior
• Ofrecer seguridad y mostrar liderazgo dando la posibilidad de un ciclo de retro-alimentación que permita mejorar el cambio original

Piensa siempre antes de los tipos y elabora una etsrategia, siempre educa a las personas para que se sientan parte del cambio y si es necesario toma notas con las sugerencias.

Comienza a utilizar estas herramienta y seguramente verás los cambios y resultaods más pronto, de forma efectiva y duradera.

La semana pasada estuve en Barcelona donde uno de los días caminé hasta arriba del monte Montjuïc, donde sin esperarlo, encontré un excelente ejemplo de la aplicación de las metodologías Lean de punta a punta de la empresa.
Sin dudas que el FC Barcelona o Barsa como lo conoce la gente (su central se observa dese la cima del Montjuic) es un claro ejemplo de implementación Lean. El club se ha transformado en los últimos años en un ícono mayor para la gran parte de la gente, sin importar el país o la pasión por el football. Y debo admitir que no soy un gran admirador de este deporte, pero sin dudas que han hecho un excelente trabajo que puede ser replicado un muchas empresas que deseen ser exitosas y comenzar a utilizar lean.

Sus jugadores, personal, sponsors e hinchas son apasionados de este y totalmente comprometidos con el club. El mismo tiene más de 150.000 socios, varios sponsors que generan envidia, finanzas sólidas y un claro ejemplo de insitución deportiva.

¿Cómo una institución puede tener tantos seguidores?
La Conexión Emocional o EC en inglés (Emotional Connectivity) es un término que resuena en cualquier empresa exitosa (Apple, Google, etc) y significa cuan emocionalmente apasionados son sus empleados por realizar su trabajo y la conexión que ellos tienen con la creencia de que la compañía y las metas propuestas por sus clientes son la verdadera guía y motivación.

¿Cómo se puede saber si una institución o compañía tiene un nivel alto de EC?
Cualquier mención a Barcelona FC y se generará una atención extrema y exacerbación de sus hinchas. Otro síntoma es apreciar cuantas personas que lo apoyan utilizan la camiseta o cualquier otra indumentaria del club.

¿Porqué los seguidores del Barcelona FC tienen tanta lealtad y compromiso con el club y su conexión emocional es tan fuerte?
Por empezar cada uno de sus miembros son embajadores del club y se sienten parte de la marca. A su vez, los miembros del equipo comparten la misma pasión con los jugadores e hinchas y la creencia en que el equipo trabaja día y noche para mejorar de forma rápida, organizada y eficiente todos sus aspectos. Veamos entonces cuales son los atributos del club que generan alto EC:

1. Todos los jugadores entrenan de forma muy exigente
2. El capitan es muy disciplinado y respetado como lider
3. No se toleran comportamientos egoistas dentro del equipo
4. Los jugadores deberán entender sus roles y estudiar a su oponente antes del juego
5. El entrenador tiene siempre un plan conciso y siempre estudia al rival
6. Durante las semanas anteriores, el club publicita a sus «clientes» a través de emails, teléfono, pancartas electrónicas cercanas al estadio, etc sobre su próximo partido u otra cosa de interés.
7. Los jugadores conocen sus estadísticas después de cada juego para así poder analizar su rendimiento.
8. El club evalúa cada semana el rendimiento y evalúa los posibles cambios de estrategia.
9. Los doctores y otros profesionales de la salud trabajan con aquellos lesionados para así poder prepararlos para el próximo evento.
10. El equipo de finanzas analiza el dinero que se recaudó de venta de entradas, publicidad etc.

Lo que estamos viendo aquí es un ejemplo excelente de la utilización de LEAN en una empresa a través de todos sus «departamentos», cosa que muchas veces es un misterio para muchos ejecutivos sobre como implementar LEAN. Digamos entonces que en términos de negocio, los 10 puntos anteriores se podrían traducir como:

1. Todos los jugadores entrenan de forma muy exigente – Alta productividad, no solamente actividad y movimiento
2. El capitan es muy disciplinado y respetado como lider – Liderazgo y respeto
3. No se toleran comportamientos egoistas dentro del equipo – Se es un equipo y no un conjunto de individuos
4. Los jugadores deberán entender sus roles y estudiar a su oponente antes del juego – Se analiza lo que el cliente desea y la mejor forma de llevarlo adelante
5. El entrenador tiene siempre un plan conciso y siempre estudia al rival – Pensamiento estratégico
6. Durante las semanas anteriores, el club publicita a sus «clientes» a través de emails, teléfono, pancartas electrónicas cercanas al estadio, etc sobre su próximo partido u otra cosa de interés – Comunicación abierta y transparente
7. Los jugadores conocen sus estadísticas después de cada juego para así poder analizar su rendimiento – Análisis constante basado en hechos y no en suposiciones
8. El club evalúa cada semana el rendimiento y evalúa los posibles cambios de estrategia – Revisión posterior a la implementación basada en hechos y no en suposiciones (mejora contínua)
9. Los doctores y otros profesionales de la salud trabajan con aquellos lesionados para así poder prepararlos para el próximo evento – Optimización (Inspeccionar y adaptar)
10. El equipo de finanzas analiza el dinero que se recaudó de venta de entradas, publicidad etc – Gestión de entrada y re-inversión en el capital gente

Los factores más comunes que obstruyen el crecimiento y la conexión emocional en las compañías pequeñas y medianas son:

• Liderazgo pobre – Me importo yo y no el equipo; no hay capitán.
• Gestionar por emails y no en sitio de trabajo, no hablar con las personas –  No hay liderazgo
• No se entrenan a las personas – No existe un regimen de desarrollo personal
• Personas equivocadas en un role inadecuad – Personas equivocadas en roles claves
• No existen procedimientos documentados y la misma tarea puede ser llevada adelante de diferentes formas – No existe un concepto de calidad
• Personas no conocen o comprenden la estrategia y se mueven a la deriva – falta de planeamiento
• No existe la revisión luego de la entrega sobre que se hizo bien o mal – No hay mejora contínua
• Equipos compitiendo entre sí – No existe el concepto de equipo 
• Generación de informes sobre datos que no producen valor – Desconexión de la realidad y disminución de la claridad/transparencia
• Nadie enseña a nadie – Nadie que guie y lidere, generación de silos

Es entonces que los siguientes factores son esenciales a la hora de crear una conciencia de crecimiento de la conectividad emocional en la empresa:

• Respeto
• Un equipo y no existe el término «Ellos y nosotros»
• Invertir el uno en el otro
• Creencia que se debe mejorar cada día y nunca se ha termido de crecer
• Comunicación efectiva
• Información en tiempo real y disponible o entendible por todos
• Los trabajadores deben todo a sus clientes y creen en la visión de la compañía
• Creación de planes que sean entendidos por todos y se puedan criticar abiertamente
• Re-inversión económica en la empresa y sus empleados
• Forma organizada que permita entrenar nuevas personas y mejorar las existentes

Recuerda que los lideres deben siempre liderar con el ejemplo, sus empleados creer en la empresa y estar abiertos a educar a otros. Por supuesto que la transparencia es un factor fundamental. En un entorno donde por ejemplo las personas tengan miedo de ser despedidas, no existirá implementación posible de LEAN, Scrum o cualquier otra metodología que se base en la conexión emocional. Recuerda que liderar es un camino que no tiene fecha de fin y donde la mejora es continua.
Si en tu empresa las personas no concen una respuesta casi inmediata a «¿Qué compañía admiras más?» enonces hay algo que no está funcionando.

En una empresa existen cientos de reuniones de todo tipo y casi a toda hora. He tenido incluso equipos de desarrollo donde… ¡el 60% de su tiempo era solamente reuniones!
En principio la idea es sencilla… contar con un mecanismo que permita de forma colectiva obtener consenso y posteriormente los resultados que permitan mover ciertos objetivos al próximo escalón. Normalmente, las personas se imaginan una reunión como un proceso lineal que se inicia en un punto en el tiempo y finaliza obteniendo las respuestas y los mayores beneficios para la empresa.

No obstante, muchas de las compañías que he ayudado estan lejos de ello. El mayor problema es que las reuniones ofrecen de una forma exacerbada la condensación de los problemas raíz que cuenta la empresa.

Si hay problemas de jerarquías, se plasmará esto en la reunión como una persona o grupo dominante. Si hay problemas de comunicación, se tendrán siempre los mismos individuos interactuando. Si las personas realizan multitarea en su trabajo diaro, entonces saldrán varias veces de la reunión para atender a otro asunto. Este mecanismo puede verse también enturbiado por:

• problemas de respeto hacia los compañeros o el cliente
• discusiones interminables
• mala comunicación o no efectiva
• personas que no entienden el contexto por no haber sido preparadas previamente a la reunión
• pérdida de noción o falta de objetivos hacia el cliente
• falta de visibilidad del proyecto o temas a tratar
• no ofrecer un entorno de aprendizaje y mejora
• desconocer como priorizar la toma de decisiones
• etc.

Piensa por un segundo… ¿Has experimentado alguno de estos inconvenientes?

«La reunión no es un mecanismo aislado, sino que una extensión de los demás procesos y valores de la empresa, con sus virtudes y defectos amplificados»

En algunos marcos de trabajo Ágiles, tales como Scrum, se tienen varias reuniones (Scrum Diario, Planificación de la entrega la que es opcional en Scrum, revisión del ciclo Sprint, retrospectiva, planificación del ciclo o Sprint) pero solamente se ofrece un patrón estricto para 2 de ellas, las que están centradas en mejorar el proceso:

1. Scrum Diario – Hay un tiempo límite, se realiza de pié, se cuentan con preguntas preestablecidas
2. Retrospectiva – Se debe analizar el último ciclo, se espera un resultado de la reunión (plan de acción), todos los miembros deben intervenir de igual forma sin importar su predilección de comunicación y se espera mejorar.

En las demás, la forma de llevarlas adelante se rige por resultado solamente, esto es, a criterio del consumidor.
Si estás de acuerdo en que las reuniones son un pilar fundamental en la empresa ¿No sería mejor emplear un conjunto de patrones que permitan que las mismas sean realmente efectivas?
Cuando digo esto, no hablo solamente de la preparación previa (la que considero imprescindible), sino de un protocolo que incremente el valor hacia la empresa y cliente.
Es aquí que entra en juego un modelo que siempre utilizo y que consta de 7 pilares o 7P, las que deberán ser seguidas sin exclusión si se desea lograr el mayor beneficio para la empresa y cliente; éste último es siempre nuestro objetivo final y al que se le debe brindar la mayor satisfacción posible (¡no olvides que es finalmente él quien paga tu sueldo y no tu empresa!).

El modelo de las 7P*
Propósito – ¿Porqué tenemos esta reunión? Se debe conocer de forma clara la respuesta. ¿Existe algo urgente? Si es ese el caso, ¿Qué está pasando y cual creo que es el problema? Si no es posible responder alguna de estas preguntas, quizá la reunión no sea necesaria o requiera más investigación/preparación previa.

Producción final – ¿Qué elementos se deberán producir como resultado de la reunión? ¿De que forma apoyarán la reunión? Si ella se centrará en hablar pero no hay elementos que la apoyen, piénsa en un par de ellos e imagínate su impacto.

Personas – ¿Quien necesitará acudir y cuál será su role? Si tienes problemas para definirlo, puedes pensar en aquel grupo de personas que puedan aportar preguntas y aquellas que podrán responderlas. ¿Son realmente las personas que invito las más adecuadas para responder a las preguntas?

Proceso – ¿Cuál será la agenda de las personas para crear el resultado? Es importante aquí que todos conozcan de antemano la agenda de la reunión.

Problemas – ¿Qué riesgos tiene la reunión y como los solucionaré/encausaré? ¿Debería poner reglas claras y hacerlas visibles? (ej. no teléfonos celulares, interrupciones o temas fuera de la questión)

Preparación – ¿Qué cosas deberían hacerse por adelantado? (lectura, investigación o tareas para que los invitados deberán realizar antes de la reunión)

Preocupaciones materiales – Problemas de locación o cualquier otra cosa física que apoye a la reunión y pueda no estar disponible.

(c) o’reilly 2010

Una de las cosas importantes a tener en cuenta es que las 7P influyen sobre las personas como una buena práctica. A su vez, alguno de los factores no esperados pueden cambiar la estrategia originalmente pensada, como por ejemplo, que pasaría si solamente una parte de los participantes acudiese a la reunión.

Con reuniones recurrentes (esas que muchos encuentran tediosas), es importante preguntarse siempre ¿Porqué tenemos esta reunión hoy?

Aumentar la visibilidad es una excelente idea… ¿Porqué no hacer visible los 7P durante la reunión?

Ten en cuenta si eres el  moderador de la reunión que el plan original puede cambiar, pero deberás siempre mantener el control de la situacion (recuerda las reglas).

¿Conoces mi libro sobre Cambio organizacional y agilidad empresarial disponible en 3 idiomas?

Gracias por escucharme,
Erich.

*El modelo de las 7P se acredita a James Macanufo

En cada curso de Scrum que dicto, hay una pregunta recurrente… ¿Qué libro me cuenta experiencias reales de Scrum y sus posibles soluciones?

La respuesta no es fácil ya que la mayor parte del tiempo los libros de Scrum o Agile se centran o bien en enseñar el marco o en discutir temas a un nivel de abstracción alta. Es así que cuando se comienza a aplicar Scrum , quien lo practica experimenta normalmente ciertos problemas, muchos de los cuales son comunes en la mayor parte de las empresas.

«Scrum es un marco de trabajo fácil de entender pero difícil de aplicar»

Buscar soluciones en Internet es una opción, pero normalmente requiere tiempo y leer varios sitios web o blogs, los que muchas veces nos dejan con mas incertidumbres que respuestas y es dificil conocer su credibilidad.
Es así que es importante asegurarse que obstáculos que encontramos al utilizar el marco de Scrum puedan ser resueltos de forma adecuada y entendiendo el porqué de la solución.
Una de las opciones podría ser contratarme para una consultoría, pero eso es difícil para algunas empresas, ya sea por tiempos o pasos necesarios para concretar la misma.

Es así que existe otra solución la que radica un libro que leí allí por Abril de 2012, el que es muy ameno y plantea cientos de ejemplos de la vida real y posibles soluciones. Mi colega Mitch Lacey ha hecho un excelente trabajo y publicado algo único en su especie.

The Scrum field Guide: Practical Advice for your first year

El libro es adecuado para todos aquellos que tengan ya cierto conocimiento de Scrum y experimenten el día a día, necesitando soluciones rápidas. Es también una excelente referencia para todos aquellos que deseen preparar el examen de Scrum Master certificado o refrescar los concimientos.

Debo decirte que se hace muy amena su lectura ya que expone situaciones reales con claridad, muchas de las cuales son muy graciosas (¡quizá porque noe stamos en sus zapatos!). Para los amantes de Kindle, el libro está también en este formato a un precio reducido.

Una buena forma de estar preparado para el día a día en Scrum y conocer a su vez más detalles sobre como llevar adelante las diferentes reuniones, porque elegir ciertos procedimentos, emplear soluciones de «emergencia» y detectar inconvenientes apenas aparecen.
Excelente recopilación de anécdotas, ameno, buen número de ejemplos y
técnicas, claridad en la exposición.

El precio es un poco más elevado comparado con
otros libros de Scrum o Agile.

Valoración 1 a 5:

Una excelente recomendación para el otoño de la zona Europea o primavera en América Latina.