Not SAFe for work
Y el circo de product management
El otro día vi la entrevista a Marti Cagan con Lenny y me hizo pensar en lo que hemos vivido el año pasado. El año pasado hemos visto varios despidos en empresas tecnológicas, con un impacto muy fuerte en el área de producto. ¿Cómo puede ser que el rol que más tiene aportar al negocio sea el foco de estos despidos?
El detonante de esta avalancha de despidos fue la controvertida declaración de Brian Chesky en la que comentaba que iban a prescindir del roll del product manager dentro de los equipos de desarrollo. En realidad el cambio iba consistir en una transición hacia un papel más enfocado al negocio, parecido al rol del Product Marketing Manager de Apple, y menos en la gestión del día a día de los equipos de desarrollo.
Por poner dos ejemplos más locales, Glovo y Factorial han realizado movimientos similares, haciendo hincapié en la falta de aporte de valor de las jerarquías de producto al producto en si mismo. Conforme las organizaciones han ido creciendo se han ido creando estructuras de poder, que “gestionaban cosas”.
Cuando oigo estas afirmaciones de empresas que considero que tienen buenas dinámicas de producto me gusta reflexionar sobre los motivos de raíz que les han podido llevar ahí.
Creo que en este caso, el problema de raíz es que hacer producto es complicado . Ni el problema es fácil de definir, ni la solución es fácil de ejecutar. Por eso se dedican tantos esfuerzos en las formalidades de la gestión de productos, en vez de entender mejor el negocio y hacer el trabajo duro de mejorarlo.
¿A que me refiero con formalidades? Pues por ejemplo cómo aplicar Scrum de manual.
Creo que alguna vez he comentado que no soy muy fan de Scrum. Creo que el framework está bien planteado y que cada ceremonia y artefacto aportan valor a lo largo del ciclo de desarrollo del producto. El problema no es que Scrum esté mal diseñado, el problema es que es un framework muy enfocado a la parte de gestión del desarrollo de software y que por lo general se implementa en la superficie y no en su trasfondo. Esa es la parte que creo que está rota de Scrum. Hemos quitado parte de madurez a los desarrolladores en campos como el trabajo en equipo o la resolución de problemas y hemos creado roles dedicados a ello . Sí, hablo del PO que sólo gestiona backlog y el Scrum Master que vela por que los principios de Scrum se practiquen acorde a lo que el dogma indica.
Los equipos maduros de desarrollo, implementan Scrum bien y funciona. Son capaces de incorporar estos roles, coordinar las distintas reuniones y el desarrollo de artefactos, sin que eso nuble el objetivo principal de trabajo que es desarrollar código de calidad que solucione el problema de los clientes de la empresa.
El problema es que en aquellos equipos dónde Scrum viene impuesto, de repente nos encontramos más tiempo dentro del equipo intentando aplicar el framework y sobre todo, preocupados por si lo estaremos aplicando bien o no.
Esto es product management barato.
SAFe como ejemplo de product management barato
El otro día me encontré esta charla de Mark Rendle (@rendlemark).
El foco de la presentación es sobre todo repasar algunos errores que han costado millones de euros a la humanidad cómo decidir utilizar 6 dígitos para las fechas hasta el famoso 2KY. Si te gustan este tipo de curiosidades de programación de algunas cagadas históricas te recomiendo el video entero.
Pero sin duda alguna, la parte que más me gustó, fue su mención a SAFe: Scaled Agile Framework for Lean Enerterprises.
¿Qué es SAFe? Un framework de organización para grandes empresas que quieran adoptar un modelo más ágil. El framework presenta una serie de flujos y artefactos que se pueden combinar para conseguir delegar independencia a los equipos a la vez que se coordinan los esfuerzos de toda la empresa.
¿Suena bién no?
A SAFe le pasa como a Scrum. No está mal sobre el papel. El problema es cuando se utiliza por organizaciones para justificar el trabajo de personas de gestión que no contribuyen al core del negocio. Al fin de al cabo, por qué es necesario montar una jerarquía de cinco niveles para seguir evolucionando el producto.
Si nos enfocamos en lo que dice el Agile manifesto,
Individuals and interactions proceses and over tools.
En qué momento, encadenar a los equipos de trabajo a ceremonias de sincronización con otros equipos, tener una cadencia fija que dependa de la empresa o compartir el backlog en un mismo proyecto de Jira se parece al axioma sobre el qué se sustenta todo.
En mi opinión no lo hace…
Tampoco creo que SAFe sea un mal framework. Simplemente creo que junta dos cosas que por lo general no me gustan de los dogmas agile:
Es muy prescriptivo: SAFe define como debe comportarse cada equipo dentro de la organización y sobre todo como deben relacionarse entre ellos. En mi opinión cada empresa tiene suficiente complejidad, como para tener que adaptar sus procesos a un framework standard
Se centra más en los flujos de trabajo que en el aporte de valor de los equipos. Por compararlo con otro framework, creo que trabajar con una North star metric o con OKRs pone más foco en el valor que en los flujos de trabajo.
Usar la calidad de la implementación del framework en vez de métricas de negocio es bastante común ya que es más fácil medir el éxito de una implantación en función de las dailies que se realizan o en cuantos equipos tienen scrum master de oficio en vez de ver el impacto que ha tenido el desarrollo del ultimo trimestre en los objetivos globales de la empresa.
Entonces, si SAFe y estos frameworks son tan malos, ¿por qué hay tantas empresas implementándolos y tantas empresas adaptando sus forma de trabajar? Ó ¿por qué me hablas de una framework del cuál no puedo sacar nada útil?
Creo que Safe es una de muchas formas de resolver el mismo problema, la coordinación de equipos con mucha autonomía pero con un mismo objetivo. Safe busca minimizar que dos equipos estén trabajando en lo mismo sin saberlo o maximizar el valor combinado aportado debido a una buena coordinación entre ellos.
Tener un roadmap común dentro de la organización, reuniones periódicas dónde se revisen los objetivos comunes de la empresa o dónde se compartan los últimos avances de cada equipo son herramientas que fuera del framework de SAFe, pueden aportar valor a la empresa.
El circo empieza cuando en vez de realizar actividades que aportan valor a la empresa y al negocio, empezamos a realizarlas para ponernos un sello más de agilismo en el pecho.
Álvaro, me ha gustado mucho tu post.
La realidad es que a veces se pone muchísimo foco en la metodología (Scrum, SAFe, etc.) y se nos olvida que hay que adentrarse en las entrañas del negocio y entenderlo de arriba a abajo para luego poder saber cómo hacer que crezca.
Entender el negocio va definitivamente primero, y luego lo segundo es el framework. Lo que pasa que entender el negocio no se puede "paquetizar y vender" tan bien como un framework que suele encajar con calzador en muchas organizaciones.
Estandarizar la forma de trabajo ayuda, pero bajo mi humilde opinión antes hay que entender muy bien cómo hace nuestra empresa dinero, para luego de forma organizada proponer cambios para poder crecer.