¿Cómo pueden los arquitectos trabajar con equipos Scrum autoorganizados?

Una organización con varios equipos ágiles de Scrum también tiene un pequeño grupo de personas designadas como "arquitectos empresariales". El grupo EA actúa como control y guardián de la calidad y el cumplimiento de las decisiones. Esto lleva a solapamientos entre la decisión del equipo y las decisiones de EA.

Por ejemplo, el equipo puede querer usar la biblioteca X o usar REST en lugar de SOAP, pero el EA no aprueba eso.

Ahora, esto puede llevar a la frustración cuando se anulan las decisiones del equipo. Llevado lo suficientemente lejos, puede conducir a una situación en la que la gente de EA "toma" todo el poder y el equipo termina desmotivado y no es muy ágil.

Las guías Scrum tienen esto que decir al respecto:

Autoorganizado: Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir el Backlog del Producto en Incrementos de funcionalidades potencialmente liberables.

¿Es eso razonable? ¿Debería disolverse el equipo de EA? ¿Deberían los equipos rechazar o simplemente cumplir?

Un equipo de desarrollo está formado por 3–9 personas con habilidades interfuncionales que realizan el trabajo real.

Scrum Master debería invitar a "Enterprise Architect" a formar parte del equipo del proyecto. Entonces la comunicación entre el arquitecto y los programadores sería excelente.

La elección de la tecnología utilizada es parte de los requisitos del software, lo que significa que es parte de la solicitud de características que no utilice ciertas tecnologías, por cualquier razón.

Los arquitectos hablan por los sistemas y la base de código porque los sistemas y la base de código no pueden hablar por sí mismos. Tener un arquitecto generalmente es lo mejor para los intereses a largo plazo de una empresa, especialmente uno que se basa en software que se construye internamente.

Los arquitectos no les están diciendo a los desarrolladores cómo convertir la acumulación en incrementos (sprints), están diciendo qué tecnologías pueden y no pueden usarse. Estás combinando dos problemas diferentes.

La solución es no cambiar nada. Si sus equipos se frustran porque los arquitectos son demasiado restrictivos o demasiado prepotentes, ese es un problema de personal que no tiene nada que ver con SCRUM y debe abordarse con las partes interesadas del negocio como un tema de satisfacción de los empleados y, si es posible, el resultado final ("Nos lleva x%más tiempo desarrollar características yporque el arquitecto zno nos deja usar Turbo Pascal").

Este tipo de cosas son necesarias para mantener el equilibrio entre la necesidad de un equipo grande para realizar el proyecto y la necesidad de mantener pequeños los equipos ágiles.

En general, el 'scrum líder del equipo' está compuesto por un miembro elegido de cada uno de los equipos más pequeños. Eso proporciona algo de la naturaleza autoorganizada, así como también proporciona algún tipo de representación para que las decisiones tomadas por el grupo de alto nivel sean aceptadas por el grupo ágil.

Para su escenario particular, algo debe hacer para detener la desmotivación del equipo ágil, pero probablemente no la rebelión o la simple aceptación. El equipo necesita darse cuenta de que estás allí para hacer un buen software, no para someterte a los ideales. Tener un montón de equipos diferentes, cada uno con diferentes tecnologías para hacer cosas similares en el mismo proyecto, conducirá a un software peor. Tener un montón de equipos diferentes que usan diferentes estándares de codificación en el mismo proyecto conducirá a un software peor.

Por lo tanto, necesitará alguna forma de llegar a un consenso sobre cómo va a funcionar el proyecto. El scrum líder del equipo se usa en otros lugares de manera efectiva. Es posible que deba hacer algo diferente o analizar por qué su grupo no lo está haciendo de manera efectiva.

La pregunta es: ¿Cuál es la razón por la que existe este equipo de Arquitectos? La única razón por la que puedo pensar es para hacer cumplir la interoperabilidad entre varios equipos. O los equipos están trabajando en varias partes de un solo producto y este equipo de arquitectos existe para mantener cada parte trabajando en conjunto.

Realmente no creo que este esquema pueda funcionar bien en un entorno ágil, por las razones exactas que usted dice. Los diversos equipos deben ser independientes y también lo deben ser sus entradas y salidas. Por lo tanto, restringir sus resultados solo debe ser parte de los requisitos de entrada. Pero esas limitaciones deberían ser razonables. Algo como "No debe usar la biblioteca X" no es un buen requisito, pero decir "Debe limitar al mínimo el número de bibliotecas de terceros usadas" o "Agregar nuevas bibliotecas, que no se usan en otros equipos debería ser limitado". debería estar bien.

Luego disolvería el equipo de arquitectos en todos los equipos y usaría su experiencia en cuestiones de arquitectura. Al formar parte del equipo, podrán ver mejor los problemas que tiene el equipo y podrían tener mejores ideas u opiniones más educadas sobre el cambio de las partes centrales de la arquitectura. También se debe alentar a los arquitectos de todos los equipos a que se comuniquen para garantizar que la arquitectura se mantenga constante en todos los equipos.

El grupo de Scaled Agile Framework habla muy bien de esto. La mayoría de nosotros tratamos a nivel de equipo, pero al escalar necesitamos reconocer que también hay roles que desempeñar a nivel de programa y cartera. Deben tomarse decisiones arquitectónicas en toda la organización, y eso debería alimentar lo que está sucediendo en los niveles inferiores de la organización. ¡No tiene nada de malo tomar decisiones arquitectónicas!

En relación con esto, el reciente libro de Dean Leffingwell sobre requisitos ágiles de software es una buena lectura sobre este tema, lo he estado leyendo yo mismo.

También tenemos múltiples equipos ágiles (algunos hacen Kanban, algunos Scrum) y arquitectos. Los arquitectos son responsables de la infraestructura que abarca todos nuestros productos (bibliotecas auxiliares, autenticación, infraestructura de construcción), etc. Toman decisiones técnicas, pero también implementan cosas, principalmente componentes de infraestructura.

Esto funciona bien, y generalmente no hay conflicto. Creo que un punto crucial es:

Los arquitectos no tienen autoridad formal sobre los equipos, y no pueden simplemente anularlos. Normalmente, los arquitectos toman decisiones que se aplican a todos los productos, y los equipos toman decisiones para su producto. Si hay un conflicto, entonces el arquitecto y el equipo solo necesitan llegar a un acuerdo o escalar a la gerencia (aunque eso rara vez ocurre).

Creo que es realmente importante hacer que los arquitectos y desarrolladores sean pares. Ambos trabajan hacia un objetivo común, solo en diferentes áreas. Si nadie puede simplemente "anular" al otro, la cooperación será mejor.

No veo ningún conflicto aquí. Por lo que entiendo, todo el EA (como un título pomposo que creo que es) está destinado a hacer es QA. Todos deberían ser conscientes de eso.

Debe considerar que, en cualquier metodología de desarrollo (que merece ser considerada una), la recopilación de requisitos es un paso crucial, ya sea iterativo o inicial.

Algunos de estos requisitos están establecidos por la política de la empresa. Y estos establecen las reglas básicas:

• El equipo tendrá que cumplir con ellos como con cualquier otro requisito. Desafiar la política simplemente queda fuera del alcance del proyecto y debe manejarse por separado.
• El trabajo de EA es hacer cumplir estos requisitos y no imponer su imaginación personal. No les gusta X, esa es su opinión personal. Nada más y nada menos. Trátelo como cualquier otra opinión. Sin embargo, si el asesor experto puede demostrar que el uso de X viola un requisito existente, están en su derecho de prohibir el uso de X y si conocen una alternativa viable y el equipo no, entonces es su derecho hacerla cumplir.

Pero de cualquier manera, un requisito se cumple o no. Si esa determinación es difícil de hacer, entonces falta el requisito y debe reiterarlo para que sea verdaderamente comprobable (en un sentido más amplio). Debe manejar eso como cualquier requerimiento de reiteración.

Su arquitecto no debe anular las decisiones tomadas por sus equipos ágiles. Su arquitecto debe incluir estos en los requisitos / historias pasados ​​a los equipos. Deben mantener a los equipos actualizados cuando cambie el panorama del proyecto y se introduzcan nuevos requisitos de interoperabilidad.

Los arquitectos que dan órdenes y examinan decisiones técnicas es un defecto cultural. Se ven a sí mismos como el "jefe" en lugar de simplemente mantener una meta / visión compartida y mantener equipos separados en la misma página. Las metodologías ágiles se basan en la comunicación y el contacto. Cuando sus arquitectos no se involucran hasta que se toman las decisiones, están fallando en la agilidad.

Martin, creo que puedes tener una idea errónea sobre cómo funciona un equipo autoorganizado en su entorno.

Usted citó la Guía de Scrum: "Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir la Cartera de Productos en Incrementos de funcionalidad potencialmente liberable".

Esta no es una licencia para que el equipo Scrum haga lo que quiera (siempre que lo haga) sin tener en cuenta las necesidades tecnológicas y comerciales de la empresa en su conjunto, y las necesidades de los otros equipos.

Seguro que los interesados ​​pueden abusar de su influencia. Ese es uno de los desafíos de la colaboración, y ciertamente no se limita al EA. Pero la colaboración no termina en el límite del equipo.

Cascada o Scrum (esto parece mezclar dos, lo que sí, no va a funcionar), eso me parece una capa de administración bastante inútil en primer lugar. Los encargados de las decisiones tecnológicas deben ser desarrolladores principales, el gerente general de desarrollo cuyo trabajo debe ser evitar que las preferencias del desarrollador conviertan su aplicación en una hidra de opciones tecnológicas, y el presupuesto de quien tenga que pagar la factura potencial.

Nada me sigue asombrando como los no desarrolladores que realmente tienen el descaro de tomar decisiones tecnológicas sin siquiera consultar a las personas reales que tienen que sufrir las consecuencias de esas decisiones.