viernes, 23 de octubre de 2020

¿Cuáles son los aprendizajes sobre infraestructura para PI Plannings remotas?

Ejemplo de cada tipo de herramienta
Ya llevamos más de medio año afectados por el COVID-19, y eso nos ha llevado a efectuar todo tipo de eventos de trabajo de forma remota y dispersa, entre ellos la PI Planning. En este post quiero abordar los 5 tipos de herramientas digitales que necesitamos para dotar a las PI Plannings de una infraestructura adecuada:
  • Videoconferencia: La herramienta central que conecta todo y sirve de nexo y comunicación entre personas y artefactos. La sesión central de principio a fin de la PI Planning transcurre en esta herramienta, allí es donde las personas nos vemos las caras y colaboramos, y también donde compartimos información a través de chats y pantallas. La herramienta debe de incluir salas para grupos pequeños para las sesiones individuales de equipos. Estas salas deben de coexistir a la vez y ser visitables por cualquier persona; si un equipo necesita hablar con otro equipo u grupo, por ejemplo para para resolver una dependencia o aclarar una duda, ha de poder contactar y moverse fácilmente a través de las salas. Una opción excelente, y a fechas de hoy la más adecuada, es Zoom con sus breakout rooms. Necesitaremos una sala por equipo, una para Product Management, otra para arquitectura/sistemas/UX, una para el Scrum de Scrums, varias salas para conversaciones grupales esporádicas y también es muy recomendable una sala tipo cafetería para quienes estén descansando y/o quieran tener charlas informales.
  • Backchannel: Canales de mensajería instantánea adicionales que sirvan para potenciar y acelerar la comunicación. Recordemos la PI Planning es un evento de alrededor de cien personas, o más, entre las que se producirán cientos de conversaciones. Algunas de estas conversaciones pueden producirse perfectamente en herramientas como Whatsapp o Slack. Slack es especialmente útil por su sistema de canales que permite estructurar fácilmente las conversaciones de forma similar a los breackout rooms de la videoconferencia, además de permitir conversaciones por pares entre todos los asistentes. Otra función clave del backchannel es ser canal secundario cuando la videoconferencia falle. Al ser un canal totalmente independientemente la combinación de ambos nos asegura que haya un canal de comunicación con todo el mundo en todo momento.
  • Colaboración: Tableros de colaboración virtual tipo whiteboards para las sesiones de trabajo de los equipos, como lo son los tableros de los equipos, el Program Board, el tablero de Riesgos, un tablero Kanban para el progreso de evento, el canvas con la composición del tren (ART), un parking lot y otros. Estos tableros digitales son el punto de referencia para visibilizar el trabajo colaborativo de los equipos y del tren (ART). Se trata de herramientas como Miro, ConceptBoard y Mural. También podríamos utilizar herramientas como PIPLanning.app que están diseñadas exclusiva y únicamente para PI Plannings.
  • Feedback: Herramienta que permita recoger feedback para sesiones como lo son el voto de confianza y la retrospectiva de final de PI PLanning. Mentimeter y Kahoot son herramientas de este tipo que además son adecuadas para pequeños rompehielos a lo largo del evento para mantener el nivel de energía alto.
  • Gestor de pilas: Para la ejecución del PI es adecuado que el seguimiento de las pilas y del trabajo se realice en herramienta de gestión de proyectos ágiles, herramientas como JIRA, VersionOne y SeviceNow. Tableros colaborativos tipo whiteboard maximizan la colaboración síncrona y visibilidad en la PI Planning, y este tipo de herramientas de gestión facilitan la ejecución y colaboración asíncrona a lo largo del PI de pequeños grupos, como lo son los equipos.
La infraestructura para PI Plannings remotas y dispersas tiene sus retos con los que lidiar. Es crítico ensayar todos los aspectos y efectuar un ensayo general previo a la primera PI Planning. Mi consejo clave se podría resumir en: "probar, probar, probar... y probar otra vez".

Hemos de asegurarnos que todos los asistentes estén capacitados para el uso de todas las herramientas a utilizar; y que todos ellos tengan acceso a la infraestructura con los permisos necesarios. Por otro lado debemos de asegurarnos que la infraestructura pueda hacer frente a esa cantidad de usuarios concurrentes, no olvidemos que las VPNs se convierten fácilmente en un cuellos de botella. Y no nos olvidemos de las licencias, si una licencia hubiera de fallar o expirar sin duda ocurrirá en la PI Planning.

Todos los asistentes deben de tener cámaras y micrófono, y pensemos que el hecho de que un portátil tenga una cámara y micrófono no significa que esté preparado para funcionar el día de la PI Planning... podemos asegurarnos a través de los Scrum Masters, por ejemplo, que todos los miembros de los equipos tengan capacidad de videoconferencia.
PI Planning con videoconferencia por Zoom, tableros colaborativos en Miro y voto de confianza con Mentimeter

miércoles, 14 de octubre de 2020

¿Cómo tratar a los "externos"?

"Externos" versus "internos" - cortesía de Pixabay
Me sorprende una y otra vez que, cuando hablamos de arrancar una tribu o un tren (Agile Release Train), surja la duda sobre si formar y entrenar a los "externos". Como "externos" se entiende personas subcontratadas de lo que conocemos como consultoras. Me sorprende, porque si estamos introduciendo nuevas formas de trabajar se debe de entender, por puro sentido común, que estas formas de trabajar han de ser bien entendidas por todas aquellas personas que participen de las mismas, independientemente de que sean "internos" o "externos".

Entre otras surgen dudas legales, como que no se puede pagar formación a "externos", pero una cosa es asistir a una formación y otra quién la paga. Si queremos introducir Agilidad, como cualquier nueva forma de trabajar, la solución más eficiente es formar a todas las personas de la misma manera, de una sola vez y sin distinguir "internos" y "externos". Obtendremos varios beneficios:
  • Aprendizaje acelerado: la formación se realiza de una sola vez a modo de bootcamp en lugar de en un período de meses, lo que acelera el tiempo y el aprendizaje de todos y permite acelerar el lanzamiento de la tribu o del ART.
  • Un paradigma ágil común: todas las personas reciben la misma formación al mismo tiempo y del mismo trainer, eliminando la variabilidad de diferentes sesiones de formación por diferentes trainers que pueden utilizar cursos diferentes.
  • Rentabilidad: uno de los desafíos de una transformación ágil a nivel escalado es la disponibilidad y el coste de la formación. Los trainers talentosos y probados son difíciles de encontrar, no siempre están disponibles y su valor y coste son proporcionalmente altos. El enfoque de bootcamp suele ser de tres a cinco veces mas rentable que la formación de equipos individuales.
Hay que entender que lo que importa es que las personas que ejecuten el trabajo lo hagan en las mejores condiciones de trabajo posible, y para ello es necesario entrenarlos en Agilidad, apoyarles y darles los recursos necesarios. No importa si son "externos" o "internos".

Recordemos que las personas que hacen el trabajo toman decisiones a su nivel a diario, decisiones que inevitablemente impactan en la calidad de producto, y por ende en la competitividad de la compañía. Necesitamos personas competentes y motivadas, y de nuevo no importa si son "externos" o "internos".

El mayor activo de las empresas que se basan en trabajadores del conocimiento, como lo es el desarrollo de software por ejemplo, es el conocimiento de las personas. Es por ello que hoy en día se habla de capital humano. Un "externo" que por ejemplo lleve 4 años en una empresa cliente puede tener más conocimiento institucional y una red social más extensa y conectada que otros empleados "internos".


Las personas somos emocionales, nos sentimos ligados y orgullosos de lo que formamos parte. Si preguntamos a un "externo", que lleve en una empresa cliente un periodo mayor a un año por ejemplo, de qué empresa se siente parte, probablemente nos diga que de la empresa cliente y no de la empresa consultora que es quién le paga el sueldo. Si no lo tratamos como igual sus intereses probablemente se focalizarán en los propios en lugar de contribuir a los objetivos de la compañía cliente.

Los que hacen competitiva a la compañía, tienen buenas ideas y fomentan la innovación y crean productos de calidad son las personas que hacen el trabajo, independiente si son "externos" o "internos". Por tanto los líderes, liderando a través del ejemplo, debemos de tratar a todas esas personas de igual manera.

lunes, 12 de octubre de 2020

¿Qué técnica de retrospectiva se basa en el nivel de felicidad de los equipos?

Medición del índice de felicidad
en individual con Mentimeter

Los Scrum Masters debemos de introducir diferentes técnicas en las retrospectivas de los equipos ágiles. Una técnica enfocada a las emociones trata de la medición del índice de felicidad del equipo y permite traer a la consciencia el nivel de felicidad y buscar acciones de mejora concretas.

Está técnica está especialmente indicada para cuando el equipo ha experimentado muchas emociones diferentes durante un sprint y desea analizar las consecuencias. También cuando hubo varios retos dentro del sprint y el equipo quiere entender mejor cuándo y cómo surgieron los problemas.

La técnica ocurre en tres pasos:
  1. Medición del índice de felicidad individual para consolidarlo en el nivel actual del equipo
  2. Recoger razones del nivel de felicidad recogido
  3. Efectuar conversaciones alrededor de las razones principales
En los tiempos actuales, con los miembros de equipo dispersos, las dinámicas las hacemos con herramientas virtuales, en nuestro caso funciona muy bien Mentimeter. Cada miembro del equipo marca en su móvil u ordenador el nivel de felicidad desde la perspectiva de las emociones que ha vivido a lo largo del sprint.

En la sesión del Scrum Master, o facilitador, Mentimeter muestra el nivel de felicidad consolidado del equipo, que este comparte con todos.
Nivel de felicidad consolidado del equipo
Visto el nivel de felicidad consolidado recogemos las razones que han llevado a ese nivel mediante una nube de palabras. Las palabras las escriben los miembros de forma individual, y aquellas palabras que tengan más ocurrencias se desplazan automáticamente hacia el centro y toman un tipo de letra más grande. De esta manera es muy fácil identificar de forma visual cuales son las razones principales.
Nube de palabras con las razones del nivel de felicidad

A través de la nube de palabras el equipo puede identificar lo que afectó al sprint y generar una conversación sobre estas razones y buscar mejoras. Conocer las causas directas puede ayudar al equipo a resolver problemas en el futuro. Del mismo modo, si el equipo se siente positivo, ¿por qué no aplicar la misma técnica para tener éxito con problemas similares en el futuro?

Como toda retrospectiva esta técnica sirve también para ventilar problemas y celebrar éxitos, en definitiva reforzar a los equipos y generar team-building.

Mis agradecimientos a Gertru que aportó sus experiencias a este post :-*

lunes, 5 de octubre de 2020

¿Qué hacer con quienes se resistan a la transformación hasta la muerte?

John Kotter - Resistance to Change
Una transformación ágil es un cambio mayor en una compañía, un cambio tan crítico que requiere un alineamiento de todos, desde el CEO a cada uno de los empleados. Muchos abrazaran el cambio, para mucho otros el alineamiento será gradual, y algunos se resistirán a muerte...

En este post quiero mostrar el consejo que da John Kotter en su video sobre resistencia al cambio, y lo hago transcribiendo y traduciendo sus palabras:

"Tengo un consejo para ti y luego retrocederé y explicaré por qué es importante.

En un proceso de cambio siempre encontrarás a tu alrededor algunas personas que básicamente siempre dicen que "no no", y lo dicen en serio. Estos son los tipos que se resisten hasta la muerte. Tenemos una tendencia a tratar de atraerlos, de cooptarlos en el proceso, de trabajar con ellos para cambiar su opinión. Y mi consejo es "olvídalo". Sácalos del camino sin importar quiénes sean en términos de poder o relaciones contigo, porque si los dejas dentro harán tanto daño que el cambio se verá socavado.

Ahora déjame retroceder.

Todavía tengo que ver un cambio importante en una empresa u organización gubernamental donde no se encuentren en todos los niveles algunas personas cuya reacción a cualquier nueva estrategia o idea sea "no no". Ahora, algunas de estas personas, si están en posiciones poderosas, serán muy francas contigo, otras no, estarán muy calladas, pero eso es lo que piensan y eso es lo que sienten. Y la tendencia que veo con demasiada frecuencia ante este problema, y que creo que habría hecho yo mismo hace 10 años antes de entender a través de múltiples estudios, es decir: "Bueno, si tan solo pudiéramos pasar un poco más de tiempo con Jorge, lo ganaremos o, ya sabes, es lo suficientemente importante como para tener que cooptarlo. Lo haremos parte del equipo clave, y si lo atraemos sentirá eventualmente algo de propiedad por este programa, lo que acabará por resolver el problema.

Mi observación ha sido: si los "no no" son lo suficientemente fuertes, es inútil, es absolutamente inútil, y la única alternativa que tienes es sacarlos del camino, distraerlos, mantenerlos fuera del camino, porque el daño que pueden hacer es casi infinito. La travesura, por ejemplo, de simplemente sonreírte y decir "sí, sí" pero luego ir por detrás, porque ya no les prestas atención, y hacer cosas que deshacen los cambios que has hecho, como hablar con grupos de aquí diciendo "sabes que esto es un poco loco" y empezar a ganárselos, de prometerles hacer algo y luego "oh Dios, ya sabes, se me olvidó... o, tenía esta otra prioridad", y eso te frena... el daño que pueden crear es casi infinito.

Creo que a la mayoría de nosotros no nos gusta la idea de decir que "no tiene esperanza". Tenemos que sacarlos de esto y mantenerlos fuera de esto de alguna manera. Creo que a la mayoría de nosotros no nos gusta eso, pero creo que en los casos de cambios significativos, cuando hay esos "no no" alrededor, esa es la única solución. Realmente la única solución".



Quiero añadir que debemos de cuestionarnos si queremos personas en nuestra compañía cuyos valores personales no estén alineados, al menos en parte, con los valores de la compañía. No olvidemos que los valores son los fundamentos que guían la conducta para llevar a equipos y empresas a nuevas formas de trabajar con mejores resultados de negocio, entre ellas a Business Agility.

miércoles, 30 de septiembre de 2020

¿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...

lunes, 21 de septiembre de 2020

¿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.

jueves, 17 de septiembre de 2020

¿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
14 Principios
Mejora continua
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
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
  • 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
  • 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.

domingo, 13 de septiembre de 2020

¿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?

lunes, 7 de septiembre de 2020

¿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...