Hace casi 20 años que nació el Desarrollo Ágil de Software. Su primer principio nos recuerda que estamos aquí para ayudar a un customer, a un usuario. Todo aquel software que se desarrolla y no tiene uso supone una pérdida de dinero y de tiempo. El software con valor es aquel que tiene uso, que tiene un propósito, y que es rentable.
Muchas veces nos echamos las manos a la cabeza cuando vemos autopistas sin coches, aeropuertos sin aviones, o cualquier obra que no tiene ninguna utilidad. La crisis de 2008 desveló un mundo de excesos de cosas inútiles. ¿Nos ocurre lo mismo con el software que no se usa?
Scrum te dice si tu software es de valor
Muchas empresas que apuestan por Scrum creen que van a conseguir mejorar su entrega de valor con ello. Siento dar malas noticias, Scrum no te va a ayudar a eso. Lo primero que vas a conseguir con Scrum es transparencia, levantar la alfombra y ver la “suciedad de tu empresa”. Algunos ejemplos:
- Necesitamos equipos multifuncionales end-2-end: en esta empresa trabajamos por silos y no se puede, hay un departamento de calidad que valida los desarrollos.
- Los equipos son autoorganizados: aquí les decimos con qué herramientas trabajar, dónde sentarse y cómo hacer las cosas.
- En Scrum tratamos de maximizar valor, ¿medís valor?: lo máximo que medimos es la velocity de cada equipo y la comparamos.
Scrum no va a hacer que tus equipos entreguen más valor, son los propios equipos los que tienen que cambiar. Scrum te va a dar transparencia, te va a ayudar a enseñar las deficiencias, y eres tú el que tienes que dar un paso al frente.
Logic model para entender el software con valor
Imagina que eres desarrollador de software y acabas de entrar en un nuevo equipo para desarrollar una web, para una empresa que recauda fondos para llevar agua a países necesitados de África y, así, lograr que prosperen.
A la hora de medir el trabajo de un equipo, podemos utilizar el logic model. El logic model está dividido en cinco partes que tratan de medir todo aquello que ocurre en un equipo o en una organización.
En primer lugar, tenemos los inputs, todo aquello que entra en el equipo: personas, herramientas, ordenadores, etc.
En segundo lugar, el logic model mide las actividades, todo aquello que hace el equipo: eventos de Scrum, técnicas de desarrollo, reuniones, emails, dinámicas de trabajo… en nuestro ejemplos las actividades son el desarrollo de software, como un genérico.
Tras las actividades, medimos los outputs, los resultados de esas actividades: features concretas, documentos, manuales, etcétera. El resultado puede ser la propia web para poder recaudar fondos.
A continuación, disponemos de los outcomes, que son los resultados de valor que producen nuestros outputs. En los equipos, suelen ser las métricas de valor: nuevos usuarios, porcentaje de conversión, ROI, u otros. En nuestro ejemplo, el dinero recaudado o la cantidad de agua que hemos podido comprar.
Y por último, el logic model se centra en los impactos, que son outcomes a largo plazo. Por ejemplo, el poder llevar camiones cisterna cada día a diferentes pueblos de África, conseguir su desarrollo y generar riqueza.
¿A qué te dedicas?
Imagina que un familiar o un amigo te pregunta: ¿Cuál es tu trabajo? En función del modelo lógico, podemos responder de varias maneras:
- Si piensas en los inputs, dirás que perteneces a un equipo
- En el caso de que pienses en actividades, dirás que desarrollas software
- Cuando piensas en outputs, dirás qué estás construyendo una aplicación web para recaudar fondos
- Si te centras en los outcomes, responderás la cantidad de fondos o de agua que sois capaces de conseguir.
- Finalmente, si piensas en impactos, comentarás la cantidad de camiones que sois capaces de contratar y cómo ayuda al desarrollo de varios pueblos de África.
Ante una misma situación, y un mismo trabajo, cambia mucho dónde ponemos el foco. ¡Lo mismo ocurre con Scrum!
Scrum y el software con valor
Scrum propone una serie de roles que utilizan la inspección y la adaptación, en diferentes eventos, sobre una serie de artefactos. El marco nos permite visualizar en qué punto está nuestro trabajo para poder adaptarnos y tomar decisiones rápidamente que nos permitan ser efectivos.
Sin embargo, la efectividad está condicionada por el punto del logic model en el que nos focalicemos. No es lo mismo centraros en el número de personas del equipo o en la cantidad de software que desarrollan, que centraros en la cantidad de camiones cisternas que hemos conseguido llevar hasta la fecha. Una pregunta muy buena puede ser: ¿cuántos caminos cisterna más vamos a poder llevar con lo que acabamos de terminar este Sprint?
La Sprint Review es la misma, pero no es lo mismo centrarte en sí el equipo trabajaba bien, o si realmente da resultados. Scrum es igual, pero el mindset que utilices es la esencia del éxito de una organización.
El mindset Scrum
En las empresas donde no funciona Scrum, el problema no radica en la técnica ni en cómo lo aplicas sino en el foco donde pones las conversaciones. No es lo mismo hablar de valor y centrarnos en generar más, que en hablar de la cantidad de horas que un equipo trabaja. Podemos hacer mucho software, pero que puede que esté en la dirección equivocada, métricas como la velocidad del equipo no nos dicen si estamos teniendo éxito.
Podemos medir el número de funcionalidades que un equipo desarrolla, pero si esas funcionalidades no generan fondos para comprar agua, no sirven de nada. Por eso, las métricas de performance del equipo dan información, pero nunca dicen si estamos teniendo éxito.
Esta es la auténtica diferencia entre equipos Scrum que funcionan, y aquellos equipos Scrum que siguen dando los mismos resultados que los tradicionales. En estos, el paradigma sigue siendo la entrega en fecha, no crear software con valor.
Y tú, ¿piensas en trabajar mucho o en dar resultados?
