Autor: erichbuhler

¿Cómo va el producto o iniciativa?

Seguro que escuchaste esta pregunta más de una vez en tu vida, y es que en definitiva, es normal que las personas quieran conocer como va el avance del producto/iniciativa y que tiempo llevará terminar el trabajo. De lo contrario, se estaría en un estado de caos, cosa no deseable en una empresa. He podido apreciar esto en varias ocasiones.

«Lo que no se define, no se puede medir, lo que no se mide no se puede mejorar, y lo que no se mejora se degrada siempre.»
William Thomson (Lord Kelvin)

Han sido muchos los proyectos o iniciativas donde me he visto involucrado y topado con personas que miden y realizan estadísticas por encargo, sin conocer o entender de lo complejo que el ser humano es cuando, se trata de medir algo intangible.
Muchas veces, las personas comprenden lo que se desea medir, pero desde una única perspectiva.

En ocasiones, estas métricas se crean sin informar a los individuos que hacen el trabajo de su existencia, o sin que se les explique para qué se necesitan. Ello evidentemente erode la confianza de los empleados y de los equipos.

Quizás has estado usando el marco de trabajo de Scrum ya por algún tiempo. Habrás visto que en este generalmente emplea el gráfico Burndown. Este indica  el progreso de las tareas que se están llevando adelante. Sin embargo, aunque esto puede ser útil, hay otras áreas que deben ser medidas si se quiere crear una organización ágil, donde la gente tenga el deseo de aprender y mejorar todo lo que se hace.

Existen diez reglas que te recomiendo seguir, y que confío en que ayudará a tu iniciativa y empresa a ser más exitosa.

Regla 1: Las personas que hacen el trabajo son las que más saben de dónde se encuentran
En las metodologías tradicionales es el jefe de proyecto el que de alguna forma trata de «explicar» el estado del proyecto o iniciativa basado en su experiencia. Este tiene a su vez la visión completa del producto o de lo que se desea hacer.

En las formas de pensamiento Ágile se incorpora un concepto que viene de las técnicas Lean, y que indica que es la gente que hace el trabajo la que realmente conoce donde se está.
Obviamente, esto asume que a las personas involucradas se les de el poder, visión y contexto para comprender y cambiar lo que se está llevando adelante.

Esto ayuda a dejar de lado la miopía de proceso vista en las metodologías tradicionales. Un ejemplo clásico de la miopía de proceso es la línea de montaje de Ford. Allí, cada empleado solamente conocía la tarea a realizar, pero no el resultado final.

Regla 2: Medir los resultados siempre con los individuos en mente
Cuando se realizan las mediciones, las personas deben comprender los valores y estar de acuerdo con los mecanismos empleados. De lo contrario, se estará dirigiendo la información hacia un resultado subjetivo.

Los valores y mecanismos deberán ser visibles y comprendidos por todos los integrantes de la iniciativa.

Regla 3. Ofrecer libertad de las acciones a tomar
Una vez que los valores han sido entedidos por las personas que realizan el trabajo, se les deberá dar total libertad de tomar las medidas que crean necesarias para así poder llegar a la meta prevista.

Ello implica el no realizar acciones deliberadas que puedan forzar (de forma pasiva o activa) a que los empleados tengan que acomodar sus formas de medir o interpretar los datos para ajustarlos a los resultados esperados por el resto de la empresa.

Recuerda que las decisiones externas a un grupo tratan de cambiar comportamientos, mientras que las internas refuerzan el crecimiento del equipo.

Regla 4. Nunca emplear métricas como método de presión o para castigar a las personas
Las métricas no deben ser utilizadas para forzar a las personas a producir más, sino que deberán ser empleadas para que sus miembros comprendan mejor la situación y así puedan aprender y buscar nuevas alternativas para alcanzar una meta.

Regla 5. Utilizar métricas convenientes
Las métricas convenientes son aquellas que están balanceadas  y pueden ser comprendidas por los diferentes miembros del equipo(s). Esto es lo opuesto a métricas complejas o aquellas que se centran solamente en las partes críticas o problemáticas.

Regla 6. Poner el foco en la meta final compartida
En un partido de football, el objetivo puede ser ganar, pero si observamos solamente a la métrica de goles por jugador, entonces desearemos automáticamente aumentar la misma. Ello dará situaciones tales como jugadores robándole la pelota a sus compañeros para así marcar un gol.

Obviamente  incrementaría el índice, pero no el rendimiento real del equipo.

Se debe poner el foco en la meta final o compartida y en el flujo requerido para alcanzarla, de una forma que no degrade la salud del equipo.

Regla 7. Mantener la métrica simple
No necesitas más de 3 o 4 gráficos para analizar el rendimiento real de un ma iniciativa o producto. Más de esto te llevará a confusiones.

Nunca debe ser una herramienta para demostrar lo inteligente que es un grupo de la empresa, sino que para ayudar a comprender lo que está pasando de forma sencilla, y con valores simples. Adicionalmente, debe ser fácil de gestionar y ayudar a reducir la complejidad de los procesos.

Regla 8. Discutir las métricas
La empresa debe siempre favorecer de forma proactiva y positiva que sus empleados puedan discutir/criticar las métricas de una forma franca y abierta, sin penalización alguna.

En organizaciones donde la confianza está comprometida, ello puede ser un desafío.

Regla 9. Asegurarse de que las premisas se encuentran bien planteadas
Crear un informe con premisas falsas o erróneas dará como resultado valores exactos, pero no reales.

Por ejemplo, medir productividad basada en líneas de código escritas por desarrollador (en vez de evaluar la calidad) o número de llamadas a un call center puede dar como resultado información exacta, pero que no sea de utilidad.

Mi recomendación es que siempre seas crítico con la meta final que se desea alcanzar y cómo las medidas se alinean con esta.
En definitiva un informe, cualquiera sea éste, debería cumplir con lo que yo llamo PDR:

P – Pronosticar
Ayudar a pronosticar con la mayor certeza posible el futuro cercano, por ejemplo, que se podrá terminar y cuando.

D – Diagnosticar
Ayudar a encontrar dónde se encuentra el problema y sus posibles soluciones

R – Retroalimentar
Brindar retroalimentación positiva para así mejorar los procesos del equipo o empresa.

Mejorar la forma de medir ayuda a comprender las interacciones internas del proceso y personas involucradas en la fabricación y funcionamiento de un producto. Ello hace posible el tomar mejores decisiones y acercarse así a la meta real.

Regla 10. Llegar a un balance
Se deben considerar múltiples factores y que ellos se encuentren plenamente balanceados.

Es así que la tabla a continuación te será de utilidad en estos casos. Ella fué confeccionada por Larry Maccherone y hace posible analizar varias áreas a medir, y a su vez, asegurarse de que ninguna de estas se encuentre infra o sobrevalorada a costa de otra.

El marco de trabajo original se creó para productos, pero también se puede utilizar para el cambio en la organización.

El cuadro se focaliza en 4 áreas, las que deberán ser observadas y consideradas con el mismo peso.

El cuadro superior izquierdo se centra en medir la velocidad de respuesta. Podría ser, la velocidad desde la concepción hasta su implementación para el caso de un producto, en el caso de un cambio en un área de la empresa la velocidad de adopción, etc. A la derecha se indica si se están haciendo las cosas bien (por ejemplo, la calidad correcta o las expectativas de los clientes o los empleados). En la parte inferior izquierda se indica la previsibilidad. Esto es, si tienes una velocidad constante que permita predecir los resultados y su tiempo sin afectar negativamente a los empleados, equipos o la salud de la organización.

Finalmente, «seguir haciéndolo» son aquellos hábitos, procedimientos o resultados que necesitan ser magnificados para tener éxito.

Mi recomendación es que observes si cuando creas las fomas para medir lo que deseas, se tienen en cuenta estas 10 recomendaciones.

Si quieres conocer técnicas avanzadas para mejorar tus equipos, te invito a conocer mi último libro «Lidera el cambio exponencial».

Gracias por escucharme,

Erich.

En esta nueva entrada verás como muchas áreas que parecían no estar relacionadas pueden afectar el funcionamiento de un equipo de alto rendimiento. Cuando la empresa empieza a usar Agile, comienzan a verse ciertos patrones de conducta que hacen que el implementar las metodologías sea un pequeño desafío cada día. La primera cosa a asumir es que esos inconvenientes no se dan como consecuencia del cambio de la forma de trabajo sino que en realidad estuvieron allí desde el principio.

Agile hace siempre que las fallas en los procesos queden expuestas y se muestren de forma explicita. El mayor inconveniente es que muchas veces no es fácil detectar donde se encuentra realmente el problema y en muchas ocasiones se tiene la percepción de que está en un lugar, mientras que en la realidad se sitúa en otro. Esto es lo que yo llamo el proceso espejismo y te contaré una historia para que veas como esto se da en muchos ámbitos.

Años atrás me encontraba en Inglaterra trabajando como Scrum Master al frente de 2 equipos de trabajo los cuales usaban tableros visuales Kanban para representar sus flujos de forma explícita y así dejar los procesos visibles para todas las personas. Durante varios ciclos de trabajo nos encontramos con un inconveniente que se repetía una y otra vez y que consistía en que los desarrolladores acusaban al tester de no ser lo suficiéntemente eficiente o rápido a la hora de probar las aplicaciónes.

El proceso espejismo
A primera vista parecería ser cierta la aseveración de los desarrolladores, sin embargo, un análisis más en profundidad me demostró que el problema se encontraba en otro sitio… el grupo de desarrolladores tenía una velocidad de finalización de historias de usuario no constante, esto es, una semana podían terminar un par mientras que a la próxima un número muy superior.

Esto daba como resultado que el tester no contaba casi con trabajo para probar la primera semana mientras que la segunda se generaba una cola interminable de requerimientos. Rascando un poco más pude apreciar que habían serios problemas de comunicación y colaboración, cosa que debería ser el punto de discusión en vez de quedarse con la visión simplista del tester ineficiente.

El sistema del reloj de arena
En teoría las empresas y sobre todo los grupos de trabajo deberían funcionar como relojes «Suizos» en cuanto a su coordinación, colaboración, confianza y excelencia técnica para así lograr un resultado óptimo, pero digamos que en muchos casos no es ni siquiera la regla. En el ejemplo anterior te he mostrado como hay una relación estrecha entre muchas áreas que parecen no estar conectadas pero que en definitiva son el centro del asunto.

Es así que hace algún tiempo atrás comencé a idear un sistema rápido para detectar sintomatologías de grupos Agile (pero puede ser usado para otras metodologías) para posteriormente conectarlas y descubrir el origen real del problema, cosa que en ocasiones no es fácil de apreciar directamente.

A esta técnica la denominé «El reloj de arena» por su similitud con el funcionamiento del mismo. La idea es sencilla pero muy poderosa, debes dibujar 5 líneas superiores y 6 inferiores, lo que dará un resultado similar a un reloj de arena y de allí su nombre. Cada una de las líneas o ejes representará una característica definida que te explicaré en breve.

Nota: Asumo que tu equipo realiza todas las reuniones obligatorias en Agile (¿Lo haces?)

Obviamente el flujo será siempre hacia abajo; la metáfora te ayudará a la construcción inicial y a comprender su funcionamiento. Ahora indica en la parte superior de cada eje (línea) los conceptos de:

1a. Colaboracion
2a. Excelencia técnica
3a. Honestidad y confianza
4a. Colocación/Comunicación
5a. Disponibilidad del dueño del producto

Te explicaré en breve qué significa cada uno de ellos. Por su parte, en el cuadrante inferior deberás contar con los siguientes 6 textos:

1b. Carencia de conocimiento específico
2b. Presión en el trabajo
3b. Centralización de conocimiento
4b. Multitaréa
5b. Estructura jerárquica
6b. Deuda técnica

Los números fluyen siempre hacia abajo como el reloj de arena y todos ellos con una escala del 0 al 5, comenzando o terminando en el centro. Como puedes apreciar, estos se encuentran con líneas sólidas a excepción de «Deuda técnica», la que está diferenciada ya que no deberías llenarla (la calcularemos en base a los otros valores).

“Deuda técnica (también conocida como deuda de código o diseño) es una metáfora que se refiere a las consecuencias eventuales de la evolución pobre de la arquitectura de software o desarrollo de código. Es en general la parte del requerimiento que normalmente no es su funcionalidad y que debido a ello no se hace y se dilata en el tiempo (ej. optimizar la base de datos), ya sea por apuro en la entrega o por el deseo de finalizar la tarea antes, lo que da como resultado que se ésta se acumule indefinidamente con otras»

Que el número sea más grande indicará que hay mas de ello (o mejor calidad para algunos casos), por ejemplo, honestidad 5 querrá decir que las personas del grupo confian plenamente en ellas mientras 2 que casi no cuentan con este valor. A su vez, el cuadrante inferiore destaca características que a mayor número más negativo será el impacto, por ejemplo, «Carencia de conocimiento» igual a 5 indicará que el equipo realiza tareas de desarrollo o trabaja sobre tecnologías que no conoce. Como regla general, todo aquello que se acerque al medio será siempre positivo, mientras que lo que se aleje tendrá un efecto negativo en el equipo o empresa. Veamos entonces los diferentes valores y una explicación; es importante que comprendas claramente cada eje ya que será la clave para que puedas interpretar correctamente los resultados.

1a. Colaboracion
Indica la colaboración efectiva entre los miembros del equipo. No hay que confundir comunicación con colaboración; algunos equipos son alborotados, hablan mucho, estan llenos de buenas intenciones pero no concretan las tareas ni finalmente colaboran de forma funcional. Para este último caso el valor será 0 mientras que colaboración sin barreras o perjuicios será 5.

2a. Excelencia tecnica
La primer pregunta es saber qué estándares de código y diseño se siguen, ellos son fundamentales a la hora de contar con calidad alta de codigo/diseño así como facilitar el mantenimiento y disminuir la deuda técnica. A su vez, mantener los documentos o cualquier otra información necesaria al día tal como la especificación de instalación, plan de contingencia, integración, etc es parte de la excelencia técnica. Si el equipo desconoce la respuesta a ésta pregunta entonces obviamente el valor será 0.

3a. Honestidad y confianza
Honestidad y confianza es algo siempre dificil de medir y detectar directamente, pero puede ser evaluado observando los conflictos del equipo. Alguno de los síntomas para saber si se cuenta con poca honestidad y confianza son estimados no realistas, acuse directo a personas por tareas no finalizadas, errores que se reiteran ciclo a ciclo, problemas de poder, etc. De verse alguno de estos entonces la honestidad brillará por su ausencia. La puedes también evaluar preguntando a los integrantes del equipo que depositen de forma anónima en una bolsa un valor de 0 a 5 indicando el nivel percibido de honestidad y confianza.

4a. Colocación/Comunicación
Quizas sea el elemento más fácil de ver a simple vista pero puede ser tramposo. Cuando todos los miembros del equipo se encuentran en el mismo sitio físico y se comunican efectivamente entonces será 5. Ahora bien, si algunas de las personas están en forma remota, el valor debería ser también el máximo si el grupo puede verse las caras en cualquier momento, ya sea mediante la colocación de cámaras y la posibilidad de comunicacación visual a un clic de distancia.

5a. Disponibilidad del dueño del producto
Un problema que padecen muchos de los equipos es no contar con el propietario del producto en su totalidad. Algunos están disponibles algunos días u horas de la semana y otros, aunque en teoría deberían estar a tiempo completo, se hallan tan ocupados que no tienen tiempo. A su vez, puede estar disponible pero existir problemas jerárquicos o lo que se llama «el arma invisible», esto es, la intimidación conciente o no que la persona ejerce sobre grupo, como si este estuviese armado.

Veamos ahora los valores del cuadrante inferior, los que tendrán un efecto negativo cuanto mas grande sea su valor.

1b. Carencia de conocimiento técnico
En algunas ocasiones los equipos carecen del conocimiento técnico necesario de fondo para resolver una tarea del ciclo. Este no radica en no saber como implementar una funcionalidad sino que en desconocer las características de la herramienta por no haberla utilizado anteriormente o tener serias dificultades. En general cuando esto pasa suelen hacerse sugerencias sobre la forma de resolver el problema basado en un supuesto funcionamiento de la herramienta, lo que obviamente aumenta la incertidumbre y riesgo y hace que los estimados estén más lejos de la realidad. Cualquier carencia de conocimiento técnico importante del equipo tenderá a acercar la evaluación al número 5.

2b. Presión en el trabajo
Si existen fechas impuestas de finalización así como otro tipo de presiones externas altas combinadas con las de carácter psicológico (miedo a ser despedido, trabajo de fines de semana,etc) en conjunto con reales (fecha de entrega fija debido a un cambio de legislatura o convenio con el cliente, etc), entonces se decantará hacia el número 5.

3b. Centralización de conocimiento
Imagínate que se requiere en cada ciclo 4 características particulares tales como comocimiento de base de datos, prueba, desarrollo y diseño de interfáz gráfica. Si alguno de estos se centra en una sola persona que se hace indispensable entonces el valor será 5. Para el caso que el equipo no sea totalmente funcional (diferente del concepto de todos pueden hacer casi todo) entonces subirá también.

4b. Multitarea
Si los miembros del equipo realizan multitarea de proyectos, esto es, se dedican a más de uno, el valor tenderá a subir. Te diría que si las personas están adjudicadas activamente a 3 o más proyectos a la vez el número debería ser 5.

5b. Estructura jerárquica
Si se cuenta con estructura jerárquica estricta y poco flexible dentro o fuera del equipo que influya activamente en las decisiones de los miembros del grupo entonces el valor será 5. Si de lo contrario, el equipo se auto-gestiona y decide como llevar adelante las tareas, se acercará al cero.

6b. Deuda técnica
Finalmente la deuda técnica no deberás marcarla ya que se te dará estimada como un resultado de los valores ingresados anteriormente. Recuerda que ella representa todas aquellas tareas que por apuro, presión o vagancia se dejan para mas tarde (sin afectar el funcionamiento del requerimiento), lo que hace una acumulación interminables de cosas que parecen prescindibles pero que se deberían llevar adelante en breve (también historias de usuario no funcionales).

Analizando los valores
Una vez recopilada la información y marcados todos los puntos en cada uno de los ejes tendrás una primera aproximación visual al estado del equipo. Como te indiqué anteriormente, los distintos ejes están inter-relacionados por lo que la deficiencia de uno de ellos afectará sin lugar a duda a los otros.

Nota: La deuda técnica aproximada debería darse como resultado de la media de los valores del eje inferior. Mayor número, más será la acumulación de la deuda técnica. En este caso la deuda técnica será posiblemente alta (4).

El cuadrante de inferior tiene evidentemente un peso significativo ya que influeye de forma negativa a los resultados de la parte superior. Por ejemplo, un equipo que realiza multitaréa constantemente (5) no podrá tener una excelencia técnica de 5, y para el caso que ello pase es una falsa percepción que debería ser ajustada a la baja. Basado en mi experiencia asumiré que el cuadrante inferior influye hasta en un 80% los valores de la parte superior, esto es, una media de 5 abajo supondrá una pérdida de 80% del valor arriba.
Calculemos entonces la media del cuadrante inferior en base a la imagen y veamos que porcentaje debería ser ajustado.

Media de los ejes inferiores:
(4+5+3+5+4) / 5 = 4.2

(80*resultado) / Valor Maximo = % detrimento

(80*4.2) / 5 = 67.2% de detrimento

Este caso nos ha dado que el eje superior deberá ajustarse a la baja, aquí será un 67% del valor indicado originalmente como resultado de las fuerzas que negativas sobre el funcionamiento del equipo. Esto te servirá para poder identificar claramente la diferencia entre la percepción y realidad funcional. Esta última se dará como resultado efectivo de tomar en cuenta varios de los factores mas importantes que afectan a las personas y su trabajo en equipo.

El sistema del reloj de arena podría ser empleado casi sin cambios para otras áreas de la empresa. Adicionalmente te sirve para que puedas pensar sobre las diferentes fuerzas que afectan a los grupos de trabajo, que quizá no hayas tomado en cuenta anteriormente.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Por muchos años me han hecho la misma pregunta una y otra vez, la cual radica en si las empresas de Latino América y España tienen las mismas características a la hora de comenzar a usar Agile con respecto a las anglosajonas. Por fin he decidido hacerme un poco de tiempo estas dos semanas que me encuentro en España dando formación para tratar de mostrarte 7 de las características que podrían marcar una diferencia importante al implementar las técnicas. Por supuesto que lo que te describiré no es parte de un estudio científico pero sí está avalado por mis años de experiencia, lo que verás a su vez tiene sentido común y puede ser aplicado directamente en la mayor parte de los casos.
Es importante que comprendas primero la situación particular de tu empresa y analices si se podrían dar más de uno de los puntos detallados a continuación:

1. Jerarquías bien definidas
El primer inconveniente que encuentro en Latino América y España es que las compañías cuentan en general con una estructura jerárquica más fuerte, la que tiene varios efectos secundarios a la hora de implementar Agile. La diferencia se ha analizado por varios expertos y pienso que podría ser debido a las distintas características de revolución que han existido en la historia entre Latino América/España y su contraparte anglosajona (revolución gloriosa en Reino Unido, USA, etc), lo que marcó la forma en cómo las sociedades han sido estructuradas. Sin irnos de tema, una investigación realizada por Conway demuestra que la estructura jerárquica de la empresa incide directamente en el código escrito.

«Ley de Conway: La estructura de una Organización se refleja en el código escrito.»

La estructura de organización jerárquica tradicional impactará en la estructura de forma negativa, resultando en código poco claro, mala arquitectura, mantenibilidad y adaptabilidad pobre así como costos elevados yfallas frecuentes. Esto es, en compañías con jerarquías más estrictas el código orientado a objetos será menos óptimo y flexible, lo cual aumentará a su vez la cantidad de fallos y los tiempos desde la idea del cliente hasta su concepción final. Por otro lado la llamada «Deuda técnica» o de diseño/código (todo aquello que deberías hacer pero podrías dilatar para más adelante) es muchas veces omitida, lo que hace que finalmente se enlentezca aún más el proceso de programación y se desmotive a los miembros de los equipos ya que, en muchas generalmente, el trabajo se hace más duro y el riesgo se aumenta.

 «Deuda técnica (también conocida como deuda de código o diseño) es una metáfora que se refiere a las consecuencias eventuales de la evolución pobre de arquitectura de software o desarrollo de código»

La relación con los clientes o Propietario del producto también es estructurada de forma jerárquica, lo que conlleva a que los miembros del equipo tengan muchas veces dudas sobre si plantear la necesidad de realizar ciertas tareas de mantenimiento interno por miedo a reprimendas.
Imagínate que el Dueño del producto sugiere un cambio en una base de datos que traerá consigo la necesidad casi obligatoria de optimizar otras áreas del producto o de lo contrario se hará más difícil escribir código en el futuro cercano. Ésta charla podría no ocurrir ya que en muchas ocasiones el último es visto como jefe, lo que dará como resultado que las tareas adicionales no sean llevadas adelante.

Si no hay coraje para hacer lo que se piensa, lo que normalmente es correcto será lo que no se hace.

SOLUCIÓN: Tu eres un profesional
En principio cada individuo que trabaja en sistemas, tanto provenga de una universidad o haya efectuado su formación en la empresa, debería considerarse a sí mismo como un profesional y actuar de acuerdo a ello. Imagínate un doctor dilatando la decisión de indicarle a un paciente el tomar cierta medicación por miedo a lo que pensará de sus efectos secundarios o un arquitecto prorrogando modificaciones en un puente porque luego del estudio de viabilidad se comprobó que hay que adicionar dos nuevos pilares.  Obviamente éste tipo de situaciones no ocurre en dichos ámbitos ya que ambos se consideran profesionales.
Ante la duda, actúa profesionalmente siempre informando sobre tu opinión basada en tu experiencia y asegúrate que las personas sean comunicadas y los posibles problemas se hagan visibles, tanto en medios informáticos como en papel (colocando tarjetas o pancartas en las paredes que recuerden los problemas acarreados).

2. Disponibilidad de ofertas de trabajo
En algunos mercados donde el mercado no ofrece muchas oportunidades a nivel laboral o se encuentra en recesión (como es el caso actual de España), los miembros del equipo pueden temer por sus puestos de trabajo. Debido a ello, comienza un círculo vicioso que es muy peligroso para la empresa, el cual se caracteriza por que los empleados no sugieren nuevas ideas o soluciones debido al miedo mayoritariamente irracional de la pérdida del puesto de trabajo. Esto hace que la empresa comience un ciclo de no-innovación en que hunde más a la misma.

SOLUCIÓN: Reafirma la innovación y ofrece un ambiente seguro
La empresa desde el ámbito gerencial deberá ofrecer un ambiente de trabajo que integre de forma implícita los medios para que las sugerencias de nuevas ideas -incluso de aquellas vistas como radicales- sean siempre bienvenidas y canalizadas por un canal que acepte la evaluación dentro de un marco de trabajo que demuestre seguridad y positivismo hacia ellas. Ello asegurará a la compañía innovación y detener automáticamente el circulo vicioso de degradación.

3. Creencias sobre la organización… (La creencia del León)
En muchas ocasiones los empleados tienen la creencia de que no pueden realizar cambios a la estructura o las opiniones serán valoradas. Esto es como la creencia del León, el cual es el rey de la selva en teoría, pero en realidad éste nunca vivió alli. Las creencias pueden ser tan fuertes que los miembros de un equipo pueden seguir indicaciones de forma ciega y sin cuestionar el porqué.

Recuerdo todavía una de las empresas en las que trabajé en donde era necesario enviar un email a una dirección no monitoreada y copiar el mismo a una carpeta de la red con la lista de las Historias de usuario finalizadas. Este proceso que parecía obvio para todos, no tenía sentido alguno y no ofrecía valor de negocio alguno, pero era efectuado de forma casi automática.

SOLUCIÓN: Fomenta la crítica
Fomenta que los miembros de la empresa critiquen los procesos de forma positiva, esto es, preguntando porqué eso está allí, reviendo el valor de negocio y ofreciendo soluciones. Para que esto pase se deberá siempre ofrecer un marco de trabajo informal y estructurado en donde los empleados se sientan confortables y se cuente con una política activa de mejora de procesos activa (como podría ser LEAN).

4. El efecto del paquete cerrado
En los mercados anglosajones cuando ciertas técnicas (como ser Agile) se implementan en la empresa, ella se adapta de acuerdo a las necesidades. El problema que existe en muchas compañías de habla hispana es que la mayor parte de las técnicas  con ideas que provienen de mercados más grandes se toman como un paquete cerrado, el que deberá ser seguido de forma estricta. Esto hace que no exista un crecimiento real o crítica y adecuación (inspeccionar y adecuar) lo que deriva muchas veces en el fracaso institucional.

SOLUCIÓN: Piensa en los procesos de forma proactiva
Criticar todo aquello que se implemente una vez visto sus resultados, analizar si existen casos similares en empresas del exterior y rever aquellas medidas tomadas, así como también evaluar las posibles modificaciones siempre y cuando se lleven adelante empleando un modelo empírico (probar y ver los resultados para luego tomar decisiones, así como también compararlos constantemente con el mercado internacional).

5. Formas de expresión diferentes
Los hispanoparlantes suelen comunicarse verbalmente en formas que pueden ser vistas muchas veces como no tan organizadas y alborotadas en comparación con su contraparte anglosajona. Esto que resulta no tan obvio, puede degradar rápidamente la comunicación y hacer que los individuos más tímidos no tengan la ocasión de expresar sus ideas u opinión.

SOLUCIÓN: Asegúrate todos tienen voz
Es aquí que a mi criterio se deberían emplear mapas de interacción (ver artículo sobre Retrospectiva en Agile) y asegurarse que la comunicación entre miembros del equipo y otras partes sea organizada y efectiva. De ser un problema, el Scrum Master o cualquier otra persona en la empresa debería ser capaz de poder identificar y sugerir los cambios necesarios para mejorar la comunicación y efectividad de los mismos.

6. Documentación y traducciones al Español
Muchos años atrás colaboré con la traducción de varios libros técnicos para el mercado hispanoparlante. El problema surge en que aquellos de lenguajes o infraestructura son siempre puntuales y lo que se dice puede ser verificado en todos los casos con el código. Cuando hablamos de metodologías Agile, esto es diferente ya que mayoritariamente involucra gente y procesos. Es así que la diferencia entre una traducción empleada y otra puede dar como resultado una diferencia abismal, cosa que podría ser totalmente captada por el lector, aplicándose posteriormente la idea de forma incorrecta.

SOLUCIÓN: Coteja varias fuentes
Verifica los conceptos con otras fuentes de forma explícita y asegúrate que los mismos son similares a los que se aplican en otros lugares. A su vez, las compañías deberían en mi opinión emplear un «Coach» por el primera año Agile para que de esta forma se puedan “tirar” de las cuerdas correctas sin la necesidad de correr el riesgo de una mala interpretación.

7. Agile mal aplicado
En Uruguay he visto por ejemplo que muchas empresas no emplean Agile por considerarlo como técnicas para proyectos pequeños. Esto es así ya que hace varios años atrás se intentó implementar Agile de forma incorrecta, lo que dio como resultado dicha creencia.

SOLUCIÓN: Analiza seriamente los motivos
Verifica que los mitos y restricciones sean reales y trata de analizar seriamente los motivos de fondo de ellos. ¿Es una restricción institucional? ¿Se han seguido todos los pasos sugeridos o han omitido por creerlos no necesarios? En principio te sugeriría que la empresa siguiese estrictamente todos los pasos sugeridos así como se sometiese a retrospectivas regulares para inspeccionar y mejorar los procesos sobre bases ciertas. Planes de acciones definidos y pruebas empíricas deberían ser empleadas constantemente y como práctica habitual.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

La séptima encuensta anual del estado de desarrollo Agile ha sido publicada por VersionOne el pasado mes de Febrero de 2013 y contiene información muy interesante sobre el estado de las metodologías y tendencias.

Comencemos con un poco de historia
A mediados de 2000 existió en Latino América y España una tendencia a probar las metodologías Agile en diferentes empresas. Éste primer intento simplemente se remitió a integrar algunas de las técnicas de manera parcial, continuándose en el resto del equipo y compañía con la utilización de los métodos tradicionales.

A su vez, no se hicieron cambios de fondo en la estructura, por lo que los mandos gerenciales continuaban empleando el modelo de comando y control con los grupos, así como también gestionando los requerimientos sin la inclusión de los integrantes del equipo y otras partes interesadas. Debido a esto, surgieron algunos pre-conceptos que todavía pueden verse afianzados en estos mercados hispanoparlantes:

1. Creencia de la inutilidad de las técnicas
Las compañías descartaron a las metodologías Agile y volvieron a los modelos tradicionales por creer que el punto de falla se encontraba en Agile. Se pensaba que no se adaptaba a los mercados de habla hispana o no ser capaces de resolver los problemas locales.

2. Fijación de creencias falsas
Debido a que las técnicas no fueron aplicadas correctamente o en su totalidad pero si llamadas Agile, se reafirmaron varias ideas como ser que no eran mas efectivas que los modelos tradicionales o que no podían ser empleadas en proyectos de gran porte o distribuidos. Ésta última se incrementó en Latino Americana, donde un trabajo de fondo será necesario en los próximos años para demostrar lo contrario.

Un motivo importante del crecimiento de las creencias fue que no se contaba todavía con investigación sobre los efectos de la implementación de Agile en la empresa. Afortunadamente ahora se tienen mucho mas detalles y los resultados son claros. De acuerdo al estudio CHAOS de Standish Group en 2011, solamente un 14% de los proyectos llevados adelante con las metodologías tradicionales (Cascada, etc) son exitosos contra 42% bajo Agile. A su vez, los métodos en cascada fallaron en un 29% contra 9% de Agile.

Los desarrollos Agile son 3 veces más exitosos que cuando se realizan con metodologías de Cascada (Waterfall). (C) Standish Report

Resultados de la encuesta 2013
El mes pasado (Febrero) se publicaron los resultados de la séptima encuesta del estado de desarrollo bajo el marco Agile, de donde se desprenden varios valores importantes de analizar. Los resultados involucraron a un 60% de empresas de USA, 27% Europeas y las restantes de otros paises. De ellos 3/4 son compañías de una media de 100 personas, mientras que el restante 1/4 de más de 500.

«3/4 de empresas tienen una media de 100 personas y 3/4 de más de 500»

De estos grupos, se deprendió que su gran mayoría (44%) utilizaban Agile para construir un producto que posteriormente se comercializaría en el mercado, 33% para uso interno y el resto (23%) en servicios de IT. Puedes ver que se abarcan aquí estructuras similares a las que puedes encontrar en Latino América o España.

«44% construir un producto comercial, 33% interno, y 23% servicios de IT»

Uno de los datos que se diferencian con las las empresas Españolas o Latinoamericanas es que la mayor parte contaban ya con profesionales de Agile que venían ejerciendo por al menos 3 a 4 años. Es quizá por ello que el 84% emplean Agile mientras que solamente 16% los modelos tradicionales.

«84% utilizan Agile y 16% metodologías tradicionales»

Para mi sorpresa, solamente el 54% hace uso de Scrum, mientrs que la utilización de Scrum/XP fue de 11% y 4% de Kanban; cosa que imagino se verá ampliamente magnificado en este año 2013 debido a los grandes beneficios que estas dos últimas técnicas ofrecen como herramientas integradoras.

(C) Version One 2013

Miedos y porqué usar Agile
El mayor miedo reflejado en la encuesta fué la falta de planeamiento inicial en los proyectos (83%) seguido (31%) por la supuesta pérdida de control en la gestión de los procesos (dejadas en manos de los grupos auto-administrados) y finalmente la oposición de los mandos gerenciales (27%) y falta de documentación (26%).
La mayor parte implementaron Agile debido a que mejoraba sustancialmente la calidad del producto final así como también su productividad y permitía la gestión más eficiente de los requerimientos y la visibilidad general de las metas.

Lecciones aprendidas en los últimos años
En cuanto a las lecciones aprendidas en los últimos años, yo personalmente he visto la tendencia de incorporar Agile de punta a punta en la empresa (no solamente en los grupos de desarrollo como islas aparte), con el fin de asegurar la escalabilidad y eficiencia real. Ello se viene afianzando desde hace algún tiempo con el empleo de las técnicas de Lean y los conceptos de radiadores visuales y adminitración de flujo de Kanban, lo que  a mi parecer tendrá una implicancia mayor en éste año 2013.
Se vió también que lo más importante cuando se quiere implementar Agile es el apoyo de los grupos gerenciales, sin ellos está claro que todo cambio se verá obstruído por la resistencia y fricción típica en estos casos (de la cual te hablé en estos los artículos de Resistencia Institucional y cambios hacia Agile Parte 1 y  parte 2).

Una cosa que me llamó poderosamente la atención fue que el informe no incluía todavía uno de los puntos más importantes en Agile que consiste en la gestión y redacción mucho más eficiente y honesta de los contratos entre clientes y empresas de software (prometo escribir sobre esto en algún momento).

Te dejo el vínculo para que puedas corroborar tu mismo los datos y re-pensar la estrategia de tu empresa.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recusos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

 

Varios años de experiencia en retrospectivas en diferentes culturas me han dado como resultado algunas técnicas interesantes para mejorar el rendimiento de tu equipo y entender más sobre el funcionamiento humano. En ésta entrada te lo mostraré desde el punto de vista de un Scrum Master, pero podría ser aplicada y brindada al grupo por cualquier integrante.

La retrospectiva Robot
Especialmente para los recién entrados en la dinámica Agile (aunque también lo he visto en grupos que llevan ya cierto tiempo), las retrospectivas se convierten en reuniones muy automáticas («robóticas») y siempre al final del ciclo; esto es:

1. Se plantea lo que se hizo mal
2. Se indica lo que se podría mejorar
3. Se comenta lo que se hizo bien
4. Se ponen ciertas medidas o ajustes y finalmente se da por acabada la reunión.

El mayor problema es que ésta modalidad en el largo plazo puede ocasionar mas inconvenientes que soluciones. El primer punto a entender es porqué se llevan adelante las reuniones en Agile/Scrum y cual es el fin de realizar ciertas preguntas. El hecho de que las preguntas estén allí no es primordialmente para para conocer información acerca del resultado de los procesos, sino que principalmente para modelar un comportamiento, esto es, poner a los individuos dentro de cierto patrón de pensamiento y acción.

«Las preguntas en las reuniones Agile se efectúan para modelar un comportamiento»

Por supuesto que de forma secundaria está el obtener información y hacer algo con ella, como ser remover obstáculos, cambiar un proceso, etc.
La retrospectiva es algo entonces que no debe ser tomada a la ligera ya que es el único punto donde el grupo puede radicalmente cambiar su dirección mediante la toma de decisiones, adoptar medidas y aprender para el mediano y largo plazo. Podrías pensar que la reunión Standup diaria tiene un fin similar, no obstante, ésta última ataca obstaculos relacionados principalmente con las historias de usuarios y no del grupo en si.

La mayor carencia con la modalidad de reunión «robot» es que existen infinidad de problemas que no pueden ser sacados a la luz a no ser que se empleen técnicas que apunten estos inconvenientes de forma directa pero despersonalizada. Acuérdate que el trabajo del último ciclo es siempre:

1. Reciente
2. Involucra a todos en forma grupal y principalmente personal
3. Las personas se sienten orgullosas de lo que desarrollaron

Es así que varios problemas pueden esconderse bajo formas de trabajo no adecuadas que muten ciclo a ciclo con el fin de poder «ocultarse» de la vista de un simple mortal.

El modelo de Muzafer Sherif problema 1
Imagínate que tu eres nuevo en un grupo Scrum de 5 personas y que a uno de los integrantes más aceptados no le gusta o quiere escribir pruebas unitarias. El resultados menos deseable es que otro integrante o integrantes decidan cubrir la tarea mediante la escritura adicional de los mismos ciclo a ciclo. Esto que puede parecer trivial, hace que el problema de fondo enmascare a una problemática que afectará el rendimiento del equipo en todos sus ciclos Sprint futuros y que raramente podrá ser detectada en una retrospectiva «robot». Esto es así ya que los miembros encontraron una «solución» paleativa de corto plazo, la que será luego extendida indefinidamente.

Muzafer Sherif

Este proceso que fue explicado por Muzafer Sherif, famoso sociólogo nacido a comienzos del siglo pasado. Éste indica que el grupo ejerce influencia normativa, ya que mantener opiniones diferentes puede afectar a la integridad del equipo y así ocasionar rechazo. De esta forma, si alguno de los actores que cuentan con más influencia deciden moverse en otra dirección,  los demás podrían aceptar el problema y buscar una solución «temporal» para no generar un rechazo. Así se estará alejando paulatinamente de la optimización de las tareas, cosa fundamental en Agile.

El modelo de Muzafer Sherif problema 2
Ahora imagínate que no eres nuevo y tienes algo más de soltura con el grupo de Scrum y decides mencionar el problema. En todo caso, se podría aplicar la segunda regla que especifica que constantemente corroboramos la información con los demás integrantes del grupo, por lo que si opinamos algo diferente a lo que el conjunto opina, adoptaremos su punto de vista para evitar estar equivocados. Esto obviamente haría que finalmente -y aunque pienses que las cosas no están bien- aceptes la mayoría por miedo a equivocarte.
El resultado final es que el proceso se verá altamente comprometido, eso es, se generará un montón de tareas pequeñas que consumirán tiempo y no redituarán en valor agregado al cliente ni equipo.

La solución para el problema de Sherif 1 y 2
Ante la duda recomiendo emplear siempre una de las reglas fundamentales de las metodologías LEAN la que indica que se debe optimizar siempre el tiempo de la totalidad de los procesos desde el nacimiento del requerimiento hasta que el cliente lo tiene en sus manos (en este caso en software funcionando) y retirar todos los bloqueos que obstaculizan al mismo.

Por ejemplo, una pregunta acertada en la retrospectiva sería «¿Qué procesos nos inhabilitan a reducir los tiempos desde concepto a entrega?» y se podría mostrar un esquema de los sitintos procesos y tiempos.

Mala aplicación de la teoría de encolamiento y restricciones
La teoría de encolamiento y restricciones reconoce que la producción de un sistema consiste en múltiples pasos, donde el resultado de cada uno de esos pasos depende del resultado de pasos previos y plantea soluciones para mejorar los pasos menos productivos. Imagínate que en cada ciclo de trabajo los desarrolladores se quejan porque el o los «testers» toman mucho tiempo en realizar las pruebas. Un vistazo inicial al proceso podría verse como el siguiente:

Asumiendo que el cuello de botella está en los procesos de prueba, el grupo podría elegir en la retrospectiva llevar adelante alguna de las siguientes acciones para el próximo ciclo:

1. Adicionar mas «testers»
2. Mover ciertos desarrolladores a la parte de prueba para ayudar a los «testers»
3. Evaluar otro software de pruebas que sea más rápido

No obstante, esto daría en la mayoría de los casos una caída en la productividad debida a la curva de aprendizaje o menor cantidad de recursos disponibles en un área por el pasaje a otra. En realidad, un análisis por menorizado nos muestra que el problema no está en el proceso de prueba sino que el cuello de botella se encuentra en el desarrollo, el que no cuenta con un micro-ciclo consistente y finaliza todas sus historias de usuario y pasaje a los testers al mismo tiempo, produciendo así un bloqueo del proceso.
Esto puede ser el resultado de un tamaño excesivo de historias de usuario, otros procesos que consumen tiempo de desarrollo pero no agreguen valor, o incluso un mal funcionamiento del sector de programación ya sea por requisitos definidos por el grupo o políticas de la empresa.
Es así que nuevamente hay que analizar los micro-procesos de forma unitaria y ligarlos a su totalidad para ver porqué un área del equipo se ve desbordada de trabajo. A su vez, lo que yo llamo presbicia de proceso (incapacidad de ver algo si lo tienes cerca) y el cuidado que ponen muchas personas en no herir a otras, hace que los problemas no puedan salir a la luz mediante el desarrollo de una retrospectiva típica.

Técnica abstracta: la música
Una de las cosas que hay que tener en mente es siempre deslindar el sentimiento personal sobre las tareas realizadas y asumirlas a modo de grupo. Si se falló ha sido el equipo y nunca un individuo en particular (esto asume sinceridad y no solamente que se diga pero no se asuma). De haber un conflicto siempre se deben poner reglas claras sobre comportamiento y respeto mutuo y exhibirlas al comienzo de cada retrospectiva.
No obstante, el elevar los problemas a un plano mas abstracto puede ayudar; yo he experimentado con la técnica que te detallaré y obtenido un resultado excelente.

El funcionamiento
1. Se reparte a cada integrante una tarjeta y un lápiz
2. Se solicita a los participantes escribir en un trozo de papel hasta 2 temas musicales que representen al último ciclo de trabajo
3. Se pide de a un intrgrante a la vez que explique el porqué del tema musical.
4. Opcionalmente se puede solicitar a la persona que cante un trozo, lo que hará la reunión más divertida.

Ej.
Pedro: «Elegí «Welcome to the jungle de XXX» porque ha sido como una jungla para mi, cuidándome la espalda todo el tiempo, corriendo y viendo si sobrevivo;  finalmente elegí la 5ta sinfonía de Beethoven porque el final fué muy armonioso »

Es normal que los primeros participantes comiencen tímidamente su exposición y poco a poco se animen a más, por lo que es siempre recomendable elegir a las personas más extrovertidas al principio. A su vez, se busca inicialmente respuestas metafóricas como «corriendo y viendo si sobrevivo». Obviamente no se trata de una situación real, ya que de lo contrario el integrante sería integrante de un grupo de choque de la marina y no de desarrollo de software.

Regla 1:
Cuando se hace la exposición no debes interrumpir a la persona hasta que termine pero si tomar nota. Una vez finalizada debes comenzar a preguntar en forma figurada pero que lleve a resultados directos, por ejemplo «¿Qué quieres decir por correr por tu vida?» y mover las respuestas poco a poco hacia términos reales.

Más abstracto                                            Más directo
<————————————————————->
1era pregunta ->
………2nda pregunta ->
……………………………………etc ->
………………………………………………etc ->

Regla 2:
Una vez que se tiene algo como «El Jefe de producto me presionó para terminar con la historia», no emites opinión personal, lo anotas en una tarjeta y lo pones en la pizarra.

Regla 3: 
Una vez finalizada la vuelta agrupas o remueves aquellos redundantes y le pides al equipo  que los pongan en orden de prioridad de acuerdo a lo que consideren haga mas daño a menos.

Regla 4:
Finalmente seleccionas 4, examinas posibles soluciones y medidas a tomar en el próximo ciclo y las anotas y las dejas disponibles para que el grupo las vea día a día o pones algunos centinelas que verifiquen que todo va bien.

Técnica abstracta direccional: los personajes
Uno de los inconvenientes que puedes encontrar es que pese a que el problema esté allí y  sea visible para ti, no sea obvio para el grupo y no pueda ser obtenido mediante la técnica anterior. Es así que esta segunda opción emplea algunas prácticas «inocentes» y más acertivas que comienzan poco a poco a involucrar a la retrospectiva los problemas existentes.

Preparación
Antes de la reunión deberás buscar fotos de dibujos animados e imprimirlos (tantos de cada uno como personas en el equipo; si hay 5 personas y tienes 10, entonces imprimirás 50). Si el ciclo ha sido caótico, puedes poner más dibujos animados de guerra, si han habido conflictos de poder podría ser la imágen de un dibujito que a tu criterio lo represente (podría ser por ejemplo Pinkie cerebro), etc.; todo esto mezclado con otros más generales.

El funcionamiento
1. Se cortan pequeño y se ponen todos los impresos en la mesa y se da 1 minuto a los integrantes para seleccionar hasta 3 personajes que representaron el último ciclo.
2. Pedir a un integrante a la vez que explique el porqué de su selección y aplicar la técnica de pregunta global a específica indicada anteriormente.
3. Anota en una tarjeta la respuesta final y ponerla en la pizara.

El proceso posterior es similar, se analizan los problemas, se priorizan y se busca un plan a llevar adelante.
La principal diferencia con la técnica de la música es que aquí se pueden elegir personajes que por sus características pre-dispongan/dirijan a los miembros del equipo a «atacar» a ciertos problemas.

Técnica de acción-reacción
Éste método se me dió como resultado en uno de los equipos bastante conflictivos que tenía en una de las empresas Londinenses y es muy efectivo por su naturaleza, pero  requiere en general que los miembros lleven trabajando junto por algun tiempo.

Preparación
La idea es que durante el ciclo se anoten en tarjetas los problemas que van surgiendo, por ejemplo: «Cierto miembro da órdenes a todos los integrantes con los que programa.» y se guarden. Luego antes de retrospctiva se deben transformar estas a nivel general y en forma de pregunta, por ejemplo:

«Jorge da órdenes a todos los integrantes con los que programa.» –> «¿El trabajo en pareja funciona con igualdad de roles o jerárquicamente?»

El funcionamiento
Durante la retrospectiva se deben poner todas las tarjetas en una pizarra dadas vuelta (para que lo sintegrantes no las puedan leer), y se emplea alguna de las técnicas anteriores o las 3 preguntas de la retrospectiva «robot». Finalizada con la parte de averiguación y cuando están ya todos los problemas planteados por el equipo y visibles en la pizarra, se dan vuelta los previamente cubiertos y se discuten para ver si hay algo que se había perdido. En general lo que suele pasar es que el equipo no «descubre»  ciertos problemas que se encuentran ocultos hasta que se efectúan las preguntas de las tarjetas pre-escritas.
Luego nuevamente se priorizan los problemas, se indican pasos a seguir y se termina con la reunión.

Esta última técnica es de mucha utilidad cuando el equipo no es capaz de visualizar problemas, se haya olvidado por el estrés del ciclo, o encubierto con alguna accion paleativa.

Finalmente, puedes realizar retrospectivas en cualquier punto, no tiene por que ser al final del ciclo; si hay un problema entonces ella puede ser una solución. Con equipos nuevos es siempre recomendable hacer la retrospectiva parado (removiendo las sillas, mesas y dejando solamente la pizarra) ya que de lo contrario, se tenderá a bifurcar en las conversaciones).

Recuerda… el éxito para una buena retrospectiva es siempre su preparación y no te olvides que los procesos están basados en personas, las que actúan siguiendo un protocolo o interacción que puede ser cambiado siempre y cuando las acciones no sean abruptas y el individuo vea el valor positivo del cambio.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

 

Si eres nuevo en el mundo de Agile habrás visto que al final de cada ciclo (Sprint) se realiza una reunión donde básicamente se analiza lo que se ha hecho bien, las cosas que no ha salido como se esperaba y que se puede todavía mejorar. En principio esto puede parecer una reunión fácil de llevar adelante, pero debo decirte que en mis años enseñando Scrum, he visto como fallar en estas ha desmoronado la moral y la productividad de los mejores equipos de trabajo, aquellos más motivados y que parecián indestructibles.
En las reuniones de día a día (Stand Ups) se detectan inconvenientes, los cuales se corrigen sobre la marcha, pero es en la reunión de retrospectiva donde se marca el rumbo y se solucionan los problemas de fondo.
Esto es así ya que al final del ciclo siempre se tiene una visión más clara debido a que:

1. Se pueden enumerar parte de los problemas
Se han finalizado con parte o todas las historias de usuario y han sido aceptadas por el dueño del producto, lo que nos permite poner un punto final. Esto hace que sea mas fácil enumerar los problemas habidos en las distintas etapas.

2. Fin de la miopía del ciclo
Mientras se está en el ciclo se tiene lo que llamo la «miopía de ciclo», en el cual no podemos ver más alla del trabajo que tenemos pendiente por estár zambullidos en los problemas del día a día e historias restantes.

Es así que la retrospectiva es el único mecanismo que permite corregir el rumbo (o inspeccionar y adaptar) y asegurar que se crezca como equipo, a nivel personal y de empresa. No debemos considerar a la reunión como un simple espacio para analizar lo que se hizo mal, ya que de ser así, se estará eligiendo un camino simplista que reducirá la efectividad y potencial de la retrospectiva y hará que los miembros del equipo la vean como algo factible de omitir al final del ciclo.
Esto son algunas de las cosas que deberían darse como resultado de la retrospectiva:

1. Analizar y aprender nuevas formas de interacción con las personas del equipo y/o externas al mismo así como analizar su funcionamiento.

2. Inducir nuevas reglas internas de trabajo y/o modificar las actuales.

3. Vislumbrar soluciones a problemas existentes, tanto sean tecnológicos como de poder (comando y control).

4. Analizar lo que se hizo exitosamente y asegurarse de que se mantendrá ésto en el futuro.

5. Dejar sentado restricciones/formas de trabajo claras para que sean comunicadas a actores externos del grupo. 

6. Seleccionar aquellos problemas más destacados, priorizarlos y buscar una solución.

La retrospectiva es un elemento importante que, de ser llevada correctamente, aumenta la confianza y seguridad de las personas del equipo, haciendo que ellas trabajen en confort y puedan aumentar su rendimiento y productividad.

Problema 1: No hay tiempo para la reunión de retrospectivas
Éste es uno de mis puntos favoritos y que he visto más frecuentemente. Si bien a simple vista parece que las personas no tienen tiempo, una visión más cercana puede denotar problemas estructurales todavía más graves, como por ejemplo:

1. Los miembros del equipo no confían en si mismos u otras personas de la empresa (o temen por su puesto de trabajo), lo que hace que no quieran ser expuestos a la fragilidad de poner a la luz los problemas.

2. Trabajan en varios proyectos al mismo tiempo (multitarea), lo que da como resultado que no puedan centrarse en el equipo o historias de usuario. Esto es un déficit en la forma de trabajo Agile, generando ruido (o lo que se llama Muda en las metodologías Lean), bajando así la productividad final. Se deberá aquí buscar una solución que involucre el compromiso de las personas con el proyecto y los estimados.

3. El Scrum Master no es capaz de llevar adelante la reunión de forma en la cual se extraigan realmente los 6 puntos mencionados anteriormente. Debido a ello los miembros no la ven como algo importangte o interesante. Planificación es siempre el mejor antídoto y el que te recomiendo.

4. Las historias de usuario no son suficientemente pequeñas o los estimados de puntos para ciclo Sprint no han sido calculados correctamente.

Es por ello que la regla de los 5 PORQUÉ y el sentido común (¡que es siempre el menos común de todos los sentidos!) es siempre una buena forma de descubrir la raíz del problema.  La técnica es utilizada para explorar la relación causa y efecto oculta a simple vista sobre un problema en particular. El número 5 deriva de una observación empírica sobre el número de iteraciones tipicamente necesarias para llevar al fondo de un asunto. La técnica es tan sencilla como efectiva, debes preguntar varias veces sobre un tema; por ejemplo:

1. Scrum Master: ¿Porqué estás ocupado Juan?
Juan: Porque tengo que terminar varias tareas.
2. ¿Porqué tienes que finalizar con varias tareas?
Juan: Porque estoy trabajando en 2 historias de diferentes proyectos
3. ¿Porqué trabajas en historias de más de un proyecto?
Juan: Mi ex-jefe me asignó una tarea adicional hace unos días que me está  consumiendo parte de mi tiempo.

En general basta con menos de 5 preguntas para llegar al problema real. Una vez detectado el mismo, se hace mas sencillo el poder lidiar con éste y buscar una solución

Problema 2: Las tareas se asumen a título personal
Hay que admitirlo.. cada tarea de programación que un desarrollador lleva adelante es como su obra maestra y obviamente se siente orgullosa de ella. Esto hace que si algo salió mal, algunas personas lo tomen a titulo personal, o lo que es peor, señalen o inculpen a aquellos «culpables».
En un equipo Agile todos son responsables de los resultados exitosos así como de aquellos no tanto. No existen culpas sino problemas a resolver.
Si esto pasa, quien sea Scrum Master deberá moderar la conversación, recordar que se trata de un equipo y dejar pautas claras sobre el respeto hacia los individios y su trabajo.
De ser un problema reincidente, mi recomendación es pegar en la pared antes de la retrospectica algunas pautas básicas sobre el funcionamiento de la misma.

Problema 3: Monopolización de la retrospectiva
Una de las personas monopoliza la retrospectiva y no deja interactuar a los demas miembros del equipo. Esto es común cuando se tienen individuos que anteriormente se situaban jerárquicamente sobre otras personas (jefes de proyecto, etc) o personas mas extrovertidas. La tarea aquí del Scrum Master es balancear la reunión; una de las técnicas que funcionan bien es el llamado indicador de interacción. Básicamente dibujas cuadrados en una hoja grande con los nombres de las personas en la sala. Cada vez que una sugiere una idea agregas un punto. Ésto dará una idea visual de quienes interactúan y quienes no y su posterior ajuste.

Problema 4: El dueño del producto utiliza la retrospectiva para dar indicaciones claras de que desea en próximos ciclos
Recuerda, no hay relación entre roles y clasificación de problemas, todos estos deberán ser votados y priorizados por el equipo en forma democrática, sin importar su role. Si el dueño del producto no comprende claramente las reglas, está en el Scrum Master en recordárselas y asegurar que las metodologías Agile sean seguidas al pie de la letra.

Problema 5: Los problemas son obvios pero no se mencionan en la retrospectiva
Todavía acuerdo uno de mis equipos en una empresa de Londres donde un consultor y ex-jefe daba órdenes y levantaba la voz a los miembros del equipo. Los mismos me sugirieron realizar una restrospectiva; mi primer pregunta fué si había algún problema en la interacción del equipo. Para mi sorpresa obtuve un «No» seguido como respuesta que todo estaba funcionando correctamente y era una de los mejores ciclos Sprint de la historia de la compañía. En estos casos tienes dos caminos a seguir:

A. Realizar preguntas abiertas para ver si el problema sale a la luz. De esta forma puedes guiar al equipo lentamente hacia una conclusión, pero ten cuidado, no fuerces la situación. En caso que nada surja pasa al mi punto B.

B.  Finalizar la retrospectiva y dejar que el equipo falle en algún punto del ciclo actual o futuro. Esto que puede parecer una recomendación poco coeherente, tiene su fundamento en apoyar a los miembros a que maduren en términos agile.

Aquí puedes ver claramente que existía un problema extremo de falta de confianza y miedo de perder su puesto de trabajo, lo que los inhabilitaba a actuar.

Problema 6: Charlas sinfin y no soluciones
Ésto es muy común en equipos Agile nuevos donde no se comprende el sentido real y funcionamiento de la retrospectiva. De ser éste el caso, te recomiendo las siguientes 3 medidas:

1. Retira las sillas de la habitación; las personas paradas tienden a ser más breves y concisas.
2. Prepara la sala antes de la hora de comienzo, pega en las paredes 3 carteles con  los textos: «Lo que hicimos bien», «Lo que fué problemático», «Lo que se puede mejorar».
3. Tan pronto como el equipo entra en la habitación pídeles que escriban en trozos de papel las respuestas a las preguntas anteriores (que pueden ser múltiples) y las peguen en cada columna
4. Finalmente prioriza con ellos los problemas y haz que los mismos sean discutidos.

Finalmente, no te olvides que lo que se habla en una retrospectiva allí se queda. Te comento en breve algunas técnicas para obtener lo mejor de cada retrospectiva.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recusos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa