¿Estás trabajando en un proyecto tradicional? ¿Te preocupa la efectividad de los resultados? ¿Ves riesgos de no cumplir con los plazos y alcance comprometido? ¡Sigue leyendo! En este artículo te comparto diez estrategias para hacer tu proyecto más ágil.

La agilidad de proyectos es la capacidad de adaptarlo a los nuevos aprendizajes y a los cambios de contexto, para lograr mejor los objetivos.

Estoy convencido de que todos los proyectos se pueden “agilizar” independientemente de su naturaleza, de la industria y de la metodología que se adopte. No me refiero particularmente el marco de trabajo que se esté utilizando, sino a mejorar la capacidad de adaptación para lograr mayor efectividad.

Voy a listar las estrategias que me han sido de utilidad para este propósito. La intención es que puedas tomar estas ideas y busques la forma de aplicarlas en el proyecto donde estés trabajando.

Incluso aunque no estés ocupando un rol de liderazgo o gerente de proyecto, siempre puedes mejorar las condiciones con propuestas de mejoras. Los actos de liderazgo están en todos lados, no siempre requieren autoridad formal.

1. Estrategia aplicar el marco de Cynefin

¿Realmente necesita tu proyecto ser agilizado? Cynefin es un framework para la toma de decisiones que te permite responder esta pregunta.

El primer paso es identificar el dominio de complejidad del problema que intentas resolver, esto también está relacionado al nivel de incertidumbre. Los dominios de cynefin son: obvio, complicado, complejo y caótico.

Si el dominio es “obvio” (también conocido como “simple” o “claro”), entonces el proyecto puede ser resuelto de la forma habitual y conocida. No será crítico agilizar el proyecto. Un ejemplo, es implementar una solución de software que ya está desarrollada, pero requiere instalarla y configurarla siguiendo los pasos ya conocidos.

Si el dominio es “complicado”, también puedes aplicar una metodología tradicional, aunque un marco ágil podría ser de mayor efectividad. Un ejemplo es la implementación de una solución de software ya desarrollada, pero donde se requiere a un experto que analice las causas raíces de los problemas que vayan surgiendo.

Si el dominio es “complejo”, una metodología tradicional no será efectiva. En estos tipos de proyectos es difícil prever con anticipación todas las actividades y tiempos. La mayoría de los desarrollos de software entran dentro de esta categoría.

Algunas preguntas que pueden ayudar son ¿Puedes identificar todas las tareas requeridas para completar el proyecto? ¿Consideras que no habrá nuevas tareas no previstas? ¿Sabes cuánto tiempo demora cada tarea? ¿Consideras que no habrán cambios de contexto que afecten a la planificación? ¿Qué tanto sabemos sobre este proyecto y qué tanto tenemos por aprender en el camino?

Si identificas el domino “complicado” o “complejo”, utiliza este framework para apoyar tu recomendación de emplear un marco de trabajo ágil o al menos algunas de las otras estrategias.

Si te interesó esta estrategia, te comparto este enlace con mayor información sobre cada uno de los dominios de complejidad.

2. Estrategia de escapar de la trampa del triángulo de hierro

Si el proyecto fue concebido con una fecha de entrega ya definida, un alcance ya determinado y un costo fijo es posible que estés en peligro! Esta situación no suele tener buenos resultados en un contexto complejo y de incertidumbre.

Salvo en los casos donde las variables fijas no presentan una restricción (por ej: fechas muy holgadas y alcances pequeños), la mayoría de los proyectos de este tipo en entornos complejos fracasan, de acuerdo al estudio realizado por The Standish Group, The Chaos Report

Si estás en esta situación, lo mejor es no engañarse desde el comienzo del proyecto y exponer los riesgos, generar las conversaciones necesarias para entender por qué se encuentran en esta situación y qué pueden hacer para permitir alguna de las variables libre.

En los proyectos ágiles, lo habitual es mantener como variable libre el alcance, es decir que pueden estimar, pero no comprometer los resultados que se entregarán en cada fecha determinada de entrega. Sin embargo, las fechas de entrega son fijas, tempranas y frecuentes y el costo puede estar ya determinado para cada ciclo.

El modelo del triángulo invertido ilustra esta diferencia clave entre los proyectos tradicionales y los proyectos ágiles.

Para escapar de la trampa del triángulo de hierro podrías tomar estos pasos:

• Remitirse a experiencias pasadas ¿Cuál es la experiencia previa del equipo y de los clientes con proyectos de estas características? Si no ha sido exitoso, ¿Qué se puede aprender de aquella experiencia para aplicar en este proyecto?

• Utiliza la información estadística de la investigación CHAOS Report como información respaldatoria.

• La situación puede tener origen en falta de confianza y por lo tanto caer en la tendencia de ejercer mayor control. Si es así analiza el origen de esta situación y la experiencia previa en cuanto a los acuerdos y compromisos.

• Evita comprometerte a resultados que no crees poder cumplir y generar falsas expectativas. Esto refuerza más aún la falta de confianza.

• Da referencias a los clientes a este artículo y al video de Henrik Kniberg, “Product Owner in a Nutshell“, para ayudar a entender otras formas de gestionar el proyecto.

• Comenzar el proyecto con una Incepción Ágil. Se trata de una reunión colaborativa para definir aspectos clave del proyecto. Es un evento ideal para identificar los riesgos del Triángulo de Hierro y proponer formas alternativas que aseguren mejores resultados. Más información aquí.

• Utiliza la siguiente estrategia #3

Un ejemplo interesante es la construcción del edificio más alto del mundo en la actualidad: Burj Khalifa (829.8 metros) en el 2004. En general, la construcción civil sigue un proceso tradicional. Sin embargo, el desafío de hacer la torre de estas características requiere innovación de procesos, de técnicas y de materiales, con lo cual no se trata de un proyecto “Simple”, sino más bien ”Complicado”

En este proyecto, se decidió que el alcance fuera variable. Esto significa que mientras construían la torre, no sabían cuántos pisos tendría una vez terminada. La decisión se tomó lo más tarde posible, en función de ver hasta dónde podían llegar. Los planos tampoco estaban terminados mientras se estaba construyendo la torre.

Si construir la torre más alta del mundo pudo hacer su proyecto más ágil, ¿Aún sigues pensando que en tu proyecto no es posible? No te preocupes y sigue leyendo más estrategias.

3. Estrategia de Entregas Parciales y MVP

Los proyectos ágiles realizan entregas parciales, frecuentes y tempranas del producto funcionando. El resultado más obvio de esta práctica es que permite incorporar el feedback para ajustar el plan de la siguiente entrega.

Además, mostrar resultados concretos de manera frecuente y pedir feedback aumentará la transparencia y la confianza de todos los involucrados, generando así un contexto más apropiado para el éxito del proyecto.

Si no es el caso de tu proyecto, comienza particionando en etapas o fases. Es una gran mejora hacerlo en dos etapas, que de una sola vez. A mayor cantidad de particiones, estarás agilizando más el proyecto. Atención: cada fase debe tener como resultado una versión del entregable final, como ilustra Kniberg en su imagen:

El primer objetivo en todo proyecto en donde se desarrolla un producto o servicio en un contexto complejo, debe ser obtener un “Producto Mínimo Viable” (MVP, por sus siglas en inglés). El concepto consiste en que lo más temprano posible exista alguna versión del producto que se pueda probar. Si se requiere validar la idea, antes de la construcción del producto real, es conveniente que el MVP sea un prototipo. Sino, puede ser una versión básica que tenga solamente lo esencial. Para esto la priorización y la mirada “User Journey” es fundamental. Una técnica muy útil para lograrlo es el User Story Mapping. Aquí tienes un artículo y un video que explica qué es y cómo elaborarlo.

4. Estrategia de priorizar lo importante y lo riesgoso

Los proyectos tradicionales asumen que se completará todo el proyecto, dentro de los plazos estipulados y el cliente espera ver el producto completo al final. Con lo cual da igual el orden en el que se realicen las tareas. En ocasiones, se comienza por donde es más fácil, quedando las tareas más riesgosas y con mayor incertidumbre para más tarde.

Sin embargo, en la práctica los proyectos se interrumpen por cambios en el contexto, porque lo que era riesgoso termina siendo muy costoso de implementar, porque se agota el presupuesto o tiempos estipulados se extienden demasiado.

Independientemente que el cliente espere todo el producto al final del proyecto, esta estrategia consiste en implementar primero lo que aporta más valor y lo que tiene más incertidumbre y riesgo. De esta manera mitigaremos los riesgos más temprano y si el proyecto se interrumpe podremos entregar lo que más valor tiene.

El siguiente gráfico, elaborado por VersionOne muestra estos conceptos comparando el modelo tradicional con el modelo ágil.

Un ejemplo: cuando realicé mi proyecto de tesis para mi carrera de Ingeniero en Sistemas, la cátedra exigía las entregas acordes a un proceso secuencial. En los primeros seis meses las entregas consistían en documentación funcional y de diseño del sistema. La construcción comenzaba en el segundo semestre, una vez aprobados los documentos.

Conociendo los riesgos asociados, comencé con la construcción desde el comienzo, resolviendo primero los aspectos más riesgosos del proyecto. De esta manera logré terminar con el proyecto completo con anticipación, con buena calidad y mucho más tranquilo, mientras otros equipos estuvieron en problemas y lidiando con el estrés del último momento..

5. Estrategia de decidir lo más tarde posible.

Esta estrategia es uno de los principios de Lean y consiste en no cerrarse a las posibilidades con más anticipación de la necesaria.

En todo proyecto hay ciertas decisiones que se pueden dejar pendientes para tomarlas más adelante, cuando haya más información y estemos en mejores condiciones de decidir.

Identifica qué decisiones, una vez tomadas pueden condicionar el futuro del proyecto, generan un punto de inflexión, generan compromisos o gastos que luego serían costosos de revertir.

Busca formas alternativas de dejar las opciones abiertas hasta el último momento responsable, para permitir que el proyecto sea más adaptable. Responsable significa no correr con costos por no haber tomado decisiones. El siguiente gráfico ilustra este concepto.

Un ejemplo simple: en lugar de comprar un servidor web, utiliza un servicio de outsourcing en la nube hasta que estén completamente seguros que es la decisión correcta. Contratar el servicio es una decisión más fácil de revertir que comprar un equipamiento.

Otro ejemplo de decidir lo más tarde posible, es el antes mencionado en el caso de Burj Khalifa.

6. Estrategia de Separar el Objetivo de la Solución

Si queremos lograr que el proyecto tenga mayores posibilidades de éxito y efectividad en resolver un problema, desafío u objetivo, el mismo debe estar claramente identificado, definido y comunicado. El problema debe estar desapegado de una solución en particular.

En este sentido debemos plantear el proyecto en términos del objetivo y no en términos de implementar una solución ya determinada.

Si el objetivo no está claro, es posible que se implemente la solución y no se resuelva el problema o no se cumpla el objetivo, por lo que la efectividad puede ser menor.

Cuánto más cerrado sea la definición del proyecto en cuanto a la solución a implementar, más difícil será adaptarlo luego. Si en cambio el proyecto está definido más cercano a la necesidad, el problema, la oportunidad, el desafío o el objetivo, la solución puede ir tomando forma a medida que se implementa y se aprende más sobre el contexto y así lograr mayor efectividad.

Si logramos particionar el proyecto en etapas o fases, cada una de ellas puede tener un objetivo específico a resolver.

Si estamos en una situación, donde el cliente solicita implementar una solución particular, podemos indagar sobre el “para qué”. ¿Qué problema resuelve esta solución, que es más importante que la solución en sí? ¿Es posible que hayan otras soluciones que también puedan resolver este problema? ¿Podemos sugerir otras soluciones que sean más efectivas, con menor riesgo, con menos costo o en menos tiempo?

7. Estrategia de ajustar cómo se mide el proyecto

Los proyectos más tradicionales penalizan el cambio. Si el cliente tiene un nuevo requerimiento, se genera un sobrecosto. Si se identifica que es necesario realizar una nueva tarea imprevista, el equipo corre con la penalidad de llevarla cabo como horas extras para no afectar la planificación inicial y no generar demoras en la fecha comprometida.

Esto se debe a que el avance del proyecto se mide con el cumplimento de las tareas estipuladas dentro de los tiempos establecidos. En ocasiones a pesar de que las tareas planificadas no lleven al éxito.

Si te encuentras en esta situación, indaga la utilidad que tienen estas métricas para el cliente, y si existen otros indicadores que tengan más sentido que sólo el cumplimiento del plan.

Busca métricas que no penalicen en cambio, y que estén en línea con entregar valor al cliente. Por ejemplo, el cumplimiento de un objetivo relevante para el cliente, una métrica de negocio, o incluso el feedback subjetivo del cliente del valor percibido al obtener las entregas parciales.

8. Estrategia de empoderar al equipo

En los proyectos ágiles, los equipos se autogestionan para realizar el trabajo y organizar la forma de llevarlo a cabo. Esto implica que el equipo tiene autonomía para tomar decisiones y realizar cambios en la forma de trabajo.

Si te encuentras en un proyecto, donde hay un jefe de proyecto que asigna tareas, puedes generar conversaciones para lograr mayor delegación y sobre la posibilidad de que el equipo proponga otras soluciones y formas de trabajo.

Es altamente importante otorgar responsabilidad al equipo por la calidad de los resultados. De poco sirve que cada integrante del equipo se ocupe solamente de sus tareas asignadas. Todos deben ser igualmente responsables por el éxito del proyecto. Esta condición favorece el trabajo colaborativo y en equipo.

9. Estrategia de la mejora continua con retrospectivas.

Los proyectos suelen terminar con una conversación de “lecciones aprendidas” o “post-mortem”. La limitante es que las lecciones aprendidas llegan tarde, cuando ya terminó el proyecto y no sirven para ajustar el curso del mismo.

La estrategia consiste en contemplar dentro del proyecto, instancias pautadas periódicamente para reflexionar sobre cómo está funcionando el equipo y los resultados que genera. El objetivo es tomar decisiones que permitan hacer ajustes durante el curso del proyecto. Estos momentos son especialmente útiles luego de cada entrega parcial del proyecto. Obtiene aprendizajes que puedas aplicar en la siguiente fase.

En los equipos ágiles esta instancia lleva el nombre de retrospectiva: mirar hacia atrás, lo que venimos haciendo y los resultados logrados para ajustar hacia adelante. Existen muchas dinámicas que facilitan este proceso, como las que puedes encontrar en el sitio: https://retromat.org/es.

Algunas preguntas útiles son: ¿Cómo está siendo la satisfacción del cliente? ¿Cómo podemos mejorarlo? ¿Cómo podemos ser más efectivos en nuestra colaboración como equipo? ¿Cómo es nuestra capacidad de aportar al proyecto con nuestras habilidades y conocimientos? ¿Cómo está nuestro nivel de estrés y satisfacción en este proyecto? ¿Qué estamos aprendiendo y que nos falta aprender? ¿Qué impedimentos tenemos y cómo podemos removerlos? ¿Qué podemos hacer distinto? ¿Qué estamos haciendo bien y queremos conservar? ¿Cuáles son nuestra fortalezas y debilidades?

Los proyectos no son solamente ágiles por adaptar el curso del proyecto, sino también por adaptar la forma de trabajo.

10. Estrategia de lograr flujo en la cadena de valor

¿Consideras que no puedes aprovechar ninguna de las nueve estrategias anteriores? No desesperes, aun tienes una estrategia más: generar flujo significa que el proyecto debe estar continuamente avanzando sin detenerse a través de la cadena de generación de valor.

Las dependencias

A veces primero tienes que dar un salto de fe…la confianza viene después.

Miércoles a las 10 de la noche, me siento frente a mi computadora, de fondo la frase anterior aparece reveladora mientras en la tele se ve “Man of steel”. Intento buscar alguna analogía que resulte poderosa y me ayude a conectar un cúmulo de ideas que vienen rondando meses, si no es que años mi mente y hoy se atreven a salir en forma de letras.

La analogía parece reveladora a medida que avanza la noche. En muchos sentidos para una organización, comenzar un camino con la agilidad representa justo eso: un salto de fe. 

Esto me hace rememorar conversaciones del Ágiles 2019 relacionadas al humo en el mundo ágil.

¿Acaso estamos vendiendo saltos de fe?, ¿Cuántas veces nuestros clientes tuvieron dudas sobre los posibles resultados de la agilidad en su organización?, Y sin embargo se vieron obligados a dar el salto, solamente por qué otras grandes organizaciones lo hicieron y podían quedarse rezagados.

En este sentido las organizaciones tienen una necesidad real de embarcarse en este camino, lo cual ha creado altísima demanda de profesionales, que las ayuden a transitar ese camino lleno de incertidumbre y dudas qué representa un cambio profundo.

Esto trae consecuencias que viéndolas en retrospectiva, parecen obvias para el estado de la profesión; Agile coches con poca formación, gurús que venden transformaciones organizacionales en un año, Instructores ágiles sin experiencia práctica pero venden cursos como expertos, diseño de mega estructuras de escalamiento sin tener equipos trabajando de manera sostenible, habilitadores de cambio que en su vida han escuchado o leido una pagina de Clean Code, y esto por mencionar solo algunas.

Los últimos años esto ha venido tomando fuerza casi de manera imparable, como una bola de nieve que crece y crece, no hace falta si no revisar linkedin para ver la cantidad de Agile Enterprise Coaches que surgen cada día luego de un curso de certificación o un año de experiencia como Scrum Master.

En este punto siento necesario hacer una aclaración importante, pues si bien el tono del artículo hasta este punto puede resultar en catarsis o queja, la intención es más bien dar respuesta de alguna manera a lo planteado en esas conversaciones del Ágiles 2019 y posteriores en el chat de telegram creado por Andres Joaquin (a quien hago responsable indirecto de la existencia de este artículo) ¿Cómo combatir el humo ágil?

Una conclusión qué va tomando fuerza en mi mente es que nos quejamos demasiado, de lo que hace fulano o lo que vendió mengano, pero ¿qué estamos haciendo para cambiar esta situación?. La respuesta de muchos en este punto seguramente será: con hacer bien mi trabajo y no vender humo es suficiente. Lo cual si bien me parece correcto, también me parece insuficiente. Pues parto de la premisa de que el agilista no vende humo de adrede, lo hace desde la ignorancia (al menos en la mayoría de los casos)

A esto se le llama el efecto Dunning-Kruger, un sesgo cognitivo, según el cual los individuos con escasa habilidad o conocimientos sufren de un sentimiento de superioridad ilusorio, considerándose más inteligentes que otras personas más preparadas, midiendo incorrectamente su habilidad por encima de lo real. Este sesgo se explica por una incapacidad metacognitiva del sujeto para reconocer su propia falta de competencias en determinado tema.

De esa misma manera seguramente todos hemos vendido humo en algún punto de nuestra carrera, y a medida que tomamos experiencia, nos vamos haciendo más conscientes y mejores profesionales.

Entonces si muchos agilistas con buenas intenciones, viven el efecto Dunning-Kruger, y caen en estos problemas que empobrecen y descalifican la profesión, ¿Qué podemos hacer?

Es un mundo de influencers, de redes sociales, donde el agilista que más brilla es el que tiene mejores videos en youtube o publica más fotos de procesos exitosos frente a un tablero, y nos guste o no las personas que comienzan en la agilidad los van a tener como referente. 

Tenemos como responsabilidad guiar y mentorear a otras personas, ayudarlos a ser más conscientes de sus brechas para que puedan salir del efecto Dunning-Kruger.

Tanto para orientar a otros como para ser cada día más conscientes del hacer te dejo algunas ideas para evitar el humo ágil:

Evitar el dogmatismo

Es importante estar abiertos a otras corrientes de pensamiento, pues en la agilidad no existen verdades absolutas.

La agilidad no es el objetivo final

En este mismo sentido recordar siempre que nuestro objetivo es ayudar a nuestro cliente y mantenerlo en el centro, entender sus necesidades  y tener presente que lograr agilidad no garantiza un mejor resultado para mi cliente, y que en algunos casos, otros enfoques podrían ser mejores para el clima y el contexto actuales.

Aceptar que no se

Especialmente desde el lado del experto que acompaña organizaciones nos cuesta reconocer que no sabemos,es importante aceptar que hay cosas que puede estar más allá de nuestro conocimiento actual, debemos admitir valientemente lo que no sabemos para obtener ayuda de otros practicantes y mejorar 

Complementar la teoría con experiencia práctica

Todos generamos experiencia de distintas maneras, pensando en esto siempre debemos tener en la mira qué, como aprendices constantes iremos descubriendo nuevas cosas y más allá de hablar de ellas, tenemos como responsabilidad llevarlas a la práctica, experimentar y aprender de esas experiencias para hablar con propiedad

Compartir con la comunidad 

La comunidad es una fuente de aprendizaje continuo, tanto para quienes están comenzando el camino de la agilidad, como para quienes tienen un buen terreno. La comunidad es un espacio polinizador para formar nuevos profesionales y mejorar también uno mismo

Estas son solo algunas de las primeras ideas que se me vienen a la mente para tener en cuenta y así evitar el humo ágil, cuentame ¿cuales se te ocurren a ti?

Además de esto dejo el link del articulo de Andres Joaquin donde plantea un experimento relacionado a esto. hasta pronto

La facilitación consiste en sostener un espacio donde los participantes logren sinergia -el todo sea más que la suma de las partes- para que la inteligencia colectiva del grupo emerja y que de manera creativa logren resultados efectivos.

Como facilitador, diagnostico e intervengo en en las dinámicas y el proceso del grupo para ayudarlos a identificar y resolver sus problemas.

Tanto para talleres de trabajo (workshops), como de capacitación (training), con entre 15 y 50 personas, me ayudo con algunas herramientas, que con la experiencia fui probando y seleccionado.

Por eso, en este video te comparto mis 10 herramientas preferidas. Estas herramientas me acompañan en todos mis talleres logrando una experiencia de mayor calidad para los participantes y para mí.

Listado de Herramientas y Referencias

1. Kartalas o Pin
2. Pelota de Espuma (Derecho a la palabra)
3. Parlante Bluetooth (Logitech 300X) https://www.logitech.com/es-roam/product/x300-wireless-speaker
   
4. iPad (Minimalistic Countdown Timer) https://apps.apple.com/si/app/minimalistic-countdown-timer/id612374149
5. Cutter
6. Marcadores Neuland
7. Presentador (Logitech Spotlight) https://www.logitech.com/en-us/product/spotlight-presentation-remote
8. Celular
9. Spotify
10. Agua

La entrada Mis 10 Herramientas de Facilitación se publicó primero en Coaching Organizacional.

Quiero más...

• sólidos valores que incluyen el trabajo enfocado en hacer pocas cosas a la vez y con altísima calidad, privilegiar  el trabajo colaborativo, el respeto y el compromiso en la entrega de resultados valiosos
• tres roles en los proyectos Scrum: el Product Owner responsable de definir prioridades y trabajo a realizar, el Equipo de Desarrollo que “construye” el producto o servicio, y el ScrumMaster que es un líder servicial cuya labor consiste en asistir al equipo completo para que rinda a su máximo potencial en forma sostenible en el tiempo
• un conjunto de reuniones y reglas que aseguran visibilidad del avance del proyecto para asegurar que todo equipo pueda trabajar en iteraciones de tiempo corto (o “Sprints”) al cabo de las cuales ocurre un incremento de valor real brindado por el equipo a sus clientes u organización

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 autoevaluarse, 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.

• El usuario final

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.

• Otros Stakeholders

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.

• El proceso Scrum

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). 

• Product Delivery:

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.

• Product Discovery:

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.

Descarga el Diagrama en formato PDF: Las Cuatro Áreas de Atención del Product OwnerDescarga

Bonus: Guía de Preguntas de Autoevaluación

Descarga la Guía de Preguntas en PDFDescarga

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?

La entrada ¿Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención? se publicó primero en Coaching Organizacional.

Junto Pablo nos charlamos un poco sobre escalado ágil, y como LeSS nos ayuda a des-escalar la complejidad!!

Solía creer que todo era una elección…

En cada momento de nuestras vidas nos enfrentamos a una elección. Desde levantarnos del asiento a preparar una cena saludable, o pedir aquella pizza por salir del paso. Cada acción comienza con una decisión.

La vida es la suma de todas tus elecciones

Albert Camus

Como facilitador de equipos, organizaciones y comunidades, había creído que todo el tiempo nos encontrábamos en constante elección.

¿Me hago cargo de aquella reunión improductiva de los jueves a la tarde, o ignoro la situación, esperando que alguién más actúe? Esa es una elección.

Recientemente mis creencias fueron sacudidas, pues la idea que se impregna cada vez con más fuerza en mi es que cada acción es una reacción . Esto se aplica tanto a las acciones tomadas por organizaciones como aquellas tomadas por individuos.

¡Y no me malinterpretes! Sigo creyendo que estamos en constante elección, solo que no siempre somos dueños de nuestras decisiones. Nuestra forma de decidir está condicionada a un conjunto de creencias que tomamos como verdaderas pero en muchas ocasiones resultan ser sesgos cognitivos.

Decidimos sobre la base de nuestra experiencia, apoyándonos en nuestros éxitos y fracasos, independientemente de si esa experiencia se aplica al momento actual. Tal como si tuviéramos un método predictivo instalado en el cerebro. 

En los últimos años he aprendido múltiples técnicas y herramientas para tomar mejores decisiones y algo que tengo muy claro es que el camino hacia una buena decisión no sigue una línea recta. Cualquiera que afirme que hay una lista de verificación o un diagrama de flujo de pasos que puede seguir para tomar una decisión de calidad seguramente es un vendedor de humo (término que nos encanta en la comunidad ágil hoy por hoy).

Y el problema como lo veo yo está justo ahí: tomar decisiones efectivas en un equipo o una organización va mucho más allá de tener un set de herramientas que puedo sacar como una baraja de opciones para que mi cliente escoja como jugando a la ruleta rusa.

Desde mi visión la labor del facilitador está orientada a ayudar al grupo a superar los posibles sesgos cognitivos, profundizando en lo que hay en el medio de querer tomar una decisión y generar acciones. 

Pero, ¿Cómo lograr esto?

Para responder esta pregunta lo primero a lo que debemos enfrentarnos es a distinguir estos posibles sesgos cognitivos que pueden surgir en medio de la toma de una decisión. Esto nos ayudará a escoger la técnica de facilitación adecuada y nos ayudará a distinguir una toma de decisión conciente de una reacción condicionada al contexto.   

En este punto mientras voy tecleando empiezo a sentir que el artículo se hace extenso y no es mi intención robarte demasiado tiempo de tu paso por redes sociales, así que vamos con algunos de estos sesgos cognitivos:

La toma de decisiones no es lógica. Usamos la emoción para decidir

Sin nuestra capacidad de empatizar emocionalmente con alguna de las opciones, podemos perdernos en el peor de los casos posibles de análisis de parálisis . Por ejemplo, no hay una buena razón para elegir un sabor de helado en lugar de otro desde una perspectiva puramente lógica. Cuando seleccionamos del menú, confiamos en la preferencia y el deseo de limitar las opciones, no la lógica. 

Nadie dice, sin embargo, que nuestras emociones nos llevan a tomar buenas decisiones, solo que están involucrados y son un factor importante. Esta es una de las razones por las cuales los facilitadores debemos estar capacitados para manejar el ambiente emocional en la sala.

Predisposición inconsciente

Varios estudios iniciados en la década de 1970 demuestran que nuestra mente subconsciente “decide” algo hasta 7 segundos antes de que se registre en la mente consciente como una decisión.

En el estudio, los participantes podían decidir libremente si querían presionar un botón con la mano izquierda o derecha. Tenían la libertad de tomar esta decisión cuando quisieran, pero tenían que recordar en qué momento sentían que habían tomado una decisión. El objetivo del experimento era descubrir qué sucede en el cerebro en el período justo antes de que la persona sintiera que se había tomado la decisión. Los investigadores descubrieron que era posible predecir a partir de las señales cerebrales qué opción tomarían los participantes ya siete segundos antes de tomar una decisión consciente.

Ahora tal vez esto no importa. La investigación no implica que alguna fuerza externa esté imponiendo nuestras decisiones; solo que no registramos conscientemente estas decisiones de inmediato.

Por otra parte, seguro te ha sucedido que sigues enojado mucho después de que se resuelve la causa original de la rabia. Cuando esto sucede, sabemos que estamos enojados y sabemos que no tenemos ninguna razón lógica para estar enojados (¡porque ya se disculpó! ¡Fue un error!), Así que inventamos razones para justificar nuestras emociones (de manera inconsciente).

Somos muy buenos para encontrar razones por las que creemos lo que creemos, incluso si esas razones no están basadas en nuestra realidad experimentada. Y dado que tomamos decisiones antes de saber que hemos decidido, esto predispone de manera inconsciente nuestra opinión.

En este punto como facilitador estar atento a identificar esas predisposiciones nos dará un poco de luz para hacer ver otras perspectivas y ayudar al grupo a ser consciente de este sesgo cognitivo.

Siempre estamos trabajando con información limitada.

Muchas veces ni siquiera nos damos cuenta de lo que está frente a nosotros, a menudo no podemos distinguir lo que estamos buscando

Esto se denomina “ceguera por falta de atención sostenida”, un fenómeno confirmado en un estudio tras otro. Más recientemente, 20 de los 24 radiólogos no notaron a un gorila colocado en una gammagrafía pulmonar .

“Lo miran directamente, pero como no están buscando un gorila, no ven que es un gorila”

dice Drew (el autor del estudio).

En otras palabras, en lo que estamos pensando, en qué estamos enfocados, filtra el mundo que nos rodea de manera tan agresiva que literalmente da forma a lo que vemos.

La investigación aquí muestra que con mayor frecuencia vemos los hechos que coinciden con los patrones reconocidos, ya sea los patrones que hemos sido entrenados para detectar, o los patrones que esperamos encontrar 

La buena noticia: aunque muchas personas sufren de ceguera por gorilas, no todos lo hacen. Esto constituye un caso poderoso para la diversidad, ya que cuanto más diverso sea su grupo, mayor será la probabilidad de que alguien en el grupo pueda detectar al gorila que usted no puede.

Como facilitador debemos generar espacios que permitan pensar fuera de la caja y ver otras perspectivas al grupo. Resulta que lo que crees que sabes puede ser algo que tu amigo sabe, no tú.

Resulta que lo que crees que sabes puede ser algo que tu amigo sabe, no tú.

En su nuevo libro La ilusión del conocimiento: por qué nunca pensamos solos , Steven Sloman y Philip Fernbach afirman:

Creemos que sabemos mucho más de lo que realmente sabemos.

Los seres humanos han construido sociedades y tecnologías enormemente complejas, pero la mayoría de nosotros ni siquiera sabemos cómo funciona un bolígrafo o un inodoro.

¿Cómo hemos logrado tanto a pesar de entender tan poco? Porque mientras los individuos saben muy poco, la mente colectiva o “colmena” sabe mucho.

La clave de nuestra inteligencia está en las personas y las cosas que nos rodean. Estamos constantemente aprovechando la información y la experiencia almacenada fuera de nuestras cabezas: en nuestros cuerpos, nuestro entorno, nuestras posesiones y la comunidad con la que interactuamos, y por lo general ni siquiera nos damos cuenta de que lo estamos haciendo.

La naturaleza fundamentalmente comunitaria de la inteligencia y el conocimiento explica por qué a menudo asumimos que sabemos más de lo que realmente sabemos, y por qué las opiniones políticas y las falsas creencias son tan difíciles de cambiar.

Esto resulta un arma de doble filo, y nuestra misión al pensar en la facilitación es identificar esas creencias colectivas que el grupo da por sentado para ayudarles a descubrir nuevas realidades.

En este mismo sentido…

El pensamiento grupal limita las opciones

La lluvia de ideas falla debido al pensamiento grupal. Cuando escuchamos primero la idea de otra persona, cuando vemos lo que piensa el jefe, cuando se nos pide que suspendamos las críticas para no pisotear los sentimientos de nadie, no generamos las mejores opciones. Literalmente y explícitamente cerramos el pensamiento crítico en nombre de la armonía.

La toma de decisiones efectiva requiere comprender la situación y luego decidir entre alternativas viables. el pensamiento grupal puede limitar considerablemente la cantidad y la viabilidad de tus alternativas, lo que es un verdadero obstáculo.

Toma de decisiones a gran escala, desemboca en fallos a gran escala 

Esta parece bastante obvia, pues en la agilidad promovemos la experimentación en pequeños pasos, sin embargo decisiones como elegir el framework que vamos a utilizar para escalar la agilidad en la organización o la estrategia para permear la cultura ágil son un buen ejemplo de cómo caemos en este sesgo constantemente.

En este sentido deberíamos tratar de mantener pequeñas las decisiones, para que el fracaso de cualquier decisión no descarrile todo el tren. 

Si tomamos demasiadas decisiones en un día, agotamos nuestros músculos de toma de decisiones.

La fatiga de las decisiones limita la cantidad de decisiones que podemos tomar bien en un día. Mark Zuckerberg hizo esto famoso al explicar por qué siempre llevaba la misma camiseta gris:

Tengo muchas ganas de limpiar mi vida para tener que tomar la menor cantidad de decisiones posible, aparte de cómo servir mejor a esta comunidad (la de Facebook).

Mark Zuckerberg, Facebook Q&A Noviembre 2014 .

A medida que tomamos más decisiones durante el día, nuestra capacidad de razonar a través de los matices involucrados se sumerge de manera dramática. Cuanto más decisiones tomamos, menos capacidad de toma de decisiones tenemos disponible. A medida que nos cansamos, tendemos a tomar decisiones “más seguras” y más fáciles, pero no mejores. Dejamos de sopesar todos los factores lógicamente y confiamos más en esas reacciones viscerales.

Este fenómeno funciona para sabotear la dieta de todos. Me sirvo del ejemplo con el que abrí este artículo pues después de un día completo de tomar decisiones (Como por ejemplo qué sesgos cognitivos debía incluir y cuales no en un artículo), nuestra capacidad para elegir la cena saludable sobre la pizza reconfortante está totalmente agotada. La decisión visceral gana (¡Sí, pizza!). Lo que, lamentablemente, significa que el intestino pierde. Y la razón por la cual justificó el pedazo de pizza que tengo en la mano mientras escribo estas líneas.

Como facilitador entender los ritmos e identificar en qué momento debemos parar de tomar decisiones ayudará a aumentar la efectividad de la organización.

Ya para este punto mi capacidad de toma de decisiones se encuentra altamente deteriorada por lo cual me despido y te agradezco por llegar hasta este punto no sin antes preguntarte.

 Referencias:

http://nymag.com/scienceofus/2016/06/how-only-using-logic-destroyed-a-man.html

https://www.goodreads.com/book/show/11990.The_Rebel

https://www.forbes.com/sites/eriklarson/2017/03/21/how-common-emotions-affect-team-decision-making-and-what-to-do-about-it/#6d72119e2896

https://www.planetadelibros.com/libro-el-cerebro-idiota/209989

https://www.goodreads.com/book/show/30780235-the-knowledge-illusion

• Co-creamos espacios de trabajo sostenibles donde personas y equipos pueden enfocarse en los clientes
• Estimulamos y reforzamos hábitos de colaboración efectiva entre las diferentes áreas de la organización
• Utilizamos nuevas métricas de impacto (outcomes) que ayudan a las personas a trabajar con mayor productividad y calidad
• Creamos equipos estables que tienen objetivos claros y pueden solucionar problemas creativamente

• Por ejemplo los dueños de un nuevo restaurante se encuentran con que su futura (posible) clientela ya tiene de alguna forma resuelto donde cenar --ya sea en sus casas, en negocios de comida para llevar, o en otros restaurantes existentes.

• Mucha gente comenzará a ir al nuevo restaurante y se convertirá en cliente habitual si encuentran que la experiencia de cenar allí es mucho mejor que las opciones existentes.

Origenes

El Concepto

Definición de las Tribus

1. Cosecha & Cierre

Preparación

Eramos un grupo de organizadores trabajando desde hace varios meses para concretar el evento. Estuvimos organizando y facilitando todos los aspectos previos y posteriores al evento, así cómo las primeras actividades del evento (acreditación, apertura, primeras charlas relámpago, etc.), hasta la formación de las tribus. 

Es importante aclarar que en este caso, el lugar elegido (Centro de Eventos Colinas de Cuncumen) contaba con una infraestructura espectacular, con personal propio y todos los aspectos relacionados con la comida resueltos, lo cual simplificó muchos varios aspectos de la organización. 

Adicionalmente, para habilitar la auto-organización de las tribus, cuidamos particularmente disponibilizar la mayor información posible a todas, cómo por ejemplo la agenda completa del evento:

Preparamos previamente los materiales necesarios para las actividades típicas de un Agile Open Camp: laminas/rotafolios, marcadores, cinta, hojas, lapiceras, post-its y otros útiles. Dejamos todos estos materiales en libre acceso para las tribus que los necesitarían. Debatimos en el equipo de organización si comprar algún material extra para la fiesta (cotillón, etc.), pero al final sentimos que ibamos a influenciar o restringir la auto-organización de la tribu de Fiesta, así que no lo hicimos. 

Cada persona del equipo de organización eligió (por interés propio) la tribu a la cual quería participar. Tuvimos que recurrir a un par de personas que no habían participado de la organización para completar. Llamamos a esta persona de la organización el Irresponsable de la Tribu. Su rol en la tribu era lanzar la tribu y dejar que se auto-organice, haciendo de nexo si fuera necesario entre la tribu y el resto de la organización y/o el staff del lugar.

Finalmente diseñamos unas dinámicas para el lanzamiento de las tribus para el inicio del evento. 

Lanzamiento de las Tribus

Magia

Feedback

¿En qué tribu participaste?

Las tribus fueron un gran aporte al éxito del Agile Open Camp Chile 2018

¿Cómo viviste tu participación en la tribu?

¿Qué hubiera sido diferente en el AOC Chile 2018 al no existir las tribus?

"No se puede mejorar. Son auto-organizadas!!!"

¿Cómo elegir los ritmos adecuados en un mundo cada vez más veloz?

Sobre Carl Honoré

Después de trabajar con niños de la calle en Brasil, Carl Honoré cubrió América del Sur y Europa para The Economist, Observer, Houston Chronicle, National Post y la revista Time.

Sus libros sobre los sorprendentes beneficios de la desaceleración se han traducido a más de 35 idiomas y se han incluido en las listas de libros más vendidos en muchos países.

Presenta programas de radio y televisión, y su charla en TED Elogio de la Lentitud ha sido vista 2.8 millones de veces.

Quiero más...