Stooa, desarrollo Agile de una herramienta de fishbowls

En tiempos de pandemia, llevar esta dinámica al entorno virtual nos pareció una necesidad para mantener el vínculo entre runroomers y para preservar nuestro ecosistema ágil. Pero, ¿éramos los únicos con esta necesidad? ¿Qué estaba ocurriendo en otras organizaciones? 

Gracias al proceso de research e iteración que os contamos en este case, logramos convertir una intuición en realidad. Y así nació Stooa: el primer fishbowl online del mercado.

A raíz de la pandemia e inmersos por completo en el trabajo full remote, nos encontramos con el reto de trasladar nuestros espacios de encuentro y participación, pilares fundamentales de la cultura colaborativa de Runroom, al plano online. 

En particular, necesitábamos una herramienta interna de comunicación que fuese capaz de facilitar automáticamente debates autoorganizados entre grandes grupos de personas.

Después de hacer un benchmark, descubrimos que no existía ningún software con este fin en el mercado y nos propusimos investigar si nuestra inquietud también constituía un problema para otros: ¿Se necesitan herramientas online que permitan intercambiar conocimiento de forma fluida y ordenada? ¿Hacen falta tools específicas para dinámicas de unconference (debates colaborativos autoorganizados)?

Estas preguntas motivaron la conceptualización y creación del MVP (Minimum Viable Product) de Stooa, la primera herramienta online específica para dinámicas de fishbowl.

Para la creación de Stooa seguimos la metodología Lean. Un método que se origina en el Japón de los años setenta con el TPS (Toyota Production System), y que se centra en identificar y potenciar la creación de valor minimizando el desperdicio o la pérdida de tiempo (waste). De acuerdo con este sistema, el éxito de un producto, servicio o modelo de negocio dependerá de cuán hábiles seamos iterándolo a la luz del feedback que recibamos de su testeo, antes de quedarnos sin recursos. La clave para minimizar el waste está en aprender (lo máximo y lo más rápido posible) sobre los clientes.

¿Cómo iniciamos este aprendizaje? 

Para explorar la viabilidad de una idea, lo primero que hay que hacer es validar si el problema al que pretendemos dar solución es un problema real para alguien. Dicho de otro modo, si hemos encontrado un problema que merece la pena resolver. En el universo Lean, esta fase se conoce como problem-solution fit o empathy. 

Nuestra experiencia cuando asistíamos a eventos de unconference online es que resulta muy difícil tener una conversación ordenada, fluida e inteligible si hay más de cinco personas en sala. Así que nos propusimos validar el siguiente problema: ¿Hacen falta herramientas online específicas para eventos participativos y autoorganizados? ¿Es una inquietud compartida? 

Para averiguarlo, nos basamos en el marco teórico que propone Ash Maurya en Running Lean y seguimos los siguientes pasos:

1. Creamos un Lean Canvas

Lean Canvas (inspirado en el Business Model Canvas de Alexander Osterwalder) es una herramienta pensada para conceptualizar modelos de negocio de proyectos en los que hay mucha incertidumbre. En una sola página, proporciona una vista de pájaro de los aspectos clave involucrados y de cómo se relacionan entre ellos. Al ser un diagrama esquemático y conciso, permite introducir cambios de forma muy sencilla y tener trackeado el aprendizaje a medida que se va obteniendo. 

Este es el Lean Canvas de Stooa, lienzo primigenio en el que volcamos todo el aprendizaje que vendría después:

2. Validamos el problema mediante entrevistas (The Problem Interview)

Una vez diseñado el Lean Canvas, hay que averiguar si nuestro modelo de negocio se fundamenta en un problema que merece la pena resolver. Utilizamos como herramienta las entrevistas de problema a potenciales clientes para validar si la necesidad que nos había parecido detectar existía realmente.

Siguiendo la estructura de guión que se propone en Running Lean, orientada a obtener información no sesgada de los clientes hipotéticos, realizamos diez entrevistas de unos 30 minutos a distintos stakeholders, como Miquel Rodríguez, Marc Mauri o Jose E. R. Huerta, para averiguar cuál era su vivencia y principales pains en los eventos de unconference online:

La conclusión de las entrevistas fue que sí parecía existir el problema y que, por tanto, ¡tenía sentido explorar una posible solución!

3. Creamos un prototipo para una posible solución

Llegados a este punto ya sabemos que hacen falta herramientas específicas que faciliten dinámicas de unconference online. De entre las que existen (dot voting, World Café, speed dating, open space, etc.), escogimos el fishbowl por estar muy ligado a la cultura de Runroom.

Hicimos un Design Sprint de una semana en el que, de forma colaborativa, creamos un prototipo de lo que en el futuro acabaría siendo Stooa. Y trasladamos esta primera interfaz a los mismos stakeholders que habíamos entrevistado para que interactuasen con ella y pudieran darnos feedback.

4. Validamos la solución mediante entrevistas (The Solution Interview)

Para capturar sus impresiones con el prototipo de Stooa, les hicimos lo que se conoce como entrevistas de solución, cuyo objetivo es validar si la solución propuesta resuelve el problema de forma efectiva. Al igual que con las entrevistas de problema, es clave definir hipótesis y someterlas a juicio. Después de realizar las diez entrevistas, les pasamos una encuesta cuantitativa para saber si estarían dispuestos a pagar por un producto como Stooa.   

Una vez analizada y sintetizada toda la información obtenida de las entrevistas y encuestas, había algo que celebrar: ¡el prototipo de Stooa parecía una buena aproximación para resolver su problema y estarían dispuestos a pagar por ello! 

Ese fue el pistoletazo de salida para desarrollar nuestro MVP, es decir, el conjunto mínimo de características que Stooa tenía que tener para dar una respuesta satisfactoria a los pains que actualmente acarrean las dinámicas de unconference online.

Desde una perspectiva agile de entrega temprana y frecuente de valor, hicimos un desarrollo iterativo e incremental de Stooa, prototipando y testeando sistemáticamente. 

El primer MVP de Stooa lo desarrollamos en seis sprints de dos semanas, con tests de usuario para validar sus principales funcionalidades. Para ello, pusimos en marcha un equipo crossfuncional formado por múltiples roles y perfiles (negocio, frontends, backends, researchers, designers, etc.) que fueron cambiando a lo largo del proceso sin que eso afectara a la calidad del producto ni al calendario de las entregas. 

El 12 de febrero de 2021 lanzábamos Stooa en un evento que no podía ser más representativo, “20 años del Manifesto Ágil”, tres fishbowls online en los que estuvimos hablando sobre la evolución del "agilismo" y las distintas formas de entenderlo.

Aunque su desarrollo no cesa, a día de hoy Stooa es una realidad y algunas organizaciones como el PEMB (Pla Estratègic Metropolità de Barcelona) están utilizándola para vehicular sus procesos participativos. En Runroom no podemos estar más contentos de haber desarrollado una herramienta tan acorde a nuestros valores que permite la conversación abierta, fluida y autogestionada, conectándonos con amigos actuales y aquellos que están por venir. 

Pero el trabajo no acaba aquí: con más ilusión que nunca, nos proponemos validar el market-solution fit de Stooa y nos adentramos en la fase de adherencia de este largo viaje. Con este objetivo, a finales de noviembre de 2021 convertimos Stooa en producto Open Source y lo abrimos a la comunidad internacional de desarrolladores a través de las plataformas Product Hunt y Hacker News. ¡Una oportunidad para devolver algo de lo recibido durante todos estos años! 

Os invitamos a leer la newsletter que le dedicó Product Hunt a Stooa durante su lanzamiento: "The fishbowl method at work".

Nuestros próximos pasos son dar a conocer Stooa a comunidades virtuales, seguir generando valor y conseguir un producto Open Source alineado con la cultura colaborativa de Runroom. To be continued…!