Las serendipias son mágicas. Quedo fascinado cada vez que se presentan. En estos días tuve una y se las quiero compartir:
Células ágiles con proveedores externos
Estuve en un cliente que está iniciando su transformación ágil y conversamos de cómo conformar sus equipos o células ágiles para el desarrollo de software, y de cómo hacer para trabajar métodos ágiles cuando el proveedor de desarrollo ( el que genera el código fuente ) es una casa de software es externa.
La conversación gravitó alrededor de temas como: Generación continua de valor, métodos de trabajo ágiles, el costo de retrasar la solución (Cost of delay), cultura y Mindset.
Intentamos clarificar conceptos y centrarnos en el contexto, el aquí y ahora del cliente, su entorno y el de sus colaboradores
Las principales conclusiones a las que llegamos fueron:
Si quieres trabajar métodos ágiles es útil conformar equipos (células) ágiles donde participen los integrantes de toda la cadena de generación de valor y una buena herramienta para identificar esta cadena es el Value Stream Mapping.
Los actores más comunes en estos equipos de desarrollo son los desarrolladores (obviamente), el Scrum master, el Product Owner y ¡atención!: También es importante que involucres personas que generen valor, que necesiten sincronización y que tomen las decisiones en el equipo, ¿como quiénes? Como personas de testing, seguridad, infraestructura, y experiencia de usuario.
Sí, en el contexto de este cliente deben estar en la célula, permanentes o por demanda, pero que estén como miembros del equipo, no como terceros que opinan de tanto en tanto y obstaculizan el flujo continuo de valor.
Se trata de conformar todo en los equipos y métodos ágiles para que se maximice el flujo continuo de valor
Y ¿en cuanto a los tiempos de participación de las personas en los equipos? En el caso de mi cliente, lo ideal en este momento es la siguiente participación:
- Tiempo completo: Los desarrolladores o testers.
- Mínimo medio tiempo: El Scrum master y el Product Owner.
- Por demanda, pero asistiendo a mínimo 2 reuniones Daily Meeting semanales y a todas las Sprint Planning, Sprint Review y Sprint Retro: El resto de personas.
Además conversamos de las T Shape capabilities para que cada miembro sea polivalente, se disminuya la dependencia de una persona y se maximice, nuevamente, la generación de flujo de valor.
El otro tema grueso del que dialogamos fue:
¿Cómo hago para trabajar métodos ágiles si mi proveedor de desarrollo (el que genera el código fuente) es una casa de software es externa?
Bomm !!! Principio ágil:
La colaboración con el cliente es más importante que la negociación del contrato.
En este contexto sería: Es más importante el compromiso de una persona con su célula ágil que quien es su empleador según su contrato laboral.
Y entonces ¿cómo funcionan las células ágiles con proveedores externos?
Ahí viene la cultura y el mindset: Las personas que pertenecen al equipo son del equipo, no del cliente o del proveedor. Y esto realmente se nota cuando bromean igual, se defienden igual, se toman unas cervezas por igual con los miembros del equipo sin notarse quién le paga la nómina a cada cual (es decir si son empleados del cliente o del proveedor). Ahí es cuando la magia de la agilidad actúa…
Las personas que pertenecen al equipo son del equipo, no del cliente o del proveedor.
Al final el cliente mira los dibujos que habíamos hecho en el tablero, y me dice: Juan, aquí habían venido un muchos consultores con muchas de teorías súper enredadas pero no habíamos podido ver el tema tan simple, con tanta claridad y tan práctico.
Luego llego a mi casa, comemos y vemos el capítulo 5 de la temporada 3 de Vis a Vis en Netflix y hablan de la navaja de Ockam y de cómo ha aportado a las investigaciones de los detectives.
La navaja de Ockham (a veces escrito Occam u Ockam), es un principio metodológico y filosófico atribuido al fraile Guillermo de Ockham (1280-1349), según el cual: En igualdad de condiciones, la explicación más sencilla suele ser la más probable. Esto implica que, cuando dos teorías en igualdad de condiciones tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.
En igualdad de condiciones, la explicación más sencilla suele ser la más probable.
Alerta:
En ocasiones la opción compleja puede ser la correcta, de acuerdo a la evidencia que la apoye. Lo que expone el postulado es que es que en condiciones idénticas, son preferidas las teorías más simples.
Y ahí va la serendipia:
El haber vivido estos 2 momentos en un mismo día me hizo conectar:
El principio de la navaja de Ockham además de aportar a economía, lingüística, teología, biología, estadística y música, le puede aportar, y mucho a los métodos y formas de trabajo ágiles.
En conclusión: Estudia mucho, analiza mucho, aprende mucho, escucha mucho, analiza los Frameworks (marcos de trabajo) y al final aplica lo que aprendiste y hazle caso a las ideas construidas por tu equipo de trabajo, hazle caso a lo que te parezca más práctico, más simple , a lo que creas que te genera más valor tu contexto (aquí y ahora, en la situación actual) que a lo que diga una teoría, marco o consultor por más famoso que sea.
Hazle caso a lo que te parezca más práctico, más simple , a lo que creas que te genera más valor tu contexto (aquí y ahora, en la situación actual) que a lo que diga una teoría, marco o consultor por más famoso que sea.
¿Qué piensas? ¿Te parece aplicable la navaja de Ockham para la búsqueda de ideas y formas de trabajo, ágiles o no ágiles?
Para más contenidos de Transformación digital y agilismo visita:
Linked In: https://www.linkedin.com/in/juanandres-ochoa/
O si quieres escribirme mi correo es: juanandres.ochoa@castor.com.co
Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.
Escucha nuestro Podcast: Transformación Cultural en Latinoamérica
