TLDR; Cuando digo que no soy partidario del modelo Feature Teams, algunas personas pueden pensar que es una consecuencia de la falta de delegación, o incluso del conservadurismo organizativo. No es nada de esto. Es principalmente por el bien de la eficiencia que prefiero los escuadrones (es decir, equipos autónomos especializados por tema comercial / contextos limitados) PERO combinados con la técnica Swarming cuando sea necesario. Advertencia: esta publicación también contiene una mini diatriba contra la infame maniobra de Conway inversa ;-)

Este artículo sigue a mi publicación anterior ( ¿DDD es de derecha? ) que hablaba sobre el diseño basado en dominios y varias preocupaciones de la organización. Artículo en el que mencioné muy brevemente que no era fanático de los Feature Teams. Explicaré aquí por qué.

El mundo perdido de los Feature Teams

Ya experimenté la moda cuando todos juraron por los equipos de características. Fue en la década de 2010 y la mayoría de las grandes organizaciones realmente pensaron que los iba a salvar de sus problemas de Cultura (), de su deuda técnica pero también de su carga burocrática. El principio es simple: formamos un equipo centrado en el cliente, multidisciplinario pero estable, al que se le asignarán regularmente diferentes misiones. Misiones diferentes, pero cada vez con una funcionalidad particular que el equipo administrará solo de principio a fin (corte vertical). Para lograr esto, el Feature Team podrá intervenir solo en todos los componentes que se interpondrán en su camino (frontal, posterior, infra, db, etc.).

La idea de un equipo de funciones es que no necesita llamar a otros equipos para poder agregar una función o una capacidad a un producto.

Advertencia: la noción de "característica" en el equipo de características no significa que sea responsable de un dominio comercial en particular (que sería su especialidad). No, la noción de “característica” corresponde más bien a la unidad de trabajo del equipo (que puede cambiar regularmente). Un equipo de características es un poco como el A-Team: un equipo autónomo que resuelve los problemas que surgen (al comienzo de cada episodio) y que cambia constantemente de tema antes de emprender nuevas aventuras.

Pero los problemas vienen cuando...

En tales organizaciones, potencialmente podemos tener varios equipos de características trabajando simultáneamente en diferentes características, pero todas en la misma plataforma/software. Habiendo visto esto aquí y allá en viejas experiencias o con clientes (cuando era consultor), esto puede dar lugar a:

• Problemas de simultaneidad entre equipos al codificar en el mismo componente
• Base de código heterogénea que termina con muchos enfoques de diseño diferentes. Por lo tanto, conduce a un código más complicado de leer/comprender/mantener/evolucionar (¿choque de culturas de desarrollo?)
• Diseños centrados en el corto plazo, con personas que prestan menos atención a la durabilidad y mantenibilidad del código resultante. Como si fuera casi intrínseco a su declaración de misión.

De hecho, lidiar con dominios complicados puede ser un verdadero dolor de cabeza o generar mucho código de dominio anémico con Feature Teams.

Asi que. ¿Cómo podemos enfrentar todas estas dificultades?

El modelo de “escuadrones” de Spotify

No sorprende entonces que el modelo que surgió en los años siguientes fuera el modelo “squads” de Spotify. Éste partía del concepto de equipo multidisciplinar y estable (como un Feature team), pero la gente de Spotify fue más allá en el aspecto de la autonomía.

Han pedido a cada una de estas cuadrillas que invierta más tiempo y que permanezca asignada a un área de negocio particular, un aspecto funcional específico del producto. Entendieron que era necesario invertir un mínimo funcionalmente hablando, para poder ser plenamente efectivos, autónomos y capaces de tomar decisiones relevantes.

Y no me malinterpreten: “Squad” no es solo un término “cool” para hablar de un equipo. Las escuadras son equipos AUTÓNOMOS. Les damos una misión que perdurará en el tiempo, y les pediremos que tomen posesión de su Dominio comercial por sí mismos.

El dominio en el que trabaja un equipo debe caber en la cabeza de todos

Team Topologies (de Matthew Skelton y Manuel Pais ) llegó unos años después con el término "equipo alineado con flujo". Pero mientras encontré interesante su propuesta para reducir la carga cognitiva en los equipos, al colocar un límite superior estricto en el tamaño de los equipos ("el dominio en el que trabaja un equipo debe caber en la cabeza de todos"), sigo prefiriendo usar el nombre "Escuadrones" para representar autonomía.

Nota: trabajar en la autonomía de los equipos es una de mis pasiones, como mencioné recientemente aquí en Cómo evitar que la búsqueda de la autonomía de los equipos se convierta en un caos...

Squads & DDD: un dúo fantástico para abordar la complejidad empresarial

La autonomía es realmente el terreno común entre el modelo de “Escuadrones” y el Diseño Dirigido por Dominio (DDD). De hecho, este último sugiere que alineemos nuestro software con las necesidades de los Dominios y dividamos nuestro producto en diferentes "reinos" autónomos pero conectados llamados Contextos Limitados (por ejemplo, Contabilidad, Ventas, Búsqueda, etc.). Se supone que estos reinos/contextos acotados nos dan más libertad y autonomía para entregar valor (por ejemplo, no necesariamente queremos impactar y pedir su opinión a los equipos dedicados de Marketing cuando cambiamos una parte relacionada con la Contabilidad). Para obtener más detalles sobre qué es DDD, puede ver esto ( Diseño basado en dominio explicado en 3 minutos ).

Para lograr este desafío, generalmente queremos tener solo un equipo responsable por Bounded Context (y muy a menudo con algo como un módulo o una API web por BC) porque queremos que cada uno de ellos sea consistente internamente (en términos de diseño y general). Acercarse).

Por encima de todo, queremos un buen tiempo de comercialización y equipos autónomos en la toma de decisiones. Por lo tanto, adaptamos nuestra arquitectura en consecuencia, siguiendo los límites de nuestro dominio. Tener varios equipos propietarios del mismo contexto delimitado complicaría la toma de decisiones. Por cierto, Domain Driven Design puso un nombre a una situación en la que varios equipos compartirían un fragmento de código: Shared Kernel .

Incluso si todo es una cuestión de contexto, puedo decir sin sonrojarme demasiado que un núcleo compartido es muy a menudo una situación dolorosa (¿un olor?) organizacionalmente hablando. Al menos requiere una cierta madurez y una cultura corporativa que valore la colaboración dentro de la empresa (que no tendrás si valoras a las personas y das bonificaciones individualmente, por ejemplo) que son realmente raros. No imposible pero raro.

En resumen: generalmente queremos evitar situaciones en las que diferentes equipos se ocupen de la misma parte comercial de nuestro Producto.

El uso de equipos de características parece inadecuado en esencia con respecto a este objetivo de la OMI.

En Agicap

Como era de esperar, esto es más o menos lo que encontré en Agicap cuando llegué el año pasado para ser el vicepresidente de ingeniería de esta expansión europea en auge.

Pero a diferencia de la situación de Spotify, donde cada escuadrón (entiéndase “todo el equipo”) es realmente autónomo en la toma de decisiones, los gerentes de producto de Agicap fueron los que impulsaron con fuerza la fase de implementación del desarrollo.

Había funcionado bastante bien hasta ahora. Sobre todo el hecho de no tener Product Owners (POs) sino Product Managers, cubriendo tanto la fase de descubrimiento como la de entrega (muy eficiente).

No obstante, los equipos de tecnología regularmente recibían solicitudes de la gente de Producto para cambiar la estructura de sus equipos. Cosas como pedirnos que traslademos un desarrollador específico de un equipo a otro para que se adapte mejor a sus necesidades funcionales actuales o futuras. Seguir tales solicitudes nos habría llevado a tomar decisiones de impacto a largo plazo para las personas, pero basadas en la actualidad del producto a corto plazo (para las próximas semanas o meses).

Cualquiera que sea la perspectiva que tomes sobre esto, no me parece una buena idea.

¡No somos "recursos" por el amor de Dios!

Mi deseo de fomentar equipos autónomos se remonta a mediados de la década de 2000, cuando descubrí XP (programación extrema) en el trabajo. Pude experimentar el poder y la eficiencia local de un equipo XP autónomo en un proyecto piloto en un gran banco de inversión. Una experiencia increíble a tantos niveles. Un montón de años después, también pude experimentar la frustración de trabajar en una gran organización que no entendía la dinámica de los equipos de desarrollo y Dynamic Reteaming . Una organización que se pasaba el tiempo fragmentando nuestros equipos una y otra vez según los proyectos en boga.

Como dije en mi artículo anterior, se necesitan al menos 6 meses para construir un equipo de desarrollo eficiente donde las relaciones interpersonales sean efectivas y se adquiera cierta experiencia comercial.

Dedicar tiempo a reorganizar el casting de los equipos de desarrollo afecta en gran medida a nuestra eficiencia. Además: ¡no somos máquinas! Somos humanos con afectos, vínculos y apegos que tejemos a lo largo del tiempo con nuestros compañeros.

(

Pequeño paréntesis: la maniobra inversa de Conway (ICM)

Estas son las mismas razones por las que algunos de nosotros nos quejamos cuando oímos hablar de la maniobra inversa de Conway (ICM) . Y no estoy hablando de la versión original de ICM que estaba bien (es decir: "romper los silos que restringen la capacidad del equipo para colaborar de manera efectiva" ). Me refiero a cómo generaciones de consultores han convertido a ICM en un monstruo frankenstein (es decir: “ cambia tu organización para alcanzar tu arquitectura objetivo” ).

Sobre ese tema específico, esté atento a la próxima serie de excelentes artículos de mi amigo Cyrille DUPUYDAUBY (debería publicarse muy pronto). Él fue el primero en alertarme sobre este tema hace años y aclarará por qué.

Algunos como John CUTLER o Mathias VERRAES ( Conway's Law Doesn't Apply to Rigid Designs ), ya han entendido que conceptos como la maniobra inversa de Conway eran probablemente demasiado ambiciosos dada la deuda funcional y técnica de ciertas arquitecturas:

« Finalmente, es fácil decir "¡simplemente empodera a tus equipos!" Incluso con las mejores intenciones, eso podría no ser fácil. Su arquitectura y estructura organizativa actuales pueden limitar sus opciones. » ( John CUTLER — TBM 27/52: Niveles de mandato )

Algunos de nosotros también decimos que esta maniobra es poco ética y jodidamente ingenua. Razón por la cual incluso hablo de estafa para el ICM.

Primero, poco ético, porque no jugamos así con las personas, humanos reales en nuestras organizaciones. No se "refactoriza" a la gente. No juegas con la gente como juegas con el código.

Es jodidamente ingenuo también, porque la cara oculta del Iceberg con el que te toparás es una vez más la Cultura. Algo familiar para los entusiastas de la gestión del cambio como yo. ¿Recuerda? El que se come todas las estrategias en el desayuno (cf. Peter Drucker).

)

Una vez hecho este paréntesis sobre el lado humano, volvamos a nuestro tema principal: lo que Swarming puede aportar a equipos estables y autónomos (es decir, Squad).

Swarming: ese pequeño extra que necesitábamos para una organización DDD eficiente

Está bien. Primero: expliquemos qué es Swarming. Swarming es como un grupo de trabajo (por lo tanto, temporal), pero dentro del cual habremos definido desde el principio quién será el responsable del soporte de producción de cualquier software resultante (punto aún más importante si, como nosotros, estás en un “usted construye ¡usted lo ejecuta!” modo). Arroja luz sobre muchas decisiones de diseño colectivo y evita la conocida situación al finalizar un grupo de trabajo: "Por cierto: ¿¡¿quién se encarga del apoyo para esto que acabamos de hacer juntos?!?" (silencio largo ;-) En cuanto a un grupo de trabajo, los miembros de un Swarming provienen de varios equipos diferentes y tendrán que trabajar juntos para resolver un problema a corto plazo (antes de volver a su equipo al final del día)

Más allá de su efectividad para lograr que las personas adecuadas colaboren según el tema, una iniciativa de Swarming aporta mucho capital social a una organización al promover temporalmente las relaciones interpersonales entre diferentes escuadrones (muy útil para el futuro cuando todos regresen a su escuadrón).

¿Por qué necesitamos Swarming?

Si nos esforzamos demasiado y malinterpretamos el concepto de autonomía recomendado por DDD, podemos caer en la tentación de confundir autonomía con aislamiento. También podemos tener la tentación de aislarnos demasiado... Ver cada conectividad y cada interacción entre los BC como el mal absoluto que debe evitarse.

He visto a muchas personas caer en la trampa de dejar de pensar en los demás y centrarse solo en sus propios contextos acotados, en su propio equipo. Puede ser fácil olvidar que somos parte de un ecosistema donde cada parte tiene un papel que desempeñar y donde las interacciones deben ser limitadas -seguro- (en términos de superficie de exposición) pero no ignoradas. Nuestro trabajo debe ser útil y utilizado. Todos (PM, desarrolladores) sueñan con una situación en la que nunca necesitemos otros equipos/BC para avanzar y aportar valor. Pero todos sueñan...

De todos modos. Nada de esto coincide con lo que nos dice DDD. En cambio, DDD quiere que cada contexto acotado sea el más autónomo, por supuesto, pero útil para las necesidades de nuestros usuarios. Para lograr esto, debemos conectar sabiamente los diferentes BC, no ocultarlos completamente entre sí. Y para eso están la mayoría de los patrones estratégicos de DDD: para ayudarnos a permitir de forma segura estas interacciones entre BC.

Bueno, Swarming interviene precisamente en estos pocos casos en los que necesitamos trabajar en la sincronización e interacciones entre 2 o más Bounded Contexts.

El swarming también puede ayudarnos a sobrevivir a situaciones en las que nuestras CC aún no están bien definidas. Antes de una aclaración de Dominio o Mapa de Contexto.

Cuando termina un Swarming, todos encuentran a su equipo y sus súbditos. Swarming es solo una forma muy eficiente de colaborar con personas de varios equipos y experiencia en el dominio para alcanzar un objetivo de manera eficiente.

Por eso quise probar esta técnica cuando llegué hace un año. Y debo reconocer que nunca me canso de ver los efectos beneficiosos que tiene (ahora que hace unos meses que no lo experimentamos aquí o allá).

Para concluir: ¡Enjambre FTW!

Como mencioné al comienzo de este artículo, he visto tantas situaciones complicadas pero sobre todo bases de código inconsistentes después de que fueron tocados por varios equipos de características que creo que el Equipo de características ya no es interesante.

Peor aún, he visto muchas veces equipos de funciones que no están muy bien informados ni interesados ​​por las sutilezas o el lenguaje ubicuo de cada parte funcional/BC. Cada vez, el impacto en el código base fue dramático (Dominio anémico o aproximado).

Razón por la cual no creo que los equipos destacados puedan competir con los escuadrones combinados con Swarming siempre que necesitemos presionar con fuerza en un tema o colaboración determinada.

Próximos pasos

Hoy en Agicap, la gente de tecnología está muy cerca de sus Gerentes de Producto. Pero el próximo paso de nuestro viaje de mejora continua será que los Gerentes de Producto involucren incluso antes a las personas de tecnología durante su descubrimiento (el famoso "cambio a la izquierda" para tecnología).

También me gustaría que empezáramos a considerar las vías duales de Continuous Discovery / Continuous Delivery, tan queridas por Marty Cagan y Jeff Patton. Esto debería permitirnos aún más poner nuestra fuerza de energía e ingeniería ÚNICAMENTE en ideas validadas por nuestros clientes. Mejorar aún más la relación costo/beneficio de nuestras acciones.

«Maximiza el valor, minimiza el esfuerzo» (Jeff Patton)

Pero ese será el tema de futuras publicaciones, supongo.

Para saber más sobre Agicap:

• Muéstrame tu dominio ( sesión de mapa de contexto de pronóstico y monitoreo de flujo de caja )
• https://agicap.com/
• https://career.agicap.com/