Inception Workshop: cómo abordar un proyecto ágil

Esta semana he facilitado un inception workshop para arrancar el que va a ser el primer proyecto ágil de uno de nuestros clientes. El proyecto consiste en un desarrollo a medida utilizando Microsoft Dynamics CRM y SharePoint para una herramienta de backoffice. Actualmente ya disponen de una versión en Microsoft Access, y la intención es crear una nueva versión basada en web e integrada con sus sistemas de información actuales.

Ya se había autorizado el proyecto con un enfoque más tradicional (análisis previo, oferta, análisis detallado, diseño, desarrollo, etc.), se había firmado una oferta con un proveedor y tenían ya un documento de requisitos bastante avanzado. Decidimos probar un enfoque ágil para el proyecto a partir de este punto. Así que el siguiente paso fue convocar un workshop eficiente para acordar con más detalle cómo iban a colaborar (sprints, roles, etc.) y crear una primera versión del backlog transformando el documento de requisitos en historias de usuario.

Me gusta poner nombre a las sesiones, así que en honor al gran programa de TV3 llamé al workshop “QUÈ QUI COM” y planifiqué las actividades de crear una visión, identificar roles, definir necesidades, beneficios, definir el producto, definir el modelo de relación y crear el product backlog inicial.

Al empezar la sesión pregunté “¿Qué vamos a hacer hoy?” y la respuesta unánime fue “Definir historias de usuario”.  Mmmm… Directamente al product backlog… Creí en ese momento que los pasos previos iban a ser vistos como una pérdida de tiempo, ya que se disponía de un documento de requisitos trabajado durante bastante tiempo que estuvo aparcado hasta disponer de recursos suficientes para arrancar. El alcance estaba claro y acotado. Igualmente, con algunas dudas, seguí con el plan de la sesión.

Inception workshop parte 1: Visión y roles

Definimos la visión con el modelo clásico de Geoffrey Moore en Crossing the Chasm, y que también propone SAFe como definición de una Epic:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

Por cierto, siempre que utilizo esta técnica acaba costando un poco diferenciar entre la necesidad y el beneficio sin tener la sensación de repetir.

Trabajando la Visión nos dimos cuenta de las expectativas diferentes de algunos de los participantes. Llegamos a un acuerdo y se llegó a la conclusión que era igual de importante la nueva herramienta de backoffice como los procesos de gestión asociados a su uso. Punto importante.
Después definimos los roles con un modelo colaborativo, y nos salieron 19 (!!!) roles diferentes. A pesar que teníamos claro que inicialmente serían menos, y que después se fusionarían algunos, en este punto empezamos a ver que el proyecto podría convertirse en algo más de lo que se preveía. Hubo debate, se nos echó el tiempo encima, y pasamos al meollo de la cuestión: el product backlog.

Inception workshop parte 2: Product backlog

Expliqué el modelo de Jeff Patton para hacer un User Story Map, y empezamos a modelar el skeleton con el principal flujo de trabajo. En este punto intentamos crear un MVP, ya que el workflow era bastante complejo, con diferentes estados, reglas de negocio y triggers.
El punto clave fue cuando entramos en detalle del skeleton, vimos que “todo es un must”, y que iba a costar reducir. “Tenemos que poner la misma funcionalidad que está ahora en el Access, no podemos arrancar con menos, sería ir hacia atrás”.
Y apareció el diálogo más revelador de toda la sesión:

– Pero si ahora todo se puede hacer con el Access, ¿por qué hacéis una versión nueva?

– Para que se integre con nuestros sistemas, tenga acceso web y añadimos algunas mejoras.

– ¿Solo por eso vale la pena todo el esfuerzo?

– Bueno, es que ahora el Access no se utiliza del todo, falta información.

– ¿No se utiliza del todo?

– No hay información fiable 100%. Los usuarios no informan todos los campos necesarios, así que no sabemos si el contenido es vigente.

– ¿Y por qué los usuarios no lo informan?

– Bueno, el día a día…, ya sabes…, se trata de un paso más, y si se lo pueden ahorrar pues mejor.

– Pero la información es relevante. Si estuviera centralizada ahorraríamos mucho tiempo de gestión.

– Sí, es cierto. Pero no se utiliza.

A partir de ese momento, cambió el enfoque. No se trataba de disgregar la funcionalidad en historias de usuario. Se trataba de ver qué fallaba en la versión actual, averiguar los motivos, buscar una alternativa, y hacer foco en no cometer los mismos errores. Algo que ya se podía deducir en el “Unlike” de la visión, pero que se nos pasó por alto.

Quitamos todas las reglas de negocio (poder hacer cualquier cambio de estado sin seguir un workflow, no tipificar entidades…, TODAS). Nos centramos en definir los beneficios, y hacer una nueva versión haciendo foco en:

• la colaboración de los usuarios durante el workflow
• el aseguramiento de información actualizada
• la centralización y versionado de documentos
• la centralización de las conversaciones asociadas

Resultados

El objetivo era evitar que la herramienta se convirtiera en una burocracia más, en que no hubiera información fiable, en que no sirviera de nada porque el contenido está obsoleto, en que “mejor miro el último correo que me enviaron sobre este tema…”, en resumen, en evitar los motivos que hacían inservible la versión actual.

Queríamos que los usuarios amaran la herramienta, que fuera lo primero que consultaran por la mañana para ver en qué punto estaba su trabajo, sus siguientes pasos.

Reducimos los roles a 3, el mínimo imprescindible para poder colaborar en todo el proceso de inicio a fin.

El alcance al finalizar la sesión no se parecía en nada al que había en el documento de requisitos al empezar. Nadie había pensado en hacer foco en el aspecto colaborativo y en cómo asegurar que se utilizaría. El contrato con el proveedor era poco más que papel mojado, pero todos nos dimos cuenta que construir lo que estaba escrito habría sido hacer un producto inservible. Un “Access v2”.

A día de hoy no sabemos cómo acabará este proyecto. Pero sí que sabemos cómo habría acabado de no haber realizado esta sesión inicial. En un cajón, junto con la versión actual.