¿Cómo justificar dos días de asistencia de todos los integrantes de un tren a una PI Planning?

La Program Increment (PI) Planning es un evento de dos días con una cadencia en entorno trimestral en la que se juntan todos los integrantes de un tren (ART), así como también sus interesados. Todas esas personas dejan de dedicarse a sus tareas habituales para dedicarse durante esos dos días a elaborar un plan de partida para los siguientes tres meses. Y ese coste es relativamente fácil de calcular...

Más/menos 100 personas trabajando juntas en una Program Increment Planning - thanks to Konjurer

Si pensamos en una PI Planning presencial tenemos toda clase de costes adicionales; los desplazamientos y hoteles que con suerte solo afectan a parte de los asistentes, una sala suficientemente grande y funcional que quizá sea una sala en un hotel, los desayunos, comidas y demás necesidades a cubrir en un grupo de tantas personas.

En una PI Planning remota tenemos costes de infraestructura, como son las licencias de herramientas de videoconferencia, tableros virtuales, backchannels en forma de chats... y otros costes como los de facilitadores y técnicos en las diferentes localizaciones para garantizar y maximizar la comunicación y colaboración durante el evento.

Si sumamos todos estos costes una PI Planning parece imposible de financiar... En repetidas ocasiones me han hecho la pregunta: ¿Cómo haces para convencer a una empresa para que gaste tanto presupuesto en este evento?

La variable que suele no tenerse en cuenta es el coste de retraso, el coste en que incurrimos si no hacemos la PI Planning. Hemos de confrontar ambos costes para darnos cuenta que es mucho más costoso no realizar PI Plannings que si hacerlas.

Los costes de una PI Planning tienen facturas y nóminas asociadas, es relativamente fácil hacer los números. Calcular el coste del retraso requiere más exploración, hablar con diferentes expertos y pedirles su estimación del coste del retraso en diferentes aspectos:

¿Qué pagarías por un tablero con las dependencias
resueltas de un grupo de más/menos 100 personas
para los próximos tres meses?

• ¿Qué valor tiene para nosotros un plan trimestral factible, el resultante de la PI Planning, que tenga todos los números para cumplir con los objetivos comprometidos en el evento? Recordemos que se trata de un plan que afecta a más/menos 100 personas... en otras palabras, 100 personas han pensado durante dos días como construir el mejor producto posible a la primera. Y además resultando un plan equilibrado con la capacidad productiva de esas personas.
• ¿Qué valor tiene para nosotros un alineamiento de lo que se construye con los objetivos de negocio? En la PI Planning todos ven y entienden el cuadro general de en lo que participan, por tanto tomaran decisiones acertadas y alienadas con negocio. Por otro lado las propias decisiones a todos los niveles se toman rápidamente, ya que todos estamos presentes y en estrecha comunicación.
• ¿Qué valor tiene para nosotros la identificación y resolución de dependencias entre equipos y con otros servicios compartidos? ¿Qué valor tiene el tablero de dependencias? En él tenemos las dependencias resueltas del trabajo de un grupo de más/menos 100 personas que permite evitar bloqueos y posiblemente meses de retrasos.
• ¿Qué valor tiene para nosotros la colaboración de más/menos 100 personas? El hecho de que un equipo, así como un equipo de equipos o ART, es mucho más que la suma de los individuos es ciencia, es dinámica de grupos demostrada una y otra vez a lo largo de décadas.

Hay empresas que hacen estos números y consideran la PI Planning como una ventaja competitiva frente a quienes no las hacen...

¿Qué significa equipos remotos, distribuidos, dispersos y virtuales?

Equipos remotos ¿virtuales, distribuidos o dispersos? - cortesía de Pixabay

Con COVID-19, y el consecuente asentamiento del teletrabajo como nueva normalidad, éstos términos referidos a equipos han tomado relevancia. Los hemos incorporado en nuestro lenguaje del día a día pero a veces los empleamos de forma inadecuada o confusa. Con este post quiero tratar de exponer el significado y diferencias entre éstos.

Las nuevas configuraciones de equipos tienen en común que están compuestas por miembros de equipo que comparten una misión y que desempeñan su trabajo desde una combinación de entornos fijos, móviles y/o remotos. Distinguimos entre dos tipos de equipos, los equipos remotos y los equipos virtuales.

• Un equipo remoto trabaja directamente con una única pila de producto gestionada por su Propietario del Producto, y sus miembros no están colocalizados geográficamente.
• Un equipo virtual es un equipo temporal donde miembros de diferentes áreas de especialización realizan tareas específicas o resuelven problemas específicos. Un equipo virtual suele estar formado por personas que habitualmente trabajan en otros equipos. Un equipo virtual puede estar colocalizado, pero el término generalmente se refiere a equipos geográficamente deslozalicados. Estos equipos virtuales que se han formado con un propósito específico "se dispersan" una vez que su tarea se ha completado.

En función de la localización de los equipos y sus miembros distinguimos entre:

• Equipos distribuidos son aquellos donde los miembros de los equipos están colocalizados y los equipos están deslocalizados en diferentes localizaciones geográficas con respecto los equipos con los que colaboran (ART, tribu,...), como por ejemplo una tribu con el equipo de desarrollo en España y el equipo de arquitectura en la India.
• Equipos dispersos son aquellos donde todos o algunos de los miembros de los equipos están dispersos en diferentes localizaciones, como por ejemplo fue la situación de confinamiento COVID-19 donde todos los miembros de cada equipo teletrabajaron desde su casa.

Equipos distribuidos y dispersos presentan retos diferentes:

• Para los equipos distribuidos podemos utilizar técnicas de coaching para desarrollar a los equipos individuales a través de las etapas de formación de equipos y la identidad de tribu. Serán capaces de desarrollar sus propios mecanismos de sincronización si les proveemos de las herramientas de comunicación y trabajo distribuido necesarias.
• En los equipos dispersos es más difícil crear identidad y por tanto es necesario desarrollar una cultura virtual completa, lo que implica invertir en reforzar la autonomía y la toma de decisiones descentralizada con formación y entrenamiento especializados.

¿Qué cultura hay detrás de la Casa de Lean?

A semejanza del Manifiesto Ágil en Agilidad tenemos la Casa de Lean (House of Lean) en Lean. House of Lean es un contenedor en forma de diagrama de casa para los principios y prácticas de la mentalidad Lean. Éstos se forjaron con el sistema de producción de Toyota y la manufactura Lean y han evolucionado y se han extendido de manera que actualmente se aplican al desarrollo de software, de productos y de sistemas.

La evolución de la Casa de Lean ha incluido conceptos y técnicas familiares para los coaches ágiles, ha ayudado a reducir mudas y muris, y también ha resultado en una herramienta para ayudar a focalizar en el valor y reducir los gastos, especialmente al escalar utilizando marcos como SAFe.

Hay muchas variantes de la Casa de Lean, aunque todas ellas tienen como objetivo la entrega de valor en su techo y el liderazgo alineado con Lean y Agile en su base.

Veamos la propuesta de Scrum Manager:

La Casa de Lean según Scrum Manager

Objetivo

Lograr el menor tiempo de entrega sostenible con:

• La mejor calidad y valor para las personas y la sociedad
• Costes bajos
• Alta moral, seguridad y deleite del cliente

Respeto por la gente

• Tu cliente es quien consume tu trabajo, no le creas problemas
• Tus empleados hacen todo el trabajo, prioriza su desarrollo: "desarrolla personas y después construye productos"
• No hagas que la gente trabaje en cosas sin valor, es desperdicio
• Crea un ambiente de mejora para equipos e individuos, haz que ellos indentifiquen mejoras y evolucionen sus propias prácticas
• Construye asociaciones estables a largo plazo con tus proveedores que estén basadas en la confianza
• Desarrolla equipos, dales los recursos que necesiten para que puedan desarrollar un trabajo excelente

Prácticas

• Aplica pensamiento de producto poniendo el foco en las cosas de mayor valor para reducir el coste de aprendizaje sobre el mismo
• Aplica cadencia a los eventos (planificación de releases, retrospectivas, reuniones diarias)
• Timeboxing, acabado el tiempo previsto se para cualquier evento o ciclo
• Reutilización de la información y del conocimiento
• Gestión visual:
• Kanban
• Sistema de mejora de procesos basado en un sistema de arrastre con restricciones al trabajo en proceso (WIP) y visualización del flujo
• Poka-yoke
• Sistema a prueba de errores
• Andon
• Sistema de control visual que alerta de errores
• Desarrollo concurrente para que los diferentes especialistas colaboren alrededor de cada elemento a construir

14 Principios

• Filosofía a largo plazo: un producto no tiene fin si lo sabemos evolucionar continuamente
• Ciclos cortos y rápidos: ciclos de aprendizaje rápido sobre proceso y producto
• Sistema “pull”: sistema de arrastre
• Heijunka: carga de trabajo balanceada a la capacidad del sistema para reducir variabilidad (mura) y sobrecarga (muri)
• Jidoka (stop-and-fix): detener la producción para arreglar problemas
• Mejora continua: inspección y adaptación continua
• Kanban: gestión visual
• Good tech: se utiliza solamente tecnología probada
• Forma a líderes al servicio para los que hacen el trabajo
• Forma a equipos y personas excepcionales
• Keiretsu: respeta la red de colaboradores y proveedores
• Go and see (Gemba): Los responsables visitan y conocen el lugar de trabajo
• Decisiones con consenso y la consideración minuciosa, actuación rápida
• Aprendizaje: reflexión constante (Hansei) y de la mejora continua (Kaizen)

Mejora continua

• Go and see (Gemba): ir a donde ocurre el trabajo y promover la mejora
• Kaizen: método de gestión de la calidad basado en acciones concretas
• Los 5 whys: técnica para la identificación de causas raíz
• Búsqueda de desperdicio: distinguir entre valor y desperdicio
• Búsqueda de la simplicidad y perfección: sólo productos con calidad no tienen fin, trabajar acelerando el flujo

Base

Cultura de Gerencia (Liderazgo al Servicio):

• Aplicar y enseñar Lean Thinking en la toma de decisiones
• Predicar con el ejemplo
• Adoptar una mentalidad de crecimiento
• Ejemplificar los valores y principios de Lean
• Desarrollar personas
• Liderar el cambio
• Fomentar la seguridad psicológica

Veamos la Casa de Lean que propone LeSS

The LeSS Lean Thinking House - imagen del tema Lean Thinking de LeSS

La evolución más significativa es la sustitución del pilar de prácticas por el desarrollo de producto.

Desarrollo de producto

• Desarrollo de grandes ingenieros a largo plazo
• Mentorización de lideres-ingenieros-maestros
• Cadencia
• Equipos multifuncionales
• Salas para el equipo y con gestión visual
• Ingeniero jefe/Product Manager emprendedor
• Desarrollo concurrente basado en abanicos de opciones
• Creación de más conocimiento

Y finalmente la Casa de Lean de SAFe©

The SAFe House of Lean - imagen del tema Lean-Agile Mindset cortesía de © Scaled Agile, Inc.

SAFe ha evolucionado principalmente los 4 pilares de la Casa de Lean para maximizar la coherencia con su marco de escalado.

Respeto por la gente

• Crear una cultura generativa donde los lideres ponen énfasis en el logro de metas y misiones de la organización a tiempo
• Tus empleados hacen todo el trabajo, prioriza su desarrollo: "desarrolla personas y después construye productos"
• Tu cliente es quien consume tu trabajo, no le creas problemas
• Construir asociaciones estables a largo plazo con tus proveedores que estén basadas en la confianza
• Entender que para cambiar la cultura primero hay que cambiar la organización, y que la organización se puede cambiar implementando marcos ágiles como Scrum y SAFe

Flujo

• Optimizar la entrega sostenible de valor de forma continua
• Construir con calidad donde la calidad no sea una variable
• Entender, explotar y gestionar la variablidad, la variabilidad nos da la oportunidad de descubrir la mejor solución y maximizar el valor entregado
• Cambiar de mentalidad de proyecto a producto

Innovación

• Fomentar personas innovadoras en todos los niveles
• Dotar de espacios y tiempo para la innovación, con comunidades de práctica por ejemplo
• Go and see (Gemba): Los responsables visitan y conocen el lugar de trabajo
• Fomentar la experimentación y el feedback rápido para mejores decisiones y la mejora continua
• Pivotar sin piedad ni sentimiento de culpa, si algo ya no tiene sentido tíralo, no podemos cambiar el pasado, pero si el futuro
• Fomentar oleadas de innovación desde cualquier área y cruzando áreas

Mejora implacable (continua)

• Constante sensación de tensión, entender por ejemplo que hoy nuestro cliente está, pero quizá puede que mañana no si no nos centramos en sus necesidades
• Optimizado el todo aplicando System Thinking
• Fomentando una cultura de resolución de problemas
• Reflexionar sobre los hitos clave para identificar y abordar abiertamente las deficiencias del proceso en todos los niveles
• Basar la mejoras en hechos

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿Por qué Recursos Humanos son tan importantes en Agilidad?

La fuerza impulsora detrás de las organizaciones con mentalidad ágil son los trabajadores del conocimiento, personas que saben más de su trabajo que sus jefes y lideres, por tanto necesitamos personas proactivas, apasionadas y comprometidas a las que empoderar para que puedan tomar decisiones con la información que manejan a su nivel. Todo ello en un entorno donde se da valor y se potencia la colaboración y el alineamiento. En definitiva queremos personas que quieran pensar, personas que quieran aprender continuamente, personas que quieran ser dueñas de sus planes y sentir verdadero compromiso hacia sus planes para construir las mejores soluciones a las necesidades de los clientes de la compañía.

La mentalidad ágil desafía al área de Recursos Humanos tradicional a realinear su enfoque de personas para esta nueva forma de trabajar que trae la Agilidad:

Buen pensamiento, buenos productos - lema interno en las instalaciones de Toyota

Si cuidas de tus empleados ellos cuidarán de tus clientes

Existe el Manifiesto Ágil para el Desarrollo de RRHH que nos aporta los valores y principios necesarios. En este post quiero mostrar los puntos que me parecen críticos para la forma de pensar y de actuar de Recursos Humanos ágiles:

• Selección y contratación: Queremos gente que piense, que se integre y que colabore con los demás, por tanto las claves están en el talento de las personas y su actitud en vez de en sus aptitudes. Los equipos ágiles prosperan cuando Recursos Humanos contrata candidatos con la actitud y la cultura adecuadas, ya que el éxito depende de las habilidades colectivas y colaborativas del equipo. Deben evitarse tipos "O", candidatos con tendencia al heroísmo y la especialización excesiva.
• Desarrollo y crecimiento: Cuanto mejor piensen esas personas y cuantas mejores aptitudes (herramientas) les demos, mejores decisiones tomarán, mejor trabajo harán y más competitiva harán a la compañía. Por eso Recursos Humanos deberá fomentar el crecimiento, aprendizaje continuo y la toma de decisiones descentralizada (autoorganización) de los empleados de la compañía basándose en la motivación intrínseca y proveer de vías y espacios de aprendizaje. La Agilidad no distingue entre el trabajo y el aprendizaje.
• Fomentar la colaboración: Recursos Humanos deberán ser system thinkers, entender la compañía desde el punto de vista del todo e impulsar a las personas en una misma dirección. Esto se consigue fomentando la colaboración, haciendo entender que desde el punto de vista del trabajo, por ejemplo una tribu, esta tiene prioridad sobre el equipo, y este lo tiene sobre el individuo. De esta manera, si está explicitado que las dependencias dentro de la tribu tienen prioridad sobre las prioridades de los equipos, será del interés de cada individuo colaborar con los demás equipos, y se crearán planes que tendrán en cuenta las necesidad de otros y se eliminarán demoras y bloqueos que suelen retrasar el desarrollo en meses.
• Cuidado de la salud emocional: El trabajo lo realizan personas y las personas tenemos una naturaleza que nos define: somos seres emocionales. Si estamos cansados, estresados, desilusionados, preocupados, enfadados... no realizaremos un buen trabajo. Recursos Humanos debería de cuidar el lado emocional de los empleados de la compañía, a veces simplemente escuchando y otras con habilidades adquiridas de coaching sistémico y personal. Incluso es recomendable que hubiera un psicólogo en el equipo de RRHH.



RRHH velando por los empleados - Photo by Dylan Gillis on Unsplash

• Desempeño: En lugar de calificaciones de desempeño de empleados periódicas, usualmente anuales, Recursos Humanos ágiles da forma a una cultura de respeto mutuo facilitando diálogos sinceros de feedback continuo entre líderes, empleados y compañeros que fomenten la mejora continua a todos los niveles. La métricas de desempeño deben de ocurrir a nivel de sistema, por ejemplo a nivel de tribu, en la que se ha establecido un objetivo común y las métricas a nivel sistémico van a fomentar que todos los individuos colaboren para maximizar el desempeño del todo, el de la tribu.

Conociendo un poco más como son Recursos Humanos en una organización ágil te invito a reflexionar y te pregunto: ¿qué está en tus manos para hacer que esto se haga realidad en tu compañía?

¿Cómo evitar los proyectos sandía?

Proyectos sandía - Sandía cortesía de Pixabay

Estamos a un mes de la fecha de entrega, todo va muy bien y el proyecto está en verde. De repente, como un bandido que nos asalta desde detrás de un árbol, todo parece ir mal y el proyecto se pone en rojo; desviado, con sobrecostes... un verdadero desastre. Eso es lo que se llama un proyecto sandía, verde por fuera y rojo por dentro. Los proyectos sandía suelen ocurrir por falta de transparencia, uno de los valores fundamentales que promueven Scrum y la Agilidad, uno de los valores que debería de estar en cualquier proyecto.

También existen los proyectos cangrejo, que siempre están en rojo, se complican cada vez más y hacen sufrir a todos en todo momento... pero esos son otra historia y no son objeto de este post.

Veamos qué cosas podemos hacer para que nuestros proyectos ágiles no se conviertan en proyectos sandía:

• La DoD (Definición de Hecho): introduciendo una definición de hecho para las tareas del proyecto. La DoD alineará el entendimiento de lo que significa "hecho" para todas las personas involucradas en el proyecto; "hecho" significará lo mismo para negocio, los interesados, el jefe de proyecto y los desarrolladores. Conseguiremos dos beneficios; reduciremos el retrabajo, ya que lo que esté hecho verdaderamente lo estará, y no habrá sorpresas ni malentendidos. Por otro lado ganaremos visibilidad sobre el progreso real del proyecto, ya que lo finalizado realmente estará finalizado.
• Focalizar en valor de negocio: priorizando las tareas en función del valor entregado al cliente. Así empezaremos el proyecto construyendo aquellas funcionalidades que sean más críticas o resuelvan las mayores necesidades de nuestro cliente. Las funcionalidades que queden para el final del proyecto no desatarán ninguna crisis si se desvían o no se hacen.
• Acabar antes de empezar: introduciendo una regla que marque que solo se puede continuar con la siguiente tarea del proyecto cuando la tarea anterior esté totalmente finalizada. A parte de focalizar al equipo, y por tanto acelerar el flujo, esta regla va a evitar que haya muchas tareas abiertas que oculten el verdadero progreso del proyecto.
• Nunca aceptar tareas que no cumplan con la definición de hecho: una tarea hecha al 90%, por ejemplo, no está hecha. Si la aceptamos como hecha, sea como equipo, jefe de proyecto o interesado, introduciremos incertidumbre en el proyecto que cuando explote generará un retrabajo que será muy costoso.
• Dividir en tareas pequeñas: tareas pequeñas focalizan por ser pequeñas, si empezamos una tarea pequeña es muy probable que no nos interrumpan mientras trabajemos en ella. Por otro lado tareas pequeñas son más fáciles de comprobar y de testear, por tanto será más fácil aplicar la definición de hecho. Tareas pequeñas dan sensación continua de avance y de cerrar cosas, con lo que habrá menos ruido en la cabeza de los desarrolladores y por ende una mayor motivación.
• Dar visibilidad frecuente a lideres e interesados: involucrándolos en revisiones y demos frecuentes de lo que estamos construyendo. Muchas veces la falta de visibilidad sobre la realidad del proyecto provoca que interesados, clientes y managers tomen decisiones equivocadas e influyan de forma negativa en el proyecto. Así por ejemplo es muy positivo que éstos conozcan las problemáticas por las que pasa el proyecto o el equipo, ya que éstos pueden aportar soluciones desde fuera que desde dentro del equipo no hayamos pensado.

Quiero finalizar el post resaltando que las prácticas y artefactos que he mencionado son algunos de los que promueve la Agilidad...

¿Crees que no puedes aprender de lo aprendido? Shu-Ha-Ri puede ayudarte

Imagen de Victoria Garrido :-)

El concepto de Shu-Ha-Rri es propio de las artes marciales japonesas, especialmente del Aikido.

Fue presentado por primera vez por Fuhaku Kawakami como Jo-ha-kyū. Más adelante Zeami Motokiyo, el maestro de Noh, extendió este concepto a su baile como Shu-Ha-Ri, que a su vez devendría en parte de la filosofía del Aikido y del arte marcial Shorinji Kempo.

Shu-Ha-Ri describe las etapas del aprendizaje hasta la maestría y se puede traducir aproximadamente como: "primero aprende, después desaprende y finalmente trasciende".

Por lo tanto:

• Shu: requiere seguir las reglas
• Ha: una vez que has seguido las reglas, hay que empezar a romperlas
• Ri: aquí se debería de innovar con tus nuevas reglas y abandonar las establecidas

Estas tres etapas nos ayudan a reconocer la esencia de una técnica y como consecuencia de ello habilitarnos poder transportar conocimientos a diferentes contextos.

Cabe la posibilidad de estar siempre en las dos primeras etapas, pero si se deseamos trascender deberemos llegar a la tercera.

Un ejemplo de esto, que es el más tradicional y común, cuando se incorpora un nuevo compañero a un equipo: ante la novedad siempre nos adaptamos y seguimos en los primeros meses con las reglas establecidas, con el paso de tiempo, y una vez interiorizada la situación del equipo, empezamos a romper con determinadas pautas con las cuales no estamos muy de acuerdo, y finalmente empezamos a establecer nuestras propias pautas/reglas.

Si aplicamos esto a la Agilidad se puede plantear una situación similar, puesto que las personas que entran a formar parte de organizaciones ágiles, no siempre están muy familiarizados con ellas, al principio siguen a pie juntillas todo lo que se les explica referente a las mismas, pero una vez interiorizan conceptos y avanzan en la utilización, y esto lo he vivido en primera persona, empiezan a realizar sugerencias, debatir determinadas actuaciones e incluso implementar pequeños cambios que sirven como tester para mejorar lo que hasta ese momento existía.

Todos sabemos que nada es para siempre, de allí la iteración, evolución, mejora y/o aprendizaje continuo. Es muy importante aprender, mirar con otra perspectiva y finalmente evolucionar. Gracias a estas evoluciones el ser humano disfruta hoy en día de importantes avances que han permitido mejorar a nivel de humanidad, de organizaciones, etc.

Estos ejemplos se podrían aplicar a numerosas situaciones, pero os invito a que participéis o reflexionéis sobre ellos.

Como dice Einstein:

Si buscas resultados distintos, no hagas siempre lo mismo