¿Por qué mi equipo no es capaz de entregar software a tiempo?

En este artículo, analizamos algunas de las razones por las cuales un equipo de desarrollo de software podría estar sufriendo retrasos en su planificación que no le permiten entregar un proyecto a tiempo. Comenzamos examinando qué significa realmente estar "a tiempo" antes de explorar varias razones comunes por las cuales las entregas pueden retrasarse. Este artículo se centra firmemente en la identificación de problemas y no pretende profundizar en las soluciones que podrían ser adecuadas para las entregas tardías.

Planteamiento del problema

Alineación de conceptos y expectativas

Antes de abordar por qué los equipos de desarrollo no están entregando en el plazo previsto, es fundamental definir qué significa realmente "a tiempo".

Es posible que los equipos de desarrollo no estén siendo lentos en absoluto. Podría suceder que se les estén imponiendo expectativas poco realistas. Por ejemplo, puede ser que las fechas de entrega de los productos sean dictadas por los directores de la empresa antes de que los equipos de desarrollo participen en la planificación. Las organizaciones deberían ser cautelosa al imponer el triángulo de hierro a un equipo de desarrollo, ya que es casi seguro que lleve al fracaso de un proyecto o producto.

Es fácil para una empresa culpar al equipo de desarrollo por una entrega tardía. Por lo tanto, es de vital importancia que el concepto de "a tiempo" sea entendido, acordado y asumido por todas las partes interesadas. Si se responsabiliza a un equipo de desarrollo de un plazo de entrega en cuyo acuerdo no han participado, no estarán motivados para cumplirlo y es probable que caigan en un juego de culpas porque «¡de todas formas nunca acordamos esa fecha!

Planificación realista

Los equipos de desarrollo se sienten más cómodos cuando se les pide que estimen un plazo para algo pequeño, con pocos elementos desconocidos. Sin embargo, las personas enfocadas en el negocio exigen saber cuánto tiempo tomará entregar proyectos grandes, con muchos riesgos e incertidumbres.

El deseo del equipo de desarrollo de hacer predicciones solo a corto plazo es comprensible, ya que no pueden prever lo que podrían descubrir o lo que aún no ha sucedido durante una entrega prolongada. Por lo tanto, consideran factible predecir con certeza solo en días o, posiblemente, semanas. Por otro lado, el deseo del negocio de obtener certezas a largo plazo es comprensible, ya que solo tiene sentido para los inversores pronosticar ingresos y gastos en períodos de meses o años.

Se debe buscar un punto medio, y es fundamental que la organización resuelva esta tensión en la planificación de manera que satisfaga a todos los stakeholders antes de examinar las posibles causas de los retrasos en la entrega.  La estimación del tiempo, teniendo en cuenta la incertidumbre y el riesgo, es también un elemento importante de la gestión de proyectos de software.

Falta de personal

Es posible que un equipo de desarrollo no cumpla con los plazos debido a una falta de personal. Aunque desde la década de 1970 sabemos que simplemente agregar más personas a un esfuerzo de desarrollo de software no reducirá necesariamente el tiempo de entrega, sería incorrecto descartar a priori la posibilidad de que más personal sea la solución a una entrega lenta.

Silos y falta de alineación

Muchas organizaciones han evolucionado naturalmente en torno a competencias técnicas. Esto parece perfectamente lógico y funciona bien hasta cierto punto. Consideremos la evolución de una organización, desde su fase de startup hasta convertirse en una organización madura con, digamos, 300 personas distribuidas en varias oficinas.

Una startup comienza de manera natural con un pequeño grupo de personas en un equipo multifuncional responsable de todo lo que hace la empresa. En los primeros días puede haber un CTO (quien tuvo la idea y es bueno para recaudar capital), un administrador de bases de datos, un experto en frontend, un desarrollador Java, un experto en infraestructura, un investigador, un experto en UX, un vendedor, y un experto en operaciones. Este grupo probablemente estará ubicado en una pequeña oficina compartida, donde todos se conocen bien y están al tanto de lo que cada uno está haciendo para la compañía.

Si avanzamos un par de años, llegamos al punto en que la solución está en producción y quizás hay 15 empleados técnicos. En algún momento, el administrador de bases de datos se convirtió en el gerente de bases de datos con su propio equipo; el equipo de frontend se formó alrededor del experto original en web; el equipo de backend se estructuró en torno al desarrollador Java, y el equipo de infraestructura (o plataforma) creció alrededor del experto en infraestructura original. Esto seguirá funcionando mientras suficiente gente del equipo original, que comparte la visión original, permanezca en la empresa y mientras todos se conozcan bien.

Sin embargo, en algún momento, la Ley de Conway comenzará a jugar en contra de la organización. Los miembros de las diferentes competencias ya no sabrán lo que están haciendo los otros grupos ni cómo lo hacen. Empezará a ser difícil entregar nuevo valor porque las cadenas de valor se habrán fragmentado entre varios equipos, cada uno con sus propios objetivos, prioridades e incentivos.

Esta empresa ahora tiene traspasos de trabajo. El resultado de estos traspasos es el tiempo de espera. El tiempo de espera es desperdicio. No importa cuán “ocupadas” o “utilizadas” estén las diferentes partes de la cadena de valor, si hay traspasos y colas, ese tiempo de espera será el mayor factor en tu tiempo de entrega total.

Falta de conocimientos o habilidades

La directriz Agile de Norm Kerth debería leerse al principio de cada reunión retrospectiva. Nos dice que:

"Independientemente de lo que averigüemos, entendemos y creemos que todos hicieron el mejor trabajo posible, teniendo en cuenta lo que sabían en ese momento, sus habilidades y capacidades, los recursos disponibles y la situación del momento".

Este es un mensaje importante y siempre hay que tener en cuenta que un equipo puede carecer de habilidades y capacidades. No lo descartes como posible causa de la incapacidad para cumplir los plazos.

Experiencia y competencias

¿Son los desarrolladores de tu equipo capaces de entregar los resultados que les estás pidiendo? ¿Cuentan los equipos con la experiencia necesaria para hacerse responsables de un proceso de entrega? Es fundamental comprender, articular y alinear las habilidades requeridas en cada equipo, y tener una conversación abierta y honesta sobre si esas habilidades están presentes.

Si descubres que a tu equipo le faltan las competencias o la experiencia necesarias, ese es el problema que debes abordar.

Conocimiento del dominio

¿Tienes un equipo muy competente pero con un conocimiento insuficiente del dominio en el que se les pide trabajar? También podría ocurrir que una persona en tu equipo esté acaparando todo el conocimiento del dominio en un silo personal. En el primer caso, necesitas evaluar qué tipo de capacidad de ownership de producto o análisis debes introducir; en el segundo caso, es necesario examinar los mecanismos que utilizan tus equipos para compartir contexto internamente. Por ejemplo, ¿están colaborando regularmente en todos los aspectos de la entrega, desde la creación de historias hasta el desarrollo y la implementación?

Mecanismos de control

Muchas organizaciones, especialmente las más maduras, cuentan con mecanismos de control que fueron diseñados originalmente para apoyar un resultado de manera sensata, dadas las normas tecnológicas y de negocio prevalentes en el momento de su concepción. El problema con muchos de estos procesos es que ya no tienen sentido en el mundo moderno de entregas Agile y, en algunos casos, pueden incluso impedir la creación de valor. Estos procesos a veces se conocen como Risk Management Theatre.

Un buen ejemplo de esto es el tradicional comité o equipo de gestión de cambios. En la época en que el software se entregaba en ciclos largos, tal vez de años o más, y rara vez se modificaba después de la entrega inicial, tenía sentido analizar y registrar cuidadosamente el impacto de los cambios y los riesgos potenciales. En el mundo actual, donde el feedback rápido y la integración de calidad son prioritarios, estos procesos no solo dejan de tener sentido, sino que también pueden obstaculizar la entrega rápida de valor a tus clientes.

Deuda técnica

Un gran factor que ralentiza la entrega de software es la acumulación de deuda técnica. Este es un concepto que se ha discutido desde al menos 1992 por Ward Cunningham.  Cada test que falta, cada fragmento de código mal escrito, cada método mal nombrado, cada incumplimiento de las normas de diseño tiene un coste.

Este coste generalmente es pequeño en cada caso, y lo que es crucial, no se paga de inmediato, pero eventualmente pagarás un precio alto porque, al igual que con la deuda monetaria real, el costo de cada uno se acumula. La calidad del código no debe considerarse como un lujo innecesario, sino como el aceite que hace que el motor funcione de manera suave y, en última instancia, funcione en absoluto.

Es importante reconocer cuándo estás sufriendo los efectos de la deuda técnica acumulada y, si es así, tomar medidas para abordarla. Enfrentar la deuda técnica es una tarea de mantenimiento necesaria que ayudará al equipo de desarrollo a entregar software a tiempo, hoy y en el futuro.

Existen muchas herramientas disponibles que se pueden utilizar para analizar bases de código, identificar smells en el código o un mal diseño, y sugerir mejoras. Dichas herramientas pueden proporcionar métricas objetivas que se pueden rastrear para ayudarte a entender si la deuda técnica es un problema, si está mejorando o empeorando, y si debes tomar medidas para abordarla.

Idealmente, cualquier producto gestionado por un buen equipo de entrega no debería acumular altos niveles de deuda técnica. Pero si lo hace, necesitas una estrategia para abordarla. Estrategias simples, como la regla boy scout, pueden ser útiles. Pero, la prevención, como en muchas cosas en la vida, es mejor que la cura.

Automatización

En un enfoque moderno de DevOps, el equipo de desarrollo asume la responsabilidad de desarrollar y operar la aplicación que producen. Parte de esta cadena de valor end to end es desplegar la aplicación en alguna infraestructura. La entrega lenta a menudo puede ser causada por la falta de automatización en los procesos asociados con el despliegue. En los peores casos, el acto de lanzar software implica que una persona o un grupo de personas sigan una lista de tareas manuales para hacer funcionar la última versión del software en tu entorno de producción.

El estado ideal para el despliegue de software debería ser tener pipelines automatizados que puedan desplegar tu software con solo presionar un botón. Además, no solo debería estar automatizado el acto de despliegue y, por lo tanto, ser repetible, sino que la infraestructura en la que se despliega debería ser creada o modificada a través de scripts que se ejecuten a través de dichos pipelines automatizados.

Tu objetivo en cada nivel debe ser automatizar todo lo que pueda ser automatizado. Cualquier tarea manual y repetitiva no solo es una pérdida de tiempo, sino que conlleva un alto riesgo de fallo.

Métricas y rendimiento

Finalmente, y tal vez de manera paradójica, los métodos por los cuales tu organización mide la productividad de tus equipos de desarrollo podrían estar causando que entreguen más lentamente. Existe un deseo natural en la mayoría de los paradigmas de gestión de entender qué tan bien están funcionando los equipos y las personas. El gurú empresarial Eli Goldratt dijo una vez: "Dime cómo me medirás y te diré cómo me comportaré". Es totalmente posible que las mediciones que estás tomando estén causando el mismo problema que deberían ayudar a resolver.

La forma fundamental de medir a un equipo que crea algo es entender su throughput o rendimiento. El throughput se define como la tasa de retorno de valor a la empresa o a sus clientes. El problema es que es prácticamente imposible entender el rendimiento en una organización de entrega de software porque puede ser muy difícil evaluar el valor de epics, features, stories o tareas.

Esto lleva a los managers a idear sustitutos para medir el rendimiento, como story points, stories completadas, líneas de código o bugs corregidos. El problema con estos sustitutos es que no son indicadores anticipados del valor devuelto y a menudo pueden ser fácilmente manipulados.

Podrías crear una métrica sensata, coherente y a prueba de manipulaciones que sea un buen sustituto del throughput. Incluso podrías calcular el rendimiento con exactitud, pero lamentablemente estos casos son raros.

La mejor manera de evaluar el valor, y entender la productividad de tus equipos, es tener en cuenta algunas métricas clave y trabajar en su mejora. Estas métricas - tiempo de entrega, frecuencia de despliegue, mean time to recover y tasa de fallo de cambios - han demostrado ser un indicador de alto rendimiento en equipos y organizaciones de entrega.

Conclusión

• Existen diversas razones por las cuales un equipo no cumple con los plazos previstos de un proyecto, cada una con su propia solución. Algunas reglas a seguir al diagnosticar y tratar de solucionar una entrega lenta son:
• Comprende qué significa “a tiempo”. Asegúrate de que todos los stakeholders estén alineados en su significado y estén comprometidos con las fechas acordadas.
• Entiende si hay transferencias de trabajo y considera reorganizar tu negocio para que cuentes con equipos multifuncionales alineados y capaces para entregar la totalidad de los resultados a sus clientes.
• No descartes explicaciones simples. ¿Tenemos suficiente personal? ¿Contamos con las habilidades adecuadas?
• Preocúpate por la deuda técnica y asegúrate de que todos entiendan que es un problema global cuando se acumula.
• Automatiza todas las tareas que puedas.
• Mide solo lo que realmente importa; si no es posible medir el rendimiento, considera hacer un seguimiento de las cuatro métricas clave: tiempo de entrega, frecuencia de despliegue, mean time to recover y tasa de fallo de cambios.