Cinco cosas Escalofriantes sobre la adopción de Agile

Pasión ÁgilArtículosCinco cosas Escalofriantes sobre la adopción de Agile

Nov

1

November 1 , 2017 | Posted by admin | , , ,  |

Cinco cosas Escalofriantes sobre la adopción de Agile

Siempre he sido un gran fan de las películas de terror (y si no me creen pregúntenle a mi madre o a mi esposa). Y admito que me emociono cada vez que sale una buena película o secuela de terror, y aunque soy de ver películas en casa nada como una buena película de terror en una sala de cine.

Hablando de cosas de terror, hay aspectos de cada transformación ágil que pueden enviar un escalofrío por la columna vertebral y guardando las proporciones, hacernos sentir como si estuviésemos viendo una película de terror en una buena sala de cine. Así que hablando de cosas de miedo, veamos las cinco cosas que pueden generar terror a lo largo de su viaje de transformación hacia Agile.

  1. En Agile NO hay fase de diseño

Los arquitectos y la gente de tecnología avanzada, a menudo se asustan con la idea de que no hay una fase de diseño en las metodologías ágiles. Si bien es cierto, que los equipos ágiles evitan una fase de diseño inicial, eso no significa que el diseño no ocurra.

El diseño en un proyecto ágil se caracteriza por dos atributos: emergente e intencional. Un diseño emergente, es aquel que surge con el tiempo. En lugar de hacer todo por adelantado en una sola fase, ya que el diseño es una actividad continua. El diseño surge a lo largo del desarrollo del software.

Pero el diseño también es intencional. Esto significa que el diseño no surge aleatoriamente. El diseño se guía por la intención de las personas técnicas o quizás incluso alguien en un rol de arquitecto designado.

Si las personas técnicas sénior están preocupadas por una parte específica del sistema, el PO (Product Owner), debe priorizar uno o dos puntos atrasados ​​del producto en esa parte específica . Esto permitirá que el equipo explore esa parte del sistema al construir una pequeña parte de este. Hacerlo ayudará a identificar el diseño apropiado en esa área.

Permitir que el diseño surja guiado por la intención del equipo reducirá el terror de que no haya una fase de diseño en ágil.

  1. Me convertiré en un Generalista.

Un mito común que ha persistido desde los primeros días de la agilidad, es que los equipos ágiles no valoran a los especialistas y quieren que todos se vuelvan generalistas. Esto es aterrador para muchas personas por dos motivos: primero, nadie disfruta de todos los tipos de trabajo por igual y, en segundo lugar, debido a la preocupación de que podría afectar la empleabilidad futura, si alguien puede hacer cuatro cosas adecuadamente en lugar de una cosa extremadamente bien.

La idea de que todos se conviertan en generalistas en un equipo ágil es completamente falsa. Si estoy entrenando a un equipo que tiene el mejor desarrollador de JavaScript del mundo, voy a querer que esa super estrella haga cosas increíbles en JavaScript, sin aprender cómo convertirse en un DBA.

Sí es cierto, los equipos ágiles valoran a los miembros que tienen habilidades múltiples. Es decir el Tester también puede escribir algo de JavaScript, por ejemplo.

Una de las maneras más fáciles de equilibrar la cantidad de trabajo entre dos habilidades, es tener a alguien que pueda hacer cualquier tipo de trabajo. Un ejemplo podría ser, si a su equipo le resulta difícil equilibrar la cantidad de trabajo en una iteración entre programadores y testers, buscar a alguien experto en codificación y pruebas podría resolver ese problema.

Un objetivo en agile es la formación de equipos Cross-Funcionales, lo que significa que el equipo tiene todas las habilidades necesarias para producir un producto terminado, que funcione dentro de la iteración. Hacer eso no requiere que cada persona tenga todas las habilidades.

Si la idea de convertirse en un generalista hace que tu cabello se encrespe, entender que un equipo multifuncional aún permite especialistas debería tranquilizar tu mente.

  1. ¡No podemos planificar ni predecir fechas!

La administración a menudo se enfría hasta los huesos con la idea de que un equipo ágil no puede planificar o predecir fechas más allá de la iteración o sprint actual.

Es Cierto, los equipos ágiles renuncian a la falsa comodidad de los proyectos demasiado planificados con diagramas de Gantt, que muestran una fecha de finalización en un futuro lejano; Pero eso no significa que los equipos ágiles no puedan hacer planes o predecir fechas o alcance de entrega futuros.

Un gran beneficio de ágil es que en cada iteración el equipo enciende la manivela en todo el proceso de desarrollo. Es decir, toman una idea generalmente expresada como nada más que una simple historia de usuario, e implementan completamente esa característica. Esto significa que cada pocas semanas, un equipo puede medir su progreso y asi pueden saber cuánto han hecho.

En contraste con un proyecto de desarrollo tradicional, tal vez uno con una fase de análisis, una fase de diseño, una fase de codificación y, finalmente, una fase de prueba. Cuando ese equipo mide su progreso en un período de tiempo, están midiendo solo la rapidez con que realizan uno (o quizás dos) tipos de trabajo. La rapidez con que un equipo está haciendo diseño no dice nada de cuán rápido será el equipo para codificar y probar.

La clave de la planificación ágil es abrazar la incertidumbre, admitiendo que es imposible conocer toda la funcionalidad que se construirá antes de comenzar el proyecto, y luego ajustarla de diversas maneras. Cuando los equipos combinan esta realización con la capacidad de medir realmente la cantidad de trabajo realizado en cada iteración, esto conduce a una planificación confiable, lo que debería calmar los nervios de un equipo gerencial intimidado por la perspectiva de no tener previsibilidad.

  1. ¡No tendré trabajo!

La perspectiva de hacer que un equipo o compañía sea ágil, es suficiente para asustar a algunos gerentes que están preocupados de que no tendrán trabajo una vez que se complete la transición.

Esto es comprensible; sería desalentador comenzar un esfuerzo de transición destinado a ayudar a una empresa a saber que puede hacer que su papel sea superfluo.

Sin embargo, puedo decir claramente que no conozco todavía una empresa que haya decidido adoptar la agilidad y que luego haya empezado a decir: “De acuerdo, ya no necesitamos personas con un cargo X”.  “Simplemente no sucede. Claro esta, una Organización  puede decidir que un cargo específico ya no es necesario o apropiado. Pero las personas con esos cargos todavía tienen trabajos. Y en la mayoría de los casos, creo que terminaran con trabajos mejores y más enfocados. Dicho esto, es cierto que algunas personas terminarán teniendo un control menos directo sobre las personas o las decisiones, y pueden encontrarlo frustrante, incluso al punto de abandonar la empresa.

  1. ¡Scrum tiene demasiadas reuniones!

Como muchas personas, realmente odio las reuniones.  Pero incluso yo puedo reconocer que algunas reuniones son importantes y útiles. Y eso incluye las cuatro reuniones estándar de Scrum: El Planning, el Dayli, el Review y la Retrospectiva.

La idea de todas estas reuniones, sin embargo, puede enviar a algunas personas a un sudor frío.

Aquí está el problema con las reuniones de Scrum: tienen nombres. Cuando algo tiene un nombre, es más fácil atacar. En mi experiencia, muchos equipos que adoptan Scrum tuvieron más reuniones antes de Scrum. Pero las reuniones no tenían nombres y en su mayoría eran reuniones ad hoc convocadas para resolver problemas específicos.

La clave para superar el pensamiento aterrorizante de pasar demasiado tiempo en reuniones es mantener la reunión corta. Una vez que encuentren formas de acortarlos, esas reuniones ya no deberían asustarnos.

Compartir esto:

Comentarios


×