¿Por qué decimos que la Agilidad va de Personas?
La semana pasad, trabajando con un equipo Scrum de diseño de software, acerca de cuáles eran los principales bloqueos que estaban encontrando en los sprints, identificaron la asignación de tareas como uno de los principales.
A través de un modelo de conversaciones ágiles, trabajaron para identificar qué criterios podían utilizar para ver quién hacia cada tarea ya que habitualmente había conflictos en el proceso de elección del trabajo y últimamente era el Scrum Master quien acababa asignándolas al equipo (restando por tanto autonomía y responsabilidad).
Les pregunté cómo lo habían estado haciendo hasta ese momento y entonces empezaron a aflorar razones que nada tenían que ver con el propósito del Sprint y que estaban causando descontento en el equipo y poca motivación para ejecutar el trabajo, ya que según comentaban, había veces que unos elegían tareas con “intereses poco claros” para el resto del equipo.
Poco a poco fueron comentando que los equipos de desarrollo son perfiles que continuamente quieren estar aprendiendo cosas nuevas por lo que elegir siempre las tareas que “más sabes hacer” desmotiva bastante porque no te permite avanzar en la adquisición de conocimiento.
Es entonces cuando empezamos a reflexionar sobre cuál era su propósito para el Sprint: producir un incremento del producto completamente operativo y útil para el cliente y en un periodo de tiempo acotado.
Comentaban que tenían claro que conseguir llegar a tiempo a la realización de las tareas durante el sprint, cumpliendo los requisitos planteados en las user history, implicaba que las tareas las hicieran siempre los más expertos, pero eso les produciría falta de aprendizaje y desmotivación.
Tras diversas reflexiones y poniendo siempre por delante los principios Agile, se plantearon que si son capaces de equilibrar los momentos “críticos” (en los que evidentemente el equipo ha de asignar la tarea a quien pueda resolverla mejor y en menos tiempo), con otros en los que puedan permitirse fomentar el aprendizaje (un miembro del equipo podrá elegir una tarea que no sepa hacer tan bien como otro compañero pero que le suponga desarrollo profesional), podrían trabajar ambos aspectos.
Eso sí, se comprometieron a que cuando solicitaran al equipo hacer una tarea que llevara implícito el desarrollo profesional, lo indicarían con transparencia y sin “intereses ocultos” de manera que el equipo pueda decidir si es un buen momento o no.
En definitiva, las conversaciones transparentes son clave para un buen funcionamiento Scrum, que permita identificar cuáles son los estímulos que mueven el comportamiento de las personas del equipo y sobretodo crear un entorno de confianza y compromiso para que el equipo se sienta cómodo y pueda manifestar abiertamente cómo se siente y qué necesita para seguir evolucionando.
Un equipo puede estar muy capacitado técnicamente para el desarrollo de un producto, pero es clave la gestión de las Personas para que el equipo consiga su propósito.
Por eso, decimos que la agilidad va de Personas.
LEAN MANAGEMENT es una filosofía de trabajo enfocada totalmente hacia el cliente, centrada en la parte fundamental de los procesos y que persigue en todo momento la eliminación del desperdicio y la aportación de valor al cliente en todos los procesos de la organización. Seguir un sistema de gestión Lean dentro de una empresa proporciona una serie de beneficios entre los que podemos destacar: Reducción de los tiempos de los distintos procesos dentro de la empresa. Todo el tiempo que antes se perdía en realizar distintas tareas que no aportaban valor, ahora se reutiliza en otras acciones que generan valor. Mejora de a la eficacia de los trabajadores, haciendo su trabajo con menos esfuerzo y obteniendo mejores resultados. Las personas que conforman los grupos de trabajo dentro de la empresa estarán más satisfechas y se verá aumentada la calidad de su trabajo. Mejora del servicio al cliente. La entrega del producto al cliente se realiza más rápido y los niveles de satisfacción son más elevados ¿Qué ventajas podemos obtener al aplicar esta filosofía a un departamento de Recursos Humanos? Reducción de los tiempos en los procesos de selección, onBoarding, etc… Mejora de la eficacia del equipo de Talento, ejecutando su trabajo con menos esfuerzo y mejores resultados Mayor motivación del equipo al ver incrementada la calidad de su trabajo Mejora la experiencia del empleado pues los diferentes procesos se diseñan “people centric” con foco en la aportación de valor etc.. En definitiva, el LEAN TALENT MANAGEMENT posibilita una m ayor dedicación del equipo de Talento a responsabilidades estratégicas que aportan valor al negocio ¿Estás preparado para transformar el departamento de RRHH tradicional en un área de negocio de la compañía?
La semana pasad, trabajando con un equipo Scrum de diseño de software, acerca de cuáles eran los principales bloqueos que estaban encontrando en los sprints, identificaron la asignación de tareas como uno de los principales. A través de un modelo de conversaciones ágiles, trabajaron para identificar qué criterios podían utilizar para ver quién hacia cada tarea ya que habitualmente había conflictos en el proceso de elección del trabajo y últimamente era el Scrum Master quien acababa asignándolas al equipo (restando por tanto autonomía y responsabilidad). Les pregunté cómo lo habían estado haciendo hasta ese momento y entonces empezaron a aflorar razones que nada tenían que ver con el propósito del Sprint y que estaban causando descontento en el equipo y poca motivación para ejecutar el trabajo, ya que según comentaban, había veces que unos elegían tareas con “intereses poco claros” para el resto del equipo. Poco a poco fueron comentando que los equipos de desarrollo son perfiles que continuamente quieren estar aprendiendo cosas nuevas por lo que elegir siempre las tareas que “más sabes hacer” desmotiva bastante porque no te permite avanzar en la adquisición de conocimiento. Es entonces cuando empezamos a reflexionar sobre cuál era su propósito para el Sprint: producir un incremento del producto completamente operativo y útil para el cliente y en un periodo de tiempo acotado. Comentaban que tenían claro que conseguir llegar a tiempo a la realización de las tareas durante el sprint, cumpliendo los requisitos planteados en las user history, implicaba que las tareas las hicieran siempre los más expertos, pero eso les produciría falta de aprendizaje y desmotivación. Tras diversas reflexiones y poniendo siempre por delante los principios Agile, se plantearon que si son capaces de equilibrar los momentos “críticos” (en los que evidentemente el equipo ha de asignar la tarea a quien pueda resolverla mejor y en menos tiempo), con otros en los que puedan permitirse fomentar el aprendizaje (un miembro del equipo podrá elegir una tarea que no sepa hacer tan bien como otro compañero pero que le suponga desarrollo profesional), podrían trabajar ambos aspectos. Eso sí, se comprometieron a que cuando solicitaran al equipo hacer una tarea que llevara implícito el desarrollo profesional, lo indicarían con transparencia y sin “intereses ocultos” de manera que el equipo pueda decidir si es un buen momento o no. En definitiva, las conversaciones transparentes son clave para un buen funcionamiento Scrum, que permita identificar cuáles son los estímulos que mueven el comportamiento de las personas del equipo y sobretodo crear un entorno de confianza y compromiso para que el equipo se sienta cómodo y pueda manifestar abiertamente cómo se siente y qué necesita para seguir evolucionando. Un equipo puede estar muy capacitado técnicamente para el desarrollo de un producto, pero es clave la gestión de las Personas para que el equipo consiga su propósito. Por eso, decimos que la agilidad va de Personas.
“ El 70% de las grandes empresas españolas usan Agile de forma regular ”, así lo desvela un estudio sobre la adopción de Agile en España elaborado por la asociación Business Agility Corporation (BAC) formada por profesionales de distintos ámbitos de negocio pertenecientes a las principales empresas del país. La necesidad de adaptación de las empresas a los entornos VUCA (volatilidad, la incertidumbre, la complejidad y ambigüedad) hace que en la mayoría de las ocasiones la adopción Agile sea identificada como la posibilidad de ayudar a las organizaciones a transformar el negocio y por lo tanto suele ir liderada por el propio CEO o en su defecto por los equipos de TI cuando se habla de Transformación Digital. Es frecuente en muchos casos, que las organizaciones empiecen la transformación cambiando las rutinas operativas de los equipos de trabajo e implantando nuevas herramientas del mundo agile con la intención de que sea este cambio el que provoque como consecuencia la adopción de nuevos comportamientos en las Personas. Sin embargo, tras mucho tiempo y esfuerzo, las organizaciones empiezan a detectar que no se avanza en la implantación, hay conflictos frecuentes entre los equipos, los perfiles más senior no entienden porqué han de trabajar de una manera diferente a cómo lo venían haciendo (y que les había funcionado hasta ahora)….y es entonces cuando los líderes se plantean, ¿qué estamos haciendo mal?. Y es que las herramientas y las metodologías no funcionan por sí mismas, son las Personas las que hacen que funcionen. Pensar primero en las Personas y luego en los procesos y herramientas es la clave del éxito de una transformación organizativa. Y si hablamos de Personas, ¿no tendrá recursos humanos mucho que aportar en un proceso de transformación? Claro que sí. Mas aún, cualquier transformación organizativa que implique un cambio cultural y no vaya de la mano del equipo de recursos humanos, tiene muchas posibilidades de fracasar puesto que no hay otro perfil en la estructura organizacional cuya principal pasión sea trabajar en el comportamiento de las personas. Los líderes en las organizaciones han de saber que, como cualquier cambio en una organización, la transformación Agile ha de cubrir una serie de etapas para lograr una exitosa implantación y recursos humanos tiene un reto importante en cada una de ellas: COMUNICACIÓN. La información a las personas, previamente a llevar a cabo cualquier iniciativa, es clave para poder empezar con un clima de motivación frente a generar actitudes de resistencia al cambio. Es imprescindible explicar lo que va a ocurrir, los motivos para el cambio, que habrá un plazo de adaptación, y de esa manera generar tranquilidad frente a temores infundados. Comunicar el compromiso de la alta dirección es fundamental para conseguir el compromiso de los empleados. IDENTIFICACIÓN. Es importante analizar si las personas poseen los comportamientos clave o “AgileMindset” de manera intrínseca pues en caso contrario será imprescindible trabajar un cambio de mentalidad previamente al inicio del proyecto. Agile implica transformar totalmente la manera como se venían haciendo las cosas y los cambios no son fáciles. FORMACIÓN. Formar a las personas en los nuevos comportamientos es condición necesaria durante una transformación. ¿Cómo hay que comportarse en los “Daily meeting”?, ¿cómo dar feedback entre compañeros en una reunión de retrospectiva?, ¿Cómo pedir al equipo que manifiesten cómo se han sentido durante el proyecto cuando no ha sido habitual hablar de emociones? EJEMPLO. Para que recursos humanos pueda liderar la transformación ha de empezar transformándose a sí mismo. Empezar a adoptar nuevas formas de colaboración, implantar nuevas herramientas para sus procesos y/o proyectos y ser evangelizadores de agile. ADAPTACIÓN. Conforme la organización vaya aceptando el cambio e integrando en su forma de trabajo las metodologías aprendidas y la nueva forma de hacer, es posible que los roles de HR vayan migrando a nuevas responsabilidades. En función del perfil de la compañía probablemente la figura de HRPartner dejará algunas de las funciones actuales y aportará más valor como Agile Coach de los diferentes equipos Scrum. En definitiva, si eres un líder de recursos humanos tienes un gran reto por delante. ¿Estás preparado para empezar?
Scrum es un conocido marco de trabajo ágil para el desarrollo y gestión de proyectos de software. Sin embargo, es mucho más que eso, se trata de un marco de gestión que permite hacer frente a problemas complejos de manera adaptativa, contribuyendo al desarrollo de productos/soluciones del más alto valor para los clientes. Cada vez más organizaciones están convencidas de la necesidad de hacer las cosas de manera diferente para poder dar respuesta a la continua variabilidad en las demandas de los clientes. Para ello, acompañando a una transformación cultural (adopción de #AgileMindset) están introduciendo scrum en los diferentes departamentos. El marco de trabajo scrum se basa en tres elementos: eventos, roles y artefactos, que deben ser aplicados en conjunto. Cada uno estos elementos sirve para un propósito específico, y cada uno es esencial para el éxito. Además, es necesario un conjunto de reglas para aglutinar y armonizar todos los elementos. Vamos a detenernos en los eventos en scrum para ver porqué los departamentos de recursos humanos deberían estar más cerca de estas reuniones operativas. Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso de avance por tiempos prefijados (time boxing). Sprint Planning: reunión de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el objetivo del sprint y las tareas necesarias para conseguirlo. Daily Meeting: breve reunión diaria del equipo. Cada miembro indica lo que hizo ayer, lo que va a hacer hoy para alcanzar el sprint goal y los bloqueos que pueden impedirle el avance. La figura del #Scrum Master tiene en su rol eliminar esos bloqueos. Sprint Review: La reunión se realiza al final del sprint donde el propietario del producto comprueba el incremento e identifica las funcionalidades que se consideran “hechas” y las que no. Retrospectiva del Sprint : revisión de lo sucedido durante el sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint. De estas reuniones, hay dos en las que el contenido es de un gran valor para los responsables de desarrollo de personas: Daily Meeting : como ya hemos indicado, es rol del Scrum Master reducir las barreras para el avance del equipo. Pero, ¿qué pasa con los bloqueos cuando no son de carácter técnico? ¿Y si obedecen a aspectos de índole más emocional? En ocasiones el bloqueo puede ser producido por un conflicto entre personas, un problema personal de alguien del equipo, egos individuales, etc…También puede ocurrir que los bloqueos obedezcan a falta de conocimiento técnico a la hora de realizar una tarea o carencia de alguna soft skill. Retrospectiva: es otro momento de análisis en el que además de evaluar los aspectos operativos de la forma de trabajo y crear un plan de mejora, se trabaja en profundidad el feedback entre los miembros del equipo donde se explicitan aquellos comportamientos que no han contribuido al avance del proyecto y también se lleva a cabo el reconocimiento por los logros alcanzados. ¿Pero están los equipos capacitados para dar y recibir feedback abierto y en grupo? Los equipos de recursos humanos continuamente están ideando fórmulas para obtener información sobre el desempeño de las personas de la organización, pero difícilmente pueden acceder a ella de manera sistemática. Con scrum implantado en los equipos operativos, los departamentos de recursos humanos pueden disponer de un canal de información continua sobre la evolución/desarrollo de las personas que les permita: Implementar planes de formación individuales alineados con el negocio Entrenamiento en habilidades para facilitar la adopción de los nuevos marcos de trabajo ágil Diseñar programas de intervención de conflictos (conociendo las interacciones más frecuentes que se producen en los equipos de proyectos) Alinear iniciativas de reconocimiento con el feedback de las reuniones y un largo etc... En definitiva, si tu empresa está iniciándose en el mundo de la agilidad, y lideras el departamento de recursos humanos, no dudes que la aplicación de scrum en los equipos de proyectos es una gran ventaja. Pero, ¿están tus procesos de gestión de personas diseñados, de manera que permitan trabajar adecuadamente toda la información recibida y generar productos de valor para los empleados? Porque para entender y aplicar los marcos de trabajo ágiles necesitas haber adoptado una mentalidad ágil. ¿Estás preparado para ese cambio?
¿Qué es un MVP? El MVP es la versión mínima de un nuevo producto, e incluye las características básicas para satisfacer las necesidades de los clientes. Permite a una empresa o equipo recolectar la mayor cantidad de información validada gracias a sus "early adopters", para así mejorar el producto lo antes posible, con el fin de lanzarlo a un público más amplio. Poner el foco en el desarrollo de un Mínimo Producto Viable a diferencia de hacerlo sobre un Producto Terminado, es clave para que una empresa reduzca el riesgo. Este mismo enfoque se puede aplicar al desarrollo de productos/proyectos/servicios dentro del área de rrhh. Habitualmente trabajamos con un esquema tradicional: diseño de producto terminado y con un alcance global, es decir, para toda la organización. Sin embargo, esto supone mucho tiempo, dedicación y coste, sobre todo cuando tras el lanzamiento (en ocasiones después de meses de trabajo), el proyecto presentado NO satisface las necesidades de nuestras Personas. ¿Para qué sirve diseñar un Mínimo Producto Viable? El propósito principal es realizar un experimento para validar si los usuarios quieren la solución que les ofreces. No importa cuán bueno y útil sea el MVP si no soluciona las necesidades de las personas a quienes va dirigido Cómo hacer un Producto mínimo viable en 3 pasos: 1. Identificación de usuarios clave Cuando vas a iniciar el desarrollo de un producto/proyecto/servicio tendrás que tener en cuenta quienes serán los usuarios y cuáles son las necesidades específicas de cada uno. Habitualmente ponemos el foco en los trabajadores pero habrá que tener en cuenta a todos los stakeholders (managers, propiedad, finanzas, etc…) que puedan estar implicados. Una vez identificados los usuarios, realiza una lista con las necesidades que hayas recogido (a través de encuestas de clima, formularios de satisfacción, canales de comunicación, entrevistas, etc...). Te aconsejo redactarlas siguiendo este esquema: YO (empleado/ manager...) QUIERO (la necesidad que has identificado) PARA (el objetivo que pretende conseguir una vez solucionada la necesidad) 2. Define claramente las características que vas a incluir en tu MVP Para la definición del MVP hemos de tener en cuenta algunas consideraciones fundamentales: necesidad vs deseos Tendrás que responder a esta pregunta ¿Las personas desean esta función para resolver su problema o la necesitan realmente para dar solución a su problema?. Mientras que los deseos son esas características que van a convencer a las personas para que prueben lo que ofreces, las necesidades son las características imprescindibles del servicio o producto. Si no tienes la seguridad de que algo vaya a usarse o con qué frecuencia, se trata de un deseo. También es clave limitar el alcance. Identifica un equipo, perfil o departamento que serán en primera instancia los usuarios del producto (early adopters) 3. Construye, mide y aprende Pon el foco en la creación de tu producto, identifica indicadores de satisfacción y cuanto antes testéalo con los “early adopters”. En esta etapa de análisis es cuando se hacen los ajustes necesarios. En función del feedback que recibas, si el producto cumple con las hipótesis que te planteaste y por tanto genera satisfacción, continúa el desarrollo. Si no es así, modifica lo que no está aportando valor, plantea nuevas hipótesis y vuelve a comprobarlas. El diseño de proyectos con un enfoque ágil, es de gran utilidad al área de RRHH pues posibilita ofrecer servicios con foco absoluto en las personas, en menos tiempo, con un elevado control del riesgo y creando mayor satisfacción. Te interesa el mundo de la agilidad aplicado a RRHH? Entonces hablemos!
Frecuentemente escucho a compañeros/as de profesión decir que nunca hay suficiente presupuesto para las acciones de RRHH. Y sin embargo, todos los CEOs de las empresas, saben que la clave de los negocios son las Personas. ¿Cómo puede ser que se abandonen acciones, que se supone impactan directamente en el bienestar del activo principal de una compañía? Algo no estamos haciendo bien. ¿No será que los/as líderes de RRHH, no sabemos vender bien nuestros proyectos a los Comités o CEOs? Desde mi humilde opinión, algo que caracteriza a los/as profesionales de RRHH es su pasión por el desarrollo de personas y estoy convencida de que la puesta en marcha de muchos de esos proyectos, tendrían grandes beneficios y generarían un gran valor en sus negocios. Sin embargo, es frecuente que esas ideas no progresen más allá de una presentación, o incluso de un análisis de presupuestos. En la mayoría de los casos, una vez el departamento financiero, comité o CEO revisa los costes que la empresa ha de acometer para impulsar el proyecto, la respuesta es: no hay presupuesto. Pero, qué pasa con los beneficios que se podrían obtener de la implantación de esas ideas? ¿porqué sólo analizamos los costes? Y ahí considero que está la clave. Muchas veces en RRHH no sabemos medir el impacto positivo de nuestras acciones, de manera que si solo presentamos costes y los beneficios que ofrecemos son subjetivos (ej: personas motivadas, comprometidas....) pero sin ningún dato medible, es normal que nos digan que ya abordaremos el proyecto para el siguiente presupuesto. ¿Cómo podemos aprender a vender mejor nuestros proyectos? Empecemos por utilizar un Pich Deck. ¿Qué es un Pitch Deck? Un Pitch Deck es una breve presentación que utilizan los/as emprendedores/as de startups para dar una visión general de su negocio y conquistar a los inversores. A pesar de la brevedad de las presentaciones, que generalmente utilizan 10 diapositivas o incluso menos, crear un Pitch Deck no es fácil, sobre todo cuando no estamos acostumbrados/as a simplificar y redactar sólo lo que aporta valor a la venta del proyecto. Para empezar, debes tener en cuenta los siguientes aspectos: Diapositivas simples, que transmitan ideas importantes y directas. Usa fuentes grandes y limita el número de palabras en cada diapositiva. Usa imágenes siempre que encajen y aporten valor. Crea un vínculo emocional con las ideas. Cuéntalo como una historia y mantén el interés. Aporta referencias que soporten tus argumentos La duración no suele ser superior a 5 minutos. El resto de tiempo lo puedes dedicar a resolver dudas y preguntas Mándala en PDF una vez finalizado el Pitch Deck. El documento que envíes puede llevar información en texto que no hayas presentado en las diapositivas. ¿Qué diapositivas incluye el Pitch Deck? 1. El PROBLEMA que has detectado en tu empresa. Demuestra que has hecho un análisis objetivo de la situación y añade datos numéricos, %, evidencias que respalden tus argumentos sobre el problema identificado. 2. La SOLUCIÓN que has identificado. Indica cuál es la clave para hacer frente al problema y argumenta en qué información te basas para presentar tu planteamiento. Añade datos que evidencien que tu solución generará beneficios y en qué porcentajes. 3. El PRODUCTO que vas a implementar. Explica en qué va a consistir el producto/proyecto que vas a desarrollar, Ej: implantación de un software, un nuevo modelo de evaluación, un sistema retributivo, etc.... Añade imágenes que respalden tus propuestas para que la audiencia pueda entender mejor lo que tienes en mente. 4. La TRACCIÓN o evolución en el desarrollo de la solución. Explica los hitos principales y qué resultados vas a lograr en cada uno de ellos. Cuenta en qué momento del proyecto estás y el timing de logros. El modelo de Design Thinking te puede ayudar mucho: Ideación - Validación - Test - Lanzamiento 5. El MODELO DE NEGOCIO . Explica el plan de monetización que obtendrá tu empresa con la implantación de tu producto. Si quieres que "compren" tu propuesta, vincula los hitos de tu producto a KPIs de negocio. 5. El MERCADO . Explica el TAM (Total Addressable Market), SAM (Served Available Market) y SOM (Serviceable Obtainable Market) TAM = todas las personas de tu empresa a las que puedes llegar con tu producto SAM = % sobre el TAM que realmente son público objetivo del producto SOM = % del SAM al que te vas a dirigir inicialmente 6. La APROXIMACIÓN AL MERCADO Explica "cómo vas a ganar clientes", es decir, cómo vas a conseguir que las personas utilicen tu producto. Ej: plan de comunicación, a través de mandos intermedios, con videos tutoriales, etc... 7. La COMPETENCIA Haz un análisis de las empresas de tu competencia y explica cómo están afrontando el problema identificado. Argumenta porqué tu propuesta es mejor y qué ventaja competitiva genera para tu compañía 8. El EQUIPO Presenta al equipo que va participar en el proyecto. Es más que recomendable implicar a personas de otras áreas en el desarrollo y apostar por equipos multidisciplinares para crear productos HR. Puedes explayarte en algún punto como por ejemplo PRODUCTO y utilizar 2 diapositivas, pero es recomendable no emplear más de 10. En definitiva, si eres capaz de preparar tu Pitch Deck de 5 min y 10 slides estás listo/a para presentar tu proyecto. ¡Muchos éxitos! Pero si todavía te cuesta encontrar datos para completar el pitch deck, quizás no sea el momento para vender tu idea. Te recomiendo invertir tiempo en trabajar el contenido del pitch deck para estar absolutamente seguro/a de que tu propuesta va a aportar valor a la empresa. ¿Quieres apoyo en la elaboración de tu Pitch Deck para presentar esa idea que consideras clave para evolucionar tu negocio? No dudes en contactarnos!