¿Qué significa ser ágil?

Lo que estás describiendo no es Agile por definición (Manifiesto Agile) es Waterfall con reuniones de estado diarias . Agile significa adaptarse fácilmente al cambio, si no hay un circuito de retroalimentación interactivo con el propietario del producto y, por lo tanto, con los clientes, ¿qué cambio está ocurriendo?

Agile se trata de fallas rápidas, a través de una comunicación constante con el propietario / cliente del producto. Es mejor fallar más pronto que tarde, se realiza menos trabajo y se "pierde" menos. Y no se queda estancado con el argumento de que "no tenemos tiempo para hacerlo correctamente, ya que pasamos mucho tiempo haciéndolo mal, solo tenemos que continuar en este mismo camino, aunque esto nos lleve al fracaso". ".

Parece que su administración está haciendo "SCRUM, pero ..." donde "pero" es donde tiran todos los SCRUM cosas con las que no entienden o no están de acuerdo y simplemente hacen las cosas de la misma manera que siempre, pero con nuevos nombres de palabras de moda brillantes para todo.

En SCRUM, el soporte diario es NO sobre la entrega de estado a la administración, es para forzar la interacción del desarrollador, para que sepa qué están haciendo los demás miembros de su equipo. Ayudarse mutuamente y no duplicar el trabajo. Si tarda más de 45 segundos por persona, lo estás haciendo mal. Se trata de la transparencia para el equipo, si una persona está dando el mismo estado varios días en algo que debería ser un solo día de trabajo, el equipo puede resolver el problema de las personas más pronto que tarde.

Si no está probando el código de los demás como está escrito, tampoco lo está haciendo correctamente. Las pruebas deben estar incrustadas en el proceso, no un pensamiento posterior. El control de calidad debe incluirse en las sesiones de planificación y proporcionar estimaciones sobre el tiempo que tomará la prueba.

Si no está cumpliendo con los compromisos de Sprint y no está cumpliendo, no lo está haciendo correctamente. Los sprints son sobre compromisos si se está comprometiendo con demasiado trabajo, deje de hacerlo, no hay forma de que pueda introducir una previsibilidad o repetibilidad si no puede comprometerse con precisión en los entregables.

Jarrod proporcionó una buena respuesta (+1 a eso) y me gustaría extenderlo un poco.

Agile no se trata solo de fallas rápidas y comentarios entre el propietario del producto (cliente) y el equipo; se trata de una retroalimentación rápida entre todos los actores involucrados. Ser realmente ágil (y esto es directamente de el manifiesto ) es reconocer que el proceso existe solo para ayudar a los desarrolladores a entregar un mejor producto. El proceso de personas anteriores al proceso significa que tan pronto como el equipo reconoce que el proceso existente no funciona, lo modificas y lo haces funcionar.

"Scrum but ..." también es un problema, pero esta moneda tiene ambos lados. Si observa el manifiesto, verá que se trata del equipo y que las herramientas / procesos funcionen para usted. No hay dos equipos iguales y, por lo tanto, cada uno operará de forma ligeramente diferente y eso está bien. Sin duda, puedes tomar la metodología Scrum completa e intentar seguirla hasta la letra y ver si eso funciona para tu equipo.

Otra alternativa es en lugar de impulsar otro proceso en el equipo y hacer que todos sigan lo que Scrum te dice que hagas, prueba el enfoque ágil : comunícate con el equipo y ve si juntos pueden identificar áreas problemáticas y soluciones para cada uno. Luego, gradualmente, introduzca cambios en la forma en que trabaja para que se solucionen los problemas.

Puede tardar un poco, pero ...

1. Primero solucionará los problemas más importantes que tendrán el mayor impacto en la capacidad de sus equipos para entregar el producto
2. Al identificar problemas inmediatos y participar en la búsqueda de soluciones, los miembros de su equipo entenderán por qué ciertas prácticas son importantes y no las harán simplemente porque se les dice que las hagan.

Si dibujamos una analogía entre Scrum y un patrón de diseño, trabajar de la manera que propuse sería similar a codificar en un patrón, donde mantendrá el código lo más simple posible y solo convergerá en un patrón de diseño cuando sea necesario. A diferencia de simplemente elegir un patrón de diseño y rodar con él (es decir, seleccionar ciegamente a Scrum y todos sus procesos como un solo conjunto), lo que a veces hace que el código sea más complejo y más difícil de mantener de lo que podría haber sido de otra manera.

La clave para entender es que ágil no se trata de idear un nuevo proceso para hacer las cosas; se trata de un cambio continuo y un ajuste constante a los procesos / prácticas existentes.

si el equipo (y su administración) realmente quieren "ser ágiles", deben elegir una de las metodologías ágiles ( Scrum , por ejemplo), adquiera un poco de entrenamiento y sígalo completamente. También deben analizar detenidamente las Prácticas de ingeniería que se utilizan para apoyar el proyecto ágil en particular Metodología elegida.