El problema de las Software Factories con Scrum

Las razones por las que algunas software factories no logran aplicar Scrum de manera exitosa. Pero es posible revertir esta tendencia si se hacen los cambios necesarios.

¿Puede aplicarse Scrum en las software factories? Hace unos días en uno de mis workshops de Certified Scrum Master se dio un debate muy interesante alrededor de esta pregunta.

Por curiosidad hice una encuesta en instagram (@martinalaimo) con la misma pregunta. De algo más de 100 personas el 77% dijo que sí. Yo, claramente sesgado por mi experiencia y la de mucha gente cercana, tengo una "unpopular opinion": Scrum y las típicas Software Factories son incompatibles por naturaleza. La clave de mi creencia está en la palabra "típica".

Pero para dudar y moderar ese sesgo decidí hacer una nueva pregunta, esta vez en LinkedIn y en Twitter. Me llamó la atención que esta consulta fue vista por casi 5000 personas, y solo hubo 7 comentarios que, en su mayoría son aportes valiosos sobre opiniones y experiencias de otras personas, pero ninguno responde directamente la pregunta.

A partir de esto, también compartí mi opinión en instagram y recibí muchísimos comentarios reforzando la idea de que Scrum y las típicas Software Factories no son compatibles sin antes hacer profundos cambios en el servicio y en el modelo de negocio.

Scrum y las Software Factories son incompatibles si no se dan ciertas condiciones fundamentales

¿De dónde viene la incompatibilidad? Aquí comparto los impedimentos más frecuentes que he encontrado dentro de 4 áreas importantes: modelo de negocio, modelo operativo, cultura organizacional, las personas.

La estrategia de negocio de las software factories

En una Software Factory típica, el cliente proporciona un requerimiento o especificación en detalle y la “fábrica” construye el software respetando esa especificación. Para que la “fábrica” sea competitiva necesita vender más. En muchas ocasiones, la estrategia para lograr más ventas es bajar los precios y optimizar costos, como por ejemplo mano de obra económica, estandarización de procesos y especialización de tareas.

Un aspecto importante que reduce costos es la reutilización de componentes de software. Aunque no muchas veces eficientemente implementado, es otra ventaja de una fábrica que mantiene un stock de partes estándares que luego puede integrar a sus proyectos y así reducir el esfuerzo necesario para la construcción del producto.

Los impedimentos a la agilidad los vemos en la práctica cuando:

  • Se crean big-designs-upfront buscando mitigar riesgos de aprendizaje a partir de la búsqueda de detalle anticipado,
  • Se respeta el requerimiento del cliente a rajatabla asumiendo una de dos posibilidades: 1) que lo que el cliente solicita es lo correcto (la excepción a la regla) y 2) que la responsabilidad de conocer la problemática y la solución es exclusiva del cliente,
  • Se crean equipos de componentes para el mantenimiento de los "stocks" creando así múltiples dependencias entre los proyectos y los equipos de componentes.

Cómo funciona el modelo operativo orientado a proyectos

La operación se orienta a “proyectos” donde el éxito significa entregar en tiempo, lo especificado por el cliente y dentro del presupuesto preestablecido. Para lograrlo hay procesos fuertes de seguimiento y control, y bastante complejidad accidental creada por la burocracia y trazabilidad de las decisiones.

La burocracia y la trazabilidad de decisiones crean complejidades que mueven el foco de la entrega de valor.

La especialización en la tarea crea departamentos que se comportan como silos (área de diseño, área de programación, área de testing, etc.). Para aumentar la eficiencia del silo, las personas (recursos) se asignan a varios proyectos.

Los impedimentos a la agilidad los vemos en la práctica cuando:

  • El foco está en la entrega y no en el valor de lo que hacemos
  • Los procesos se tornan tan burocráticos que se transforman en un obstáculo a la creatividad de las personas
  • Ausencia de autonomía en la toma de decisiones y los procesos no pueden ser alterados a partir de lo aprendido, lo que se refleja en la falta de empoderamiento de los equipos en la mejora continua.
  • Las personas no trabajan enfocadas en los productos, tienen más compromiso con sus tareas individuales que con los equipos o los resultados.

Cultura de la opacidad

Estas organizaciones son propensas a crear una noción de “nosotros vs. ellos” entre desarrolladores y clientes. Crece mucho la desconfianza y la búsqueda de culpables frente a las situaciones críticas. Esto lleva a que se eviten choques apelando a la opacidad de la información. Una frase típica es “esto no lo puede saber el cliente”.

El fuerte foco de la fábrica en entregar proyectos hace muy difícil la creación de cultura de producto, donde los equipos de desarrollo se preocupen por tener una visión a largo plazo, comprender las problemáticas reales de los clientes, acercarse a ellos y medir los resultados basándose en outcomes. Lo que predomina, en cambio, es el “yo hice lo que me pediste”.

Lo que predomina en esta cultura de trabajo es el "yo hice lo que tú me pediste".

El retrabajo se ve como un fracaso, resultado de no haber entendido bien lo que se ha solicitado o el resultado de la negligencia profesional. Muy pocas veces se lo interpreta como un aspecto natural del desarrollo evolutivo de productos.

Los impedimentos a la agilidad los vemos en la práctica cuando:

  • El Scrum Product Owner es excluido del equipo por pertenecer al cliente
  • La relación con el Scrum Product Owner es meramente transaccional
  • No hay transparencia hacia los stakeholders
  • La desconfianza se apodera de las relaciones
  • Las personas no saben para qué están construyendo lo que están construyendo
  • No hay sentido de propósito en el trabajo que hacen
  • El comportamiento es más mercenario (dime qué hacer y lo hago) que visionario (empatizo con el cliente y me motiva resolver su problema)

Personas y su impacto en los resultados

Para reducir costos, los equipos se arman con una mayoría de profesionales en los inicios de su experiencia. Probablemente hayas escuchado que los llaman “recursos junior”. De lo contrario los números no cierran. Esto limita no solo la complejidad y calidad de los productos creados sino también la carrera de desarrollo interna de las personas, porque si ellas crecen muy rápido, también los sueldos crecen y pronto ya no es rentable el modelo de negocio.

Una forma de evitar el estancamiento profesional es cambiando de empresas con frecuencia, generando un alto nivel de attrition.

Para resolver esta problemática del “estancamiento”, los desarrolladores encuentran el crecimiento mudándose de empresas. En vez de ascender dentro de la empresa, obtienen esa promoción como una oferta tentadora de otra empresa. Esto genera un alto nivel de “attrition” y escasez de equipos estables.

Los impedimentos a la agilidad los vemos en la práctica cuando:

  • Los equipos son inestables y con bajo sentido de pertenencia
  • La poca experiencia es una constante
  • Hay alto nivel de frustración con el aprendizaje que la empresa posibilita y con la calidad del trabajo realizado
Realizar un mindset shift hacía Digital Products Crafter

Todo lo anterior no implica que una software factory con estas cuatro incompatibilidades nunca podrá llegar a ser exitosa en el aprovechamiento de la agilidad. Pero para que suceda hay muchos cambios necesarios. Identifiqué todos estos cambios bajo el concepto de transformación de una Software Factory a lo que yo llamo un grupo de Digital Products Crafters, inspirado en la propuesta de Software Craftsmanship, ampliada a todos los involucrados en la creación de un producto, no solo del software que lo materializa.

Modelo de negocio

A diferencia del modelo basado en la idea industrial del software donde la ventaja competitiva está en el ahorro de costos y la producción a gran escala, el nuevo paradigma de orientación a productos digitales tiene sus columnas en la innovación tecnológica y el deleite de los clientes. Yo lo resumo con el concepto de productos alucinantes.

Para lograr este cambio es necesario partir por entender la práctica como una disciplina artesanal donde cada producto construido requiere un esfuerzo único e irrepetible de entendimiento profundo de los usuarios del producto y sus problemáticas y un camino continuo de exploración y descubrimiento que no se puede reemplazar por una definición completa anticipada.

El vínculo con el cliente debe pasar de ser transaccional a ser relacional. La ex Software Factory se asociará simbólicamente a su cliente en vez de limitarse a ser un proveedor de servicios. Esta asociación se refleja fuertemente en la operación y cultura de la empresa.

Los productos digitales exitosos rara vez pueden considerarse como terminados.

Otro aspecto importante, y seguramente disruptivo de este modelo de negocio es que el servicio no solo consiste en crear el producto sino también en formar el equipo de producto y transferirlo al cliente. El resultado del trabajo ahora no es solo el producto construido sino también el equipo de personas que le da vida y lo hará crecer en el tiempo. ¿Para qué? Bueno, algo de nuestros tiempos es que un producto digital exitoso en raras ocasiones puede considerarse terminado. ¿Cuándo se terminó de construir AirBnB, Uber, Spotify, Instagram? La respuesta es nunca. Para alcanzar la vigencia del producto es necesario un trabajo constante de exploración y adaptación y, una vez alcanzado ese objetivo, hay que seguir haciéndolo para mantener el éxito y no perder su interés.

Modelo operativo

Para hacer esto es preciso asumir humildemente que el equipo de producto no es el usuario final y que no saben lo que éste necesita.

En vez de una especificación detallada, ahora reciben una serie de problemas a solucionar y pasan tiempo con los usuarios o consumidores en sus entornos, les ponen atención, los escuchan atentamente y los observan de cerca. Recién a partir de allí podrían tener una idea aproximada de la solución que realmente necesitan crear.

Ya no debería existir el SPOC (Single Point Of Contact), un rol habitual en Software Factories que mediaba la comunicación entre el cliente y el equipo. En su lugar, el equipo de producto no solo es capaz de comunicarse con el cliente (sponsor y stakeholders) sino también con los usuarios y/o consumidores finales.

Por último, el progreso ya no se medirá en términos de output (cumplimiento de hitos del plan basados en alcance y cronograma), sino en términos de outcomes (cambios en el comportamientos de los usuarios o consumidores del producto).

Cultura & Personas

Podría resumir esta sección en tan solo una frase: crear una cultura orientada al producto. Pero, ¿qué distingue a una cultura con estas características?

Foco en los clientes/consumidores: todos los miembros de cada equipo interactúan directamente con los clientes, más allá de los stakeholders. Su razón de estar ahí no es fabricar software, sino atender las necesidades de sus clientes, dentro de las limitaciones del negocio.

Las personas no están ahí para construir lo que sea. Son parte del equipo de producto porque se preocupan por la visión y ayudan a los clientes a resolver sus problemas reales. Debe existir un fuerte sentido de innovación, un deseo ardiente de experimentar con la tecnología y los nuevos paradigmas para crear excelentes productos.

Para esto hay que asumir riesgos. Es imposible lograrlo si lo que se busca es permanecer constantemente en la zona de confort. Aprender mucho y rápido sobre los supuestos más riesgosos. Existe una verdadera colaboración entre las personas del equipo de producto, donde conviven no sólo fabricantes de software, sino diseñadores de experiencia de usuario, y todos los roles necesarios para el desarrollo del producto. El cambio es de 180 grados. Y así creo que sí podrá funcionar la agilidad, y en particular Scrum, en una ex Software Factory devenida en Digital Products Crafter.