¿Puede aplicarse Scrum en las software factories? Hace unos días en uno de los workshops de Certified Scrum Master se dio un debate muy interesante alrededor de esta pregunta.
Creemos que Scrum y las típicas Software Factories son incompatibles por naturaleza. La clave de esta creencia está en la palabra "típica".
¿De dónde viene la incompatibilidad? Aquí compartimos los impedimentos del progreso más frecuentes que hemos 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 ser competitiva, la fábrica busca incrementar ventas, a menudo reduciendo precios y optimizando costos mediante mano de obra económica, estandarización de procesos y especialización de tareas.
La reutilización de componentes de software es clave para reducir costos. Aunque no siempre se implementa eficientemente, una ventaja significativa en una fábrica es mantener un inventario de partes estándar que pueden integrarse en proyectos para disminuir el esfuerzo en 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 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 una 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”.
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.
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
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 podríamos llamar 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.
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.
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í podrá funcionar la agilidad, y en particular Scrum, en una ex Software Factory devenida en Digital Products Crafter.
