Blog&Artículos

Pocos se percatan en las compañías sobre 2 actitudes similares de hacer frente al trabajo que obtienen resultados antagónicos.

Hace algún tiempo atrás me tocó ayudar a un conjunto de equipos de una empresa (llamémosla LECO) que necesitaban contar con una herramienta para guardar el conocimiento resultado de sus sesiones de comunidades de excelencia técnica. La idea era capturar durante las reuniones toda la información  generada para así poder compartirla posteriormente con otros grupos o nuevos miembros de la organización.

Los equipos Scrum se ofrecieron para instalar la herramienta, lo que podía incluirse como una tarea compartida entre ellos. La idea era simple… se adicionaba a una pila (backlog) compartida para luego ser llevada adelante en 1 o 2 días.

Como LECO contaba con sus propios procedimientos y departamento encargado de infraestructura, decidió solicitárselo a éste último para que el proceso fuese más eficiente. Ello no distraería a los equipos Scrum de sus tareas habituales y conservaría el foco al 100% de los mismos en la entrega de valor al cliente. A su vez, no ofendería a ninguna persona  ya que nadie se sentiría que otra persona estaba haciendo su trabajo.

Pese a la buena voluntad del departamento de infraestructura de LECO, no tuvieron otra opción que adicionar la tarea a su pila interna, a la espera de contar con el tiempo y la persona adecuada para hacer realidad la instalación de la herramienta. Esto se tradujo en un retraso de semanas (sino meses), lo que hizo que se perdiese de forma irrecuperable la posibilidad de capturar el conocimiento adquirido durante las sesiones de comunidades de excelencia técnica.

Otra experiencia fue la de una organización (llamémosla ATOP) donde el Product Owner realizaba constante presión en el equipo para así aumentar la cantidad de características factibles de terminar al final de cada Sprint. La idea era sencilla… aumentar la eficiencia del equipo traería como resultado un mayor valor para el cliente.

Ambos casos son un ejemplo claro donde se busca hacer más eficientes las tareas o procesos a los que se está directamente expuesto.

¿Qué hay de malo en ello?

En el caso de LECO, se optó por una solución que parecía la más adecuada. La trampa consistió en que el traspaso de información y delegación aumentó la eficiencia pero disminuyó su eficacia, debido a que el nuevo dueño de la tarea estaba más ocupado que quien se había ofrecido inicialmente, lo que hizo que se incrementase su complicación (pasos necesaros para llevar adelante la tarea).

El caso de ATOP es similar, se trató de aumentar el valor entregado al cliente, pero al observar el plazo de espera (Leadtime), esto es, desde la concepción de la idea hasta la entrega final al cliente, ello no hacía mayor diferencia.

Estos son ejemplos claros de Eficiencia vs. Eficacia.

En la primera (eficiencia) se favorece a una optimización local para obtener un resultado tangible de forma veloz o se opta por seguir y mejorar los caminos habituales sin desafiar al status-quo de la organización. Ellos son comunmente vistos en empresas altamente jerárquicas o con alto número de silos o burocracia o entornos altamente politizados y sin mejora continua.
En la segunda (eficacia), se centra en aquellas piezas del puzle necesarias para que a nivel global se pueda cumplir el objetivo lo antes posible sin un incremento en deuda de conocimiento, técnica o humana (emocional). Aquí pones tu energía en completar el rompecabezas, mientras que en la primera opción (eficiencia) en poner tu pieza de la forma más rápida posible.

Marcar la diferencia cada día entre eficacia y eficiencia es un buen sitio donde comenzar a trabajar en las futuras organizaciones ágiles.

Gracias por escucharme,

Erich.

Software es una actividad social, o por lo menos, debemos concebirla de esta manera.

Estarás de acuerdo que las empresas modernas y competitivas requieren un alto nivel de interacción entre los individuos si desean conseguir un objetivo común.

¿Qué tal si pudieses hacer un único cambio en tu organización que trajese altos beneficios y apoyase la supervivencia de tu estrategia? ¿Lo considerarías?

Fija la respuesta en tu mente y sigue leyendo.

¿Qué tal si la solución fuese fácil de implementar y no se necesitase un marco de trabajo ni entrenamiento adicional?

Nuevamente, fija la respuesta y sigue leyendo.

Existe una pandemia, cada organización que visitamos, con cada persona con la que hablamos, nos encontramos exactamente el mismo inconveniente… parecería existir una relación directa entre el número de reuniones y su cargo. Cuando era niño no recuerdo haber tenido más de una reunión cada 3 o 4 meses para evaluar mi desempeño escolar, aunque en algunos casos, podía ser más frecuente si mi conducta no era la esperada.

¿Cuánta de las reuniones de tu empresa crees que son productivas? ¿Qué tal si las prohibieses todas? (a excepción de aquellas del Marco de trabajo de Scrum para el caso que lo utilices)

Bain & Company encontró que un jefe promedio pierde 1/2 día a la semana en reuniones no productivas, mientras que un ejecutivo senior un 40%. Ello sin contar los tiempos de preparación o los emails a enviar después de la misma más el efecto en cadena producido por terminar la reunión más tarde.

Podrías pensar en no ser radical y focalizarte la primera semana en asegurarte que ninguna reunión pueda exceder los 30 minutos (no obstante, ten en cuenta cuál es el título de artículo). Buena elección… al bajar los tiempos mejorarás el flujo de información y cadencia en tu empresa (teoría de colas).

«Hola, desde hoy haremos un experimento donde no podremos llevar adelante reuniones de más de 30 minutos» 

Bain & Company indicó que un fabricante para el cual realizaron un estudio salvó el equivalente a 200 puestos de trabajo sólo por limitar a siete el número de personas a asistir a cada reunión y recortar la duración de las mismas de 60′ a 30 minutos.

Algunas ideas adicionales que podrías emplear:

1. Llevar adelante todas las reuniones de pie
2. Hacerlas siempre opcionales
3. Utilizar una agenda estricta para la reunión y adherirse a la misma
4. Utilizar un cronómetro visible y ponerse de pie cuando el tiempo haya terminado, avisando a las personas 5 minutos antes de su fin.
5. Asegurarse que no se resuelva ningún problema durante reuniones con números elevados de personas; simplemente se identifique quien lo hará luego de la misma.

Si no te convencí todavía… ¿Cuántas horas crees que inviertes de forma no productiva al mes?

Atlassian encontró que, en promedio, 31 horas se gastaban en reuniones improductivas al mes por persona. Los investigadores Alexandra Luong y Steven Rogelberg fueron un poco más lejos:

• 91% de los asistentes a reuniones admitieron estar constantemente pensando en otras cosas durante las mismas; ¿Eres tú uno de ellos?
• Sólo las reuniones no productivas le costó a las empresas de Estados Unidos 37 millones de dólares en un año.
• Nuevamente ellos comprobaron que al menos se perdían 31 horas en reuniones no productivas

Los datos indican también que las compañías tienen demasiadas reuniones y que en su mayoría son ineficientes.

Hay también un efecto secundario que hemos podido apreciar personalmente en Innova1st… se le pide a los empleados que trabajen más para compensar el tiempo «perdido» durante las reuniones. Y si utilizas el marco de trabajo de Scrum, ello parece exacerbarse. ¿Te ha pasado a ti?

¿Sabías que a un desarrollador de software le lleva  23 minutos de media volver al punto de flujo donde se encontraba antes de interrumpir su trabajo? Basta que la persona tenga 3 reuniones al día para que las 31 horas se transformen en 51, o lo que es igual… ¡Casi media semana de trabajo perdida al mes!

Pero no estás solo si decides cortar por lo sano… Intel no ha cancelado las reuniones, pero ha prohibido aquellas sin un propósito claro. Lenovo tomó una decisión radical… la empresa empoderó a cualquier empleado para que pueda cancelar una reunión si ve que no conduce a ninguna parte. Project eMT, Semco y Fishbowl han abolido todas las reuniones como política de la organización. Un equipo de Weekdone decidió no tomar más reuniones y enviar el siguiente póster a todo aquel que les solicitase una:

Facebook, highfive y Asana (establecida por un co-fundador de facebook) no permiten hacer reuniones los días miércoles. Movieline, una compañía online de mudanzas, no deja que se molesten a los equipos los días Martes. Esto no sólo hace que sea más fácil para los empleados concentrarse en su día de no-reuniones, sino que sea más sencillo agendar citas para el resto de la semana.
Para el caso que utilices un calendario digital, aquí tienes una opción viable…  bastará con bloquear todo el día para que se cancelen todas las reuniones.

Otra alternativa es emplear la regla de los 2 pies (lo utilizamos en las conferencias auto-organizadas ej. OpenSpace):

1. Estas aprendiendo o
2. Estas contribuyendo
3. Si no estás haciendo ninguna de las 2 cosas, entonces como persona responsable levántate y vete

No obstante, pocos empleados se atreven a retirarse de una reunión donde hay un superior, por lo que no recomiendo ésta última en una organización donde las personas no se sientan seguras.

Toma ahora tu decisión, ve al calendario y elimina todas las reuniones donde no aportas ¿Te sientes bien? Ahora prosigue por aquellas que desconoces exactamente que se busca. ¿Mejor no? Continúa ahora con las restantes que lo bueno viene después…

Verás como las personas se las arreglarán para estar en constante alerta con el fin de tener micro-interacciones contigo durante el día, ahora que no pueden agendarte reuniones, lo que favorecerá un flujo firme de información y decisiones, cosa que apoyará que tu empresa siga creciendo y adaptándose en los tiempos que corren.

Si necesitas conocer más sobre como potenciar equipos Scrum y Agilidad dentro de tu empresa, visita nuestro sitio Web.

Gracias por escucharme,
Erich.

PD: Hoy cumplimos 10 años sin utilizar un calendario electrónico en las empresas que ayudamos.

 

 

 

Hace ya algunos años que está de moda la agilidad, Scrum, Kanban y todo aquello que incluya una única palabra de entre 5 y 8 letras. Pasamos de siglas de 2 a 3 caracteres para irnos a acrónimos y posteriormente a palabras, y quizás en la próxima década nos sorprendamos con una combinación de números y caracteres chinos, tomando en cuenta el auge de la población de ese país y la presión que tendrá a nivel global sobre el resto de los idiomas.

Como resultado de esto, muchas organizaciones entienden a la agilidad como algo que se «hace» en vez de algo que se «es» (hacer vs. ser Ágil). Es también común que se suelan extender varias de las ceremonias de los equipos Scrum al resto de la organización como parte de la cultura de la empresa.

Las retrospectivas son una de las primeras en integrarse dentro de las actividades regulares, con la idea de apoyar así la mejora continua y en algunos casos, estandarizar la forma de trabajo a nivel institucional.

En ocasiones, las personas preparan, reservan su tiempo, llevan adelante y obtienen un par de puntos de mejora de procesos como resultado de la reunión.

¿Es ello una retrospectiva? Sigue leyendo…

Hasta aquí todo parece funcionar a las mil maravillas, pero hay un dicho que dice que «No porque estés dentro de un garage te transformarás en un coche».

En mi experiencia, la mejora de procesos es solamente una de las 7 partes esperables para que una retrospectiva sea válida. Se puede clasificar como otro tipo de reuniones, con un fin claro pero  diferente.

Lo he visto en muchas empresas y a mi criterio esto se debe a que se desconocen las otras áreas a tratar requeridas por la ceremonia. Tengo otra teoría que se basa en que es más fácil y ofrece menor riesgo para las personas el mejorar procesos que  hablar de una parte humana que se focalice en descubrir nuevas vías de interactuar con el resto, expresar sentimientos, etc.

Hay un punto adicional que puede ser la causa… el culto de cargo.

El culto de cargo se centra en la historia de aborígenes de Australia y Melanesia que reproducían aviones que veían en el cielo y pistas de aterrizaje que observaban de los porta-aviones, pero a diferencia, la construcción se llevaba adelante con madera u otros materiales naturales. La idea era que copiando se podrían atraer los mismos beneficios de volar o captar la atención de los dioses para que los aeroplanos reales pudiesen aparecer pronto.

¿Qué es lo que pasa en una retrospectiva vs. una mejora de procesos?

 

Retrospectiva	Mejora de procesos
Reflexionar sobre lo que se hizo a nivel de procesos y analizar su causa raíz	Reflexionar sobre lo que se hizo a nivel de procesos y analizar su causa raíz
Reflexionar lo que se hizo a nivel humano y como mejorarlo
Descubrir nuevas formas de interacción con las otras personas o equipos y contar con una estrategia	Establecer el protocolo sobre como se interactuará con otras personas  equipos externos
Descubrir como realizar el trabajo en un ecosistema eficiente que elimine las optimizaciones locales y los silos	Descubrir como realizar el trabajo en un ecosistema eficiente que elimine las optimizaciones locales
Aprender como focalizarse en formas que apoyen la mejora continua
Mejorar aquellas cosas adicionales que no se clasifiquen como de factor humano o de proceso
Planear pequeñas estrategias que acentúen el éxito y disminuyan la respuesta ante el fracaso

Ahora que ya sabes la diferencia podrás planear tu próxima sesión de  retrospectiva teniendo ésto en mente o llevar adelante una reunión de mejora de procesos. Tú decides que es lo mejor en cada caso.

Gracias por escucharme,
Erich.

¡Necesitamos tener una visión clara en la organización que nos permita dirigir la compañía hacia un lugar donde nuestra competencia todavía no ha llegado!
Pero… no todavía… las personas están super ocupadas terminando varias tareas a la vez, y si les agregamos más carga de trabajo las bloquearía.

¡Necesitamos terminar con la multitarea y focalizar a cada persona en la tarea más prioritaria que es aquella que brinda más valor de negocio para el cliente!
Pero… no todavía… necesitamos primero maximizar las ganancias de los accionistas!

Esto es parte de cómo siempre ha funcionado la organización y su cultura de maximizar la ganancia.

¡Necesitamos cambiar la cultura de la organización!
Pero… no todavía…  es más fácil cambiar los procesos y algunos roles. Observemos lo que hace nuestra competencia, analicemos los nuevos roles y procesos requeridos y luego de ello, veamos si es el momento.

¡Necesitamos cambiar las estructuras y procesos de la organización!
Pero… no todavía… han estado funcionando así por las últimas décadas, alguien trató de hacerlo y no le funcionó. Además, estas estructuras son las que nos han asegurado las ganancias cada año.

Mejor hablemos con el área de innovación que ellos tenían una idea sobre algo llamado Agile para trabajar con los gerentes y lentamente cambiar la empresa.

¡Necesitamos trabajar con la gerencia!
Pero… no todavía…  ello llevará tiempo y dinero y será difícil reunirlos a todos ya que están siempre viajando para conocer las mejores formas de orientar nuestros productos a servir al cliente.

¡Necesitamos conocer como orientar mejor nuestros productos mejor para servir al cliente!
Pero… no todavía…  eso es algo que requeriría alterar como se establece el diálogo directo entre los empleados y con los socios estratégicos, y me anticiparon que no motiva a las personas debido a que no es parte de sus evaluaciones de rendimiento.

¡Necesitamos cambiar la forma de evaluar a nuestras personas!
Pero… no todavía…  nadie se ha quejado y todo el mundo está contento de obtener las compensaciones extras al final del año. Quizá podríamos hacerlo diferente con las nuevas contrataciones…

¡Necesitamos contratar nuevas personas que tengan pasión por la empresa!
Pero… no todavía…  ese proceso nos obligaría a cambiar los equipos, pero ya hemos cerramos contrato con nuestros futuros socios estratégicos que nos proveen personas para los equipos.

¡Necesitamos cambiar los contratos con nuestros socios estratégicos para que nos permita contar con equipos que puedan adaptarse a la flexibilidad requerida por los mercados!
Pero… no todavía… porque ellos tienen una visión clara para nuestra organización.

Éste círculo puede seguir una y otra vez, de distintas formas y colores. Al final del día, sólo se necesita cambiar la variable para resolver la ecuación… saber que cuál es el sentido de urgencia y asociarlo al cambio.

En mi opinión, la aceleración exponencial de la innovación debido a los ciclos cortos de trabajo de la competencia, las formas de trabajo ágiles, la inteligencia artificial y bigdata, hacen que si no cambias, y no eres un monopolio, tus productos se estén predestinados a estar fuera del mercado en poco tiempo.

La exponencialidad del cambio es una realidad, y está aquí para quedarse.

Si quieres saber más, te invito a conocer técnicas sobre cómo enfrentar estas situaciones en mi libro Lidera el Cambio Exponencial, disponible en Español, Portugues, Inglés, y en breve en audio libro (inglés).

Gracias por escucharme,
Erich.

En un mundo ideal, los equipos Scrum siempre son de 5 a 7 personas, tienen energía alta, individuos con deseos de alcanzar el modelo  de aprendizaje “T”, buen humor, retrospectivas brillantes, productos excelentes y silos imperceptibles dentro del grupo.

Eso en teoría ya que en la práctica las cosas pueden ser muy diferentes. Ello es claramente debido a que la variabilidad interna de los equipos Scrum es muy alta (entropía) y a su vez la dinámica de construir software de punta a punta en sí requiere reglas de juego diferentes.

Es por ello que la “estabilidad” en estos equipos es mucho más frágil que en formas de trabajo Kanban (por ejemplo). No obstante, no hay nada más divertido y desafiante que trabajar con éste marco de trabajo, y como dijo Daniel Pink… Maestría, Autonomía y Propósito es la base de la motivación de cada día.

¿Cuáles son los riesgos? Hay varios como ser la anarquía en vez de auto-organización, la fatiga del Sprint (de la que te hablaré en otro momento), la autosuficiencia en vez de autonomía y el factor camión ¿Lo conoces?

Originalmente el factor camión era un número que iba de CERO al número máximo de personas que componían el equipo. Éste indicaba a cuantos integrantes del mismo debía pasarle un camión por encima para no poder cumplir con la fecha de entrega o el compromiso realizado para el Sprint en curso.

Un poco trágico, por lo que cambiaré por el factor lotería, esto es, cuantos miembros deberían sacarse la lotería y renunciar a la empresa para no llegar a lo prometido.

En general, en los equipos con alto número de silos el factor lotería es muy bajo (1 o 2). Es común ver ello en productos donde se requieren roles específicos como UX, VD, etc. Aquí comunmente el resto de los miembros no conoce o se interesa por la importancia de la experiencia de usuario y la persona en cuestión no se siente empoderada para influir que ello pase.

Otro ejemplo pueden ser expertos técnicos (ej. base de datos) con muchos años de experiencia que ven poco provechoso el dejar de realizar su área  para llevar otras de poca relevancia de acuerdo a su óptica.

También el hecho de que exista un PC con configuración específica y única dentro del equipo aumentaría el factor camión.

Aquí pensar en contar con un reemplazo de la persona para el caso que no esté presente ofrecerá una solución parcial de comienzo pero insuficiente en el corto plazo si el objetivo final no es cubrir los demás aspectos.

El factor lotería no solamente afecta cuando la persona está ausente sino que incluso cuando ella está presente. ¿Cómo es eso posible?

Si existe uno o más silos dentro del equipo habrá un factor importante de riesgo, lo que se traducirá en un valor bajo de camión, lotería, Ferrari, o cualquier otro elemento de disuación.

En estos casos, el equipo debería actuar de forma inmediata para hacer visible los problemas y trabajar activamente en una forma medible de  eliminación los mismos. El objetivo debe ser siempre propiciar la alta densidad social dentro del grupo, la polinización cruzada y que todos los miembros puedan comprender la experiencia de usuario, estimar cualquier tarea, mejorar las habilidades técnicas y de negocio.

El hacer frente pronto no solamente reducirá los riegos sino que incrementará el flujo dentro del equipo, minimizando así los bloqueos en el mediano plazo y aumentando la innovación del producto final.

Recuerda que toda reducción interna de bloqueos aumentará el flujo y valor entregado al cliente, o lo que es igual, abaratará el costo de las características realizadas para el cliente.

En un equipo de 8 personas, un factor lotería de 1 o 2 aumentaría la complejidad y procesos dentro del mismo, mientras que uno de CERO, o lo que es igual, del número total de integrantes, ayudaría a construir un equipo imparable. ¿Qué afecta el factor camión?

1. Tamaño y cantidad de trabajo en las colas de entrada del equipo
2. Forma en que el equipo se encuentran organizado
3. Distancia humana entre sus integrantes y como se generan los bloqueos
4. Secuencia en la cual los trabajos son efectuados
5. Nivelación de trabajo dentro del sistema (forma en que trabaja el grupo)
6. Nivel de automatización logrado dentro del mismo (normalmente la automatización se hace en «islas» desconectadas)
7. Cantidad de ciclos de retro-alimentación entre sus miembros

¿Recuerdas que en la agilidad deseamos simplificar todo lo que se hace?

La simplicidad es el arte de maximizar la cantidad de trabajo no realizado, y ello es esencial.

¿Cómo podrías incrementar el factor lotería para así disminur los riesgos?

1. Observa los procesos que se llevan adelante y mejóralos constantemente, especialmente céntrate en reducir los cuellos de botella y trabaja en mejorar el flujo interno del equipo
2. Trata de incrementar la polinización cruzada entre todos los miembros sin importar su especialización
3. Esfuérzate por que las personas conecten técnicamente y humanamente dentro del equipo
4. Asegúrate que todos intervengan y comprendan el negocio y la experiencia de usuario durante los refinamientos para así mejorar la evolución del producto
5. Trabaja en conjunto para la disminución de la deuda técnica y sobre todo, que se evalúen decisiones de punta a punta entre la totalidad de los integrantes en vez de ser en “islas” de conocimiento y que luego se  “conecten”
6. Organiza “workshops” frecuentes sobre las habilidades que están concentradas en pocas personas  y utiliza Pairing para que se mejore el nivel técnico del equipo.
7. Asegúrate que no se adicionen procesos extras sino que se focalice en trabajar activamente en bajar la complejidad del funcionamiento del equipo
8. Encuentra una forma de *MEDIR* los avances de forma clara para saber si estás mejorando, refina y vuelve al punto 1.

Recuerda finalmente que pensar en cambiar el backlog de un producto basado en si está o no una persona del equipo es un error que puede costarle a la empresa varias veces el sueldo de ese integrante y disminuir la credibilidad de las partes interesadas (stakeholders).

 

¿Cuál es el factor camión de tu equipo?

Gracias por escucharme,
Erich.

Un muchacho joven viajaba a través de Japón hacia la escuela de un famoso artista marcial. Al llegar al dojo, se le dio una audiencia con el sensei. «¿Qué quieres de mí?», Preguntó el maestro. «Quiero ser tu estudiante y convertirme en el mejor karateka de la tierra,» respondió el muchacho. «¿Cuánto tiempo debo estudiar para ello?» «Diez años por lo menos», respondió el maestro. «Diez años es mucho tiempo», dijo el chico. «¿Y si estudio el doble de duro que los otros estudiantes?» «Veinte años», respondió el maestro. «¡Veinte años! ¿Y qué pasa si practico día y noche con todo mi esfuerzo? » «Treinta años», le respondió el maestro. «¿Cómo es que cada vez que digo que voy a trabajar más duro, me dices que necesitaré más tiempo? «, Preguntó el chico «La respuesta es clara… Cuando un ojo se fija en tu destino, queda sólo otro para encontrar el camino»

Anónimo De: Zen en las artes marciales por Joe Hyams, 1979, p. 95

Aunque lo parezca, no existe tal cosa como los esfuerzos extraordinarios. Debo decirte un pequeño secreto… ellos en general no brindan resultados extraordinarios.

Es común ver a organizaciones premiar los esfuerzos extraordinarios en contraposición a los resultados realistas. Los esfuerzos heroicos no son escalables, no apoyan un modelo deseable para llevar adelante el día a día de una organización, y pese a aumentar la adrenalina de los grupos y dejar aparentemente claro que todo se puede dentro de la empresa, convierte a las personas de la organización en maquinarias defectuosas.

Gracias por escucharme,
Erich.

Ok, digamos que el Product Owner siempre está dedicado al equipo el 100% de su tiempo, trabaja codo a codo con quienes implementan el como de la solución, refina la pila (backlog) al menos 2 veces a la semana, mantiene las fechas de entrega alejadas del equipo y enseña a la compañía sobre la importancia de la priorización y valor de negocio.

La totalidad de los miembros se han esmerado en resolver las historias de usuario, remover los obstáculos y pasar la Definición de Terminado (Definition of Done). El día ha llegado, todo el mundo está ansioso ya que en menos de media hora esas características que harán volar la imaginación de las partes interesadas (Stakeholders) estarán en el “aire” de la sala.

La habitación está lista, se cuenta en cada silla con un programa a seguir en papel con una decoración muy bonita, así como una breve descripción de cada sección a llevar adelante. A su vez, el Scrum Master ha confeccionado un par de dinámicas para romper el hielo, ya que hoy habrá varias visitas importantes, de las cuales se espera retro-alimentación positiva, tanto hacia el producto como también sobre difundir las bondades hacia el resto de la empresa de la nueva solución.

Incluso los miembros del equipo han comprado  dulces y tartas para recibir a los invitados, así como se han conseguido  varios computadores portátiles y tablets para probar la versión móvil.

El día anterior, Product Owner y equipo probaron las distintas características para asegurarse no solo la pre-aprobación sino que también que todo esté en orden.

Las expectativas son altas y puede sentirse en el ambiente la energía y optimismo resultado del trabajo duro de 2 semanas más la acumulación de pequeñas tareas en los anteriores. El equipo realmente quiere ver como cambiará la vida de esas personas a perpetuidad el trabajo que han hecho.

De repente, el teléfono suena 10 minutos antes de la Sprint Review y las noticias no son alentadores…. su Product Owner ha tenido un percance personal(*) y se siente indispuesto. No estoy hablando aquí de uno  mediocre que pone otra prioridad de la empresa el día de la ceremonia más importante, esto es algo inesperado y de último minuto.

¿Qué hacemos entonces? ¿Cancelamos la Sprint Review para el día siguiente? ¿Fin del próximo Sprint? ¿La hacemos otro día con menos personas? ¡El equipo entra en pánico!

La respuesta es NO a todas ellas. La cadencia es fundamental en la agilidad; aquí los equipos son auto-organizados, responsables y deben apropiarse del problema de la misma forma que hacen con las historias de usuario.

“Como equipo Scrum deseo poder mostrar lo que he hecho y obtener retro-alimentación para así deleitar al cliente”

Hasta aquí no hay problema ya que es posible que se lleve adelante, no obstante, el criterio de aceptación de la ceremonia Sprint Review es que las historias de Usuario sean aceptadas/rechazadas durante la misma.

¡Ups! debemos entonces ver la historia completa

“Como equipo de Scrum Deseo poder mostrar lo que he hecho y obtener retro-alimentación para así deleitar al cliente”
Criterios de aceptación:

• Que se muestren las soluciones a los problemas
• Que se aprueben o rechacen las historias si se cumple la Definición de Terminado y los criterios de aceptación de cada una de ellas

Para esta segunda parte, es necesario que alguien tome temporalmente el rol de Product Owner. ¡Pero cuidado, no es un Product Owner Proxy! Es simplemente una persona dentro de la empresa que tiene el conocimiento y el poder suficiente para aprobar las historias y no ser enviado al infierno por hacerlo.

En las organizaciones más jerárquicas, podría ser el Jefe del Product Owner, pero otro Product Owner también es un buen candidato.

Conseguido el mismo, la sesión se lleva adelante de la misma forma

¡pero cuidado!

Quizá se necesite tomar un poco más de notas o incluso filmar la sesión ya que seguramente se pierda parte de la retro-alimentación en el traspaso de la misma para cuando esté de vuelta el alma perdida.

Pero Erich…. ¿Qué hacemos si no hay nadie que lo suplante?

Si no hay nadie que pueda ser un reemplazo de forma temporal, sería posible para el equipo presentar las historias pero no llevar adelante su aprobación, por lo que éstas quedará temporalmente congeladas (sin ir a producción).

Es importante en todo momento mantener la motivación y capturar toda la retro-alimentación posible. Al no estar el Product Owner, es posible que no se hagan tantas preguntas, por lo que deberán poner especial atención en enfatizar y maximizar las mismas.

Finalmente, si al día siguiente para la ceremonia de Sprint Planning el Product Owner sigue ausente, el equipo puede comenzar su Sprint tomando del Backlog de Producto las historias más prioritarias basadas en su velocidad (velocity), esto es, en el orden de prioridad existente ya que el equipo no tiene la potestad para cambiar la misma.

Gracias por escucharme,

Erich.

(*) Ningún Product Owner ha sido maltratado para escribir éste artículo.