¿Puede un equipo tener 150 personas en él? RÁPIDO Ágil dice que sí

FAST Agile es la práctica organizacional más interesante que he aprendido en mucho tiempo. Hoy comparto qué es FAST Agile y exploro si vale la pena experimentar con él. TL;DR? Bastante convincente, pero todavía experimental.

¿Qué es FAST Agile?

1. FAST Agile es una variante de software ágil. FAST se centra en la autoorganización dentro de equipos muy grandes. Estos grandes equipos se denominan Colectivos. Pueden ser unas pocas personas, hasta 150 personas [1].

Dos veces por semana, el Colectivo se reúne. En la reunión:

• Los miembros del equipo muestran y cuentan el progreso que han logrado .
• El líder del producto reitera la visión y establece la dirección . Dan contexto a los mejores proyectos. Introducen nuevas prioridades a medida que se completa el trabajo o cambian las prioridades. Y normalmente muestran las prioridades de forma visual, en una pared o equivalente virtual.
• Las personas dentro del Colectivo se autoorganizan y se autoseleccionan en equipos más pequeños para entregar el trabajo de mayor prioridad.

La parte más interesante de FAST Agile son estos equipos autoorganizados, así que describámoslos con un poco más de detalle.

En cada reunión, las personas se ofrecen como voluntarias para liderar equipos y las personas se ofrecen como voluntarias para participar en esos equipos. Cuando alguien se ofrece como voluntario para administrar un equipo, da un paso al frente y dice: “Voy a trabajar en [uno de los mejores proyectos]”. Luego, las personas se unen a los equipos que se han creado y trabajan en esa área. El tamaño mínimo del equipo es de dos, por lo que necesita que la gente "vote con los pies" para formar el equipo.

Los equipos formados hacen no tiene que estar en torno a las prioridades que el producto ha establecido. Por ejemplo, se puede formar un equipo para mejorar la tubería de implementación o mejorar el monitoreo de algunos servicios inestables.

Fuera de la hora a la semana en las reuniones, las personas pasan la mayor parte de su tiempo en sus equipos autoorganizados y autoseleccionados. Teóricamente, podrías cambiar de equipo dos veces por semana. Pero en la práctica, las personas terminan descubriendo con quién les gusta trabajar, y los equipos tienden a establecerse después del primer mes más o menos .

Permanecen lo suficientemente fluidos como para que las personas puedan moverse a medida que cambian las necesidades comerciales, o se necesitan personas con experiencia en diferentes áreas. Mover equipos es un cambio esperado y de bajo esfuerzo. Entonces, lo que esto significa es que durante las reuniones del Colectivo, hay un patrón de personas que recrean sus equipos, pero la composición tiende a no cambiar tanto como podrías imaginar.

Hay muchos otros detalles, como cómo se manejan los errores y las guardias. Abordaré algunos de estos temas más adelante. Pero el núcleo básico de FAST Agile son estos equipos de autoselección, trabajando dentro de un Colectivo más grande, en proyectos. Las reuniones del Colectivo están estructuradas y enfocadas en brindar contexto sobre las necesidades del negocio y comunicar el progreso en relación con esas prioridades.

Resumen de diferencias

FAST es muy diferente a la forma en que funcionan la mayoría de las organizaciones de software ágiles en la actualidad. Aquí están las diferencias como las veo:

Como puede ver, FAST es un enfoque muy diferente al que están haciendo la mayoría de las empresas hoy en día.

Entonces, ¿cuáles son las compensaciones?

Tal como lo veo, estas son las ventajas y desventajas de FAST Agile:

• FAST puede ofrecer una mejor escalabilidad organizacional
• FAST se puede experimentar de forma incremental
• FAST debería resultar en menos reorganizaciones
• FAST hace que sea más fácil responder a las prioridades cambiantes
• FAST podría ser mejor para la motivación intrínseca y la retención

Pero…

• Muchos entornos son incompatibles con FAST
• Es posible que deba administrar la autogestión
• FAST requiere mucho trabajo
• Los materiales FAST están llenos de jerga

Discutiremos cada uno de estos a su vez.

FAST puede ofrecer una mejor escalabilidad organizacional

Cuando escala organizaciones, normalmente lo hace al escalarlas "horizontalmente". Haces crecer la organización un equipo a la vez. Cada uno de estos equipos posee una porción del producto y, a menudo, tiene una organización de plataforma que hace que los equipos de productos sean más efectivos.

La complejidad de la organización estalla a medida que aumenta el número de personas. Si tiene diez personas en ingeniería, todas pueden comunicarse entre sí. Cien personas en ingeniería no pueden hablar entre sí. Y el código base no cabrá en la cabeza de ningún individuo. Entonces, segmenta esta complejidad en equipos, y cada equipo tiene un área en la que puede concentrarse.

FAST es interesante porque es un intento de escalar organizaciones “verticalmente”. En lugar de agregar más equipos, FAST intenta crear equipos más grandes , llamados Colectivos. Los Colectivos aún poseen código, pero los equipos autoorganizados dentro de ese Colectivo no. Y todavía tienes que segmentar la comunicación. Pero los equipos son más dinámicos y evolucionan continuamente. En lugar de remodelar equipos a través de reorganizaciones, es una parte continua y esperada de la forma en que opera.

El tamaño del equipo es un tema familiar para muchos jefes de ingeniería. ¿Qué tamaño deben tener los equipos? Profundicemos un poco en este tema, ya que nos ayuda a comprender cómo FAST pretende escalar mejor.

¿Qué tamaño deben tener los equipos?

Cuando pasa tiempo con la gente del vicepresidente de ingeniería, de vez en cuando surge el tema del tamaño del equipo de ingeniería. Escuchará argumentos para equipos pequeños y argumentos para equipos grandes. Ambos lados tienen méritos.

Ventajas de los equipos pequeños

• Menos gastos generales de coordinación y comunicación dentro del equipo.
• Puede moverse rápidamente como resultado.
• Menos flujos de trabajo, por lo que es más fácil concentrarse y producir resultados.
• Más fácil de manejar.

Ventajas de los equipos grandes

• Organización más plana. Una organización de ingeniería con 150 ingenieros tendrá de 3 a 4 directores con equipos de diez personas. Tendrá de 6 a 8 directores y de 1 a 2 vicepresidentes con equipos de cinco personas. ¿De dónde viene la confusión en una organización? Probablemente el liderazgo, por lo que los equipos grandes pueden reducir la confusión.
• Más resiliencia. Alguien puede tomar vacaciones y el equipo puede continuar bien.

Los equipos pequeños son geniales dentro de su equipo, pero menos ideales porque hay tantos que aumentan la complejidad organizativa. Los equipos más grandes son mejores para la complejidad organizativa general, pero menos ideales para el rendimiento dentro de cada equipo.

El enfoque que adoptan muchos líderes es formar equipos grandes que se centren en menos flujos de trabajo. Esto reduce la complejidad del equipo interno y también reduce la complejidad organizativa.

Puede ver FAST como un enfoque que intenta lograr una simplicidad organizativa aún mayor a través de equipos ridículamente grandes. Y también trató de obtener los beneficios de tener pequeños equipos de autoensamblaje.

Escalar organizaciones es un trabajo desafiante

Gran parte de mi negocio de consultoría es ayudar a las organizaciones a lidiar con la escala. Hay varias fases de los desafíos de escalamiento a los que se enfrentan las organizaciones.

La primera barrera suele estar en la marca de ingeniero 15-25. Este es el momento en que su ameba se ha vuelto demasiado grande y necesita dividirse. Ves este tipo de problemas:

• Los canales de comunicación se vuelven ineficaces.
• Ingeniería comienza a tener problemas de entrega y/o calidad.
• Los gerentes o líderes se sienten abrumados. Agregar más personas empeorará las cosas, no las mejorará.

Y una segunda barrera está en torno a los sesenta ingenieros. En este punto, empiezas a ver muchos más problemas de coordinación :

• Los proyectos entre equipos rara vez tienen éxito.
• El trabajo del producto inunda los equipos de la plataforma, o viceversa.
• Incapacidad para completar grandes iniciativas.

He visto a personas brillantes fallar una y otra vez al navegar estos cambios escalonados en la complejidad organizacional. Mi corazonada es que estos aumentos en el orden de los pasos en complejidad corresponden a cuando agrega una capa adicional de administración.

El crecimiento de las organizaciones de ingeniería es una habilidad real. Requiere una comprensión profunda de cómo funcionan las organizaciones y las personas. Aprendes cosas como:

• Modelos de coordinación para lograr que grupos de personas trabajen juntas.
• Equipos alineados con flujo versus equipos diseñados funcionalmente.
• Cómo hacer reorganizaciones, donde cambias a las personas y codificas a medida que cambian las prioridades comerciales.
• Cómo dividir los productos en áreas de responsabilidades técnicas que se superponen con la inversión en productos.
• Establecimiento de canales de comunicación en torno a los equipos.
• Configuración de programas de guardia y confiabilidad para respaldar su producto de manera efectiva.
• Establecer organizaciones de plataforma e iniciativas de experiencia de desarrollador para combatir la complejidad.
• Etc.

Incluso si tiene personas con esta experiencia, se requiere mucho esfuerzo de su equipo de administración para lidiar con la escalabilidad. Entonces, si FAST puede escalar mejor, desbloqueará gran parte del potencial de su equipo de administración para enfocarse en otra cosa. Y, debido a que los cambios en el orden de los pasos ocurren con mucha menos frecuencia, podría estar haciendo que su organización sea mucho más fácil de administrar.

Un experimento mental en torno a FAST Agile

Entonces, imagina que puedes escalar el tamaño del equipo. En lugar de equipos de cinco o diez personas, ¿qué pasaría si pudieras tener equipos efectivos de veinte personas? ¿O equipos de sesenta personas?

A primera vista, esta es una proposición ridícula. Los equipos tan grandes no son efectivos. Incluso los equipos de doce personas son una exageración. A veces veo los currículums de personas a las que les han informado veinte o treinta personas. Mi reacción inmediata es pensar que trabajaban en una empresa terrible. Tener tantos informes directos es un "olor organizacional".

La premisa central de FAST Agile es que si agrega equipos de autoorganización y autoselección dentro de este Colectivo más grande, puede escalar sus equipos de manera más horizontal . Cada equipo (FAST los llama Colectivos) puede ser mucho más grande. Y luego los equipos con los que la gente trabaja día a día se autoensamblan dentro de esos Colectivos.

Si los Colectivos más grandes fueran efectivos, reducirían significativamente la complejidad organizativa. La típica puesta en marcha de software podría tardar años más antes de tener que dividirse en áreas de responsabilidad. No sería necesario segmentar rigurosamente el código base en áreas que pertenecen a cada equipo. Esto liberaría un tiempo de gestión significativo que los gerentes podrían usar para concentrarse en el producto y los equipos.

Entonces, esto es lo central que debemos probar: ¿el autoensamblaje y la autoorganización ofrecen una forma de operar que sea tan efectiva como los equipos diseñados más pequeños?

Si es así, ofrecerá una forma de escalar organizaciones que es potencialmente un orden de magnitud mejor para escalar organizaciones. ¿Por qué tanto? Comparemos una organización que crece con equipos de seis personas versus una organización que crece con “equipos/colectivos” de sesenta personas.

Hay muchas suposiciones integradas en este argumento, y es posible que puedas hacerle algunos agujeros. Pero incluso si lo hace, FAST esencialmente permite que una unidad organizativa más grande sea propietaria de un área del producto y la base de código.

FAST es nuevo, por lo que no hay mucha evidencia en este momento sobre si los equipos FAST funcionan con la misma eficacia que los equipos ágiles convencionales. Pero sospecho que la respuesta a esa pregunta es sí. Tengo un par de razones para creer eso. En primer lugar, la experiencia preliminar de Jim Shore con él fue bastante positiva y es alguien en quien confío.

Una segunda razón por la que soy optimista con FAST es que he tenido cierta experiencia con grandes grupos de personas que se autoorganizan. Y me sorprendió lo bien que funcionó.

En las pequeñas empresas, por supuesto, se ve mucha autoorganización. Pero a medida que las empresas crecen, estandariza las cosas y elimina la autoorganización, excepto dentro de los equipos. Sin embargo, uno de los experimentos más interesantes en los que participé fue un evento de autoorganización a gran escala en New Relic. Rediseñamos todos nuestros equipos y les pedimos a todos en cincuenta equipos de software que seleccionaran de qué equipo querían formar parte. Teníamos restricciones sobre las habilidades necesarias para cada equipo y habíamos definido lo que todos debían poseer. Terminó siendo mucho más exitoso de lo que nadie esperaba, incluso nosotros, los organizadores.

Entonces, aunque el jurado está deliberando sobre esto, mi corazonada es que esta práctica tiene mucho potencial en los contextos correctos.

FAST se puede experimentar de forma incremental

Esto no se menciona en los materiales de FAST, pero una cosa que me llamó la atención por ser interesante acerca de FAST es que se puede experimentar con él de forma incremental.

Puede implementar FAST Agile en un equipo como un experimento y luego usar un enfoque de blob en el que absorba equipos adicionales con el tiempo. Si va bien, continúa tragando equipos adicionales. Si no es así, cancela el experimento.

FAST debería resultar en menos reorganizaciones

El cambio ocurre en las organizaciones. Las prioridades cambian, la gente se va, las áreas del producto tienen un crecimiento inesperado. Las decisiones técnicas anteriores te muerden y tienes que hacer un trabajo adicional. Surgen nuevas oportunidades que requieren inversión.

Todas estas cosas tienen un impacto en la estructura de su organización. Tienes un conjunto de equipos, cada uno de los cuales tiene sus propias áreas de propiedad. A medida que ocurre este cambio, usted refactoriza su organización con el tiempo para rendir lo mejor que pueda. Estas refactorizaciones son "reorganizaciones", y en organizaciones en crecimiento, ¡pueden ocurrir con frecuencia!

Las reorganizaciones deberían ser mucho menos frecuentes con FAST. La unidad de reorganización es tan grande que no debería tener que hacerlo con tanta frecuencia.

Una desventaja potencial de esto es que no tiene equipos con áreas de responsabilidad definidas. Por lo tanto, podría tener una difusión de la responsabilidad y tener un código común mal mantenido. (Hablaremos de esto un poco más tarde)

FAST hace que sea más fácil responder a las prioridades cambiantes

Cuando las prioridades cambian en equipos estructurados convencionalmente, tiene equipos configurados para hacer el trabajo. Si esa estructura de equipo no es compatible con las nuevas prioridades, debe refactorizar su organización.

Para FAST, los cambios de prioridad son más fluidos y continuos. Mientras las responsabilidades estén dentro del Colectivo, los equipos simplemente se organizan en torno al trabajo, y es como otro día.

La estructura de las reuniones del Colectivo también hace que el cambio de prioridades sea menos dramático. Básicamente, tiene un All Hands incorporado dos veces por semana. En las reuniones colectivas, puede comunicar continuamente el contexto y educar a su equipo sobre sus clientes y el mercado. Esto debería ayudar a mantener a su equipo mejor alineado.

Cuando comparo ese enfoque con algo como los OKR trimestrales, parece más fluido y parece que haría un mejor trabajo al alinear a las personas. Requiere un esfuerzo comprometido del líder del producto para compartir continuamente el contexto y las prioridades. Pero algunos de los mejores equipos de los que he sido parte tenían un líder de producto que actuaba de esta manera, así que sospecho que es un tiempo bien empleado.

FAST podría ser mejor para la motivación intrínseca y la retención

Muchos equipos pueden sentir que su proceso está diseñado como herramientas para controlar a las personas. Y puede sentirse como trabajar en una línea de montaje.

FAST adopta la autoorganización como un componente fundamental de su diseño. Es tan fundamental que no funcionará sin la autoorganización. Requiere un conjunto de herramientas completamente diferente para la gestión, y es en su mayoría (aunque no completamente) incompatible con los enfoques jerárquicos de arriba hacia abajo.

Daniel Pink destacó tres aspectos de la motivación intrínseca :

• Autonomía : un deseo de ser autodirigido, lo que aumenta el compromiso sobre el cumplimiento.
• Maestría : la necesidad de mejorar sus habilidades.
• Propósito : el deseo de hacer algo que tiene significado y es importante. Las empresas que solo se enfocan en las ganancias sin valorar el propósito terminarán con un servicio al cliente deficiente y empleados insatisfechos.

Con FAST, puedes autodirigir tu trabajo, ayudándote a sentir autonomía. Puede elegir concentrarse en el trabajo que mejora sus habilidades, logrando una sensación de dominio. Y se le recuerda constantemente cómo su trabajo está conectado con lo que es importante para el negocio, ayudándole a tener un sentido de propósito. Entonces, aunque no está garantizado, veo un potencial para las organizaciones que implementan FAST para ver altas tasas de retención.

La autoorganización también proporciona algunas señales útiles que pueden ayudar a una comunidad de personas a trabajar mejor juntas. El tipo de persona “gerente imbécil” recibe una señal de que su comportamiento no es bienvenido. ¿Cómo? Dan un paso adelante para liderar un equipo y decir el trabajo que quieren hacer. Si nadie se une a su equipo, el trabajo no se hace y el equipo no se forma (los equipos tienen un mínimo de dos o tres personas o no se hacen).

La autoorganización también permite a las personas lidiar con aspectos dolorosos del trabajo que pueden no recibir atención en otras empresas. Por ejemplo, si el conjunto de pruebas es terrible, alguien puede dar un paso adelante para liderar un equipo que solucione ese problema. Es perfectamente razonable hacer un trabajo que no es explícitamente una prioridad comercial. Pero está a la vista, y otros tienen que unirse para que suceda. Esto puede ayudar a evitar sentirse como si estuviera en una fábrica de características .

Finalmente, puede elegir las personas con las que trabaja todos los días. Cuando he visto equipos autoorganizados en el pasado, este fue un beneficio inesperado: las personas eligieron trabajar con las personas con las que querían trabajar. Y esos equipos eran mucho más fuertes de lo que esperaba.

La cosa contra la que se equilibraría todo esto es cualquier nuevo dolor que la gente experimentaría con FAST. Un desafío podría ser la dinámica de poder informal o la política potencial.

Muchos entornos son incompatibles con FAST

Debido a que FAST es tan nuevo, es más arriesgado implementarlo. FAST no tendrá sentido en todas las situaciones. Y hay más incógnitas. Es mejor pensar en ello como un enfoque experimental.

¿Qué entornos son más propicios para probar FAST? ¿Y dónde debes evitar FAST?

Cuantas más cualidades de esta lista tenga su empresa, mejor se adaptará a FAST:

• Interés por la innovación y la experimentación en la gestión.
• Entornos de alta confianza y bajo miedo. O al menos un deseo de evitar el mando y control en el liderazgo.
• Un buen guía o facilitador del proceso. Alguien que pueda dirigir una reunión colectiva eficaz, configurar el proceso, evaluarlo y gestionarlo activamente. Alguien que entiende la dinámica organizacional y cómo los humanos en grupos trabajan juntos. (Podrías contratarme para esto).
• Una tasa de cambio de prioridades media a alta. FAST es menos útil si las prioridades no están cambiando.
• Un equipo colaborativo, autodirigido, de alto rendimiento y de aprendizaje continuo.
• Un equipo de liderazgo que puede determinar sus prioridades.
• Tiene un líder de producto que puede hablar sobre las prioridades y el contexto comercial en cada reunión del Colectivo. Y pueden comunicarse de manera efectiva.

Cuanto menos verdaderas sean estas características, más vientos en contra enfrentará con FAST. No creo que necesites estar en un entorno perfecto para ello. De alguna manera, creo que querer ser estas cosas es más importante que ser realmente estas cosas. Entonces, quizás el factor de éxito más importante es que el liderazgo está dispuesto a hacer espacio para ello.

Es posible que deba administrar la autogestión

Los sistemas de autoorganización pueden funcionar de manera efectiva. Pero no son gratis. Son más como administrar una comunidad.

Deberá crear restricciones y medios para incentivar el comportamiento correcto. Y tendrá que observar cuidadosamente y administrar para asegurarse de que las cosas no se desvíen.

Cualquier organización puede tener malos actores o personas que no están alineadas con los intereses de esa comunidad. Recuerdo una vez que hablé con un ingeniero que me dijo (no bromeo) que no creía que tuviera la obligación de producir valor para su empleador. Algunos ingenieros pueden querer enfocarse en cosas que desarrollen sus habilidades o los conviertan en empleados más valiosos, en lugar de cosas que son buenas para la empresa que los emplea.

Con FAST, se registra para administrar una comunidad de personas.

En situaciones convencionales, la jerarquía deja claro quién es el responsable de esto. En FAST, sospecho que sería fácil tratar de evitar el conflicto y "dejar que los miembros lo averigüen". Esto podría dar como resultado que las redes de poder informales dominen en una especie de tiranía de falta de estructura . Si usa FAST, esto es algo contra lo que me protegería.

El otro extremo sería no dejar que el grupo resuelva los problemas y dejar que la gerencia lo maneje por completo. Esto también podría ser dañino.

Por lo tanto, FAST requerirá una buena facilitación, una observación cuidadosa y una intervención ocasional.

FAST requiere mucho trabajo

La principal razón por la que quizás no desee experimentar con FAST es que hay mucho trabajo oculto con FAST. Requiere muchos cambios en su organización, a una forma desconocida de operar.

Puede comparar FAST con trabajar en un nuevo lenguaje de programación de computadoras. El nuevo lenguaje parece prometedor porque tiene tantas características ergonómicas nuevas que parece mucho mejor que cualquier cosa que haya visto antes. Pero no tiene marcos y bibliotecas escritos en este nuevo lenguaje. Así que tendrás que construir mucho tú mismo.

Entonces, la mayor desventaja de FAST es que no es una práctica bien establecida. Deberá inventar muchas cosas para lidiar con las incompatibilidades entre el funcionamiento de FAST y las prácticas convencionales. Aquí hay unos ejemplos:

¿Cómo funciona la gestión del rendimiento?

En los equipos convencionales, tiene un gerente que supervisa el trabajo y entrena a las personas. Tiene revisiones de desempeño, y si alguien no encaja bien, el gerente puede intervenir. Aunque existen problemas con las revisiones de desempeño, la mayoría de las personas entienden cómo funcionan y cumplen un propósito en la organización.

En los equipos FAST, en realidad no existe una manera obvia de hacer revisiones de desempeño. ¿El gerente de la persona siquiera sabe lo que está haciendo o cómo está trabajando? Ni siquiera puedes evaluar "equipos", porque son transitorios.

Por lo tanto, toda la noción de gestión del rendimiento debe reinventarse. Si bien eso puede ser una buena idea de todos modos, es algo que requerirá pensamiento e invención.

¿Cuál es el papel de los gerentes de ingeniería en FAST?

Hay muchas maneras de estructurar un rol de gerente de ingeniería. Por lo general, recomiendo que el gerente de ingeniería sea responsable de la gestión del proyecto porque lo hace trabajar codo con codo con su equipo, sin ponerlo en un área donde el diferencial de potencia cause problemas. Hay muchas formas válidas de definir el rol de gerente de ingeniería, pero esa es una a la que tiendo a gravitar.

En FAST, el rol del gerente de ingeniería es menos claro. No tiene equipos de larga duración, por lo que es más difícil para el gerente de ingeniería trabajar codo con codo con sus subordinados directos.

Podría hacer que los gerentes de ingeniería lideren los equipos autoensamblados. O podrías hacer que sean puros gerentes de personas. O podrías hacer que sean jugadores-entrenadores.

Todos estos tienen compensaciones y algunas desventajas bastante grandes. FAST parece disminuir la necesidad de tanta gestión de ingeniería. Todavía necesita personas para contratar, administrar el desempeño y supervisar el proceso. ¿Pero tal vez no tanto como en una organización convencional?

He visto sufrir a muchas organizaciones porque no valoran la gestión como disciplina. Pero supongo que las organizaciones FAST necesitan menos gestión.

Tengo mucha curiosidad por ver si esto funciona y quiero saber de las organizaciones que experimentan con FAST. ¿Qué haces con la gestión?

¿Cómo garantizará la calidad del código sin áreas de propiedad?

La propiedad del código proporciona incentivos naturales para mantener alta la calidad del código. Está en tu propio interés, porque tu yo futuro tiene que trabajar en tu código actual.

En una situación de propiedad de código compartido, debe hacer todo lo posible para garantizar la calidad del código. Mi recomendación sería el emparejamiento o el mobbing como práctica obligatoria.

También necesitará estándares más estrictos para los patrones de código. Necesitarás pelusa de código. Y necesitará algún tipo de toma de decisiones arquitectónicas. No desea tener veinte patrones sobre cómo su código frontend maneja el estado. Estos son problemas que tendrá en la mayoría de las organizaciones de software, pero serán mucho más apremiantes en una organización que utilice FAST.

Una cosa en la que muchas organizaciones invierten poco es en capacitación y comunicación en torno a patrones de diseño de software efectivos. Y conversaciones para asegurarse de que todos estén alineados sobre qué enfoques usar y cuándo. Estos son probablemente aún más importantes en una organización FAST.

La propiedad de código compartido es una práctica que tiene algún precedente. Valdría la pena dedicar tiempo a profundizar en cómo tener éxito si continúa con RÁPIDO.

¿Qué sucede con múltiples Colectivos y cruzando los límites del Colectivo?

El trabajo que cruza los límites colectivos es esencialmente indefinido en FAST. Y las grandes iniciativas que requieren un alto grado de coordinación también están subespecificadas por FAST. Así que tendrías que inventar soluciones a estas situaciones.

Cualquier organización lo suficientemente grande como para tener múltiples Colectivos que usen FAST se encontrará con proyectos de Colectivos cruzados. Los patrones para abordar estas cosas serán similares o análogos a cómo lo resuelves en una escala más pequeña. Pero este es un territorio en gran parte desconocido, hasta donde yo sé. Por lo tanto, deberá utilizar algunos modelos de coordinación para resolver estos problemas cuando surjan. Será un acto de invención.

¿Cómo trata FAST las guardias?

On-call no se menciona específicamente en la guía FAST . Así que tendrás que inventar un plan para lidiar con eso.

En los equipos convencionales, el consejo estándar para las guardias es que cada equipo sea responsable de sus propias operaciones. Y tener a todos en el equipo de guardia. Esto implica que debe tener equipos de al menos cuatro personas para que la carga no sea tan mala. La idea es que tener equipos de guardia para su producto de trabajo los incentiva a aumentar la confiabilidad. Esto les ayuda a garantizar que tengan un horario de guardia decente.

Con FAST, puede crear una rotación de guardia que tenga niveles (siga este runbook y escale si eso no soluciona el problema). Y deberá mantener explícitamente un mapa de quién puede respaldar qué. Esto no se asignará a sus equipos.

Esto no es muy difícil de hacer, pero es menos común que las prácticas convencionales de guardia y requerirá la atención de la gerencia.

¿Qué pasa con la corrección de errores y las escaladas de soporte?

FAST tiene un rol opcional llamado "Administrador de funciones". Son una especie de expertos en una función en particular y son el punto de contacto en torno a esa función para las partes interesadas. No se les exige que trabajen continuamente en esa función, pero se les exige que tengan una comprensión continua de la misma.

Al igual que en la guardia, necesitará un mapeo de funciones para personas con experiencia en esas funciones. Esto será importante tanto para los errores como para las escaladas de soporte. Y también podría combinarlo con guardia también. Necesitará alguna forma de clasificar los problemas a las personas adecuadas.

También deberá asegurarse de tener un mecanismo para llenar los vacíos de conocimiento cuando la experiencia esté aislada en una o dos personas.

Una cosa que tendrá que decidir es su política para corregir errores. ¿Quiere que siempre se arreglen, lo que ralentiza el trabajo de otras funciones? ¿Los errores los corrigió la persona que los introdujo, o quieres algún otro esquema? ¿Y cómo determinará quién es responsable de clasificar los errores? ¿Probablemente una rotación de algún tipo?

Las escaladas de soporte también requerirán algo de esfuerzo. El punto de contacto es el administrador de funciones de un área. Pero, ¿y si el administrador de funciones está de vacaciones? Probablemente desee más de una persona con conocimientos sobre cada área. ¿Y si la pregunta de soporte termina requiriendo trabajo? ¿Simplemente haces el trabajo o lo introduces en las prioridades centrales?

Ninguno de estos son problemas difíciles de resolver, pero son trabajo de gestión. Y todo lo que haga tendrá compensaciones de enfoque versus capacidad de respuesta.

¿Qué sucede con los incidentes de confiabilidad y las retrospectivas de incidentes?

FAST no define cómo se manejan los incidentes. Sus patrones de guardia determinarán en gran medida cómo se manejan los incidentes, y probablemente involucrarán a quien sepa cómo solucionar la situación para que lo solucione.

FAST no describe cómo manejar las retrospectivas de incidentes. Recomendaría hacer algo como lo siguiente: programar una retrospectiva de incidentes antes de la próxima reunión del Colectivo. Uno de los objetivos de la retrospectiva sería identificar algunos trabajos que podrían realizarse para reducir la probabilidad o la gravedad de lo que sea que haya causado el incidente. Otra sería aprender todo lo que pueda del incidente.

En la reunión del Colectivo inmediatamente después del incidente, compartiría lo que aprendimos y también haría una prioridad automática para el siguiente ciclo para hacer parte del trabajo identificado en la retrospectiva.

En New Relic, no usamos FAST, pero teníamos una política similar. Lo llamamos "No repetir incidentes" (DRI). Fue una de las mejores cosas que hicimos por la confiabilidad. La regla era que el trabajo de DRI era automáticamente más importante que otras prioridades. Por lo tanto, un incidente siempre resultó en un alcance menor o en una fecha límite retrasada.

¿Cómo trabajan los diseñadores en FAST?

Un desafío al que se enfrentan muchos diseñadores es centrarse en trabajar con el equipo de ingeniería o hacer el trabajo antes que el equipo de ingeniería. O haz que operen en ambos sentidos. Escuchará fuertes argumentos a favor de ambas formas de trabajar.

FAST no especifica cómo debería funcionar esto, por lo que deberá decidir por sí mismo. ¿Los diseñadores se inscriben en los equipos para trabajar? ¿O son una organización de servicios que trabaja con anticipación y actúan como consultores cuando las personas necesitan algo de ellos? Tendrás que decidir. Probablemente haría que los diseñadores se inscribieran y formaran parte de los equipos, pero nuevamente, este es un ejemplo del tipo de decisiones que deberá tomar al adoptar FAST.

¿Cómo trabajan los jefes de producto en FAST?

La función del producto en FAST es principalmente priorizar y comunicar prioridades. Hay muchas cosas que no se describen realmente en el manual de FAST sobre el trabajo fuera de eso.

La suposición en el manual de FAST parece ser que los gerentes de producto inspiran y comunican, y luego los ingenieros trabajan en las funciones.

En la medida de lo posible, haría que los ingenieros hablaran con los clientes y que adquirieran experiencia en el área del producto en la que están trabajando. Idealmente, estarían haciendo el trabajo, mostrándolo a los clientes y recibiendo comentarios de ellos. . Hacer que los gerentes de producto faciliten eso y mejorar la capacidad de los ingenieros para hacerlo de manera efectiva podría ser una parte valiosa de su trabajo.

Hay mucha flexibilidad en este modelo. Podría hacer la transferencia típica del producto a la ingeniería, o podría hacer que descubran y resuelvan los problemas del espacio junto con los clientes.

Como puede ver, hay muchas lagunas en FAST. Tendrás que resolver el problema del resto.

Los materiales FAST están llenos de jerga

Es posible que encuentre confuso el sitio web y el manual de FAST. Tendrá que navegar por una gran cantidad de jerga y terminología molesta para obtener el oro de FAST Agile. Como ejemplo, aquí está la terrible definición de FAST Agile que intenta definir la práctica en la versión 2.12 de la Guía FAST :

“¿Qué es la tecnología de escalado de fluidos? La tecnología Fluid Scaling combina la tecnología de espacio abierto y la asignación abierta para crear un método ligero, fácil de entender y fácil de dominar para organizar a las personas en torno al trabajo, que escala. FAST es el acrónimo de Fluid Scaling Technology. La tecnología Fluid Scaling para Agile es FAST Agile”.

Entonces. Malo. Y esto es muy representativo. Verá muchas referencias a colectivos, ciclos de valor, tecnología abierta, transformación verde azulado, teoría Y, etc. Todo esto se presenta sin explicación, y realmente, incluso si se explicara, no sería útil. Están hablando a una audiencia de nicho de teóricos ágiles y se centran en la atribución en lugar de la utilidad.

Conclusión

Entonces, ¿dónde nos deja eso? ¿Vale la pena experimentar con FAST Agile?

Creo que la respuesta a eso es sí, pero con precaución y en los contextos correctos. Puedes jugar con él dentro de equipos individuales. Y si tiene apoyo de liderazgo, experimente con él gradualmente dentro de organizaciones más grandes.

Por favor, comparte conmigo si experimentas con él. Y si desea ayuda para implementarlo en su organización, comuníquese conmigo. Te ayudaré directamente o te conectaré con otras personas que puedan ayudarte.

Gracias

Las primeras versiones de esta publicación eran... realmente malas. Me gustaría agradecer a Seth Falcon y Davy Stevenson por su crítica. Ambos señalaron algunos problemas importantes con la publicación que me hicieron retroceder y repensar mi enfoque. E hicieron algunos puntos excelentes que incorporé en sus propias secciones de la publicación. Eventualmente, reescribí la mayor parte de la publicación y quedé mucho más feliz con el resultado. ¡Gracias! Seth tiene un boletín informativo sobre liderazgo en ingeniería que vale la pena consultar, y Davy (como yo) brinda asesoría y capacitación para empresas emergentes .

Jim Shore me presentó FAST Agile. Él tiene algunas charlas excelentes sobre sus experiencias con él. Y nos hemos reunido varias veces y discutido las implicaciones y la implementación de FAST. Jim es el autor de El arte del desarrollo ágil .

Imagen de Kanenori en Pixabay

notas al pie

1. Creo que 150 personas es probablemente difícil de manejar para un Colectivo. Sospecho que sesenta personas es un tamaño máximo mejor.