¿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.

¿Qué tal JIRA como herramienta para apoyar la gestión de proyectos ágiles?

Propietario del Producto ante la pila de producto

Hemos ido probando distintas herramientas y hasta el momento ninguna cubre el ciclo completo incluyendo proyecto y fase de mantenimiento, desde la gestión de la construcción con Scrum, los planes de pruebas con sus criterios de aceptación y las incidencias. En esta ocasión hemos probado JIRA que promete tener todas las herramientas necesarias de forma integrada. Si visitamos la página JIRA Agile podemos leer:

"JIRA Software es una herramienta ágil de gestión de proyectos compatible con cualquier metodología ágil, ya sea Scrum, Kanban o la tuya propia. Desde tableros hasta informes ágiles, puedes planificar, supervisar y gestionar todos los proyectos de desarrollo de software ágil con una sola herramienta. Elige una metodología para ver cómo JIRA Software puede hacer que tu equipo publique software de calidad con mayor rapidez".

Y si vamos al apartado de Scrum:

"Scrum es una metodología ágil con la que se diseñan productos en una serie de iteraciones de longitud fija. Hay cuatro pilares que conforman la estructura de esta metodología: la planificación de sprints, los stand ups (también llamadas scrums diarios), los sprints y las retrospectivas. Saliéndose de lo común, JIRA Software viene con una completa serie de herramientas ágiles que harán que tu equipo de scrum lleve a cabo estos eventos con facilidad".

Entre las características del producto se puede leer:

• Gestión de release planning
• Gestión fácil de la pila de producto con drag&drop
• Gestion de la planificación de sprint
• Gestión del scrum diario
• Tablero de scrum con drag&drop
• Basa la medida del esfuerzo en puntos de historia

De entre los informes ágiles incluye:

• Diagrama de evolución
• Informe de sprint (burndown)
• Gráfico de velocidad
• Diagrama de flujo acumulado
• Informe de epic
• Gráfico de control
• Evolución de epics
• Evolución de publicaciones
• Informe de versión

Pantallazo con la lista de informes ágiles y un par de ejemplos

Lo que no me gusta:

• Se hace patente el origen de JIRA como gestor de tareas, las historias de usuario son task y las tareas sub-tasks. Pero esto es sólo una cuestión estética que sin duda Atlassian acabará mejorando.
• El tablero de scrum, aunque está muy bien resuelto, es poco colorido (tengo que admitir que no cargamos fotos o avatares de los miembros del equipo), y se corta con más de 4-6 historias de usuario y por tanto requiere de scroll. Esto reduce la visión agregada del mismo y reduce la visión del todo y del avance del sprint.

Tablero Scrum muy funcional pero poco llamativo para una gestión visual

Lo que me gusta:

• Historias de usuario no finalizadas en el sprint las lleva de vuelta, junto a sus tareas, a la pila de producto. Es exactamente como debe de ser, si no hay entrega no debe de contar. A más de un equipo novel le extrañará este comportamiento y se producirá la oportunidad para formarles y hacerles comprender el guiado por valor de negocio. Cuando se abra un nuevo sprint y se incluya la historia recuperará las tareas y los puntos hechos contarán para el nuevo sprint.
• Me encanta que JIRA trabaje por defecto con puntos de historia, para cambiar a horas ideales hay que ir a un rincón de la configuración que está algo escondido. :-)
• La gestión a nivel de release permite ver el estado completo, con trazabilidad a las incidencias, a los datos de desarrollo y a los impedimentos.
• Incluye un potente motor de workflow que permite ajustar el flujo de JIRA al del equipo/compañía, permitiendo crear estados y transiciones de flujo personalizadas para cada tipo de elemento: incidencias, historias de usuario, epics, tareas...
• Los tableros de scrum de JIRA son muy funcionales y muy intuitivos. Se pueden personalizar en vertical para encajar estados con el flujo de trabajo del equipo, y en horizontal para añadir carriles para separar epics, roles, productos/proyectos, etc.

A la izquierda: Los sprints se montan arrastrando historias desde la pila de producto
A la derecha: Arriba, la pila de producto y el detalle de una historia, abajo el detalle de una tarea

Para concluir mencionar que JIRA es una buena herramienta agile que cubre en gran medida las necesidades de desarrollo y que integra de forma avanzada las herramientas de desarrollo con una experiencia común para todo el equipo scrum e interesados del proyecto.

¿Qué parámetros analizar para determinar si un proyecto es factible?

¿Cuánto cuesta? del Agile Inception Deck de Jonathan Rasmusson

Nuestros clientes suelen estar interesados primordialmente en dos cosas:

• ¿Cuánto va a costar esto?
• ¿Para cuándo va a estar listo?

En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Cúanto cuesta?, en la que hacemos todo lo posible para responder a estas dos preguntas para que puedan decidir si el proyecto vale la pena y mostrarles lo que va a requerir.

Junto con los resultados de las actividades del pack de la incepción Estimar el tamaño y Mostrar la solución, esta actividad nos da la tu oportunidad de mostrar qué tipo de equipo va a ser necesario y en como lograr los objetivos del proyecto.

El equipo A del Agile Inception Deck de Jonathan Rasmusson

En la tabla del equipo A, como en la de la imagen de la izquierda, se muestra el equipo necesario sin el cual el proyecto no puede tener éxito. Con esta tabla se establecen las expectativas en torno al tamaño del equipo, los roles clave, el conjunto de habilidades requeridas y la combinación de habilidades funcionales cruzadas necesarias. Es importante incluir nombres de personas concretas cuando estas son requeridas por su expertise.

Con unos cálculos relativamente simples y a grandes números podemos encontrar el coste aproximado del proyecto y decidir sobre su factibilidad. Los costes derivaran principalmente de los salarios de los miembros del equipo durante el tiempo previsto del proyecto, más costes relativamente menores de recursos y servicios para la puesta en marcha. Un ejemplo de cálculo podría ser:

3 personas X 3,5 meses X 20 días/mes X 8 horas/día X $150/hora ≈ $250K

Si se tratara de un proyecto cerrado con un presupuesto establecido, podemos hacer ese tipo de cálculo para ver si el proyecto es factible dadas las condiciones preestablecidas.

¿Cómo identificar los riesgos principales en la fase de definición del proyecto?

Dinámica colaborativa con post-its para hacer
emerger los riesgos, en rojo el que más preocupa

¿Cuántas veces no nos hemos podido dormir dándole vueltas al estado de un proyecto? Y por buenas razones: pensamos en si nuestros clientes van a cambiar una y otra vez sus requisitos y prioridades, en si las estimaciones no han sido excesivamente optimistas, en que siempre parece que hay más cosas que hacer que lo que tiempo y presupuesto permiten... Y, ¡estos sólo son los riesgos conocidos del proyecto!

Hay mil cosas que pueden ir mal, algunas se pueden gestionar y otras no, algunas se deben de gestionar y otras no. Por ejemplo, no se puede hacer mucho ante el derrumbe de la economía, pero si gestionar dependencias con otros equipos e interesados.

En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Qué nos impide dormir?, una dinámica que nos invita a una discusión sana sobre algunos de los desafíos y riesgos con los que el equipo podría enfrentarse durante el proyecto, cuales simplemente asumir, cuales mitigar y cuales gestionar.

Riesgos que vale la pena gestionar son por ejemplo:

• Gestión del cambio clásica anclada al alcance inicial y no utilizar Scrum con un alcance variable guiado por valor de negocio
• Disponibilidad limitada del Propietario del Producto y usuarios clave
• Equipos con miembros sin dedicación plena al proyecto
• Entornos de desarrollo y test no dedicados o inestables
• Carencia de expertise técnico en la compañía
• Scrum Master influenciado por la inercia de un sistema no ágil
• ...

¿Qué nos impide dormir? del Agile Inception
Deck de Jonathan Rasmusson

Los objetivos de la dinámica son:

• Identificar los riesgos del proyecto
• Establecer cuales se gestionan
• Establecer qué riesgos se mitigan
• Team building & team commitment

Dinámica:

• Se rellena un tablero con los riesgos identificados por los participantes, cada participante en individual, para luego consolidarlos en un tablero
• Para cada riesgo se asignan impacto y probabilidad
• Se priorizan los riesgos y se establecen estrategias
• Finalmente el entregable será un tablero de riesgos como por ejemplo un tablero ROAM:
• RESOLVED: riesgos detectados pero que no eran tales
• OWNED: riesgos sobre los que alguien toma la responsabilidad de gestionarlos
• ACCEPTED: riesgos que simplemente se asumen
• MITIGATED: riesgos para los que se han decidido acciones mitigantes concretas

Se trata de una dinámica muy potente ya que nos da la oportunidad de pedir los recursos necesarios para tener éxito y poder exponer las consecuencias si no se proveen estos recursos.