Esta semana vuelvo a la carga con, a juzgar por las visitas, uno de vuestros temas favoritos: Agile en RRHH.
Ya habíamos hecho un acercamiento general, y un zoom sobre cómo podríamos aplicarlo para mejorar el reclutamiento. Ese ejemplo pretendía ser una demostración de que, lejos de trasladar literalmente una metodología de desarrollo de software y esperar que haga magia, lo que pienso es que debemos intentar es interiorizar sus conceptos y utilizarlos en cada caso como mejor sirvan a nuestros objetivos.
Si os habéis leído el título del post, habréis adivinado que el proceso al que quiero someter al agilizador hoy es… la gestión del desarrollo del talento.
Cuando hablábamos de reclutamiento el problema de partida al que nos enfrentábamos es que estos procesos suelen alargarse innecesariamente con el consiguiente riesgo de perder buenos candidatos por el camino, por tanto el objetivo principal era conseguir optimizar los tiempos de entrega.
El desarrollo del empleado no es algo que tenga un final, es un proceso de mejora continua con lo cual no se trata de acortar tiempos, sino de obtener mejores resultados, es decir, mayor satisfacción de las personas en su crecimiento profesional, que se transforme en una mayor contribución de los mismos para su compañía.
Hace meses, hablando en el blog sobre los empleados que no tienen interés en desarrollarse, ponía el foco en uno de los problemas a los que se puede enfrentar este proceso, la falta de confianza… sobre todo en los casos en los que se ve obligado a dejar su crecimiento profesional en manos de un manager que no valora su desempeño.
Otro problema recurrente cuando hablamos de gestión del desarrollo es que el jefe de turno no le conceda importancia (= tiempo) porque siempre tiene otras cosas más urgentes de las que ocuparse.
A estos retos son a los que trataremos de dar respuesta tirando de recursos de Scrum.
Recordemos que sus principios básicos son:
- Transparencia: Recetada por los mejores especialistas para la mejora de confianza.
- Inspección y Adaptación: Imprescindibles en un proceso de mejora continua como nuestro desarrollo profesional.
Hablemos ahora de roles:
Scrum master: Aquí aparece claramente RRHH, el encargado de vigilar que las reglas del juego se cumplen y de tutorizar a los empleados en el funcionamiento de este proceso. Las personas de este departamento no suelen tener el don de la ubicuidad con lo cual su presencia física puede ser una opción solo cuando el empleado lo requiera por alguna razón justificada, pero en general su presencia será más virtual revisando que las reuniones scrum-desarrollo están teniendo lugar.
Product owner: Encargado de definir el backlog, que en este caso podemos traducir la lista de acciones que hay que completar dentro de un plan de desarrollo orientado a estar preparado a una posición concreta. Por defecto, en la mayoría de las empresas, este rol lo ocuparía el manager, pero en un mundo ideal para mí lo ocuparían un grupo de líderes o trabajadores experimentados, una comunidad de mentores, que definiese desde la experiencia y la objetividad los itinerarios de desarrollo dentro de la empresa.
Equipo de desarrollo: En este caso no hay un equipo como tal, sino cada empleado ha de ser responsable de su propio desarrollo.
Una vez adaptamos los roles, llega el turno para los eventos, o, para decirlo de un modo más informal, la dinámica de funcionamiento de una gestión del desarrollo ágil.
Cuando hablamos de desarrollo, las mejoras se consiguen a base de cambiar hábitos, lo que nos llevaran a nuevos comportamientos, con los que conseguiremos mejorar nuestras competencias profesionales. Y aquí tenemos un guiño al scrum original, el desarrollo de las personas, como el del software, puede (incluso debe) hacerse de manera incremental.
Podemos por tanto definir sprints en los que la complejidad de los entregables que componen nuestro backlog irá in crescendo (hábito, comportamiento, competencia), y podemos compartir nuestro progreso con el product owner (comunidad de mentores o manager). En estos casos, la reunión presencial desde un punto de vista logística puede ser complicada, por lo que lo recomendable sería un lugar de encuentro virtual (aplicación, foro, etc…) como norma general y uno físico cada cierto tiempo.
El scrum master en este caso no sería un rol que necesitase pegado al proceso, más bien supervisa y entra en juego solo cuando surgen dudas o discrepancias.
Lo importante en pos de la confianza, es que la comunicación se haga de forma trasparente, y las reuniones (sprint reviews) que se planifiquen luego se lleven a cabo. Si optamos por una herramienta digital, resultará más sencillo por aquello de configurar recordatorios, y porque, bien organizado ni siquiera el acceso entre el empleado y su mentor tendría que ser síncrono. El primer nuevo hábito que debemos introducir es que las personas piensen en su desarrollo con regularidad, y para eso debemos de dar facilidades desde un punto de vista tecnológico y desde un punto de vista de soporte humano (por eso creo que es más fácil de conseguir con una comunidad autogestionada y con verdadero interés en el desarrollo del talento, que con el único manager que te ha tocado en suerte)
Evidentemente, como suelo hacer en esta serie de post agile, esto no es (al menos aún) un método científico, si no la ejemplificación de que con un poco de conocimientos básicos de agile, podemos extrapolar sus ideas y lograr dinamizar un proceso de RRHH.
Seguro que puede hacerse de otro modo, las sugerencias siempre son bienvenidas en los comentarios de este blog, pero es obvio que hay ideas de esta metodología que aplicadas con cierta constancia puede mejorar nuestros procesos. ¿Por qué no intentarlo?
Growth steps by IconTrack from the Noun Project
One Comment