Buscar en Gazafatonario IT

domingo, junio 18, 2017

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto

La Guía de Scrum define el Refinamiento del Backlog de Producto como:
“El refinamiento de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo”.
Pero ¿qué hay detrás de escena? ¿Cómo luce un buen refinamiento de producto? Hablemos un poco sobre eso.
Sobre el Producto
Primero, me gustaría decir algunas palabras sobre backlogs y cómo logramos que estos sean grandiosos:
Actualmente sabemos que
“La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación”.
Aunque no es un concepto complicado, la noción de backlog de producto (o como se llama en español, la Lista de Producto), no siempre la entendemos completamente.
Roman Pichler y Mike Cohn dicen que un backlog de producto apropiado debería ser DEEP:
Detallado apropiadamente. Los elementos del backlog de producto difieren en su nivel de detalle. Los que se desarrollarán en los próximos sprints deben haber sido lo suficientemente entendidos hasta el punto de que puedan ser completados por el equipo en cada uno de esos sprints. De otro lado, aquellos elementos que no serán construidos durante un tiempo deberían describirse con menos detalles.
Emergente. El backlog de producto es una entidad viva que cambia constantemente y evoluciona a medida que el producto está siendo desarrollado o mantenido. A medida que el Dueño de Producto y el equipo aprenden más acerca del producto y de su entorno, por ejemplo, del mercado y de sus usuarios, adicionan nuevos elementos, eliminan otros y ajustan otros. Emergente es un atributo el cual no solo esperamos que este atributo esté presente en cada backlog, sino que es un indicativo de un backlog de producto sólido y efectivo.
Estimado. Cada elemento del backlog de producto tiene un estimado que corresponde al esfuerzo requerido para desarrollar ese elemento. El Dueño de Producto usa muchas veces este número, entre otras cualidades, para determinar la prioridad del elemento en el backlog de producto.
Priorizado. ¡Ni más faltaba! Todos los elementos el backlog de producto están priorizados (ordenados). Los elementos de mayor valor deben estar en la parte superior y los de menos valor en el fondo. El ordenamiento del backlog de producto determina el orden de entrega de sus elementos. Esta es una de las muchas formas en que un Dueño de Producto maximiza el esfuerzo del equipo y el valor entregado al negocio.
Por experiencia también sé que un buen backlog de producto es:
  • Transparente. Es visible a todos aquellos involucrados en el diseño y desarrollo del producto y a todos los interesados en el producto.
  • Relevante. Los nuevos cambios que se observan mientras se desarrolla el producto se reflejan en el backlog de producto, refinando sus elementos de manera adecuada.
Una vez que hemos entendido estas premisas, estamos preparados para jugar el juego del refinamiento del producto.
Sobre el Refinamiento
El refinamiento establece un entendimiento común entre el Dueño de Producto y los miembros del equipo acerca de los elementos priorizados y su funcionalidad y los desafíos técnicos. También crea más transparencia entre los miembros del equipo Scrum.
Aunque no hay una sola forma de definir el refinamiento del Backlog de Producto genéricamente en Scrum, - no hay ninguna fórmula que garantice el éxito cuando de afinar el backlog se trata – en la práctica hacemos refinamiento cuando enfrentamos:
  • Un backlog de producto muy grande
  • Un elemento de backlog grande
  • La adición de nuevos elementos al backlog de producto
También, cuando eliminamos elementos existentes del backlog de producto lo estamos refinando.
Cualquier elemento del backlog de producto debería refinarse cuando y a medida que conocemos información adicional sobre él.
Deberíamos dar prioridad al refinamiento de elementos del backlog de producto que se van a desarrollar en el siguiente Sprint.
El refinamiento del backlog de producto es o debería ser un proceso continuo conducido por el Dueño de Producto. Este se reúne con los interesados y usuarios para recolectar cualquier información necesaria para el refinamiento. Pero también planea y lleva a cabo reuniones con el equipo para que sus miembros conozcan los elementos nuevos/modificados en el backlog. El Dueño de Producto también debería conducir estas sesiones de refinamiento del backlog de producto.
Para saber más de Refinamiento del Producto puedes leer mi artículo sobre Purga Ágil del Producto.
Sobre el Dueño de Producto
Esta es la razón por la cual, solo a través de una buena sinergia entre el equipo y el dueño de producto, que ellos pueden construir un producto útil y fantástico. Un gran desafío para el dueño de producto es gestionar el flujo de los múltiples requisitos que llegan desde los distintos interesados y lograr que haya consenso entre todos (interesados, usuarios, equipo de desarrollo) sobre los requisitos que proporcionen el mayor valor al negocio.
El resultado de una sesión de refinamiento de producto es un entendimiento común de los elementos del backlog de producto que pueden desarrollarse en el siguiente sprint. ¡Por lo menos!
Un Dueño de Producto extraordinario sabe que si un producto debe ser competitivo en el mercado, entonces este debe cumplir con todos sus atributos requeridos que se hayan definido (las características imprescindibles), pero también con sus atributos de desempeño (las características importantes o que sería bueno que tuviera) y sus atributos interesantes (esas características que tienen valor para el negocio y que sería bueno que el producto tuviera).
Por cosas como esta es que ejercer el rol de Dueño de Producto eficientemente no solamente es vital para desarrollar productos fructíferos con Scrum. También es un proceso de aprendizaje para los individuos que ejecutan el rol y para la organización.
Desde este punto de vista, el rol del Dueño de Producto significa lograr un balance entre el tira y el afloje del desarrollo del producto. No es una tarea simple de llevar a cabo. Construir el producto correcto en el momento correcto es un asunto de mayor interés para el éxito de todo Dueño de Producto. Es lo que se conoce como el “Dilema del Dueño de Producto”.
Cuando un producto exhibe una historia bien construida que es coherente, se convierte en un producto no ordinario. Cuando las partes de este producto no ordinario interactúan, generan resonancia, una mejora de la potencia que hace que un producto sea más grande y más eficaz de lo que la suma de sus partes podría predecir. Esta resonancia incita a respuestas de sus usuarios. Por lo general, son reacciones que hacen que la gente experimente un producto como algo extraordinario, útil y valioso.
Scrum, junto con otro conjunto de prácticas y técnicas ágiles, nos proporciona el marco de trabajo necesario para construir tales productos de valor con las características correctas.
¡Y para eso es que están los Dueños de Producto!
Así que, ¿qué estás haciendo tú para crear esta sinergia y construir productos sorprendentes? Déjamelo saber en la sección de comentarios abajo.

Nota:
Publiqué este artículo en Pulse el 1 de junio de 2017, originalmente en inglés:
On Product Backlog, Backlog Refinement and the Product Owner Role
Para saber más sobre el rol del Dueño de Producto puedes leer mi artículo Guía Supernumeraria para un Dueño de Producto Virtuoso.

miércoles, junio 14, 2017

De las Reuniones de Requisitos - 1 -


Empiezas a construir una solución errónea y a nadie le importa...
¡Solicitas una reunión de requisitos y todo el mundo pierde la cabeza!

jueves, junio 08, 2017

Escalar Para Qué

La pregunta no es o no debería ser ¿cómo escalar Ágil? Más bien es un asunto de ¿por qué escalar Ágil? Pero antes de entrar en materia, quiero recordarles algo que he mencionado en varios escenarios: antes de escalar Ágil como solución, pensemos en ‘desescalar’ el problema.
El asunto con el escalamiento es que se nos está convirtiendo en una cuestión de cuál método usar y no en lo que verdaderamente importa a las Organizaciones: ¿por qué escalar? Debemos ir a la causa raíz, el problema detrás del problema, es quizás una de las pocas vías razonables que tenemos para encontrar una razón de peso para escalar Ágil y tal vez un buen camino a seguir.
Los marcos de trabajo o los métodos de escalamiento proporcionan herramientas que ayudan en el proceso, pero me parece que apenas si nos permiten lograr que los equipos realicen correctamente el trabajo y que lo hagan de manera integrada. Pero hacer correctamente el trabajo correcto es otra cosa.
Cuando empezamos la transformación a o la adopción de Ágil, lo hacemos provistos con el Manifiesto Ágil y quizás Scrum o Kanban, acompañados de algunas otras prácticas y el pensamiento Lean. Tenemos la férrea esperanza de que el área de TI no necesite nada más allá de algunas otras herramientas Ágiles que hoy ya podemos brindar como “paquetes” (BDD, Refactoring, User Story Map, entre otras).
Luego nos damos cuenta que, contrario a lo que sucedía con el enfoque tradicional, el Ágil es un pensamiento que debe tener un lugar en cada uno de los asientos de la empresa y en cada lugar que habitan sus miembros. Entonces, cuando queremos salir fuera de la oficina de TI, hacia el resto de la Organización, nos olvidamos del Manifiesto y nos aprovisionamos con todo tipo de artilugios ‘agilísticos’ como si se tratara de la cruzada definitiva, la última cruzada de los agilistas o algo similar.
Pensamos más en el número de equipos y de personas a escalar que en el Valor y en el número de productos o servicios que debemos desarrollar.
No todas las corporaciones necesitan escalar Ágil. Algunas solo necesitan Ágil para entregar software con Valor de manera temprana y frecuente. No se trata de que tan Ágil soy comparado con mis vecinos, más bien de lo que se trata es de si voy correctamente en el camino Ágil correcto y de lo que debo hacer para mantenerme allí.
En definitiva, lo que tenemos que responder, mientras seguimos encontrando formas mejores de hacer las cosas, tanto por nuestra cuenta como ayudando a otros, es si nuestra Organización o la que estamos acompañando en su camino Ágil ve el tiempo de respuesta como un diferenciador crítico para sus consumidores finales o ante sus competidores.
Pero aun más importante es si queremos escalar la forma cómo pensamos acerca de las personas y sus interacciones o solo la forma de desarrollo de nuevos productos y servicios. ¿Queremos escalar el nivel de motivación y felicidad de nuestros compañeros de trabajo y colegas o solo su productividad y eficiencia? Y si se trata de ambas cosas, ¿lo estamos haciendo? Más aun, ¿lo estamos haciendo de una manera correcta?
Otros porqués incluyen:
  • ¿Qué tan innovador queremos que sea el portafolio de la Organización?
  • ¿Qué tanta incertidumbre hay en nuestros esfuerzos de desarrollo y, por extensión, en nuestro futuro?
  • ¿Queremos innovar o simplemente realizar el mejor mantenimiento posible a lo que hacemos y proporcionamos?
  • La estocástica también juega un papel importante. ¿Qué tan aleatoria es la demanda de nuestra Organización?
Finalmente, ¿estamos planeando o ejecutando ya una metempsicosis organizacional, en el sentido de transformación, a la que podamos sumar la adopción de Ágil a gran escala? ¿O simplemente queremos vender o implantar una marca más por asuntos de moda que por aspectos fundamentados en la ingeniería y en las prácticas de la industria?
¿No será que estamos cayendo una vez más en el uso de un gran número de métodos o marcos de trabajo y sus variantes, con diferencias poco entendidas e incrementados artificialmente y que además carecen de evaluación y validación experimental creíble? Eso ya nos sucedió, de allá venimos, de metodologías y prácticas inmaduras que obstaculizaban gravemente la ingeniería de software, en particular, y el desarrollo y entrega de productos y servicios con Valor, en general.
Otro asunto, riesgoso y de mayor impacto para la Organización, es tratar de escalar sin haber terminado de construir los cimientos o cuando todavía hay disfunciones Ágiles en el nivel más básico. En ese caso, lo único que lograremos escalar serán precisamente los problemas, no las soluciones. Pero este será tema de otro artículo.
Escalemos la entrega de Valor, no solo el método o marco de trabajo que queremos usar.

martes, mayo 30, 2017

De Retrospectivas y de Ratones


O de cómo los Agilistas le ponemos el cascabel al gato

La falta de atención a las acciones de mejoramiento es una de las razones principales por las cuales muchas personas, equipos y organizaciones no ven valor en las retrospectivas*; es uno de los motivos por los cuales en una tras otra de estas ceremonias dejamos entrever el mismo comportamiento apático y hasta errático, es la causa por la cual nos sentimos grandemente desmotivados cuando de regresiones ágiles se trata.
Las acciones de mejoramiento que surgen a raíz de una retrospectiva o de cualquier otro evento durante el sprint no se ejecutan los fines de semana a las 3 de la tarde o el jueves a las 10 de la noche antes de finalizar el sprint actual; tampoco se realizan solo por mencionarlas, como si la lista de acciones se tratara de un pozo de los deseos que el Hada de las Retrospectivas hace realidad cada dos semanas o menos.
Cada una de esas acciones toma tiempo, se trata de un esfuerzo serio para el que quizás no estamos preparados pero que debemos llevar a cabo si queremos mejorar como personas, como equipo, como organización.
Hay diferentes categorías de mejoramiento:
A nivel personal
A nivel de equipo
A nivel de liderazgo
A nivel de organización
Conocer el impacto que tendrá la acción de mejoramiento nos ayuda a saber a dónde ir, qué puertas tocar en la organización, cómo tenemos que proceder.
En ocasiones, las acciones de mejoramiento no se implementan o el objetivo no se alcanza en un solo sprint. Lo importante es que al final de cada iteración haya avances o hayamos logrado metas intermedias. Volveré con esto más adelante en una de mis recomendaciones a continuación.
Recomendaciones
Podemos proponer o establecer un time-box para ejecutar estas acciones de mejoramiento. Es decir, un lapso de tiempo máximo durante el sprint, así como lo hacemos con la planificación, el refinamiento o la misma retrospectiva. Ese tiempo dependerá de si la acción de mejora será ejecutada una sola persona, varias o todo el equipo; también, si depende de alguien más en la organización o de otra área de la misma. En este último caso, alguien del equipo Scrum, no tiene que ser solo el Scrum Master, debería encargarse de gestionar la realización de esas acciones. Lo importante es que en la siguiente retrospectiva mostremos avance medible y verificable de la tarea.
No tratemos de mejorar solo lo que hemos hecho mal o lo que no estamos haciendo. También se puede seguir mejorando lo que estamos haciendo bien o muy bien. ¡No hay límites!
En ese mismo sentido, no abordemos solo los problemas que enfrentamos durante el sprint, analicemos también lo que hemos hecho bien y por qué, para seguir haciéndolo, para convertirlo en algo común y corriente en nuestro trabajo, recordable y repetible.
No convirtamos la retrospectiva en una sesión de autoflagelación. El “mea culpa” por humildad o por sacrificio no funciona. Si esto se repite es porque no estamos creando escenarios seguros para fallar y aprender y entonces allí hay una acción de mejoramiento que realizar.
No dejemos todo en manos de la Organización. En principio, las acciones de mejoramiento son nuestra responsabilidad. Si más adelante, después de implementarlas, logramos que la organización se beneficie con ellas, bienvenidas. Las tareas que se salgan de nuestras manos o de nuestro control, ya sea por presupuesto, por tiempo o por complejidad o por cualquier otra razón, entreguémoslas a ojos cerrados. El Scrum Master o el Dueño de Producto nos pueden servir de puente con el resto de la organización para que estas se implementen en algún momento. En cualquier caso, no dejemos que estás bloqueen nuestro trabajo.
Aunque el mejoramiento no es el foco principal de lo que hacemos, tampoco debería ser lo más complejo, lo que más estrese el esfuerzo de las personas o del equipo. Concentrémonos en acciones pequeñas pero de alto impacto, o realicemos su implementación gradualmente. Por ejemplo, si queremos mejorar nuestra puntualidad porque estamos llegando tarde, no intentemos lograrlo del todo en un sprint o menos. Más, si esa no es nuestra cultura. En cambio, hagámoslo incrementalmente. ¿Qué tal 5 minutos la primera semana o el primer sprint? ¿Lo logramos? Bueno, ahora otros 10 minutos. ¿Meta alcanzada? Ahora sí, últimos 15 minutos. ¿Ya estamos llegando a tiempo? Sigámoslo haciendo de esta manera para siempre, motivados, con energía, ¡con la mente en el juego!
Toyota Kata viene a mi mente, pero hablaremos de ello en otra ocasión. Sin embargo, y a propósito de esto, las acciones de mejoramiento no tienen por qué ser una lista plana, a veces sin voluntad, sin vida. Pensemos en experimentos. Propongamos hipótesis. Hagámoslo divertido. Después de todo, esto debe ser lo “fácil” de nuestro trabajo. Lo otro, lo verdaderamente esencial, el desarrollo del producto/servicio en medio de la incertidumbre y hasta del caos, eso sí que debe estresarnos. Busquemos en la realización de estos experimentos, en la prueba de estas hipótesis, ese descanso que nuestra mente necesita para lograr ese otro objetivo cardinal que nos ocupa.
¿Y qué sucede, qué hacemos cuando la implementación de una acción de mejoramiento nos está causando problemas? ¿Desechamos esa mejora? No. Cambiamos la estrategia, solicitamos ayuda, ¡está bien pedir ayuda!
Trabajemos en equipo: el todo es mayor que la suma de las partes y es una de las razones por las cuales, los equipos Ágiles, como los gatos, siempre caemos de pie.
Finalmente, no esperemos al término del sprint para revisar y conocer si nuestras acciones de mejoramiento se han implementado o están en camino. Seamos proactivos: ¿en qué vamos? ¿Cómo podemos ayudar? ¿Hay algo que pueda hacer para que logremos este objetivo? Son algunas de las preguntas que nos podemos hacer como equipo, quizás durante la Reunión Diaria o en cualquier otro momento del día, mientras estiramos las piernas o nos tomamos un café. O simplemente digamos, “¡hoy es un buen día para mejorar!”
Y tú, ¿qué estás haciendo para mejorar? Déjamelo saber en el foro.

-----
*Adenda
Siempre recomiendo a los Scrum Masters que acompaño o a cualquier miembro del equipo que recuerde durante las primeras de cambio la Directiva Primaria de las Retrospectivas, sobre todo las primeras veces que se realiza un ritual de esta naturaleza, cuando el equipo es nuevo o cuando detectamos en los asistentes cierto temor a participar activamente de las mismas. Puedes descargarla de:
Ahora bien, para saber más de retrospectivas, puedes leer este artículo de mi gran amigo Leonardo Agudelo, http://www.twitter.com/sweepnoise, que publicamos en la página de la Comunidad Ágiles Colombia:
Y luego te recomiendo ampliamente las Lecciones Aprendidas de mi otro gran amigo Jorge Abad, http://twitter.com/jorge_abad, con quien he tenido la oportunidad de hablar extensamente sobre el asunto mientras ayudamos a terceros a implementar todas estas formas mejores de hacer las cosas:
Y un recurso indispensable para realizar retrospectivas fantásticas, es Retromat, de Corinna Baldauf, una suerte de elementos en los cuales inspirarnos y con los cuales podemos planear nuestras próximas retrospectivas, y cuya traducción al español hace ya algunos años fue conducida por Thomas Wallet, quien se define a sí mismo como un enfermo de las retrospectivas, acompañado de Pedro Serrano y un grupo de entusiastas de la Comunidad Ágil Latinoamericana:

Créditos de la portada: Designed by Peoplecreations / Freepik

lunes, mayo 29, 2017

Directiva Primaria de las Retrospectivas



Independientemente de lo que descubramos, entendemos y creemos sinceramente que todo el mundo hizo el mejor trabajo posible, dado lo que sabía en ese momento, sus capacidades y habilidades, los recursos disponibles y la situación en ese momento.
Norman L. Kerth

jueves, mayo 25, 2017

Generación de Valor con Scrum

El pensamiento Ágil llegó para quedarse. Se trata de un enfoque caracterizado por el trabajo colaborativo, las entregas de producto con Valor tempranas y frecuentes, el mejoramiento continuo y las continuas inspección y adaptación a los cambios que se suscitan en el entorno. 
Scrum es hoy el marco de trabajo Ágil más ampliamente usado porque es un instrumento que nos conduce hábilmente por el camino de la Agilidad, nos permite aumentar la productividad y la calidad de lo que hacemos a la vez que obtener retroalimentación sucesiva de los consumidores finales. 
En esta presentación revisaremos como con el marco de trabajo Scrum se puede generar Valor de manera temprana y frecuente durante los esfuerzos de desarrollo de nuevos productos.
Descarga la presentación a continuación y déjanos conocer tus pensamientos e inquietudes al respecto en el foro: