la importancia de implementar los principios ágiles de comunicación, colaboración, transparencia, retrospección y simplicidad.
He trabajado en TI durante 25 años y conocí la mentalidad Agile en 2006. Abracé inmediatamente a Agile porque muchos de sus principios eran cómo ya trabajaba. Me gusta la simplicidad, desarrollé software en iteraciones para poder recibir comentarios y realizar correcciones de curso, prefería comunicarme cara a cara, y puse a mis clientes y desarrolladores en la misma sala con frecuencia para que pudieran colaborar y asegurar que estuviéramos en el Camino correcto.
Avance rápido hasta hace unos años, cuando una empresa me trajo para ayudarlos en su viaje Ágil. El primer día, el director me dijo que eran “ ya muy ágil”. Tenían todos los roles correctos en su lugar, sus ceremonias parecían estar bien ejecutadas, los artefactos parecían limpios y actualizados, parecían tener todo junto. Pero cuando comencé a investigar cómo interactúan entre ellos, vi la desconfianza entre TI y las unidades de negocio que no dio lugar a una colaboración real, casi toda su comunicación fue por correo electrónico para propósitos de "CC YA" y hubo una pesada carga de informe de estado debido a la falta de transparencia En la superficie se veía genial, pero debajo había un gran desastre. Estaban haciendo las partes fáciles de Agile, las prácticas de Scrum, pero no prestaban atención a las partes más duras : los principios Ágiles . Aprendí que priorizar las prácticas sobre los principios es una de las razones clave para el fracaso de Agile.
Puede implementar las prácticas de Scrum perfectamente y aún fallar en Agile. Es posible que vea una mejora en su capacidad para responder al cambio e incluso podría proporcionar un software que funcione más rápido por un tiempo. Sin embargo, no pasará mucho tiempo hasta que los beneficios de Agile sean menos evidentes. Los equipos tendrán dificultades para seguir el ritmo, el software no coincidirá con las expectativas del usuario con tanta frecuencia, y entonces Agile se considerará un fracaso. Incluso puede decidir volver a sus antiguas costumbres, formas que son más cómodas.
La incorporación de principios ágiles es la parte más difícil de Agile: cosas como trabajar a través de problemas de comunicación, desconfianza y falta de responsabilidad. A menudo omitimos trabajar con estos principios porque implica más tiempo y esfuerzo de lo que podemos desear invertir. Sin embargo, casi siempre son las cosas más difíciles las que nos dan el mayor beneficio.
¿Cuáles son algunos de los principios o cambios culturales que son las partes más difíciles de Agile?
Comunicación
A menudo veo a personas que usan Scrum Master para enviar sus mensajes a otros. Están acostumbrados a trabajar con un gerente de proyecto, y un Scrum Master es un rol totalmente diferente. Como Scrum Master trabajando con un nuevo equipo de Agile, tres miembros diferentes del equipo una vez vinieron a mí tratando de comunicarse a través de mí durante nuestro primer sprint. Uno de ellos dijo: "Dwight, necesito esta información de Ramesh antes de que pueda comenzar a codificar". Ramesh estaba a solo 20 pies de distancia de nosotros, pero estaban acostumbrados a que un gerente de proyecto manejara sus comunicaciones.
Un principio ágil clave es comunicarse cara a cara siempre que sea posible. La comunicación cara a cara puede asustar cuando muchos de nosotros estamos acostumbrados a sentarse en un cubículo sin tener que hablar con otras personas. Cuando esto sucedió, acompañé al miembro del equipo al escritorio de la otra persona y les pedí que comunicaran el mensaje directamente. Ayude a sus equipos a adquirir el hábito de comunicarse cara a cara como u primera opción en lugar de como último recurso. El tiempo perdido no es ágil.
Colaboración
Agile se trata de personas que trabajan juntas, hablan juntas y presentan grandes ideas juntas. Estamos fundamentalmente en riesgo cada vez que alguien trabaja en algo solo. Un problema de colaboración que a veces veo ocurre cuando un Gerente de proyecto tradicional se convierte en Scrum Master. Los Project Managers pueden hacer grandes Scrum Masters, pero ten cuidado con aquellos que traen un estilo de comando y control junto con ellos. Agile no se trata de comando y control, pero algunos nuevos Scrum Masters tienden a administrar y dirigir en lugar de colaborar con las partes interesadas y el equipo. Los equipos Great Agile no son administrados: se los anima a colaborar y a resolver los problemas ellos mismos. A menudo, la experiencia se aprende mejor (bien o mal) que diciéndole qué hacer.
También veo un patrón similar con los nuevos propietarios de productos, pero con el comportamiento opuesto. Muchos nuevos propietarios de productos están acostumbrados a crear requisitos, entregándoselos al equipo de desarrollo y luego a sentarse y esperar el producto final, con poca o ninguna participación adicional de su parte. La colaboración continua entre el propietario del producto y el equipo, junto con la corrección oportuna del curso, ayuda a garantizar que lo que se entrega al final del sprint sea justo lo que los interesados querían.
Sin embargo, esto puede consumir mucho tiempo para el propietario del producto, y muchos de los nuevos en el rol no están listos para el compromiso o simplemente no saben que deben estar tan involucrados. Animo a los propietarios de productos a involucrarse regularmente con el equipo del proyecto durante todo el sprint. De esta forma, Sprint Review se convierte en una formalidad porque el propietario del producto ya ha visto varias iteraciones de las características durante el sprint y ha guiado al equipo a construir exactamente lo que los interesados quieren.
Transparencia
La transparencia es solo ser honesto, contarlo como es y, a veces, ser vulnerable. Una vez trabajé con un VP que me pidió que pasara el informe del estado de un proyecto para que se viera mejor para su liderazgo principal . Expliqué la importancia de la transparencia, que humildemente aceptó. La franqueza resultante sentó un precedente de honestidad y apertura que continuó, sin importar los resultados. No podemos arreglar las cosas si los problemas se barren debajo de la alfombra. La transparencia ágil significa plantear cuestiones al aire libre donde se pueden tratar. Las herramientas de ciclo de vida ágil automatizadas son geniales, pero para que los equipos y las partes interesadas puedan ver lo que realmente está sucediendo, deben tomarse el tiempo para acceder a la herramienta y poder verla. En mi experiencia, muy pocas personas ajenas al equipo se toman el tiempo para hacerlo regularmente.
Al menos al comienzo de una transformación Ágil, animo a los equipos a hacer que el trabajo sea más visible colocando grandes tablas de papel de Scrum y gráficos de quemado en una pared y mostrando esta información a todos los que los rodean. El liderazgo realmente aprecia la visibilidad que esto aporta al trabajo de desarrollo. Esto también puede ayudar a reducir la necesidad de informes de estado ya que cualquiera puede mirar el muro del equipo y ver exactamente qué está pasando.
Otro consejo de transparencia que aprendí se deriva del hecho de que muchos miembros nuevos del equipo de Agile son reacios a plantear obstáculos durante las reuniones de stand-up. Una de las principales funciones del Scrum Master es eliminar los obstáculos para que el equipo pueda concentrarse en la entrega de software. Pero si no se levantan obstáculos, el Scrum Master no puede ayudar a eliminarlos. Les recuerdo a los nuevos equipos al comienzo de cada reunión stand up que planteen incluso posibles obstáculos si hay alguna posibilidad de que algo pueda retrasar su trabajo o hacer que no cumplan con su compromiso de sprint. Los miembros más silenciosos del equipo especialmente necesitan aliento para hablar. Recompense a los que expresan su opinión y plantean obstáculos en los primeros sprints, especialmente a las personas más tranquilas, reconociéndolos frente al equipo.
Retrospección
Me gusta comparar la retrospección con la documentación del software. La documentación del software a menudo no se realiza porque se considera de baja prioridad en comparación con pasar al siguiente proyecto. De la misma manera, algunos equipos ágiles omiten las retrospectivas de sprint porque creen que no tienen tiempo o no ven el valor de hacerlo. Solo puede tener una mejora continua cuando se detiene para reflexionar sobre lo que funciona o no funciona y toma una decisión consciente para ajustar las cosas. Pequeños ajustes aquí y allá pueden ser la diferencia entre el éxito y el fracaso. Una vez leí que "la acción sin reflexión lleva al agotamiento y la reflexión sin acción conduce al cinismo". Es vital realizar retrospectivas después de cada carrera y luego implementar realmente los cambios valiosos que surgen de ella.
Sencillez
Esta puede ser una de las partes más difíciles de Agile. La mentalidad Agile es muy simple: hay cuatro valores en el Manifiesto Ágil y en los 12 Principios Ágiles acompañantes. Scrum tiene algunos roles, artefactos y ceremonias. Todo lo demás que hay es un intento de mejorar la mentalidad ágil. Algunas de esas ideas son grandes adiciones y algunas simplemente complican el concepto simple de Agile. La documentación del software es un excelente ejemplo de cómo Agile puede simplificar nuestros proyectos. Los artefactos deben reducirse al mínimo a solo lo que realmente se necesita para hacer el trabajo.
La documentación tiene valor, no me malinterprete: la gobernanza y la documentación de cumplimiento a menudo son necesarias, y el software debe mantenerse utilizando comentarios o documentación de soporte. Sin embargo, a menudo existe una tendencia a crear documentos simplemente porque "siempre los hemos hecho", independientemente de si tienen valor o si alguna vez se leen. Comprenda y sopese el costo real de crear cada documento con el beneficio anticipado. Luego, minimiza el esfuerzo para crear esos artefactos. Puedes hacer que se vea elegante después si eso es realmente importante. Si un diagrama dibujado a mano y escaneado es suficiente para que el equipo avance, es un gran ahorro de tiempo.
Estos son algunos ejemplos de cómo los principios ágiles hacen una gran diferencia. Tenemos que hacer un esfuerzo consciente para ejecutar las partes más difíciles de Agile, los principios, y no solo las partes más fáciles, las prácticas.
Por lo tanto, aunque las prácticas de Scrum o Kanban son importantes, las prácticas solos a menudo conducen a la falla ágil. Los principios ágiles y el cambio de la cultura de desarrollo son en general las partes más difíciles, pero son lo que hace que Agile sea sostenible a largo plazo y maximiza los grandes beneficios que tiene para ofrecer.
Entonces, ¿cuál es el siguiente paso? Mire a su equipo, escoja uno de los principios o áreas de cambio cultural necesarios, una de las partes más difíciles, y ayude a su equipo a hacer lo que debe hacer. Los equipos que continúan trabajando en los principios y en la cultura, cambian duro y lo suficiente como para convertirse en la élite Ágil, los pocos que verdaderamente entienden a Agile, los pocos que desatarán el verdadero poder que el desarrollo Ágil tiene para ofrecer.
Fuente: https://dzone.com/articles/agile-principles-over-practices?edition=395205&utm_source=Zone%20Newsletter&utm_medium=email&utm_campaign=agile%202018-09-18
