…las cosas funcionan bien, ya que todo el mundo hace lo que hay que hacer por pura pasión, de forma tan perfecta que un observador podría concluir que todo el mundo tiene la capacidad de leer la mente de los demás. Sin embargo, a medida que la organización y el producto crecen, también lo hace la cantidad de información que los equipos deben dominar, gestionar y compartir para realizar su trabajo. Las decisiones son cada vez más sensibles al contexto (tanto de los equipos como de los productos), con una complejidad que pide algún tipo de estructura para que las cosas funcionen sin problemas a medida que la organización madura. Se busca una estructura organizativa que optimice la capacidad del equipo de hacer las cosas para crear el Mayor Valor.

✥✥

La comunicación y la retroalimentación efectivas están en el centro del desarrollo de sistemas complejos eficaces, y la estructura organizativa debe optimizarse para las vías de comunicación más cruciales. La comunicación y la retroalimentación regular, junto con la autoorganización, son el corazón ágil. La interacción de personas con preocupaciones diversas y transversales se encuentra en el corazón de la innovación ().

Los equipos de desarrollo que trabajan en productos complejos luchan continuamente con la doble naturaleza de la función y la forma. Tendemos a crear límites entre las actividades de desarrollo y las unidades organizativas siguiendo estas líneas. Sin embargo, la función y la forma no son más que categorías construidas socialmente y en cierto modo arbitrarias: la fiabilidad puede ser una preocupación tan apremiante para un sistema determinado, mientras que la belleza, la compatibilidad con versiones anteriores o alguna otra preocupación pueden dominar un esfuerzo de desarrollo determinado. En cada caso, el negocio será mejor servido si el Equipo de Desarrollo se organiza en torno a las preocupaciones más cruciales del negocio – sean las que sean.

Cuando su equipo comienza a madurar en sus primeros días y comienza a moverse hacia la construcción de un Equipo Scrum, tiene más personas que pueden trabajar convenientemente como una unidad organizativa para cubrir todas las funciones de un negocio (planificación de la liberación, el desarrollo y el crecimiento profesional). Pero el crecimiento y la madurez también causan incomodidad, ya que los equipos añoran la eficacia desestructurada de los simples días de trabajo informal. Sin embargo, para crecer y gestionar adecuadamente el producto en el mercado se requiere una estructura organizativa algo disciplinada y una gobernanza ligera.

Las culturas tienen una necesidad intrínseca de estructura para el funcionamiento eficaz del conjunto. La comunicación más eficaz siempre se produce localmente dentro del ámbito de lo familiar, por lo que es crucial localizar el proceso de toma de decisiones en torno a las preocupaciones organizativas más cruciales. En cualquier organización social no trivial, es importante que las personas puedan asociar rápidamente cualquier ámbito de interés con el «lugar» más eficiente al que acudir cuando necesiten información sobre ese ámbito o necesiten actuar en él.

Una simple partición organizativa (es decir, una jerarquía) es suficiente en los ámbitos sencillos que deben ocuparse de un solo conjunto de preocupaciones separables. Pero el enfoque jerárquico se rompe en el caso más típico de los esfuerzos de desarrollo con múltiples preocupaciones que se superponen. Esto empuja hacia unidades organizativas más grandes y complejas que intentan corregir el problema con economías de alcance. Sin embargo, los equipos de trabajo más eficaces son los equipos pequeños, y es necesario dividir el trabajo de alguna manera.

Sin embargo, ningún equipo es una isla, y una nación de desarrollo es más que una colección de islas. Los equipos desarrollan individualmente su propia identidad, donde un sentido natural de xenofobia (necesidad de lo familiar) hace que los equipos sólo den una importancia secundaria a las preocupaciones que vienen de fuera de su círculo social. Si se limita la empresa a un conjunto de interacciones sociales, basadas en una única y simple partición, se cierran las ideas fuera de los límites que alimentan la innovación.

La rapidez en la toma de decisiones es primordial. Algunas cuestiones son urgentes («Estamos siendo atacados por otra tribu y debemos montar una defensa contra ellos»), mientras que otras, aunque importantes, toleran o incluso piden una deliberación más larga («¿Cuál es la mejor ubicación para la nueva sala de reuniones?»). El término capas de cizallamiento describe procesos relacionados que se mueven a diferentes velocidades, según la noción de placas tectónicas que se mueven unas sobre otras, como las que conducen a un terremoto. Tanto los arquitectos de edificios () como el campo de la arquitectura de software (véase ) han adoptado la frase para describir estructuras o preocupaciones con diferentes tasas de cambio en un sistema estrechamente acoplado. Una empresa debe estructurar su organización para poder responder rápidamente a los problemas de la primera categoría sin destruir su eficacia para los problemas de la segunda.

Otro principio ágil es que estamos orientados hacia el exterior: es decir, nuestro enfoque y preocupación son el usuario final, el mercado y los clientes, más que las herramientas y tecnologías que utilizamos para hacer nuestro trabajo. La organización debe reflejar también esta preocupación, ya que es clave para la propuesta de valor y la construcción de todo el Flujo de Valor del desarrollo.

Al final, la estructura de la organización debe tener tanto que ver con la estructura del proceso como con la estructura del producto.

Por lo tanto,

Organizar la fuerza de trabajo en Pequeños Equipos de más o menos cinco personas, repartidos según las preocupaciones más importantes para la creación de valor de la empresa. Complementar esta estructura con un pequeño número de estructuras transversales para las preocupaciones secundarias pero importantes, sin olvidar nunca que estas estructuras son sólo optimizaciones en lo que es un entorno abierto de cooperación sin restricciones.

Considere una empresa que está construyendo un teléfono móvil. Podrían organizar sus equipos Scrum en torno a los principales entregables u opciones adquiribles. Así que puede haber un equipo para la libreta de direcciones, otro para el calendario, y otro para la funcionalidad del teléfono más tradicional: ver Área de Valor. Esas son las principales preocupaciones de la empresa. Pero puede haber grupos que se reúnen para definir las prácticas, las políticas y las normas corporativas (por ejemplo, el aspecto de la interfaz de usuario), con representantes de cada equipo Scrum. Estos grupos no construyen el producto, pero sirven como intercambios de información y como fuentes de normas que guían el desarrollo. En las organizaciones sanas hay una superposición casi completa entre los miembros de estos últimos grupos y los miembros del equipo de desarrollo.

En la mayoría de los entornos, la estructura de organización primaria refleja la estructura primaria de las partes interesadas, que suele ser el mercado. Por esta razón, no organizamos los Equipos Scrum a lo largo de la partición de los artefactos internos, ni de acuerdo con el loci de la experiencia del dominio, sino más bien a lo largo de las líneas de los entregables del mercado, tales como características. La organización en torno a las características u otros entregables del mercado es también una ventaja para la capacidad de respuesta del mercado y la reducción del tiempo de comercialización, porque el equipo es el lugar de todo el trabajo necesario para implementar una característica. Esto mantiene la coordinación dentro de un límite organizativo. Si los subconjuntos de trabajo o las competencias básicas dirigen la estructura organizativa, entonces los cambios en el mercado o en la naturaleza del producto final probablemente implicarán la coordinación entre múltiples equipos u organizaciones, lo que reducirá la capacidad de respuesta y aumentará el tiempo de toma de decisiones.

Si esta es la única estructura, sólo apoya la visión del mercado y margina una serie de otras preocupaciones empresariales válidas. Para que esta estructura funcione, debe complementarse con estructuras transversales que apoyen un segundo nivel de eficacia comunicativa, por ejemplo, las relacionadas con las competencias básicas. Por ello, este patrón aparece casi siempre junto con un patrón como Birds of a Feather y el patrón descrito en Domain Expertise in Roles. La estructura de roles de la organización atraviesa los muros que se forman naturalmente entre los equipos. Consigue que los esfuerzos de producto dentro de una empresa se conecten entre sí y con la dirección ejecutiva a través del MetaScrum. Los equipos que han desarrollado un grado de orgullo de equipo (véase Orgullo de equipo) serán más eficaces, ya que ésta u otra fuerza equivalente fomentará la responsabilidad. Esto ayuda a asegurar que estas estructuras permanezcan en juego a pesar de los efectos xenófobos de la pertenencia a un equipo.

Amárquelo todo con un entorno abierto sin paredes ni puertas. Los equipos de desarrollo son unidades sólo de compromiso de desarrollo, y no debe haber ninguna interferencia que limite el libre trabajo entre los desarrolladores a través de los equipos. Añadir pequeñas salas cercanas para los períodos cortos de silencio, la reflexión seria y pequeñas reuniones.

Cualquier componente de valor es un juego justo como un criterio de organización. Por ejemplo, Scrum valora mucho la colocación de los miembros del equipo, por lo que es probable que los límites organizativos más básicos correspondan a Equipos Colocados.

✥ ✥ ✥

Nótese que hay dos niveles de la Ley de Conway en un buen Scrum: uno impulsado por un enfoque en el producto, y otro impulsado por un enfoque en las áreas de competencia. En el nivel de la superficie organizamos el equipo de acuerdo con el proceso; que es la principal preocupación tanto para los aspectos del proceso hacia adentro y hacia afuera. Así que las tres esferas de dominio del proceso son:

• el Equipo de Desarrollo que es dueño de las decisiones sobre el uso adecuado de la tecnología y la técnica en la construcción del producto;
• el Propietario del Producto, que es dueño de la definición y dirección del producto; y,
• el ScrumMaster que es responsable de que el proceso apoye la entrega regular del Equipo de Desarrollo.

Los Equipos de Desarrollo Scrum son equipos de características (producto). Es decir, el principio de organización principal de un Equipo Scrum es que se alinea con un tren de entregas de características a lo largo de un flujo de valor. Hay una organización jerárquica débil y superficial dentro de Scrum que da cabida a múltiples Equipos de Desarrollo dentro de cada desarrollo del producto, compartiendo un Product Owner común, en una organización llamada un Scrum de Scrums. Cada equipo de desarrollo dentro de un solo desarrollo del producto construye un conjunto de características a la vez. Con el tiempo, los impulsores clave del negocio, el conocimiento del negocio compartido, y los artefactos del flujo de valor vincularán estas características. No hay títulos reconocidos o subdivisiones dentro del Equipo de Desarrollo.

Hay muchas maneras de dividir el trabajo en equipos de características. Un Equipo de Desarrollo puede entregar características a un mercado determinado (ver La organización sigue al mercado), o desarrollar productos para algún subconjunto del espectro tecnológico de la empresa (un equipo para teléfonos y otro para tabletas, aunque ambos comparten gran parte del mismo software). En general, cada equipo debe formarse en torno a algún producto que represente un componente del valor de la empresa: véase también Value Stream Fork. Sin embargo, Scrum desaconseja una estructura de equipo de desarrollo en la que cada equipo es dueño de una parte del producto, o sólo de un subconjunto del producto. Si los miembros de un solo equipo pueden desarrollar sólo una parte del sistema, entonces tendrán que coordinar más decisiones de desarrollo con otros equipos. Se hace difícil para los equipos para tomar decisiones a nivel local, y los resultados incluyen retraso en la retroalimentación y traspasos.

En el segundo nivel de la Ley de Conway dentro de Scrum, la gente se organiza en torno a las áreas de competencia en la que la competencia impulsa el valor. Estos pájaros de una pluma ayudan a los miembros a profundizar su facilidad en algún área profesional o técnica, ya que comparten ideas o toman la formación. La mayoría de las personas tienen un deseo innato de mejorar (ver ), y estos grupos alimentan el orgullo individual mientras los miembros del equipo aprenden y crecen. Pero de nuevo, estos grupos no forman una estructura de informes, y cualquier miembro del equipo puede pertenecer a varios Birds of a Feather, así como a su propio Equipo Scrum. Ver también Experiencia en el Dominio en Roles.

Los límites del Equipo de Desarrollo, y la identidad, así como los límites del Equipo Scrum y la identidad, son explícitos. La noción de identidad del equipo es clave para el Orgullo de Equipo y para el funcionamiento eficiente de la organización, ya que la identidad del equipo aporta el contexto social que ayuda a optimizar la toma de decisiones. Cualquier noción de identidad organizativa más allá de estas dos debe ser tácita y no explícita o administrada. De nuevo, en el Equipo de Desarrollo no hay más títulos formales que el de «Desarrollador». Si hay una sola regla inviolable, es que ningún individuo puede utilizar su estación tácita de experiencia para anular el consenso del equipo o disminuir de cualquier otra manera el espíritu de trabajo en equipo, como en El espíritu del juego. Unas Normas de Conducta desarrolladas conjuntamente son un fuerte presagio de la identidad del equipo.

Puede haber pericia en los roles a nivel individual, pero es importante completar este patrón con Equipos Transfuncionales siempre que sea posible para optimizar la posibilidad de tomar decisiones locales.

La Ley de Conway original surgió del software (ver , pp. 28-31). Hay muchos mitos asociados con el origen y la práctica de la Ley de Conway. Durante mucho tiempo se sostuvo que la orientación a objetos apoyaba la Ley de Conway al localizar las preocupaciones del mercado dentro de las clases. Eso es cierto a medias; las clases tienden a encapsular las preocupaciones a largo plazo de la competencia central de la organización. Sin embargo, la orientación a objetos parece centrarse en la conexión entre la experiencia de los desarrolladores y los artefactos que desarrollan, más que en cualquier conexión con el mercado o los casos de uso. La preocupación por la alineación con la estructura del mercado debería superar la preocupación por la visión del mundo de los desarrolladores de su proceso y producto.

El estilo de desarrollo en cascada tuvo su apogeo. En las organizaciones en cascada, la estructura organizativa principal seguía las etapas del proceso: análisis de requisitos, diseño, implementación y prueba (, pp. 1-9). Según la Ley de Conway, la estructura organizativa reflejaba esos procesos. El software bien podría reflejar esas fases también: por ejemplo, una arquitectura orientada a servicios (SOA) evidenciará la mayoría de los requisitos de valor añadido en la capa de integración de servicios, mientras que los servicios individuales se encuentran en otra capa. La cascada pone todas las características en manos de los desarrolladores a la vez, lo que permite razonar sobre las interacciones entre las características. Mientras que los enfoques de diseño de software de la era de la cascada trataban de alinear las preocupaciones del mercado (casos de uso) con la arquitectura, la estructura organizativa cortaba esa taxonomía. Lo mismo puede decirse de la organización de la línea de montaje en las fábricas.

Debido a que los equipos de desarrollo son equipos de características, deben centrarse en una característica a la vez (como en Swarming). El principal entregable de mercado de Scrum es una característica, y en este sentido, hay una buena alineación entre la estructura del equipo y el mercado. Scrum no dice nada sobre la forma de la arquitectura del producto, pero en el espíritu de la agilidad tiende a desalentar la propiedad individual del código. Cada equipo de desarrollo tiene licencia para trabajar en cualquier parte del producto. Podemos decir que Scrum equilibra los beneficios organizativos de la encapsulación con los beneficios de la alineación del equipo con el entregable del mercado. El propietario del producto, con el apoyo del equipo de desarrollo, gestiona la forma de manejar las interacciones de características que surgen con el tiempo.

Considere, por ejemplo, que un equipo puede implementar la función de llamada en espera para un sistema de telecomunicaciones, mientras que otro implementa el desvío de llamadas. Debido a la emergencia, no siempre se puede prever el coste de resolver las dependencias entre dos elementos del Product Backlog (PBI) cualquiera, por lo que, en general, es imposible superar este problema asignando los PBI a los equipos. En cualquier caso, asignar prematuramente el trabajo a los equipos puede hacer imposible que la gente trabaje eficazmente en las partes difíciles (especialmente las relacionadas con la interacción entre las partes) y limita la auto-organización en el nivel del Equipo Scrum. Las dos características pueden ser altamente interdependientes, pero la estructura de Scrum no da la talla de primera clase a esas interacciones. En este caso, probablemente sería mejor que un solo equipo desarrollara ambas características. La forma de asignar el trabajo a los equipos se basa en la planificación continua y la toma de decisiones compartidas, a partir de la Planificación del Sprint. Un buen equipo Scrum se esfuerza por dividir el trabajo entre los equipos de desarrollo a través de interacciones íntimas, pero de tiempo limitado, entre el Product Owner y el equipo de desarrollo, como en los eventos para restablecer continuamente un Backlog de Producto Refinado, así como a través de la Planificación de Sprint.

La gestión suele ser un componente de la mezcla organizativa, aunque hay algunos desarrollos de Scrum que se ejecutan sin ningún tipo de gestores (por ejemplo, ver el reciente vídeo sobre la transformación ágil en Bosch Software Innovations. ) El ethos de Scrum tiende a centrarse en las personas y el producto, y el enfoque se encarna en los roles de Scrum y las organizaciones (como el Equipo de Desarrollo y el Equipo de Propietarios de Producto) que representan. Si una organización con gestores preexistentes se propone introducir Scrum, es demasiado fácil para el esfuerzo de Scrum descartar la parte de gestión de la organización como de otro mundo. En tales situaciones en las que una organización libre de gestión no es una opción, es crucial involucrar a los gerentes.

Steven Johnson. De dónde vienen las buenas ideas. Nueva York: Riverhead Trade, 2011.

Stewart Brand. Cómo aprenden los edificios: Lo que ocurre después de construirlos. Nueva York: Penguin, 1995.

Brian Foote y Joseph Yoder. «Big Ball of Mud.ˮ En Pattern Languages of Program Design 4, Brian Foote et al., eds. Londres: Pearson, 2000.

Daniel Pink. Drive: La sorprendente verdad sobre lo que nos motiva. Nueva York: Riverhead Books, 2011.

Melvin E. Conway. «How do committees invent?ˮ En Datamation 14(4), abril, 1968, pp. 28-31.

Dr. Winston W. Royce. «Managing the Development of Large Software Systems.ˮ En Proceedings IEEE WESCON, agosto de 1970, pp. 1-9. (Publicado originalmente por TRW.)

Bosch Software Innovations. «Lecciones aprendidas: Agile organization at Bosch Software Innovations.ˮ YouTube.com, 15 de junio de 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Créditos de las imágenes: Imágenes proporcionadas por PresenterMedia.com.