Apuntes: 50 ideas rápidas para mejores historias de usuario

Portada: 50 Quick Ideas for User Stories

Fifty Quick Ideas To Improve Your User Stories es una recopilación de consejos prácticos de Gojko Adzic y David Evans para equipos que trabajan de manera iterativa. Una lectura recomendada para crear mejores pilas de producto, con historias útiles y bien priorizadas.

Hemos preparado una selección de estos consejos, destacando algunos de los más versátiles y útiles de conocer para proyectos de todo tipo. Pero no son los únicos. Al final del resumen hemos añadido también el índice original del libro, para dar mejor idea de todos los temas que se abordan.

Apuntes: Lean UX, cómo aplicar los principios Lean a la mejora de la experiencia de usuario

Compartimos nuestros apuntes del libro Lean UX: cómo aplicar los princpios Lean a la mejora de la experiencia de usuario, de  Jeff Gothelf y Josh Seiden. Su estrategia adapta el diseño de UX a entornos de trabajo ágiles, y es por tanto fácil de combinar con scrum.

Utiliza principios de design thinking, desarrollo ágil y el método Lean Startup de Eric Ries para crear de forma colaborativa y en poco tiempo. Su lectura puede resultar útil no sólo a diseñadores, sino también a gestores y desarrolladores que ya tengan al menos un conocimiento básico de agilidad.

En la última página se incluye un esquema con una posible adaptación de los eventos del proceso de Lean UX a la rutina de un típico marco scrum, con sprints de dos semanas:

Apuntes: Sprint, cómo probar cualquier idea en 5 días

Queremos compartir nuestros apuntes sobre el libro Sprint: El método para resolver problemas y testar nuevas ideas en sólo cinco días, de Jake Knapp, John Zeratsky y Brad Kowitz. En él se explica, en detalle y con ejemplos reales, cómo llevar a cabo un design sprint, uno de los agile inception más válidos para proyectos difíciles.

Se recomienda especialmente en estos casos:

  • Proyectos de alto riesgo, en los que es mejor equivocarse y aprender rápido antes de invertir demasiado.
  • Proyectos para los que se dispone de poco tiempo.
  • Proyectos que han quedado atascados.

En la última página del PDF hay disponible un checklist general con todos los eventos que componen el taller. Se recomienda seguir su orden y duración de forma fiel al menos en los primeros intentos.

Esperamos que este resumen sea útil a la hora de valorar y decidir si aplicar este tipo de taller colaborativo en proyectos propios. En caso de que sí, recomendamos leer el material original para entender bien el funcionamiento de cada parte del taller. El libro también contiene consejos útiles para el desempeño de ciertos roles (facilitador, entrevistador…).

¿Es Agile Coach el trabajo más difícil que existe?

Meme sobre como a veces nos sentimos los coaches ágiles.

Me reí mucho cuando vi este meme de la imagen a la izquierda, sobre todo porque es exactamente así como me siento a veces… y parece que esté en un sótano donde el trabajo del coach ágil no es visible, jajaja.
En conversaciones al respecto hablábamos que quizás el trabajo más difícil sea el de médico, ya que a veces se mueren personas, y eso es muy duro. Luego caímos en la cuenta que la cuestión del post es sobre la dificultad de desempeño y, aunque ser médico es emocionalmente duro, sus intervenciones se basan procesos muy probados y siempre están «arropados» en las decisiones difíciles por un comité médico.
La dificultad en el desempeño de un coach ágil es que lidia con la resistencia al cambio. Como expertos en Agilidad traemos cambios a las rutinas y hábitos de los profesionales, y las personas nos negamos de forma natural, por miedo o dificultad, a realizar algo nuevo o diferente. El ser humano es un animal de hábitos y le agrada tener todo bajo control, en consecuencia las situaciones nuevas pueden generar caos, incertidumbre y descontrol.

Resistencia al cambio – from Torbenrick

Las personas están más dispuestas a cambiar cuando ven que sus líderes están cambiando de forma activa, que estos actúan dando ejemplo de cambio. Hay muchas razones de resistencia por parte de los líderes al cambio organizacional:

  • Miedo a lo nuevo
  • Temor al fracaso
  • La gran inversión económica que representa una transformación ágil
  • Pérdida de dinero, trabajadores, clientes o proveedores.
  • Cambios en los beneficios/bonus que ofrece la organización
  • Desconocimiento o desinformación del porqué se realizan los cambios y sus aspectos positivos y/o negativos

Y ahí estamos los coaches ágiles promoviendo el cambio, nadando a contracorriente, sacando a la gente de su zona de confort en una situación en la que no hay un peligro inminente. Algunos líderes ven en el cambio una oportunidad de mejorar, aprender y superarse, y dan permiso a sus equipos a fallar para aprender. Otros se dejan llevar por sus miedos, o tienen otros intereses, así que no escuchan al coach ágil y toman decisiones o ponen restricciones no alineadas con la Agilidad.
Y esa es la razón por la que coach ágil es uno de trabajos más difíciles que existen, su foco está en aquellos que por ahora son un impedimento para la transformación ágil y no sienten la necesidad de cambiar y liderar el cambio.
Un coach ágil sabe que su propio crecimiento es resultado de facilitar el crecimiento en la entrega de valor de otros. Ser coach ágil es una gran oportunidad para servir a los demás, de hacer trascender más allá del logro de un resultado puntual de una actividad o el cumplimiento de un objetivo. Se nos ponen por delante cada día nuevos y apasionantes retos para mejorar la forma de trabajar de equipos y líderes. En mi experiencia es uno de los trabajos más difíciles que existen y a la vez uno de los trabajos más motivantes y apasionados.


Enlace a la publicación original.

Scrum Level versión 3.2

Scrum Level

Los cambios de esta versión afectan sobre todo a la presentación y redacción de los materiales, con una excepción: Se ha ampliado la explicación del principio 8 de la agilidad operativa (Personas sobre procesos) gracias al feedback de los últimos talleres de Scrum Level, por tratarse de un principio fundamental para la agilidad y de evaluación compleja, que requiere especial atención y detalle.

  1. Cambios formales: 
    1.1. Títulos más breves en algunas secciones.
    1.2. Eliminación de las tablas 5, 8 y 10 por redundancia.
    1.3 Corrección de erratas.
  2. Ampliaciones sobre el principio 8 de la agilidad operativa.

¿Y CÓMO EVALÚO EL GRADO DE AGILIDAD DE UNA ORGANIZACIÓN? (SCRUM LEVEL)

Seguro que existen muchas formas de medir el nivel de madurez o de agilidad en una compañía. Scrum Manager nos ofrece una manera a través de Scrum Level.

Para entender completamente Scrum Level es necesario tener 2 conceptos. El primero es A qué se refiere con Scrum. Casi todo el mundo conoce Scrum, en mayor o menor medida, y el que lo conoce suele tener como referencia la Guía de Scrum.

Sin embargo, antes de que Ken Schwaber presentara Scrum en 1995 en la OOPSLA (Conferencia anual «Object-Oriented Programming»). Nonaka y Takeuchi, en 1986, dieron este nombre a una manera de trabajar «con un ambiente caracterizado por equipos brillantes, autoorganizados y motivados que abordan un desarrollo desde una visión general solapando fases del desarrollo y compartiendo el conocimiento y aprendizaje de forma abierta» (Scrum Level).

Y es la descripción original de Nonaka y Takeuchi a la que se hace referencia cada vez que leemos Scrum en el manual de Scrum Level.

El segundo concepto son los paradigmas culturales definidos por Frederic Laloux en su libro «Reinventando Organizaciones» y de los cuales hago una breve descripción en ¿EN QUE SE PARECEN LOS PARADIGMAS CULTURALES DE FREDERIC LALOUX A LAS CAPAS DE LA TIERRA?

A través de esta clasificación podremos identificar a qué paradigma pertenece una organización y comprender mejor las implicaciones de los posibles cambios que se requieran realizar.

Scrum Level nos permite evaluar la agilidad desde el punto de vista Operativo y Organizativo (denominado Facetas). No todas las organizaciones tienen la capacidad de agilizar estas dos facetas, bien por no disponer de productos que puedan desarrollarse en fases, bien porque la compañía no quiera o no esté preparada para hacer cambios organizativos.

Por lo tanto, para empezar es importante conocer en qué tipo de organización estamos trabajando y el motivo de la transformación:

  • Para una entrega temprana y continua de valor
  • Para potenciar la creación de valor basados en las personas y su motivación
  • Para escalar la agilidad

El tipo de organización en la que estamos trabajando, el motivo de la transformación más el conocimiento que podamos tener del grado de implicación de la dirección nos indicará si podemos evaluar ambas facetas o sólo una de ellas.
Las dos facetas se han dividido en dimensiones que pueden evaluarse por separado, flexibilizando y potenciando las opciones que el evaluador tiene:

  • Faceta Operativa:
    • Dimensión técnica
  • Faceta Organizativa:
    • Dimensión estructural
    • Dimensión cultural

Scrum Level cree que la agilidad de una compañía no viene dada por los métodos que emplea, sino por los principios y valores que aplica. Por tanto, los métodos o frameworks sólo son el vehículo que nos permite llevar un principio o valor a la práctica. En esta línea Scrum Level mide los principios y valores sin entrar en el medio utilizado para su puesta en escena.

Así, cada una de las dimensiones contiene un conjunto de principios o valores que permitirán evaluar el grado de agilidad que la compañía tiene. Pero su evaluación sólo puede llevarse a cabo con la consecución de unas prácticas o comportamientos dentro de la organización o equipos que definirán el grado de aplicación del principio o valor. 

Para la dimensión Técnica evaluaremos los principios y prácticas (Scrum Level v3.1.1 – Página 40):

Para la dimensión Cultural evaluaremos los valores y comportamientos (Scrum Level v3.1.1- Página 66):

Para la dimensión Estructural evaluaremos los valores y comportamientos (Scrum Level v3.1.1 – Página 67):

Cada una de estas prácticas y comportamientos se evaluarán a través de un equipo de personas cuidadosamente seleccionados dónde podamos asegurar recoger la mayor variabilidad de puntos de vista posibles. 

El rango de valores estará entre 0 a 3 con alguna excepción oportunamente explicada en la guía. 

Una vez evaluada cada práctica y comportamiento, serán necesarios hacer un sencillo cálculo (media aritmética) a nivel de principio o valor y después a nivel de dimensión. De esta manera obtendremos el grado de agilidad de cada dimensión de la compañía o área evaluada.

Y después, ¿cómo sabemos dónde tendremos más éxito en los siguientes pasos? Efectivamente, es muy importante buscar una brújula que nos permita saber dónde podríamos tener un mayor grado de éxito en los siguientes pasos.

Para facilitar el camino por donde deberíamos continuar Scrum Level nos da otra herramienta para conocer el grado de soporte que tendremos durante la transformación en cada una de las dimensiones. Esta herramienta tendrá en cuenta:

  • La evaluación que hemos realizado.
  • La situación actual (medidos de 0 a 3):
    • Implicación directiva.
    • Compatibilidad cultural.
    • Los medios
    • Formación y coaching.
  • La predisposición al cambio para cada uno de los puntos de la situación anterior (medido entre el 0 y el 2, dejando el valor 3 a la discreción de un evaluador experto).

Por último, Scrum Level nos proporciona una tabla de riesgo (Scrum Level v3.1. – Página 75), que nos mostrará alertas en función del valor obtenido de la suma de cada punto de la situación actual más la  predisposición al cambio.

Para acabar me gustaría remarcar dos ideas muy importantes:

  1. Una evaluación de Scrum Level ha de realizarse por una persona experta que pueda valorar qué ha de medirse y cuál es la mejor manera de hacerse. Por ejemplo, la medición de una dimensión cultural directa en una compañía Naranja donde la implicación de la dirección y su predisposición al cambio es baja puede resultar bastante peligroso.
  2. La evaluación de Scrum Level está pensada para realizarse sobre organizaciones o partes de ellas donde ya se aplica Scrum. Es decir, no tiene sentido que participe en la evaluación personas que están trabajando con modelos predictivos de gestión de proyectos.

Un saludo

Actualización de la Guía Scrum Master de la versión 3.04 a la 3.05 para unificar términos y criterios

Guía Scrum Master

Para unificar términos en la comunidad scrum hemos actualizado la denominación de «equipo de desarrollo» a «desarrolladores» que ha incorporado la guía editada la semana pasada por Ken Schwaber y Jeff Sutherland, de manera que en la descripción del marco estándar de scrum de nuestra guía de formación: 

  • La denominación anterior «equipo scrum» se mantiene para referirse a equipo formado por los roles del marco: scrum master, product owner y equipo de desarrollo.
  • La denominación anterior «equipo de desarrollo» se ha cambiado a «desarrolladores». El cambio se ha realizado tanto en la descripción del ciclo scrum (pág 27) como en todas las apariciones de la guía en la que la descripción «equipo» o «equipo de desarrollo» pudiera dar lugar a confusión con «equipo scrum».

En cuanto a las consideraciones por la introducción del concepto «objetivo del producto» y los compromisos asociados en los artefactos: pila del producto, pila de sprint y definición de «hecho»:
son conceptos que nuestra formación ya contempla con el concepto de «visión» del propietario de producto y la importancia de compartirla con el equipo de desarrollo (ahora desarrolladores 🙂 así como el papel de ser el referente de alineamiento del equipo. En este sentido, nuestra guía, al cubrir más allá de la descripción del ciclo estándar ya lo trata transmitiendo la importancia de la visión del producto por parte del propietario del producto, cuyo valor debe comprender y compartir todo el equipo y hacia el que se deben alinear los esfuerzos.
Para mejorar la comprensión de los objetivos y compromisos que esto implica en los artefactos: pila del producto, pila del sprint e incremento, se han añadido respectivamente:

  • Pila del producto: El objetivo de la pila del producto es describir el estado que tendrá el producto en el futuro y que dibuja la visión compartida por el equipo para planificar.
  • Pila del sprint: La pila del sprint debe servir para definir y estar alineada con el objetivo del sprint, que marca un hito en el avance hacia la visión del producto.
  • Incremento: El incremento debe cumplir con las medidas de calidad que requiere el producto. La «definición de hecho», debe ser conocida y compartida por todo el equipo, y el incremento no se considera terminado hasta que no se alcanza.

Y por último sobre la preferencia del término de equipos autogestionados frente a autoorganizados que usa en versiones anteriores la guía de  Schwaber y Sutherland:
parece que remarca que el grado de autonomía del equipo scrum debe ser amplio, aunque sin dar mayor concreción. En este punto nuestra formación expone igualmente el concepto de equipos autoorganizados o autogestionados, sin profundizar en la guía de Scrum Master, donde posiblemente exceda el objetivo como enseñanza dirigida a equipos ágiles. En la guía troncal 2 (Scrum Level) al estar dirigida a la agilidad desde la perspectiva de la organización, la exponemos con una concreción más apropiada al tratar el principio de estructura desjerarquizada en la dimensión estructural de la empresa, marcando 4 niveles de autonomía posibles para equipos (equipos dirigidos, equipos autogestionados, equipos autodiseñados y equipos autogobernados).

Guía Scrum Master 3.05: Página de descarga.

Gestionar planes o ideas

Este vídeo ilustra con dos ejemplos la diferencia clave entre gestión predictiva y gestión ágil: la primera gestiona trabajos que tienen plan detallado desde el principio, mientras que la segunda lo va desarrollando al tiempo que lo ejecuta.

Cuando se sabe con detalle cómo debe ser el resultado final, lo más adecuado es programar un plan de acción con todas las tareas necesarias y ejecutarlo tal y como se ha previsto.

Sin embargo cuando se prefiere comenzar desde una idea general y hacerla crecer, analizando su evolución para tomar en cada momento las mejores decisiones, lo mejor comenzar con un esbozo e incrementarlo y mejorarlo de forma continua.

Manual de historias de usuario

Libro Historias de usuario de Scrum Manager

La agilidad da la bienvenida a los cambios durante el desarrollo porque aportan mejoras a la idea previa.

Las historias de usuario son un buen formato para gestionar requisitos en evolución y este manual de Scrum Manager, es sin duda uno de los mejores 😉

Esperamos que os resulte útil y con ese fin lo ponemos a disposición de todos a los que os pueda ayudar.

Los autores.

Scrum no sirve…

Scrum no te sirve si lo que buscas es una metodología para implantar agilidad.

Si quieres una metodología ágil y piensas en scrum… deberías reconsiderar si lo que andas buscando existe, porque la mejor metodología ágil es la «no metodología».
Los equipos y empresas ágiles no lo son por emplear metodologías o prácticas ágiles, sino por trabajar con principios y paradigmas culturales ágiles.

El marco estándar, el denominado scrum oficial no es una meta para alcanzar la agilidad, sino un punto de partida.

Siguiendo el concepto japonés «Shu Ha Ri» que muestra la trayectoria del aprendizaje a través de etapas, desde los primeros pasos o «Shu» hasta la maestría o «Ri«, el marco oficial es la etapa «Shu«. Es lo que denominamos scrum técnico, que sirve para aprender a dar las primeras «pedaladas» ágiles, manteniendo el equilibrio.

De igual forma que el conocimiento del lenguaje y su gramática es el punto de partida para llegar a ser escritor, el conocimiento de prácticas y marcos ágiles, es necesario para quien quiere ser ágil; pero al aprender las técnicas no hay que olvidar que al igual que la literatura no se consigue simplemente por aplicar las reglas gramaticales, la agilidad tampoco se logra sólo por emplear prácticas ágiles.

El marco de scrum técnico es perfecto para empezar, pero no te quedes en él 😉