En demasiadas ocasiones, las empresas se establecen con la misión de "adoptar una metodología ágil" antes de comprender realmente lo que esto significa. Comienzan a aparecer fisuras y se pierden las expectativas, lo que deja a todo el mundo preguntándose cuál es el verdadero valor de "adoptar una metodología ágil" y termina por mermar tus probabilidades de llegar a conseguirlo.
Lo cierto es que adoptar una metodología ágil se traducirá en equipos más productivos y en una entrega de proyectos más rápida, pero solo si todo el mundo puede ponerse de acuerdo sobre las reglas del juego. Únete a Heather Fleming y a Justin Riservato, del gigante de comercio electrónico Gilt, en el debate acerca de por qué lograr un consenso en torno a los principios de la metodología ágil es más importante que implementar un proceso.
Concretamente, Heather y Justin analizan las respuestas a tres preguntas fundamentales que cualquier equipo debe estar preparado para responder antes de embarcarse en el camino hacia la adopción de una metodología ágil:
- "Pero ¿cuándo acabarás?" Por qué deshacerse del concepto de plazos de entrega es la conversación más importante (y la más difícil) que has de mantener a la hora de adaptarte a la metodología ágil.
- "Esa es mi máxima prioridad, pero no puedo reunirme contigo hasta la semana que viene". Qué hacer cuando tu socio de negocio no puede ser (ni será) un miembro de pleno derecho del equipo.
- "Yo solo quiero codificar. ¿Por qué tengo que acudir a todas estas reuniones?" Por qué la implementación de scrum no es el primer paso para adoptar una metodología ágil.
Mira y aprende
Preguntas y respuestas
A continuación, Heather y Justin han seleccionado algunas de las principales preguntas de la sección de preguntas y respuestas de esta presentación. Sigue leyendo para adentrarte más en las tácticas sobre cómo aplicar metodologías ágiles.
P1: Tablero ágil digital frente a tablero ágil físico. ¿Qué opináis sobre ellos?
R1: Realmente, depende de la configuración del equipo. ¿Estáis todos en el mismo lugar? ¿Qué tamaño tiene el equipo? ¿Disponéis de espacio suficiente para un gran tablero físico? Hemos hecho ambas cosas en Gilt, pero hemos comprobado que, a medida que crecemos y ampliamos a decenas de equipos, los tableros ágiles de Jira Software son más prácticos que los tableros físicos. Son más fáciles de configurar y modificar, así como más sencillos de compartir con miembros de equipos remotos. Lo que nos encanta de los tableros físicos es que, sencillamente, no puedes ignorarlos, los tienes delante de ti. Además, son un lugar fantástico para mantener charlas improvisadas sobre el trabajo actual o, si lo prefieres, organizar reuniones rápidas de pie.
P2: ¿Cómo puedes trabajar con un gestor o cliente que no sigue ni comprende el proceso ágil? A veces, me siento como un orientador de workflow sin éxito.
R2: Es importante que pienses acerca del orden de las operaciones. Si estás tratando de trabajar en un proceso ágil con personas que no creen en él, entonces te estás precipitando un poco. Lo más importante para que este proceso funcione es llegar a un consenso acerca de la filosofía antes de ponerla en práctica. Lo hemos logrado en el pasado examinando problemas específicos que un equipo tiene con el proceso actual y resolviéndolos con la ayuda de una metodología ágil. ¿Puedes guiar a tu jefe o cliente por los problemas reales que están tratando de resolver? y ¿cómo lo enfocarías en un marco ágil? ¿Puedes llevarles paso a paso hasta la metodología ágil, en lugar de hacerlo con una gran transformación de todo el proceso? Entonces puedes empezar a mostrar resultados auténticos de esta forma, progresivamente, conforme el equipo va trabajando mejor. Para resumir, aplica un enfoque ágil para adoptar la metodología ágil. ;)
P3: ¿Cómo puedes implementar un proceso ágil cuando el proyecto tiene una oferta fija o un calendario fijo con una lista establecida de requisitos que aplicar?
R3: En primer lugar, es imposible completar un proyecto correctamente con un calendario fijo Y una lista cerrada de requisitos que implementar, así que ¿existe alguna forma de lograr que todo el mundo coincida en que esto es una utopía? La mayoría de las limitaciones en cuanto a plazos y requisitos no son auténticas: son deseos. Empieza debatiendo por qué estás haciendo el trabajo, o cuál es el problema que estás tratando de resolver. Si comprendes realmente los objetivos del proyecto y los motivos de las limitaciones, puedes asegurarte de que el equipo está haciendo lo correcto en el momento apropiado. Anotar todos los requisitos junto con sus fechas no es suficiente para que todos ellos se cumplan mágicamente a tiempo.
P4: La mayoría de los proyectos tienen una fecha de lanzamiento que suele comunicarse a los socios y clientes. En este caso, la única cuestión negociable es el conjunto de características (aunque algunas afectan a la calidad). ¿Cómo puedes trabajar sin incumplir los límites de un plazo determinado?
R4: Creemos que ya has resuelto esta duda por ti mismo; lo consigues negociando el alcance. Si no es así, tienes razón en que la calidad se resentirá. Pensar que puedes interferir en el alcance es un mero sueño. Debes asegurarte de que tus equipos trabajan con la realidad, incluso si esa realidad no es lo que la gente quiere oír. Heather escribió una breve entrada del blog que puedes leer aquí.
P5: ¿Cómo crees que se debería cambiar el modo en que se implementa scrum?
R5: La rigidez de scrum es nuestro mayor problema para conseguirlo. Pensar que un único proceso altamente preceptivo funcionará igual para todos los equipos, independientemente de aquello en lo que estén trabajando y de quiénes son, es presuntuoso. Hemos visto que funciona con algunos equipos, pero scrum no es el único medio para adoptar una metodología ágil, y muchos equipos no lo consiguen porque piensan que tienen que implementar scrum de una forma específica con todas las funciones laborales, historias de usuario, criterios de aceptación, reuniones y piezas previstos. Heather también tiene un problema con el cargo "experto en scrum". ;)
P6: ¿Cómo puedes evitar que las partes interesadas influyan directamente en los miembros del equipo?
R6: Bueno, una buena parte interesada ES un miembro del equipo. Así que, idealmente, trae a la parte interesada clave a tu equipo para que podáis trabajar todos juntos. Si tienes al tipo de parte interesada que solo pone pegas al equipo, o se inmiscuye en el proyecto e intenta cambiarlo todo, es importante que todos los miembros entiendan lo que están haciendo y por qué. Da igual entonces con quién hable la parte interesada, la respuesta será la misma. Eso es lo que os convierte en equipo y no la unión de un grupo de individuos. Debes saber comunicarte —y mucho— y asegurarte de que todo el mundo está en sintonía y remando en la misma dirección.
P7: ¿Estimas las historias basándote en cálculos aproximados de órdenes de magnitud (en horas) o basándote en puntos?
R7: Lo hacemos de ambas formas y algunos equipos ni siquiera realizan estimaciones. Los puntos son fantásticos porque son más abstractos y no están ligados a ninguna fecha específica del calendario. Si tu equipo se resiste a realizar las estimaciones, las horas pueden resultar muy útiles como transición, ya que son valores más tangibles. El propósito de las estimaciones es ser capaz de decir si el sprint es demasiado intenso o ligero, y ajustarlo; además, realmente no sirven para nada una vez que se inicia el sprint. Descubrimos que una vez que has trabajado con un equipo durante un tiempo, el proceso de estimación se vuelve innecesario. Todos podemos ver el trabajo y decir con facilidad si la cantidad es adecuada para el sprint.
P8: ¿Cuánto valor aportas para que los responsables o gestores de proyectos dispongan de las habilidades de análisis exhaustivo y el conocimiento del producto en lugar de, simplemente, coordinar reuniones entre las partes interesadas de las secciones tecnológica y empresarial para recopilar requisitos?
R8: Prácticamente, todo el valor posible. :) Coordinar reuniones o tomar notas, no son habilidades especializadas. Cualquiera puede tenerlas. Aunque es importante que ocurran, no es en realidad el mayor valor añadido que puedes ofrecer al equipo. Si todo lo que haces es trabajo administrativo, entonces el equipo hace bien en preguntarse por qué formas parte de él. Todos los miembros del equipo de gestión de proyectos de Gilt tienen un profundo conocimiento de la materia pertinente, así como de las herramientas y técnicas necesarias para llevar a cabo el trabajo y llevan dichas habilidades con ellos a cada equipo en el que trabajan. Muchos de nosotros éramos ingenieros antes o trabajábamos con otros departamentos de Gilt y traíamos con nosotros una experiencia única en la materia.
P9: Normalmente ¿de qué tamaño son los equipos y qué antecedentes tienen los miembros de Gilt?
R9: Idealmente, queremos que nuestros equipos tengan una estructura sencilla, pero que sean lo bastante grandes como para ser autosuficientes, lo que les permitirá avanzar en sus proyectos sin tener que depender de otros equipos. Seguimos la regla de las "dos pizzas": dos pizzas deben ser suficientes para alimentar a los equipos. Asimismo, creemos firmemente que cada miembro del equipo trae consigo un conjunto de talentos exclusivos, y es preciso que los comparta con el equipo con independencia de cuál sea su cargo. Así que si, tradicionalmente, el propietario del producto es responsable de todas las presentaciones, pero está cansado de ellas, y si hay un ingeniero al que se le da genial contar historias y ganarse al público, vamos a dejar que el ingeniero aporte ese talento al equipo. ¡Eres algo más que un cargo!
P10: ¿Cómo gestionas un equipo de QA independiente, especialmente, en el que las pruebas pueden producirse en un sprint diferente al del desarrollo?
R10: Esta es una de las posturas más controvertidas que adoptamos, pero en Gilt no contamos con un equipo de QA independiente. Creemos en las pruebas de automatización a través del proceso de desarrollo y despliegue. Los equipos son responsables de la calidad del código que entregan. Si tienes el tiempo y la experiencia necesarios para escribir código, también lo tienes para escribir pruebas que permitan comprobarlo. Delegar esta labor en un equipo de QA nunca nos ha dado buenos resultados. Además, es algo que requiere mucha documentación y tiempo adicional para que los equipos de QA se pongan al día.
P11: Si cuentas con equipos que trabajan en varios "productos" a la vez, ¿funcionaría reunir a todos los gestores de productos en la misma sala durante la planificación del sprint y pedirles que determinen las prioridades relativas de todos los productos? ¿Alguna otra idea de cómo hacerlo?
R11: ¡Para! Sin duda, esto no va a funcionar. El equipo debe contar con un gestor de productos propio y no trabajar en varios productos para varios gestores de productos que no forman parte del equipo. Quienquiera que actúe como líder del equipo debería dar un paso adelante aquí y delinear claramente la metodología de priorización del equipo y en qué orden van a abordar la ejecución del trabajo según dicha metodología. Esto se relaciona con nuestra visión de que "tienes que estar alineado con tu metodología antes de poner un proceso en práctica".
P12: Estoy tratando de pasar los servicios creativos de marketing a la metodología ágil. Tenemos algunas entregas que DEBEN realizarse en una fecha determinada (el diseño de un anuncio que debe imprimirse en una revista). ¿Cómo podemos integrar estos proyectos en un marco ágil?
R12: La metodología ágil es capaz de manejar dificultades como esta. Depende del equipo saber identificar qué es lo que hay que hacer y para cuándo, y planear los sprints en consecuencia. La metodología ágil debe ayudarte a cumplir estos plazos, ya que te otorga la capacidad de ajustar tus prioridades y tu trabajo planeado (alcance) para cada sprint. Si empiezas a supervisar tu velocidad, no tardarás en ser capaz de decir lo antes posible si vas a poder cumplir esos plazos o no. A partir de entonces, dependerá de un buen jefe de equipo el poder negociar lo que el equipo necesita para tener éxito.
P13: ¿No puede el cambio de metas parecer corrupción del alcance?
R13: Sí, así es, pero nosotros no lo llamamos "corrupción del alcance" porque queremos promover el cambio durante un proyecto. Una de las mayores ventajas de una filosofía ágil es que te permite adaptarte a las situaciones que se escapan a tu control. Si el entorno competitivo cambia, o si lo hacen las necesidades de tu negocio, o hay nuevas tecnologías disponibles, ¿estás seguro de que quieres seguir adelante con la matriz de requisitos que se creó hace meses? Si quieres ofrecer el mejor producto a tus clientes, acepta el cambio y sácale provecho. En la metodología ágil no existe la "corrupción del alcance" (introduce un truco mental Jedi aquí).
