Cómo elegir un método de trabajo para tu situación

01 / CONTEXTO

El método no puede responder una pregunta que aún no has formulado

Cuando un proyecto se atasca, es tentador buscar un método nuevo. A veces elegimos un sprint porque suena rápido, un tablero porque hace visible el trabajo o una reunión porque permite sentir que hemos empezado. Pero ninguna de esas formas de trabajo aclara qué necesitamos aprender. Si la pregunta es si un cliente reconoce un problema, construir durante cinco días puede producir una respuesta muy elaborada a la pregunta equivocada.

Yo empezaría por escribir la decisión que se acerca. Puede ser «¿debemos cambiar esta propuesta?», «¿podemos entregar este servicio con la capacidad actual?» o «¿qué parte del proceso no entendemos todavía?». El método debe ayudarnos a conseguir la evidencia necesaria para esa decisión. Su nombre importa menos que la relación entre pregunta, acción y señal.

Esta forma de pensar también me ayuda a leer una tensión que aparece en mis apuntes de LEINN. Luis recomendó usar un Design Sprint para cocrear un PMV con Xcrier; al día siguiente, Javi de Miguel expresó su rechazo a las metodologías ágiles sin desarrollar el motivo. Recibir recomendaciones opuestas me obliga a volver al problema: qué necesitábamos aprender y con qué medios contábamos.

Conoce más sobre LEINN →︎

02 / MECANISMO

Escoger según incertidumbre, complejidad y reversibilidad

Yo compararía un método mediante cinco preguntas:

1. ¿Qué no sabemos? Si la incertidumbre está en el problema o en el usuario, conviene observar y conversar antes de optimizar una solución.
2. ¿Qué cambia mientras trabajamos? Un problema estable permite más planificación; uno que incorpora respuestas humanas o dependencias cambiantes necesita ciclos cortos de revisión.
3. ¿Qué coste tiene equivocarse? Una prueba pequeña y reversible permite aprender sin comprometer toda la operación.
4. ¿Qué capacidad tenemos? Un método que exige un decisor, cinco personas disponibles o una semana protegida no encaja si esas condiciones no existen.
5. ¿Qué señal cambiará la siguiente decisión? Sin una señal, el método se convierte en una secuencia que se cumple por inercia.

El Double Diamond del Design Council organiza el trabajo en descubrir, definir, desarrollar y entregar, y permite volver a fases anteriores cuando la evidencia lo exige [1]. Scrum, por su parte, se presenta como un marco para generar valor mediante soluciones adaptativas a problemas complejos, con transparencia, inspección y adaptación [2]. Puedo tomar ideas de ambos, pero adoptar Scrum exige respetar su estructura; seleccionar algunas prácticas no equivale a aplicar el marco completo.

También importa distinguir un procedimiento de una exploración. Un procedimiento busca repetir una operación conocida con criterios claros. Una exploración acepta que todavía no sabemos qué funciona y necesita una prueba que pueda cambiar de forma. Llamar «ágil» a cualquiera de las dos no resuelve la diferencia.

Cuando intenté adaptar un sprint a LUXXO, nuestro equipo en LEINN, descubrí que varios proyectos todavía no podían explicar con claridad qué necesidad querían resolver. Preparé primero preguntas para ordenar el modelo de negocio y después una secuencia para prototipar y probar. La adaptación reactivó algunos proyectos, pero no sostuvo por sí sola el trabajo del equipo. De ahí me llevo dos comprobaciones: tener una pregunta concreta que probar y contar con personas que puedan dedicarle tiempo. Un sprint puede servir para contrastar una hipótesis; no hace falta darla por validada de antemano.

03 / COMPARACIÓN

Tres métodos para tres preguntas distintas

La tabla no es un catálogo para escoger sin pensar. Obliga a que la pregunta aparezca antes del método. Si una misma situación contiene preguntas distintas, podemos combinar formas de trabajo: conversar para entender el problema, hacer una prueba corta para comparar alternativas y documentar después lo que ya sabemos repetir.

04 / EJEMPLO

Una decisión de cinco días y otra que necesita más escucha

Ejemplo hipotético: un equipo recibe peticiones para mejorar el alta de clientes. Una persona propone un sprint de cinco días. Antes de aceptarlo, el equipo formula dos preguntas diferentes. La primera es si los nuevos clientes abandonan porque no entienden un paso concreto. La segunda es cómo debe operar el alta cuando hay excepciones de facturación.

Para la primera pregunta, el equipo habla con personas que abandonaron, observa el recorrido y prueba dos mensajes con una muestra pequeña. Define que seguirá si encuentra el mismo obstáculo en varias conversaciones y si una versión del mensaje ayuda a completar el paso. Para la segunda, entrevista a quien gestiona los casos excepcionales, mapea entradas y decisiones y redacta un procedimiento provisional. Un sprint de diseño puede ayudar a elegir una alternativa de interfaz; no sustituye el conocimiento del proceso de cobro.

Al terminar la semana, el equipo descubre que el texto no era el principal problema: faltaba información que el cliente debía recibir de otra persona. El método no ha fracasado. Ha hecho visible que la siguiente prueba debía cambiar de lugar. Esa es la señal que buscaba.

05 / APLICACIÓN

Explicar por qué eliges una forma de trabajar

Para elegir un método en mi proyecto escribiría una frase con seis partes: «Queremos decidir ___; todavía no sabemos ___; trabajaremos durante ___; tenemos estas restricciones ___; probaremos ___; cambiaremos de decisión si observamos ___». Si la frase no cabe porque intentamos resolver todo a la vez, la primera tarea puede ser acotar la pregunta.

Después compararía dos métodos posibles, incluyendo el coste de cada uno. ¿Qué personas deben estar disponibles? ¿Qué se deja de hacer? ¿Qué información produce? ¿Qué riesgo queda sin cubrir? Esta comparación evita que una herramienta se convierta en una identidad del equipo o en una forma de aplazar una decisión.

En la revisión preguntaría si el método permitió aprender lo que necesitábamos. Si no, distinguiría entre una mala ejecución y una forma de trabajo inadecuada para la situación. La bitácora sobre planificar con dependencias desarrolla el reajuste de una entrega; la de generar opciones explica cómo abrir posibilidades antes de elegir una prueba.

06 / LÍMITES

Ningún marco elimina la incertidumbre

Una semana de trabajo concentrado exige que las personas necesarias estén disponibles y que podamos contactar con usuarios. Si no se cumplen esas condiciones, copiar el calendario de un sprint no produce la misma prueba. Ajustaría el método explicando qué posibilidad de aprender se pierde y cómo la recuperaremos.

La recomendación de un mentor puede orientarme, pero necesito comprender para qué situación la formuló. Los principios de gobierno ágil de GOV.UK también vinculan las decisiones a la evidencia, los límites y la autoridad disponible. [3] Por eso no mediría el método solo por la rapidez con que completamos sus actividades.

07 / APRENDIZAJES

Qué me llevaría

• Escribiría la decisión y la incertidumbre antes de escoger una herramienta.
• Compararía método, capacidad, coste de equivocarse y reversibilidad.
• Definiría una señal que pueda cambiar la siguiente acción.
• Separaría explorar un problema, probar una solución y repetir una operación.
• Revisaría el método por el aprendizaje que produjo, no por haber completado sus pasos.

08 / PREGUNTAS DETONANTES

Para continuar

• ¿Qué decisión concreta debe ayudarme a tomar el método?
• ¿Qué parte de la situación todavía no entiendo?
• ¿Qué condición tendría que existir para que esta forma de trabajo fuese posible?
• ¿Qué coste acepto si la prueba no produce una señal?
• ¿Qué observaría para cambiar de método?