11 errores que se deben evitar al querer implementar DevOps
Habilitar la agilidad en una organización sin duda requiere cambios en todos los niveles organizacionales. Algunos mas complejos que otros, pero al final es una espiral de cambios constante, para adaptarse al nuevo contexto y/o a las nuevas necesidades.
Desde hace varios años, los equipos de negocios y desarrollo han visto un cambio de los enfoques tradicionales de desarrollo de software, al tener que pasar del desarrollo en cascada al desarrollo iterativo, de ágil a nivel de equipos ha escalado ágil hasta llegar a Enterprise Business Agility.
Pero cambiar el enfoque de una organización desde la definición de temas estratégicos, pasando por la identificación de necesidades de los clientes, la gestión del portafolio y el desarrollo de iniciativas hasta llegar a la entrega está lejos de ser sencillo. Cada bloque del proceso presenta diferentes tipos de retos que deben ser abordados a lo largo de todo el ciclo de la mejor manera posible.
Es decir que, para tener una visión completa de la agilidad empresarial, es necesario equilibrar el Valor (construir lo correcto), la Calidad (construir correctamente y el Flujo (construir a la velocidad adecuada). Para este último, significa optimizar el flujo de entrega de valor balanceando el grado en que la organización optimiza el uso de recursos y optimiza el flujo de entrega de valor al cliente.
Es en este punto en donde entra DevOps. Para unos una cultura, para otros una metodología, para otros algo creado sin necesidad, dado que la agilidad como tal engloba el concepto de unir de manera colaborativa y con el único fin de generar valor, el trabajo de las diferentes áreas de la organización.
Implementar DevOps en una organización se convierte en un desafío cultural y tecnológico, lo cual significa que es obligatorio para cualquier organización tomarse en serio el proceso, tener líderes a la cabeza del proceso, que lo entiendan y puedan trabajar con diferentes tipos de roles de manera interfuncional, será sin duda una de las claves principales del éxito de la implementación. Por lo tanto, si hay una visión clara y los objetivos están bien definidos desde el principio, entonces el resto de la organización se alineará. Por el contrario, si esto no existe, es casi seguro que la implementación va a fallar.
A continuación, veamos los 11 principales errores que se deben evitar entonces al querer implementar DevOps:
Partir con la idea que DevOps es una cultura. No, DevOps no es en sí una cultura, pero sí requiere de una fuerte evolución cultural y organizativa para su implementación. Un evolución cultural hacia la colaboración, la comunicación, y en último término la completa integración entre las áreas de desarrollo y sistemas. Lo cual requiere una buena gestión del cambio.
Pero según lo anterior, entonces que podemos decir que es DevOps: DevOps es una metodología de desarrollo software, y una evolución cultural no es en sí misma una forma de desarrollar software. Esta evolución cultural es tan complicada de conseguir en algunas organizaciones, que muchas personas la identifican directamente con implementar DevOps.
Creer que DevOps es un Rol o cargo nuevo. Este es otro error común, ya que se tiende a confundir DevOps con modelos que algunas startups se ven abocadas a adoptar en sus inicios, en los que todos los miembros del equipo técnico saben de desarrollo, de operaciones, de bases de datos… etc. DevOps no consiste en aumentar la responsabilidad de los desarrolladores haciendo que lleven varios sombreros (en particular dos, el de desarrollo y el de operaciones), sino en sustituir esos dos sombreros por uno solo, un nuevo sombrero de DevOps.
Según Rob Steward, vicepresidente de desarrollo de producto de Progress Software, “una buena práctica de DevOps liberará a los desarrolladores de ciertas tareas, para que se centren en hacer lo que mejor saben hacer: escribir software. Dado que DevOps elimina el trabajo y las preocupaciones de la puesta en producción del software una vez que está escrito”.
Si esto es así, ¿qué es un ingeniero DevOps?, ¿Por qué se buscan en el mercado (y cada vez con mayor demanda) perfiles con habilidades específicas para montar equipos DevOps? La respuesta es sencilla. Para un desarrollador pasar a un modelo DevOps resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas habilidades. Estas habilidades, según una investigación de Puppet Labs, son: scripting, reingeniería de procesos, experiencia con herramientas específicas y una serie de soft skills necesarios para lograr las interacciones que se requieren dentro del proceso. Por lo que un perfil de este tipo, no es fácil de encontrar.
Así que no, DevOps no es una profesión, y estrictamente no existen ni perfiles DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con capacidades específicas para integrarse en equipos DevOps”.
No considerar a las personas y a los recurso en el proceso de implementación. Si no se tiene suficiente conocimiento sobre las cargas de trabajo de los equipos y sus capacidades para realizar tareas, lo mejor es no obligarlos a adoptar DevOps. Lo más recomendable siempre será, cuantificar primero la carga de trabajo de cada una de las personas de los equipos y de los equipos en general. Los siguientes pasos serán entonces, diseñar indicadores clave de rendimiento (KPI) y garantizar que estén bien controlados. Acto seguido, analizar y comprender el rendimiento de todos, para así utilizar la información obtenida para organizar mejor las cargas de trabajo
Ver a DevOps solo como un proceso de automatización. Si bien en DevOps, es importante automatizar la mayor parte del proceso (si la mayor parte, no todo), tanto como sea posible. DevOps va más allá, Matthew Skelton (cofundador de Skelton Thatcher) dijo: “si se crea un enfoque DevOps, que involucra a un único equipo encargado de la automatización, se perderá el sentido, ya que concentrarse solo en la automatización le proporcionara solo un poco de efectividad adicional en TI”. otro experto en DevOps, Stephen Thair (Cofundador de DevOps Guys) explica: “DevOps no es solo una cosa de TI. Ya que, si la organización está centrada solo en la automatización, DevOps le ofrecerá un software mejorado. Pero no solucionará los problemas de cuellos de botella que tenga el flujo de desarrollo de soluciones en la organización”.
Otro punto interesante para tener en cuenta es: Armar un equipo o célula en TI enfocado en DevOps, hará que se establezca un nuevo silo en el flujo.
Querer implementar DevOps con personas sin experiencia. Actualmente muchas empresas están dando el paso hacia la implementación de DevOps. Sin embargo, en muchos casos con pocos o ningún ingeniero con experiencia real en la implementación de DevOps. Como resultado, terminan entregando trabajos de baja calidad. Aquí hay que tener algo presente, pasar de un proceso de desarrollo de soluciones sin DevOps a uno con DevOps es una idea brillante, pero solo si como organización se está bien preparado y se cuenta con ingenieros con experiencia. Ya que el nivel de habilidades y conocimientos que se requieren es extremadamente alto.
Sobreponer la velocidad sobre la calidad. Muchas organizaciones se enfocan en fabricar un producto rápido, en lugar de enfocarse en la calidad. (aquí una opinión muy personal: agilidad sin calidad, no es agilidad y la agilidad si debe brindar velocidad a la hora de generar valor, pero con calidad). Las tareas de DevOps deben lograrse manteniendo altos estándares. Por otro lado, no puede comprometer la velocidad con la calidad. En el mundo de hoy, la competencia se ha vuelto tan dura y permanecer relevante es un desafío. Es por eso por lo que muchas organizaciones se apresuran a aceptar proyectos de DevOps y terminarlos en el menor tiempo posible. Como resultado, la calidad del trabajo es pobre. La velocidad y la calidad deben funcionar de la mano.
Avanzar hacia nuevas tecnologías sin terminar de madurar las anteriores. El problema en muchas organizaciones es que comienzan a usar nuevas tecnologías antes de que terminen de investigar y/o madurar las anteriores. Además, en muchos casos vemos como usan tecnologías que aún están en modo beta, solo porque los competidores están haciendo lo mismo. (el mismo caso sucede con la agilidad, la cual en muchos casos llega a las organizaciones, más por el hecho que en la competencia se está “trabajando bajo agile”, que por el hecho de existir conciencia que se debe habilitar en la organización) . Antes de comenzar a usar estas tecnologías, las organizaciones deben tomarse el tiempo necesario para realizar una investigación seria y exhaustiva de dichas tecnologías, con el objetivo de determinar si estas son las que realmente requiere o se adaptan a la organización o si, por el contrario, es la organización quien debe adaptarse a ellas. Esto con el fin de gestionar dicho cambio responsablemente. Hay que tener en cuenta también que la tecnología cambia día a día y se están introduciendo complementos para actualizar las tecnologías antiguas. Sin embargo, lo recomendable siempre será, no tengas prisa por actualizar cuando se trata de tecnología. Lo mejor siempre será, tomarse el tiempo para aprender todo en cada etapa, y luego avanzar al siguiente paso cuando se esté listo.
Tener un ¿por qué? muy pobre para querer implementar DevOps. Al igual que al hablar de agilidad en una organización, es muy importante tener un ¿por qué?, muy solido a la hora de hablar de DevOps. Dado que DevOps es una excelente manera de acelerar la formar en que TI puede asegurarse que cumple con las demandas de la empresa. Sin embargo, al querer implementar DevOps, este debe enfocarse en respaldar las necesidades de la organización. Tener claro el ¿por qué?, siempre ayuda a determinar la estrategia adecuada. Y una estrategia adecuada, ayudara a alentar a las partes interesadas a determinar el presupuesto, los recursos y los cambios que se necesitan.
No incluir a las personas de auditoria o de PMO. Muchas organizaciones consideran que DevOps es un tema exclusivo de TI, quizás porque en su acrónimo habla de Desarrollo y operaciones. Sin embargo, DevOps es una combinación de muchas partes interesadas. Ya que este es un proceso continuo de automatización y desarrollo de software que puede dar lugar a muchas áreas grises en temas de auditoria, cumplimiento de estándares de seguridad y/o normativos. Por lo cual es de suma importancia contar con personal de auditoria o de la PMO que entienda los procesos, evalué los controles e identifique los riesgos (esto no es un trabajo solo de este grupo de personas, debe ser de todas las personas que participan. Sin embargo, por su neutralidad, están llamados a brindar una mirada externa que aporta mucho valor). Es decir, la organización debe crear un sistema de pensamiento inclusivo, que haga que la implementación de DevOps no sea algo solo de TI, sino por el contrario que sea de contexto organizacional.
Determinar un plan de implementación prescriptivo y ser rígido con dicho plan. Al igual que en la agilidad, es más importante “responder al cambio sobre seguir el plan” sin que el plan no sea importante. Y he aquí en donde muchas organizaciones fallan en su implementación de DevOps. La rigidez con que se busca abordar DevOps en la organización termina creando puntos ciegos (como los que se presentan en una habilitación agile) que no permiten ver la situación real. Por eso es importante localizar el liderazgo adecuado dentro de la organización para dicho fin, es decir lideres que estén al servicio de la implementación de DevOps, no al contrario. Por otro lado, se debe gestionar el cambio de paradigma en la organización sobre como abordar las fallas o errores. Es decir, si en la compañía se castiga el error, las personas serán reacias a mostrarse abiertas a los cambios que requiere la implementación de DevOps. Fomentar la experimentación será clave en el proceso.
Sobre vender DevOps en la organización. DevOps no es una bala de plata que va a solucionar todos los problemas de cuello de botella que existen en la organización y/o las ineficiencias que existan en TI y/o en el proceso de desarrollo de soluciones. Aquí es crucial entender por parte de la organización, que entre mejor estén hechas las cosas antes del despliegue, mejores resultados se obtendrán. Otro punto importante es adoptar un enfoque que vaya proyecto por proyecto y no uno completo o Big Bang. Siempre es recomendable comenzar por proyectos valiosos, pero no de misión crítica. De esa manera la organización puede ver los beneficios claros de las practicas de DevOps, así de los posibles errores que se estén cometiendo, sin que sus procesos críticos se vean afectados. Así con el paso del tiempo y cuando el tema vaya madurando en la organización, se va llevando a procesos más críticos.
Como puedes ver mi querido amigo lector, son muchos los errores que se pueden cometer al querer implementar DevOps en una organización. Aquí solo mencioné los más comunes, sin llegar mencionar los técnicos, que representan otros desafíos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Habilitar la agilidad organizacional es sin duda un viaje que realiza la organización como un todo a lo largo de su existencia. Y es que, con el paso del tiempo, Las organizaciones han tenido que trabajar y autorregularse frente a cambios en el ecosistema (el mercado, los competidores, las condiciones, la tecnología, la economía). Este fenómeno se conoce como homeóstasis organizacional. Y es esa capacidad de respuesta que han mostrado las organizaciones a lo largo de la historia en mayor o menor nivel de adaptación, es la que hoy denominamos “agilidad”. Lo que refuerza el pensamiento que la agilidad es parte de las organizaciones. Ahora, en estos tiempos de V.U.C.A, donde el cambio en el ecosistema es más dinámico y veloz, requiere que las organizaciones tengan cada vez más un mayor nivel de agilidad. Es decir, que su capacidad de responder a los cambios sea a un ritmo casi que frenético.
Este viaje, requiere de una constante inspección y adaptación por parte de las organizaciones, con el fin de hacer los cambios necesarios que le permitan regular su comportamiento y su estructura según requiera la situación actual en la que se encuentre y la porvenir. Y así poder adecuarse a los cambios externos de la manera y tiempo más óptimamente posible. Como todo viaje, requiere un medio para ser llevado a cabo. Ese medio es la gestión del cambio; la cual como en todo vehículo hay que tener presente la existencia de los denominados “puntos ciegos”, los cuales de no ser tenidos en cuenta pueden complicar dicho viaje.
Los puntos ciegos (también conocidos como ángulos muertos) existen en los vehículos y obstaculizan el campo visual de los conductores y pueden provocar accidentes de tránsito. En los automóviles, por ejemplo, existen puntos ciegos provocados por los marcos del parabrisas delantero y trasero. Según los expertos, en la parte frontal del auto, los conductores tienen menos visibilidad en el lado izquierdo del parabrisas, debido a que el pilar (marco del parabrisas) de ese costado les está más próximo.
En el viaje de habilitación de la agilidad organizacional, dichos puntos ciegos pueden presentarse de diversas formas y en distintas etapas, por lo que representan todo un reto. No solo por su dificultad al momento de identificarlos, sino también de poder generar acciones que mitiguen su impacto a futuro.
Entre los distintos puntos ciegos tenemos:
La Implementación de Frameworks: Enfocarse solo en ello, es un punto ciego de los más comunes que se presentan. Dado que muchas organizaciones, consideran que la agilidad es una metodología o framework que se puede implementar. Por lo tanto, enfocan todo su esfuerzo en implementar roles y eventos, aprender prácticas e implementar artefactos. Dejando de lado la gestión del cambio de Mindset que se requiere para que dicha agilidad florezca de manera orgánica en la organización.
Las Métricas: Este punto ciego se presenta, porque las organizaciones no han podido entender el concepto del valor al que se refiere al hablar de agilidad. Por lo tanto, continúan midiendo alcance, tiempos y costos de manera fija, sin tener presente el valor generado, el costo del retraso, el costo del valor generado, el time to market, entre otras variables que se deben comenzar a llevar al momento de hablar de agilidad. en otros casos se centran en el registro mas no en el análisis de las mismas.
El Proyecto de implementación agile: Este punto ciego se presenta, cuando las organizaciones, ven la agilidad como algo que van a implementar y no como la capacidad que debe ser habilitada en toda la organización. Por lo tanto, crean un proyecto de implementación, el cual, al ser un proyecto, tiene un alcance, que por lo regular es solo el área de TI y tiene un tiempo fijo de duración definida, con lo que consideran que finalizado dicho tiempo ya serán una organización ágil. Nada mas alejado de la realidad.
La táctica: Este punto ciego se presenta, cuando en la organización todo lo referente a la agilidad se toca y se lleva solo en la parte táctica, mas no en la parte estratégica de la organización, como consecuencia se presenta la desconexión organizacional en su máximo esplendor. Dado que la forma en que se hacen las cosas y las cosas que se hacen no van conectadas con los objetivos estratégicos de la organización y en muchos casos tampoco con las necesidades reales de los clientes.
La implementación tecnológica: Este punto ciego se presenta, cuando en la organización se considera a la tecnología como el motor de la transformación. De hecho, se parte de la premisa la transformación digital como la adquisición y/o desarrollo de tecnología, tomando como objetivo la automatización de procesos y/o la venta de productos y servicios mediante plataformas digitales; sin comprender ni estar dispuestos a hacer la evolución cultural que se requiere.
Las estructuras virtuales: Este punto ciego se presenta, cuando en la organización se centran en crear equipos, salas, trenes, squads, etc. El llenar la organización de estas estructuras, sin la creación redárquica que estas estructuras requieren y mas aun sin la conexión con la jerarquía que se mantiene en la organización.
Agile TI: Este punto ciego se presenta, cuando la organización quiere habilitar la agilidad solo en TI. El solo hecho de plantearlo así, ya conlleva, ha que esta no sea habilitada. Dado que solo se implementaran prácticas, tecnologías y/o Frameworks en dicha área; incluso es probable que en ella se de el cambio de paradigma. Mas al no contemplar los cambios desde el negocio, tanto la propuesta de valor, como la generación y comercialización del mismo no será la idónea. Es por eso que el negocio en sí, debe evolucionar a la par de la tecnología y además, derribar el muro que los separa será la clave.
Cambio de paradigma en los equipos: Este punto ciego se presenta, cuando en la organización existe la idea, que solo deben de ser agiles los equipos. Es decir que solo las personas que hacen parte de ellos deben de cambiar su paradigma y adoptar el Mindset ágil. Y con ello cambiar su forma de pensar y de hacer las cosas; mas no en las capas jerárquicas mas altas de la organización. Por lo que se centra el esfuerzo en entrenar solo a las personas que van a hacer parte de dichos equipos mas no a la totalidad de la organización.
Estos mi querido amigo lector, son solo algunos de los tantos puntos ciegos que existen en un viaje de habilitación agile. Que como podrás ver, de no ser identificados a tiempo, harán que el viaje de habilitación agile sea más complejo de lo que de por sí ya es. Y quizás el resultado no sea el esperado. Por lo tanto, la correcta gestión del cambio será la piedra angular de una habilitación agile exitosa.
PD: homeóstasis: fenómeno en el que un sistema adaptativo complejo regula su comportamiento y estructura para adecuarse a cambio externos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
¿Y si dejamos de hacer Juegterapectivas y nos dedicamos a hacer Retrospectivas?
Hay una premisa universal en los negocios y esta es: «las organizaciones necesitan mejorar para mantenerse en el negocio y continuar entregando valor a sus clientes. Es decir, necesitan evolucionar, adaptándose a los diferentes cambios en el entorno en que se mueven y coexisten con otras organizaciones». Para esto las organizaciones a lo largo del tiempo han utilizado programas de mejora, que por lo general toman demasiado tiempo en su implementación y a menudo son ineficientes e ineficaces de cara al resultado esperado.
En este orden de ideas como decía Albert Einstein: “Locura es hacer la misma cosa una y otra vez esperando obtener diferentes resultados”. Lo cual también desafortunadamente es una premisa para muchas organizaciones. Que insisten en hacer los mismos tipos de planes de mejora, esperando mejorar algún día o peor aún, esperando mejorar al ritmo que se requiere en estos tiempos del VUCA.
Ahora bien, mi querido amigo lector, una de las cosas más
hermosa que tiene la agilidad, es esa invitación a realizar cada cierto
periodo de tiempo una pausa para la reflexión, el análisis y la definición
de nuevas pautas a seguir. Pautas que nos permitan mejorar lo que estamos
haciendo, el cómo lo estamos haciendo, la forma en como estamos interactuando
interna y externamente y como evolucionamos esa cultura que se esta forjando
día a día.
Para esto, el manifiesto ágil propone en su principio numero 12: “A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia”. Sin duda mi querido amigo una clara invitación a la búsqueda de la mejora continua, no a hacer retrospectivas, lo que son dos cosas totalmente diferentes. El problema actual en muchos equipos y organizaciones radica en que se enfocan en hacer lo segundo (retrospectivas), mas que en hacer lo primero (mejora continua).
La mejora continua o Kaizen (unión de las palabras japonesas 改(“kai”) que significa “cambio” y 善 (“zen”) que significa “bueno”). Realmente, Kaizen es una filosofía japonesa enfocada en que las mejoras hay que hacerlas constantemente, no cuando detectamos un error o un problema. Por lo que las mejoras hay que estar haciéndolas siempre. Además, las propuestas de mejora involucran a todos los participantes en una organización.
Ahora cuando hablamos de retrospectivas, etimológicamente hablando, el concepto nos remite a la lengua latina y a su vocablo retrospicĕre, que hace referencia a “observar hacia atrás”. Por lo tanto, es aquello que tiene en cuenta un trabajo que se realizó en el pasado.
Hago referencia a estas dos cosas mi querido amigo lector, porque los equipos agiles deben enfocarse principalmente en la mejora continua. Es decir, ser proactivos y no, en solo en hacer retrospectivas. Es decir reactivos. Para lo primero, hace unos meses escribí un post (Ver post Aquí), precisamente sobre lo que es la mejora continua. Y en esta ocasión, quiero que analicemos, un problema que presenta muchos equipos, y tiene que ver con las retrospectivas.
Como indique en el bloque anterior, las retrospectivas se usan para observar lo acontecido en el pasado, es decir, en términos agiles, para observar, analizar y reflexionar sobre lo que sucedió en el sprint que acaba de terminar; pero más importante aún sobre cómo debemos mejorar de cara a los sprint futuros.
He aquí mi querido amigo lector donde comienza el problema que te planteo analicemos en esta ocasión. Y es el hecho que se ha confundido el objetivo del espacio y en consecuencia se viene realizando lo que particularmente denomino Juegterapectivas, espacios en donde en vez de observar, analizar y reflexionar sobre lo que sucedió en el sprint que acaba de terminar; pero más importante aún sobre cómo debemos mejorar de cara a los sprint futuros. Se están haciendo espacios de juegos o esparcimientos lúdicos y/o terapias grupales de exposición de problemas y dolores, pero que no terminan en acciones concretas de mejora.
Entre las principales causas que he observado (y pueden existir más)
por las que se presenta este fenómeno están:
La utilización del espacio para la realización de juego y/o Icebreakers sin un objetivo. Lo que hace que en muchas ocasiones se pierda el objetivo del espacio, ya que se convierte en un espacio para jugar y divertirse y evitar precisamente hablar de los temas que más preocupan al equipo.
Falta de conocimiento y/o experiencia en facilitación de este tipo de espacios.
La no existencia de un objetivo claro a abordar en el espacio.
Falta de participación del Facilitador (Scrum Master/Agile Coach), al no involucrarse, con los búsqueda de los resultados esperados, termina asumiendo una posición de dominación de la situación y no asume las responsabilidad de apropiación de resolución de impedimentos.
La Participación de personal externo al equipo o al contexto actual. Si bien es cierto que deben de participar todos los que están involucrados en el proceso de generación de valor, hay que tener presente que no todos están de manera activa todo el tiempo participando del proceso, por lo que es importante saber identificar quienes si aportan valor al espacio y/o a la mejora buscada.
Foco puesto en los dolores y no en las oportunidades de mejora. Por lo que es muy común ver que el espacio los participantes presentan todos los problemas que aqueja el equipo, pero al final del espacio no se genera ninguna propuesta de acción de mejora.
Abordaje del espacio como una terapia de grupo emocional. Algunos facilitadores ven las retrospectivas (y hacen que el equipo también la vea) como el momento terapia, donde se habla de sentimientos y relaciones personales. Esto está bien, siempre y cuando sean problemas reales de los equipos y estos en ese momento, sean los aspectos más importantes para tratar y que hayan sido decididos por el equipo. La Psicología es genial cuando los verdaderos problemas son de relaciones humanas y como dice el refrán: “para un martillo todos son clavos”. Nuestra como facilitadores, es precisamente esa facilitar, no ser Psicólogos ni coach de personas (más si de equipos, cosa que es distinta). De nada sirve un equipo que se quiere, si la calidad del producto que desarrollan es pésima.
Tratamiento por parte del facilitador del espacio hacia las personas como niños. Como dice un refrán popular: “Si tratas a las personas como niños, se comportarán como niños”. Por lo que, si la única manera que tenemos de hablar de los problemas es a través de juegos y metáforas, ¿Cómo esperamos alcanzar soluciones adultas?
Preparación y desarrollo del espacio por una única persona. Este es un espacio de equipo no solo del facilitador.
Nota: En los puntos aquí expuestos he decidido colocar el término
“Facilitador”, para no herir susceptibilidades. Dado que muchos consideran que
este es su “momento de gloria”. Sin embargo, espero sea claro a quien me
refiero.
Cuando los equipos y las organizaciones caen en el fenómeno de las juegterapectivas, se puede observar que se frena su crecimiento, se hace mas evidente la agilidad cosmética y se vuelve (si es que se logró avanzar) a las antiguas practicas que no permiten adaptarse de manera adecuada y a la velocidad adecuada al entorno VUCA. Sin contar que roles como Scrum Master y Agile Coach, pierden credibilidad en la organización y se tiende a que sean visto como recreacionistas, humoristas, psicólogos frustrados, animadores de espacios y hasta secretarios muy bien remunerados. En casos como estos incluso, desafortunadamente se llega a la burla, en donde se desprestigia el alto valor que aportan estos roles en una organización. Aquí algunos ejemplos:
Para que esto no suceda, hay que tener claro, para que se hacen verdaderamente las retrospectivas y como se deben hacer. Pero sobre todo tener presente el poder que estas dan a los equipos. Dado que, cuando los integrantes se empoderan del espacio, conlleva a que exista más aceptación por parte de las personas a hacer las acciones que conducen a una menor resistencia a los cambios que se necesitan para aplicar las acciones de mejora que deben de salir de una retrospectiva. Ya que, al ser el mismo equipo el que consensua las acciones, termina empoderándose de ellas, por lo que no hay transferencia de acciones ni de decisiones, lo que permite que el mismo equipo tenga el control de estas.
Las retrospectivas proporcionan entonces una forma en que los
integrantes de un equipo se comprometen mediante la mejora en las cuatro
dimensiones de mejora (que hacemos, como lo hacemos, como interactuamos y la
cultura que estamos formando), en buscar acciones que den respuesta los
problemas que enfrentan. Ahora, para que una retrospectiva sea exitosa,
necesita varios elementos que deben estar presentes en ella. Tema que Norman Kerth en su libro Project Retrospectives, define cinco
requisitos importantes para una retrospectiva de éxito:
“La necesidad de un ritual”: Por lo general los seres humanos no se detienen a reflexionar durante la mayoría de los proyectos, dado que esto no es una actividad natural. Sin embargo, la definición del espacio como un ritual, permite la formalización de dicho comportamiento, ya que los rituales unen a las personas y les permite centrarse en lo importante. En este punto son importantes dos cosas, la primera que el espacio no debe enfocarse en las cosas negativas y segundo, es que todas las personas involucradas en el proyecto deben estar involucradas en la retrospectiva, dado el enorme potencial de aprendizaje y de mejora que esta ofrece.
“Nombrar o definir el espacio”: Lo que se busca es el entendimiento claro por parte de todas las personas sobre lo que es, el objetivo que se busca, el como se hace, cuales son los inputs, los outputs y la forma de seguimiento a dichos outputs.
“El Factor Seguridad”: las personas deben sentirse lo suficientemente cómodas, es decir en un espacio de seguro y tranquilo, para compartir sus problemas, sus opiniones, sus preocupaciones, sus aportes, sin que estos sean juzgados. Norman, por ejemplo, plantea que antes de iniciar una retrospectiva, deberíamos comunicar una directriz principal como por ejemplo: “Independientemente de lo que descubramos, debemos entender y creer de verdad, que todos hacen el mejor trabajo que él o ella podría hacer, dado lo que se sabía en ese momento, sus habilidades y capacidades, los recursos disponibles y la situación actual”.
“El lado más oscuro”: Representa el espacio a evitar o caer, ese espacio que se convierte en una especie de sesión de quejas y/o acusaciones entre los integrantes del equipo. Por lo cual hay que entender que las personas no se quejan con malas intenciones, simplemente exteriorizas lo que les afecta. El problema llega cuando el receptor se deja intimidar por la denuncia o queja e inmediatamente entra en modo defensivo y contraataca, lo que conlleva a una retrospectiva no productiva. En este sentido es importante que las personas expresen sus pensamientos como deseos en lugar de acusaciones, ya que esto cambia el tono de voz y crea así un entorno seguro, lo que es vital para el éxito de una retrospectiva.
“El facilitador del espacio”: En lo personal, siempre he pensado que, sin un buen facilitador, una retrospectiva será un desastre. Por lo cual considero sumamente importante que el espacio cuente con un buen facilitador, dado que cada retrospectiva aborda diferentes tipos de problemas, por lo que identificar y aplicar las actividades y/o ejercicios adecuados ayudara a resolverlos de la mejor manera y que al final la retrospectiva aporte valor de negocio. Es decir que identifique las cosas mas importantes que un equipo requiere mejorar y aplique acciones para que dicha mejora se dé.
Por último, en el libro Agile
Retrospective, de Esther Derby y
Diana Larsen, se describen las actividades mínimas que debería tener una
retrospectiva:
Preparar el escenario
Recopilar datos
Generar percepción sobre los hechos (reflexionar)
Decidir qué hacer
Cerrar la retrospectiva.
Como escribí en el párrafo anterior, es importante identificar y aplicar las actividades y/o ejercicios adecuados para cada uno de los puntos propuestos por Esther Derby y Diana Larsen, para así realizar una retrospectiva exitosa y no una juegterapectiva.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
¿Y si en vez de hacer Transformaciones Ágiles, mejor Evolucionamos Organizacionalmente?
Desde hace varios años ya, venimos escuchando en el argot popular y organizacional (sin contar con todo lo que actualmente se puede leer al respecto), términos como “transformación digital”, “transformación cultural” y “transformación ágil” como si las personas y las organizaciones, tuviesen que convertirse en otra cosa, en lugar de adaptarse a su entorno. No será más bien, mi querido amigo lector, qué tenemos tantas ganas de cambiar que ¿cualquier alternativa nos sirve? Me pregunto y te pregunto mi querido amigo ¿Conoces a muchas empresas que se estén transformando? ¿No será que lo que están haciendo es adaptarse a su entorno?
Mi querido amigo lector, hay una sensible diferencia entre transformarse
y adaptarse. Casi la misma que hay entre Evolución y Revolución. Y todo estos términos
para mostrarte un poco al punto al que quiero llegar.
En una evolución no perdemos el contacto con el pasado, sino que
paulatinamente vamos abandonando la situación de partida, mientras nos
proyectamos de forma proporcional hacia el futuro. Si nos basamos en la teoría
de la evolución de Darwin, vemos que ella, se basa en la adaptación de las
especies a los cambios que se producen en su entorno. Así, se garantiza su
supervivencia gracias a las adaptaciones que se producen generación tras
generación y que convierten a los individuos de las últimas ramas del árbol
genealógico, en los mejor preparados para competir con el entorno, las otras
especies animales y preservar su continuidad en el tiempo. La transformación,
por otra parte, y según el significado del Diccionario de la Real Academia
Española, hace referencia a “acción y efecto de transformar, es decir, hacer cambiar
de forma a alguien o algo”. Podríamos concluir, por lo tanto, que la
transformación es el medio por el que se consigue la evolución.
Si trasladamos este concepto al mundo empresarial en nuestro mundo contemporáneo, notamos que existe mucha confusión en relación con el elemento esencial para garantizar la supervivencia de una especie (una organización) en el entorno cambiante y amenazante de la realidad actual. Por lo que te pregunto mi querido amigo ¿Qué crees tú, que escogería Darwin hoy en día, evolución o transformación?
El curso natural, es la evolución. Las revoluciones nos sirven para cambiar el curso de la evolución. En ambos casos, evolución y revolución, tratan de proyectarse al futuro, de escribirlo, pues el futuro es la consecuencia de lo que vamos haciendo, viviendo y diciendo. Por otro lado, la transformación no deja de ser un paso, un medio para conseguir un fin. La evolución, en este caso.
La mayoría de las veces, cuando hablamos de evolución organizacional, no hablamos de transformación, hablamos de adaptación. Las organizaciones, al igual que todos los seres vivos viven en un proceso continuo de cambios y están obligadas de forma natural a adaptarse al entorno si quieren permanecer en él, si quieren subsistir.
Podríamos decir que la adaptabilidad es la capacidad de cambiar
para poder seguir progresando en un entorno distinto, por lo que no debemos
hablar de transformación ágil ni mucho menos de implementar la agilidad, esto
lo digo porque, implementar
algo significa colocarlo en marcha, ejecutarlo. Por lo tanto, parte de la
premisa que ese algo que se va a colocar a funcionar no existía, pero que a
partir del momento de su implementación va a existir.
Y
es aquí donde comienza mi punto de vista, del hecho que la Agilidad no se
implementa, sino que se habilita. dado que la Agilidad es una capacidad (de
generar valor, de responder al cambio, de inspeccionar y adaptarse, de tener
siempre una visión sistémica, de mejorar) y la capacidad es una cualidad de
hacer algo y la cualidad es algo que representa el modo de ser propio de algo, por
lo que es cada una de las características que definen y distinguen algo.
Entonces podemos decir que a Agilidad es también una cualidad. Si llevamos esto
al contexto organizacional, la agilidad es algo que ya existe en las organizaciones.
Dado que su modo ser y hacer las cosas, para adaptarse a los constantes cambios
que requiere una organización para ser competitiva definirá que tan ágil es. Y
es aquí donde notamos la naturaleza del cambio y adaptación constante que exige
la agilidad.
Habilitar
algo implica, hacer los cambios necesarios para que una persona o una cosa,
especialmente un lugar, sirva para una función que no es la que desempeña
habitualmente, es decir hacerlo capaz o idóneo de hacer algo. De tal modo que regula
su comportamiento y estructura para adecuarse a los cambios externos. Ahora
bien, colocando esto en un contexto empresarial, vemos como con el paso del
tiempo, Las organizaciones han tenido que trabajar y autorregularse frente a
cambios en el ecosistema, en su entorno.
Como
decía Darwin, “no es la más fuerte de las especies la que sobrevive y tampoco
la más inteligente. Sobrevive aquella que más se adapta al cambio. En la larga
historia de la humanidad (incluso de la especie animal), son aquellos que
aprenden a colaborar y a improvisar los que más probabilidad de prevalecer
tendrán.”
¿Y entonces por qué todo el mundo habla ahora de “transformación digital”, “transformación cultural” y “transformación ágil”? o de ¿transformación cultural? Quizás porque el instinto humano nos impulsa a rechazar aquello que no funciona y substituirlo por algo nuevo. Lo cierto es que, lo que necesitamos las personas y las organizaciones, no es transformarnos, sino adaptarnos de forma ágil al entorno.
Una de
las metáforas que me llamo mucho la atención, para explicar la adaptabilidad,
es la que usa Bruce Lee, en la serie de televisión “Longstreet” (una serie de
drama criminal estadounidense que se transmitió por ABC en la temporada
1971-1972. Fue una película piloto de 90 minutos del mismo nombre emitida antes
del debut de la serie como ABC Movie of the Week. En ella apareció Bruce Lee, en
cuatro episodios como Li Tsung, un vendedor de antigüedades y experto en Jeet
Kune Do que se convierte en instructor de artes marciales de Longstreet. En uno
de los capítulos expresa lo veras en el video)
MI querido amigo lector, los grandes cambios en las personas y en las organizaciones requieren de tiempo. Sin embargo, los seres humanos queremos transformarlo todo cuanto antes. Ahora, hay muchas cosas que lo que necesitan no es una transformación, sino una adaptación adecuada al entorno y eso es más fácil y en muchas ocasiones más efectivo. Como decía Heráclito, lo único constante es el cambio. Y éste vendrá cada vez más rápido, nos guste o no. Podemos anticiparnos y liderarlo, o dejar que venga y tener que gestionarlo.
Por lo
tanto, mi querido amigo lector, ¿Y si en vez de hacer Transformaciones Agiles,
mejor Evolucionamos Organizacionalmente?, Dado que las Transformaciones se dan
porque las cosas no se están haciendo bien, por lo que requerimos hacer las
mismas tareas de manera distinta. Mientras que, en la Evolución, es dar un paso
hacia adelante, dado que ya realizamos bien lo que hasta ahora hacemos, pero no
es suficiente, ya que el contexto complejo nos exige más.
Pd: Un ejemplo final
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Una de las tantas cosas que me han llamado la atención en los últimos
años, en los cuales he tenido la oportunidad de acompañar diferentes
organizaciones en sus viajes de habilitación de la agilidad organizacional, es
la forma en como muchos equipos realizan casi de manera similar la famosa Daily
Meeting. Y digo que me llama la atención, porque en términos generales siguen
la misma regla, de levantarse durante 15 (o mas minutos) y responder las típicas
3 preguntas:
¿Qué hice ayer?
¿Qué voy a hacer hoy?
¿Qué impedimentos tengo?
Dando paso a lo que un colega un día denomino, la “ Daily Zombi”, ese estado mórbido de monotonía en el que entran los equipos, después de un periodo de tiempo de estar haciendo lo mismo todos los días, respondiendo las mismas preguntas y que al final terminan llegando en muchos casos a “abusar”, de dicho espacio, que de ser bien utilizado nos brinda grandes beneficios.
Entre los abusos o errores que comenten muchos equipos al momento de hacer la Daily son:
Usar la Daily como una reunión de seguimiento de estado diaria
El Scrum Master u otro miembro que no sea miembro del Equipo de Desarrollo entrevista (o interroga) a cada persona sobre el estado de su trabajo.
la Daily dura 30 minutos o más.
La reunión avanza lentamente porque los integrantes del equipo están desconectados o distraídos mientras el Scrum Master actualiza las tareas en el Kanban Board.
Usar la reunión para reforzar las posiciones de poder y decirle a la gente qué hacer.
Los miembros del equipo están desconectados y no se escuchan.
Los miembros del equipo hablan sobre tareas que no se están haciendo o temas que no tienen nada que ver con el objetivo del sprint
Los impedimentos no se discuten o no se mencionan y el Scrum Master u otros no los abordan.
Los miembros del equipo de desarrollo van de una Daily a otra para informar sobre las tareas que han/no han realizado.
El Scrum Master toma notas durante la reunión y las publica como actas de la reunión.
La reunión se retrasa hasta que llega un Scrum Master, PO o gerente, o peor aún, el equipo se ve obligado a reiniciar la reunión porque el PO o gerente llegó tarde.
Nadie en la reunión se enfoca en los objetivos del equipo para el sprint o cómo se están adaptando para lograr esos objetivos.
De seguro mi querido amigo lector, habrás identificado alguna(s) de las aquí expuestas o quizás alguna(s) no escritas. Como por ejemplo las que se presentan cuando tenemos Scrum Master que son Gerentes de proyectos (si, eso existe en muchos lados y ojo , este no es un post de terror, dado que el Halloween ya paso).
En todo caso mi querido amigo lector, estos errores o abusos se
presentan por varias razones entre las que están:
Falta de conocimiento y experiencia en facilitación por parte del Scrum Master (y en algunos casos hasta por parte de Agile Coach. Repito, eso también existe en muchos lados)
El equipo no está entrenado adecuadamente.
La organización es AINO (es decir, Ágil solo de nombre). Las personas aún hacen lo que siempre han hecho, solo que ahora dicen que son parte de equipos agiles, porque ahora usan los términos de Scrum y agile para ello.
Falta de entendimiento del marco de trabajo.
Lo abierta que es la definición del Daily en la Guía Oficial de Scrum.
Veamos este ultimo punto. La Guía oficial de Scrum nos dice que:
“El Scrum Diario (Daily Meeting), es una reunión con un bloque de tiempo de 15
minutos para que el Equipo de Desarrollo sincronice sus actividades y cree un
plan para las siguientes 24 horas. Esto se lleva a cabo inspeccionando el
trabajo avanzado desde el último Scrum Diario y haciendo una proyección acerca
del trabajo que podría completarse antes del siguiente. El Scrum Diario se
realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.
Durante la reunión, cada miembro del Equipo de Desarrollo explica:
¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?
El Equipo de Desarrollo usa el Scrum Diario para evaluar el
progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este
progreso hacia la finalización del trabajo contenido en la Lista del Sprint”.
En mi criterio personal, dicha definición la considero:
Un poco excluyente: Siempre habla del equipo de desarrollo y no invita a la participación de todas las personas que de una u otra forma participan de la creación de la solución sin ser necesariamente parte del equipo de desarrollo, por ejemplo: arquitectos, representantes de otros equipos, etc.
Promueve la monotonía: Nos indica que esta debe realizarse a la misma hora y en el mismo lugar todos los días y que se deben de responder las mismas tres preguntas.
Quizás por eso, tantos malentendidos con respecto al evento. Sin
embargo, mi querido amigo lector en la misma definición están las pautas
correctas de lo que es una Daily. Dado que ahí se nos indica: el objetivo de esta,
para que se realiza y como se debe realizar.
Objetivo: Sincronizar actividades y crear un plan para las siguientes 24 horas.
Como: Inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una proyección acerca del trabajo que podría completarse antes del siguiente.
Para: Evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Lista del Sprint.
Teniendo entonces claro que el objetivo es “sincronizar actividades y crear un plan para las siguientes 24 horas”, veamos entonces el valor que genera cumplir con el objetivo planteado.
La palabra Sincronización viene del griego syn (unido) y chronos (tiempo), por lo que hace referencia a la habilidad de ajustar en el tiempo determinadas acciones, sucesos, o para el tratamiento de la información a través de la sincronización. La sincronización de la información sería el ajuste de esta, a lo largo del tiempo. Los equipos de alto desempeño (o Equipos Agiles, dado que estos son llamados a ser Equipos de alto desempeño), deben ser capaces de desarrollar una conciencia colectiva que les permite detectar en qué momento necesitan de esa sincronización y qué información deben dar para alinearse.
La dirección de la información no tiene por qué ser siempre la
misma, a veces será necesario únicamente la sincronización de dos personas por
separado, otras veces del equipo al completo, y otras de un equipo con otros
equipos. Por lo que la sincronización provee la posibilidad de la generación de
objetivos y la validación de estos.
En la práctica, deberían existir diferentes niveles de sincronización
para el buen funcionamiento de las organizaciones. Todo comenzaría con la
sincronización con uno mismo, donde tomaríamos conciencia de lo que ocurre
dentro de nosotros y de cómo percibimos lo que ha ocurrido a nuestro alrededor,
desde ahí, a través de la comunicación ajustaríamos nuestras expectativas con
otros para poder alcanzar objetivos que no podemos alcanzar por nosotros
mismos. Por último, los equipos podrían sincronizarse con otros equipos a
través de sus miembros o de representantes que fueran alineando la información.
La información que se aporte a la hora de sincronizar debe ser
de máximo valor, considerando que la de mayor valor, es la que se encuentra más
cercana a los individuos que realizan las tareas, debido a que sin ella no se
puede construir la restante. De ahí la importancia de tener una buena
comunicación y generar entornos donde las personas puedan hablar libremente
sobre su realidad, siendo los modelos tradicionales y las personas que los
siguen auténticos motores de desincronización y ocultación de información de
valor. En esos modelos tradicionales, la información termina siendo ficticia y
más alejada de lo que verdaderamente está ocurriendo, castigando el error y no
potenciando el aprendizaje continuo.
En los equipos de alto desempeño (o equipos agiles), está
siempre presente la sincronización, e intentan potenciar la calidad de la
información que fluye y el manejo que le dan a esta. Realizan estos espacios
diariamente, para sincronizarse, por lo general lo hacen a primera hora de la
mañana y potenciar así el alineamiento hacia objetivos diarios.
Ahora, no olvidemos que un equipo alcanza el nivel de alto desempeño, cuando el poder de la conciencia colectiva sincronizada con la conciencia individual de cada uno de los miembros del equipo activa las necesidades de sincronización más allá de cualquier estructura prefijada.
Mi querido amigo lector, mi invitación final será entonces el titulo de este post: ¿Y si dejamos de hacer Daily Zombi? Y nos dedicamos mejor a sincronizarnos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Este fin de semana, tuve la oportunidad de participar en un webinar al
que fui amablemente invitado por un gran amigo, en donde se hablaba de la
importancia del rol del Product Owner y el impacto que este genera, cuando adopta
el Mindset ágil, pero además cuando tiene conocimiento y claridad en el uso de técnicas
y herramientas de gestión del “Product Backlog”. Por lo que, después de
escuchar a los participantes del espacio y recordando un poco lo que me he
venido encontrando en los últimos años en los diferentes espacios en los que he
participado y en las organizaciones a las que he estado acompañando, nació la
idea de escribir este post.
Mi querido amigo lector, haciendo uso de los siguientes principios agiles, quiero exponerte mi conclusión a la pregunta que realizo en el título de este post.
Los responsables del negocio y los desarrolladores trabajan juntos.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad es esencial.
Los equipos autoorganizados generan mejores arquitecturas, requisitos y diseños.
El equipo tiene que reflexionar sobre cómo ser más efectivo para ajustar su comportamiento y su trabajo
Los principios agiles (junto con los valores), representan la
base de lo que conocemos como agilidad, por lo que su entendimiento y correcta
aplicabilidad, nos permiten habilitar la agilidad a nivel organizacional.
El concepto de “Product Backlog” surgió en la industria del “software”. Ahora, la expresión Product Backlog (si la traducimos literalmente) significa Pila de producto, sin embargo, algunas de las definiciones más usadas son:
“Listado ordenado y priorizado de los requisitos necesarios para la implementación de un proyecto”
“Es una lista de Historias de Usuario, ordenadas según el valor de negocio que establece el Dueño del Producto, y que trata de cubrir todas las funcionalidades necesarias para desarrollar un producto”
“Lista ordenada de todo el trabajo pendiente”
“Lista de necesidades que han sido priorizadas, y contiene descripciones breves sobre todo lo que se desea para el producto que se va a desarrollar”
De seguro mi querido amigo lector, has escuchado mas definiciones de las aquí expuestas o quizás tengas tu propia definición. Para lo cual te invito a que analicemos el hecho que con el tiempo el concepto de “Product Backlog”, se ha ido aplicando también al desarrollo de productos y servicios de todo tipo. Lo que nos deja en la paradoja, que ya no estamos hablando solo de producto, y mas si nos vamos a los principios agiles, nos invita a ver que dicho “Product Backlog”, debe contener ítems que sean no solo del producto (Historias de Usuario Funcionales – Aquí se deben incluir incluso las Épicas y Features) sino también de otros factores que son:
Habilitadores tanto Técnicos como Exploratorios.
Deuda Técnica.
Mejoramiento Técnico Continuo.
Mejora continua de las cuatro dimensiones: del producto, del proceso, de la forma en que se interactúa (tanto interna como externamente) y de la cultura que se está formando.
Bugs identificados a resolver.
Razón por la cual, considero que mas que hablar de “Product Backlog”,
deberíamos hablar simplemente de Backlog, dado que este debe contener
mas que solo historias de usuario funcionales que hacen referente a un
producto, sino que además debe tener como mínimo los ítems anteriormente
expuestos.
La gestión por lo tanto del Backlog invita en definitiva también
a un equipo mas comprometido, dado que ahora son mas roles/personas que
participan (como debe ser) en su creación. Así como también requiere de un Producto
Owner mas estratégico, ya que deberá tener clara la visión y la estrategia a
seguir, para saber cómo divide la “torta”, según la capacidad del equipo;
teniendo en cuenta que se debe por ejemplo pagar la deuda técnica, estar
pensando a futuro como mejorar técnicamente la solución e incluso como fomentar
la mejora continua de los equipos.
Esto mi querido amigo lector va entre otras cosas, con la propuesta que nos hace Mike Cohn, acerca de tener presente cuatros principios básicos (Acrónimo DEEP) a la hora de construir un Backlog:
Detailed appropriately (Detallado apropiadamente)
Emergent (Emergente)
Estimated (Estimado)
Prioritized (Priorizado)
Todos estos ítems del Backlog, por lo tanto, deben ser
identificados, gestionados y estimados, llevados a la mesa el día de la planificación
y tenerlos presente en el refinamiento. Para así lograr tener una visión compartida
del trabajo a realizar.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Explorando Métricas y el valor que estas aportan en una habilitación Agile – Parte V
Showing business and magnifying glass
Hora del quinto y último paso en este viaje de exploración de métricas y el valor que estas aportan en una habilitación agile. En esta ocasión, estaremos explorando las métricas referentes a los equipos, desde distintas perspectivas. Con el fin de tener diferentes ángulos, por analizar y así poder tener mas herramientas para mejorar.
Parte V – Métricas de Equipos Ágiles
Hablar de equipos agiles y dado que su naturaleza es la entrega de
valor, la inspección y adaptación, el trabajo colaborativo y la mejora continua.
Están llamados a conseguir grandes resultados. Ya que sus características son:
La orientación a la Generación de Valor, Tienen un Objetivo Común, Tienen un
compromiso Conjunto, son Autoorganizados, Autogestionados, Multidisciplinarios,
Cross-Funcionales y Creativos, Gestionan su conocimiento, Y sobre todo están orientados
a la Mejora Continua. Dichas características, hacen de ellos un pilar
fundamental (sin duda en una organización existen más) en la transformación de
Necesidades, en ideas, ideas en iniciativas, iniciativas en soluciones,
soluciones que generan valor al cliente y garantizan un buen retorno de la
inversión a la organización.
Ahora bien, al hablar de métricas agiles, hay que ver el tema desde
distintos ángulos, ya que estos (los equipos agiles), viven en constante evolución,
en constante crecimiento. Por ende, veamos un poco desde distintas perspectivas
las métricas con que estos cuentan, para mejorar lo que hacen, el como lo
hacen, la forma en que evolucionan e interactúan y la cultura propiamente que están
construyendo.
Veamos entonces que tipo de métricas hay y cuales son:
Aspectos Humanos
Este grupo de métricas revelan los problemas que afectan el lugar sostenible y el nivel de compromiso de un equipo.
Índice de Felicidad: Crea transparencia con respecto a la satisfacción de los miembros del equipo.
Barómetro de Equipo: Ayuda a un equipo de trabajo a elevar su nivel de conciencia como tal y evaluarse frente a características de los Equipos de Alto Rendimiento.
Nivel de Mejor Continua: Permite determinar el nivel de crecimiento profesional de cada integrante del equipo y del equipo como un todo.
Nivel de Gestión de Skill: Permite determinar el nivel de gestión de los Skill técnicos y blandos de las personas y del equipo.
Índice de Motivación del Equipo: Permite determinar el nivel de notificación del equipo y de cada uno de sus integrantes con respecto al trabajo que realiza.
Índice de Conexión con la Visión: Permite determinar qué tan conectado está el equipo y cada uno de sus integrantes con la visión de la organización y con la visión del trabajo a realizar.
Índice de Delegación: Permite determinar el nivel de delegación existente en el equipo con respecto a las decisiones que este debe de tomar.
Métricas de Gestión del Riesgo
“El objetivo es detectar y controlar
posibles situaciones adversas, por un lado, identificando y gestionando
situaciones inesperadas que no se hayan previsto, ante las cuales no tenemos
una respuesta. Por otro lado, evaluando la probabilidad de que sucedan
situaciones perjudiciales, y finalmente dando una respuesta correcta y
consensuada a los problemas que se presenten.”
De estas existen 2 categorías que son:
Métricas Predictivas: Se obtienen a partir de cálculos con los datos actuales del proyecto/iniciativa. El objetivo es que las medidas obtenidas por estas métricas se aproximen el máximo posible a las especificaciones y a la planificación inicial.
Aggregated Schedule risk: Duración total del proyecto (si se utilizasen todos los planes de contingencia o alternativas previstas en caso de que se produzca un riesgo), por la probabilidad de suceso del riesgo.
Burndown de Riesgo: Mide la cantidad de riesgo conocido y no mitigado que se muestra a lo largo de un período de tiempo.
Mapa de Dependencias: Mide la identificación y gestión de las dependencias presentadas.
ROAM Metric: Mide la identificación y gestión de los riesgos presentados.
Métricas de Diagnostico:
Las métricas de diagnóstico se basan
en las mediciones realizadas a lo largo del proyecto, se usan para detectar las
variaciones adversas que se han dado en el proyecto, para poder solucionar
estos problemas tan pronto como sea posible, una vez detectado.
Se utiliza el concepto de “Earned Value
Analysis” (EVA), esta técnica para el control del proyecto comienza con la
asignación de la parte del presupuesto para cada una de las Hito planificado.
La suma total ha de ser el 100% del presupuesto total. Mientras el proyecto se
ejecuta se recolectan los datos para cada tarea completada y se establece una
proporción con la situación planificada. Aunque se van a explicar respecto al
coste, se puede aplicar también al tiempo de duración del proyecto.
Earned Value (EV): La acumulación de todos los costes que se han planificado de los Hitos del proyecto que se han completado.
Actual Cost (AC): La acumulación de los costes reales de todos los Hitos que se han planificado.
Planned Value (PV): La acumulación de los costes planificados de cada Hito del proyecto que se espera finalizar en el plazo de tiempo previsto (para proyectos de Tiempo fijo). Aunque la explicación pueda parecer complicada, se refiere a una función o gráfica del coste que se espera tenga cada Hito en un tiempo en concreto a lo largo del proyecto.
Cost Performance Index: La proporción entre el EV y el AC, es el ratio principal utilizado en EVA, cuando es mayor que uno se está gastando más dinero del estimado en la planificación.
Schedule Performance Index (SPI): Es la proporción entre EV y PV, si es menor que uno nos indica que se está retrasando los Hitos, si es mayor que un indica lo contrario, que se están adelantando.
Cost variance (CV): Es la diferencia entre EV y AC. Se puede obtener una proporción de la diferencia respecto la planificación dividiendo CV entre EV.
Schedule Variance (SV): Diferencia entre EV y PV, al igual que antes podemos obtener una proporción al dividir está diferencia entre EV.
Risk Closure Index: La proporción de riesgos cerrados, o superados, con proporción a los riesgos contemplados para el proyecto.
Ahora bien, los Equipos Ágiles, también pueden medir dos tipos de riesgo adicional que son:
El Riesgo Inherente: Es el riesgo existente ante la ausencia de alguna acción que la dirección pueda tomar para alterar tanto la probabilidad o el impacto de este.
RIESGO INHERENTE= PROBABILIDAD inh * IMPACTO inh (Impacto Inh: impacto de un evento, sin considerar las acciones y controles mitigantes) ( Probabilidad Inh: probabilidad de ocurrencia de evento no deseado sin considerar las acciones y controles mitigantes )
El Riesgo Residual: Es el riesgo que persiste luego de la respuesta de la Dirección al Riesgo.
RIESGO RESIDUAL = RIESGO INHERENTE –
EFECTIVIDAD DE CONTROLES
o RIESGO RESIDUAL = PROBABILIDAD res * IMPACTO res
Métricas de desarrollo de productos
“Ayudan a medir la alineación de las características del producto con las necesidades del usuario”.
Valor entregado al Cliente/Negocio: Es la cantidad de valor entregado. Tanto en número de entregas como en valor real generado.
Tipo de valor entregado: Es la identificación del tipo de valor que se ha entregado en un periodo de tiempo.
Pronóstico del producto: Establece tendencias futuras, basadas en el rendimiento histórico de ítems completados.
Net Promoter Score (NPS) del producto: NPS se usa para medir la respuesta a la pregunta: ¿Recomendaría este producto?
Analítica de usuario: Identifica patrones de uso dentro del producto.
Métricas de Release (lanzamiento)
“Dirigen su enfoque hacia la identificación de impedimentos para el delivery continuo”.
Defectos evadidos: Un recuento de defectos que se descubren en la producción.
Tiempo de resolución de defectos evadidos: Mide la cantidad de tiempo requerido para resolver un defecto evadido.
Promedio de éxito de los releases: Es el promedio de releases aceptados y rechazados por el cliente.
Tiempo de release: Muestra la cantidad de tiempo requerida para realizar el release de un producto al entorno de producción.
Tiempo desde el último release: Esta métrica muestra la cantidad de tiempo transcurrido desde la última vez que el equipo realizó el release de su producto a los usuarios finales.
Costo por lanzamiento: Es el costo de completar un release.
Release Net Promoter Score: ¿Los equipos están «diseñando e implementando rápidamente una excelente experiencia para el cliente, una y otra vez en el tiempo»?
Adopción del release/ promedio de instalación: Mide el número de usuarios existentes que han realizado una actualización; número de nuevos usuarios obtenidos por el release.
Métricas de la salud del proceso
“Esta categoría evalúa las actividades diarias del equipo de delivery (entrega), y evalúa los cambios del proceso”.
Diagramas de flujo acumulativo: Permiten observar los Lead times, cicle time y el Trabajo en progreso (WIP) en las diferentes etapas mientras se va logrando el “Done”.
Porcentaje de Completo y Exacto: Mide el número de ítems completados y aceptables (de calidad) para ayudar al equipo en mejorar el delivery.
Eficiencia de flujo: Realiza un seguimiento de la relación existente entre el Tiempo dedicado a trabajar en un ítem y el Tiempo que espera el ítem.
Tiempo de bloqueo por ítem: Mide la cantidad de tiempo que un ítem estuvo bloqueado mientras se lo completaba.
Agrupación de bloqueadores: Muestra la agrupación y frecuencia de ítems bloqueadores.
Push/Pull: Es el ratio entre la cantidad de ítems completados y los nuevos items agregados.
Métricas de código
“Ayudan a determinar la calidad de la implementación y la arquitectura”.
Cobertura de pruebas: Monitorea el porcentaje de código que ha sido revisado por varios tipos de pruebas automatizadas.
Time Build: Mide el tiempo de compilación y ejecución de pruebas para proporcionar feedback al equipo de desarrollo.
Densidad del defecto: Rastrea el porcentaje de defectos en cada área del sistema, determinado por la funcionalidad o la arquitectura del código.
Cumplimiento de estándares de codificación: Este es un puntaje de evaluación de alineación del código con los estándares de arquitectura.
Promedio de Crash: Es un registro de incidentes que provocan el bloqueo de una aplicación/producto.
Métricas de Madurez
“Permiten determinar el nivel de madurez (evolución) de los diferentes roles y de los equipos”
Escala de Madurez de Product Owner
Escala de Madurez del Scrum Master
Escala de Madurez de Product Manager
Escala de Madurez de Arquitectos y líderes de Tecnología
Escala de Madurez del Equipo
Escala de madurez de escalamiento de equipos:
Sin duda podrán existir más. Sin embargo, siempre el mensaje es como el famoso
libro de John Doerr “Mide lo que importa”. O dicho de otra manera mide lo que
te genera valor en el momento especifico en el que te encuentres.
Espero mi querido amigo lector, que este viaje de exploración de métricas haya sido de valor para ti, tanto como lo ha sido para mi no solo al escribirlo, sino también al descubrir y colocar en practica las diferentes métricas que he ido identificando con el paso del tiempo que llevo en este hermoso mundo Agile.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
