Puede que te sientas así porque Agile SÍ es una mierda para el desarrollo de software.
Aquí tienes el porqué…
Hablemos del proceso para hacer un gran trabajo. Para hacer un gran trabajo se requieren dos cosas (básicamente).
- Se presenta cada día para hacer el producto mejor.
- Se presenta cada día para hacerse mejor a sí mismo.
Cuando la gente hace esas dos simples cosas cada día, hacen un gran trabajo. Y eso funciona en casi todos los campos que puedas imaginar.
Y esa es la antítesis de cómo la mayoría de la gente y las empresas utilizan realmente la agilidad. El objetivo de agile no es un gran trabajo. Es otra cosa.
Lo que la mayoría de la gente se centra en el mundo del desarrollo ágil de software son las historias, las estimaciones y los sprints. Básicamente, la mayoría de la gente cree que si toman un trozo de trabajo, lo dividen en pequeños trozos y los escupen con una cadencia similar a la de una fábrica, mágicamente cumplirán con los plazos, tendrán estimaciones precisas y enviarán ¡MÁS!
El problema con eso es que el verdadero objetivo de la gestión es la palabra MÁS. Verás, enviar MÁS les hace parecer mejores. Cumplir con MÁS plazos, enviar MÁS funciones, para conseguir MÁS dinero y MÁS promociones. Es sólo un gran juego de MÁS.
Así que cada vez que llega un sprint o una epopeya, quieren MÁS características, en un plazo MÁS agresivo, para vender MÁS a los clientes en MÁS promesas que hicieron.
Pero aclárame esto Batman…
Si tienes una cantidad fija de recursos y sigues presionando por MÁS, ¿qué pasa? La mierda pasa.
Como decía la vieja canción de blues (y la versión de Zepplin), «Si sigue lloviendo, el dique se va a romper»
Así que en todos los escenarios ágiles en los que he estado, todos parecen ir lentamente hacia el desastre porque hay un deseo infinito de MÁS por parte de muchas de las personas involucradas.
Esto normalmente parece un cóctel de un gran contrato, una fecha límite imposible, y equipos de desarrolladores luchando en un simulacro de incendio completo de trabajar hasta tarde y ser miserable con la esperanza de sobrevivir al lanzamiento. El agotamiento se produce (por lo general a los mejores) y después de dos o tres rondas de esto la mejor gente se cansa y se va.
No hay manera de evitar esto porque los incentivos en el lugar todos empujan a MÁS y eso es lo contrario de hacer MEJOR.
Ves, en cada sistema o actividad hay una distribución 80/20 de la eficacia. El trabajo más efectivo se hace en el primer 20% del esfuerzo, y después de eso los rendimientos decrecientes entran en acción.
La presión constante por MÁS es en realidad una presión constante hacia los rendimientos decrecientes. Cada hora extra invertida vale menos que la anterior. Eventualmente cada hora gastada produce un valor negativo y estás peor que si hubieras parado antes.
Por ejemplo, el trabajo de programación más productivo se hace en unas 2-3 horas al día. Después de, digamos, dos horas de codificación real, los rendimientos decrecientes entran en acción y los programadores empiezan a hacer girar sus ruedas.
El escenario ideal sería que los programadores se presentaran a trabajar, hicieran 2-3 horas de trabajo de calidad y se fueran a casa. Recoger el trabajo más valioso que puedan, hacer un buen progreso, y parar.
Así es como se maximiza el rendimiento de los programadores. No requiere agilidad en absoluto. No requiere historias, sprints, estimaciones o plazos. No se necesitan Scrum Masters. No se necesitan stand ups diarios. Prácticamente toda la pompa y circunstancia no es necesaria.
PERO… lo que he descrito no es cómo funciona lo ágil. No es como se diseñan los entornos de trabajo modernos. Se supone que la gente se sienta en una silla durante 40 horas a la semana para cobrar un cheque. Los programadores tienen que ir a toneladas de reuniones sin sentido para «colaborar» en lugar de limitarse a escribir código. Se pasan horas y horas en negaciones inútiles sobre «encajará esta característica en este sprint» en lugar de simplemente codificar dicha característica y seguir adelante.
Así que, los programadores (a los que les gusta cobrar), le siguen el juego a las tonterías de agile porque parte del trabajo es seguirle el juego a agile. Antes pasó lo mismo con waterfall. Ninguno de estos métodos funciona realmente bien porque realmente se reduce a esto:
La programación es una actividad solitaria que debería parecerse más a un herrero martillando en un yunque. Día tras día, perfeccionando su oficio, dando forma a las ideas en manifestaciones físicas.
En lugar de eso, hemos tomado esa actividad solitaria convirtiéndola en una fábrica de software llena de cubículos u oficinas abiertas que son tan ridículas que son fácilmente ridiculizadas por Dilbert, The Office, y Office Space (que son todas escasamente precisas). Es probablemente la forma menos eficiente de organizar nuestro trabajo, pero optimizar la eficacia o la calidad de los programadores no tiene nada que ver con todos los propietarios, gerentes, PM’s, entrenadores ágiles, etc. que persiguen MÁS.
La respuesta sería perseguir MENOS, pero ¿quién está tan loco como para hacer eso? Nadie en la tierra ágil, eso es seguro.
-Brian