Contenidos del artículo
| Fecha | Ciudad | Curso |
|---|---|---|
| 04/03 | Curso virtual | Professional Scrum Master – Advanced (PSM-A) |
| 13/01 | Curso virtual | Professional Scrum Master (PSM) |
| 14/01 | Curso virtual | Professional Scrum Product Owner (PSPO) |
| 03/02 | Curso virtual | Professional Scrum Product Owner – Advanced (PSPO-A) |
| 10/03 | Curso virtual | Professional Agile Leadership (PAL-E) |
En esta serie de cuatro artículos quería compartir un modelo de agilidad de negocio basado en aumentar y acelerar las etapas mediante las cuales se descubren ideas de innovación, se priorizan, se ejecutan y se validan.
En el primer artículo hablé de como acelerar el descubrimiento de opciones de innovación. En el segundo de cómo acelerar y hacer más efectiva la priorización de estas opciones.
En este tercero hablaré de cómo acelerar la entrega de soluciones (habitualmente tecnológicas) a las necesidades del negocio, concretamente de:
¡Vamos a ello! 
Descubrimiento producto
La mejor manera de ir más rápido es no perder el tiempo desarrollando productos y funcionalidades que no se van a usar.
En Evidence-Based Management, el marco de trabajo de Scrum.org que ayuda a las organizaciones a mejorar su capacidad de valor mediante los objetivos y las métricas, la capacidad de innovación está influida por el tiempo disponible para trabajar en funcionalidades que potencialmente generen valor.
Desarrollar iniciativas que el cliente no ha pedido, o que no hemos validado previamente que solucionen un problema real y por el que esté dispuesto a pagar, ocupa a la organización e impide trabajar en iniciativas valiosas.
En el artículo Como descubrir mejores ideas para obtener agilidad de negocio identificaba prácticas que disminuyen la probabilidad de trabajar funcionalidades innecesarias o mal desarrolladas:
- Habilitar todos los canales de feedback.
- Empoderar al front office.
- Liderazgo centrado en el usuario.
- Experimentar de manera continua.
- Esta última práctica, la experimentación continua, da lugar al concepto de dual-track agile. Básicamente se trata de reconocer que las innovaciones efectivas para el negocio difícilmente se pueden identificar, presupuestar y ejecutar como un proyecto cerrado. La innovación requiere probar, aprender y adaptar.
En dual-track agile, existen dos flujos de trabajo:
- El descubrimiento de producto: entender cuales son los problemas y las soluciones.
- La entrega de producto: desarrollar correctamente las soluciones ya validadas.
En el curso Professional Scrum with UX exploramos y practicamos porque este modelo de desarrollo nos permite llegar antes a la solución efectiva para el usuario y la empresa.
Este diagrama de Jeff Patton lo explica bien. Cuanto antes descartemos ideas innecesarias y definamos bien las ideas útiles, más rápido llegaremos a entregarlas
Evitar esperas innecesarias
El modelo Lean Manufacturing, nacido en el Toyota Production System, insiste en que no tiene sentido optimizar una parte del proceso de creación de valor para el cliente si eso supone desoptimizar el global.
Este modelo aplicado a la innovación empresarial, tanto en sus productos como en sus procesos internos, supone examinar todo lo que se hace, desde que se identifica una idea de posible innovación hasta que se valida si esta idea ha generado el valor esperado.
El Value-Stream Mapping (VSM) es una herramienta fundamental para detectar esperas innecesarias. En este detectamos actividades donde:
- Se realiza el trabajo, como identificar la idea, validarla, desarrollarla y medir su efectividad.
- El trabajo está en espera, fundamentalmente debidas a procesos administrativos, p.e. aprobaciones o coordinaciones entre diferentes áreas.
Pues resulta que es habitual que el trabajo esté en espera mucho tiempo, ¡incluso más del 90%!
La conclusión es sencilla:
- La manera más eficaz de acelerar es reducir al máximo las esperas.
- A menudo no tiene sentido “apretar las tuercas” al equipo de desarrollo cuando p.e. ganar un 30% de eficiencia (que es mucho y genera estrés y potencial mala calidad) solo genera un 5% de ganancia total.
Este diagrama de Klaus Leopold expone muy bien los tiempos de espera.
Gestionar las dependencias
Una vez minimizadas las iniciativas de innovación y esperas innecesarias, el siguiente paso para acelerar las entregas puede ser hacer más eficiente el trabajo conjunto de los equipos. Y esto pasa por:
- Reducir las dependencias entre equipos al máximo.
- Gestionar las dependencias que no puedan eliminarse.
La transparencia del sistema de trabajo favorece ambas mejoras. Esto supone que los diferentes equipos sepan:
- Cuál es el flujo de trabajo global y de los demás equipos.
- Qué paquetes de trabajo se están trabajando en cada momento.
El modelo Flight Levels es un excelente sistema de reducción y gestión de dependencias. Básicamente:
- El tablero de coordinación extremo a extremo visualiza el flujo de trabajo de las iniciativas.
- Un representante de cada equipo se reúne con los demás diariamente para coordinarse. El objetivo es minimizar el número de iniciativas en curso (Work In Progress) y priorizar el trabajo respectivo para reducir los bloqueos.
Mantener los equipos internos y estables.
Uno de los principios fundamentales de las organizaciones ágiles es el diseño organizativo basado en equipos ágiles y estables, orientados a la entrega de valor a los clientes y no a la realización de un tipo específico de trabajo (p.e. un departamento).
Las empresas medianas y grandes pueden mantener una organización híbrida con áreas orientadas a la innovación, basadas en equipos ágiles, y otras áreas organizativas orientadas a la eficiencia, basadas en jerarquías y procesos.
La coexistencia entre ambas áreas debe gestionarse para que sea efectiva, como explicamos en el curso Professional Agile Leadership.
Para que los equipos ágiles y orientados a la entrega de valor alcancen un alto nivel de rendimiento, es necesario que tengan estabilidad y mejora continua.
A partir de los estudios del Dr. Bruce Tuckman en los años 60, se desarrolló el conocido Modelo de Tuckman, donde se identificaron las siguientes fases para que los equipos alcancen su potencial de entrega de valor:
- Formación:
- Conflicto:
- Normalización:
- Desempeño:
- Disolución:
Pasar por estas fases requiere más o menos tiempo, dependiendo de la idoneidad y experiencia de sus miembros para el trabajo en equipo, y también de la gestión activa de la cohesión y dinámica del mismo.
Tener equipos donde una parte de sus miembros no tiene dedicación estable o cambia de composición penalizan la cohesión y capacidad de generación de valor.
Tener equipos estables y con miembros de alto rendimiento tiene mayor coste que tener equipos orientados a la eficiencia, basados en maximizar la ocupación de sus miembros y donde se priman los bajos costes laborales.
Es una política organizativa si se prioriza el rendimiento y la velocidad de los equipos, o reducir su coste.
Mejorar continuamente en los equipos.
La mejora continua de los equipos es otro de los principios fundamentales de las organizaciones ágiles.
En eventos periódicos internos de los equipos, típicamente llamados retrospectivas, se identifican los aspectos que funcionaron bien en el ciclo de trabajo y los que pueden mejorar.
De los aspectos a mejorar, se suelen clasificar en tres tipos:
- Mejoras (o acuerdos) sencillos que puede realizar el equipo de manera inmediata. P.e. acordar cómo reaccionar de manera común en una situación concreta.
- Mejoras más complicadas, que requieren la dedicación de un presupuesto o tiempo por parte del equipo. P.e. realizar una formación para adquirir una nueva capacidad.
- Impedimentos organizativos, que están fuera del alcance de los equipos, como p.e. cambiar una política organizativa que les impide realizar tareas que les beneficiarían. Aquí es habitual que intervenga para ayudar un rol como el Agile Coach o Scrum Master, o bien los managers.
Un antipatrón frecuente en las organizaciones ágiles es que las mejoras de los equipos no tienen visibilidad a nivel organizativo. Esto provoca que:
- Los equipos repitan errores de otros.
- Un problema sistémico no adquiera la importancia para movilizar los cambios necesarios.
Herramientas como los tableros de mejora organizativa o los tableros de salud de los equipos, como popularizó Spotify, permiten mejorar la efectividad de la mejora tanto a nivel de equipo como organizativo.
Automatizar todo lo posible.
Las dos últimas recomendaciones son más técnicas. ¡Que no se asusten las personas con un contexto de negocio! Un entendimiento básico de lo que hacen los ingenieros puede ayudarles a entenderles mejor y a apoyarles.
El modelo DevOps supone automatizar a nivel técnico las actividades de desarrollo (Dev) de software y de operación de los sistemas (Ops).
Más allá de las prácticas y herramientas técnicas utilizadas, bastante sofisticadas, las ideas importantes a nivel de negocio respecto DevOps son:
- La tecnología existe, está madura y es mayoritariamente gratuita o de bajo coste.
- Los mejores ingenieros tienen experiencia con estas tecnologías. ¿Son más caros? Sí. Pero su rendimiento es enormemente mayor.
- El beneficio de DevOps no es solo una velocidad de desarrollo superior, sino una calidad y robustez de los sistemas inalcanzable para los equipos tradicionales.
Utilizar DevOps requiere una inversión mayor en ingenieros de alto nivel, pero el retorno es infinitamente positivo.
En el curso Applying Professional Scrum for Software Development (APS-SD) se explica como combinar Scrum con DevOps
Utilizar las métricas DORA de DevOps.
Como última recomendación de este artículo, quería compartir otra idea técnica que puede ser muy útil para acelerar el rendimiento de los equipos.
En 2018 se hizo un estudio 32.000 equipos DevOps para caracterizar qué les hacía ser efectivos. El libro Accelerate [1] se basó en este estudio e identifica las “DORA metrics” cómo los factores críticos de éxito de los equipos de software de alto rendimiento.
Estas métricas, explicadas de una manera sencilla, son:
- Frecuencia de despliegues: los equipos de alto rendimiento pueden desplegar cambios a los usuarios incluso varias veces al día sin riesgos.
- Tiempo de cambio: el tiempo que pasa desde que un desarrollador finaliza una nueva funcionalidad y que esta está lista para desplegarse con éxito.
- Tiempo medio de recuperación: el tiempo que pasa entre un despliegue a los usuarios con un error y la vuelta efectiva a la versión anterior del sistema.
- Tasa de fallos en cambios: la proporción de despliegues al usuario que generan un error.
Al igual que en el caso anterior, los aspectos técnicos detrás de estas métricas son complicados. Pero lo relevante para una persona de negocio es:
- Saber que las DORA metrics existen y,
- Poder preguntarle a su CIO, ingenieros o proveedores si son capaces de utilizarlas.
Dadme feedback en 20 segundos
Si os ha gustado este artículo, os pido dos cosas a cambio:
- Añadid comentarios de vuestra experiencia y punto de vista , haced “like” y compartirlo con vuestros conocidos.
- Completad esta encuesta que ¡os tomará solo 20 segundos!
Referencias
[1] Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology. 2018, Forsgren, Humble & Kim.
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
