Buscar en Gazafatonario IT

miércoles, diciembre 16, 2020

Scrum: cambió la guía ¿y ahora qué hago?


Se ha hablado mucho de los cambios en la guía de Scrum 2020. Pero ¿los hemos entendido? ¿Y qué sucede con lo que no cambió? ¡Scrum sigue siendo Scrum! ¿Por qué causaron tanto revuelo los tales cambios si es a todas luces evidente que la mala práctica de Scrum abunda en la región? ¿Ya leíste la guía completa y no solo el log de cambios que aparece al final de la versión en español?

¿Estás preparado para una conversación seria y profunda sobre Scrum? ¿Sobre los muy comentados, pero poco entendidos cambios propuestos este 2020? Lee la guía (toma menos de una hora hacerlo), anota tus inquietudes sobre la misma y acompáñanos en la última sesión de este año 2020 atípico. Hablaremos de Scrum, de lo que no cambió y no has terminado de entender, de lo que cambió y que te llevará mucho tiempo comprender. Te daremos pistas sobre cómo abordar tus próximas iniciativas ágiles con Scrum y prácticas relacionadas.

Es tu oportunidad de empezar el 2021 con una nueva y mejor visión sobre el marco de trabajo más ampliamente usado por los practicantes ágiles en todo el mundo. Invita a tus amigos y colegas, trae tu natilla y buñuelo navideño o lo que acostumbres compartir en navidad, y prepárate para un gran coloquio.

El 16 de diciembre nos reunimos en la Comunidad Ágiles Colombia a hablar un poco del tema, acompañado como siempre de mi gran amigo Jorge Abad. Grandes conversaciones.

Puedes ver y descargar la presentación con los aspectos más relevantes de esas conversaciones aquí:



Puedes ver el video de la sesión en Ágiles Colombia el 16 de diciembre de 2020, aquí:

domingo, noviembre 22, 2020

Ágiles 2020: o del menguado interés por el desarrollo de software en los eventos ágiles

Temas de interés en Ágiles 2020
Imagen tomada de las redes sociales.

Hace poco se llevó a cabo la más reciente edición de Ágiles Latinoamérica, Ágiles 2020. Iba a ser en Uruguay, quizás en Montevideo. Pero, por razones ampliamente conocidas o imaginadas por todos, se realizó de manera virtual. Como siempre, un evento que convoca a toda la Comunidad ágil de la región, incluso de Europa. Por ejemplo, en la charla que facilitara con mi gran amigo Jorge Abad sobre “de qué hablamos cuando hablamos de historias de usuario” había personas de España. La sorpresa es que allá eran las 2 de la madrugada del día siguiente.

A estas alturas del año, con quizás algunos miles de horas más “frente a la pantalla” que en años anteriores debido a la situación mundial, el entusiasmo de algunos no era el mismo. Sin embargo, hicimos lo posible por llegar a la cita y por cumplir con quienes apoyan el evento, con quienes lo organizaron con corazón y con pasión. A todos ellos, muchas gracias.

Pero no quiero referirme a la organización, a las vicisitudes del evento o a las sesiones, sino a su contenido. Específicamente a las categorías de contenido que hubo en el encuentro. El llamado de trabajos a presentar se hizo clasificado en cinco temas o “tracks”:

  • Producto y clientes
  • Liderazgo y cultura
  • Equipos y coaching
  • Software crafters
  • Organizaciones ágiles

Y durante la apertura se hizo una encuesta rápida sobre cuáles eran los intereses de los asistentes. Los resultados están en la imagen superior (lo siento, no pude conseguir una mejor resolución). El hecho es que desde ese mismo momento y aún después del evento llamó a muchos la atención de que el tema “técnico” no fuera del interés general (hablo de la categoría de Software crafters). El resultado muestra un interés de menos del 25 %, con una muestra representativa de 209 personas que seleccionaban sus preferencias de manera ordenada, de mayor a menor predilección. Y una primera cosa que debo aclarar es que esta es la preferencia de los asistentes, de hecho, así nos gusta hacer las cosas, con lo que les interesa a las personas “hoy”, no con lo que alguien más piensa o presume que le puede servir o concernir.

Pues bien, para aquellos que piensan y sienten que esto es un contrasentido, que se está perdiendo el interés por lo “técnico”, que las personas que tenemos responsabilidades o roles como Scrum Master, coaches o mentores ágiles, facilitadores o habilitadores, no estamos interesados o, peor aún, no sabemos de lo técnico, y que todo esto es una consecuencia de lo que ha venido pasando en los últimos no solo en el Ágiles Latinoamérica sino en otros eventos de esa misma índole, los invito a reflexionar un poco sobre lo siguiente:

Yo creo que tenemos que mirar el contexto. Desde mi punto de vista esto quiere decir que el pensamiento ágil se está llevando a todos los rincones de la organización y que ha salido de una vez por todas y para siempre de las áreas de tecnología, sobre todo de las de desarrollo de software.

Es que pensar que los Scrum Masters deben saber de software es decir que solo podemos usar Scrum para hacer desarrollo de software, cuando, de hecho, hace muchos años hemos pasado esa frontera. Scrum se usa hoy en muchos contextos fuera del desarrollo de software y fuera de lo “técnico” (considerando “técnico” el software), porque cada área tiene su “técnico”. Por ejemplo, si son equipos de Talento Humano, de Operaciones, de Logística, de Mercadeo, de Ventas, incluso de la alta gerencia de la empresa, los Scrum Masters no tienen porqué saber de desarrollo de software.

Si uso Scrum o cualquier otra práctica ágil para crear un hospital, para desarrollar un producto o servicio que no tenga nada que ver con software, para investigación y desarrollo, para enseñar (incluso para aprender), para una empresa de preparación de matrimonios, para abrir y gestionar una cafetería o un restaurante o un bar, para llevar a la cúspide a un equipo deportivo, en fin, para cualquier otra cosa que no sea software, entonces necesitamos otro tipo de agentes de cambio, de facilitadores o habilitadores ágiles, de Scrum Masters, de personas que hagan el trabajo a “lo ágil”.

Quizás eso es lo que quieren decir esos números. Ya abordaremos el tema de si, cuando se trata de desarrollo de software, los Scrum Masters deben saber de software o no, yo pienso que sí. Pero eso es algo muy distinto a lo que estamos hablando aquí.

Debemos entender de una vez por todas y para siempre que la agilidad y Scrum y Kanban y todas las demás prácticas que usamos hoy, no las usamos solo para hacer software. ¿Tú que piensas? Por favor, déjamelo saber en el foro.

¡Aunque sea cuales fueren tus pensamientos, espero verte en #Agiles2021 en Panamá!


Coletilla:

Hace algunos días se publicó la nueva versión de la guía de Scrum, asunto que generó mucho interés entre la comunidad de practicantes ágiles en todo el mundo. Sobre el tema que abordé en este artículo, tengo que referirme a la declaración inicial que hacen los autores de la guía y cocreadores de Scrum, Sutherland y Schwaber. Explícitamente dicen al inicio:

Nos sentimos honrados de ver que Scrum está siendo adoptado en muchos dominios que tienen un trabajo esencialmente complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces”.

Es definitivo, hace mucho dejamos de usar Scrum solo para desarrollo de software y las áreas de la empresa fuera de Tecnología son muchas más. Quizás a ello se deba el interés creciente en otros temas ágiles.


sábado, noviembre 21, 2020

Un mejor Scrum o cómo mejorar tu práctica ágil para entregar resultados asombrosos

 

Estoy comprometido con mejorar la práctica de Scrum en las organizaciones y comunidades que acompaño y me he convencido de que todos los equipos, sin importar su estado de desarrollo, pueden optimizar su capacidad de inspeccionar y adaptarse para hacer mejor las cosas.

En mi continuo trasegar por las organizaciones que usan Scrum o intentan hacerlo me he encontrado con manifiestos desordenes en ese ámbito: desde el uso de un Scrum fundamentalista o Scrumdamentalismo, ese que raya en lo sectario, pasando por el-mismo-Scrum-para-todo-el-mundo, sin dejar atrás el Cascrumcada o “Scrum-cascada”, el Scrum mecánico, apenas para un apocalipsis zombi, o el extremista “Scrum-solo-para-mí” porque mi organización es única en el mundo, hasta el muy común en las empresas que apenas comienzan, el Scrum-sin-terminar, con el que todavía están extendiendo el Sprint, usan el tiempo de la retrospectiva para terminar de probar y no la hacen o simplemente no hay entrega de incremento probado y funcionando la mayoría de las veces.

Al enfrentar estas alteraciones he encontrado muy útil determinar no solo el nivel de desarrollo de los equipos sino el estado general de la organización en materia de pensamiento lean-ágil, estructura y cultura organizacional, identidad de los equipos, trabajo colaborativo y qué tanto está arraigado el mejoramiento continuo en la forma de hacer las cosas de la empresa, para así tratar de curar no solo los síntomas sino las causas raíz de estas disfunciones y empezar a entregar mejores resultados, cumpliendo así con la promesa ágil.

De estos asuntos trata esta presentación que hice en el Regional Scrum Gathering México 2020.

Puedes ver y descargar la presentación aquí.

martes, noviembre 10, 2020

De qué hablamos cuando hablamos de Historias de Usuario

Las historias de usuario son instrumentos de comunicación social que guían la creación y el desarrollo de producto.

En la práctica, podemos representar muchas cosas de un producto o servicio específico como historias de usuario, o todas. Pero hay algunas cosas que definitivamente no son historias de usuario y estamos cayendo en el infame síndrome de que "cuando somos martillo, todo lo vemos como un clavo". Es decir, queremos maltratar cualquier cosa que necesitamos hasta hacerlas parecer como una historia de usuario.

En esta presentación breve y conversatorio, hablaremos precisamente de esto y más alrededor de las historias de usuario. Y, de manera colaborativa con la audiencia, trataremos de encontrar una respuesta a la pregunta "¿de qué hablamos cuando hablamos de Historias de Usuario?"

Puedes ver y descargar la presentación que hicimos en #Agiles2020 aquí:

Actualización 20210405: Puedes ver y descargar la presentación, 2da edición, revisada, no corregida y aumentada, aquí:



lunes, octubre 26, 2020

Mitos y verdades ágiles

 


Mitos, Monstruos, Leyendas urbanas y otros desvaríos de Ágil y de Scrum

Los mitos son una parte esencial de toda cultura. Y la cultura ágil no es una excepción. De hecho, los mitos sobre agilidad y sobre marcos de trabajo como Scrum son una de las razones de las tantas malas prácticas en las que incurren las personas, equipos y organizaciones que intentan hacer las cosas de la manera ágil. En esta sesión hablaremos un poco de las “invenciones” más comunes cuando de pensamiento ágil y Scrum se trata, y de cómo podemos despojarnos de estas aprehensiones.

Estas aprehensiones tienen su origen en la falta de conocimiento teórico-práctico sobre algo específico, en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes practicamos el desarrollo de software. Lo que haré a continuación es mencionar brevemente algunos de estos arquetipos quiméricos que pululan en el universo de los métodos ágiles en general y de Scrum en particular.

Puedes ver y descargar la presentación aquí.



Esta presentación se basa en un artículo de 2013 que puedes encontrar en:


miércoles, octubre 21, 2020

Historias de usuario para colaborar en entornos complejos

 Uno de los pilares fuertes de la agilidad es la Colaboración. Y las historias de usuario se constituyen en una herramienta de primera categoría para hacer un trabajo colaborativo de manera efectiva. Son un medio vinculante entre los usuarios o consumidores finales, los interesados del negocio, sus representantes tipo Dueños de Producto y los equipos de desarrollo de producto.


Estas y otras ideas, en la presentación que puedes ver y descargar aquí.



viernes, octubre 09, 2020

Apuntes sobre transformaciones ágiles: lo bueno, lo malo y lo feo

 

Prefacio

Aunque no es requerido, antes de pasar a estos nuevos apuntes, los invito a leer mis dos apuntes anteriores:

Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html

Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto

http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

Ahora así, vamos con…

Lo bueno, lo malo y lo feo

Las organizaciones quieren y siguen avanzando en ese camino perenne que es la agilidad. Eso es bueno. Lo malo es que siguen aferradas a las formas de pensar y de gestionar tradicionales que las condujeron hasta este momento de su evolución. Lo feo es que no están dispuestas a sacrificar el statu quo en pro de ganar más kilometraje ágil.

Lo bueno es que el movimiento ágil sigue ganando amigos incondicionales, cada vez más individuos, equipos y empresas quieren incorporar el pensamiento ágil y lean en su quehacer. Pero las personas y las organizaciones se están perdiendo de crear su propia experiencia ágil debido al fanatismo por copiar a priori “modelos” de otras organizacionesSpotifys”. La “celulitis” empresarial llegó para quedarse y los amantes de las tribus y los escuadrones pululan a tutiplén.

No tiene nada de malo en sí mismo, muchos procesos de innovación y de cambio tienen sus orígenes en la copia de formas y modelos existentes a los que se les adicionan atributos disruptivos o de avanzada. Lo malo es no saber por qué realizan la copia, más allá del ya bien conocido “es que el vecino es ágil”, “es que nos dijeron que adoptáramos tal o cual referencia”.

Lo feo es no ir a la causa raíz de por qué queremos la forma ágil de hacer las cosas, lo feo es no darse la oportunidad de crecer orgánicamente sino ir directamente a lo de “escalado” ágil con marcos de trabajo donde la estructura organizacional actual se vea representada con pocos o ningún cambio en los procesos existentes.

Los agentes de cambio estamos en la obligación de guiar a las personas y sus equipos a lo largo de ese camino ágil, es necesario que los ayudemos a cambiar las preguntas, más allá de darles las respuestas que quieren a las cuestiones vigentes. También estamos allí para establecer metas incómodas e incluso hacer otras preguntas difíciles, cuya indagación al interior de las organizaciones hará posible que emerjan las disfunciones existentes. Sin embargo, es importante dejar en claro que la experiencia no nos hace infalibles... ¡excepto quizás en esta afirmación!

Sobre Liderazgo

Lo bueno es que queremos un nuevo estilo de liderazgo en las empresas y en los equipos. Lo malo es que queremos que los líderes sean unos cuantos, preseleccionados, sometidos a un proceso de descarte y finalmente seleccionados vía evaluaciones sucesivas de personalidad, actitudes y habilidades individuales, a imagen y semejanza de modelos propietarios de otras compañías disímiles con la nuestra. Lo feo es que no nos estamos dando la oportunidad de cultivar a los líderes dentro de la organización y darnos ese lujo sin igual de verlos crecer y de afianzarse como mentores y como fuentes de inspiración para los demás.

Los líderes son todas las personas que puedan transformar su contexto o generar nuevos y mejores espacios para sus equipos. En los entornos de turbulencia que circundan a las empresas en este nuevo milenio, necesitamos y queremos personas que exhiban atributos de liderazgo:

  • Servicial
  • Basado en valores
  • Para la complejidad (VUCA)
  • Para proporcionar foco en la entrega de valor
  • Para la autoorganización, fomento de la colaboración y equipos multifuncionales
  • Para crear una organización de aprendizaje, basada en la experimentación
  • Para el fomento de entornos seguros para fallar
  • Para gestionar el sistema, no las personas

Sobre las prácticas ágiles


Lo bueno es que las empresas quieren llegar a la práctica de la agilidad mediante el uso inmediato de procesos y herramientas. Lo malo es que no quieren tener las conversaciones escabrosas y comprometedoras que son necesarias durante el proceso de transformación, para fundar pilares como la colaboración, entrega, reflexión y mejora continua inherentes al pensamiento ágil y lean que todos deseamos interiorizar.

Lo feo es que prefieren enmascarar las prácticas actuales, añejas en carpetas celosamente custodiadas por los guardianes de los procesos organizacionales, con nombres apropiados para la social media que permiten a la gestión tradicional aparecer en los titulares de la agile socialite con títulos y niveles de madurez en vez de sembrar actitudes y cosechar una mentalidad basada en valores y definida por principios.

Al hacer esto último, lograremos entender de una vez por todas y para siempre que los procesos metodológicos normalmente tienen una entrada, o un número reducido de entradas, actúan sobre esas entradas y entregan un resultado, aunque este no sea de valor. Esa es la intención de una metodología.

Mientras tanto, los marcos de trabajo (clasificados como) ágiles, no prescriben entradas específicas a los procesos, solo proporcionan guías o marcos de actuación ante un impulso y se enfocan, o enfocan a sus practicantes, en entregar resultados de valor, no resultados “intermedios” o salidas de actividades particulares del proceso. Scrum es buen ejemplo que salta a la vista. Estos marcos de trabajo, además, nos permiten poner de manifiesto esa mentalidad basada en valores y definida por principios con un gran número de prácticas y lineamientos.

Además, en el trabajo que hacemos no es posible determinar con anticipación qué acciones resultarán en qué reacciones. Es decir, no podemos prever cuál será el resultado. Más aún, no podemos predecir el futuro. ¡Perentorio!

Por ello preferimos correr experimentos para analizar si estos nos mueven en la dirección correcta, es decir, sondeamos, detectamos y respondemos. En otras palabras, recibimos retroalimentación del entorno (luego de la Entrega de valor) y reflexionamos basados en evidencias, en datos (inspección y adaptación).

Reflexión

Finalmente, quiero dejarlos con esta cavilación, nacida de mi observación durante esta difícil etapa que atraviesa la humanidad y, por ende, las organizaciones del mundo entero: con el aislamiento obligatorio y la dispersión a la que fuimos sometidos este 2020, las empresas "multiplicaron" su fuerza laboral. ¿Cuánto daño nos está haciendo a las personas y las empresas el cada vez más frecuente "estoy en 2 reuniones porque me necesitan"?

Déjamelo saber en el foro.


martes, septiembre 29, 2020

Entiende el MVP (Producto Mínimo Viable) y por qué prefiero Producto que se pueda probar, utilizar y adorar más temprano

Por Henrik Kniberg. Publicado el 2016-01-25 – 12:14.

Hace un par de años dibujé esta imagen y comencé a usarla en varias presentaciones sobre desarrollo ágil y lean:

¡Desde entonces el dibujo se ha vuelto viral! Aparece en todas partes, en artículos y presentaciones, incluso en un libro ("User Story Mapping" de Jeff Patton, una lectura excelente por cierto). Muchos me dicen que el dibujo realmente captura la esencia del desarrollo iterativo e incremental, la puesta en marcha ajustada, el MVP (producto mínimo viable) y demás. Sin embargo, algunos lo malinterpretan, lo cual es bastante natural cuando sacas una foto de su contexto original. Algunos lo critican por simplificar demasiado las cosas, lo cual es cierto. La imagen es una metáfora. No se trata del desarrollo real de un automóvil, se trata del desarrollo de un producto en general, utilizando un automóvil como metáfora.

De todos modos, con todo este rumor, pensé que era hora de explicar el pensamiento detrás de esto.

Primer ejemplo: no así

La fila superior ilustra un concepto erróneo común sobre el desarrollo iterativo e incremental de productos (también conocido como Ágil).

Muchos proyectos fracasan gravemente porque realizan una entrega tipo Big Bang (construya la cosa hasta que esté 100% terminada y entregue al final). Perdí la cuenta de la cantidad de proyectos fallidos que vi debido a esto (ve más adelante para ver algunos ejemplos). Sin embargo, cuando Ágil se presenta como una alternativa, las personas a veces se resisten a la idea de entregar un producto sin terminar, ¿quién quiere la mitad de un automóvil? Imagina esto:

“Aquí señor, aquí está nuestra primera versión, un neumático delantero. ¿Qué piensa?"

El cliente dice "¿Por qué diablos me entregas un neumático? ¡Pedí un COCHE! ¿Qué se supone que debo hacer con esto?"

(Por cierto, estoy usando el término "cliente" aquí como un término genérico para representar a personas como gerentes de productos, dueños de productos y usuarios pioneros en la adopción).

Con cada entrega, el producto está más cerca de estar terminado, pero el cliente todavía está enojado porque en realidad no puede usar el producto. Todavía es un auto parcial.

Y finalmente, cuando el producto está terminado, el cliente dice “¡Gracias! ¡Finalmente! ¿Por qué no entregaste esto en primer lugar y te saltaste todas las demás entregas inútiles?”.

En este ejemplo, el cliente está contento con el producto final, porque es lo que pidió. En realidad, eso no suele ser cierto. Ha pasado mucho tiempo sin ninguna prueba de usuario real, por lo que es muy probable que el producto esté plagado de fallas de diseño basadas en suposiciones incorrectas sobre lo que la gente necesita. Entonces esa carita sonriente al final es bastante idealista.

De todos modos, la primera fila representa “ágil bastardo”. Técnicamente, puede ser una entrega incremental e iterativa, pero la ausencia de un ciclo de retroalimentación real lo hace muy arriesgado, y definitivamente no es ágil.

De ahí el título "No así".

Segundo ejemplo: ¡así!

Ahora para la segunda fila.

Aquí adoptamos un enfoque muy diferente. Comenzamos con el mismo contexto: el cliente pidió un automóvil. Pero esta vez no solo construimos un automóvil. En su lugar, nos centramos en la necesidad subyacente que el cliente quiere que se satisfaga. Resulta que su necesidad subyacente es "Necesito ir de A a B más rápido", y el Carro es solo una posible solución para eso. Recuerda, el automóvil es solo una metáfora, piensa en cualquier tipo de situación de desarrollo de productos personalizados.

Entonces, el equipo ofrece lo más pequeño que se les ocurre que hará que el cliente pruebe cosas y nos dé su opinión. Algunos podrían llamarlo MVP (Producto mínimo viable), pero yo prefiero llamarlo Producto Comprobable más Temprano (más sobre esto más adelante).

Llámalo como quieras (algunos incluso llaman a su primer lanzamiento "la versión en patineta" del producto, basándose en esta metáfora...).

Es poco probable que el cliente esté satisfecho con esto porque no está cerca del auto que ordenó. ¡Pero eso está bien! Aquí está el truco: no estamos tratando de hacer feliz al cliente en este momento. Podríamos hacer felices a algunos de los primeros en adoptarlo (o a los pragmáticosque están sufriendo), pero nuestro principal objetivo en este momento es simplemente aprender. Idealmente, el equipo explica esto claramente al cliente con anticipación, para que no se sienta demasiado decepcionado.

Sin embargo, a diferencia de la rueda delantera en el primer escenario, la patineta es en realidad un producto utilizable que ayuda al cliente a pasar de A a B. No es genial, pero es un poquito mejor que nada. Entonces le decimos al cliente "no se preocupe, el proyecto no está terminado, esta fue solo la primera de muchas iteraciones. Seguimos intentando fabricar un coche, pero mientras tanto, intente esto y envíenos sus comentarios”. Piensa en grande, pero entrega en pequeños incrementos funcionalmente viables.

Podríamos aprender algunas cosas realmente sorprendentes. Supongamos que el cliente dice que odia la patineta, le preguntamos por qué y dice "Odio el color". Estamos como "uh... ¿el color? ¿Eso es todo?". Y el cliente dice “¡Sí, hazlo azul! Aparte de eso, ¡está bien!”. ¡Acabas de ahorrar *mucho* dinero sin construir el auto! No es probable, pero ¿quién sabe?

La pregunta clave es "¿Cuál es la forma más barata y rápida en que podemos empezar a aprender?" ¿Podemos entregar algo incluso antes que una patineta? ¿Qué tal un tiquete de autobús?

¿Ayudará esto a resolver el problema del cliente? Tal vez, tal vez no, pero definitivamente aprenderemos algo al poner esto en manos de usuarios reales. Lean Startup ofrece un gran modelo basado en enumerar sus hipótesis reales sobre los usuarios y luego trabajar sistemáticamente para validarlas o invalidarlas.

No es necesario que pruebes el producto en todos los usuarios y no es necesario crear un producto para probar algo. Probar un prototipo incluso en un solo usuario te enseñará más que nada.

Pero bueno, volvamos al ejemplo de la patineta.

Después de jugar con él en la oficina, el cliente dice: “Está bien, es un poco divertido y me lleva a la máquina de café más rápido. Pero es inestable. Me caigo con demasiada facilidad”.

Así que en la próxima iteración intentamos resolver ese problema, o al menos aprender más sobre él.

¡El cliente ahora puede moverse por la oficina sin caerse!

¿Contento? En realidad, no, todavía quiere ese coche. Pero mientras tanto, en realidad está usando este producto y nos está dando su opinión. Su mayor queja es que es difícil viajar distancias más largas, como entre edificios, debido a las ruedas pequeñas y a la falta de frenos. Entonces, el siguiente lanzamiento, el producto se transforma en algo así como una bicicleta.

Ahora el cliente puede moverse por el campus. ¡Yiihaaa!

Aprendemos algunas cosas en el camino: al cliente le gusta la sensación de aire fresco en su rostro. El cliente está en un campus y el transporte consiste principalmente en desplazarse entre edificios.

La bicicleta puede llegar a ser un producto mucho mejor que el automóvil que se imaginó originalmente. De hecho, mientras probamos este producto, podemos aprender de todos modos que los caminos son demasiado estrechos para un automóvil. ¡Le ahorramos al cliente toneladas de tiempo y dinero, y le dimos un producto mejor en menos tiempo!

Ahora puedes estar pensando "¿pero no deberíamos haberlo sabido ya a través de un análisis inicial del contexto y las necesidades del cliente?" Buen punto. Pero en la mayoría de los escenarios de desarrollo de productos de la vida real que he visto, no importa cuánto análisis inicial hagas, todavía te sorprendes cuando pones la primera versión real en manos de un usuario real y muchas de tus suposiciones resultan estar muy lejos.

Entonces, sí, haz algo de análisis inicial, descubre todo lo que puedas antes de comenzar el desarrollo. Pero no le dediques demasiado tiempo y no confíes demasiado en el análisis; en su lugar, comienza a crear prototipos y a publicar, ahí es cuando ocurre el verdadero aprendizaje.

Como sea, volviendo a la historia. Quizás el cliente quiera más. A veces necesita viajar a otra ciudad y el paseo en bicicleta es demasiado lento y sudoroso. Entonces, en la próxima iteración agregamos un motor.

Este modelo es especialmente adecuado para software, ya que el software es, bueno, Soft. Puedes "transformar" el producto a medida que avanzas, a diferencia del hardware en el que esencialmente debes reconstruir cada vez. Sin embargo, incluso en proyectos de hardware, la entrega de prototipos tiene un gran beneficio para observar y aprender de cómo el cliente usa su producto. Es solo que las iteraciones tienden a ser un poco más largas (meses en lugar de semanas). Incluso las empresas de automóviles reales como Toyota y Tesla hacen muchos prototipos (bocetos, modelos 3D, modelos de arcilla a gran escala, etc.) antes de desarrollar un nuevo modelo de automóvil.

¿Y ahora qué? Una vez más, tal vez el cliente esté contento con la motocicleta. Podríamos finalizar el proyecto antes de lo planeado. La mayoría de los productos están plagados de complejidad y características que nadie usa. El enfoque iterativo es realmente una forma de entregar menos o encontrar la forma más sencilla y económica de resolver el problema del cliente. Minimiza la distancia a Impresionante. Muy zen.

O, nuevamente, el cliente puede optar por continuar, con o sin modificaciones a los requisitos. De hecho, podemos terminar con exactamente el mismo automóvil que se imaginó originalmente. Sin embargo, es mucho más probable que obtengamos conocimientos vitales en el camino y terminemos con algo ligeramente diferente. Me gusta esto:

¡El cliente está encantado! ¿Por qué? Porque en el camino aprendimos que aprecia el aire fresco en su rostro, así que terminamos con un descapotable. Después de todo, consiguió un coche, ¡pero mejor de lo planeado originalmente!

Así que retrocedamos un paso.

¿Cuál es tu patineta?

El escenario principal (entregar una llanta delantera) apesta porque seguimos entregando cosas que el cliente no puede usar en absoluto. Si sabes lo que estás haciendo (tu producto tiene muy poca complejidad y riesgo, tal vez hayas construido ese tipo de cosas cientos de veces antes), entonces sigue adelante y haz una única entrega tipo “big bang”. Construye la cosa y entrégala cuando esté lista.

Sin embargo, la mayoría de los esfuerzos de desarrollo de productos que he visto son demasiado complejos y arriesgados para eso, y el enfoque del Big Bang con demasiada frecuencia conduce a fallas enormes y costosas. Entonces, la pregunta clave es ¿Cuál es tu patineta?

En el desarrollo de productos, una de las primeras cosas que debes hacer (después de describir qué problema estás tratando de resolver para quién) es identificar su equivalente en patineta. Piensa en la patineta como una metáfora de lo más pequeño que puedes poner en manos de usuarios reales y obtén retroalimentación real. O usa un "boleto de autobús" si esa metáfora funciona mejor.

Esto te dará el circuito de retroalimentación vitalmente necesario y te dará a ti y al cliente el control sobre el proyecto; puedes aprender y hacer cambios, en lugar de simplemente seguir el plan y esperar lo mejor.

Veamos algunos ejemplos de la vida real.

Ejemplo 1: reproductor de música Spotify

“Con más de 75 millones de usuarios, es difícil recordar un momento sin Spotify. Pero hubo una época en la que todos estábamos reflexionando sobre los pasillos de Target en busca de nuevos CD. Un momento de nuestras vidas en el que todos nos convertimos en ladrones en Napster. Una época en la que iTunes nos obligaba a comprar canciones por 2 dólares la pieza. Y luego vino Spotify". –Tech Crunch.

Spotify es un producto bastante elegante ahora. Pero no empezó de esa manera. Tuve la suerte de estar involucrado muy temprano en este viaje increíble (y todavía lo estoy).

Como startup en 2006, Spotify se fundó sobre algunas suposiciones clave: que la gente está feliz de transmitir (en lugar de poseer) música, que los sellos discográficos y los artistas están dispuestos a permitir que la gente lo haga legalmente y que la transmisión rápida y estable es técnicamente factible. Recuerda, esto fue en 2006 cuando la transmisión de música (como Real Player) era una experiencia bastante horrible, y la música copiada por piratas era prácticamente la norma. La parte técnica del desafío fue: “¿Es posible crear un cliente que transmita música instantáneamente cuando presionas el botón Reproducir? ¿Es posible deshacerse de esa molesta barra de progreso de 'Buffering'?"

Empezar de a poco no significa que no puedas pensar en grande. Este es uno de los primeros bocetos de lo que tenían en mente:

Pero en lugar de pasar años construyendo todo el producto y luego averiguar si las suposiciones se mantenían, los desarrolladores básicamente se sentaron y piratearon un prototipo técnico, pusieron cualquier música copiada que tuvieran en sus computadoras portátiles y comenzaron a experimentar salvajemente para encontrar formas de hacer que la reproducción fuera rápida y estable. La métrica de conducción fue "¿cuántos milisegundos se necesitan desde que presiono Reproducir hasta que escucho la música?". ¡Debería reproducirse casi instantáneamente y continuar reproduciéndose sin problemas sin tartamudear!

“Pasamos una gran cantidad de tiempo enfocándonos en la latencia, cuando a nadie le importaba, porque estábamos empeñados en hacer que pareciera que tenías toda la música del mundo en tu disco duro. Obsesionarse con los pequeños detalles a veces puede marcar la diferencia. Eso es lo que creo que es el mayor malentendido sobre el concepto de producto mínimo viable. Esa es la V en el MVP". -Daniel Ek, cofundador y CEO.

Una vez que tenían algo decente, comenzaron a probarse a sí mismos, con su familia y amigos.

La versión inicial no se pudo lanzar a una audiencia más amplia, estaba totalmente sin pulir y básicamente no tenía características excepto la capacidad de encontrar y reproducir algunas canciones codificadas, y no había acuerdo legal o modelo económico. Era su patineta.

Pero descaradamente pusieron la patineta en manos de usuarios reales, – Amigos  y familiares –  y rápidamente obtuvieron las respuestas que necesitaban. Sí, era técnicamente posible. Y sí, a la gente le encantó el producto (o más bien, ¡en lo que el producto podía convertirse!) ¡Las hipótesis fueron validadas! Este prototipo en ejecución ayudó a convencer a los sellos discográficos y a los inversores y, bueno, el resto es historia.

Ejemplo 2: Minecraft

Minecraft es uno de los juegos más exitosos en la historia del desarrollo de juegos, especialmente si se tiene en cuenta el costo de desarrollo. Minecraft es también uno de los ejemplos más extremos de la mentalidad de lanzamiento temprano y frecuente. El primer lanzamiento público se realizó después de solo 6 días de codificación, ¡por un solo hombre! No se podía hacer mucho en la primera versión: era básicamente un paisaje en 3D feo y en bloques donde se podían desenterrar bloques y colocarlos en otro lugar para construir estructuras toscas.

Esa fue la patineta.

Sin embargo, los usuarios estaban muy comprometidos (la mayoría de las comunicaciones entre desarrolladores y usuarios se realizaban a través de Twitter, bastante divertido). Entre los primeros usuarios estábamos mis cuatro hijos y yo. Se realizaron más de cien lanzamientos durante el primer año. El desarrollo de juegos es todo acerca de encontrar la diversión (algunas compañías de juegos con las que he trabajado usan el término "Definición de Diversión" en lugar de "Definición de Terminado"), y la mejor manera de hacerlo es haciendo que personas reales efectivamente jueguen ese juego. – En este caso, se trataba de miles de personas reales que habían pagado para probar la versión de acceso anticipado y, por lo tanto, tenían un incentivo personal para ayudar a mejorar el juego.

Gradualmente, se formó un pequeño equipo de desarrollo alrededor del juego (en realidad, eran 2 chicos), y el juego se convirtió en un gran éxito en todo el mundo. No creo haber conocido a ningún niño en ninguna parte que no jugara Minecraft. Y el año pasado, el juego (bueno, la compañía que se formó alrededor del juego) se vendió a Microsoft por $ 2.5 mil millones. Bastante sorprendente.

Ejemplo 3: Un gran proyecto gubernamental

Alrededor de 2010, la policía sueca lanzó una gran iniciativa para permitir que la policía pasara más tiempo en el campo y menos en la estación: PUST (Polisens Utrednings STöd). Un proyecto fascinante, participé como coach y escribí un libro sobre lo que hicimos y lo que aprendimos (Lean from the Trenches).

La idea era colocar computadoras portátiles en los automóviles y software personalizado para que la policía tuviera acceso a los sistemas que necesitaran en tiempo real, por ejemplo, mientras se interroga a un sospechoso (estábamos en la era anterior a las tabletas).

Habían intentado construir sistemas similares en el pasado y fracasaron estrepitosamente, principalmente debido al pensamiento Big Bang. Me dijeron que uno de sus intentos anteriores tomó 7 años desde el inicio hasta el primer lanzamiento. ¡SIETE AÑOS! Para entonces, por supuesto, todo había cambiado y el proyecto fue un fracaso total. Así que esta vez querían hacerlo de otra manera.

El proyecto de 60 personas (más tarde denominado "PUST Java") tuvo un éxito sorprendente, especialmente por ser un gran proyecto gubernamental (incluso quedó en segundo lugar en los premios CIO "Proyecto del año"). Uno de los principales factores de éxito fue que no intentaron construir todo de una vez, sino que dividieron al elefante en dos dimensiones:

  • Por región. No es necesario que lo publiquemos en TODA Suecia a la vez, podríamos comenzar publicando solo en una región.
  • Por tipo de delito. No es necesario que soportemos TODOS los tipos de delitos inicialmente, podríamos comenzar apoyando solo 1-2 tipos de delitos.

La primera versión, la 1.0, fue su patineta.

Era un sistema pequeño, que soportaba solo un par de tipos de delitos, y se probó sobre el terreno con un puñado de policías en Östergötland (una región de Suecia). Otros tipos de delitos tenían que tratarse a la antigua: conducir hasta la estación y hacer el papeleo. Sabían que eran conejillos de indias y que el producto no estaba ni cerca de estar terminado. Pero estaban felices de probarlo, porque conocían la alternativa. Habían visto qué tipo de sistemas asquerosos surgían de procesos que carecían de retroalimentación temprana de los usuarios, ¡y ahora finalmente tenían la oportunidad de influir en un sistema mientras se estaba construyendo!

Sus comentarios fueron duros y honestos. Muchas de nuestras suposiciones volaron por la ventana, y uno de los grandes dilemas fue qué hacer con todas las especificaciones de casos de uso cuidadosamente elaboradas que se estaban volviendo cada vez menos relevantes a medida que llegaba la retroalimentación de los usuarios reales (esta era una organización con un historial en cascada y el hábito de hacer un extenso análisis al principio de los proyectos).

De todos modos, en pocas palabras, la retroalimentación temprana se canalizó hacia mejoras del producto y, gradualmente, a medida que a los policías de Östergötland les empezó a gustar el producto, pudimos agregar más tipos de delitos y difundirlo a más regiones. Para cuando llegamos al gran lanzamiento (1.4), con el despliegue a nivel nacional y la capacitación de 12000 policías, no estábamos tan preocupados. Habíamos hecho tantos lanzamientos, tantas pruebas de usuarios, que dormimos bien la noche del lanzamiento nacional.

Desafortunadamente, la victoria duró poco. Un proyecto de seguimiento (PUST Siebel) lo estropeó y volvió al pensamiento de cascada, probablemente debido a un viejo hábito. 2 años de análisis y pruebas sin lanzamientos ni pruebas de usuario, seguidos de un lanzamiento espectacular de la "próxima generación" del producto para los 12.000 policías a la vez. Fue un desastre absoluto, y después de medio año de hemorragia cerraron todo. El costo del desarrollo fue de unos 20 millones de euros, pero los estudios internos estiman que el coste para la sociedad sueca (porque la policía se vio perjudicada por el horrible sistema) fue del orden de mil millones de euros.

¡Una forma bastante cara de aprender!

Ejemplo 4: Lego

Actualmente estoy trabajando en Lego y estoy asombrado por su capacidad para ofrecer nuevos éxitos, año tras año, sin falta. Escucho muchas historias interesantes sobre cómo hacen esto, ¡y el tema común es la creación de prototipos y las primeras pruebas de usuario! A menudo veo grupos de niños en la oficina y los diseñadores colaboran con los jardines de infancia, las escuelas y las familias locales para probar sobre el terreno las últimas ideas de productos.

Aquí hay un ejemplo reciente: Nexo Knights (lanzado en enero de 2016):

Cuando comenzaron a explorar este concepto, hicieron prototipos en papel y se los llevaron a los niños pequeños. La primera reacción de los niños fue "oye, ¿quiénes son los malos? ¡No veo quién es bueno y quién es malo!". ¡Ups! Así que los diseñadores siguieron iterando y probando hasta que encontraron un diseño que funcionó con los niños. Apuesto a que incluso tú puedes ver quién es el bueno y quién es el malo en la imagen de arriba...

No estoy seguro de dónde está exactamente la patineta en esta historia, pero entiendes la idea: ¡retroalimentación temprana de usuarios reales! No te limites a diseñar el producto y construirlo todo. ¡Imagínate si hubieran construido el producto basándose en sus supuestos de diseño originales y hubieran aprendido sobre el problema después de entregar miles de cajas a tiendas de todo el mundo!

Lego también tiene su parte de fracasos duramente ganados. Un ejemplo es Lego Universe, un mundo Lego en línea multijugador masivo. Suena divertido, ¿eh? El problema es que se volvieron demasiado ambiciosos y terminaron tratando de construir todo a la perfección antes de lanzarlo al mundo.

Aproximadamente 250 personas trabajaron durante 4-5 años (por el constante cambio de alcance debido al perfeccionismo), y cuando finalmente llegó el lanzamiento, la recepción fue... tibia. El juego terminado fue hermoso, pero no tan divertido como se esperaba, por lo que el producto se cerró después de 2 años.

¡No hubo patineta!

¿Por qué no? Porque las patinetas no son geniales (al menos no si esperas un automóvil), y la cultura de Lego se trata de brindar experiencias increíbles. Si trabajas en los cuarteles generales de Lego en Billund, Dinamarca, pasas por este enorme mural todos los días:

Se traduce aproximadamente como "Solo lo mejor es suficientemente bueno". Ha sido el principio rector de Lego desde que la empresa comenzó hace más de 80 años y les ha ayudado a convertirse en una de las empresas más exitosas del mundo. Pero en este caso se aplicó mal el principio. La búsqueda de la perfección retrasó la retroalimentación vital, lo que significó suposiciones erróneas sobre lo que a los usuarios les gusta y no les gusta. Exactamente lo contrario de Minecraft.

Curiosamente, los equipos de Lego Universe estaban usando Scrum e iterando en gran medida, al igual que los chicos de Minecraft. Pero los comunicados fueron solo internos. Así que lo más probable es que hubiera una patineta y una bicicleta, etc., pero esos productos nunca llegaron a los usuarios reales. No es así como se pretende utilizar Scrum.

Fue una falla costosa, pero Lego aprendió de ella y constantemente mejoran en las primeras pruebas y de la retroalimentación de los usuarios.

Mejora sobre el "MVP"

Y eso (respiración profunda…) me lleva al tema de MVP - Producto Mínimo Viable.

La idea subyacente es genial, pero el término en sí mismo causa mucha confusión y angustia. He conocido a muchos clientes que dicen "De ninguna manera quiero una entrega de MVP – ¡esa es la última entrega que recibiré!" Con demasiada frecuencia, los equipos entregan el llamado Producto Mínimo Viable, y luego rápidamente son llevados al siguiente proyecto, dejando al cliente con un producto sin terminar y con errores. Para algunos clientes, MVP = MRC (Basura Mínima Liberable - Minimum Releasable Crap).

Lo sé, lo sé, esto se reduce a una mala gestión en lugar del término MVP, pero aun así... el término invita a malentendidos. “Mínimo” y “Viable” significan cosas diferentes para diferentes personas y eso causa problemas.

Así que aquí hay una alternativa.

En primer lugar, reemplaza la palabra "Mínimo" por "Temprano". La idea principal detrás del lanzamiento de un MVP es obtener retroalimentación temprana: al entregar un producto mínimo en lugar de un producto completo, podemos obtener la retroalimentación antes.

¡Pocos clientes quieren "mínimo", pero la mayoría de los clientes quieren "temprano"! Entonces ese es nuestro primer cambio:

Mínimo => Más temprano

A continuación, elimina la palabra "Viable", ya que es demasiado vaga. Tu "viable" es mi "horrible". Algunas personas piensan que Viable significa “algo que puedo probar y de lo que puedo obtener comentarios”, otras piensan que significa “algo que el cliente realmente puede usar”. Así que seamos más explícitos y dividámoslo en tres cosas diferentes:

El producto comprobable* más temprano es la patineta o el tiquete de autobús, el primer lanzamiento con el que los clientes pueden hacer algo. Puede que no resuelva su problema, pero genera al menos algún tipo de retroalimentación. Dejamos muy claro que el aprendizaje es el objetivo principal de esta versión y que cualquier valor real para el cliente será una ventaja.

El producto utilizable más temprano es quizás la bicicleta. La primera versión que los primeros usuarios realmente usarán, de buena gana. Está lejos de estar terminado y puede que no sea muy agradable. Pero pone a tus clientes en una mejor posición que antes.


El producto adorable más temprano es quizás la motocicleta. El primer lanzamiento que los clientes adorarán, les contarán a sus amigos y por el que estarán dispuestos a pagar. Todavía hay mucho que mejorar y es posible que acabemos con un descapotable, un avión o algo más. Pero hemos llegado al punto en el que tenemos un producto realmente comercializable.

Consideré agregar un paso anterior, "Producto con retroalimentación más temprana", que es básicamente el prototipo en papel o equivalente que usas para obtener tu primera retroalimentación del cliente. Pero cuatro pasos parecen demasiados, y la palabra retroalimentable... ¡Uf! Sin embargo, ese también es un paso importante. Algunos llamarían a un prototipo de papel el Producto que se puede probar más temprano, pero supongo que eso se reduce a cómo se define “Comprobable”. Consulta la Guía de MVP de Martin para conseguir más información – tiene muchos ejemplos muy concretos de cómo obtener retroalimentación temprana con una inversión mínima.

Por supuesto, la gente todavía puede malinterpretar el Más temprano probable / Usable / Adorable, pero es al menos un paso más explícito que el nebuloso Producto mínimo viable.

Puntos para llevarte

Buen momento para terminar. Nunca pensé que sería tan largo, ¡gracias por quedarte! Conclusiones clave:

  • Evita la entrega Big Bang para el desarrollo de productos complejos e innovadores. Hazlo de manera iterativa e incremental. Eso ya lo sabías. ¿Pero, lo estás haciendo realmente?
  • Empieza por identificar tu patineta, el producto comprobable más temprano. Apunta a las nubes, pero trágate tu orgullo y comienza entregando la patineta.
  • Evita el término MVP. Sé más explícito acerca de lo que realmente estás hablando. El más temprano comprobable / utilizable / adorable es solo un ejemplo, usa los términos que sean menos confusos para tus partes interesadas.

Y recuerda: el dibujo de la patineta / automóvil es solo una metáfora. No lo tomes tan literal: o)

PD: aquí hay una historia divertida sobre cómo mis hijos y yo usamos estos principios para ganar una competencia de sumo de robots: o)

Gracias Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colegas de Crisp, Spotify y Lego, y todos los demás que dieron toneladas de retroalimentación útil.

***

Artículo original de Henrik Kniberg: Making Sense of MVP

***

sábado, septiembre 12, 2020

El Scrum Master y el Scrum Diario

 

Según la guía de Scrum, “los Scrum Diarios mejoran la comunicación, eliminan la necesidad de realizar otras reuniones, identifican impedimentos a remover relativos al desarrollo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo. El Scrum Diario es una reunión clave de inspección y adaptación”.

“El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo”.

Pero el Scrum Master, ni mucho menos el Dueño de Producto ni ninguna otra persona facilitan, conducen o gestionan este evento de Scrum. Es el mismo Equipo de Desarrollo en pleno el encargado de llevarla a cabo, si bien alguien como el Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión.

En el nivel Shu de Scrum, para que haya una reunión Diaria efectiva y se mantenga el espíritu de Scrum y ágil, el Scrum Master enseña al Equipo de Desarrollo a:

1.    Mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos.

2.    Planificar trabajo para las siguientes 24 horas

3.    Optimizar la colaboración y el desempeño del equipo mediante la inspección del progreso en el trabajo diario y haciendo una proyección del trabajo del Sprint a realizar a continuación

4.    Realizar el Scrum Diario a la misma hora y en el mismo lugar todos los días para reducir la complejidad

5.    Usar el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Lista de Pendientes del Sprint.

6.    Entender cómo intenta trabajar diariamente en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint

7.    Establecer la estructura de la reunión

8.    Conducirla de diferentes maneras siempre que se enfoque en el progreso hacia la Meta del Sprint

9.    Usar preguntas para llevar a cabo la reunión, pero también a basarse en discusiones y en otras tácticas para conducirla

10. Volverse a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint

11. Ser los responsables de dirigir el Scrum Diario

12. Adueñarse de la reunión. A tratarla como una reunión interna del equipo, aunque haya otras personas presentes.

Cuando el Equipo de Desarrollo ha interiorizado y practica todos estos comportamientos, para lo cual puede pasar un tiempo considerable que depende más de la actitud y el compromiso de los miembros del equipo, que del acompañamiento, necesario por demás, de un líder como el Scrum Master o un coach ágil, entonces es posible pasar a un nivel Ha de la reunión, pero eso, mi estimado amigo, podrá o podrá no ser motivo de otro trabajo.

Para saber más de la Reunión Diaria, lee también mi artículo de 2014, Compendio Sobre el Scrum Diario, en este mismo Gazafatonario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html

Y te invito a descargar el póster en alta resolución para que lo compartas con tu equipo y con toda tu empresa:




Descarga el póster en alta resolución y en tamaño gigante (100 x 70) para que lo compartas con tu equipo y con toda tu empresa: