Esta es la segunda parte del post sobre “Implantando la agilidad en empresas grandes”, dos post en que te voy a dejar cinco decisiones, y buenas prácticas, que se suelen plantear principalmente en este tipo de implantaciones.
4 – Equipos especializados frente a multifuncionales
En Scrum and XP from the Trenches Henrik Kniberg hace una buena exposición sobre este tema. Supongamos un sistema con tres componentes: cliente, servidor y BBDD. Una opción podría ser tener un equipo (o varios) por cada componente, un quipo para el cliente, otro para el servidor y un tercero para la BBDD.
El problema del anterior enfoque, el de equipos especializados, viene cuando una historia de usuario, un requisito funcional, o no funcional, involucra a los tres equipos.
Frente a los equipos especializados, la opción recomendada son los equipos multifuncionales. En estos equipos habría personas con conocimiento de la parte cliente, personas de la parte servidor y personas con conocimiento en la BBDD. Esto ayuda a eliminar dependencias y bloqueos.
5 – Una pila de producto para todos los equipos o una pila de producto para cada equipo
Existen y se observan ambas estrategias, creo que la decisión final depende del producto, del ambiente de la empresa, etc.
En la primera, una pila de producto para todos los equipos, habiendo, como vimos antes, sincronizado el comienzo de los Sprint, lo que se suele hacer es una reunión de planificación del sprint con todos los equipos, finalizada la cual cada equipo sabrá las historias de usuario a implementar. Esto simplifica las pilas pero necesita unas reuniones de planificación de Sprint eficientes, con buen ambiente, etc.
En la segunda opción, el Product Owner de los Product Owner, y los Product Owner de cada equipo, deben mantener varias pilas de producto. Aquí el problema puede venir de si el, o los, Product Owner pueden saber qué equipo técnico debe implementar cada historia de usuario.
Concluyendo…
Aquí te he dejado algunas de las decisiones más típicas que se suelen plantear, luego, como todo, cada uno de los anteriores tendrás que adaptarla al entorno específico.
Puedes también complementar todo esto con algún caso de estudio, que te de ideas, como aquel sobre como Spotify organiza, de manera ágil, su departamento de desarrollo software.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier!
yo no estoy totalmente de acuerdo con los equipos multifuncionales de los que hablas en el punto 4. Creo que en el enfoque que tu planteas de cliente, servidor y BD es demasiado estanco y casi no hay otra solución posible que el equipo multifuncional.
Si dividimos la aplicación por funcionalidades en vez de por componentes caben otros enfoques. Por ejemplo: el tema de pagos, que suele ser bastante complejo, por un lado (con sus especialistas en pagos), el backend con los suyos (puede haber un gestor de contenidos) y el resto de frontend con profesionales especializados en JS o la tecnología que sea…
A mí me gusta que todo el equipo sepa hacer de todo pero no para que lo hagan, si no para que puedan tener en cuenta las implicaciones que tienen para otros equipos sus acciones. Creo que a la hora de la verdad, y si surgen problemas, lo mejor es tener especialistas.
Saludos