Innovación en Escala: Articulando SAFe para la generación de innovación — Parte 2
En la primera parte de esta serie explicaba una forma de organizar varios elementos de SAFe que articulados apropiadamente pueden brindar un enfoque válido para la generación de innovación a nivel empresarial, cobijados por la adopción de una mentalidad de emprendimiento al estilo Lean StartUp. De esta forma, el post anterior presentaba los siguientes pasos:
- Definir un Value Stream enfocado a la Innovación
- Asignar presupuesto al Value Stream de Innovación
- Crear Iniciativas de innovación como Épicas
- Presentar y refinar la Épica
A este punto, ya se cuenta con una Épica analizada y refinada en función de las perspectivas de Deseabilidad / People (¿ésta iniciativa resuelve alguna necesidad de alguien?), Viabilidad / Business (¿es ésta iniciativa rentable para el negocio? ¿están dispuestos a pagar por esta solución?) y Factibilidad / Technology (¿es posible construirla con la tecnología existente? ¿debemos crear tecnología para consolidar esta idea?).
[caption id=”attachment_175326261" align=”aligncenter” width=”500"]
Épica vista desde las perspectivas del Design Thinking[/caption]
Como resultado de este análisis, contamos con una primera versión de su Modelo de Negocio (deseablemente en un Lienzo) y un Caso Ligero de Negocio propuesto por SAFe, que le añade a la Épica mayor perspectiva de negocio y es muy útil para el Portafolio. Puede ser algo como lo siguiente:
[caption id=”attachment_175326286" align=”aligncenter” width=”676"]
Ejemplo de un Modelo de Negocio[/caption]
Es importante resaltar que estos elementos representan el diseño del “primer experimento” a ejecutar; de tal forma, todos los elementos del lienzo son sólo hipótesis y el modelo de negocio completo estará en evolución a medida que vayamos recolectando aprendizaje validado, a través del feedback de nuestros Early-Adopters, descubriendo sus problemas y necesidades.
[caption id=”attachment_175326288" align=”aligncenter” width=”676"]
Evolución del Modelo de Negocio[/caption]
Una vez que nuestra épica ha sido aprobada por el Program-Portfolio Management Team y asignada al Agile Release Train dentro del Value Stream, lo siguiente que SAFe sugiere en su dinámica a nivel de Programa es trabajar en la Visión, el Roadmap del Producto y en el Backlog de Features, a través de varios roles propuestos en este nivel:
[caption id=”attachment_175326292" align=”aligncenter” width=”676"]
Visión, Roadmap y Program Backlog en SAFe[/caption]
Pues NO!, no lo haga así. Sí bien esta dinámica sirve bastante bien para la creación productos en otro tipo de Value Streams donde las condiciones de entrega y cumplimiento son diferentes, desde mi punto de vista ésta perspectiva no refleja una visión de emprendimiento y generación de innovación. No puede establecer un roadmap y backlog de Features para crear una solución a una necesidad y a un usuario que todavía no conoce; hay que experimentar, hay que aprender.
Entonces, en lugar de la Visión enfóquese en descubrir patrones, problemas, necesidades y aprendizaje validado; puede plasmarlos en un Problem Statement que puede cambiar con el aprendizaje obtenido. En lugar de un Roadmap, no pierda de vista su Modelo de Negocio y su evolución; y en lugar de un Backlog de Features cree varias Hipótesis de Cliente, del problema y de la solución o producto.
[caption id=”attachment_175326296" align=”aligncenter” width=”490"]
Pensamiento basado en Planificación vs. Pensamiento Emprendedor (Lean StartUp)[/caption]
Realice un “Taller de Empatía” (Empathy Workshop)
Para lograr dirigirse a los elementos de la derecha en el gráfico anterior, es necesario “empatizar”. En este taller el equipo emprendendor (en el que ahora se convierte el equipo de Programa de SAFe: Epic Owner, Product Manager, System Architect, Product Owners, Teams y los demás) se reúnen para profundizar sobre varios de los elementos del modelo del negocio y darle rostro a los Clientes y Usuarios, generar hipótesis de problema y solución más enfocadas, y bosquejar capacidades e interacción. En otras palabras, aplicar los pasos del Design Thinking.
“Design Thinking es un proceso de innovación enfocado en personas que se nutre de herramientas de diseño para integrar las necesidades de los usuarios, las posibilidades de las tecnología y los requisitos para el éxito de un negocio.” — Tim Brown, Presidente y CEO de IDEO
La dinámica de este taller me emociona. En los talleres de Design Thinking que he facilitado he visto una integración poderosa de la capacidad creativa y de ideación de los participantes, pensamiento enfocado a personas y uso de técnicas del UX que generan una energía genial y entregables fantásticos. Hay muchas herramientas y técnicas que se pueden aplicar el proceso de DT, sin embargo me permito sugerir el siguiente toolkit al que se le puede añadir o quitar elementos. Aplicando este toolkit he realizado talleres en aproximadamente 2 horas con excelentes resultados (pero tómese su tiempo):
[caption id=”attachment_175326329" align=”alignnone” width=”2010"]
Toolkit ligero para un taller de Design Thinking por Johnny Ordóñez[/caption]
En esta presentación puede profundizar sobre cada paso y las herramientas propuestas dentro de este, así como también algunas fotos de los equipos y su trabajo.
Reemplace sus Features por Hipótesis
En el primer post de esta serie hablaba de llamar Agile Innovation Lab en lugar de ART a los equipos dentro del Value Stream de Innovación; esto es porque me gusta imaginarlo como lugar donde se están corriendo experimentos para probar hipótesis a través del método científico:
[caption id=”” align=”aligncenter” width=”350"]
Método Científico en Lean StartUp por Alex Cowan[/caption]
Una hipótesis es una explicación propuesta para explicar un fenómeno. Es un supuesto sujeto a experimentación. Cuando junto con su equipo, crearon su Modelo de Negocio, definieron algunas hipótesis que responden a varias de estas preguntas:
- ¿Quién es tu Usuario y quién tu Cliente?
- ¿Qué problemas tienen?
- ¿Cómo tu producto encaja en su vida personal o laboral?
- ¿Cómo y cuándo usarán tu producto?
- ¿Quién pagará por tu producto?
Considere a éstas Hipótesis al nivel del modelo de negocio. A continuación se pueden establecer hipótesis a nivel de “capacidades” deseables de producto o solución; es decir, construir el producto correcto para la necesidad correcta. Josh Seiden propone aplicar el enfoque de experimentación al desarrollo de software creando así algo denominado Hypothesis-driven Development. Las hipótesis son mejores que los requerimientos en el contexto del emprendimiento donde existe gran incertidumbre. Los requerimientos o features son mejores en contextos donde los estándares son bien conocidos, existe mayor conocimiento del cliente/mercado y de cierta forma el dominio del problema es “estable”. Por esta razón, no significa que la dinámica propuesta por SAFe: Visión -> Roadmap -> Features está mal, simplemente no la creo apropiada para equipos en un Value Stream de Emprendimiento e innovación.
“Necesitamos cuestionar el concepto de tener requisitos fijos para un producto o servicio. Los requisitos son valiosos cuando los equipos ejecutan una bien conocida o entendida fase de una iniciativa, y pueden aprovechar las prácticas bien conocidas para lograr el resultado. Sin embargo, cuando se está en una fase exploratoria, compleja e incierta se necesita hipótesis.” — Barry O’Reilly, Co-autor de Lean Enterprise: How High Performance Organization Innovation At Scale
.
Siguiendo la plantilla de Josh Seiden, una hipótesis luce así:
[caption id=”attachment_175326298" align=”aligncenter” width=”500"]
Ejemplo de Hipótesis usando la Plantilla de Josh Seiden[/caption]
Priorice las Hipótesis
Una de las confusiones comunes de los emprendedores a los que he tenido la oportunidad de hacer mentoring, es aquella de diferenciar ¿quién es el Usuario y quién el Cliente?. En ocasiones son los mismos, en otras no. Cliente es quién está dispuesto a pagar por tu producto o servicio en busca de resolver una necesidad real que posee él o ella mismo o un grupo. Usuario es quien estará interactuando directamente con el producto o servicio, quien tiene el problema. Una forma de priorizar las hipótesis es usar la siguiente matriz:
[caption id=”attachment_175326300" align=”aligncenter” width=”676"]
Matriz de Priorización de Hipótesis[/caption]
Comience por ordenar desde la sección roja hacia la turquesa. Otra forma de hacerlo es la propuesta por Josh Seiden que enfoca el probar los supuestos más riesgosos primero, aquellos de las cuáles no tenemos información y que pueden tumbar el emprendimiento en caso de ser falsas:
[caption id=”attachment_175326301" align=”aligncenter” width=”500"]
Matriz de priorización de supuestos por Josh Seiden[/caption]
Ambos enfoques son totalmente válidos y pueden ser usados en función de la madurez de su modelo de negocio, si posee mucha incertidumbre sobre sus hipótesis de Cliente y de Problema, quizás el segundo sea mejor. Si su modelo ha madurado y ha logrado comprobar efectivamente el Cliente, el usuario, el problema y se dispone a probar la solución, posiblemente el primero sea mejor opción.
Desgloce su Hipótesis en Historias de Usuario
A este punto varios agilistas me han preguntado: ¿y dónde están las historias? Tranquilos, vienen a continuación. A pesar de que esto no es parte del enfoque de Hypothesis-driven Development, cuando combina Lean StartUp y Agile Development donde sus equipos usan Scrum por ejemplo, es necesario establecer alternativas sobre cómo comprobar las hipótesis que sacaremos al mercado. Las historias de usuario tienen como objetivo comprobar el supuesto de la hipótesis a través de capacidades más pequeñas que se implementarán en el producto. Si bien es cierto, las historias también pueden ser expresadas en formato de hipótesis en su nivel de granularidad; mi consejo es hacer una correlación y dejar las hipótesis un poco más “grandes” y que los equipos puedan descomponerla en elementos más familiares como historias de usuario.
[caption id=”attachment_175326304" align=”aligncenter” width=”500"]
Ejemplo de Historia de Usuario[/caption]
En un equipo Scrum, el responsable de hacer esto es el Product Owner; si bien este rol puede existir, es preferible que todo el equipo emprendedor trabaje destilando alternativas de producto para probar las hipótesis. En algunos casos, no necesariamente significará crear software.
La matriz podría verse así:
[caption id=”attachment_175326305" align=”aligncenter” width=”676"]
Hipótesis e historias[/caption]
No es necesario llenar todas las hipótesis con historias. Es mejor enfocarse en definir historias para aquellas de las hipótesis con mayor prioridad que se desee probar en el siguiente Producto Mínimo Viable o MVP. Crear historias no es suficiente, es necesario priorizarlas también. Hay muchos métodos de priorización de historias de usuario, para este contexto sugiero utilizar el Método de Análisis de Kano porque se enfoca en lograr aquella “calidad subjetiva” que va más allá del cumplimiento de features, me gusta la búsqueda de elementos “deleitadores”, sorprendentes, “no esperados” que son más cercanos a definir una mejor experiencia de usuario, vital para los productos de emprendimiento. No quiere decir que las demás no sean útiles, pero tengo una predilección personal por Kano.
[caption id=”attachment_175326307" align=”aligncenter” width=”500"]
El Modelo Kano[/caption]
De esta forma, se podrán agrupar las historias de usuario por Básicas, Lineales y Deleitadoras:
[caption id=”attachment_175326308" align=”aligncenter” width=”676"]
Aplicando el Modelo de Kano a las historias[/caption]
Tentativamente, las franjas desde la roja hacia la turquesa nos indican la prioridad y el orden del backlog. Sin embargo, la linealidad puede ser contraproducente. En algunos equipos Scrum donde hemos usado esta técnica, existe la tendencia de seleccionar primero aquellas historias que son básicas, luego las lineales y por último las deleitadoras; con el objetivo de cumplir las características básicas del producto, aunque al principio no encante.
No me gusta mucho, no debes esperar al final para deleitar al usuario; me gustan más una secuencia que nace de navegar por todas los tipos de historia tratando de entregar en cada MVP un poco de todo, y deleitando también:
[caption id=”attachment_175326309" align=”aligncenter” width=”676"]
Secuencialidad en la toma de Historias[/caption]
Okay, pienso que puedo cerrar aquí por el momento. En el siguiente post escribiré sobre la definición del MVP y la medición del aprendizaje validado.
Gracias por su feedback.
Johnny
Referencias
http://www.hackerchick.com/2012/04/hypothesis-driven-development.html
