Formas de iniciar una transformación organizacional en la empresa
Tuve la oportunidad de participar en la transformación organizacional de una empresa local (estoy en Perú) bastante grande y conocida.
Como menciono en otro artículo, el tiempo es muy valioso en las empresas; por tanto es un gancho importante al hablar de cómo nos benefician las prácticas ágiles en la gestión de proyectos y personas.
Cuando hablas del tiempo, hablas de el cambio en los clientes y por tanto en la organización. Esto puede ser llevado a negocios que brindarás e ingresos planificados. Todo eso enamora a las empresas; al menos lo suficiente para que te sigan escuchando.
Lo primero fue un proceso de "enamoramiento" del equipo de tecnología. Hablar sobre devops, hablar sobre equipos multidisciplinarios, hablar sobre el involucramiento del negocio en la labor de creación de soluciones, hablar de valor en los pedidos, todo eso ayuda y mucho.
Esto se complementó con capacitaciones dirigidas sobre principios ágiles, gestión de proyectos ágiles y escalabilidad ágil. Un enfoque en el valor de lo que generamos, de la importancia de la participación del negocio y de la "licencia" que de debe tener para equivocarse temprano los puede llevar a pensar que es la panacea. Algunos pueden dudar de que algo así exista, pero al menos ya hay interés.
Lo siguiente es enfocarse en el negocio. Dado el interés de TI, ellos te van a apoyar (o debes buscar su apoyo) a convocar charlas con personas claves de la organización.
El enfoque en el corazón de la agildad, es decir en la entrega continua de valor hacia los clientes, el tener equipos colaborativos de alto rendimiento, el poder adaptarse al cambio rápidamente y tener un enfoque de calidad y mejora contínua, hace que la gente de negocio entienda el porqué las cosas no pueden continuar como están y debe haber un cambio.
Eso es suficiente para llamar su atención y querer ahondar más. Tal vez no crean el cuento completo, pero ya les entró la curiosidad al respecto.
Esto debe complementarse con charlas orientadas a lo que se espera de un Product Owner, la necesidad del Inception, el porqué debemos enfocarnos en un MVP en lugar de querer hacer todo y sobre trabajo colaborativo.
Recuerdo mucho un entrenamiento relacionado a User Story Mapping y cómo en un par de horas, puedes pasar de una idea hacia un esquema listo para empezar a trabajar con un equipo de desarrollo. Recuerdo el brillo en los ojos de los participantes que un par de horas antes no sabían que era tan simple (parece simple) poder poner sus ideas a disposición sin tanta documentación. Aparte que eran ideas que se les había pedido elaborar ahí mismo y no relacionadas al trabajo. Vieron el mundo de otra manera. Querían poner en práctica lo aprendido.
Igual toma tiempo el pasar de una instancia a otra; no todo es en un día o en el mismo mes. Todo toma tiempo en las empresas.
Lo siguiente que viene es armar pilotos. Proyectos que puedan ser realizados bajo Scrum.
Hay que saber escoger los pilotos. No todo proyecto puede ser piloto. Recuerden que la empresa no tiene experiencia en proyectos similares; por ende va a querer usar un proyecto controlado. Uno con impacto pero no crítico para la organización porque no quiere fallar.
Tampoco hay que esperar mucha variabilidad en los requerimientos; se deja la puerta abierta pero al inicio no va a haber mucho cambio. Poco a poco se brindará la confianza para ellos y verán que es posible manejar el "core" de lo que se requería más cambios que realmente generan valor al producto. No necesariamente vas a terminar toda la lista original (esto se pacta con el cliente) pero verás que la cara de felicidad del cliente va en aumento con cada entregable.
Ya cerrado el piloto, verás que van a ir pensando en hacer una transformación organizacional apuntando hacia metodologías ágiles; es decir que no querrán retornar a hacer proyectos en cascada.
El no hacer más proyectos en cascada de la noche a la mañana es irreal. Pero creo que será material para otro artículo.
Como menciono en otro artículo, el tiempo es muy valioso en las empresas; por tanto es un gancho importante al hablar de cómo nos benefician las prácticas ágiles en la gestión de proyectos y personas.
Cuando hablas del tiempo, hablas de el cambio en los clientes y por tanto en la organización. Esto puede ser llevado a negocios que brindarás e ingresos planificados. Todo eso enamora a las empresas; al menos lo suficiente para que te sigan escuchando.
Lo primero fue un proceso de "enamoramiento" del equipo de tecnología. Hablar sobre devops, hablar sobre equipos multidisciplinarios, hablar sobre el involucramiento del negocio en la labor de creación de soluciones, hablar de valor en los pedidos, todo eso ayuda y mucho.
Esto se complementó con capacitaciones dirigidas sobre principios ágiles, gestión de proyectos ágiles y escalabilidad ágil. Un enfoque en el valor de lo que generamos, de la importancia de la participación del negocio y de la "licencia" que de debe tener para equivocarse temprano los puede llevar a pensar que es la panacea. Algunos pueden dudar de que algo así exista, pero al menos ya hay interés.
Lo siguiente es enfocarse en el negocio. Dado el interés de TI, ellos te van a apoyar (o debes buscar su apoyo) a convocar charlas con personas claves de la organización.
El enfoque en el corazón de la agildad, es decir en la entrega continua de valor hacia los clientes, el tener equipos colaborativos de alto rendimiento, el poder adaptarse al cambio rápidamente y tener un enfoque de calidad y mejora contínua, hace que la gente de negocio entienda el porqué las cosas no pueden continuar como están y debe haber un cambio.
Eso es suficiente para llamar su atención y querer ahondar más. Tal vez no crean el cuento completo, pero ya les entró la curiosidad al respecto.
Esto debe complementarse con charlas orientadas a lo que se espera de un Product Owner, la necesidad del Inception, el porqué debemos enfocarnos en un MVP en lugar de querer hacer todo y sobre trabajo colaborativo.
Recuerdo mucho un entrenamiento relacionado a User Story Mapping y cómo en un par de horas, puedes pasar de una idea hacia un esquema listo para empezar a trabajar con un equipo de desarrollo. Recuerdo el brillo en los ojos de los participantes que un par de horas antes no sabían que era tan simple (parece simple) poder poner sus ideas a disposición sin tanta documentación. Aparte que eran ideas que se les había pedido elaborar ahí mismo y no relacionadas al trabajo. Vieron el mundo de otra manera. Querían poner en práctica lo aprendido.
Igual toma tiempo el pasar de una instancia a otra; no todo es en un día o en el mismo mes. Todo toma tiempo en las empresas.
Lo siguiente que viene es armar pilotos. Proyectos que puedan ser realizados bajo Scrum.
Hay que saber escoger los pilotos. No todo proyecto puede ser piloto. Recuerden que la empresa no tiene experiencia en proyectos similares; por ende va a querer usar un proyecto controlado. Uno con impacto pero no crítico para la organización porque no quiere fallar.
Tampoco hay que esperar mucha variabilidad en los requerimientos; se deja la puerta abierta pero al inicio no va a haber mucho cambio. Poco a poco se brindará la confianza para ellos y verán que es posible manejar el "core" de lo que se requería más cambios que realmente generan valor al producto. No necesariamente vas a terminar toda la lista original (esto se pacta con el cliente) pero verás que la cara de felicidad del cliente va en aumento con cada entregable.
Ya cerrado el piloto, verás que van a ir pensando en hacer una transformación organizacional apuntando hacia metodologías ágiles; es decir que no querrán retornar a hacer proyectos en cascada.
El no hacer más proyectos en cascada de la noche a la mañana es irreal. Pero creo que será material para otro artículo.
Comentarios
Publicar un comentario