Cherry Picking, en inglés significa, literalmente, «elección de cerezas», la frase, según el contexto, tiene diferentes significados, tradicionalmente viene a ser presentar algo que es falso como cierto, argumentándose en una selección de datos que nos interesan, dejando los datos que no nos interesan fuera de la argumentación. En otros contextos, como el del post de hoy, Cherry Picking es elegir de entre un grupo amplio de elementos (prácticas ágiles) aquellos que más nos interesan.
Lo que te quería contar en este post es que después de muchos años, muchas batallas y muchas implantaciones ágiles, creo que el único método para lograr eso que ahora llamamos transformación ágil (de la que muchos hablan y pocos logran realmente) que he visto repetirse con éxito es… que no se siguió ningún método. Es decir, que no hubo un paso uno, un paso dos, etc., que siempre se siguieran y cumplieran de la misma manera en dos sitios que lo lograron.
Más que un método de implantación de la agilidad (que hasta podría decir que ya dicho así, «método», «plan», suena poco ágil) en los éxitos que yo he vivido hubo un Cherry Picking de prácticas ágiles.
De entre las decenas de prácticas que consideramos ágiles, en los sitios que yo he visto que han hecho una transformación ágil decente, hubo Cherry Picking: constantemente se iban seleccionando prácticas ágiles, algunas se acabaron rechazando y otras adaptando, y no he visto en dos sitios exactamente las mismas prácticas y de la misma manera. Y esa selección y adaptación nunca nadie la podría haber prescrito al inicio de la transformación ágil.
Aún hoy me encuentro con gente que intenta tomar un «framework» ágil y seguirlo al pie de la letra, hasta he visto Powerpoints con diagramas de Gantt que contaban cómo serían los pasos de esa supuesta implantación ágil, con sus fechas y con las prácticas de las que hacer uso. Mala idea esa de implantar una cultura, la ágil, que se fundamenta, entre otros, en que el cambio es bienvenido y en la adaptación, con un plan predictivo a seguir al pie de la letra.
Mi consejo cuando quieras «planificar» una implantación ágil, para aquellos sitios que quieran escalar la agilidad, también en sitios más pequeños, es que la propia implantación sea ágil, y que no se case con ningún método, sólo con los valores ágiles. Que no se case con SAFe, Scrum, XP, LeSS, Spotify o el que sea, y que a su vez hagas un Cherry Picking de las prácticas que te interesen de cada uno de ellos, pocas, muchas o ninguna. Selección, prueba y adaptación o rechazo, de manera constante, de prácticas ágiles.
Y eso de la adaptación y selección constante de prácticas aplica no sólo a conocidos frameworks… aplica a cualquier práctica. Raro es, por ejemplo, que dos grupos utilicen la misma manera de medir la velocidad, incluso habrá quien vea que para su caso, lo mejor, es no medirla, raro es que dos grupos tengan la misma manera de plantear un Sprint, la misma cultura de retrospectivas, etc. Llámalo diversidad, prácticas diferentes y todas validas… Cherry Picking.
Ah, por cierto, a modo de paréntesis final, y por no dejarlo sin mencionar, en el contexto del desarrollo software, el Cherry Picking es una antigua práctica de control de versiones, que se basa en tomar sólo ciertas y específicas partes de diferentes versiones (de diferentes ramas) y «mergear» (unir) esa selección en una nueva versión. Y, ojo, en el contexto del control de versiones… no está considerada una buena práctica, pero aquí ya no voy a entrar en eso.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Vamos… lo que en español suele llamarse «picotear como las gallinas»
100% de acuerdo contigo Javier!
Yo siempre he pensado que la elección de la metodología/tecnicas a emplear en un proyecto ha de ser una adaptación a la cultura del grupo encargado del proyecto. Pero a veces parece que está un poco demonizado hacer «ScrumBut»… ¿no crees?
Es que en «la cultura popular» Scrum but se entiende como Scrum but «práctica que tipicamente es del mundo cascada»
Si, tienes razón, se suele tender a cambiar cosas para no cambiar nada… Pero ¿no crees que un cambio tan profundo como es el cambio al enfoque ágil, dentro de una organización «tradicional» necesita una gestión del cambio gradual?
Un saludo!
Probablemente si requiere un cambio gradual, pero no sé que tan efectivo es querer cambiar la cultura, manteniendo patrones de conducta… yo entiendo como cambio gradual a la implantación de nuevos patrones, que tal vez tengan un pequeño impacto, pero finalmente cambie la forma de ejecutar o tomar estas nuevas conductas
Cherry picking: un poquito de aquí…un poquito de allá.
Y como hacer un Cherry Picking cuando la metodología que existe en la empresa es propia de la empresa? Es decir, no se basan en ninguna metodología conocida, sino se basa en la cultura de la propia empresa, los procesos y burocracias que pueda tener.
Como poder llevar a los Gerentes de Desarrollo y Tecnología a que se pueda hacer un Cherry Picking para cada implementación?
Depende, si quieres implementar nuevas metodologías, creo que ir por equipos o incluso personas concientizando sobre el valor de realizar los cambios a una forma mas ordenada o herramienta que permita seguir el enfoque, ahora si el cambio es cultural, y nos importa abrir el camino para luego trabajar de forma colaborativa, las metodologías, frameworks, herramientas o procesos es mucho más sencillo.
A los gerentes, creo que hacerles ver que una reunión sin sentido cuesta X cantidad de dolares, euros, pesos, probablemente estén dispuestos a escuchar opciones que hagan más efectivas las reuniones.
A veces implementar una metodología es complicado por las mismas políticas de la empresa, los gerentes están acostumbrados a ciertas costumbres, por ejemplo soy de suramerica y algunos gerentes tienen la mentalidad de tirarle a todo lo que se mueva y sacar un producto rápido para ver como nos va mientras se termina de pulir, todo es prioridad y tiene a una sola persona en uno o varios proyectos, todas estas cosas hace que los desarrolladores se aburran por lo que ellos consideran desorden (también es que las escuelas muestran un visión del desarrollo de software a gran escala pero los de mediana y pequeña terminan siendo diferentes a lo esperaban ), por eso me toca sacar de varias metodologías alguna técnica que de orden o la impresión de el, por eso me toca sacar cosas de scrum, otras de kamban, otras de XP pero todavía no puedo decir que tengamos una mentalidad ágil, pero aun así es complicado y buenos elementos se terminan yendo a pesar de que en otros aspectos es una buena empresa y tiene un buen ambiente de trabajo.
Este es mi caso y mi experiencia, seria bueno saber que recomiendan en estos casos.
PD: felicitaciones por el blog, siempre estoy pendiente ya que considero acertadas y útiles muchas de la opiniones y temas planteados