Escalar ágil requiere cambiar el ritmo
Los equipos y las organizaciones de software de hoy quieren escalar más rápido que nunca. La presión para lanzar funciones a un ritmo creciente mientras se mantienen los errores al mínimo solo se ve agravada por el tamaño cada vez mayor de los equipos de desarrollo necesarios para ofrecer esas funciones. Seguimos agregando más y más desarrolladores a un equipo, pero obteniendo retornos incrementales a medida que los desarrolladores experimentados entregan cada vez menos código de alta calidad que puede hacer o deshacer el producto.
Los enfoques que nos han llevado hasta aquí se han estancado. En lugar de agregar personas a un equipo, para crecer tenemos que mirar de manera diferente a cómo trabajan juntas las personas que ya están en un equipo.
Antes de entrar en eso, veamos la historia hasta ahora.
El modelo en cascada fue esencialmente el primer método de gestión de proyectos introducido en la industria del desarrollo de software. En ese momento, el software era solo una pequeña parte de los proyectos de infraestructura más grandes.
CONTENIDO RELACIONADO: Ágil a los 20: dónde estaba y hacia dónde se dirige
Debido a la rigidez de las especificaciones para estos proyectos, había poco margen para variaciones en el proceso. Los cambios en las especificaciones durante el desarrollo habrían resultado en altos costos, por lo que el enfoque muy rígido y estructurado de Waterfall funcionó bien.
A medida que el software ganó importancia en los negocios y, en última instancia, en el uso personal, aumentó el número de aplicaciones de software mucho más pequeñas. Esto, a su vez, condujo a un aumento en el número de empresas de software que crean dichas aplicaciones y a un aumento de los problemas con el enfoque rígido y determinista de Waterfall.
Agile surgió de la necesidad de abordar estos desafíos. Los equipos de software descubrieron que era mucho más útil tener un proceso que responda a los cambios en las solicitudes de los clientes y rápidamente haga que algo básico funcione y, a partir de ahí, se adapte e itere.
Sprints, el aspecto más utilizado del desarrollo ágil, permitió a las empresas de software crear valor para los clientes mucho más rápido. Además, los equipos pudieron reaccionar más rápido y reducir el retrabajo resultante de cambiar las especificaciones.
Y aquí estamos en el presente. A pesar de la evolución de los enfoques de desarrollo de software a lo largo de los años y los beneficios que conlleva, los problemas que surgen del crecimiento de equipos y organizaciones siguen sin resolverse.
¿Entonces que hay de nuevo?
Tomemos un pequeño equipo de desarrollo y sigamos a medida que escalan.
Nuestro equipo de desarrollo, que forma parte de una empresa emergente, tiene cinco desarrolladores. De los cinco, uno es un desarrollador senior con mucha experiencia, otro par son desarrolladores senior y los dos últimos son juniors con mucha menos experiencia. Antes de que los juniors subieran a bordo, los tres desarrolladores senior se coordinaron y simplemente siguieron adelante. Pero a medida que el equipo crecía, necesitaban estructurar un poco más su planificación y ejecución de sprints para que todo el equipo tuviera una quincena ocupada.
Además, el desarrollador de mayor edad dedicó su tiempo a ayudar a los dos nuevos juniors. Esto, por supuesto, limita el otro trabajo que puede hacer.
Casualmente (o quizás no en absoluto) han surgido dos nuevas presiones: generar más características; y al mismo tiempo fijar la calidad en función de los errores derivados de los nuevos desarrollos. Nuestro desarrollador más antiguo, que se ha convertido en el líder del equipo de facto, se queja al fundador de que necesita más apoyo. Por supuesto, son viejos colegas que han estado en el negocio desde el principio y convencen al fundador para que apruebe nuevas contrataciones.
En este punto, el equipo tiene una estructura real y seguramente programará el trabajo de todos para asegurarse de que aprovechen al máximo el equipo. Este equipo en crecimiento requiere bastante tiempo en el desarrollador senior, pero eso es de esperar para mantener la máquina en funcionamiento. Además, el fundador recibe llamadas con consultas «urgentes» de los clientes e ignora la carga del sprint para acelerarla en la carga de trabajo del desarrollador más antiguo.
Volviendo a la pregunta: ¿qué está pasando? ¿Por qué deberían hacer esto los equipos de todo el mundo?
Estos problemas no surgen de la malicia y ciertamente no surgen de la estupidez (dado el calibre de las mentes involucradas). En cambio, se basan en dos suposiciones que hacemos sobre cómo deberían trabajar los equipos.
Primero, asumimos que la contribución de todos los miembros del equipo es la misma. Al final del día no hay un «yo» en el «equipo» y todos hacemos nuestra parte aquí.
Esta suposición se muestra en la forma en que planificamos el trabajo. Realizamos reuniones de planificación en las que todos pueden opinar sobre el trabajo que deben realizar. El enfoque en estas reuniones de planificación está más en las entradas y una distribución uniforme de la carga que en la salida del equipo.
En segundo lugar, asumimos que el tiempo que no funciona es una pérdida de tiempo. Cuanto más hacen todos, más hacemos como equipo. ¿Ley?
Esto se hace evidente en situaciones en las que tenemos un miembro del equipo que tiene una hora libre en un día. En lugar de facilitar que ese miembro del equipo mueva el pulgar, encontraremos algo más «útil» para ellos. ¿Quizás investigar una solución rápida?
Estas suposiciones se basan en eficiencias razonables que tenemos como humanos, pero estas suposiciones no se aplican de manera efectiva a los equipos de software.
¡Examinémoslos con más detalle!
1. Todos los miembros del equipo contribuyen por igual a los resultados del equipo.
Cada equipo tiene una persona que es la persona más competente de ese equipo. Esta brecha de nivel de habilidad se amplía por su experiencia con el código base y el producto, lo que resulta en una gran diferencia en el valor del código que escriben frente al de la persona más joven. Esto no significa que los desarrolladores junior no sean valiosos, simplemente ilustra la naturaleza del trabajo y el valor agregado que se puede hacer en cada nivel de antigüedad.
Esto es vital porque, por defecto, el desarrollador senior más competente actúa como un cuello de botella para el trabajo que el equipo en su conjunto puede hacer y, lo más importante, el trabajo de alta calidad que el equipo puede hacer, lo que nos lleva a concluir que NO todos los miembros Las contribuciones son las mismas.
2. El tiempo de inactividad es una pérdida de tiempo
Un equipo de personas que trabajan juntas no es como nadadores en una piscina, cada uno nadando por su propia longitud. Hay muchas dependencias en el trabajo de los miembros del equipo, lo que significa que en un solo sprint nunca tendremos una carga uniforme y algunas personas estarán inactivas de vez en cuando. Forzar una carga uniforme debería fallar.
Si la primera suposición es incorrecta y no todas las contribuciones de los miembros del equipo son iguales, entonces debemos maximizar la contribución del recurso más calificado. Esto se puede hacer de muchas maneras. Uno de ellos es que están inactivos durante 30 minutos entre tareas, ya que si retomarían otra tarea, se retrasarían para comprometerse con el recurso de cuello de botella.
¡A veces, no trabajar es la mejor contribución que puede hacer un miembro del equipo!
¿Cómo arreglamos esto?
La respuesta es conceptualmente simple, pero mucho más difícil de implementar.
Lo que el equipo necesita es más capacidad para el cuello de botella de la botella (el desarrollador más antiguo), no el cuerpo de la botella (todo el equipo). Al aumentar la capacidad del cuerpo, solo estamos forzando el cuello de botella en lugar de centrarnos en aumentar el cuello de botella, lo que aumenta el rendimiento de todo el equipo.
Entonces, la respuesta es coordinar el cuello de botella de manera más efectiva, luego proteger el trabajo del equipo de los efectos de las desviaciones y, finalmente, acelerar el flujo de trabajo a través del equipo. Estas tres iniciativas forman «Pace», un marco amigable y ágil que reemplaza a Scrum en muchos equipos. Para obtener algo tangible de este artículo, aquí hay 4 reglas de ritmo de aplicación inmediata para minimizar los cuellos de botella y maximizar el rendimiento del equipo:
1.Asegúrese de que siempre haya trabajo por hacer para el cuello de botella
- Dado que el cuello de botella controla nuestro rendimiento y la pérdida de tiempo debido al cuello de botella para el equipo, nos aseguramos de que siempre se haga un trabajo valioso para el cuello de botella.
2. Alivie el cuello de botella de las tareas innecesarias
- Todo el trabajo que otros pueden hacer se les asigna, liberando el cuello de botella de hacer solo el trabajo que necesitan hacer. Compruebe la trampa de la eficiencia de las tareas de planificación para el cuello de botella, ya que son más rápidas.
3. Programe el trabajo de otras personas en torno al cuello de botella
- El trabajo del cuello de botella (incluido el trabajo de otros que requiere el cuello de botella) se planifica primero. Entonces el trabajo de otros haciéndolo No Se puede planificar la interacción con el cuello de botella.
4.Asegúrate de que el cuello de botella sea de buena calidad.
- Para minimizar el riesgo de cuellos de botella, se introducen pasos de calidad adicionales, como pruebas o listas de verificación, inmediatamente antes del cuello de botella.
Pace aplica estas reglas probadas a lo largo del tiempo y se asegura de que aporten beneficios significativos, casi de inmediato y a largo plazo.