5 datos sobre la transformación ágil

Nunca he sido fan de las películas de terror. Pero Halloween siempre me ha encantado. De niño me encantaba ponerme disfraces espeluznantes y asustar a mis amigos y a otras personas. Y admito que me gusta la emoción de entrar en una casa embrujada bien preparada en Halloween.

Sin embargo, también en cada transformación ágil hay aspectos que pueden provocar escalofríos, y esos momentos no son tan emocionantes.

Así que abordemos juntos estas cinco cosas que dan miedo y hablemos de qué son exactamente y por qué no son tan aterradoras una vez que se comprenden correctamente.

1) ¡Ahhh! ¡En Agile no hay fase de diseño!

Con frecuencia, los arquitectos y el personal del departamento de desarrollo se preocupan porque en Agile no existe una fase de diseño explícita. Aunque es cierto que los equipos ágiles evitan fases de diseño al inicio de un proyecto, eso no significa que el diseño se descuide.

El diseño en un proyecto ágil se caracteriza por dos rasgos: es emergente e intencional.

El diseño emergente surge con el tiempo. En lugar de una fase de diseño inicial, el diseño es un proceso continuo. El diseño surge durante la creación del software.

Pero el diseño también es intencional. Esto significa que el diseño no surge por casualidad. El diseño es guiado por los responsables técnicos del proyecto o incluso por un arquitecto específico.

Si estas personas están preocupadas por una parte determinada del sistema, el Product Owner debería priorizar uno o dos [Product Backlog Items]( "Product Backlog Item") de esa área. Esto le da al equipo la oportunidad de conocer mejor esa parte del sistema desarrollando una pequeña porción. Esto ayudará a encontrar el diseño adecuado.

Cuando el diseño surge de esta manera a través de las decisiones del equipo, el hecho de que en Agile no haya una fase de diseño explícita ya no resulta tan aterrador.

2) ¡Socorro! ¡Me estoy convirtiendo en generalista!

Uno de los mitos más extendidos en Agile es que los equipos ágiles no quieren especialistas y, en cambio, prefieren que todos en el equipo sean generalistas.

Esto asusta a muchas personas por dos razones: primero, no a todos les gusta hacer todo tipo de trabajo. Segundo, a menudo existe la preocupación de que pueda afectar la empleabilidad futura si alguien puede hacer cuatro cosas medianamente bien en lugar de una extremadamente bien.

La idea de que todos en un equipo ágil deben ser generalistas es falsa. Si estoy asesorando a un equipo que tiene al mejor experto en JavaScript del mundo, quiero que esa superestrella haga cosas geniales con JavaScript y no que aprenda a ser administrador de bases de datos.

Sí, en los equipos ágiles se desea tener miembros con diversas habilidades: por ejemplo, el tester que también puede escribir algo de código. La opción más sencilla es tener a alguien que pueda realizar ambos tipos de trabajo igual de bien. Si tu equipo, por ejemplo, tiene un desequilibrio entre tareas de programación y pruebas, es útil tener a alguien en el equipo que pueda tanto programar como hacer pruebas.

Un objetivo en Agile es la formación de equipos interdisciplinarios. Esto significa que un equipo posee todas las habilidades para crear un incremento de producto terminado y funcional en una iteración. Pero eso no significa que cada miembro del equipo deba poseer todas las habilidades necesarias en el equipo interdisciplinario.

Si la idea de convertirte en un generalista te pone los pelos de punta, te aliviará saber que los especialistas también son bienvenidos en los equipos interdisciplinarios.

3) ¡Oh no! ¡No tenemos planes ni pronósticos!

Con frecuencia, a los gerentes les estremece la idea de que un equipo ágil no pueda hacer planes ni predicciones más allá de la iteración o Sprint actual.

Afortunadamente, eso no es del todo cierto.

Sí, los equipos ágiles renuncian a la falsa comodidad de proyectos sobreplanificados con diagramas de Gantt confusos y cronogramas exactos hasta un futuro lejano. Sin embargo, eso no significa que los equipos ágiles no sean capaces de planificar y pronosticar el futuro.

Una gran ventaja de los métodos ágiles es que el equipo revisa y ajusta todo el proceso de desarrollo en cada iteración. Toma una idea en forma de una simple User Story e implementa esa funcionalidad. Esto significa que los equipos pueden medir su progreso cada pocas semanas. Así descubren cuánto trabajo pueden realizar.

Comparemos esto con un proyecto de desarrollo tradicional que quizás tiene una fase de análisis, una fase de diseño, una fase de codificación y finalmente una fase de pruebas. Cuando estos equipos quieren medir su progreso, solo pueden determinar qué tan rápido completan una (o quizás dos) de esas tareas. La velocidad con la que un equipo realiza el diseño no dice nada sobre qué tan rápido avanza con el código o las pruebas.

Lo más importante en la transformación ágil es dar la bienvenida a la incertidumbre — admitir que es imposible conocer toda la funcionalidad antes de comenzar el proyecto — y luego elegir una de las muchas formas de adaptarse. Cuando los equipos entienden esto y miden la cantidad de trabajo en cada iteración, esto debería tranquilizar a la dirección y conducir a una planificación confiable.

4) ¡Socorro! ¡Voy a perder mi trabajo!

La idea de una transición ágil de un equipo o de toda una empresa puede asustar bastante a algunos gerentes, ya que muchos temen que su puesto sea innecesario después de la transición.

Eso es comprensible. Por supuesto, sería terrible comenzar una transición sabiendo que esto hará tu propio rol innecesario.

Sin embargo, nunca he ayudado a una empresa con la transformación ágil y he escuchado que se diga: "De acuerdo, ya no necesitamos a las personas con tal o cual rol. Todos serán despedidos." Eso no sucederá. Por supuesto, puede ocurrir que un título de puesto específico ya no sea necesario o adecuado, pero esas personas seguirán teniendo un empleo. De hecho, creo que en la mayoría de los casos terminan con trabajos mejores y más adecuados que antes. Claro, puede ser que algunas personas tengan menos control directo sobre empleados y decisiones y estén frustradas por ello, a veces tan frustradas que abandonan la empresa.

Como nunca he visto que personas con determinados roles o habilidades sean simplemente despedidas durante una transformación ágil, creo que el miedo a ello es tan infundado como el miedo a un apocalipsis zombi.

5) ¡Uhhh! ¡En Scrum hay demasiadas reuniones!

Como la mayoría de las personas, odio las reuniones. En general, lo que me importa es por qué hago lo que hago. La mayoría de los días no tengo ninguna reunión. Qué suerte.

Sin embargo, incluso yo puedo admitir que algunas reuniones son importantes y útiles. Esto incluye las cuatro reuniones estándar en Scrum: el Sprint Planning Meeting, el Daily Scrum, la Review y la Retrospectiva.

Solo pensar en todas estas reuniones hace sudar a algunas personas.

Y el problema con las reuniones de Scrum: tienen un nombre. Cuando algo tiene un nombre, se puede atacar más fácilmente. Según mi experiencia, la mayoría de los equipos tenían más reuniones antes de Scrum. Esas reuniones no tenían nombres y generalmente se realizaban de forma espontánea para aclarar ciertas cosas.

Con un experimento puedes comprobarlo rápidamente. Busca en tu calendario cualquier mes en el que aún no trabajabas con Agile. Suma el tiempo que pasaste en reuniones ese mes. Luego suma el tiempo que ahora pasas en reuniones de Scrum y compara ambas cifras.

Creo que te sorprenderá el resultado. Como las reuniones de antes de la transformación ágil no se celebraban de forma regular y recurrente, no tenían nombres y por tanto no quedaban en la memoria como, por ejemplo, un "Sprint Planning Meeting".

El consejo más importante para no tener miedo de pasar demasiado tiempo en reuniones es mantenerlas cortas. De vez en cuando trabajo con equipos a los que tengo que pedirles que dediquen un poco más de tiempo a sus reuniones.

Sin embargo, la mayoría de los equipos pasan demasiado tiempo en las reuniones de Scrum. Una vez que se logra mantenerlas breves y concisas, no deberían asustar a nadie.

Conclusión: Relájate... ¡estos fantasmas no son reales!

Caminar por una casa embrujada y disfrazarse es divertido porque todos sabemos que todo es una ilusión. Los fantasmas, monstruos, vampiros, hombres lobo y locos con motosierras no son reales.

Y los cinco mitos ágiles descritos aquí tampoco lo son. No hay nada malo en tener un poco de miedo al principio. Sin embargo, la formación y la experiencia desenmascararán rápidamente estos mitos y te darán una sensación de seguridad.

Si quieres hacerte tu propia idea de la realidad ágil y los mitos sobre Scrum y compañía, echa un vistazo a nuestra Agile Journey, donde te presentamos los roles en detalle, o conviértete ahora en Scrum Master certificado o visita nuestro Agile Leadership Training.

Este texto proviene del blog de Mike Cohn y fue traducido al alemán por nosotros.

Innovación en la empresa

=> ¿Qué caracteriza a las empresas innovadoras?

Estrategia vivida

=> Descubre cómo llevar tu estrategia empresarial al siguiente nivel.

Empresas invencibles

=> ¿Cómo es la gestión moderna de la innovación en la empresa?