Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay

Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

• El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y

• El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay

El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 

La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.

El imposible y desatinado caso de SCRUMStudy®

Imagen de Sophie Janotta en Pixabay

Una colega lanzó esta pregunta en una comunidad de Scrum Masters:

Que tal grupo, […],

Duda: (corríjanme si estoy mal, por favor)

Entre las diferentes compañías tales como SCRUMstudy^®, Scrum Alliance, Scrum.org, etc.

En cuestión a la teoría que imparten todas las diferentes compañías/empresas ¿existe alguna diferencia entre el contenido que imparten para enseñar a sus receptores Scrum? o ¿Todas las compañías en cuestión a teoría enseñan lo mismo pero te certifican según la compañía en la que tomaste la capacitación o curso?

[…]

Saludos.

[Texto copiado con permiso de su autora]

Recordé que hace ya algún tiempo estuve involucrado en otro foro sobre la muchas veces discutida pregunta “¿dónde me certifico?”. Mis ideas de entonces quedaron registradas en:

https://www.linkedin.com/pulse/donde-me-certifico-como-scrum-master-luis-antonio-salazar-caraballo/

Pero esta nueva pregunta iba más allá. Hablaba de la teoría. Y lo que más me llamó la atención fueron las respuestas iniciales de otros foristas quienes, de alguna manera, no diferenciaban en el tratamiento de Scrum que hace el así llamado SBOK^® y la guía oficial de Scrum, escrita por sus creadores.

Como es un tema escabroso, de esos que elevan las pasiones, lo pensé mucho antes de involucrarme. Finalmente, pudo más la responsabilidad que tengo con el “hacer bien las cosas”, el compromiso que tengo con el mejoramiento del uso de Scrum por parte de las personas, equipos y organizaciones a mi alrededor. Así que esta fue mi respuesta:

Imagen de David Mark en Pixabay

A ver si trato de explicar esto con una analogía:

Aunque la FIFA no inventó el Fútbol, es hoy el organismo que “rige” los estándares, que regula, que establece las “reglas” de ese deporte. A pesar de ello, es posible jugar al fútbol con variantes y no “pasa nada”: fútbol playa, fútbol 5, fútbol 7, fútbol sin porterías, etcétera. Cada una de estas otras versiones tiene distintas reglas, creadas o inventadas por nosotros mismos, las personas, o por algún organismo distinto a la FIFA. Hay menos jugadores en algunos, hay variaciones en las reglas, en fin. Pero en definitiva, el Fútbol como tal, el deporte del balón, el universal, es el de la FIFA.

Así ocurre con Scrum. Este marco de trabajo fue creado por Jeff Sutherland y Ken Schwaber y fueron ellos quienes escribieron originalmente lo que hoy se conoce como la guía de Scrum. El primer documento lo presentaron al mundo en 1995. Puedes encontrar más de los orígenes de Scrum en:

https://www.scruminc.com/origins-of-scrum/

Ahora bien, son Jeff Sutherland y Ken Schwaber quienes siguen actualizando y manteniendo la guía (la teoría) de Scrum de tanto en tanto. Ellos reciben la retroalimentación de la comunidad pero finalmente ellos son sus creadores y, por decirlo de alguna manera, sus guardianes. Aunque bien todos nosotros deberíamos ser custodios de esa guía oficial también.

Después de Scrum llegaron organizaciones como la Scrum Alliance, creada precisamente para fomentar el uso del framework. Ellos crearon algunas certificaciones asociadas: Scrum Master, Product Owner y Scrum Developer. Y basaron sus cursos y certificaciones en la guía de Scrum escrita por Sutherland y Schwaber.

Más tarde aparecieron empresas como Scrum.org de Ken Schwaber y Scrum Inc., de Jeff Sutherland.

Y luego otras empresas certificadoras. Incluyendo SCRUMStudy^®. Casi todas estas últimas empresas certificadoras de Scrum son independientes, de terceros, pero basan sus certificaciones en la guía de Scrum escrita por Sutherland y Schwaber, la guía oficial.

Casi todas, excepto SCRUMStudy^®, que basa sus entrenamientos (teoría) y exámenes de certificación en un libro que ellos llaman Scrum Body of Knowledge (SBOK^®). Un libro de más de 400 páginas la última vez que lo consulté. Mientras que la guía oficial solo tiene unas 18 páginas en español.

Imagen de LhcCoutinho en Pixabay

Este SBOK^® es como esas otras versiones de Fútbol de las que te hablé al comienzo. Tiene otras reglas, muy diferentes a las que tiene la guía de Sutherland y Schwaber, los creadores de Scrum.  Imagina las diferencias nada más en número de páginas. De 18 a más de 400. Pero quisiera poner tres ejemplos de las disparidades que presenta la una versus la otra:

1. Roles propuestos: en Scrum “oficial” (en la guía de Sutherland y Schwaber, la de 18 páginas), los tres roles propuestos son: Dueño de Producto, Scrum Master y Equipo de Desarrollo. Solo tres y nada más que tres. Estos tres roles forman lo que conocemos como Equipo Scrum. Mientras tanto en el SBOK^® se proponen 2 tipos de roles: Roles Core y Roles Non-core. A los primeros pertenecen los tres roles de la guía oficial aunque con una discrepancia: el equipo de desarrollo se llama Equipo Scrum. En la guía oficial, como dije antes, este Equipo está compuesto por los tres roles. Aquí no. Y los roles non-core son Stakeholders (dentro de los cuales cuentas Customer, Usuarios y Patrocinador), Vendedores y Cuerpo de asesoramiento de Scrum. En definitiva, son reglas distintas.
2. En la guía oficial de Scrum, el tamaño del equipo de desarrollo va de 3 a 9 personas. En la sección 3.6.2 (Tamaño del Equipo Scrum), el SBOK^® dice que “El tamaño óptimo de un Equipo Scrum es de seis a diez miembros”. Otra vez, una regla disímil.
3. En la guía oficial de Scrum, la duración máxima del Sprint es de un mes. Mientras que en la sección 2.7.1 (Scrum Time-boxes), el SBOK^® dice que “Un Sprint es una iteración Time-boxed de una a seis semanas de duración”. Otra disparidad.

Y así podemos encontrar muchas. De 18 a más de 400 páginas. Simplemente son reglas desiguales, algunas muy opuestas. El SBOK^® No es Scrum.

Con esto solo estoy tratando de señalar que la guía de Scrum, la cual puedes descargar de inmediato desde https://www.scrumguides.org/download.html o directamente la edición en español desde: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf, es la guía oficial que te presenta la teoría y las reglas de Scrum. Es la única fuente fiel, escrita y mantenida por sus creadores.

¿Quién sabe? Seguramente, si vas a jugar Fútbol y tomas el balón con la mano o si en tu equipo hay trece jugadores en la cancha recibirás una infracción y quizás hasta no puedas jugar.

Espero que sea de utilidad.

Saludos,

Las primeras reacciones a mis ideas en el foro fueron bastante positivas. De hecho, mucho más de lo que merezco. Pero eso me motivó a trasladar la explicación hasta mi Gazafatonario, para que más personas tuvieran acceso a ella. Por favor, déjame saber qué piensas al respecto.

Soy un buen Scrum Master pero la empresa no está preparada

O “Soy un buen Scrum Master pero la empresa no es ágil”

Imagen de mohamed Hassan en Pixabay

Cuando eres Scrum Master, sea cual fuere tu nivel de experiencia o de madurez en el rol, nunca más se da el caso de “no soy yo, son ellos”:

• Es que apenas están implementando Scrum, ellos (la organización, los equipos, las personas) no están maduros. | ¿Es posible “implementar” Scrum?
• Es que todavía están (los equipos, las personas) atascados en los modos tradicionales de gestión y creen que soy el jefe o el gerente.
• Es que ellos necesitan entender la nueva forma ágil de trabajar que quieren adoptar. | ¿”Adoptar”, luego no era “implementar” Scrum?
• Es que están esperando que yo comande al equipo desde alguna suerte de puesto de control o cabina de mando.
• Es que yo no tengo autoridad sobre el equipo. Soy solo un líder servicial a su servicio, como dice la guía de Scrum. Y el equipo es autogestionado. Funciona por sí solo. | ¿Un equipo “funciona”?
• Y la lista de razones puede llegar a ser interminable.

Muchas organizaciones con una fuerte cultura de comando y control no te tomarán en serio como Scrum Master si no muestras habilidades para tomar el control de la situación. Las formas de hacer las cosas y mucho menos las formas de pensar actuales se cambian en pocos meses. Hacer que la empresa, los equipos y las personas maduren o siquiera estén conscientes de su nivel de agilidad es tu responsabilidad también.

Imagen de Gerd Altmann en Pixabay

No puedes simplemente ignorar la cultura actual de la organización y conducirte sobre los nuevos preceptos que te “dicta” la agilidad, el pensamiento Lean o prácticas como Scrum. “Es que ellos no entienden nada de liderazgo servicial ni de mejoramiento continuo”. No hay tal cosa como “ellos y nosotros” en el pensamiento ágil.

No te apresures. Da un paso a la vez y aprende de la reacción del entorno. Concéntrate primero en el equipo y ve escuchando al resto de la organización sin atribularte por la avalancha de ideas, solicitudes, advertencias, restricciones, desafíos, oposiciones y demás escenarios que vas a vivenciar. Para ello, viene bien hacerse acompañar de otros Scrum Masters, coaches ágiles o de cualesquiera que te proporcione ideas y que desee llevarlas a cabo contigo.

Estás allí para enseñarle a cada miembro del equipo a ser un líder, para empoderarlo y ayudarlo a aclarar su rol en este nuevo orden de las cosas, para remover algunos de los obstáculos en su camino pero más que a nada para instruirlo en cómo eliminarlos por sí mismo. Por sobre todas las cosas, no pierdas de vista que vienen de la cultura de ser recursos, así que piensa en ellos como personas y haz todo lo que esté a tu alcance para aumentar su felicidad.

Eres su entrenador pero deja que ellos también te entrenen. Aprende de la cultura y de los comportamientos imperantes. Luego, comienza a promover y a resaltar nuevos comportamientos “a lo ágil” y a desalentar, sin presión, las conductas actuales que no posibilitan el mejoramiento del equipo. Define un buen conjunto de valores que sean consistentes con el mensaje que quieres enviar y con el nuevo camino que les quieres mostrar, los valores de Scrum te ayudan, sí.

Asegura victorias tempranas. Una matriz de Esfuerzo versus Valor siempre viene bien en estos casos. Asegúrate de hacer con tu nuevo equipo lo que está en la zona de mayor Valor pero menor Esfuerzo y por ningún motivo mires la zona de mayor valor y menor esfuerzo.

Matriz de Esfuerzo versus Valor

Esfuerzo y Valor son relativos. Asume que todo lo que haces genera Valor y requiere de cierto esfuerzo. Pero incluye las variables que necesites para garantizar que algunas tareas, de tres a cinco de ellas, generan más valor que otras y requieren menos esfuerzo que otras. Y así, hasta completar la matriz. Distintos ejercicios te pueden llevar a lograr esto en pocos minutos, aun si tu equipo no es el mejor comunicándose.

Ve a lo seguro, sin dejar de experimentar. Después de todo, de eso se trata, de aprender mediante experimentos rápidos y baratos. Sigue la línea Shu-Ha-Ri como en esta infografía que preparé con mi gran amigo, compañero de batallas ágiles, Jorge Abad (@Jorge_Abad):

Scrum Master Shu-Ha-Ri

En esta etapa inicial, como Scrum Master, sigue la guía de Scrum con cierta precisión. Concéntrate en cómo organizar y llevar a cabo los eventos con el equipo, que se tengan los artefactos y que cada miembro del equipo Scrum se desempeñe como lo plantea la guía, sin preocuparte demasiado por la teoría subyacente; por ejemplo, en cómo planificar en un entorno empírico. Si hay múltiples variaciones sobre cómo hacer algo, solo decídete por la forma en que la guía lo establece o en como lo aprendiste. Tengo que decirlo, en este último caso, quizás estés equivocado, así que igual, hazte acompañar de alguien más experimentado, incluso de miembros de tu nuevo equipo. Ellos ahora son tu familia.

Más adelante pasarás a los demás estados. Recuerda que si ingresaste al equipo y a la organización, hay una alta probabilidad de que la madurez en materia de desempeño de todos quizás se reinicie “a lo Tuckman”, en donde los miembros del equipo tengan miedo (otra vez) de pedir ayuda unos a otros y a ti, no confiarán completamente en ti y te monitorean de cerca cuando estés trabajando en una tarea específica, con o sin ellos; muchos de ellos tendrán sus propias ideas sobre el proceso y las agendas personales serán rampantes; quizás te encuentres con roles específicos dentro del equipo, como líder técnico, facilitador, diseñador, documentador, incluso gerente; volverán las discusiones abstractas (si alguna vez se fueron) sobre distintos conceptos y temas y algunos miembros estarán impacientes con estos debates. Entre otros comportamientos típicos de la etapa de Formación de un equipo tradicional.

Incluso parecerá que estás logrando poco hacia la consecución de los objetivos del proyecto (sí, todavía se llamará “proyecto) y recibirás toda la carga de la culpa cuando te señalen a ti y a la nueva forma ágil de hacer las cosas que intentas poner de manifiesto en el ambiente. No te preocupes mucho por ello, aunque no estén completamente seguros de las metas y problemas del proyecto, algunos, quizás todos, estarán entusiasmados y orgullosos de estar en el equipo y a la expectativa de lo que pueda venir.

Las cosas así, quizás no puedas ir más allá del estado Shu, así te sientas con la fuerza, la experiencia y el coraje para empezar con el estado Ri. Lo leí de Melina Jajamovich (@latodoterreno) recientemente, “No hay seniority que valga cuando se trata de #agilidad | El mindset es un desafío de cada día”. Eres un eterno aprendiz, inculca eso en tu equipo, estás allí para acompañarlos a ser mejores.

Finalmente, empieza a pensar en el futuro del equipo. De hecho, esto se convertirá en lo más común y en lo mejor que podrás hacer en tu nuevo rol. Con el tiempo aprenderás que para un Scrum Master extraordinario no hay tal cosa como “no puedo hacer esto o aquello porque surgió algo urgente”. Debes adelantarte en el tiempo y visionar cómo llevarás al equipo al siguiente nivel de crecimiento, sin dejar de vivir en el presente para estar al frente de las tareas menos mundanas de protección y liderazgo del equipo.

Ya eres Scrum Master, no lo eches a perder solo porque el resto de la organización no te entiende. Asume tu responsabilidad, toma el control y muéstrales las cosas fantásticas que pueden lograr con agilidad. Es tiempo de cambiar.

El último día del sprint

Imagen tomada de Pixabay

"Comenzar fuerte es bueno. Terminar fuerte es épico". [Robin Sharma]

Desde siempre he visto como los equipos de desarrollo de producto, especialmente los de desarrollo de software, emprenden los más titánicos proyectos con unas ganas inconmensurables, una fuerza interior, personal y grupal, que parece infinita y una pasión energizante que enciende los motores de la creación, el trabajo en equipo y los deseos de triunfar.

Nada muy distinto a lo que ocurre hoy en cada iteración de cualquier iniciativa o esfuerzo de desarrollo: el primer día los equipos planifican su propósito de vida para las siguientes jornadas y hasta son capaces de hacer un pronóstico de cómo alcanzarán la meta del sprint que comienza. Y diariamente acuden a la cita de la colaboración y la creación de valor con la mejor sonrisa y disposición.

O así es… ¡hasta que se acerca el fin de la iteración!

Un sprint es un bloque de tiempo breve en el que hay que mantener el foco y el esfuerzo regulado para terminarlo como lo empezamos. Con brío y pundonor. Pero eso no está ocurriendo con muchos equipos. En mis continuos ejercicios de acompañamiento y consultoría me sigo encontrando las historias de nunca acabar:

• Es que no hicimos retrospectiva para terminar las historias de usuario
• Programadores escribiendo programas minutos antes de la revisión con los interesados. ¿Y las pruebas?
• Vamos a aplazar la revisión. Mañana hacemos la planificación del próximo sprint, luego la retrospectiva. Pasado mañana hacemos la revisión de este sprint que termina.
• Solicitemos un aplazamiento del paso a producción para el próximo sprint.
• Pidamos una extensión del sprint. Necesitamos dos o tres días más para terminar lo prometido.
• Y la lista continúa.

Entre otras cosas, es a lo que se refieren Jeff y Ken cuando dicen que Scrum es “difícil de llegar a dominar”. Pero no se trata solo de Scrum. Es esa falta de disciplina que tenemos para hacer que las cosas terminen, ese apego a lo que es y no queremos dejar ir, inherente a todo ser humano. Es esa facilidad para conjugar el verbo empezar pero a la vez esa dificultad para conjugar la voz finalizar.

El último día del Sprint comienza el primer día del Sprint

Imagen tomada de Pixabay

Hagamos un plan hasta el penúltimo día del sprint, sea cual fuere su duración. Sí, con historias de usuario más pequeñas es posible. Y sí, todavía pueden ser entre 6 y 10 historias de usuario.

Recordemos en la planificación que la revisión y la retrospectiva requieren de preparación. No es algo que ocurre solo porque llegó la hora de hacerse o porque el marco de trabajo lo exige. Nunca veo esas tareas de preparación en el backlog del sprint. Y no, no son historias de usuario. Son actividades que bien pueden realizar el Scrum Master, pero también el Dueño de Producto o cualquier otro miembro del equipo, aunque preferiblemente uno de los dos primeros.

En cada reunión diaria, examinemos efectivamente cómo vamos hacia el cumplimiento de la meta del sprint y qué estamos haciendo específicamente para preparar esa gran fiesta que es la revisión del incremento con los interesados, no solo con el Dueño de Producto. Y, ni más faltaba, vayamos pensando qué clase de retrospectiva queremos hacer. Y sí, quince minutos es suficiente para ello. Durante la preparación de estos eventos finales también surgen impedimentos que hay que resolver con prontitud.

Recordemos, si no aseguramos la calidad del producto, no está terminado. Siempre pongamos de manifiesto que solo revisaremos lo que verdaderamente está terminado. Y no, casi terminado no es terminado.

El Scrum Master bien puede crear una campaña de expectativa hacia el exterior del equipo, dirigida a los interesados, sobre la próxima revisión, el siguiente gran hito. Y también hacia el interior del equipo: la siguiente gran oportunidad de inspección y adaptación, la retrospectiva. Sin que esto quiera decir que los demás eventos no son oportunidades de evaluación y ajuste, en el sentido de mejora continua.

Promovamos el descanso placentero y el sueño profundo, incluso la relajación y la meditación, la noche antes del día final del sprint. Descansemos, estemos con nuestras familias o amigos, salgamos a cenar, a disfrutar de una caminata a la luz de la luna con quien mejor nos sintamos o simplemente reposemos al ritmo que nuestro corazón dicte. Preparémonos así para la gestación de un día de buenas noticias con el resto del ecosistema organizacional.

Participemos de los preparativos, una revisión interna previa del producto no está demás. Lleguemos antes que todos los demás y recibamos a los invitados a la revisión, si los hay, con una gran sonrisa, con sendos mensajes de bienvenida, con una bebida. Y no, no es hora de licor.

[De la revisión propiamente dicha hemos hablado en variadas ocasiones así que no voy a entrar detalles sobre lo que debe o debería ocurrir durante la misma]*.

Aunque esto es del ámbito de la reunión misma, no dejemos de solicitar y recibir con la mente bien abierta toda la retroalimentación que nos brinden los asistentes. Ese será el motor que nos permita hacerlo mejor la siguiente vez. Y finalicemos con los agradecimientos respectivos, los aplausos, los abrazos, ¿por qué no? Después de todo, estamos todos en el desafío de deleitar a los consumidores finales de nuestro producto.

Finalmente, hagamos una pausa, tomemos un café y vamos a la retrospectiva. Esa cita íntima y necesaria en cada iteración. [Tampoco me extenderé mucho en este apartado]**

Al final del día, piensa que mañana seguirás mejorando. Es todo lo que necesitas para triunfar.

Apostilla:

No solo el último día, sino todos los días de tu vida, tiende la cama antes de salir. Si al final tienes un mal día o muchos malos días, siempre te recibirá una cama limpia y tendida. ¡Es la clave para cambiar el mundo!

-----

* Por ejemplo, además de lo que dice la guía de Scrum, mi gran amigo Jorge Abad ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[AgendaScrum] Pasos para Realizar el Review o Revisión

Tipde Scrum: La calificación del Product Owner al finalizar el Sprint

Buenasy Malas Prácticas en el Review / Demo de Scrum

Lacara del santo hace el milagro. Efectividad del Planning y Review

Los invito a que los lean. Encontrarán consejos muy útiles cuando de preparar y realizar este evento del que les he hablado se trata.

** Por ejemplo, pueden leer mis artículos:

De Retrospectivas y de Ratones

Directiva Primaria de las Retrospectivas

Dueño de Producto, usted ha sido invitado a la Retrospectiva

Aquí mismo en este Gazafatonario.

El contexto de tu producto importa: aquí te cuento el porqué

Imagen tomada de Pixabay

Escucha el audio de este artículo aquí:

Los dueños de producto virtuosos utilizan una combinación de análisis de negocios, experiencia de usuario y habilidades de gestión de productos para determinar cuál es el siguiente producto correcto a diseñar y construir y para compartir con el equipo de desarrollo el entendimiento que tienen de su visión.

Mucho antes de la era ágil ya enseñaba y acompañaba a los gerentes de producto y líderes de equipos de producto a:

• Entender mejor a los interesados, a los usuarios y a todo aquel que se viera impactado de una u otra forma por el producto y por su desarrollo
• Comprender el contexto de su producto
• Tener una percepción más íntima de las necesidades de sus consumidores
• Entender y juzgar el producto derivado de su trabajo con el equipo
• Organizar la información recopilada del aprendizaje del uso del producto, más del contexto de este.

El movimiento ágil me enseñó posteriormente que una técnica específica puede o no ser apropiada en cada situación. También me enseñó que el diseño y la elaboración de productos impresionantes es una forma de pensar, una mentalidad. De esta manera, el mensaje que llevo a los Dueños de Producto actuales para ayudarlos a determinar el momento adecuado para usar una u otra técnica y la forma más sencilla de aplicarla, es conocer en profundidad los diferentes escenarios, las circunstancias o condiciones bajo las cuales será usado el producto que tienen en mente, lo que casi siempre incluye conocer al detalle a los usuarios o consumidores.

Pero en el camino de establecer una comprensión compartida del problema y más allá, de la causa raíz, el problema detrás del problema, y de las mejores soluciones para resolverlo, nos encontramos con ciertos impedimentos como:

• Muchos backlogs de producto
• Dificultad en la priorización de cada uno de ellos y entre unos y otros
• Poca percepción del valor de cada producto y de cada uno de sus componentes, el valor para el negocio
• Muchas interdependencias entre unos y otros y hasta con productos que no están en el radar de nadie
• Los equipos no necesariamente están trabajando en los productos correctos desde una perspectiva del negocio, aunque los Dueños de Producto no ayudan mucho en este sentido

Para sobrepasar estas dificultades ayuda conocer el contexto en el cual estamos trabajando. Es útil encontrar las respuestas a preguntas como:

• ¿Quién necesitará o usará nuestro producto?
• ¿Quién es nuestro consumidor final?
• ¿A qué mercado o segmento de mercado queremos llegar?

Pero ya no estamos en el momento de quedarnos con las respuestas simples. Estamos en la era de la hiperpersonalización de productos. Cada consumidor o usuario quiere tener su propia experiencia, única, así es que dediquemos tiempo a conocer a muchos de ellos. No es que necesitemos salir con un MVP para cada uno, se trata de salir lo más rápido posible con un producto en excelentes condiciones, listo para usar o consumir y,  a partir de allí, incrementarlo y desplegarlo a más y más usuarios de manera frecuente.

Dediquemos un tiempo importante a repensar el producto. No caigamos en la trampa del “MVP muy temprano”. El mayor miedo de las organizaciones hoy es llegar al mercado con el producto incorrecto. Está bien lo de fallar rápido y barato pero no se trata de fallar por fallar. Nos enfrentamos a la paradoja de las organizaciones exitosas: solo queremos brindar productos que enamoren a las personas, pero no sabemos si el producto deleitará a nuestros clientes hasta tanto no lo hayamos entregado.

Las cosas así, llevar a cabo minuciosamente algunas de estas actividades, sino todas, ayuda:

• Definir y defender la visión del producto.
• Investigar la naturaleza y probar las necesidades del mercado
• Identificar múltiples opciones de productos de alto valor.
• Decidir las fechas de lanzamiento y el contenido. Sobre todo, lanzar con calidad.
• Durante el desarrollo “a lo Scrum”, lograr que los elementos del backlog de producto estén "Preparados" para la planificación y desarrollo
• En ese mismo orden de ideas, aceptar solo trabajo "Terminado"
• Realizar demostraciones de productos y solicitar retroalimentación en vivo y en directo, tomar atenta nota e incorporar, de ser posible, las nuevas solicitudes

En mi artículo Las historias de usuario se cuentan con C de Contexto, enumeraba Algunas herramientas que nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general. Puedes leer el artículo en:

http://www.gazafatonarioit.com/2019/06/las-historias-de-usuario-se-cuentan-con.html

Ahora bien, antes de pensar en la tecnología, pensemos en el negocio. Antes de salir a vender (o a producción), pensemos en el mercado. Antes de desarrollarlo, pensemos en el cliente o usuario. Antes de considerar sus componentes internos, pensemos en cómo se verá a los ojos, a los sentidos de las personas a las que queremos llevarle el producto.

Una técnica que estamos aplicando con éxito es esta del desarrollo de productos basado en experimentos: una forma de abordar el diseño del producto y el proceso de desarrollo para que la investigación, el descubrimiento y el aprendizaje (hacer preguntas y obtener respuestas útiles y confiables) tengan prioridad sobre el diseño y luego la validación de las soluciones propuestas. Pero sobre desarrollo de productos basado en experimentos hablaremos en otra oportunidad.

Imagen tomada de Pixabay

Mientras tanto, atención Dueños de Producto, Gerentes de Producto, deleguen completamente el diseño y la construcción del producto al equipo de desarrollo, ustedes dedíquense a explorar el mercado, a aprender de él, a pensar en nuevas formas de cambiar el estilo de vida de las personas y a conocer las necesidades de estas. Es lo que finalmente los conducirá al éxito en sus tareas habituales. ¡Escucha a tu usuario!

Finalmente, es solo a través de procesos efectivos de diseño, prueba, retroalimentación e iteración, que un Dueño de Producto y su equipo pueden validar el impacto de una idea en un contexto. Súmate a un equipo grandioso, porque un equipo estupendo hace productos fantásticos.