# data[].attributes.attachment_link.readable_text
Por Damián Buonamico

En Scrum, el Product Owner es " la voz del usuario" hacia el interior de la organización, es quien está atento a entender las necesidades de los usuarios. Esta tarea no se puede llevar a cabo efectivamente si no se tiene contacto directo con dichos usuarios para empatizar con sus necesidades, escuchar su feedback y analizar sus comportamientos.

Por esa razón, es el rol más estratégico en organizaciones que desarrollan productos (o servicios) con Scrum. Esto es cierto en la medida que el éxito del producto impacta en el éxito de la organización.

Ser Product Owner implica mantener interacciones de influencia continua con distintos actores clave dentro y fuera de la organización, situándolo en una posición panóptica del sistema y que por lo tanto facilita entender cómo las decisiones impactan en los resultados deseados.

En este artículo, comparto una representación de ocho dimensiones en las que como Product Owner debes prestar atención. ¿Hay alguna que estés descuidando?

Ser Product Owner implica mantener interacciones de influencia continua con distintos actores clave dentro y fuera de la organización, situándolo en una posición panóptica del sistema y que por lo tanto facilita entender cómo las decisiones impactan en los resultados deseados.

En este artículo, comparto una representación de ocho dimensiones, agrupadas en cuatro áreas, donde como Product Owner debes estar prestando atención. ¿Hay alguno de éstos que estés descuidando?

El siguiente gráfico ilustra las ocho dimensiones agrupadas en cuatro áreas. Lo utilizo en mis capacitaciones con una actividad que consiste en auto-evaluarse, dibujando sobre el gráfico una representación de la distribución actual de mi atención en cada dimensión e identificar áreas de mejora. Para esto podemos ayudarnos con las preguntas de autoevaluación que se encuentran al final del artículo.

Las cuatro áreas de atención del Product Owner son: Negocio, Stakeholders, Scrum y Producto. Dentro de cada área hay dos dimensiones clave.
Area Negocio:
El Product Owner se encuentra en posición de impactar directamente en el logro de resultados de negocio con sus decisiones de producto: qué características implementar y cuáles no. Dentro de esta área distingo dos dimensiones:

Modelo de Negocio: Cómo el Product Owner entiende y considera el modelo de negocio que sostiene a la organización en sus decisiones de producto.

Estrategia de Negocio: La elaboración y continua evaluación de la estrategia del Product Owner para alcanzar determinados objetivos de negocio con el producto alineado con el modelo de negocio.

Area Stakeholders:
El Product Owner tiene relación directa con los distintos interesados del producto, ya que éste es el único que tiene el poder de priorizar la próxima característica a implementar en el producto.

Mientras que la Dirección está mirando la estrategia de negocio, los equipos de producto están enfocados en cómo construir de la mejor manera ¿Quién vela por el usuario?

La relación estrecha con el usuario pone al Product Owner en una posición privilegiada para entender, más que otros actores de la organización, que características de producto deben ser priorizadas y establecer la dirección en la que debe evolucionar el producto a construir.

Recordemos siempre que el usuario final tiene el poder de despedir al CEO de la empresa con su decisión de compra. Por ello esta dimensión de trabajo es tan estratégica para el éxito de la empresa.

No solo los usuarios mueven la aguja del producto; dentro y fuera de la organización existen distintos interesados en influir en su dirección: quienes buscan maximizar la rentabilidad, los clientes, los distintos usuarios internos, otros equipos de producto, un ente regulador, etc.

Todos ellos se comunican directamente con el Product Owner, ya que es éste quien tiene la potestad de decidir cuál es la próxima característica a ser desarrollada e incluirla en la próxima versión del producto. Esto permite al Product Owner establecer relaciones estrechas con los stakeholders de la organización.

El Product Owner tiene la desafiante tarea de entender el valor relativo de los distintos pedidos y cómo aportan a la visión y estrategia general; independientemente de que tan fuerte lo pidan o del salario de quien lo pide.

Su posición le permite conocer los intereses de todos, mientras que cada stakeholder, de manera sesgada, pueden atribuir un mayor valor a sus propios pedidos por sobre los del resto. Aquí también aplica el concepto de visión sistémica del Product Owner.
Área Scrum:
El Product Owner es integrante del Equipo Scrum, junto con el Scrum Master y el Equipo de Desarrollo. Como integrante participa del proceso Scrum e interactúa con el equipo para la construcción del producto. La efectividad de este proceso depende en cierta medida de la participación del Product Owner.

El equipo de desarrollo de producto.

El Product Owner trabaja conjuntamente con el equipo de desarrollo. Esta relación que genera con el equipo de desarrollo le permite comprender mejor las posibilidades y restricciones de la tecnología utilizada y colaborar con el equipo técnico para maximizar el potencial entre desarrollo de producto y evolución de la plataforma tecnológica.

En esta relación, el Product Owner debe proteger la autonomía y auto-organización del Equipo de Desarrollo.

En Scrum, el Product Owner participa junto con Equipo de Desarrollo en la planificación, revisión y retrospectiva del Sprint y trabajan juntos refinando el Backlog de Producto.

En los equipos más efectivos, además se comparten espacios de trabajo más cotidianos para clarificar dudas durante la construcción del producto y aceptar características terminadas durante el Sprint.

El rol del product owner hacia el equipo, es el de clarificar la visión del producto, decidir las prioridades del backlog de producto, y dar feedback sobre el producto construido. Nadie más dentro de la organización tiene este poder, de influir directamente en lo que se está construyendo.

El Product Owner debe mantener el Backlog de Producto actualizado a todo momento para que el equipo de desarrollo pueda trabajar sin demoras en aquello que más valor tiene.
Área Producto
El producto es el resultado de las decisiones del Producto Owner. Para esto existen dos disciplinas que el Product Owner lidera en paralelo y de manera continua: la entrega (Product Delivery) y el descubrimiento de producto (Product Discovery).

Gestiona el producto realizando un Roadmap (plan de entregas y versiones). Decide cuándo y en qué mercados desplegar el producto, con qué funcionalidades, decide las métricas de éxito del producto, posibles integraciones con otros productos y distintas estrategias comerciales.

El peor riesgo en producto, es desarrollar muy bien el producto equivocado. Por ello, no debemos asumir que sabemos lo que el usuario necesita.

El descubrimiento de producto consiste en sostener las ideas como supuestos y validarlos de la manera más rápida y barata posible (por ejemplo, utilizando prototipos).
¿Cómo ser un Product Owner efectivo?
No es posible ser un Product Owner efectivo en las ocho dimensiones cuando el estilo predominante lo lleva a centralizar información, ser intermediario entre los distintos actores o tomar decisiones en solitario.

La visión global del Product Owner debe ser compartida con la organización, como una invitación a salir de los silos organizacionales y generar un gran equipo de trabajo colaborativo.

Es necesario adoptar un estilo de liderazgo participativo, generando espacios de integración de las distintas áreas para generar aprendizaje en equipo y fomentar una visión compartida.

A continuación, te presento una guía de dos preguntas por cada una de las dimensiones de atención del Product Owner, para disparar la reflexión y autoevaluación.
NEGOCIO Modelo de Negocio:
¿Comprendo y ayudo a otros a comprender el modelo de negocio que sostiene la organización?

¿Cómo el modelo de negocio está contemplado en mis decisiones de producto?
Estrategia de Negocio:
¿Cómo están ayudando los objetivos de negocio a alinear los esfuerzos de los distintos equipos?

¿Cómo se orientan las decisiones de producto hacia los objetivos de negocio?
INTERESADOS DEL PRODUCTO El Usuario Final
¿Cómo conocemos quién es el usuario y cuales son sus características distintivas?

¿Cómo recibimos y consideramos la información de feedback y de métricas de los usuarios para las decisiones de producto?
Otros Stakeholders
¿Cómo es la participación de los distintos interesados del producto en el proceso de validar, pedir feedback y relevar necesidades?

¿Cómo son los criterios utilizados para evaluar y considerar los pedidos de los distintos interesados? Cómo compite el valor que los pedidos aportan con la posición de la persona que lo está pidiendo?
SCRUM El Equipo Scrum
¿Cómo es la calidad de relación, confianza y colaboración del Product Owner, el Equipo de Desarrollo y Scrum Master? Cómo está el nivel de autonomía y autoorganización del Equipo?

¿Cómo estoy ayudando al Equipo de Desarrollo a comprender la visión del producto, el usuario y el negocio?
El Proceso Scrum
¿Cómo es mi participación en los eventos del proceso de Scrum (planificación del sprint, refinamiento de product backlog, revisión del sprint y retrospectiva)?

¿Cómo es mi disponibilidad para el equipo durante el desarrollo del sprint?
EL PRODUCTO Product Delivery (Entrega de Producto)
¿Cómo es la percepción del usuario de la calidad, frecuencia y calidad de las entregas?

¿Cómo es la percepción del usuario del valor que recibe de las nuevas características entregadas?
Product Discovery (Descubrimiento de Producto)
¿Cómo es nuestro proceso para descubrir las nuevas características a construir y validación de supuestos de manera temprana?

¿Cómo estamos incorporando aprendizaje del usuario, su contexto, necesidades y como el producto satisface?

# data[].attributes.attachment_link.title
¿Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención?

# data[].attributes.attachment_link.description
Por Damián Buonamico En Scrum, el Product Owner es " la voz del usuario" hacia el interior de la organización, es quien está atento a entender las necesidades de los usuarios. Esta tarea no se puede llevar a cabo efectivamente si no se tiene contacto directo con dichos usuarios para empatizar con sus necesidades, escuchar su feedback y analizar sus comportamientos.

# data[].attributes.attachment_link.readable_text
En SCRUM, gracias al product backlog, tendremos una lista de los requisitos/expectativas del cliente la cual usaremos para describir el próximo trabajo sobre el producto

Para empezar a trabajar, no es necesario que el product backlog esté completo, ni siquiera que TODOS los requisitos estén detallados, solo necesitamos el suficiente detalle para los requisitos más prioritarios con los que el equipo pueda empezar a trabajar.

¿Qué es el Product Backlog?

Es una lista priorizada y ordenada de requisitos del cliente (llamados Product Backlog items) de un proyecto. Es gestionado por el product owner, incluyendo su contenido, disponibilidad y peticiones, además es él (el product owner) quien ordena el Product Backlog en base al valor, riesgos, dependencias y necesidades de negocio.

¿Qué debería haber en el Product Backlog?

Todos los requerimientos, funcionales y no funcionales, tareas y bugs deben ir en el Product Backlog. Su contenido refleja todo el trabajo que el equipo de desarrollo tiene que hacer. En otras palabras, el equipo de desarrollo no hace absolutamente nada que no se encuentre en este listado.

¿Quién crea el Product Backlog?

El Product Owner define la visión y dirección que el producto toma, por norma general, siempre se establecen antes los requisitos conocidos y mejor entendidos. Cualquier miembro del equipo puede agregar items en el Product Backlog. Sin embargo, es el Product Owner quién se encarga de gestionarlo.

¿Cada cuánto debo actualizar el Product Backlog?

El Product Backlog nunca se completa, además, evoluciona constantemente, puede cambiar en todo momento, por lo que se actualiza cada vez que sea necesario. En cambio, recuerda que en el Sprint Backlog (los items que se escogen para desarrollar en un Sprint) no pueden cambiar.

# data[].attributes.attachment_link.title
¿Qué es el Product Backlog? [RESUELTO] ⋆ Be Agile My Friend

# data[].attributes.attachment_link.description
En SCRUM, gracias al product backlog, tendremos una lista de los requisitos/expectativas del cliente la cual usaremos para describir el próximo trabajo sobre el producto Para empezar a trabajar, no es necesario que el product backlog esté completo, ni siquiera que TODOS los requisitos estén detallados, solo necesitamos el suficiente detalle para los requisitos más prioritarios con los que el equipo pueda empezar a trabajar.

# data[].attributes.attachment_link.title
Ray Dalio: How to build a company where the best ideas win

# data[].attributes.attachment_link.description
What if you knew what your coworkers really thought about you and what they were really like? Ray Dalio makes the business case for using radical transparency and algorithmic decision-making to create an idea meritocracy where people can speak up and say what they really think -- even calling out the boss is fair game.

# data[].attributes.attachment_link.description
Brené Brown studies human connection -- our ability to empathize, belong, love. In a poignant, funny talk, she shares a deep insight from her research, one that sent her on a personal quest to know herself as well as to understand humanity. A talk to share.

# data[].attributes.body
Pincipios

# data[].attributes.attachment_link.title
Ray Dalio on LinkedIn: Click here for more on this Principle by Ray Dalio | 102 comments

# data[].attributes.attachment_link.description
Understand the concept of "by-and-large" and use approximations. Because our educational system is hung up on precision, the art of being good at approximations... 102 comments on LinkedIn

# data[].attributes.attachment_link.title
Forget what you know | Jacob Barnett | TEDxTeen

# data[].attributes.headline
How Companies Can Profit from a “Growth Mindset”

# data[].attributes.subject
How Companies Can Profit from a “Growth Mindset”

# data[].attributes.attachment_link.readable_text
When Carol Dweck was a graduate student, in the early 1970s, she began studying how children cope with failure-and she quickly realized that "cope" was the wrong word. "Some didn't just cope-they relished it," she says. "For some people, failure is the end of the world-but for others, it's this exciting new opportunity." Dweck, now a psychology professor at Stanford, spent the next several decades studying this dichotomy, which she originally described using the clunky academic monikers "fixed mindset entity theory" and "incremental theory." By the early 2000s, while writing a mass-market book on the topic, she'd come up with more-appealing labels. She now refers to people who view talent as a quality they either possess or lack as having a "fixed mindset." People with a "growth mindset," in contrast, enjoy challenges, strive to learn, and consistently see potential to develop new skills. Dweck's framework has had a significant impact: Her book Mindset, published in 2006, has sold more than 800,000 copies, and the concept of a growth mindset has come to permeate fields such as education and sports training.

A version of this article appeared in the November 2014 issue of Harvard Business Review.

# data[].attributes.attachment_link.title
How Companies Can Profit from a "Growth Mindset"

# data[].attributes.attachment_link.description
Stanford's Carol Dweck explores how a key psychological concept applies to organizations, too.

# data[].attributes.headline
The power of believing that you can improve

# data[].attributes.subject
The power of believing that you can improve

# data[].attributes.attachment_link.title
The power of believing that you can improve

# data[].attributes.attachment_link.description
Carol Dweck researches “growth mindset” — the idea that we can grow our brain’s capacity to learn and to solve problems. In this talk, she describes two ways to think about a problem that’s slightly too hard for you to solve. Are you not smart enough to solve it … or have you just not solved it yet? A great introduction to this influential field.

# data[].attributes.attachment_link.keywords[]
mejores prácticas en ingeniería de software

# data[].attributes.attachment_link.title
Manifiesto por el Desarrollo Ágil de Software

# data[].attributes.attachment_link.description
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como ayudando a terceros. Estos son nuestros valores y principios.

# data[].attributes.attachment_link.description
Seguimos estos principios: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechanel cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dossemanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los responsables de negocio y los desarrolladorestrabajamos juntos de forma cotidiana durante todoel proyecto.

# data[].attributes.attachment_link.readable_text
Spoiler alert-this article will end with a call to action, asking for your help to explore a crucial issue that will empower L&D professionals to deliver real value: learning agility, learning to learn and unlearn at speed.

But first, here's a quote about fish.
"In the new world, it is not the big fish which eats the small fish, it's the fast fish which eats the slow fish."
-Klaus Schwab

As executive chairperson of the World Economic Forum, Schwab is helping to popularize our understanding of the fourth industrial revolution -an era of rapid change where advances in technology are disrupting the way we work and live.

It'll be a while before the dust settles on the impact of AI, the rise of the "gig economy," and the influence of cryptocurrencies, but it's hard to deny that we're experiencing continued and accelerated change.

Automation has already taken over many repetitive, simple tasks, demanding that people climb Bloom's Taxonomy and embrace higher order thinking and complex skills. You've probably seen countless "top skills for the future" lists. Here's another (Figure 1):
Figure 1: These are the skills that are most needed as work evolves to demand higher order thinking.
This understanding has guided my professional direction for some time, leading me to identify three key areas of capability:

thinking, which encompasses empathy, collaboration and problem solving

Learning agility, which, as noted above, is essentially learning to learn and unlearn at speed

Leveraging digitally driven performance data, including xAPI

Learning agility
For now, I'll focus on learning agility.

This conversation harks back to the ground-breaking work by Peter Senge around " learning organizations " during the 1990s, although the increased pressure of speed is a crucial development that has seen renewed interest in "agility" come to the fore.
Learning agility is the ability to continually and rapidly learn, unlearn, and relearn mental models and practices from a variety of experiences, people, and sources, and to apply that learning in new and changing contexts to achieve desired results.
Here is an extended definition:
Figure 2: How learning agility emerges through reflection and experience.
In terms of how to achieve this, I'm influenced by Kolb's experiential learning cycle and would argue that learning agility is achieved through a continuous, rapid, and dynamic flow between reflection and experience, which I've captured in Figure 2.
A reality check and opportunity for L&D
In reality, this is never a simple progressive cycle; it's a messy and unpredictable process that leaps from point to point. In addition, learning agility can and must play out at multiple levels, for individuals, teams, and organizations. Finally, it's a process that can be improved.

That last point is particularly relevant for L&D professionals. While traditionally our industry has focused on delivering "event-based training," this brave new world is calling-even demanding-for us to improve and expand our offerings. Just as other industries are transforming, L&D professionals must become experts in enabling rather than training. This involves designing learning ecosystems and using a range of strategies to support these dynamic cycles of experience and reflection.
Learning agility for individuals
In my opinion, that means we must explore, master, and champion learning agility.

Until recently, I've focused much of my attention on how an individual (rather than organization) can become a powerful, agile learner.

Practicing what I preach, I've spent countless hours studying agile learners (especially gamers and developers), as well as reading, experimenting, and working out loud around this topic.

My research culminated in the launch of the Learn2Learn app, which explores 18 key topics to empower individuals with learning agility. These include how to:

● Learn and unlearn a diverse range of mental models for creative problem solving;

● Use feedback to improve cycles of deliberate practice;

● Use performance support to lower cognitive load;

● Reflect and make sense of complex information and experiences; and

● Fail faster, with prototyping and root cause analysis to learn more from failure.
Figure 3: Key practices that develop and support learning agility. Learning agility for organizations
I've captured and chunked these topics in an infographic (Figure 3):

Although I have given you a quick taste of how individuals can develop learning agility, that's not what I intend to focus on here. After all, there's an app for that. What I'm particularly interested in exploring is how this plays out at an organizational level.

In today's era of accelerated change the billion-dollar question is: How can organizations enable and harness learning agility to better meet their goals?

With the drive to meet customer needs more deeply and rapidly, the answer to the above question represents the ultimate competitive advantage. Solving it will enable organizations to rapidly adapt, innovate, and even lead disruption.
Figure 4: Enabling learning agility within organizations happens through specific interactions.
In other words, as the fourth industrial revolution continues to unfold, learning agility will be the difference between an organization thriving or disappearing.
Your mission, should you choose to accept it...
So how do we enable learning agility in organizations? Figure 4 represents some of my work in progress.

Rather than a definitive model, I present this in the spirit of encouraging discussion and debate. It's also a timely moment for me to circle back to the call to action I mentioned earlier.

This is the first article in a monthly "learning agility" series I'll be writing for Learning Solutions.

I don't intend to write a traditional column. Rather, I'm inviting you to be part of a conversation that will help arm L&D professionals with ideas, strategies, and techniques to enable learning agility.

I intend to use these articles to support that conversation by working out loud and sharing experiments, ideas, case studies, interviews, research and more.

Please join in by:

Sharing your experiences in enabling learning agility with me directly via Linkedin or Twitter (and possibly be featured in future columns)

Providing feedback and thoughts via the comments function below this article

Sharing this article and inviting others to participate

The second article in this series will feature Brian Murphy, head of learning and leadership at Citi. It will highlight how a marketing-styled campaign helped encourage a culture of continuous learning.

But please, don't wait a month to contribute. We're at an important juncture where L&D risks being relegated to the irrelevance of order takers and "checkbox training," even as learning agility is becoming the new currency for success.

I remain confident that together we can develop strategies to embrace Option B- where we enable people and organizations to learn, innovate, and adapt faster than ever before.

So again, I ask for your help. Please share your experience of developing learning agility, and how this conversation is playing out in your world. Does Figure 4 resonate with you, or would you add other factors? And what case studies or topics would you like me to explore in future columns?

# data[].attributes.attachment_link.description
Spoiler alert-this article will end with a call to action, asking for your help to explore a crucial issue that will empower L&D professionals to deliver real value: learning agility, learning to learn and unlearn at speed. But first, here's a quote about fish.

# data[].attributes.attachment_link.readable_text
La planificación de las tareas a realizar en la iteración se divide en dos partes:

QUÉ: Primera parte de la reunión. Se realiza en un timebox de alrededor de 2 horas (si la iteración es de 2 semanas):

El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.

El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios que prevé completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

. CÓMO: Segunda parte de la reunión. Se realiza en un El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que es el responsable de organizar su trabajo y es quien mejor conoce cómo realizarlo.timebox de alrededor de 2 horas (si la iteración es de 2 semanas)

Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de hecho (DoD).

Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.

Los miembros del equipo se autoasignan las tareas que pueden realizar, se autoorganizan para trabajar incluso en parejas (o grupos mayores) con el fin de compartir conocimiento (creando un equipo más resiliente) o para resolver juntos objetivos especialmente complejos.

Beneficios

Productividad mediante comunicación y creación de sinergias:
Todos los miembros del equipo tienen una misma visión del objetivo y se ha utilizado los conocimientos y las experiencias de todos para elaborar la mejor solución entregable en el mínimo tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.

Potenciación del compromiso del equipo sobre el objetivo común de la iteración:

Es todo el equipo quien asume la responsabilidad de completar en la iteración los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algún impedimento que bloquea el progreso de la iteración, especialmente si cuando se está llegando al final de la iteración es necesaria la participación de todos para poder completar los objetivos previstos.

Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se autoasignó) en los tiempos que proporcionó. Si existe falta de compromiso con respecto al resto de miembros del equipo se hará muy evidente en las reuniones diarias de sincronización del equipo (Scrum daily meeting) .

Una estimación conjunta es más fiable , dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo.

Artículos relacionados

# data[].attributes.attachment_link.title
Planificación de la iteración (Sprint Planning)

# data[].attributes.attachment_link.description
La planificación de las tareas a realizar en la iteración se divide en dos partes: QUÉ: Primera parte de la reunión. Se realiza en un timebox de alrededor de 2 horas (si la iteración es de 2 semanas): El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a...

# data[].attributes.attachment_link.readable_text
El Sprint Planning es el primer evento de Scrum en dónde se planifican las tareas a realizar en el Sprint en curso. En esta reunión participan, de manera colaborativa, todo el equipo Scrum: Scrum Master, Product Owner y Equipo de Desarrollo.

Características del Sprint Planning

El tiempo de esta reunión es de máximo 8 horas para Sprints de 4 semanas de duración. Para Sprints de menor duración, esta reunión debe proporcionalmente ser más corta. El Scrum Master es el encargado de asegurar que esta reunión se realice, se enseñe la importancia de la misma, y además debe asegurarse de que se realiza en el tiempo establecido.

La labor del Product Owner es la de describir las tareas con mayor prioridad al resto del equipo, estas tareas deben ser las que aparezcan en la parte superior del Product Backlog. El Equipo de Desarrollo pregunta todo lo necesario para convertir estas historias de usuario en tareas más específicas.

El Product Owner no debe explicar el 100% de los ítems del Product Backlog, es una buena práctica que los dueños de producto se presenten a esta reunión preparados para hablar sobre ítems correspondientes a 2 Sprints.

El Sprint Planning responde a las dos siguientes preguntas:

¿Qué se puede hacer en este Sprint?

¿Cómo haremos el trabajo elegido?

¿Qué se puede hacer en este Sprint?

En esta parte, el Equipo de desarrollo pronostica su capacidad de desarrollo en el Sprint. El Product Owner explica el objetivo de la iteración, y los ítems del Backlog que se deberían hacer para conseguir el objetivo final. Todo el equipo trabaja de manera colaborativa para comprender el trabajo a realizar.

Entra en importancia el Product Backlog, el último incremento desarrollado, la capacidad del equipo de desarrollo y el rendimiento en el Sprint anterior. Todos los items que se seleccionen del Product Backlog son decisión exclusiva del Equipo de desarrollo.

Durante el Sprint Planning se define el Sprint Goal, que es objetivo que el equipo Scrum debe conseguir para una correcta evolución del proyecto.

¿Cómo haremos el trabajo elegido?

Con el Sprint Goal y los ítems del Product Backlog seleccionados, el equipo de desarrollo decide cómo convertir estas historias de usuario en incremento de producto. Los items seleccionados del Product Backlog reciben el nombre de Sprint Backlog.

Cabe destacar que no es necesario que se planifique el desarrollo del 100% de las historias de usuario, es buena práctica planificar el trabajo de los primeros 2 días, y descomponer esta planificación en varias reuniones, con esto se gana agilidad y productividad.

Al final de la reunión, el equipo de desarrollo debe ser capaz de explicar tanto al Product Owner como al Scrum Master como van a trabajar de manera auto-organizada para conseguir desarrollar todos los items del Sprint Backlog, y conseguir el objetivo definido en el Sprint Goal.

🔥 Bonus: ¿Cómo planificar un Sprint en Scrum?

Si recordáis la película, "Atrapado en el Tiempo", protagonizada por Bill Murray, consistía en una repetición temporal del mismo día. Casualmente era el día de la marmota, famoso en Estados Unidos porque sirve para prever si el invierno va a durar mas o menos tiempo, en función de lo que haga una marmota.

Si la marmota al salir de su madriguera no ve su sombra, dejará la madriguera, lo cual significa que el invierno terminará pronto. Si por el contrario, la marmota ve su sombra y se mete de nuevo en la madriguera, significa que el invierno durará seis semanas más.

El día amanece con un objetivo que es desvelado cuando la marmota ve o no ve su sombra.

Cuando ejecutamos un sprint en scrum, podría asemejarse al día de la marmota, donde el comienzo del sprint se produce cuando suena el despertador y donde el conjunto de acontecimientos que van sucediendo depende de las acciones que el protagonista realiza durante el "sprint".

Se va adaptando a los nuevos cambios, y orientando todo a su objetivo final que es el de conseguir que la chica se enamore de él, y salir del bucle.

Si asemejamos la ejecución de un sprint a la película, podemos encontrar algunas similitudes.

Ambos se repiten en el tiempo como un bucle.

Las acciones principales se repiten día a día si no hay un acontecimiento importante que lo impida.

El día y el sprint comienzan y acaban en un determinado momento, suceda lo que suceda.

Ambos nacen con un objetivo, y se llevan acciones para conseguirlo. (Phill quiere enamorar a Rita - En nuestro sprint trabajamos por un incremental de valor del producto)

La planificación del sprint debemos hacerla teniendo en cuenta que una serie de acontecimientos deben repetirse en el tiempo, puesto que son los que nos garantizan una entrega incremental de valor.

Pero debemos adaptarnos a los cambios surgidos en el sprint en scrum.

Si por ejemplo necesitamos hacer estimaciones de tareas que nos requieren mas de 1 hora de reunión, podemos hacer 2 reuniones de refinamiento de 1 hora cada una, en vez de una sola por sprint. O si vemos carencias en el detalle funcional de las tareas, podemos incluir alguna reunión previa al refinamiento del PO (Product Owner) y el SM (Scrum Master) para que se detalle a nivel funcional con mayor profundidad estas tareas.

Es decir, nos vamos adaptando continuamente al cambio, para conseguir un objetivo que es el de conseguir el objetivo del sprint o que Rita se enamore de Phill como en la película que hemos comentado.

Otro punto importante es controlar los tiempos y puntualidad de comienzo y fin de las reuniones. Si observamos que este punto no se cumple, debemos incluirlo en el orden de la retrospectiva para revisar por que esta pasando y adaptarnos. Nos comprometemos con un objetivo considerando un trabajo asumible en el sprint. Si disminuimos el tiempo que podemos dedicar al trabajo no podemos asegurar la entrega.

Si tenemos certeza de la entrega de producto incremental, debemos convocar con suficiente antelación a los interesados principales de negocio que decida el PO, enviándoles una convocatoria de la Review del sprint. En realidad si todos los sprints entregamos valor, los interesados deberían ir cada sprint a la Review. Este es un punto complicado de conseguir, pero clave para conseguir un alineamiento real del desarrollo del producto con las necesidades de nuestros clientes. Comentaremos este tema con mas detalle en otra entrada.

La reunión retrospectiva debe ser variada, para que el equipo no piense que esta repitiendo el día de la marmota cada sprint, dándole dinamismo e incentivando la participación. Podemos encontrar mas detalle en la entrada de como planificar una retrospectiva.

En definitiva, el sprint en scrum debe regirse por unas bases que deben repetirse en el tiempo pero adaptándolas a las propias necesidades del momento en el que nos encontremos.

# data[].attributes.attachment_link.title
¿Qué es el Sprint Planning? + 【Bonus】Cómo planificar un Sprint

# data[].attributes.attachment_link.description
El Sprint Planning es el primer evento de Scrum en dónde se planifican las tareas a realizar en el Sprint en curso. En esta reunión participan, de manera colaborativa, todo el equipo Scrum: Scrum Master, Product Owner y Equipo de Desarrollo. El tiempo de esta reunión es de máximo 8 horas para Sprints de 4 semanas de duración.

# data[].attributes.attachment_link.readable_text
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (cuando el iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que mínimo para que el producto este disponible para ser utilizado. cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo colabora estrechamente y se llevan a cabo las siguientes dinámicas:

Para poder completar el máximo de requisitos en la iteración, se debe minimizar el número de objetivos/requisitos en que el equipo trabaja simultáneamente (WIP, Work In Progress), completando primero los que den más valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteración, permite tener más capacidad de reacción frente a cambios o situaciones inesperadas.

No se puede cambiar los objetivos/requisitos de la iteración en curso

En la reunión de planificación de la iteración el equipo realizó una previsión de los objetivos que podría completar en la iteración unos requisitos concretos, basó su plan y organización en ellos. Cambiar los objetivos/requisitos de la iteración dificulta la concentración del equipo, baja su moral y su compromiso.

El hecho de no poder cambiar los objetivos/requisitos de la iteración una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qué es lo más prioritario a desarrollar, antes de iniciar la iteración.

Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se están desarrollando eran los más prioritarios justo antes de iniciar la iteración y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas) como para que la probabilidad de cambios una vez iniciada la iteración sea mínima.

Terminación anormal de la iteración
Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteración para aplicar cambios, o si el equipo encuentra que es imposible cumplir con la previsión de objetivos que se planteó entregar. En ese caso, se dará por finalizada la iteración y se dará inicio a otra mediante una reunión de planificación de la iteración.

Artículos relacionados

# data[].attributes.attachment_link.description
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este...

# data[].attributes.attachment_link.readable_text
El Sprint Review es uno de los cinco eventos de Scrum, y ocurre en el final del Sprint, para inspeccionar el incremento y adaptar el Product Backlog en caso de que sea necesario. Es una gran oportunidad para poder recibir feedback sobre el desarrollo del producto.

Es una reunión informal, y el objetivo principal del Sprint Review es brindar transparencia tanto al equipo como al cliente.

Tiene una duración de 4 horas para Sprints de 4 semanas. Para Sprints más cortos, esta reunión tenderá a ser más corta. Este evento es organizado por el Product Owner, y es necesaria la presencia de todo el equipo de Scrum. El rol del Scrum Master es asegurar que el evento ocurre y que cumple los tiempos establecidos, además de asegurar una colaboración de todo el equipo.

Características del Sprint Review

El Product Owner se encarga de organizar e invitar al evento tanto al cliente como a todo el equipo Scrum.

El Product Owner explica qué items del Product Backlog han sido finalizados, y cuáles no. Es importante tener en cuenta que las tareas terminadas deben respetar el Definition of Done.

El equipo de desarrollo se encarga de hacer la demostración del incremento terminado durante el Sprint.

El equipo de desarrollo, principalmente, responderá a cuestiones relacionadas con el incremento. La normal es que la mayoría de las preguntas sean técnicas.

El Product Owner comenta sobre el estado del Product Backlog.

Se realiza una review del proyecto, y sobre qué es lo siguiente que se hará. En base a esto, el Product Owner se encarga de reorganizar el Product Backlog en caso de que surgiera feedback por parte del cliente.

Se hace una review sobre tiempos, presupuesto y alcance del proyecto para futuros Sprints.

¿Qué se obtiene como resultado?

El resultado del Sprint Review es un Product Backlog revisado y organizado, que probablemente definirá los items a realizar en el siguiente Sprint. Conseguimos además un mejor alineamiento con negocio con entrega continua y reducir desviaciones.

Además, confirmaremos el incremento de producto, por el feedback que nos dará el cliente.

Buenas prácticas

El Sprint Review no es solo una demo, recordemos que el principal resultado es un Product Backlog revisado, así que el feedback del cliente es importante, pero no solo para la demostración, si no para tener una visión común de lo que se realizará en el siguiente Sprint.

Enfocarse en los objetivos de negocio, esto va relacionado a la organización del Product Backlog. La tendencia es centrarse en la demostración del incremento, pero mirar los objetivos de negocio es mirar los intereses del cliente. Dichos objetivos los debemos de tener siempre en el Product Backlog.

No olvidar que podemos organizar el Product Backlog en otro momento, el feedback del cliente es importante, pero no olvidemos que puede cambiar de un día para otro. Lamentablemente muchos clientes son así, por lo que en el Sprint Review tendremos feedback, pero nuestro Product Backlog puede cambiar en cualquier momento.

# data[].attributes.attachment_link.title
¿Qué es el Sprint Review? ¿Para qué sirve? ⋆ Be Agile My Friend

# data[].attributes.attachment_link.description
El Sprint Review es uno de los cinco eventos de Scrum, y ocurre en el final del Sprint, para inspeccionar el incremento y adaptar el Product Backlog en caso de que sea necesario. Es una gran oportunidad para poder recibir feedback sobre el desarrollo del producto.

# data[].attributes.attachment_link.readable_text
El sprint retrospective meeting (retrospectiva) es el último evento en un Sprint en Scrum. Es una oportunidad para el equipo de inspeccionarse a sí mismo, y crear un plan de mejora que se pondrá en marcha inmediatamente, en el siguiente Sprint.

Este evento se realiza después del Sprint Review, tiene un tiempo máximo de duración de 3 horas para Sprints de 1 mes, por supuesto para Sprints más pequeños su tiempo de duración será proporcionalmente menor.

¿Cuál es el objetivo de la retrospectiva?

El objetivo de un sprint retrospective meeting es, básicamente, mejorar: mejorar la productividad, mejorar las habilidades del equipo, mejorar la calidad del producto. En resumen, el objetivo es mejorar la aplicación de Scrum.

Otro objetivo es hacer foco en el equipo, analizando cómo trabajamos y cómo nos relacionamos, para buscar posibles mejoras que el mismo equipo aplicará.

¿En qué consiste?

Previo a la sesión, cada miembro del equipo debe hablar de los siguientes puntos:

Qué ha funcionado bien en el último Sprint.

Cuáles cosas hay que mejorar de cara al siguiente Sprint.

Problemas que haya tenido para poder progresar correctamente en el último Sprint.

Recomendaciones a aplicar en el siguiente Sprint.

Al realizarse después del Sprint Review, podemos incorporar el feedback que hayamos obtenido dentro de los puntos a hablar.

¿Quiénes deben participar?
Debe participar el equipo completo de Scrum, no existen distinciones entre todos los miembros del equipo.
El Scrum Master es el encargado de que esta sesión se realice dentro de los tiempos y de que cada miembro del equipo entiende cuál es el objetivo del evento. Cuando se detecta un punto de mejora dentro del proceso de Scrum, el Scrum Master se encarga de hacer los cambios pertinentes para mantener las buenas prácticas ágiles.

¿Cada cuánto debe realizarse el Sprint Retrospective?

En cada Sprint, todos los Sprints terminan con el Sprint Retrospective, sin excepción.

Beneficios
El sprint retrospective incrementa la calidad del producto, además de aumentar considerablemente el aprendizaje dentro de los miembros del equipo.
El feedback siempre motiva al equipo a hacer las cosas bien, el hacer cambios para bien gracias a la recomendación de un miembro del equipo invita a que los demás también lo hagan, consiguiendo una mejora colaborativa.

Por último, los cambios siempre se aplicarán en el siguiente Sprint, por lo que cada mejora se verá reflejada a corto plazo, mejorando la productividad.

# data[].attributes.attachment_link.title
Retrospectiva - ¿Qué es el Sprint Retrospective? | Be Agile My Friend

# data[].attributes.attachment_link.description
El sprint retrospective meeting (retrospectiva) es el último evento en un Sprint en Scrum. Es una oportunidad para el equipo de inspeccionarse a sí mismo, y crear un plan de mejora que se pondrá en marcha inmediatamente, en el siguiente Sprint.

# data[].attributes.attachment_link.readable_text
El título de "Scrum Master" suena poderoso, ¿verdad? Pues aunque no lo creas, un Scrum Master no es el líder de un proyecto y tampoco el responsable de los resultados, es el facilitador del equipo ágil, y un líder al servicio de quien lo necesite.

El Scrum Master es un rol muy sustancial dentro de un equipo Scrum, su participación en todos los eventos de un Sprint y haciendo de líder al servicio de los demás, lo convierten en un ingrediente esencial para la armonía del equipo.

¿Qué es un Scrum Master?

El Scrum Master no es lo mismo que el Product Owner. El product Owner tiene una perspectiva bastante más de negocio, en tanto que el Scrum Master tiene como función que todo el equipo entienda Scrum y lo aplique de manera correcta.

Es uno de los roles dentro del equipo Scrum, se asegura de que el framework Scrum se desarrolle correctamente. Es un líder al servicio de un equipo.

Elimina impedimentos, ayuda al equipo de desarrollo a ser más productivo y guía y enseña al Product Owner en la gestión del product backlog.

Además, debe participar en las reuniones y asegurarse de que el equipo Scrum cumpla el tiempo y los objetivos establecidos.

¿Cuáles son sus responsabilidades?

Es el responsable de que Scrum sea entendido y bien aplicado dentro de la organización.

Trabaja junto con el Product Owner y el equipo de desarrollo en la creación de valor en cada sprint. Elimina impedimentos y ayuda a ser más productivo al Equipo de desarrollo.

¿Cuáles son sus funciones?

Entre otras, un Scrum Master debe:

Planificar la implantación de Scrum junto con la organización.

Ayudar a la organización a entender que interacciones con el equipo aportan valor y cuales no.

Asistir al Product Owner a saber cómo organizar el product backlog y maximizar el valor.

Asegurarse de que haya una definición de done.

Comprender y practicar la agilidad.

Ayudar al equipo a crear productos de valor.

Eliminar cualquier impedimento del equipo.

Trabajar con otros Scrum Masters para aumentar la efectividad de Scrum en la organización.

Junto con el equipo Scrum, actualizar el burndown chart.

¿Es el Scrum Master un Project Manager?

El Scrum Master es un líder al servicio del equipo Scrum. En Scrum no existen los project managers, sin embargo ejerce como el manager de Scrum, por la razón de que enseña y evangeliza Scrum dentro de la organización.

Claves para ser un buen Scrum Master

Los errores más comunes del Scrum Master

En ocasiones se cometen fallose en el momento de empezar como Scrum Masters, es por ello, que revisaremos algunos puntos que consideramos incorrectos para que los Scrum Masters puedan desarrollar un mejor trabajo en su día a día.

1. No debe organizar el trabajo del Equipo de Desarrollo, existen muchos Scrum Masters que, según su experiencia pasada, le dicen al Product Owner y al Equipo de Desarrollo las historias de usuario que pueden realizar en un Sprint, calculando su capacidad, y creando un mal clima de trabajo.

2. Nunca debe organizar los eventos de un Sprint. En muchas casos, en los Daily meetings, el Scrum Master se encarga de hacer las tres preguntas. Además de controlar el trabajo de un desarrollador, que se había comprometido con una historia de usuario el día anterior. El Scrum Master debe asegurarse que los eventos se realizan, y que se realizan dentro de los tiempos establecidos.

3. No debe categorizar a los miembros del equipo de desarrollo en roles, no debe asignar "Programadores" o "Testers", esto es trabajo interno del mismo equipo, que debe ser multidisciplinar.

4. No debe proteger al equipo, aislandolo de reuniones importantes como el refinamiento del Product Backlog, por estar con mucha carga de trabajo. Esto suele terminar en un refinamiento hecho solo por el Product Owner y el Scrum Master. El objetivo de estos eventos es que participen todos los miembros del equipo Scrum.

5. No debe obligar a esperar al Sprint Review para la inspección del incremento de producto. Ni tampoco obligar al equipo de desarrollo a no mostrar nada de lo desarrollado en medio de un Sprint. Su trabajo es encargarse de que esta labor de inspección no se convierta en un día a día.

6. No divide los Sprints en "Sprints de incremento" y "Sprints de testing". Tampoco trabaja con "Sprints cero" para la creación de la infraestructura de código.

7. No debe cambiar por si mismo Scrum por "Agilidad", tampoco eliminar eventos que considere innecesarios por falta de tiempo.

8. No debe obligar a que el Product Owner sea el exclusivo responsable de crear las historias de usuario del Product Backlog, así como de que sea el Product Owner el único que de los detalles de cada historia de usuario. El Product Backlog es responsabilidad del Product Owner pero su organización puede ser realizada de manera colaborativa si así se considera necesario. Este tipo de acciones aísla la presión a una sola persona, creando un mal clima de trabajo.

¿Cómo puedo ser en Scrum Master y obtener el certificado oficial?

Si estás pensando en obtener una certificación Scrum Master, te recomendamos que te pongas en contacto con nosotros y te ayudaremos y prepararemos de la mejor manera para que consigas esta certificación tan valiosa para las empresas hoy en día.

Ya seas un responsable de departamento, de formación o directivo en una empresa y buscas un programa para varios alumnos como si eres un profesional particular que desea incorporar este certificado Scrum Master para cualificar tu curriculum y perfil profesional para tener mayor valor en el entorno profesional podemos ofrecerte la formación y certificación necesarios.

# data[].attributes.attachment_link.title
✅ Scrum Master, Qué es y Qué cosas NO debe hacer

# data[].attributes.attachment_link.description
El título de "Scrum Master" suena poderoso, ¿verdad? Pues aunque no lo creas, un Scrum Master no es el líder de un proyecto y tampoco el responsable de los resultados, es el facilitador del equipo ágil, y un líder al servicio de quien lo necesite.

# data[].attributes.body
Piensa afuera de la caja (o del aula). Llegó la hora de los sistemas de aprendizaje

# data[].attributes.attachment_link.readable_text
I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated - Poul Anderson

Este post empieza con dos ejercicios. ¡¿Preparado / preparada?!

Si te digo "no solo de talleres aprenden las personas sino también..." ¡¿qué abren esos puntos suspensivos?! ¡¿Te animás a hacer dibujos durante 3' que representen cómo aprendemos?! No importa que dibujes bien o no, descargá todas las ideas que aparezcan rápidamente en tu cabeza, soltá tu "pluma" y fijate qué aparece. 3, 2, 1... ¡fuera!

¡¿Y?! ¡¿Cómo te fue?! ¡¿Descubriste algo?! ¡¿Hiciste muchos dibujos?! ¡¿Qué apareció en esos dibujos?! (Si te animás, compartilos aquí o en redes #learningchallenge Twitter @latodaterreno / IG @agilecooking @latodaterreno)

Muchas personas se sorprenden con la cantidad de dibujos que hacen y con el hecho de que no reflejan nada que tenga que ver con estudio, cursos ni nada parecido. Esto no es una casualidad: aprendemos a través de nuestras experiencias y hoy este concepto anda dando vueltas en el aire con el nombre de "learning agility".

Learning agility es nuestra capacidad de maximizar el aprendizaje a partir de la búsqueda de experiencias -numerosas, diversas, desafiantes-; de darles sentido: parar, registrar y comprenderlas; de internalizarlas y hacerlas propias y así crear nuevas conexiones y miradas que, finalmente, aplicaremos. Suena lógico pero, a pesar de ello, cuando intento traducirlo a las organizaciones... ¡no me parece tan evidente! Nuestras organizaciones suelen pensar en el "áreas" y "espacios" de aprendizaje estancos y rígidos. El aprendizaje queda encerrado y se hace pequeño, poniéndole límites claros y concisos -el aula, los talleres, el estudio, lo individual-. El reto que tienen nuestras organizaciones hoy es (re)pensarse como sistemas vivos, recordando que todo sistema vivo es ¡un sistema de aprendizaje!

Y para empezar con este desafío, ¡arranquemos por casa! ¡por nosotros mismos! Hagamos un nuevo ejercicio. Si te digo sistemas de aprendizaje, ¡¿qué palabras te vienen a la cabeza? ¡¿qué emociones te aparecen?! Tirá a lo loco lo primero que te venga durante 3'.

¡¿Y?! ¡¿Cómo fue?! Compartime esas palabras también (aquí o en redes #learningchallenge Twitter @latodaterreno / IG @agilecooking @latodaterreno)

Cuando hablamos de sistemas, hablamos de 3 ingredientes: propósito (o función), elementos e interconexiones. Un sistema es más que la suma de las partes: es diverso y está conformado por múltiples elementos interconectados y funciona como una red, líquida e hiperconectada; es dinámico, adaptativo busca su auto-preservación y tiene la capacidad de evolucionar, ser resiliente y aprender de la experiencia. La organización como sistema, el aprendizaje como sistema. Léase: sistema al cuadrado, aprendizaje al cuadrado.

Y todo esto es un gran reto que implica:

Soltar la idea de que las organizaciones (y su aprendizaje) son máquinas que funcionan de forma mecánica para entender que son organismos vivos, dinámicos y complejos. Y como tales: viven y aprenden.

Salir de la idea de que las áreas de RR.HH y/o capacitación son las responsables del aprendizaje de toda la organización y empezar a asignarle un rol protagónico a todas y cada una de las personas, a todos y cada uno de los equipos... Trabajar por una cultura de aprendizaje en la que cada persona es garante de su aprendizaje, del de los suyos... ¡y el de los otros!

Y de la mano de esto, entender que puede haber un plan de enseñanza pero que el aprendizaje no se planifica sino que emerge en el flow del trabajo.

Ampliar la mirada y recordar que el aprendizaje no solo ocurre a nivel "persona" sino que también tiene que haber aprendizaje de los equipos y ¡de la organización! Lo que escuchás: la organización también aprende.

Y para cerrar, recordar que vivir es aprender y aprender es vivir. Por ello, no necesitamos complejos dispositivos de aprendizaje sino saber capitalizar nuestras experiencias y... ¡ponerle conciencia a nuestros días, los de nuestros equipos y nuestras organizaciones!

¡¿Cuán sencillo es pensar en esto?! ¡¿y trabajar en esto?! ¡¿tenemos las herramientas necesarias para hacerlo?! Continuará...

#learningagility #aprendizaje #learningsystem #agilelearning #cookingincovid19 #agilecooking

Published By

# data[].attributes.attachment_link.title
Piensa afuera de la caja (o del aula). Llegó la hora de los sistemas de aprendizaje

# data[].attributes.attachment_link.description
I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated - Poul Anderson Este post empieza con dos ejercicios. ¡¿Preparado / preparada?! Si te digo "no solo de talleres aprenden las personas sino también..."

# data[].attributes.attachment_link.readable_text
Liberating Structures are a collection of 30+ interaction patterns that unflatten, enrich, and deepen interactions in groups. With strong roots in complexity science, and collected by Keith McCandless and Henri Lipmanowicz, all Liberating Structures implement five design elements and ten principles. This means that Liberating Structures are not a rigid, static set of formats. New structures are being developed all the time and existing structures are modified, adjusted, or removed. With Liberating Structures, it's possible to start shifting entire organizations by tweaking the way groups and individuals interact.

"Liberating Structures are a collection of 30+ interaction patterns that unflatten, enrich and deepen interactions in groups."

Learning 3.0 is a concept that enables you to create an environment in which everyone can feel safe to collaborate and to share experiences in order to harness the power of collective knowledge. Alexandre describes this concept in his book " How Creative Workers Learn". In learning 1.0 the expert defines the questions and answers. In learning 2.0 the learner defines questions, the expert provides the answer. In learning 3.0 the learner defines questions and answers. The motto here is "sharing is the new teaching". It's up to the facilitator to create an environment where participants are invited to share experiences and to create a learning space.

"Sharing is the new teaching"

The Five Design Elements of Liberating Structures

The five design elements of Liberating Structures offer a structure in which creating knowledge, gathering information, and sharing ideas can occur.

1. The invitation is the question or topic you want people to explore with the Liberating Structure you have in mind (e.g. "What opportunities do you see to move forward?").

2. How space is arranged and what materials are used refers to all the options you have tangible and intangible elements such as tables, chairs, projector, paper, flip charts, or how to use the space e.g. face to face or sitting in a circle.

3. How participation is distributed clarifies how much time every participant will be given to contribute (e.g. "Divide 10 minutes between the four of you").

4. How groups are configured refers to the composition of a group (e.g. first pairs, then groups of four)

5. The final design element is about the sequence of steps and the time allocated to each step (e.g. 1 minute alone, 2 minutes in pairs, 4 minutes in groups of four).

The Learning 3.0 Flow

In a way, Learning 3.0 offers "design elements" as well, it's called "The Learning 3.0 Flow". In the Learning 3.0 flow, the creative workers are the protagonists of their own learning. They problematize what needs to be learned; integrate this with their real-world and share what they have learned. The construction of knowledge begins taking as it's based on a problem or challenge from the real world, which is what is called problematization. From this follows a sensemaking process, which gives meaning to the organized material or results that will collide with your real world. The learning cycle is complete only after sharing the knowledge that has been built.

The Learning 3.0 Flow by Alexandre Magno

Learning 3.0 is about emergent learning over-prescriptive learning. The latter is based on knowledge and skills that are pre-determined for the learners - not based on their own needs. Learners are like empty containers into which experts deposit knowledge. Emergent learning happens when it is self-organized. It arises in unpredictable environments from relationships among a number of people and resources within a context in which learners organize and determine to some extent both the process and the learning destinations.

"Learning 3.0 is about emergent learning over prescriptive learning."

The whole idea is that learning is best done by people acquiring ideas from various sources, running experiments in their own context, and then sharing insights with their peers. It's about creating your own knowledge, by gathering, experimenting, and sharing.

Given the design elements of Liberating Structures and the flow of Learning 3.0, it makes sense to combine them. Liberating Structures enables 'problematizing', supports 'sensemaking' and encourages 'sharing'. To make this more tangible, I'll offer some concrete examples.

Creating a learning canvas during the Learning 3.0 workshop in 2016

Although Liberating Structures and Learning 3.0 can be combined, not every structure fits only one of the Learning 3.0 phases. For example, Critical Uncertainties can be used for both 'problematizing' and 'sensemaking'. Conversation Cafe is ideal for 'sensemaking' but offers space for 'sharing' as well. I've taken the freedom to connect it to the phase in which I think it can be used ideally.

Also, when doing the 'problematizing-phase' individually, it doesn't make sense to use Liberating Structures. Therefore, I'm going to assume you're doing the problematizing-phase as a group.

# data[].attributes.attachment_link.title
How Liberating Structures and Learning 3.0 Are Complementary

# data[].attributes.attachment_link.description
Liberating Structures are a collection of 30+ interaction patterns that unflatten, enrich, and deepen interactions in groups. With strong roots in complexity science, and collected by Keith McCandless and Henri Lipmanowicz, all Liberating Structures implement five design elements and ten principles. This means that Liberating Structures are not a rigid, static set of formats.

# data[].attributes.body
Webinar (Daniela Andrada)

# data[].attributes.attachment_link.title
Estructuras Liberadoras | Practia Academy

# data[].attributes.body
Takeshi Yoshida

# data[].attributes.attachment_link.readable_text
Why brainstorming doesn't work

That was fun, but... Why do we get that slight, lingering feeling of doubt and dissatisfaction after brainstorming sessions?

Here's why:

Group dynamics: 80/20 rule applies.

Domination: The vocal minority dominate the space, crowding out the voices of the rest.

Judgment and hesitation: Our fear of being wrong and looking stupid makes us shut up.

Ideas evaporate: We can't really listen and think at the same time, so our nascent ideas quickly dissipate while waiting for our turn to speak.

Social loafing: We become mentally lazy in groups - let others do the thinking!

Linear outcome: It's so hard to do dissociated thinking (thinking of something separate - out of the box) during a group conversation.

Anchoring bias, recency bias: The vocal minority, often the leader of the group, speaks up first, and unintentionally sets the tone of the discussion which will carry to the end. And as we place priority to the last piece of information heard, we tend not to deviate from the chain of discussion, making the conclusion somewhat predictable.

False-consensus effect, bandwagon effect: We tend to think that others think like we do. So if the vocal minority hears no disagreement, they take that as an agreement. And if everyone seems to be agreeing, we tend to follow too.

Brainstorming doesn't unleash the potential of the group, rather it makes each individual less creative.

Bringing together the best of divergent and convergent thinking

However, the one good thing about brainstorming is that, it brings people together. Working towards a group consensus in a high energy, participatory way produces a strong sense of collective achievement.

So, while brainstorming misses out on the strength of divergent thinking with individuals, it does tap into the strength of convergent thinking with the group.

Now that we know this, we just need to think of better ways to facilitate group thinking that excels in capturing both strengths of divergent and convergent thinking of the individual and group.

Design Thinking

Design Thinking is a powerful cognitive and action framework that not only helps idea generation better, but goes all the way to testing those ideas and iterating the process until ideas that work are nailed.

It is naturally a group process that is aimed to activate the creativity in everyone. A notable characteristic in the Design Thinking process is in the divergent and convergent "double diamond":

1. Empathize: For any given challenge, the team first identifies who are the customers, stakeholders, partners and other "actors" in the scene, and start with a divergent exercise of understanding them, e.g. their wants and needs.

2. Define: And then the team moves onto converging those thoughts into a problem statement, e.g. "Customer needs a way to..., because... It would be great if we can..."

3. Ideate: Next, the team diverges into generating many solution ideas for solving the problem; i.e. "How might we...?"

4. Prototype: The team then converges those ideas into a choice of a single or small set of solutions that they will build a prototype - something that will allow them to test the validity of problem statement ("Are we solving the right problem?") and the solution ("Is this solution solving the customer's problem?").

5. Test: Finally, the team sets up an opportunity to test the prototype to validate its effectiveness. The most important part is the learning - clearly it's not expected to nail the solution in one go, and the objective here is measurement and feedback into any of the Design Thinking process to iterate and experiment for a more effective solution.

Another important attribute is that, as with many other Agile approaches, Design Thinking is process driven, but not fixed process. In fact, because of the highly creative nature of the approach, Design Thinking can be a non-linear process:

Strategy session facilitation with Design Thinking

The beauty of Design Thinking is that it can be done in any scale. We can do it as a quick 30 minute table exercise, a one or two day workshop, or make it into a full few days lab and field experiment.

I very like using Design Thinking as the basic framework for strategy formation. Often when we are in problem solving mode, we don't separate the problem and solution. Thinking of what and how separately allows us to clarify and explore better - ultimately leading to better outcomes. Another trap that we often fall into is, not recognizing that ideas are hypotheses, and solutions are not real solutions yet until proven effective. Design Thinking forces us to test, measure and validate our assumptions and actions. And by doing this in iteration with light-weight prototypes, it is a very fast and cost effective way to find solutions in complex challenges.

Liberating Structures

Often in combination with Design Thinking, my other go-to facilitation toolkit is Liberating Structures.

Liberating Structures is a collection of powerful team exercises curated by Henri Lipmanowicz and Keith McCandless ( www.liberatingstructures.com). Currently there are 33 exercises listed on Henry and Keith's website. I also share my session instructions slides with abbreviated instructions and modified content here: https://agile-od.com/mental-models/liberating-structures.

Here are some of my favorites:

1-2-4-All

The first step of 1-2-4-All is a solo exercise where people write down their thoughts individually. This is a subtle yet incredibly important point: it directly addresses the many problems of group thinking in brainstorming mentioned above.

Individuals ideas are next shared in groups of 2, 4 and finally with the whole group. During this process there will be divergence and convergence of ideas, through repeat sharing and consensus building.

Jake Knapp, author of the Design Sprint book, coined the term "Thinking alone, together" for alternative ways of group thinking. 1-2-4-All is one such way. It's quick, easy and effective. I regularly use this for my sessions.

Min Specs

Min Specs is an example of a Liberating Structure that I often use with Design Thinking.

In Agile, whether it is Design Thinking, Lean Startup or Scrum, we build prototypes and MVPs (minimum viable products) to test the market first. We do this in iteration before building a full product so that we can prevent ourselves from building something that people won't buy.

The challenge is that a lot of us have a tendency to start building a full product from the get-go. Even if it's not a full product, still, we try to make a pretty meaty one.

A completely stripped down, lean version of the product, is something that is hard to imagine for many of us. This is a simple yet powerful exercise that addresses the challenge.

DAD - Discovery & Action Dialogue

We have a chronic challenge - a recurring problem X.

Let's find Positive Deviant Behaviors and practices that will help us solve this problem.

Ecocycle Planning

Organizations are systems. Organizations will always be in a state of equilibrium, but that doesn't necessarily mean it's in an optimum state with respect to the organization's objectives set by its members.

In Ecocycle Planning, we address organizational inefficiencies and resource allocation imbalance by tackling two traps: poverty trap, and rigidity trap.

25/10 Crowd Sourcing

I like to do this exercise after individually brain-spilling for ideas with a separate exercise called Crazy 8.

After individually selecting the one best idea from the eight, we go into 25/10 and let the ideas compete in the group.

It's good to keep the ideas anonymous during the 25/10. That would let the ideas go through the iterative scoring without anchoring or bias, and will let the genuinely best idea emerge as the group's choice.

15% Solutions

This is a great exercise to identify low hanging fruit, immediately actionable solutions.

WINFY: What I Need From You

But of course, all organizations can't get away from dependency challenges.

Use this exercise to sort them out.

What, So What, Now What?

This is my favorite closing exercise. I use it almost every session.

The exercise allows participants to recap the learnings, think of the relevancy of those learnings for themselves, and make each individual accountable for next step actions.

Visit here for more Liberating Structure ideas: https://agile-od.com/mental-models/liberating-structures

All pieced together...

This is what we can get done in three hours! An example of a facilitated strategy session with Design Thinking + Liberating Structures:

PDF version: Design Thinking + Liberating Structures facilitated workshop design example - 3 hour session

Would you like Coach Takeshi facilitate your next high-stakes strategy session with Design Thinking and Liberating Structures?

Reach out: https://agile-od.com/takeshi#contact

# data[].attributes.attachment_link.title
How to use Design Thinking & Liberating Structures for High Stakes Decision Making

# data[].attributes.attachment_link.description
Because brainstorming & group thinking is notoriously ineffective Why brainstorming doesn't work That was fun, but... Why do we get that slight, lingering feeling of doubt and dissatisfaction after brainstorming sessions? Here's why: Group dynamics: 80/20 rule applies. Domination: The vocal minority d

# data[].attributes.attachment_link.title
Elevator pitch. Tienes 20 segundos - eduCaixa

# data[].attributes.attachment_link.description
Backlog prioritisation is the sole responsibility of a product owner. The product owner owns the backlog, which means he/she has full control and mandate over its prioritisation, which makes it a very crucial part of the role.

# data[].attributes.attachment_link.readable_text
The Scrum Master is a complex, challenging and rewarding role. Consequently they need to develop a broad range of competencies. A diverse skill set will allow them to succeed; no matter what the world throws at them and their team.
What follows is the list of competencies that I believe a great Scrum Master / agile Iteration Manager should develop over time.

August 2014: I updated list in conjunction with adding my
Agile Coach Competencies blog. Additionally a two page PDF cheat sheet of Scrum Master Competencies are now available.

Organising the Team

* Knowledge of Scrum rules
* Communicating internally
* Communicating externally
* Up to date Team level documentation
* Reporting team status
* Involving whole team in Sprint planning

* Provides Clear Direction

* Dealing with impediments

* Effective Facilitation

* Using Collaborative engagement techniques

Improving the team

* Managing Technical Debt
* Establishing a good Team Culture

* Using Agile Technical Practices

* Using Continuous Validated Learning

Effective Retrospectives

Influence without authority

Challenging the status quo

Kaizen / Continuous Improvement

Celebrate successes

* Using Lean principles in decisions
Establishing a Self-organising team

* Exhibit Servant leadership
* Exhibit Scrum Values
* Using Agile Principles in decisions
* Ownership of team commitments
* Making it visible & get the team to take action
* Get team to identify and remove impediments
* Involving whole team in grooming / design
* Involving whole team in medium term planning
* Encouraging 'leaders' within the team
* Do yourself out of a job

Thinking Big

* Basic medium term planning
* Visualise teams medium term progress
* Ownership of Department level commitments
* Optimising the whole

High level knowledge of medium term plan for all teams

Volunteering to help other teams

* Communicating with other teams
* Identifying and resolving cross team impediments
* Improving cross team Technical Practices
* Recording appropriate feature information for future teams
* Up to date Department level documentation
* Up to date Company level documentation
* Improving other Scrum Masters and POs

* Balances Responsibilities of SM, Team Contribution, Self-Development
* Learns by reading / researching
* Learns by experimenting / doing
* Learns by discussing
* Coachable

User Stories

Other Characteristics

Getting Team Based Results

* Team delivering consistently
* Team regularly finishing their top priority stories first
* Team regularly finishing >=33% of stories prior to the Sprint half way mark
* Team and PO collaborating extensively on stories (planning, splitting, design, implementation, verification)
* Team not building up inappropriate Technical Debt
* Retrospectives regularly result in positive changes
* Innovation is occurring

Your Thoughts...

# data[].attributes.attachment_link.description
The Scrum Master is a complex, challenging and rewarding role. Consequently they need to develop a broad range of competencies. A diverse skill set will allow them to succeed; no matter what the world throws at them and their team.

# data[].attributes.attachment_link.readable_text
En una entrevista, una vez me preguntaron: como Agile Coach, ¿cuál sería la primera intervención que harías en un equipo? Sin haberlo pensado antes lo primero que se me vino a la mente fue: Asistir a la Daily Scrum en calidad de observador.

Años después y tras haber trabajado con muchos equipos desde Kleer, me encuentro validando mi punto de vista inicial y sosteniendo que:

La Daily Scrum es el momento de mayor ancho de banda y eficiencia sobre la dinámica y la cultura de un equipo Scrum que un Agile Coach puede aprovechar.

El ancho de banda es la cantidad de información disponible por unidad de tiempo. Y la eficiencia es relación entre ambas dimensiones: la gran cantidad de información y la breve duración de la reunión. En tan sólo 15 minutos, un Agile Coach puede obtener mucha información valiosa.

Y la gran ventaja es que a diferencia de otros eventos de Scrum, es una oportunidad de aprendizaje que ocurre todos los días.

El tablero de tareas y otros radiadores visuales de información (si existen) tienen mucha información útil, pero son sólo un poster, donde la Daily Scrum son los trailers de la película. En la Daily Scrum vemos tablero y al equipo en acción.
¿Y la Calidad de la Información?
Gracias a la experiencia y la capacidad de escucha y de observación, el Agile Coach puede obtener información realmente útil.

Incluso cuando el Agile Coach tiene muy poco contexto sobre el equipo o el producto que desarrollan, puede percibir información valiosa, ya que no se centra en el contenido, sino en la calidad del proceso, la estructura y las relaciones.

Las observaciones, deben ser tomadas como lo que son. El primer paso es validarlas con el Equipo antes de operar con base en supuestos.
¿Qué observar?
El siguiente es un listado de los aspectos a los un Agile Coach debe prestar atención.

Cómo es el estado de ánimo del Equipo.

Cómo es el entusiasmo, interés y motivación del Equipo para con el trabajo.

Cómo es la claridad y entendimiento sobre el Sprint, los objetivos y las tareas planificadas.

Cómo es el compromiso y la responsabilidad ante los acuerdos.

Cómo hacen los acuerdos

Cómo son las relaciones entre los miembros del equipo.

Cómo está el nivel de confianza entre las personas. Cómo es la indagación y el cuestionamiento de los puntos de vista.

Cómo es la efectividad de la comunicación.

Cómo es el nivel de formalidad o informalidad en el trato y en el proceso.

Cómo es el nivel de interés y atención en el trabajo de los demás, la colaboración y soporte entre los miembros

Cómo es el nivel de participación y de indagación.

Cómo está el nivel de transparencia de información.

Cómo es la capacidad de coordinación táctica. Qué tipo de decisiones se toman.

Cómo se toman las decisiones.

Cómo está funcionando el Tablero de tareas y radiadores visuales de información.

Quién y cómo actualiza las métricas, tableros y radiadores visuales de información

Cómo es la capacidad de mantener el foco y manejar los tiempos.

Cómo es el liderazgo, el empowerment y la auto-organización

Cómo es la gestión de impedimentos

Qué métricas de proceso utilizan

Cómo es el manejo de las prioridades.

Cómo es la calidad de las discusiones en el equipo sobre lo que es posible y lo que no.

Cómo es la participación de otras personas externas el Equipo. ¿Es el Product Owner parte del equipo?

Además, prestar atención a todo tipo de situaciones circunstanciales y cómo el equipo se hace cargo de las mismas. Por ejemplo: un miembro del equipo no está, el Scrum Master está en otra reunión, una tarea que los presentes no reconocen, un radiador visual desactualizado, etc.

La actividad de observación genera el mínimo nivel de intervención e interrupción en el Equipo. A diferencia, por ejemplo de facilitar una Retrospectiva, donde estaríamos haciendo una intervención directa en la forma normal de operación del equipo.

Si los ojos son la ventana del alma,
la Daily Scrum es la ventana a la cultura del Equipo.

En lo discursivo, la historia que nos cuentan sobre el equipo es sólo la versión de una persona, con sus recortes y distorsiones naturales. Muchas veces suele ser el caso ideal y no el cotidiano.

En Kleer, la experiencia de compartir el proceso de aprendizaje y evolución de muchos equipos, nos permite identificar los patrones de comportamiento que los potencian, así como también los anti-patrones que los limitan.

Como Agile Coach, acompañamos a los equipos en el proceso de identificar estos comportamientos y oportunidades de mejora para potenciar el rendimiento del equipo y la satisfacción en el trabajo.

Damián Buonamico

[mc4wp_form id="228″]

# data[].attributes.attachment_link.title
La Daily Scrum: la ventana a la cultura del Equipo.

# data[].attributes.attachment_link.description
En una entrevista, una vez me preguntaron: como Agile Coach, ¿cuál sería la primera intervención que harías en un equipo? Sin haberlo pensado antes lo primero que se me vino a la mente fue: Asistir a la Daily Scrum en calidad de observador.