CAPÍTULO CUARTO
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Invierte en agilidad
Como vimos en el capítulo anterior, para que tus equipos obtengan los beneficios de Agile, tu organización tiene que adoptar la filosofía Agile subyacente. No sólo gastar dinero -eso es comparativamente fácil-, sino hacer cambios reales y significativos en las estructuras, sistemas y comportamientos de la organización.
Si eso suena a mucho trabajo... pues es porque lo es. ¿Son realmente tan importantes estas inversiones?
Sí, realmente lo son.
Invertir en Agile es importante porque estás invirtiendo en cambiar tus limitaciones. La mayor parte de lo que frena a los equipos no son los procesos que utilizan, sino las limitaciones a las que están sometidos. Realiza las inversiones e ignora las prácticas, y tus equipos seguirán teniendo probabilidades de mejorar. ¿Realizar las prácticas e ignorar las inversiones? Tendrán dificultades.
Como dijo Martin Fowler1
Veo un sorprendente paralelismo entre DHH [David Heinemeier Hansson, creador de Ruby on Rails] y Kent Beck [creador de Extreme Programming]. Para cualquiera de ellos, si les presentas un mundo con restricciones, observarán las restricciones que damos por sentadas, las considerarán no esenciales y crearán un mundo sin ellas... simplemente les meten dinamita intelectual por debajo y siguen adelante. Por eso pueden crear cosas como Extreme Programming y Rails, que realmente dan una sacudida a la industria.
Martin Fowler
Haz las inversiones. Son el secreto del éxito Ágil.
Las siguientes secciones describen las inversiones que tus equipos necesitan de tu organización. Es posible que no puedas conseguirlas todas, por lo que he proporcionado alternativas. Pero las alternativas tienen el coste de reducir la eficacia, así que esfuérzate por conseguir todas las que puedas. He incluido sólo las que son importantes.
Dedica tiempo a aprender
Los cambios son perturbadores, y las nuevas ideas tardan en aprenderse. Aprender Agile ralentizará a tus equipos al principio.
¿Cuánto se ralentizarán? No existe una medida objetiva de la productividad del software [Fowler2003], pero por experiencia, yo calcularía un descenso del rendimiento del 10%-20% al principio. A medida que vayan dominando las habilidades ágiles, su rendimiento aumentará. Seguirá aumentando hasta que alcancen la fluidez, y entonces el aumento se nivelará gradualmente, como ilustra la Figura 4-1. Esto se denomina curva J y es común a todos los cambios significativos. Examinaremos más detenidamente el cambio en el Capítulo 5.
La inversión de tiempo suele amortizarse en el primer año. La duración de la inmersión inicial depende de las zonas de fluidez que persiga cada equipo, como se describe en el capítulo anterior. Recapitulando:
-
Focalización: 1-4 meses
-
Entrega: 2-6 meses
-
Optimización: 1-3 meses
Estos periodos se solapan, por lo que un equipo que aprenda a la vez las habilidades de Focusing y Delivering tendrá un bajón de rendimiento que durará unos 2-6 meses. Por el contrario, un equipo que aprenda primero las habilidades de Enfoque y pase después a las de Entrega tendrá dos caídas: una de 1 a 4 meses cuando aprenda las habilidades de Enfoque y otra de 2 a 6 meses cuando aprenda las habilidades de Entrega.
Figura 4-1. Rendimiento ágil a lo largo del tiempo
El rendimiento de los equipos ágiles también cambia de otras formas. Los equipos ágiles se centran en completar las características antes de pasar a la siguiente. Esto es especialmente cierto en los equipos de Entrega, que incorporan la calidad desde el principio en lugar de corregir los errores al final. Esto mejora la producción y el rendimiento, pero -irónicamente- parece una ralentización para las personas que están acostumbradas a ver varias funciones en curso a la vez.
El resultado neto es que las partes interesadas pueden sentirse frustradas por el ritmo del desarrollo Ágil, sobre todo en el primer año, cuando se enfrentan a tres golpes a la vez: un retraso real por el aprendizaje, un retraso percibido por centrarse en hacer las cosas, y el coste de terminar el trabajo anterior a Ágil que se declaró "hecho" sin estarlo realmente.
Esta frustración puede llevar a que los equipos se desvíen del aprendizaje de Agile y se centren únicamente en entregar software, antes de que hayan terminado de aprender. Esto es contraproducente para todos: los equipos se sentirán tironeados y frustrados, y la organización habrá malgastado las inversiones que ha hecho hasta ahora. Antes de que los equipos inicien su viaje Ágil, asegúrate de que los directivos y las partes interesadas están de acuerdo con el descenso de rendimiento del primer año.
Tu organización puede cambiar dinero por tiempo contratando a personas que ayuden a tus equipos. Esto no eliminará la caída del rendimiento, pero la hará más corta y superficial. Hay una gran variedad de ayuda disponible: tutoría ocasional, formación, ayuda con el diseño y la implantación de procesos y formación a tiempo completo. La ayuda más eficaz que puedes obtener es contratar a profesionales experimentados para que entrenen a cada equipo a tiempo completo.
Cuando te plantees a quién contratar, ignora la miríada de sistemas de certificación ágil. Demasiados son un robo de dinero. La mayoría no demuestran nada más que la capacidad de conectar el culo a la silla durante unos días. Algunos se asocian a cursos de formación excelentes, pero eso se debe al formador, no a la certificación, así que evalúa los cursos de formación independientemente de las certificaciones que pregonen. Lo mismo ocurre al contratar consultores y entrenadores. Pide recomendaciones a tu red, prueba los materiales disponibles al público y comprueba las referencias.
A medida que apliques las prácticas de este libro, es probable que te encuentres con problemas y retos específicos de tu situación. Asegúrate de tener un mentor al que puedas acudir para plantearle tus dudas. Esto no tiene por qué costar dinero; un colega respetado en una empresa que lo haya hecho antes, un grupo local de usuarios o un foro en Internet son buenas opciones.
Si no hay tiempo para aprender...
Puedes hacer que la caída de rendimiento sea menos notable, a costa de un mayor gasto general, empezando sólo por la zona de Enfoque y facilitando el enfoque Ágil en hacer las cosas.
Si tu organización no acepta ninguna bajada de rendimiento, no es un buen momento para invertir en el cambio. Si nunca parece ser un buen momento, es una gran señal de alarma. Tendrás que convencer a la dirección de que dedique tiempo al cambio antes de continuar.
Si no hay presupuesto para ayuda...
Con este libro, los muchos recursos gratuitos disponibles en Internet y dedicación al aprendizaje, tus equipos pueden aprender por sí mismos todo lo que necesitan saber. La ayuda externa es, bueno, útil, pero no es necesaria.
Elegir o crear equipos ágiles
No puedo exagerar la importancia de los equipos en una organización Ágil. La mayoría de las organizaciones consideran a las personas su "recurso" fundamental para producir trabajo. En Agile, los equipos son el recurso.
Tu organización necesita invertir en equipos que lo sean:
-
Multifuncional. Las personas del equipo tienen colectivamente toda la experiencia necesaria para que el equipo cumpla su propósito.
-
Totalmente dedicados. Los especialistas pueden venir a ayudar de vez en cuando, pero los miembros del equipo principal se dedican exclusivamente a su equipo.
-
Colaboración. Los miembros del equipo mantienen relaciones amistosas y colegiadas y colaboran estrechamente.
-
Larga duración. Los miembros de un equipo pueden tardar meses en descubrir cómo trabajar juntos de la forma más eficaz, así que mantén los equipos unidos el mayor tiempo posible.
El tamaño y la composición de cada equipo dependen de las zonas de fluidez que persigas. "Todo el equipo" tiene los detalles, pero brevemente:
-
Los equiposde enfoque se centran en conseguir resultados empresariales. Necesitan personas con la capacidad de ponerse en el lugar de los usuarios y clientes para determinar exactamente lo que hará el software. Si el objetivo del equipo está centrado en el usuario, eso incluye a personas con conocimientos de UI/UX. Los equipos también necesitan una forma de determinar en qué trabajar a continuación. Aunque lo mejor es que el equipo incluya a personas con la habilidad y la autoridad para hacerlo por sí mismas, los miembros del equipo también pueden trabajar con alguien de fuera del equipo.
-
Los equipos deentrega asumen la responsabilidad de la entrega integral de su software. Necesitan todos los conocimientos necesarios para crear e implementar su producto. Las responsabilidades que antes se transferían a otros equipos deben incorporarse al equipo. Esto incluye la gestión de la creación, la arquitectura y administración de datos, las pruebas y las operaciones.
-
Los equipos deoptimización asumen la responsabilidad del éxito empresarial general de su producto. También asumen la responsabilidad de coordinarse con las partes interesadas y decidir las prioridades del producto. Necesitan miembros del equipo que tengan experiencia en el negocio, el mercado y el producto.
Puede que ya tengas equipos que se ajusten a lo que necesitas. Si vas a crear nuevos equipos Ágiles, sigue los pasos siguientes. En cualquier caso, recuerda conseguir la participación de los equipos, como se describe en "Conseguir la participación de los equipos".
-
Decide la finalidad de cada equipo. (Ver "Finalidad") .
-
Decide cuántas personas habrá en cada equipo, en función de lo valioso que sea el propósito del equipo, sujeto a los límites de tamaño descritos en "Equipo completo".
-
Determina qué habilidades necesita cada equipo.
-
Elige a personas que tengan las habilidades que necesita cada equipo, que probablemente trabajen bien juntas y que estén dispuestas a probar el Ágil.
Si vas a crear o reorganizar muchos equipos, considera la posibilidad de utilizar la autoselección de equipos. Es sorprendentemente eficaz para crear equipos altamente productivos que están entusiasmados por trabajar juntos. El libro Crear grandes equipos: How Self-Selection Lets People Excel [Mamoli2015] describe cómo funciona.
Si no puedes dedicar personas a sus equipos...
Agile depende de una estrecha colaboración, y eso no funciona bien si la gente no está disponible. Las responsabilidades externas ocasionales están bien, pero si no puedes conseguir miembros del equipo dedicados, probablemente Agile no funcione.
Si los miembros del equipo no se llevan bien...
Es normal que los equipos nuevos pasen por una mala racha mientras descubren cómo trabajar juntos, así que no te preocupes si un equipo tiene dificultades al principio. El entrenador y el director del equipo pueden ayudar a mediar en los conflictos. Para más información, consulta "Dinámica de equipo".
Si no puedes crear equipos duraderos...
Es un despilfarro romper equipos de alto rendimiento, pero no impedirá que tus equipos sean Ágiles.
Si no puedes conseguir la experiencia empresarial, de cliente o de usuario que necesitas...
Los equipos deoptimización necesitan al menos un miembro del equipo con conocimientos de gestión de productos, pero no necesitan necesariamente un gestor de productos tradicional. A veces, los desarrolladores con mucha historia en la empresa conocen su producto y su mercado mejor que nadie. Si ese es el caso, estás listo.
Si tus equipos no persiguen la fluidez de Optimización, no necesitas un jefe de producto directamente en el equipo, pero sigues necesitando a alguien con esas habilidades para que trabaje estrechamente con el equipo, y sigues necesitando miembros del equipo que puedan representar las perspectivas del cliente y del usuario.
La implicación empresarial marca una gran diferencia en el éxito del equipo. Es una de las cosas que diferencia a Agile de sus predecesores. Haz un esfuerzo adicional para incluir las perspectivas de la empresa, el cliente y el usuario en tus equipos. Si no lo haces, es probable que el software que entreguen resulte decepcionante.
Si no puedes conseguir todas las habilidades de desarrollador que necesitas...
Puede que no seas capaz de alcanzar la fluidez de la Entrega, pero sigue mereciendo la pena aprender y utilizar las prácticas de la Entrega.
Elegir entrenadores ágiles
Cada equipo necesita un entrenador que ayude a sus miembros a aprender a ser un equipo Ágil eficaz. "Habilidades de Coaching" tiene los detalles, pero brevemente:
-
Todo equipo necesita a alguien que pueda ayudar a sus miembros a aprender a ser un equipo eficaz y compenetrado.
-
Los equipos deFocusing necesitan a alguien que les enseñe las prácticas de planificación descritas en la Parte II.
-
Los equipos deentrega necesitan a alguien que les enseñe las prácticas técnicas descritas en la Parte III.
-
Los equipos deoptimización necesitan a alguien que les enseñe las prácticas de desarrollo empresarial descritas en la Parte IV.
Algunos entrenadores pueden cubrir varias categorías. Cada entrenador puede trabajar con uno o dos equipos.
Si no puedes contratar a los entrenadores que necesitas...
Puedes crear tus propios entrenadores Ágiles. Elige a profesionales senior a los que los miembros del equipo respeten y en los que confíen -si no son inmediatamente obvios, pide recomendaciones a tus equipos- y pídeles que acepten el reto. Este libro tiene todo lo que necesitan para empezar. Los entrenadores-jugadores que se dedican por completo a un solo equipo son tu mejor opción.
Delegar autoridad y responsabilidad en los equipos
El respeto por la capacidad de las personas es fundamental en la filosofía Agile, y en ningún lugar es más evidente que en el enfoque Agile de la autoridad y la responsabilidad.
Una ejecución de primera categoría consiste en acertar en los detalles, y nadie conoce mejor los detalles que las personas que realmente hacen el trabajo... Cuando están equipados con la experiencia necesaria y guiados por un líder, tomarán mejores decisiones técnicas y mejores decisiones de proceso que las que cualquiera pueda tomar por ellos. [Poppendieck2003]
Mary y Tom Poppendieck
Desde una perspectiva de inversión organizativa, esto significa:
-
El trabajo se asigna a equipos, no a individuos. Los equipos deciden por sí mismos cómo dividir su trabajo en tareas, y quién del equipo realizará esas tareas. Puede que tengas que cambiar los sistemas de tickets y otros procesos de flujo de trabajo para adaptarlos a este enfoque. Hacerlo tiene implicaciones para las evaluaciones del rendimiento, lo que enlaza con "Cambiar las políticas de RRHH perjudiciales".
-
Los equipos deciden sus propios procesos. En concreto, los equipos deben tener libertad para utilizar su propio enfoque de planificación, ligero y sin herramientas, en lugar de estar atados a una herramienta corporativa. La dirección puede poner restricciones a los procesos de los equipos, pero debe asegurarse de que cada restricción tenga una razón claramente articulada.
-
Los equipos de enfoque trabajan con las partes interesadas para comprender las necesidades y prioridades de la empresa. La organización debe asegurarse de que los equipos tienen fácil acceso a las partes interesadas o a sus representantes.
-
Los equipos de entrega controlan sus procesos de desarrollo, creación, prueba y lanzamiento. Una vez más, la dirección puede poner restricciones a estos procesos, como imponer el uso de un proceso de publicación corporativo, pero asegúrate de que los equipos tienen la capacidad de desarrollar y publicar por sí mismos sin esperar a otros equipos.
-
Los equipos de optimización controlan su propio presupuesto y sus planes de producto. La dirección define el propósito de cada equipo, determina la estrategia general y fija los presupuestos de los equipos. También proporcionan supervisión en forma de revisión de los indicadores empresariales. Dentro de ese marco, la organización debe permitir que los equipos individuales decidan por sí mismos cómo alcanzar su propósito y gastar su presupuesto.
Si el trabajo debe asignarse a personas...
Si tu organización no se siente cómoda con que los equipos tomen sus propias decisiones de asignación de tareas, tu organización carece de la confianza que requiere Agile. Quizá puedas convencer a la gente de que cambie su forma de pensar probando el trabajo en equipo con un equipo Ágil piloto, pero procede con cautela. Los estilos de gestión de mando y control suelen ser incompatibles con Ágil.
Si no se trata de un problema generalizado, sino sólo de unos pocos directivos individuales a los que les cuesta soltar lastre, consulta "Cambiar el estilo de dirección del equipo".
Si las herramientas no apoyan el trabajo en equipo...
Si tu empresa dispone de sistemas de asignación de trabajo difíciles de cambiar, una solución a corto plazo es crear una persona "fantasma" para cada equipo que reciba las asignaciones de equipo. Como alternativa, los miembros del equipo pueden elegir tratar las asignaciones individuales como asignaciones de equipo.
A largo plazo, es mejor arreglar las herramientas.
Si los equipos tienen que utilizar una herramienta corporativa de seguimiento...
Una de las mayores fuentes de apalancamiento de los equipos ágiles es la capacidad de mejorar y agilizar su proceso. Las herramientas corporativas de seguimiento, incluidas las denominadas herramientas de Gestión del Ciclo de Vida Ágil, limitan el apalancamiento de los equipos. Al igual que muchos de los productos que compiten por un puesto en el carro de la Agilidad, estas herramientas tienden a perder tanto el sentido de la Agilidad que, en realidad, reducen la agilidad de los equipos.
Obligar a los equipos Ágiles a utilizar una herramienta corporativa de seguimiento para su trabajo diario disminuirá su rendimiento. Si no tienes elección al respecto, una solución común es mantener dos sistemas de seguimiento: un enfoque Ágil ligero y la herramienta corporativa. Consulta "Herramientas corporativas de seguimiento" para más detalles.
Si los equipos no tienen acceso a las partes interesadas...
A diferencia de los procesos en cascada, que utilizan una fase inicial de análisis de requisitos y negocio, los equipos ágiles trabajan con las partes interesadas a lo largo del desarrollo para perfeccionar los planes y recabar opiniones. Sin acceso a las partes interesadas, no construirán lo correcto.
Si un equipo no puede trabajar con uno o más grupos de interesados, asegúrate de que tiene acceso a alguien que represente los intereses de esos grupos. Elige a esa persona con cuidado: la calidad del producto del equipo dependerá de la disponibilidad de esa persona y de su capacidad para representar con precisión las necesidades de las partes interesadas.
Si los equipos de entrega no tienen control sobre sus procesos de lanzamiento...
No verás todo el beneficio de la fluidez de la Entrega hasta que tus equipos tengan control sobre sus procesos de lanzamiento. Dicho esto, hay suficiente valor en las prácticas de Entrega como para que merezca la pena perseguir la zona. Con el tiempo puedes ir eliminando el problema.
Si los equipos de optimización no tienen control sobre sus planes de productos y gastos...
Los equipos deOptimización necesitan la capacidad de realizar experimentos y adaptar sus planes, y eso requiere que controlen sus planes y gastos. Sin ello, no alcanzarán la fluidez Optimizadora.
Cambiar el estilo de dirección del equipo
Dado que los equipos deciden su propio proceso, realizan sus propias asignaciones de tareas y se coordinan con las partes interesadas, los jefes de equipo podrían pensar que no hay lugar para ellos en Agile. Pero eso no es ni remotamente cierto. El trabajo del gestor de un equipo Ágil cambia, pero no es menos importante que en un equipo preÁgil. Consulta "Gestión" para más detalles.
Habla con los jefes sobre su nuevo papel e imparte la formación necesaria. Asegúrate de que las expectativas de sus jefes han cambiado en consonancia.
Si a los directivos les cuesta soltarse...
La microgestión es molesta, pero no es un obstáculo a corto plazo. Sin embargo, inhibe el aprendizaje, al quitar las decisiones de las manos de los miembros del equipo. Los microgestores aumentarán el tiempo y el coste necesarios para alcanzar la fluidez.2
Los directivos suelen microgestionar cuando no saben qué más hacer, o cuando temen que no haya sitio para ellos en un entorno ágil. Asegura a los directivos que siguen teniendo un papel mostrándoles cómo es ese papel. La formación o un buen coach Ágil pueden ayudar.
Crear Salas de Equipo
Los equipos ágiles son muy colaborativos y se comunican constantemente. Para que esa comunicación sea eficaz, necesitan una sala de equipo diseñada para sus necesidades. Puede ser física o virtual. "Sala de Equipo" tiene los detalles.
Para los equipos presenciales, crear salas de equipo físicas puede ser una de las inversiones más caras que harás. También es una de las más valiosas; como se explica en "Team Room", las salas de equipo físicas actúan como multiplicadores del rendimiento.
Sin embargo, cuando tus equipos están empezando, puede que aún no sepas qué tipo de salas de equipo necesitan, o incluso si Agile es una buena opción a largo plazo. Probablemente tus equipos tampoco. Los equipos nuevos en Agile subestiman lo mucho que disfrutarán colaborando y sobrestiman su deseo de privacidad.
Así que no pasa nada por apostar por espacios de trabajo físicos. Reserva el presupuesto para ello -con el tiempo necesitarás buenas salas de equipo, si sigues con Agile-, pero a corto plazo, puedes requisar una gran sala de conferencias o parte de una oficina diáfana para cada equipo.
Decidas lo que decidas hacer, empieza a trabajar en ello pronto. Las salas físicas de los equipos tardan mucho tiempo en organizarse.
Si un equipo es remoto...
Puedes crear una sala de equipo virtual. En "Salas de equipos virtuales" se describe cómo.
Si no puedes crear una sala de equipo física para un equipo presencial...
Los equipos presenciales también pueden utilizar salas de equipo virtuales, pero lo desaconsejo encarecidamente. Experimentarán lo peor de ambos mundos: la inflexibilidad y los desplazamientos del trabajo presencial, combinados con los problemas de comunicación del trabajo a distancia.
Establecer un propósito favorable al aprendizaje para cada equipo
Todo equipo tiene un propósito: su lugar en la estrategia general de la organización. (Ver "Propósito".) Cuando un equipo está aprendiendo Ágil por primera vez, es importante elegir un propósito que ayude a los miembros del equipo a aprender. En la práctica, esto significa tres cosas
-
Un propósito que sea valioso, pero no urgente. Si el equipo está sometido a mucha presión de tiempo, sus miembros tendrán problemas para aprender. Recurrirán por defecto a lo que les ha funcionado en el pasado, en lugar de dedicar tiempo a aprender nuevas ideas.
-
Un propósito que sea autónomo. Cuanto más dependa el equipo de otros equipos, más problemas de coordinación tendrá. Algunos problemas de coordinación son de esperar, pero demasiados distraerán al equipo del aprendizaje.
-
Una base de código nueva. Los equipos que están aprendiendo las prácticas de Entrega tienen mucho que aprender, y es más fácil hacerlo con código nuevo. Dicho esto, en algún momento tendrán que aprender a trabajar con código existente. Los equipos que tengan un entrenador experimentado en Entregar pueden ignorar este requisito, si el entrenador está de acuerdo. También pueden hacerlo los equipos que no estén aprendiendo prácticas de Entrega.
Si hay un plazo importante...
Cada equipo necesita mucho tiempo para aprender. Si el plazo deja mucho margen de maniobra, estás bien. Si no, suele ser mejor retrasar el intento del Ágil hasta que se cumpla el plazo, o elegir equipos diferentes.
Si no hay trabajo valioso que hacer...
Es más importante que los equipos hagan un trabajo valioso que tener una base de código de campo verde. Sin embargo, sin un entrenador experimentado, es probable que los equipos que aprenden las prácticas de Entrega por primera vez tengan dificultades con el código preexistente. Prepárate para una bajada de rendimiento más prolongada, más tiempo necesario para alcanzar la fluidez y más frustración por parte de los programadores del equipo.
Sustituir los supuestos de gobernanza en cascada
La gobernanza es la forma de aprobar, seguir y gestionar el trabajo a alto nivel. Las políticas de gobernanza de la mayoría de las organizaciones asumen un enfoque de desarrollo en cascada. A veces esto requiere documentación previa o puertas de fase. A menudo requiere un enfoque predictivo de la planificación.
Para obtener los mejores resultados, hay que cambiar las políticas de gobernanza para adaptarlas al enfoque Ágil. Eso significa eliminar las puertas de fase y utilizar un enfoque adaptativo de la planificación. Consulta "Gobernanza Ágil" para más detalles.
Si se requiere una gobernanza en cascada...
Es un despilfarro y restará agilidad a tus equipos, pero puedes adherirte a las políticas de gobernanza en cascada si lo necesitas. Está bien para unos pocos equipos piloto, pero cambia a una gobernanza Ágil antes de extender más el Ágil.
La exigencia de gobernanza más común es elaborar un plan y un presupuesto fijos por adelantado. La forma más sencilla de satisfacer esta exigencia es utilizar cualquier enfoque que utilices ahora, y luego iniciar la parte Ágil del proceso después de haber pasado por la aprobación del proyecto. Alternativamente, para los equipos que dominen las zonas de Enfoque y Entrega, puedes asignar de 4 a 8 semanas para la "planificación", empezar a trabajar normalmente y marcar una hoja de ruta de alta calidad. (Véase "Hojas de ruta") .
Otra documentación previa, como un documento de análisis de requisitos o un documento de diseño, también puede hacerse utilizando los enfoques existentes antes de comenzar la parte Ágil de tu trabajo. El trabajo de conformidad restante puede programarse normalmente junto con tu trabajo Ágil, con historias (ver "Historias"), como cualquier otra solicitud.
La gobernanza en cascada es incompatible con la fluidez Optimizadora, que se basa en la planificación adaptativa. Si se te exige que te adhieras a las políticas de gobernanza en cascada, limita tus aspiraciones a las zonas Enfocar y Entregar.
Cambiar las políticas de RRHH perjudiciales
Agile es un deporte de equipo y, a pesar de que el trabajo en equipo es de boquilla, muchas empresas tienen políticas que involuntariamente lo desalientan. Cualquier política que ponga a la gente a competir entre sí dificultará el trabajo Ágil. Un ejemplo especialmente destructivo es la jerarquización, en la que se evalúa a los miembros del equipo en relación con los demás, ascendiendo a los primeros y despidiendo a los últimos, independientemente de su rendimiento real.
Un problema relacionado es el de los directivos que sólo valoran los resultados tangibles. En un equipo ágil, hay muchas formas de contribuir al éxito, como la persona que no escribe mucho código, pero pasa mucho tiempo reproduciendo errores, o la persona que trabaja en segundo plano para mejorar la comunicación.
Las organizaciones también pueden desarrollar la cultura de la culpa, que responde a los errores castigando a los culpables. La mentalidad Ágil, por el contrario, trata los errores como una oportunidad de aprendizaje. Por ejemplo, una organización no Ágil podría despedir a un programador por borrar accidentalmente una base de datos de producción crucial. En cambio, una organización Ágil se preguntaría: "¿Qué controles y equilibrios podemos establecer para evitar el borrado accidental de bases de datos y cómo podemos facilitar la recuperación de este tipo de errores?"
Este tipo de cuestiones culturales suelen reflejarse en las políticas de RRHH sobre ascensos y recompensas. Si las carreras de las personas dependen de quedar bien, independientemente de su efecto real en el rendimiento del equipo, es probable que tus equipos tengan problemas con el énfasis de Agile en el trabajo colaborativo.
No podrás cambiar la cultura de tu organización de la noche a la mañana, pero puedes trabajar para cambiar las políticas de RRHH, y los directivos pueden cambiar la forma en que tratan a sus equipos. Esto llevará tiempo, así que empieza a trabajar en ello pronto. Es probable que necesites el respaldo de la alta dirección.
Resulta útil buscar formas creativas de aplicar las políticas existentes, en lugar de eliminarlas por completo, lo que puede resultar más difícil. Recuerda también que los directivos suelen tener discrecionalidad a la hora de aplicar las políticas, así que si oyes que algo "no se puede hacer", puede que tengas que convencer a un directivo, no a RRHH.
Si las políticas de RRHH están grabadas en piedra...
Si no puedes cambiar las malas políticas de RRHH, los directivos tendrán que proteger a sus equipos de ellas. Asegúrate de que están de acuerdo con Agile y de que saben navegar por la burocracia corporativa.
Si tienes muchos equipos, limita tu piloto Ágil a los equipos con gestores expertos. Utiliza sus experiencias para motivar los cambios de política que necesitas.
Abordar los problemas de seguridad
Esta inversión no suele ser un problema, pero cuando lo es, te parará en seco. Así que infórmate, sobre todo si trabajas en un sector sensible a la seguridad.
El problema es que los equipos presenciales que utilizan prácticas como el "Pair Programming" y el "Mob Programming" trabajan juntos en el mismo ordenador. Esto puede ser preocupante desde el punto de vista de la seguridad, porque la persona que ha iniciado sesión en el ordenador no siempre es la que está ante el teclado. De hecho, la persona que se conectó puede incluso alejarse un momento para ir al baño o mantener una conversación. Dado que las personas cambian con frecuencia de persona que teclea -incluso cada pocos minutos-, no es factible cerrar la sesión y volver a entrar cada vez que hay una nueva persona al teclado.
Si tus equipos van a utilizar esas prácticas, consúltalo con el equipo de seguridad de tu empresa y trabaja con ellos para resolver sus dudas. Normalmente puedes encontrar una forma creativa de apoyar el trabajo ágil sin dejar de ser seguro. Un enfoque habitual es crear una cuenta de desarrollo compartida y bloqueada. Algunas empresas combinan esto con estaciones de trabajo de desarrollo dedicadas o máquinas virtuales basadas en servidores compartidos. El correo electrónico y otros trabajos individuales se realizan en portátiles asignados individualmente.
Una cuestión relacionada es la trazabilidad. Algunas empresas exigen que cada confirmación sea trazable hasta sus autores originales. Puedes cumplir este requisito añadiendo las iniciales o direcciones de correo electrónico de los autores al comentario de confirmación. Git tiene la convención de añadir Co-authored-by líneas al final del mensaje de confirmación.3
Algunas empresas exigen que se revise todo el código antes de liberarlo. El emparejamiento y el mobbing cumplen este requisito, pero puede que tengas que modificar las herramientas para permitir que el código se libere sin una fase de revisión separada. Si eliminar por completo el requisito no es una opción, tal vez puedas modificar la herramienta para omitir las confirmaciones que tengan coautores.
Si no hay flexibilidad en torno a los requisitos de seguridad...
Puedes exigir que la persona que ha iniciado la sesión permanezca en su ordenador. Si necesita alejarse un momento, o bien cambia de inicio de sesión, o el trabajo se detiene hasta que vuelva. Esto introduce más fricción de la que cabría esperar, así que prefiere soluciones que permitan que el trabajo continúe.
Los equipos también pueden utilizar herramientas diseñadas para el trabajo remoto colaborativo en lugar de trabajar en el mismo ordenador. Esto introduce mucha más fricción que las otras opciones, incluso cuando los miembros del equipo están sentados uno al lado del otro, así que no lo recomiendo a menos que tu equipo ya sea remoto.
Si te exigen un paso separado de revisión del código...
El código escrito por una pareja o grupo ya ha sido revisado por pares, así que los equipos pueden aprobar las revisiones de ese código. Sin embargo, esto añade fricción, por lo que es mejor eliminar este requisito antes de difundir ampliamente el Ágil.
1 Extraído del artículo "Enterprise Rails" de Fowler.
2 Gracias a George Dinwiddie por señalar este punto.
3 Gracias a Jay Bazuzi por llamarme la atención sobre estas convenciones de los mensajes de confirmación.
Get El Arte del Desarrollo Ágil, 2ª Edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
