Cuando estaba estudiando para sacarme la certificación de Scrum Master recuerdo que me descargué la guía de scrum y después de leerla un par de veces pensé ... esto es genial ... esto lo soluciona todo. Empecé a aplicar todas las prácticas que aprendí en mi equipo de arquitectura, lo cierto es que funcionaba muy bien. Funcionaba tan bien que el equipo creció hasta 10-12 personas, scrum como tal ya no funcionaba, en scrum daban algunas ideas, pero ya habíamos desbordado scrum. En ese punto, un sólo equipo no tenía sentido, la división del equipo fue necesaria.
A partir de esa experiencia fui observando y leyendo temas organizativos diversos que me llevaron a sacar un patrón de evolución de equipos que se cumplía con cierta frecuencia. Comprendiendo ese patrón de crecimiento orgánico de un equipo de desarrollo (que os explico en este artículo) pude aplicar medidas existosas tanto dentro de Opentrends como en diversos clientes de empresas digitales.
SCRUM es un framework que explica cómo organizar el trabajo de un equipo de máximo 9 personas, cuando necesitas más que eso SCRUM no sirve.
En este artículo os explicaré los tres primeras etapas de crecimiento por los que pasa un equipo de desarrollo de producto digital desde su fundación (cuando el CTO aun pica código) hasta su estructuración. Estas conclusiones son las que he obtenido después de analizar varios casos reales de empresas digital con las que he trabajado en los últimos años y espero que este escrito pueda servir de referencia para CTOs y CEOs de empresas digitales.
Antes de empezar con las tres etapas, os diré que la transición entre dichas etapas es crucial identificar que una etapa está terminando para poder iniciar los procesos de transformación internos que nos permitan seguir creciendo. Intentaré daros algunos tips que he ido aprendiendo para identificarlo.
Posiblemente esta sea el estado más divertido y emocionante para los ingenieros. Existe bastante improvisación y se generan muchas batallitas de piratas que alimentarán la leyenda del CTO en etapas posteriores. Este momento se inicia la cultura de desarrollo y depende mucho del CTO, de su capacidad de liderazgo y de su modus operandi como se implante esta cultura. Esta etapa suele terminar cuando el equipo técnico es de más de 8-10 personas (o antes si hay cierta planificación).
A nivel orgánico todo el mundo depende de las decisiones del CTO y no soporta una estructura de más de 10 personas.
Esta etapa es muy importante para crear vínculos de confianza con el equipo y empezar a encontrar las personas que serán clave en el crecimiento por su actitud y aptitud. Después se puede añadir a cargos de coordinación, pero las partes de la gestión de la confianza y la de formar a alguien en la cultura de empresa seguramente es la que uno no se puede saltar con cargos de responsabilidad, así que si en esta etapa se introducen o identifican personas que puedan crecer con el equipo eso ayudará mucho en fases futuras.
Es importante que el CTO empiece una correcta implantación de las metodologías de desarrollo que le permitan crecer. Por ejemplo, cuando el equipo es de unos 4-5 ingenieros, el CTO puede hacer de Producto Owner y de Scrum Master a la vez. Cuando son unas 8 personas puede delegar el Product Owner a una persona del equipo.
Esta etapa llega a su fin cuando el CTO no puede liderar a los ingenieros de forma directa. En este punto es necesario que los equipos se estructuren y el CTO pasará a tomar otro tipo de responsabilidades más estratégicas.
Varios equipos autónomos con especialización funcional. Se consolida una definición de arquitectura y aparecen nuevos roles: Scrum Master, Product Owner, ...
Este es el momento en el que el CTO deberá garantizar que se establezcan las bases de arquitectura de desarrollo y ALM. Es posible que en la fase anterior ya se haya hablado de cómo hacer las cosas y que se hayan automatizado algunos procesos, pero este es el momento de consolidarlo.
Cada equipo empezará a responsabilizarse de una parte de la aplicación. La división deberá ser natural y usar arquitecturas que faciliten esta forma de trabajar suele ser una buena decisión técnica. Ejemplo de estas arquitecturas son las arquitecturas de microservicios, la componentización del frontend (tanto web como móvil) o incluso los microfrontends.
En esta etapa es la de garantizar que el scrum master está trabajando correctamente, que los equipos se queden bloqueados, que los equipos no superen la fase del conflicto o que no haya propuestas de cambio en el organización suelen ser síntomas que el scrum master necesita algo de soporte. Lo figura del scrum master es básica para organizarse.
Los equipos deben ganar autonomía y la organización deberá cooperar al máximo permitiendo al Product Owner capitanear la toma de decisiones funcionales (con el soporte del equipo) y dotando al Scrum Master de autoridad para realizar cambios organizativos siguiendo CLAMS.
Esta etapa llega a su fin cuando la profundidad del producto requiere mucha coordinación entre equipos o se empiezan a detectar problemas de integración tecnológica entre los productos de los equipos. En este momento se requieren estructuras de coordinación de equipos tanto a nivel organizativo, funcional como tecnológico.
En esta etapa se construirán estructuras organizativa. Si usamos de referencia al framework organizativo de tribus y squads de Spotify, en esta etapa es cuando se requiere el uso de tribus, chapters y guilds. Estas estructuras organizativas nos permitirán coordinar funcionalmente, tecnológicamente y organizativamente el equipo de desarrollo.
Esta etapa requiere una coordinación de objetivos de los diferentes equipos. Las figuras del Program Managers y Software Engineer Managers que den soporte al CTO en la operativa diaria.
Si bien suele ser eficaz poner un Product Owner (PO) compartido cuando un equipo lo divides en dos que operan una misma parte de la aplicación. También hay que tener en cuenta que es una solución poco escalable. Lo mismo sucede cuando intentas hacerlo con el Scrum Master (SM), llega un momento de ambos se vuelven cuellos de botella.
En ese punto es cuando se necesita la figura de Software Engineer Manager (para la coordinación de los SM) y un Program Manager (para la coordinación de los PO).
En este crecimiento de nuestro equipo, el manager de ingeniería de software tendrá como función principal la coordinación de los Scrum Masters. Esto a niveles prácticos es trabajar el triplete Tecnología, Procesos y Equipo, es decir los temas más vinculados a la operativa diaria.
Este perfil depende del CTO y se encarga de la parte más operativa, mientras que el CTO se encarga de la parte más estratégica. Cuando el software crece y se requiere una coordinación de varios SEM, será necesaria la figura de un Director de Ingeniería de Software que los coordine.
El Product Manager será la persona que se encargará de la evolución del producto. El coordinará a los Product Owners (PO) y coordinará las prioridades del backlog con ellos de un modo no impositivo, puesto que los PO deberán mantener su capacidad de decisión.
El Program manager gestionará la tripleta Marketing, Cliente y Equipo para coordinar el desarrollo del producto. A nivel organizativo, estos Product Managers suelen ser los gestores de tribu y (cuando hay varios trabajando sobre el mismo producto) suelen requerir de un Director de Producto que marque la estrategia del mismo. En dado caso, ellos se limitarán a la gestión más operativa.
De saque te diré de entrada que NO, con la figura del CTO con el soporte del Software Engineer Manager a un nivel más operativo y una arquitectura fragmentada debería ser suficiente. La figura de CAO sólo encaja en grandes organizaciones que necesitan construir sus aplicaciones sobre una arquitectura sólida y homogénea.
Esta figura, en una aplicación digital no suele ser necesaria.