Si cada funcionalidad a implementar te dicen que son dos sprints, no es que tus desarrolladores no sepan programar, el problema es tu arquitectura.

Como te lo cuento.

Y seguro que has desconfiado de tu equipo de desarrollo.

Y, evicentemente, es normal.

¿Por qué?

Porque no importa cuál fuera la funcionalidad a implementar o la histora de usuario a incluir, siempre son dos sprints.

Respuesta estándar, piensas tú como responsable del producto.

Pero es una respuesta que no te sirve demasiado porque, por lo que sea, tú no vas allí a pedir funcionalidades porque sí.

Tú tienes jefes.

Como todo el mundo.

Y esos jefes tienen jefes que, a su vez, tienen otros jefes cuyos jefes tienen que dar cuentas al os accionistas.

Un rollo, sí, pero así funciona el tema.

Y claro, tú, como responsable del producto, a pesar de cometer el mayor de los pecados que se pueden cometer en una metodología ágil vas y multiplicas.

Multiplicas el número de historias de usuario para la próxima entrega de fin de año por dos esprints (recordemos que es la medida estándar)

Y te das cuenta que sí que llegáis a la entrega de fin de año. Pero del año que viene no, del siguiente.

Y claro, eso ya no mola tanto.

Más que nada por el tema de que no te echen a la calle, por no tener que dar las miiiiismas explicaciones que el anterior trimestre y que el anterior o excusas similares.

"Es que nos hemos retrasado"

"Es que es muy difícil añadir nueva funcionalidad"

"Es que el equipo de desarrollo es muy lento"

"Es que el perro se comió mi backlog"

Claro, ahí empiezan las tensiones entre el equipo de desarrollo y el equipo de producto.

Y normal.

"Es que no hacen más que poner problemas" piensa el responsable de producto.

"Es que vaya cosas nos pide este" piensan los desarrolladores.

Y así genial todo oiga.

Menos por el tema de que el producto que tenéis entre manos no sale ni a tiros.

Bueno, igual tiros sí que hay, porque estas cosas nunca terminan bien.

Y es que todos estáis pasando por alto algo sumamente importante y que os está pasando desapercibido.

El punto de encuentro entre el equipo de desarrollo y el equipo de producto es la arquitectura de software que sustenta la aplicación.

Y no hay arquitecturas buenas ni malas.

Hay arquitecturas adecuadas o inadecuadas.

Ahí tienes el problema. No se pueden añadir funcionalidades de manera eficiente en un arquitectura inadecuada.

Es imposible.

No hay manera.

Es como intentar meter el cuadrado en la figura del triángulo.

Mira que lo aprendimos de bebés con los juguetes de Playskool, pero nada oye.

¿Y esto tiene remedio?

Pues sí, claro que sí.

Primero teniendo una arquitectura de software que responda a las necesidades del negocio.

Segundo que el equipo de desarrollo participe en la definición de esa arquitectura, la interiorice y la pueda utilizar para sacar funcionalidades de manera rápida y eficaz.

¿Y esto cómo se consigue?

Pues muy fácil, debes contactar con un arquitecto de software al que le importe el negocio y sacar funcionalidad adelante, sin importar la tecnología. Que además tenga experiencia en formar equipos de desarrollo.

¿Y dónde encuentro a esa persona?

PUES AQUÍ