Agilidad y producto

  • Una cultura más que unos métodos
  • Scrum - las bases
  • Scrum con lupa
  • Design Thinking

Una cultura más que unos métodos

Ante la popularidad de la agilidad, cada uno puede llegar a pensar que esta se opone a las metodologías más tradicionales como el ciclo en V. En un error de interpretación, es frecuente creer que la agilidad es mejor que todo lo anterior.

Sería caer en el rumor, limitar el análisis y olvidar que la popularidad de la agilidad se justifica por su adaptación a la incertitud que caracteriza a nuestra época. Es lo que habíamos querido destacar anteriormente aquí.

Los modelos denominados clásicos de organización y de dirección de proyectos han evolucionado para responder a las imposiciones de «time to market». Innovar permanentemente, reducir los costes y ser lo más reactivo posible son muchas de las obligaciones que ha traído la agilidad. Implicando al máximo al cliente, intentando aportar siempre el máximo valor, una trayectoria ágil no solo implica a equipos de desarrollo. La siguiente ilustración permite comprender que el campo de aplicación de la agilidad se extiende mucho más allá de la gestión de proyectos o de la producción de soluciones de software. Es una evolución organizativa que crea una cadena de valor al establecer una relación entre todos los sectores. organizational-charts-768x748-1.gif

Scrum - las bases

Scrum es la herramienta más conocida y más implementada, hasta tal punto que existe confusión. Es como si Scrum y ágil fueran sinónimos.

Esta amalgama «la agilidad es scrum y scrum es agilidad» parece comprensible, pero no es cierta porque:

  • Scrum no es la única manera de hacer, existen otros enfoques como programación extrema (XP), Kanban, SAFe...
  • La agilidad es una cultura, un estado de ánimo.

El origen de Scrum y sus bases

Scrum significa «melé» en inglés. ¡El del rugby precisamente! No es casualidad porque según sus creadores, comparte los mismos valores del rugby: compromiso, valor, enfoque, apertura y respeto.

El enfoque Scrum fue creado por Jeff Sutherland y Ken Schwaber durante los años 90 para ayudar a las organizaciones a desarrollarse, entregar y mantener productos complejos (digitales, entre otros). Son los autores de la Guía Scrum publicada en 2009.

Scrum es un enfoque empírico, es decir que el equipo que trabaja en Scrum va a probar, aprender y adaptarse sobre la marcha. De esta manera, el conocimiento procede de la experiencia, las tomas de decisiones se hacen a partir de lo que se conoce y no a partir de teorías y suposiciones.

Es también por esta razón que no podemos hablar de método, porque un método dice normalmente cómo hacer las cosas. Scrum no es como una receta de cocina que se debe seguir para que el programa tenga éxito, evitar problemas, limitar los imprevistos... Se puede ver también como una norma del juego: ofrece el marco y el papel de cada jugador. Corresponde al equipo evolucionar y crear su propia estrategia para alcanzar sus objetivos.

Para alcanzar el empirismo, Scrum se basa en tres pilares:

  • Transparencia: todo el equipo del proyecto debe comprender y compartir los aspectos importantes del proyecto, ¡la comunicación es primordial!
  • Inspección: el equipo comprueba su trabajo sobre la marcha, y no al final, una vez finalizado el producto. También inspecciona su forma de hacer y funcionar.
  • Adaptación: se pueden hacer adaptaciones para minimizar los riesgos (retrasos, diferencia con la necesidad del usuario...)

Los ingredientes de Scrum

Scrum está compuesto por 3 funciones principales, 5 eventos y 6 «artefactos» que detallaremos en el siguiente artículo. Atención, estas funciones, eventos y artefactos son obligatorios. La Guía Scrum es muy clara en este propósito: no respetar una de estas funciones/eventos/artefactos resultará en la pérdida de transparencia y oportunidades para inspeccionar y adaptar el producto.

Scrum con lupa

Después de haber establecido las bases y detallado los fundamentos de Scrum, dediquemos también tiempo a sus rituales. Scrum está compuesto por ciertos elementos indefectibles de este enfoque:

3 funciones principales

  • El Product Owner
  • El Scrum Master
  • El Dev Team

5 eventos

  • La Sprint Planning
  • El Sprint
  • Los Daily Scrum
  • El Sprint Review (Entrega)
  • El Sprint Retrospective

3 «artefactos»

  • El Product Backlog
  • El Sprint Backlog
  • El incremento

El Scrum Team

  • El Product Owner (PO) da su punto de vista del producto que se va a diseñar. Aporta su conocimiento del mercado y las necesidades de los usuarios. Es el que redacta y mantiene actualizado el Product Backlog que registra todas las funcionalidades del producto.

  • El Scrum Master (SM) no siempre está presente en los equipos Scrum, haciendo a veces el Product Owner está función. Es el responsable del framework, procura que los distintos eventos de Scrum se desarrollen correctamente dentro del plazo.

También tiene una función de facilitador.

  • El Dev team: el equipo de desarrolladores Es un grupo de 5 a 10 «creadores» que desarrolla el producto.

También participan:

  • Los skateholders / interesados: Se trata del cliente y/o usuarios del producto que se ha desarrollado. Participan durante algunos eventos o a través del intermediario del Product Owner.

  • El UX designer: Es una tendencia que observamos cada vez más: la integración de un diseño de UX en un equipo Scrum hace una buena combinación con el Product Owner y permite mantener al usuario en el centro del proceso de creación.

En un Scrum Team no hay jerarquía, todos son iguales, las decisiones son colegiales. El equipo es autoorganizado y pluridisciplinario.

Todo comienzo del Product Backlog

Todo comienza por el primer artefacto: el Product Backlog.

Se trata de un documento escrito que contiene todas las funcionalidades, las necesidades y las mejoras relacionadas con el producto. Está redactado y actualizado por el Product Owner.

Las funcionalidades se escriben en forma de historia de usuario: User Stories.

Ejemplo para una aplicación de VTC: «Como cliente, deseo estar localizado en un plano para no tener que informar sobre la dirección de mi ubicación.»

El 1er ritual: la Sprint Planning para preparar el sprint

El equipo se reúne durante la Sprint Planning para seleccionar las User Stories (US) que se desarrollarán durante el Sprint. Como todos los eventos de Scrum, la Sprint Planning tiene una «timebox», es decir, una duración máxima. Para él, la duración máxima es de 8h (para un sprint de 4 semanas).

Al final de la Sprint Planning, cada User Story debe estar clara y calculada y los miembros del dev team deben saber qué plan de acción implementar para cumplir el Sprint Goal (el objetivo del sprint).

¿Cómo se calculan las User Stories?

Para calcular una User Story, los miembros del equipo organizan un Planning Poker, se trata de un juego de cartas que permite que cada uno/a vote y calcule el esfuerzo necesario para realizarla. Ejemplo: una tarea muy fácil pero que va a ser larga no equivale en puntos a una tarea muy fácil y rápida de realizar.

Las User Stories seleccionadas por el sprint forman el Sprint Backlog.

User-Stories en el incremento: el Sprint

El objetivo de un Sprint es desarrollar una pieza funcional del producto que se está creando: un incremento. Corresponde al equipo definir su duración, que no debe superar 4 semanas. Cuando un sprint finaliza, comenzará uno nuevo.

Cada día del sprint, el equipo se reúne durante melés diarias: los Daily Scrum. Normalmente al comienzo de la jornada y con una duración de 15 minutos, el objetivo es reforzar la transparencia y la reactividad del equipo. Cada uno comparte sus acciones del día, así como las dificultades que se encuentra o que el proyecto encuentra. Así, el equipo puede adaptarse y poner en marcha planes de acción.

Entregar, probar, adaptar: el Sprint Review

Al final del Sprint, se organiza un Sprint Review, hablamos también de fase de entrega. Con una duración de un máximo de 4 horas, se reúnen el equipo Scrum y los interesados (el cliente) y/o los usuarios.

Se realiza una demostración del incremento desarrollado. El equipo Scrum recibe entonces valiosos feedbacks que se adaptarán al Product Backlog. A menudo, es también la ocasión de detectar errores, que se corregirán durante el próximo Sprint.

Es un momento importante porque es el encuentro entre los que crean y los que utilizan. El equipo Scrum comprende para quién y por qué trabaja y los usuarios se sienten escuchados e implicados en el proceso de creación.

Analizarse a sí mismo: la retrospectiva de sprint

Último evento: el Sprint Retrospective

Es una cita de 1 hora que permite al equipo Scrum analizarse resaltando lo que ha funcionado durante el Sprint, lo que no ha funcionado e implementar un plan de mejora continua con acciones concretas.

Design Thinking

"El design thinking o pensamiento de diseño es un enfoque colaborativo de resolución de problemas que es iterativo, centrado en el ser humano, creativo y concreto." Tim Brown - cofundador de IDEO

El pensamiento de diseño fue teorizado a principios de los años 2000 en Silicon Valley tras las obras del ingeniero David Kelley y del diseñador Tim Brown de la agencia IDEO.

El método a menudo se resume en una sesión de brainstorming en equipo o talleres de creatividad con Post-It. Pero nosotros veremos que es algo más que eso...

Se trata de un método que utiliza las herramientas y los métodos de los diseñadores para diseñar soluciones que respondan a los problemas de los usuarios que previamente habremos constatado sobre el terreno.

El proceso del Design Thinking se divide en dos grades fases de diamante doble reloj de arena, ya que es una sucesión de fases de trabajo de divergencia (exploramos, miramos con amplitud) y fases de convergencia (seleccionamos, priorizamos).

Comprensión e investigación del usuario

El design thinking es un método centrado en el ser humano. Todo empieza por la observación del terreno, la comprensión de las necesidades, costumbres, problemas encontrados. Adoptando una postura empática, vamos al encuentro de las emociones y razonamientos de los usuarios.

También es la ocasión de investigar sobre el ecosistema del sujeto. Procurar conocer lo que ya se ha hecho, las buenas y malas prácticas, las tecnologías existentes... Es la primera fase divergente del método, porque puede abarcar muchos dominios diferentes, ¡según el tema que tratemos!

Algunos métodos de los diseñadores para la investigación del usuario:

  • La entrevista al usuario, los sondeos...
  • La observación «punto de vista de una mosca»
  • La inmersión «vive mi vida»
  • El reportaje de fotos
  • Definir una postura

Este trabajo de investigación permite resaltar un verdadero problema que se debe tratar que no es necesariamente en el que habríamos pensado a priori desde nuestra oficina. Se trata de aclarar el perímetro y adoptar una postura: ¡definir el problema correcto es la mejor forma de encontrar la solución correcta!

Algunas herramientas para sintetizar la investigación del usuario:

  • Empathy Map
  • Persona
  • Programas usuarios

Ideación y creatividad

¡Es a partir de este momento cuando encontramos el brainstorming y los post-it!

Una vez que hemos identificado un problema real, es hora de inventar soluciones creativas para resolverlo. Es una fase divergente, porque se trata de explorar y proponer conceptos y soluciones sin limitar su viabilidad y su deseabilidad. El objetivo no es encontrar LA solución correcta, sino generar un máximo de pistas de resolución de problemas.

Para conseguirlo, algunos consejos para un brainstorming eficaz:

  • Proponer ideas locas, ¡sin límites!
  • Construir ideas a partir de las de los demás,
  • las de los compañeros de equipo, pero también las de los demás dominios, de otras culturas...
  • No juzgar
  • Para no restringir la creatividad
  • Seguir centrado en el usuario y en el tema
  • para ser eficaz y evitar las sesiones de brainstorming de 2 horas sin ninguna solución pragmática
  • Buscar la cantidad

Prototipo, prueba y proceso iterativo

Es hora de seleccionar entre todas las soluciones producidas previamente, la o las que deseamos probar.

Para probar estas soluciones, es necesario materializarlas con un prototipo. Los primeros prototipos son fáciles, rápidos de realizar, pero permiten tener los primeros comentarios valiosos para validar o invalidar la solución utilizada.

Como el design thinking es un proceso iterativo, es posible en esta fase volver a la fase de ideación y producir o seleccionar nuevas ideas para probar. También es posible perfeccionar el prototipo para hacerlo más completo, más preciso y más realista y probar de nuevo la proposición de solución.

Algunas sugerencias de prototipo:

  • Los carteles de publicidad
  • Las maquetas de sitios web o de aplicaciones interactivas
  • Los guiones y las maquetas
  • Los embalajes de producto

Durante las fases de prueba, no solo se debe probar la deseabilidad de la solución: «¿te gusta?» sino entender por qué esta solución gusta o no y, de esta forma, analizar si responde al problema que le hemos identificado antes.

Algunas herramientas de prueba:

  • Prueba A/B
  • Las entrevistas y cuestionarios
  • Los grupos focales
  • Las tablas de feedback

Si la fase de prueba es concluyente, la solución se transforma en POC - prueba de concepto que ilustra la viabilidad y la deseabilidad de la solución. ¡Es momento de pasar a la fase de producción y ejecución!

Design thinking y agilidad

El Design Thinking no es una metodología de gestión de proyectos, sino un enfoque para imaginar y diseñar soluciones. De esta forma, no entra en la familia de enfoques ágiles (como Scrum, SAFe, XP...) que tienen como objetivo la creación del producto.

Sin embargo, desarrollar el proceso de creación del design thinking no se puede aplicar sin adoptar una postura de agilidad.

Ver los otros cursos

Descubra el curso
Agili’que ?
Quiero comprender qué es la agilidad, sus orígenes, fundamentos y aplicación hoy en día.
Descubra el curso
Agilidad y dirección
La agilidad no está reservada a los equipos de TI, yo quiero descubrir cómo ser un director ágil
Descubra el curso
Empower'me
Antes de hacer ágil, hay que serlo primero. Quiero fortalecer mi espíritu ágil y aprender a conocerme mejor.