¿Deberíamos organizar múltiples subequipos ágiles a lo largo de grupos de clientes o a lo largo de componentes de software?

Experimento.

Ninguna respuesta presentada aquí se ajustará a su producto, equipo o cliente específico. Agile promueve la mejora continua, así que adelante.

Con eso en mente, podemos revisar algunos elementos clave a tener en cuenta al experimentar:

• ¿Por qué cambiar? Tenga claros los problemas que el equipo pretende abordar al aplicar estos cambios. Cambiar por cambiar "para volverse más ágil" no es un propósito real. Su propósito real es entregar valor con más frecuencia y con previsibilidad. Agile es una herramienta que puede ayudarte en eso.

• Los equipos deben poder entregar un producto completo . Si organiza equipos por componentes funcionales, tendrá más experiencia en este componente específico, pero puede terminar con un gran equipo en la interfaz de usuario que ofrece muchos cambios que no se pueden activar porque el equipo de back-end no tiene tanta experiencia.

• Entienda su fondo actual del conocimiento . Si tiene una sola persona que realiza la interfaz de usuario y esto es clave para todas las entregas, tener diferentes equipos que dependan de esta única persona eventualmente creará un cuello de botella.

La base de conocimientos es uno de los cambios más complejos para los equipos ágiles totalmente funcionales. Si su equipo se basa en el conocimiento de personas específicas, antes de cambiar la estructura del equipo, le sugiero:

1. revisar los antecedentes de conocimientos actuales que tienen los miembros del equipo
2. ¿dónde están las lagunas o los cuellos de botella potenciales si alguien se enferma y luego
3. hable con el equipo que desee ampliar sus conocimientos en estas áreas

Recuerde, uno no necesita ser experto en todas y cada una de las áreas (todavía considero que un "desarrollador de pila completa" es una falacia en la mayoría de los casos). En cambio, uno debe tener un conjunto de habilidades en forma de T que permita a cada subequipo poder entregar con una dependencia mínima de otros equipos.

Esta es una pregunta difícil de responder porque depende de su empresa. La directriz general es optimizar el equipo hacia la creación de valor. Por lo general, una pregunta como esta se plantea como: ¿deberíamos organizar equipos en torno a los componentes del sistema y las áreas funcionales? La respuesta a esa pregunta es más fácil porque con los componentes del sistema, ningún equipo puede ofrecer una característica valiosa a los usuarios por sí solo. Sin embargo, en su caso, parece que ambos pueden ofrecer una función valiosa completa por sí mismos, por lo que la pregunta puede ser, ¿cuál puede ofrecer mejor o más a menudo una función valiosa por sí solo?

Otro modelo a considerar con un número tan pequeño de desarrolladores son los equipos completamente intercambiables. Si todos los equipos pueden hacer todo el trabajo, siempre obtendrá las funciones más importantes más rápido.

Me parece que hacerlo en torno a los componentes de software es más inteligente porque parece que los equipos podrán controlar mejor las decisiones, ya que recibirán la información de varios clientes en una sola función.

Si lo hace al revés: tener varios equipos trabajando en el mismo componente con diferentes aportes del cliente, parece que podría haber una posibilidad de pisar los dedos de los demás.

Es necesario tener en cuenta lo siguiente:

• ¿Cómo estás midiendo el éxito? ¿Qué crees que pasará después del cambio?
• ¿Podría hacer "pilotos" graduales y ver si realmente tienen un beneficio? (ejemplo: comience a mover un equipo que trabaja en un solo componente de software y vea si mejora el rendimiento de alguna manera)