Hoy por hoy, nos enfrentamos al gran reto de la deslocalización de los equipos. Bien sea por situaciones extremas como el caso de una pandemia o por necesidades de Negocio, los equipos cada vez más, modifican su manera de trabajar y de relacionarse entre ellos. Nuestra responsabilidad es, ante todo, ayudar a que éstos sigan mejorando cada día y no dejen de entregar el máximo valor posible.
Esta situación donde tenemos que asegurarnos que un cambio nos impacte lo menos posible y que a la larga suponga una mejora, no es nueva, nos la hemos encontrado con la transformación digital, en la transformación hacia nuevas metodologías.
Por eso, a continuación te mostramos en qué tienes que fijarte para conseguir el mayor desempeño de los equipos de desarrollo estés en la situación que estés.
Maximizar la entrega de Valor.
Todos lo tenemos claro, lo más importante es la entrega de valor, pero no nos ponemos de acuerdo en qué significa valor. Al igual que el valor de una casa es su espacio habitable, en TI, el valor del software es la funcionalidad entregada. Para saber qué valor te están entregando, esta funcionalidad tiene que ser calculada con una medida objetiva. No importa la metodología de desarrollo con la que trabajen tus equipos si dispones de la información adecuada para saber la eficiencia de tus desarrollos.
Ahora ya podemos maximizar la entrega de valor, maximizando la entrega de producto software.
Minimizar el impacto metodológico.
Después del valor nos fijamos en la forma de hacer las cosas ¿usamos el mejor método posible? Y nos lanzamos a abrazar la transformación digital.
En los paradigmas ágiles fijamos un presupuesto, pero no fijamos un alcance. Esta falta de compromiso supone un riesgo que sólo asume el cliente y esto puede llegar a generar desconfianza en los niveles de dirección a la hora de hacer una inversión. Cuando llegan a este punto, muchas compañías empiezan a cuestionarse cuánto les está costando el cambio metodológico. Y les asaltan las dudas.
¿Cuánto cuesta la presupuesta satisfacción del usuario? ¿cuánto cuesta acercarse al negocio, hacer los desarrollos más flexibles o reducir el time-to-market? O dicho de otra forma ¿puedo comprobar que el cambio a paradigmas ágiles es para bien y no para mal?
Paliar el impacto de lo imprevisible.
A esto tenemos que sumarle la situación actual donde nadie podía predecir el escenario de teletrabajo en el que estamos viviendo. Hemos realizado una costosa transformación digital, un cambio hacia los paradigmas ágiles donde se fomenta la colocación, que todo el mundo esté en la misma sala, rodeados de radiadores de información, que trabajen y colaboren juntos y, de pronto, los tenemos a todos en su casa trabajando por videoconferencia.
Y aquí surge el temor. ¿Cómo repercute esta situación en la maximización de la entrega de valor? ¿Sigo entregando la misma cantidad de producto software que antes? ¿Cómo puedo saber si necesito actuar para ayudar a los equipos a alcanzar el mismo desempeño de antes?
Cómo detectar dónde actuar.
Hemos hablado de maximizar el valor del producto software y esa debe ser nuestra piedra angular. Con él podremos comparar el coste de nuestros desarrollos por unidad de producto, es decir cuánto me cuesta poner una unidad de funcionalidad en producción según los distintos métodos que utilice para desarrollar: Waterfall, Agile, Agile en remoto o el que se te ocurra.
Con estos datos podremos contar con un Cuadro de Mando como éste:
Esta es la magia de fijarnos en el valor que aporta cada equipo, esa es la magia de fijarnos en el producto software. Para que la veas vamos a hacer zoom en uno de los componentes:
En este periodo de 8 sprints, sale un valor medio que corresponde a 0.654. Al tener este valor, podemos compararlo con otros escenarios como, por ejemplo, un equipo muy similar trabajando en agile con el mismo sistema pero en vez de en remoto, trabajando in-situ. O incluso lo mismo con el mismo equipo trabajando en waterfall (ver tabla superior izquierda)
Aquí puedes ver de un solo golpe de vista la eficiencia de cada una de las situaciones que hemos descrito: Waterfall, Agile (in situ) y Agile en Remoto. Esa eficiencia la calculamos por unidad de producto software y unidad de esfuerzo. De esta forma podemos comparar con la misma unidad de medida cada una de las alternativas y saber cual de ellas es la mejor para nuestras necesidades.
¿Qué significa la línea objetivo? En nuestra experiencia los equipos ágiles suelen ser más costosos en precio, pero logran una mayor eficiencia. La linea objetivo marca la eficiencia que tienen que alcanzar un equipo Agile para que nos resulte más rentable que un waterfall (es una medida del éxito de la transformación digital).
Veamos un nuevo zoom.
En este nuevo zoom podemos ver la evolución del equipo al que queremos ayudar a mejorar.
En esta evolución sprint a sprint podemos observar de un golpe de vista las historias de usuario que nos están aportando valor (en rojo) y aquellas que no lo están haciendo (en naranja). Estas últimas pueden ser debidas a corrección de bugs u otras acciones.
Con la evolución podemos ver si hay algo que impactó en el equipo y podemos ayudarle a desarrollarse mejor. Esta información puede complementarse con el número de defectos detectados (calidad) que nos permitirá saber si a futuro el producto que nos están entregando implica más costes por la corrección de bugs o no.
Qué beneficios aporta un cuadro de mando basado en la entrega de valor.
Si somos capaces de poner a disposición de los responsables un valor de eficiencia objetivo, para ellos será mucho más fácil la toma de decisiones, ya sea a nivel operativo o de negocio.
Trabajando con equipos externos de desarrollo, te puede ayudar para definir acuerdos de negociación del servicio (ANS), negociar contratos con proveedores, RFPs con eficiencia esperada de los equipos, etc.
Si por el contrario los desarrollos se hacen In-House, te podrán ayudar en la gestión operativa, en la estimación de la cantidad de backlogs que se van a cubrir, etc., llevando a tus equipos a una tendencia de mejora contínua.
Las prácticas ágiles se basan en la confianza, pero como le decía Ronald Reagan a Mijaíl Gorbachov durante las conversaciones de llevaron a la perestroika: “confía, pero verifica”.
Verificar no está en contra de Confiar. Verificar es asegurar que el resultado es el correcto y solo se logra con datos objetivos y comparables. Ayudando a alcanzar el mejor desempeño. Ayudando a ser mejores.
