Muchas veces hacer Scrum parece imposible. El contexto no lo permite, la relación cliente – proveedor o la organización no está preparada y por estrategia no queremos forzar para introducir nuevos roles, artefactos o eventos que puedan generar ruído que dañen la relación.
Lo importante es entender que Scrum no es obligatorio, muchas organizaciones se obsesionan con tratar de hacerlo cuando no tienen la capacidad ni el apoyo necesario. Realmente lo hacen más por imagen que porque entiendan de qué va, y acaban gastando más energía en discutir qué es Scrum que en tratar de hacerlo.
Hay equipos que viendo que no aplican Scrum dicen la frase “Scrum no somos, pero somos ágiles”. ¿Realmente son ágiles? Veamos algunos ejemplos.
Cumplimos los valores
Agile se compone en primera instancia de 4 valores que vienen representados en el Manifiesto Agile. Muchos equipos asumen que son ágiles por que tienen esos valores: piensan en las personas, ponen el foco en el software funcionando, tratan de no pensar en el contrato y colaborar con un cliente y aceptan los cambios por encima de cumplir un plan.
Así visto, podemos decir que son ágiles, pero, ahora nos queda estudiar los principios, que es donde realmente se fijan unas ciertas pautas.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente
Este principio se suele cumplir, decir que somos ágiles por ello no deberíamos porque he trabajado en equipos waterfall y aceptaban también los cambios (impuestos e injustificados más allá de presiones).
Sin embargo, hablamos de la importancia de la atención continua a la calidad. En muchos equipos se aceptan cambios de manera irresponsable que acaban en una reducción de la calidad y las buenas prácticas por lo que un equipo que actúa así no es ágil. Si lo pensamos tiene sentido, cuando tratamos de desarrollar código en mal estado nos cuesta mucho, nos resta velocidad y por eso somos menos ágiles.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto
Este es otro clásico dentro de los equipos que se consideran ágiles. Que una persona de negocio nos diga lo que hay que hacer no es colaborar y trabajar estrechamente, esto ya se hacía en equipos en cascada. Colaborar es algo más profundo, por ejemplo, si el equipo comete un error el responsable de negocio asume el error en nombre del equipo. Este tipo de actitudes generan una sensación de piña que hace que seamos ágiles porque fomentamos el coraje para afrontar los retos en equipo y a entender el fracaso como una fuente de aprendizaje.
Los proyectos se desarrollan entorno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo & Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados
Cuando hablamos de motivación es algo más que un gran salario o unas buenas condiciones. Hablamos de dar espacio a la autoorganización y dejar que los equipos tomen sus decisiones. Un antipatrón es darles un Jira (lo necesitan) pero después restringirles la capacidad de crear su propios flujos de trabajo. No les estamos dejando tomar sus propias decisiones debido a estándares de la organización que solo buscan el control. ¿Cuánta energía invertimos en los equipos para “trampear” estos estándares? Una vez más, esto nos acaba restando mucha agilidad.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. & Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida
Una de las grandes diferencias entre un equipo ágil y uno tradicional es la capacidad de entrega. Entregar software en periodos constantes e inferiores a 2 meses es clave. Muchos equipos que se consideran ágiles pasan meses sin terminar software. Entregar es que esté listo para liberar ante usuarios, es decir, probado, integrado y cualquier cosa necesaria para ello.
Además, que el desarrollo sea sostenible es un principio que habla de evitar los “picos de trabajo”. Algunos equipos tienen varios Sprints que son “tranquilos” para tener que apretar durante horas extras en los Sprints finales a una fecha dada. Esto no te hace ágil, te hace dependiente de las fechas y acabas luchando contra fechas imposibles.
La entrega temprana y sostenible nos da información de cómo impacta nuestro software lo que nos permite tomar decisiones. Los equipos que dejan para el final el obtener feedback pierden la capacidad de adaptarse y obtener un mejor resultado.
El software funcionando es la medida principal de progreso
Relacionado con el anterior, uno de los principios habla sobre centrarte en medir software funcionando porque un software a medias no da valor. Lo curioso es que, muchos equipos que se consideran Agile no miden nada, o miden puntos de historia u horas. Los peores miden % de avance de una fecha que les han impuesto.
Ser ágil es medir software terminado que esté listo. Eso te da información de la velocidad a la que desarrollas software realmente.Esto te da agilidad porque te permite tomar decisiones sobre lo que ocurre realmente.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara
El desarrollo software tiene unas características curiosas, su mayor coste es la mano de obra y su coste de transporte es muy bajo. Sumadas ambas cosas ha hecho que muchas consultoras decidan que los equipos se dividan en zonas donde la mano de obra es más barata. Esto ha sido muy bueno para la cuenta de resultados pero muy malo para la comunicación y los malentendidos que provocan un desarrollo pobre.
No es obligatorio que los equipos estén juntos, pero fomentar la comunicación cara a cara ayudar a ser más ágiles porque afrontamos los problemas juntos y eliminamos fallos de comunicación. Decir que somos ágiles con equipos distribuidos es muy pretencioso.
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor
Este es el principio quizás más importante y que más determina tu capacidad de ser ágil. Muchos equipos entregan tarde, sin preguntarle al usuario final, haciendo entregas grandes sin continuidad y encima solo fomentando la entrega a un cliente con el que ha pactado su consultora.
Sumado todo esto, no podemos decir que seas ágil si es tu estrategia de subidas a producción. Ser ágil es ser capaz de hacer software pronto, entregarlo, recibir feedback y tomar decisiones con lo aprendido.
Ser ágil es más que decirlo, es demostrarlo
Esto son ejemplos de equipos que dicen ser ágiles pero que realmente no lo son. No son equipos que hacen waterfall pero desde luego hacen una agilidad maquillada que se encontrará problemas en la primera salida a producción. Agile apareció como un cambio de paradigma, copiar una parte y creer que eres ágil no resolverá los problemas. Si apuestas por ser ágil, hazlo, no dudes, pero hay que interiorizar muy bien lo que ello conlleva.
