¿Cómo funciona Design Thinking?

Using Design Thinking to hack the culture in organisations por Angel Díaz Maroto

Una de las sesiones del Global Scrum Gathering Munich 2016 la dedicó Angel Díaz Maroto a Design Thinking aplicado a la transformación cultural de las compañías: "using Design Thinking to hack the culture in organisations".

La idea de esta sesión fue buscar mediante Design Thinking actividades en forma de historias con las que poder cambiar la cultura de la compañía y llevarla hacia la Agilidad. Quiero aprovechar esta experiencia para exponer esta herramienta.

Design Thinking es una herramienta de gran utilidad enfocada a fomentar la innovación en las organizaciones de una forma eficaz y exitosa. Está centrada en las personas y nos permite observar los retos, detectar necesidades y desarrollar productos y soluciones exitosas gracias al conocimiento sobre los usuarios y a la formación de equipos multidisciplinares que ofrecen diversos puntos de vista durante el proceso. Busca hacer coincidir las necesidades de las personas con lo que es tecnológicamente factible y con lo que una estrategia viable de negocios puede convertir en valor para el cliente, así como en una gran oportunidad para el mercado.

El proceso de Design Thinking es un proceso creativo no lineal, en el que se puede ir hacía adelante y hacia atrás, e incluso dar saltos, que consta de las etapas que sean significativas para nuestro entorno, y que con estas idas y venidas haga emerger del equipo una solución que cumpla con los objetivos buscados.

Proceso de Design Thinking mínimo de 3 etapas - Imágenes cortesía de Pixabay

Observar:

Esta etapa se basa en observar al usuario para comprenderlo y adquirir conocimientos básicos sobre la situación o el problema que afronta.

Brainstorm de ideas, aqui sobre todo aquello que
un directivo pueda temer a una transición a agilidad

• User-Persona: Crear usuarios tipo para los que se diseña la solución o producto y de los que queremos conocer su punto de vista y vivir su historia.
• Mapa de empatía: Desarrollar empatía con los usuarios mediante la observación de los mismos y obtener lo que piensa, oye, dice y siente.

Idear:

Sobre los elementos identificados en el mapa de empatía hacer un brainstorming para generar tantas ideas como sea posible:

• Primero divergir: ¿cuáles son las preocupaciones de la persona alrededor del producto o solución?, ¿qué es lo que más teme que pueda ocurrir?
• Votar las más representativas.
• Finalmente converger: Sobre las más votadas pensar como prevenirlas para generar ideas rompe-patrones (pattern breakers).

Prototipar:

Story board por Angel Díaz Maroto

Para prototipar una técnica excelente es el storyboard, una forma gráfica para implementar las ideas rompe-patrones.

Escoger los rompe-patrones más prometedores y hacer una actividad colaborativa con otros equipos de otras disciplinas para crear prototipos de actividades que desarrollará y vivirá la persona usuaria de la solución.

El equipo que ideó los rompe-patrones los cuenta a otro equipo, y los miembros de este último desarrollan el rompe-patrones en post-its con palabras clave con razones, visiones, patrones, etc., de forma que el conjunto cuente una historia de como implementar el rompe-patrones.

Hay que tomar feedback de las reacciones de los usuarios al interactuar con las historias del prototipo, si los objetivos no se han logrado hay que iterear. Sin duda utilizando Design Thinking emergerá una solución excelente que realmente cubra las necesidades de los usuarios.

¿Cual es la diferencia entre un coach y un consultor?

Lao-Tsé

Vivimos tiempos en los que las consultoras buscan coaches ágiles para su incorporación en algunos de sus clientes, y me pregunto si son conscientes de la naturaleza de este rol.

Si miramos en la International Coach Federation podemos leer:

"Los individuos u organizaciones contratan consultores por su experiencia... se supone que el consultor diagnosticará los problemas y prescribirá, y a veces, implementará, las soluciones. El coach parte de la suposición que los individuos y los equipos son capaces de generar sus propias soluciones con la ayuda del entrenador que les proporciona enfoques y marcos de apoyo basados en el descubrimiento".

A mi me gusta hacer un paralelismo con una de las frases de Lao-Tsé, uno de los filósofos más relevantes de la civilización china:

Si das pescado a un hombre hambriento, le nutres una jornada » consultor

Si le enseñas a pescar, le nutrirás toda la vida » coach

Para mi hay una clara distinción entre la postura del coach y la del consultor. Este último es un experto en la materia, proporciona contenido, dice qué hacer y puede hacer el trabajo de un miembro del equipo. Su enfoque es el de estar alerta a oportunidades para expandir la presencia de su empresa en el cliente.

El coach proporciona contexto y acompaña al equipo y a sus miembros a encontrar su propio camino, con la firme convicción de que las mejores soluciones siempre están en las personas que hacen el trabajo. Hace preguntas para reflexionar sobre lo que se dice y se escucha, pregunta de nuevo, tal vez insinúa o sugiere, pero siempre de forma que trabajando de forma conjunta la idea o solución emerja de forma auténtica del equipo y sus miembros. Su enfoque está centrado en las necesidades del cliente.

Desde mi experiencia la consultoría como experto Agile es apropiada inicialmente, cuando se forma o se transforma un equipo ágil, o cuando el equipo se queda atascado y no es capaz de encontrar sus propias soluciones. Por ejemplo consultor y coach se solapan al actuar como Scrum Master en el primer sprint de un nuevo equipo, proporcionando asesoramiento y orientación, luego hay que saber alejarse exclusivamente a coach y permitir que el equipo encuentre su propio camino hacia la autoorganización y la Agilidad, para finalmente hacerse obsoleto cuanto antes y que el equipo no necesite coaching.

¿Cómo imprimen los sprints flujo en la construcción de un producto?

Ciclo de eventos del sprint

El evento principal de Scrum es el sprint, un evento iterativo contenedor de los demás: la reunión de planificación de sprint, la reunión diaria, la revisión de sprint y la retrospectiva.

El sprint es timeboxed, de duración fija de entre 1 y 4 semanas, duración que se establece al principio por el equipo o la organización. Su objetivo es marcar cadencia, un ritmo de avance en el que con cada final de sprint se produzca la entrega de un incremento terminado y potencialmente instalable en producción. Los equipos ágiles son como motores, cada uno con su propia velocidad, y los sprints son las pistonadas del mismo, pistonadas con entrega incremental de producto de forma sostenida.

Flujo de Scrum por Raúl Herranz

Uno de los beneficios de la cadencia es la reducción de la variabilidad, con los sprints relativamente cortos estamos provocando tamaños de historias de usuario pequeños limitados por el tamaño del sprint, de forma que con elementos pequeños imprimimos un flujo estable a la construcción del software.

El sprint también marca un ritmo fijo para comprobar el avance y visibilidad del producto a través de la planificación de sprint y la revisión de sprint. En la planificación de sprint ocurre el corte de la pila que hace el equipo, corte que apoyado por las medidas de velocidad de sprints anteriores, implica un límite del trabajo en curso (WIP) intrinseco, con el que se ajusta el trabajo a la capacidad, lo que significa ir a favor del flujo.

A la vez imprime ritmo a puntos de reflexión y mejora al modo de trabajo a través de las retrospectivas. En estas buscamos mejoras que irán a favor del flujo, tanto para resolver impedimentos como para acelerarlo.

Ocurren ocasiones en las que el equipo se atrasa o se adelanta, casos en los que dado el timeboxing no nos permite modificar la duración de sprint, se hace el ajsute en el alcance del sprint. Podemos incluir alguna historia a medio sprint o no construir historias de menor valor de negocio. Ambos ajustes son decisión del equipo que apoyándose en el Propietario del Producto deciden sobre las historias de usuario afectadas.

¿Cúal ha de ser la perspectiva de los equipos técnicos en una compañía ágil?

Responsable de seguridad - cortesía de Pixabay

Recientemente asistí a una conversación entre un Propietario del Producto y el responsable de seguridad de la compañía. Recordemos que el objetivo de este último es el de garantizar que la privacidad y la información de la empresa esté protegida adecuadamente a través de políticas de seguridad de la información.

La conversación se centró sobre la utilización de los marketplaces Google Play y Apple App Store para el despliegue de una App Móvil a los diferentes usuarios colaboradores de la compañía.

El Propietario del Producto sostenía que la App Móvil se debía de desplegar vía marketplace, ya que el volumen de usuarios de la aplicación superaba las 2 cifras y por tanto sería la única forma viable de desplegar, tanto la aplicación inicial como las actualizaciones posteriores. Por otro lado argumentaba que es la forma en que las demás compañías lo hacen, por tanto la ciberseguridad tenía que estar resuelta y que no tenia ningún sentido reinventar la rueda.

Ciberseguridad alineada con negocio
cortesía de Pixabay

Por su lado el responsable de seguridad sostenía que esa solución atentaba contra las políticas de seguridad. Propuso soluciones alternativas, como un servidor propio para el despliegue inicial y sucesivas actualizaciones, o in extremis la posibilidad de desplegar de forma manual...

Esta divergencia puede producirse en multitud de situaciones en las que sistemas y negocio no tienen un objetivo común. ¿No debería el objetivo de toda persona, equipo, grupo, área o departamento de la compañía ser que esta sea más competitiva, se sitúe en la mejor posición posible del mercado y en definitiva maximice sus beneficios? En esta línea, ¿la función principal del responsable de seguridad no debería de ser la de alinear la seguridad de la información con los objetivos de negocio?

¿Cómo resuelve la Agilidad esta divergencia?

En primer término está establecer un entorno de responsabilidad compartida que potencie la comunicación y colaboración del Propietario del Producto e interesados con el equipo técnico, entre ellos sistemas. Un entorno adecuado propicia que se establezcan canales de comunicación para la colaboración y se den las conversaciones necesarias para hacer emerger buenas ideas a modo de abanico de opciones con buenas soluciones desde la perspectiva de negocio. En Agilidad nos guiamos por valor de negocio, por tanto aquellas opciones que dan solución a negocio se dejan madurar hasta que en algún punto de aprendizaje, un punto de feedback, tengamos información fresca para decidirnos por la mejor solución del abanico. Solo se produce entrega de valor de negocio cuando hay colaboración.

Negocio y equipo técnico negocian historias técnicas a incluir en la pila producto, quizá primero spikes para explorar las opciones del abanico, y después historias sobre seguridad, escalabilidad, eficiencia, etc. y algunas de refactorizaciones (recordemos que en Agilidad la calidad no es una variable).

En definitiva, todo trata de colaboración y comprender el objetivo último del porqué estamos en la compañía. Las políticas de seguridad son necesarias, pero no como fin en si mismas, sino con el objetivo de aporte de valor y hacer crecer a la compañía en su core-business.