Hace unos pocos días atrás Ken Schwaber, que es uno de los padres de Scrum, publicó un interesante artículo sobre valor en Agile y su diferencia con las metodologías tradicionales. He decidido tradudir el mismo para que puedas tenerlo a tu alcance, pero antes deseo que comprendas porqué la metodologías tradicionales no son la mejor opción para gran parte de los proyectos.
Metodologías tradicionales
Hay algo claro a tener en cuenta en con respecto a las metodologías tradicionales: hacen pagar mucho más por un producto de software al cliente y raramente pueden obtener un alto nivel de satisfacción ya que parten de 5 premisas:
1. Congelar los requerimientos al comienzo del proyecto.
2. Realizar pocas evaluaciones parciales (ciclos de reto-alimentación bajos)
3. Considerar como valor a las entregas que no son software
4. Penalizar los cambios.
5. Medir lo que se considera correcto
Congelar los requerimientos
El mayor problema en congelar los requerimientos al comienzo de un proyecto es que la premisa no considera como probable que un cliente puede aprender y encontrar una mejor forma o solución a un problema. Lo que inicialmente era una excelente idea, el proceso de aprendizaje de un cliente puede llevarlo a que madure al cabo de semanas y tenga una mejor respuesta. De esta forma, no obtendrá lo que considerará como la opción más óptima y no estará feliz de recibir su producto.
«En las metodologías tradicionales el aprendizaje del cliente no es parte de la ecuación»
Realizar pocas evaluaciones parciales
Debido a que no se incluye como premisa que el cliente puede aprender, entonces raramente tiene sentido la evaluación parcial de los resultados, y si se muestra un producto no terminado, es solamente para verificar que se encuentre la funcionalidad completa y cobrar un monto prestablecido, pero no se toma como un ciclo de aprendizaje y retro-alimentación.
«Las evaluaciones parciales tienen como objetivo que el cliente cumpla su objetivo contractual de pago»
Considerar valor a las entregas que no son software
Las metodologías tradicionales consideran las entregas de, por ejemplo, un documento que explique como será la aplicación o como serán las pantallas y ello se considera como una entrega de valor. En realidad, la única medida de valor que existe es software funcionando, el resto no aporta valor alguno ya que no soluciona en ninguna medida el problema del cliente. Una trampa fácil de caer.
«El entregar un documento no soluciona el problema del cliente y por lo tanto no tiene valor»
Penalizar los cambios
Ya que se congelaron los requerimientos al comienzo, es difícil realizar modificaciones, sobre todo si el proceso de análisis se ha terminado. Debido a ello, se le penaliza a los clientes por cualquier cambio que soliciten, así sea uno que es obvio y que se dió como resultado del aprendizaje o maduración de un problema por parte del cliente. Este último punto evidentemente corroe la confianza a mediano y largo plazo, lo que hará que éste deba cerciorarse de las futuras intenciones de la empresa contratada mediante extensos contratos entre las partes, lo que se traduce en mayor tiempo y dinero. A su vez, se destruye el concepto de equipo hasta el punto de elaborar el modelo de «ellos vs. nosotros». Es común ver este tipo de acciones en licitaciones, donde las empresas ofertan el precio más bajo posible (a veces tan bajo como 1 euro) pero penalizan altamente por la adición de cambios. La trampa se basa en que los clientes querrán modificaciones y tendrá que pagar por ellos un alto precio o de lo contrario, se quedarán con la opción original. Ambos escenarios son desfavorables y destruyen evidentemente la confianza, terminándose con el producto no deseado.
«Los cambios son una penalización y en muchas ocasiones una trampa»
Medir lo que se considera correcto
Muchas empresas tienden a medir lo que se considera correcto a primera vista, como ser las horas que trabaja una persona en una semana, el porcentaje de utilización, lo que el empleado ha sido capaz de finalizar en determinados días o que tan ocupado éste estuvo durante un período de tiempo… en definitiva su «productividad» con el fin de realizar micro-gestión. En realidad, los informes deben aportar un valor tangible que apoye el trabajo en equipo y la claridad de los resultados. Los informes deben ser siempre una herramienta para mejorar el proceso de forma continua y nunca para penalizar personas. Veremos en el artículo de Ken Schwaber que se debería medir y su relación con el índide de Agilidad (puedes leer también mi artículo «10 reglas de oro para medir un proyecto Ágil«)
Es por ello que las metodologías tradicionales ofrecen una baja satisfaccion de los clientes, raramente brindan lo que ellos desean y hacen que los mismos paguen más por algo que a su criterio no es la solución adecuada. A su vez, ellas ofrecen estructuras pobres de colaboración, ya que este es otro aspecto fuera de su ecuación. Hay otra forma de trabajar con Scrum y Lean y está a tu alcance.
Veamos ahora el artículo de Ken Ken Schwaber sobre Valor en Ágil.
Gracias por escucharme,
Erich.
Valor en Ágil
(Ken Schwaber, Diciembre 11, 2013, Agile Retrospectives Blog on Scrum.org
Traduccion: Erich Bühler)
Cada año, las organizaciones gastan de entre un 4 a 10% de sus ingresos en sus departamentos de software (I.T.). Se espera obviamente un valor de retorno a cambio de dicho gasto.
En estos casos, el valor se define como el beneficio económico que una organización recibe por el gastos. Al medirlo, el valor puede provenir de toda la organización o estar limitado a una sola división o línea de producto. En todo caso, este siempre debe abarcar las zonas afectadas por este gasto.
Valor es entonces una medición que comprende en un momento determinado del tiempo:
| Los ingresos por empleado | Los ingresos (producido) brutos por empleado. |
| Satisfacción de los empleados | ¿Qué tan satisfechos están los empleados? Luego de haber invertido en ellos, los mismos pasan a ser un activo importante y una ventaja competitiva. |
| Satisfacción del cliente | ¿Los clientes están más o menos satisfechos que en el pasado? Encontrar un nuevo cliente es mucho más costoso que satisfacer a los clientes actuales. |
Una organización puede cambiar el VALOR mediante:
- Los productos y servicios que entrega y vende.
- Sus sistemas, tanto manuales como automáticos, a través de los cuales entrega sus productos y servicios.
Nos centramos en este último.
Philips Iluminación
Philips Iluminación es una división multimillonaria de la corporación Philips que completó recientemente un proyecto para «acelerar» la creación de VALOR. El proyecto abarcó todas las operaciones desde cuando un presupuesto era dado a un cliente hasta que la empresa recibía finalmente el dinero. El proyecto constaba entonces de dos componentes:
- Los procesos de negocio revisados, integrados en un nuevo flujo de operaciones creados a pertir de un mapeo de la cadena de valor (value stream mapping) y su exhaustiva eliminación de desperdicio.
- Nuevos sistemas de software, basados en productos de la fuerza de ventas, que apoyaban consecuentemente los nuevos procesos de negocio.
Cada componente requiere entonces del otro para su éxito. La mejora de las operaciones del área de software (I.T.) no tendrían ningún impacto en el VALOR de la organización si la empresa no los pudiese utilizar eficazmente.
Mediciones de valor
Hemos ideado una métrica que trata de captar los dos aspectos de la capacidad actual de una organización para crear y entregar valor; ellos se componen de:
- Mediciones operacionales (que miden la eficiencia de una organización). Estas métricas están fuertemente orientadas hacia la parte de software (I.T.), tanto el desarrollo de software como la implementación de la misma en la organización. Esto incluye: el flujo, tiempo de ciclo, estabilización, calidad, tasa de re-utilización y el tiempo ciclo de entrega. La eficiencia operativa del negocios no está incluida en estas medidas, pero se hará en 2014 como parte del programa internacional Kotter (John Kotter) Accelerate!.
- Mediciones de organización (miden el impacto de que la eficiencia de dicha inversión en el mercado y el valor que la organización acumula). Estas métricas son por ejemplo, los ingresos por empleado, satisfacción de clientes y empleados y la relación de coste del producto/sistema.
Los dos indicadores se combinan en una sola métrica: Índice de agilidad. El Índice de agilidad es un número que indica la agilidad relativa, de 1 a 100. Se orienta fuertemente hacia el valor de la organización. Es 
decir, una organización puede ser muy competente, pero si no se deriva un valor de mercado por su eficiencia, el Índice de agilidad entonces será bajo.
Se espera que esta medida aumente cuando la organización gasta dinero en software, proyectos y el mejoramiento del negocio.
Criterios tradicionales de medición de un proyecto
Un proyecto tradicional evalúa una necesidad y define un conjunto completo de requisitos para satisfacer la necesidad original. A partir de estos requisitos, se establece una fecha y un presupuesto de entrega. Una vez estos establecidos, los cambios se ajustan tanto como sea posible. Las metricas o indicadores se acumulan en contra de este tipo de proyectos; el Valor no entra como parte de la medición.
| Criterio | Éxito |
|---|---|
| Requisitos | Todos los requisitos establecidos al inicio del proyecto se han cumplido |
| Presupuesto | No se ha superado el presupuesto asignado al inicio del proyecto |
| Tiempo | No se ha superado la fecha de finalización del proyecto |
Criterios de medición de un proyecto Agile/Scrum
Los proyectos Agile/Scrum son diferentes a lo visto anteriormente. El objetivo se establece: este es el impacto deseado y su objetivo. Una fecha y su financiación pueden ser estimadas en base a experiencias pasadas o surgir por conocimiento a medida que el proyecto avanza. Todo el esfuerzo se dirige a lograr la mejor solución posible para el objetivo planteado. Esta iniciativa se considerará completa cuando se cree la solución, o se determine razonablemente un determinado momento que no se puede crear más.
En un proyecto ágil, cada Sprint o iteración es un proyecto completo. Tiene necesidades, presupuesto y fecha de entrega; al final se tiene un conjunto completo de funcionalidades de software. En base a lo finalizado en la última iteración, otro proyecto podrá o no ser iniciado, añadiendo más funcionalidad a las características que se acaban de completar; cada Sprint entonces se mide de forma independiente.
| Criterio | Éxito |
|---|---|
| Confianza de los inversores en el valor | Confianza de las partes interesadas, dueño del producto y desarrolladores de que la mejor solución posible fue creada para el objetivo o meta establecida en la iniciativa, con la inversión de dinero disponible. |
| Satisfacción de los inversores | Voluntad de las partes interesadas, dueño del producto, y los desarrolladores para llevar adelante este tipo de iniciativas nuevamente. |
| Confianza en la utilidad del software creado | Confianza de las personas que utilizan el sistema o producto que el mismo ofrece una forma mejor (que antes) de llevar adelante su trabajo. |
| Satisfacción de los clientes | Grado en que los usuarios buscan con interés la próxima solución para ayudar a hacer su trabajo mejor. |
Puedes encontrar el artículo original aquí.
Los dos indicadores se combinan en una sola métrica, Agilidad Index. El Índice de agilidad es un número que indica la agilidad relativa, de 1 a 100. Se inclina fuertemente hacia el valor de la organización. Es decir, una organización puede ser muy competente, pero si no se deriva de valor del mercado de la eficiencia, el Índice de agilidad es baja.
Como organización gasta fondos en TI, proyectos y el mejoramiento del negocio, cabe esperar que esta medida aumentaría.
