Un contrato ágil para Scrum

El ejemplo de cláusulas que se muestra a continuación permite formalizar, en una petición de ofertas a proveedores (RFP, Request For Proposals) o en un contrato, cómo deberá de ser la relación entre cliente y proveedor en la ejecución de un proyecto ágil utilizando Scrum.

Aunque el lugar natural de Scrum es el contrato de un equipo por meses (pago por iteración – 2 iteraciones de 2 semanas o mensual), en muchos casos el cliente prefiere o necesita que tanto el alcance como el coste como la fecha de entrega del proyecto se fijen de antemano (ver Triángulo de Hierro). En estas situaciones, para no perder los beneficios que aporta Scrum respecto a flexibilidad y adaptación y gestión del Retorno de Inversión (ROI), se pueden definir cláusulas específicas de Cambios de requisitos y de Finalización anticipada del contrato. Con esta última en especial tanto el cliente como el proveedor ganan en términos económicos: el cliente puede ahorrar dinero y el proveedor ve premiada su productividad.

En el siguiente ejemplo, como parte del proyecto también se deberá elaborar la lista de requisitos priorizada (Product Backlog).

Proceso de control y seguimiento del proyecto
Control y seguimiento del proyecto basado en objetivos
El proyecto se ejecutará en iteraciones incrementales con una demostración del producto al finalizar cada iteración. De esta manera se podrá conocer de forma objetiva el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos), con lo que <<el cliente>> podrá tomar decisiones informadas.
Los requisitos se desarrollarán priorizados por el valor aportado a <<el cliente>>, de modo que en las primeras iteraciones se obtendrán los objetivos más importantes del proyecto y se podrán realizar ajustes al respecto con la suficiente antelación.
El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. Por esta razón, cada requisito deberá ser:
  • Independiente del resto de requisitos, en la medida de lo posible.
  • Demostrable, de manera que sea claro cómo comprobar con <<el cliente>> que el requisito está completado y que se cumplen sus expectativas.
  • De un grado de esfuerzo para ser completado semejante al del resto de requisitos, de manera que <<el cliente>> pueda realizar una extrapolación del progreso del proyecto.

Iteración 0 – Elaboración de la lista de objetivos/requisitos y planificación

Duración: <<2 semanas .. 1 mes .. lo que se considere necesario para obtener una visión de alto nivel>>.
Objetivos:
  • Planificar y distribuir los objetivos y alcance del proyecto en iteraciones, de manera que los requisitos estén priorizados balanceando el beneficio que aportan a <<el cliente>>, su coste de desarrollo y los riesgos del proyecto. De esta manera, las primeras iteraciones del proyecto podrán acomodar los requisitos más importantes y mitigar los riesgos más altos.
Actividades
  • Identificación de los objetivos del proyecto y de los requisitos iniciales de alto nivel que permiten la consecución de estos objetivos. [2]
  • Priorización de los requisitos en iteraciones y entregas considerando los siguientes criterios:
    • El valor aportado por cada requisito para <<el cliente>>. Deberá ser explícito quien es el actor o usuario beneficiario de cada requisito y qué valor le aporta.
    • El esfuerzo necesario para desarrollar cada uno de los requisitos, de manera que en las primeras iteraciones se desarrollen los requisitos que proporcionen el máximo valor con el mínimo esfuerzo y que puedan encajar en la periodicidad de las iteraciones.
    • Las dependencias inevitables entre requisitos.
    • Minimizar los riesgos del proyecto respecto a desarrollo de los requisitos, disponibilidad y grado de implicación de los actores y beneficiarios implicados, interacción con otros equipos (proyectos en paralelo, compras de material e infraestructura, encargados de entregar el proyecto a los usuarios finales), etc.
    • Maximizar la cohesión del contenido de cada iteración, identificando los puntos de acoplamiento y las dependencias entre los diferentes incrementos de manera que sean mínimos, para poder dar por realmente completados los requisitos desarrollados en cada una de las iteraciones.
  • Calcular la duració de cada uno de los incrementos desarrollados de manera que puedan encajar en la periodicidad de las iteraciones (que deberán ser de la misma duración de <<2 semanas ..1 mes>>.

Entregables

 
Iteraciones de desarrollo
Duración: Todas las iteraciones de desarrollo serán <<mensuales>>.
Objetivos:
  • Completar un incremento de producto que sea demostrable a <<el cliente>> al finalizar la iteración, de manera que pueda tomar decisiones informadas y objetivas sobre el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos).
Actividades

En el inicio de cada iteración:

  • <<El cliente>> y <<el proveedor>> mantendrán una reunión para consensuar los objetivos y contenido de la iteración, en función de los criterios de priorización indicados anteriormente, así como para dar detalle a los requisitos seleccionados en la medida en que cada una de las dos partes necesiten. De manera general, cada requisito deberá tener asociado un conjunto de condiciones de aceptación para poder considerar que el requisito ha sido completado. [3]

Al finalizar cada iteración:

  • <<El proveedor>> deberá hacer a <<el cliente>> una demostración de los requisitos completados. En esta demostración participaran los interesados que <<el cliente>> designe; entre ellos se podrá encontrar, por ejemplo, a los promotores del proyecto, al responsable funcional, al responsable técnico, a usuarios finales seleccionados, etc. <<El cliente>> hará una aceptación de estos requisitos realizando las comprobaciones de calidad oportunas.
  • <<El cliente>> podrá repriorizar el conjunto de requisitos del proyecto y consensuará con <<el proveedor>> el contenido de las siguientes iteraciones según lo estipulado en la clausula de «Cambio de requisitos» << dado que además de ser fijos el alcance y el tiempo del proyecto también es fijo el su coste para el cliente (y por tanto lo que va a cobrar el proveedor)>>. En particular, los elementos que se repriorizarán serán: requisitos inicialmente identificados del proyecto, modificaciones a estos requisitos, nuevos requisitos que aparezcan durante el proyecto, problemas de calidad detectados, etc.
Entregables
  • El producto desarrollado hasta ese momento, incluyendo todos los entregables asociados completados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. [4]

Cambios de objetivos/requisitos

Para que esta cláusula sea efectiva, <<el cliente>> se compromete a colaborar con <<el proveedor>> en todas las iteraciones y, especialmente, en las reuniones de recogida de requisitos (como, por ejemplo, las reuniones de planificación de iteración) y en las reuniones de demostración.

  • Los cambios en prioridades de la lista de requisitos no implicarán ningún coste adicional a <<el cliente>> siempre que se mantenga el cómputo total de horas del contrato.
  • La adición de nuevos requisitos (tras las demostraciones) no implicará ningún coste adicional a <<el cliente>>, siempre que se retiren del contrato requisitos no iniciados que computen las mismas horas. 
  • No se consideran cambios las subsanaciones por parte de <<el proveedor>> de los defectos de calidad del producto.

 

Finalización anticipada del contrato

  • Con el objetivo de mantener un Retorno de Inversión (ROI) aceptable en cada iteración, <<el cliente>> podrá finalizar el contrato en cualquier momento siempre que abone a <<el proveedor>> un 20% de las horas de proyecto pendientes de realizar. [5]
  • Los requisitos que previamente fueron acordados por las dos partes para ser entregados con anterioridad al momento de la finalización del contrato y que estén sufriendo un retraso de entrega atribuible a <<el proveedor>> quedan excluídos del cómputo de horas pendiente a realizar y deberán ser entregados por <<el proveedor>> sin incurrir en ningún pago adicional por parte de <<el cliente>>.
  • Sea como fuere, <<el proveedor>> se compromete a entregar un 80% de los requisitos del proyecto en la fecha inicial de entrega, cumpliendo los criterios definidos en las condiciones de aceptación para poder considerar que los requisitos han sido completados, siempre que no se produzca alguna desviación por causas que estén fuera de la responsabilidad de <<el proveedor>>. 

contrato-agil-money-for-nothing

[1] En el caso de proyectos de desarrollo de software: análisis funcional, diseño técnico, código, pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.).

[2] En el caso de proyectos de desarrollo de software, para ayudar y guiara conseguir este objetivo, en la iteración 0 ser interesante realizar una primera versión de muy alto nivel de los siguientes modelos:
  • Modelo de actores, procesos y flujo de información.
  • Modelo de Casos de Uso (funcionalidades).
  • Modelo de Dominio (entidades de información y sus relaciones).
  • Modelo de interfase de usuario (GUI), línea de diseño gráfico, hojas de estilo, guía de usabilidad y diseño de interacción, etc.
  • Modelo de arquitectura y de componentes (solución tecnológica), identificando componentes de uso común y reutilizables.
  • Modelo de seguridad (autenticación y autorización para acceder a las funcionalidades).
  • Modelo de gestión de cambios de la configuración.
  • Modelo de control de la calidad.
  • Modelo de gestión del cambio (comunicaciones a beneficiarios, formaciones y soporte).
Esto NO implica realizar un análisis funcional y/o un diseño técnico del proyecto en la iteración 0. Si en el proyecto es necesario realizar un análisis funcional o un diseño técnico, también se elaborará de manera incremental, iteración a iteración: «se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo.
También puede ser conveniente realizar las siguientes actividades:
  • Identificar el grado de configuración y parametrización del producto para cubrir las necesidades de <<el cliente>>, así como los mecanismos para conseguirlo.
  • Definir los patrones de diseño, estándares de codificación, guías de uso de los componentes de infraestructura tecnológica a utilizar o cualquier herramienta a utilizar en el desarrollo.
  • Para reducir el riesgo tecnológico lo antes posible, realizar una prueba de concepto de arquitectura, componentes tecnológicos más arriesgados, infraestructura, GUI, etc. en la iteración 0 o en la primera iteración de desarrollo.
[3] En el caso de proyectos de desarrollo de software, para ayudar a reducir la incertidumbre de la iteración, minimizar la dependiencia de <<el cliente>> durante ella y garantizar la usabilidad de la solución, puede ser necesario aprobar previamente a cada iteración el prototipo navegable de la interfase de usuario (GUI) que se desarrollará en esa iteración y acompañarlo de una descripción de comportamiento, redactada como pruebas de aceptación asociadas a cada requisito. Es de especial importancia que este prototipo lo validen tanto el responsable funcional del proyecto en representación de los promotores del proyecto como una muestra representativa de los usuarios finales (con los objetivos de obtener su feedback y de garantizar su productividad de trabajo con la herramienta).
[4] En el caso de proyectos de desarrollo de software, <<el proveedor>> deberá entregar el código fuente, scripts de instalación y la batería automatizada de pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.), de manera que sea sencillo auditarlas y repetirlas, tanto por <<el cliente>> como por el proveedor que se encargará del mantenimiento evolutivo y correctivo del sistema.
[5] En lugar de perder el 100% del coste de las horas pendientes en requisitos que no le aportan suficiente valor, a <<el cliente>> le resulta más conveniente abonar un 20% de las horas a <<el proveedor>> para así ahorrarse un 80%. Cuanto mejor se haga Scrum, más salen ganando ambas partes: el cliente, por no dedicar más dinero del necesario al proyecto, y el proveedor, por recibir un pago final (y aumentar su margen) sin dedicar ningún recurso.
Para más información:

Por qué son buenas las demostraciones en Scrum

Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde el equipo va desarrollando los requisitos seleccionados al comienzo de cada una de esas iteraciones (en la reunión de planificación del Sprint). El cliente puede tener entregas del proyecto que incluyan los resultados de varios Sprints y, una vez finalizados, todos los ellos hemos terminado el proyecto.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminada una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.
 

Una de las cosas más curiosas de la demostración de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. Una semana completa antes del final la gente pasa a centrarse en sacar la demostración adelante, y durante este tiempo se descubren muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar el desarrollo durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que tras la demostración habrá que arreglar correctamente. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demostración:
 
  • Se realiza un esfuerzo por integrar los requisitos desarrollados durante las últimas semanas para obtener un resultado compacto y demostrable al cliente final, lo cual revela numerosos problemas imprevistos y de calidad. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras iteraciones de desarrollo (Sprints), mientras que en un proyecto tradicional en cascada estos errores se detectarían al final y serían mucho más complejos de resolver.
Una persona tiende a responsabilizarse sólo de la parte de trabajo que realiza, es más difícil sentir la propiedad del resultado de un requisito cuando el equipo es multidisciplinar y se necesitan varios especialistas para completar este requisito. A menudo diferentes equipos trabajan en diferentes aspectos/componentes del producto o ámbitos del proyecto, funcionando como islas independientes unos equipos respecto de los otros. Descuidar la interacción entre estos distintos aspectos o componentes puede traer problemas a largo plazo. Por ello las demostraciones ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.
 
  • Irremediablemente se crearán soluciones temporales o, hablando más claro, parches. Estos parches estarán ahí en la demostración, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.
  • Las demostraciones obligan al pragmatismo y a la creación de un producto susceptible de ser entregado al cliente con el mínimo esfuerzo necesario. Otro aspecto que yo considero importante de las demostraciones es que los miembros del equipo no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El miembro del equipo se debe centrar en desarrollar un requisito de manera pragmática y siempre pensando en tener algo que entregar, algo que se pueda demostrar. 
Esto abre otro debate sobre como poner en un Sprint requisitos no tan fácilmente demostrables como puedan ser cambios internos del producto que no aportan valor directo al cliente o usuario, pero que facilitan añadir nuevos requisitos o cambiarlos, hacen el producto más adaptable o, simplemente, permiten mejoran su calidad. Pero eso ya es un tema diferente. 
 
  • Involucración por parte de los miembros del equipo. Personalmente creo que la demostración no debe ser realizada por única persona, sino que aquí el Facilitador (Scrum Master) debe actuar como simple maestro de ceremonias. Hacer que los miembros del equipo participen en la demostración les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.
  • El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demostración para toda la compañía. Vosotros ya sabéis como es el trabajo en una compañía medianamente grande. A menudo la mayoría de departamentos o equipos trabajan de manera independiente, y prácticamente el único contacto que tienen con el proyecto es para conocer los problemas que unos tienen con el trabajo de los otros. "¿Oye, cómo teníamos que integrar vuestra parte de producto con la nuestra?", "¡Este requisito no se ha hecho como esperábamos, estamos perdidos.", "Hay que hacer cambios corriendo, ahora mismo os hacemos una petición formal de cambios", etc.
Me atrevería a decir que es común que la sensación de las personas ajenas a un equipo, poco antes de terminar cada iteración es más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido es que ha habido problemas. Sin embargo, el hacer una demostración con los objetivos cumplidos que fueron marcados al inicio de Sprint, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo del Sprint. 
 
  • Visibilidad para el cliente. Teóricamente las demostraciones deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demostraciones internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demostración el cliente puede comprobar que se está progresando, lo cual en el mundo de los proyectos no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.
Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demostración, al menos en nuestro caso.

 

Una retrospectiva ágil de Scrum

A continuación se explica cómo hacer una retrospectiva para la solución de problemas de un proyecto e identificar qué cosas están funcionando bien.

La siguiente reunión de retrospectiva dura 1,5 horas. Los tiempos de cada actividad son aproximados.

 

Material necesario

 

Resultado de imagen de retrospectiva

Actividades

Puesta en escena (5′)

El facilitador explica el objetivo de la retrospectiva y enumera los diferentes pasos y tiempos que va a tener la reunión.

 

Qué ha funcionado bien (15′)

Una retrospectiva no sólo debe fijarse en la solución de problemas (podría quedar una sensación demasiado negativa de que las cosas no van bien), si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más.

Para «forzar» a que todo el equipo piense en las cosas positivas que sucedieron, el proceso se puede iniciar de la siguiente manera: cada miembro del equipo tiene que escribir en silencio un mínimo de 2-3 post-its con lo que funcionó bien. A partir de ahí, se van poniendo de pie, explicando su post-it, pegándolo y agrupándolos por tema.

 

Identificación de problemas (20′)

  • El facilitador hace un resumen de los hechos, objetivos conseguidos (o no) y decisiones más relevantes del período o proyecto a analizar con la finalidad de mejorar en el siguiente. Se apoya en datos objetivos utilizando para ello, por ejemplo, la lista de requisitos priorizada, la lista de tareas de la iteración, las actividades realizadas, los gráficos de progreso del proyecto o de la iteración, las métricas del proyecto, etc.
  • Los miembros del equipo proponen aspectos a mejorar adicionales, anotando los problemas en post-its que se pegan en una pared o una pizarra blanca de manera que todo el equipo pueda leerlas. Como base para identificar problemas se puede utilizar una línea de tiempo del proyecto (cronograma de lo que sucedió).
  • El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo, escribiéndolo como cabecera de grupo en la pizarra (o bien utilizando para ello un post-it.
  • El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto o la productividad del equipo. Para ello cada persona dispone de hasta 5 puntos en forma de post-its a repartir libremente entre los diferentes grupos.

 

Descubrimiento de causas (20′)

  • Para los grupos de problemas más votados, el equipo analiza por qué se están produciendo. Para ello utiliza, por ejemplo, un diagrama de espina de pez o Ishikawa, con el problema como espina dorsal y las causas como espinas que crecen a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.
  • Notar que en ningún momento se trata de buscar culpables, si no de ver qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas.

 

Plan de acción (15′)

  • El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede utilizar una lluvia de ideas. Su selección final puede estar basada en una votación o en criterios como coste, esfuerzo o tiempo de realización, satisfacción del cliente, sostenibilidad de la solución, etc.
  • Se generan las tareas necesarias y en ese momento las personas ya se autosignan la responsabilidad de ejecutar, o bien las tareas se introducen en un Improvement Backlog o la lista de tareas de la siguiente iteración (Sprint Backlog).

 

Conclusiones de la reunión (15′)

  • Se revisan las principales conclusiones y decisiones.
  • Se revisa si se ha conseguido el objetivo de la reunión.
  • Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor (¡ la retrospectiva de la retrospectiva !).

 

Artículos relacionados

Para conocer otras técnicas que se pueden aplicar en retrospectivas, así como consejos para la facilitación de éstas:
  • Agile Retrospectives: Making Good Teams Great – Esther Derby
  • Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka.

 

El jardín (un ejemplo de Scrum fabulado)

La nueva propietaria de la casa de campo se dio un paseo por los jardines. Algunas partes estaban en muy mal estado. Llamó a su capataz y le dijo lo preocupada que estaba: se había comprometido con su circulo de negocios a dar una recepción en un mes, y tenía serias dudas de si eso sería posible.

Esa misma mañana, el capataz hizo unas cuantas llamadas a otros colegas suyos. Le confirmaron que, aunque contratase a la mejor empresa de jardinería de la provincia, tenerlo todo listo le llevaría como mínimo dos meses. Tan sólo la elaboración del plano del nuevo jardín, con el detalle de las diferentes zonas, tipos de plantas y ornamentos, le llevaría casi tres semanas, contando con que la propietaria pudiese dedicar suficiente tiempo a la revisión y aprobación del estudio.
 
El capataz se dirigía al despacho de la propietaria cuando el teléfono sonó. Uno de sus colegas había recordado que un amigo suyo había pasado por un problema similar y que se lo había resuelto una nueva empresa de jardinería que trabajaba de una manera bastante diferente a las demás. El capataz se hizo con el teléfono y los llamó.
 
El planteamiento que esa empresa le ofrecía era el siguiente: vendría un equipo de 7 personas, cada una especializada en áreas concretas de creación de jardines. Se entrevistarían con la propietaria durante una mañana entera para entender qué era lo que necesitaba y conocer mejor cómo era el jardín. Como resultado, redactarían una lista con las cosas que la señora necesitaba. En este punto, sería muy importante lo siguiente:
  • Explicarían a la propietaria cuantos días de trabajo serían necesarios para hacer cada elemento del jardín. Con esta información, y conociendo el servicio que cada uno de estos elementos ofrecería, la señora debería elegir en qué orden se debería arreglar el jardín, concentrándose sobre todo en tener el máximo de cosas importantes en la fecha de la recepción.
  • Cada 15 días el equipo enseñaría a la propietaria los elementos del jardín que habría podido completar. Viendo el progreso real del trabajo, la señora no se llevaría a engaños. Además podría realizar ajustes de lo que le enseñasen (de hecho, ella todavía no se veía capaz de imaginar cómo quedaría todo el jardín) y, lo que era mejor, podría cambiar sus ideas sobre las siguientes zonas, tipos de plantas y ornamentos, dado que todavía no se habría empezado a trabajar en ellos. Únicamente necesitarían una mañana para enseñarle el estado del jardín y entender (tanto ella como el equipo) cuáles deberían ser los objetivos de la siguiente quincena. Durante este tiempo también sería necesario poder contactar con ella para preguntas puntuales.
  • Por otro lado, el equipo no conocía bien los problemas con que podría encontrarse en una vez en el jardín: canalizaciones de agua en peor estado del que esperaban, aptitud de las tierras y orientación respecto a los nuevos tipos de plantas deseados, búsqueda de herramientas específicas en las que todavía no podían pensar, etc. Por esto, al principio de cada quincena sería el propio equipo quien decidiría cuántas cosas se vería capaz de completar. Durante este tiempo, y para poder respetar el compromiso adquirido, sería muy importante que la propietaria no realizase cambios sobre lo que se acordó hacer. Es decir, antes de cada quincena la señora debería tener claro qué sería lo más importante para ella. El propio equipo la ayudaría, si fuese necesario.
El capataz pensó que estas reglas eran bastante razonables y que, con esa manera de trabajar, su jefa podría tener el mejor jardín posible para la recepción que tenía que dar en un mes, con lo que contrató a la empresa.
 
El equipo se reunió con la señora durante toda una mañana. A partir de las necesidades de la propietaria se elaboró una lista de 50 puntos con los elementos de jardín y tareas que las cubrían. Para estimar rápidamente cuantos días de trabajo serían necesarios para completar cada punto, su jefe los iba leyendo en voz alta y ellos indicaban con las manos el número de días de trabajo. Si había una diferencia importante entre lo que decían dos personas, cada uno de ellos explicaba en qué se había basado su estimación. Finalmente, se vio que para arreglar todo el jardín serían necesarios dos meses y medio aproximadamente.
 
La señora escogió qué puntos necesitaba que estuviesen listos en la fecha de la recepción, es decir, en un mes. Debían incluir arreglar las partes más importantes de los jardines de la entrada principal, el acceso hasta la casa y la parte de detrás de la casa. En los laterales apenas se haría nada: allí donde tuviese que pasar un número alto de invitados se haría un arreglo rápido para dar un aspecto más regular, siempre que ese arreglo fuese el máximo de compatible con el trabajo a realizar en esa zona en la siguiente quincena .
 
El equipo preguntó y acordó con la señora los detalles necesarios para empezar el trabajo de los primeros quince días (los jardines de la entrada principal y la parte de detrás de la casa, donde se haría el convite, cosas que representaban los primeros 10 puntos de la lista). El equipo después realizó un plan de trabajo: detalló la lista de tareas necesarias para poder completar cada uno de los elementos que habían escogido con la propietaria, se repartieron las tareas y se pusieron a trabajar.
 
Cada día por la mañana, nada más llegar, el equipo se juntaba 10 minutos. De pie, se explicaban en qué cosas habían estado trabajando el día anterior, en qué iban a trabajar ese día y qué problemas tenían. Tras esa mini reunión, algunos seguían pensando sobre cómo resolver alguna situación concreta, mientras que su jefe llamaba por teléfono a su empresa, proveedores de maquinaria o herramientas, o iba directamente a hablar con el capataz para conseguir algo que su equipo necesitaba.
 
El equipo decidió rehacer las canalizaciones de sólo esas primeras zonas y de la bomba de riego que conectaba directamente con ellas. No rehizo las canalizaciones circundantes, sino que hizo lo mínimo necesario para que siguiesen funcionando y que no fuese difícil poner las nuevas cuando la señora decidiese la quincena en qué trabajar en esas zonas no prioritarias.
 
Tras los primeros 15 días, recorrieron el jardín con la señora enseñándole lo que habían completado. Sólo había quedado por terminar 1 punto de los 10 primeros acordados. La señora pensó que en la siguiente quincena (en la que el jardín debería estar listo para la recepción) era más importante no hacer el punto pendiente y escoger bien los siguientes. El equipo consensuó con ella hacer sólo 9 puntos de la lista y así asegurar más la calidad de cara a la recepción. Después de hablar con la propietaria, los miembros del equipo dedicaron un par de horas a analizar cómo habían estado trabajando esa quincena, qué problemas eran los más importantes que se estaban encontrando de manera repetitiva (y que habría que resolver en la siguiente quincena) y qué nuevas técnicas o alternativas querían probar.
 
En el día previo a la recepción apenas hubo que hacer unos retoques finales del trabajo realizado en la segunda quincena.
 
La recepción fue todo un éxito. Los invitados felicitaron repetidas veces a la propietaria por los hermosos y acogedores jardines de su casa, cosa que la hizo sentir especialmente bien.
 
Cada quincena el equipo repitió el mismo proceso: daban una vuelta por el jardín con la señora, le enseñaban cómo habían resuelto cada punto de la lista, consensuaban cuales serían las cosas más importantes a hacer en la siguiente quincena y preguntaban el detalle necesario. Cada vez el equipo conocía mejor el jardín, con lo que su velocidad de trabajo (y el número de elementos que completaba) era mayor.
 
Llegó la última quincena de trabajo. Los puntos que quedaban en la lista apenas tenían importancia. La propietaria pensó que no valía la pena perder tiempo y dinero en detalles que apenas nadie tendría en cuenta. Por el contrario, le convenía más hacer un gran cambio en una zona del jardín en la que ya se había trabajado: necesitaba darle un aspecto un poco más oriental, ya que tras la recepción había empezado a hacer negocios con personas de China y Corea, y sería muy distendido tener conversaciones con ellas en aquella parte del jardín.
 
La propietaria había entendido que la flexibilidad para hacer cambios y el hecho de tener un jardín siempre preparado para nuevas recepciones era lo que más se adaptaba a sus necesidades, con lo que convocó al equipo para contratar y planificar los siguientes meses de trabajo.
 
 

Otras fábulas y ejemplos

 

 

Recursos externos sobre Agile y Scrum

Los siguientes recursos están más enfocados a la industria tecnológica y de desarrollo de software, aunque se pueden extraer principios, prácticas y técnicas aplicables a otros tipos de negocio:

Sitios web

Cursos

Agile en educación Primaria y Secundaria

Libros

En español:
En inglés:
  • The Agile Samurai: How Agile Masters Deliver Great Software –  Jonathan Rasmusson
  • Succeeding with Agile: Software Development Using Scrum – Mike Cohn.
  • Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka. Cómo ser un buen Facilitador y cómo guiar actividades de colaboración y trabajo en equipo (como las de Scrum).
  • Agile Estimating and Planning – Mike Cohn.
  • User Stories Applied: For Agile Software Development – Mike Cohn. Técnicas para la creación de la lista de requisitos priorizada (Product Backlog).
  • Agile Retrospectives: Making Good Teams Great – Esther Derby.
  • The Art of Agile Development – James Shore, Shane Warden.
  • Agile Software Development with Scrum – Ken Schwaber.
  • Agile Project Management with Scrum – Ken Schwaber. Experiencias de solución de problemas aplicando Scrum.
  • Agile Adoption Patterns: A Roadmap to Organizational Success – Amr Elssamadisy. Técnicas y estrategias de implantación en función de los principales problemas de negocio a resolver.
  • The Enterprise and Scrum – Ken Schwaber. Cómo escalar y implantar Scrum a nivel organizativo.

Adicionalmente a los libros anteriores, la biblioteca de agile-spain contiene referencias a libros de relacionados con el desarrollo ágil de software: ingeniería, eXtreme Programming, Lean Software Development, etc.