Blog

Covid19 y la ruptura de nuestros corazones

21/03/2020 - Blog de Pablo Lischinsky

Esta es una traducción del inglés del artículo “Covid19 and the breaking open of our hearts”, publicado el 20/03/2020, por Jennifer Garvey Berger, ver artículo original en https://www.linkedin.com/pulse/covid19-breaking-open-our-hearts-jennifer-garvey-berger/ Estoy manteniendo mi distancia del mundo y al mismo tiempo me doy cuenta de lo entrelazado que estoy con el mundo. Observo el miedo y el dolor … Leer más "Covid19 y la ruptura de nuestros corazones"

Scrum: Incremento de Producto

06/03/2020 - Code & Beyond



En el Manifiesto por el Desarrollo Ágil de Software, hoy más conocido como el Manifiesto Ágil, hay 4 valores y 12 principios, uno de los cuales dice:
El software funcionando es la medida principal de progreso.
En Scrum, ese principio está representado por el Product Increment. Es importante notar que Scrum ya no habla de software, pero la definición del incremento en la Scrum Guide dice (mi traducción):
El incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los previos. Al final del Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe estar en condición de ser utilizado y cumplir con la definición de "Terminado" del Equipo Scrum.
Podríamos decir que en Scrum, la principal medida de progreso es el Incremento de Producto funcionando.
Este incremento es entonces, una versión actualizada y funcionando del producto que se entrega al final del Sprint (agregando valor sobre los incrementos previos).

El Product Owner es quien tiene la responsabilidad de decidir si ese incremento se libera al mercado (se pasa a producción, se pone en marcha o su equivalente de acuerdo al tipo de producto), más allá de que sea usable.

Que el Incremento deba estar "terminado" significa que debe poder ser liberado sin trabajo adicional del Scrum Team.

Atención 
La Guía Scrum no especifica qué sucede con esfuerzo adicional fuera del equipo para entregar el producto a su público objetivo. Por ejemplo, en muchas organizaciones el equipo entrega un producto de software terminado, pero para pasarlo a producción el esfuerzo de otras áreas puede ser enorme. La comunidad ágil alienta a trabajar en reducir esa brecha, por ejemplo, a través de prácticas de DevOps (que NO es un rol ni un área, sino un estilo de colaboración entre desarrollo y operaciones).

La Definición de Terminado

La DoD (del original en inglés, Definition of Done) es creada por el Scrum Team com una manera de evaluar si su trabajo en un ítem del Product Backlog ó en el Incremento está completo.
Definición de Terminado
El objetivo de esta definición es brindar transparencia sobre el nivel de calidad que se considera suficiente para entregar el Incremento de Producto.

La definición es dinámica, y a través de los Sprints será inspeccionada y adaptada, en colaboración entre el Scrum Team y los Stakeholders.

Es importante que el Development Team tenga esta definición en cuenta a la hora de determinar cuánto comprometer durante la Sprint Planning. Una buena Definición de Terminado balancea el nivel de calidad esperado con el esfuerzo requerido.

Es común que la definición varíe mucho entre diferentes equipos, ya que depende mucho del tipo de producto, el contexto y la madurez en diferentes aspectos.

Cuando múltiples equipos trabajan sobre el mismo producto, usualmente colaboran para tener una Definición de Terminado mínima, compartida por todos, sobre la que cada equipo puede agregar sus propias condiciones.

Tips

En mi experiencia, es preferible comenzar con una definición humilde pero alcanzable, y trabajar con el Scrum Team en seleccionar qué prácticas pueden elevar el nivel de calidad del producto, priorizándolas. Es usual que esas prácticas tengan una curva de aprendizaje, que hace que el equipo deba inicialmente invertir más esfuerzo en cada ítem.

La buena noticia es que las prácticas de calidad, una vez que tienen impacto, ahorran esfuerzo en la medida en que el producto se vuelve más estable y el equipo las incorpora como propias. En el momento en que el equipo ya está acostumbrado a esa nueva práctica, puede agregar la condición correspondiente como parte de la Definición de Terminado, y comenzar con la adopción de la próxima práctica de calidad que sea más prioritaria.

Para ayudar a pensar en posibles ítems de la Definición de Terminado de un equipo, en Kleer creamos una guía ágil y las DoD Cards,  con ejemplos y sugerencias.

DoD Cards

Scrum: Sprint Backlog

05/03/2020 - Code & Beyond

El Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.
Sprint Backlog
Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.

La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.

Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.

El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera transparente.

También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible al menos un elemento de mejora decidido en la última retrospectiva.

Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.


El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.

Scrum: Product Backlog

04/03/2020 - Code & Beyond

Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.

Product Backlog

Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.

Esa evolución se da a través de los Sprints, a medida que:
  • Se pasan ítems al Sprint Backlog, durante la Planning.
  • Se agregan nuevos ítems que sean valiosos para el producto
  • Se eliminen ítems cuyo valor ya no es relevante
  • Se descompongan ítems grandes en otros más pequeños
  • Se cambian las prioridades de los ítems, al reconsiderar su valor actual
Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.

Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.

El Product Owner es el responsable por su contenido, visibilidad y priorización.

El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.

Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.

Refinamiento del Product Backlog

Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:

  • Con su valor establecido (y ordenados en consecuencia)
  • Divididos en los ítems más pequeño posibles
  • Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
  • Detallados (suficiente como para que nada se bloquee en la Planning)
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:
  • Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
  • Evitar analizar ítems que pueden variar (o desaparecer)
La actividad de agregar estos detalles al Product Backlog  no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.

Product Backlog Refinement

La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.

Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.

Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).

También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.

La estructura de Scrum

26/02/2020 - Code & Beyond

Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil.

Pilares y Valores de Scrum

25/02/2020 - Code & Beyond

Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"

La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.

Procesos de Control Empírico


Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.

No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:

  • Volatilidad
  • Incertidumbre
  • Complejidad
  • Ambigüedad

De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.

Los pilares de Scrum

 Transparencia, Inspección y Adaptación
Transparencia, Inspección y Adaptación
Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?

La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.

En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:
  • Decisiones acertadas o no
  • Hipótesis de negocio comprobadas o no
  • Calidad del producto
  • Estado actual frente a un contexto volátil
  • Comprensión correcta entre todos, en un entorno ambiguo
Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.

Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.

Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.

Principios de Scrum

Compromiso, Coraje, Foco, Apertura, Respeto
Compromiso, Coraje, Foco, Apertura, Respeto

Estos principios, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.

Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:

Compromiso (commitment)

Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.

En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.

La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.

Coraje (courage)

Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.

En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.

Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.

Foco (focus)

Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".

Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.

Apertura (openess)

Algo abierto es algo expuesto y evidente.

En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).

La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.

Respecto (respect)

Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.

En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.

Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.


¿Y cuál es la respuesta?

Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.

Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.

Scrum no es un modelo predictivo, es un modelo adaptativo.

Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:
  • ¿El producto agrega valor?
  • ¿Estamos más cerca de resolver el problema?
  • ¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?
Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.

¿Qué es Scrum y para qué se usa?

24/02/2020 - Code & Beyond

Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.

Scrum Guides (portada)
Sitio de la Guía de Scrum

¿Qué es Scrum?


Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):
Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.
Me gusta esa  definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.

Un marco de trabajo...


Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.

Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.

Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en en graves problemas.

...en el que las personas...


Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.

...abordan problemas adaptativos complejos, mientras entregan productos...


Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.

Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.

No hay una clara línea divisoria respecto a su aplicación porque la definición de qué es un producto tiene muchos grises, y también porque los contextos de todos los mercados son cada vez más complejos, que es uno de los motivos del éxito de Scrum.

...del mayor valor posible de manera productiva y creativa


El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.

La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.

Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.


Otras características

Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".

Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.

Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.

Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.


Hacia adelante

Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:

(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)

  • Pilares: Transparencia, Inspección y Adaptación
  • Valores: Compromiso, Coraje, Foco, Apertura y Respeto
  • Roles: Development Team, Product Owner, Scrum Master, y stakeholders
  • Eventos: Sprint, Planning, Daily Scrum, Review, Retrospective
  • Artefactos: Product Backlog, Sprint Backlog, Product Increment)
  • y las pocas reglas que los vinculan: Definition of Done, Refinement


Un pequeño repositorio co-creado de pequeñas técnicas para un día Slow

17/01/2020 - el próximo paso

Ayer tuvimos el primer encuentro virtual de la comunidad virtual BeingSlow, cuyo propósito es ir compartiendo alrededor de nuestros caminos Slow.

Slow para mi es elegir consciente y continuamente el ritmo adecuado para habilitar el disfrute responsable, las conexiones genuinas y los beneficios sostenibles (definiciónmás información).

Este primer encuentro de la comunidad tenía los siguientes objetivos:

  • Iniciar una serie de encuentros virtuales de la comunidad para compartir y co-crear sobre temáticas slow. 
  • Co-crear un pequeño repositorio de técnicas slow simples que nos permitan centrarnos, enfocarnos, tranquilizarnos, relajarnos, bajar el ritmo, recuperar energía, y también para prepararnos para momentos estratégicos, importantes o de alto ritmo.
¡Muchas gracias Ale, Celina, Ivan, Pablitux y Franco por su participación!

A continuación relato los distintos momentos del encuentro, que pueden seguir en la grabación:

1. Llegada

(desde 0'00 de la grabación)

A medida que nos ibamos sumando, fuimos entrando al tablero virtual (en Mural) para registrar nuestro nombre y ubicación. También nos compartimos lo que veníamos haciendo antes del encuentro y en qué ritmo lo llevamos. Luego revisamos y ajustamos unos pequeños acuerdos para el encuentro.


2. Síntomas

(desde 21'55)

A modo de entrada en calor, reflexionamos cada una y cada uno sobre: ¿Cómo me doy cuenta que tengo que frenar? Compartimos luego los síntomas identificados e identificamos en verde un resumen de los tipos de síntomas que nos permiten darnos cuenta que necesitamos frenar:



Luego compartimos la invitación a reflexionar sobre como detectar más tempranamente nuestros síntomas para poder reaccionar antes de que sea demasiado tarde.

Técnicas

(desde 39'50)

Identificamos en forma individual las técnicas que usamos o estamos usando para tener un día más slow: centrarnos, enfocarnos, tranquilizarnos, relajarnos, bajar el ritmo, recuperar energía, y también para prepararnos para momentos estratégicos, importantes o de alto ritmo. Luego votamos las que más nos interesaban conocer:



Siguiendo (casi) el orden de las votaciones, se presentaron las siguientes técnicas:

Respiración Wim Hof

(desde 56'21)

Franco no contó de esta técnica de respiración de hiper ventilación que se puede combinar con frió extremo. 

Referencias adicionales:

La Batería Slow 

Como Ivan se tenía que ir, no presentó esta técnica, pero nos compartió el post La Batería Slow, que nos invita a hacer el paralelo entre nuestra energía y la batería del celular, para administrarla en forma consciente. 

La Teoría del Board Dividido

(desde 1h02'04)

Ivan nos comentó esta técnica que le permite identificar actividades que disfruta y otras que no, para poder pasar de un tipo de actividades a otra según lo que necesite.

10 Alarmas

(desde 1h05'30)

Franco esta probando esta técnica donde programa 10 alarmas en su día que le recuerdan tomarse unos segundos para estar más presente en lo que está haciendo en el momento. 

Día del Alpedismo

(desde 1h09'17)

Conté de esta técnica de preparase para un día sola o solo, sin absolutamente ningún compromiso ni tarea por hacer, para poder dejarse llevar por lo que pide el cuerpo y/o el corazón en todos los momentos de ese día.

Caminata por la Naturaleza

(desde 1h13'07)

Celina nos contó que usa caminata en la naturaleza para respirar y conectarse con ella misma y/u otros.

Soltar la Preocupación para Dormir

(desde 1h14'35)

Ale explicó su técnica para cuando no logra dormirse, donde intenta no pelearse más con esta situación, aceptarlo y por ejemplo leer un libro hasta que el sueño venga solo.

Cierre

(desde 1h17'31)

Compartimos sobre: ¿Cómo nos vamos de este primer encuentro de la comunidad Being Slow?



Más Slow...

Si te interesa el tema de Slow, probablemente te sea útil sumarte a la Comunidad BeingSlow en la cuál compartimos (principalmente virtualmente) alrededor de nuestros caminos, experimentos, aciertos y errores relacionados con Slow.

Y muy probablemente organizaremos un próximo encuentro el mes que viene.

¡Abraslow!

Una fotos de mi 2019

14/01/2020 - el próximo paso

Se terminó el 2019, un año intenso para mi profesionalmente. 

Mirando para atrás veo muchas capacitaciones y viajes, esta año no tanto hacia otros países sino dentro de Argentina. 

Un año con foco en facilitaciones y en slow, con unos acompañamiento en agilidad organizacional muy desafiantes y enriquecedores. 

Como lo hice otros años (201520162017, 2018), me tomo el inicio del año para repasar el 2019, mirando mis actividades profesionales en comunidades, eventos, capacitaciones, facilitaciones, acompañamientos y algunas otras cosas.

Comunidades y Eventos

Participé de 1 solo evento en el 2019 (2 en el 2018):
  • El Agile Open Camp 2019 en España, que co-organizamos con Ingrid Astiz y David Roncero y todo un gran equipo de organizadores. Facilité dos sesiones alrededor de la temática Slow: "Pequeñas Técnicas para un Día Slow" y "El experimento". Fue impresionante ver el impacto del evento en sus participantes y todas las conexiones que se generaron. Y que bueno haber llevado el AOC a otro continente...



Adicionalmente, me involucré en distintas comunidades:
  • En febrero inicié la comunidad online BeingSlow, para compartir alrededor de #Slow: elegir consciente y continuamente el ritmo adecuado para habilitar el disfrute responsable, las conexiones genuinas y los beneficios sostenibles. Hoy ya cuenta con más de 80 participantes, con lindos intercambios y próximamente encuentros virtuales...




  • 14 Meetups de Organización del Agile Open Camp España 2019, en la web. Adicionalmente seguimos creciendo como comunidad de todos los AOCs, coordinando entre los 21 organizadores core de todos los AOCs anteriores y por venir, con ediciones del AOC en 5 países. Un equipo muy cálido!


Capacitaciones

Entrené en 2019 a 794 personas (+41% comparado con 2018) a través de 32 capacitaciones (+39%):

Con Kleer:


  • 3 Talleres del Tiempo: 2 en Buenos Aires (1 in-company y otro abierto) y 1 in-company en Madrid


  • 3 talleres in-company de Kanban  y Visual Management: 1 en Rosario, 1 en Viedma y 1 en Madrid



  • 3 talleres in-company de Liderazgo Ágil en Córdoba (con Carlos Peix y Diego Sánchez Rivera). Experimentamos y logramos momentos muy potentes en el equipo... 


  • 2 Talleres de Slow: 1 en Buenos Aires (con Carl Honoré) y 1 in-company en Madrid. Fue increíble para mi co-facilitar el taller con Carl Honoré, ídolo total y voz mundial del movimiento slow!!!




  • 1 taller in-company de Valor de Negocio en Rosario



En la Facultad Regional de Buenos Aires de la UTN con Hernán Ricchio:

Y también tomé la siguiente capacitación:
  • Herramientas para la Transformación de Conflictos en el Ámbito Comunitario, en Cipolletti, por Pablo Lumerman

Acompañamientos y Facilitaciones

Participé de los siguientes acompañamiento en evoluciones organizacionales ágiles: 
  • Evolución ágil para todas las compras estratégicas de una petrolera Argentina, con capacitación y acompañamiento de 48 células ágiles en el sector de Supply Chain de una petrolera Argentina (con Damián BuonamicoRicardo ColussoCarlos Peix y Verónica Argañaraz). Un acompañamiento super desafiante y a su vez gratificante, para lograr al final 206 MUSD de beneficios potenciales por año, además de una muy buena base de mindset ágil para seguir evolucionando.

  • Desarrollo del Liderazgo Ágil de 11 directivos de una empresa financiera de Argentina, a través de talleres grupales y coaching ejecutivo, con Damián BuonamicoCarlos PeixMartín Salias y Diego Sánchez RiveraFue una experiencia muy enriquecedora para mi trabajar con este nivel de directivos y lograr cambios que creo profundo en varios de ellos... 



También seguí trabajando con las siguientes empresas:
  • Acompañamiento remoto a 1 equipo Scrum de una empresa de productos electrónicos (hardware+software), en Nantes, Francia. 

  • Facilitaci

Cómo agilizar cualquier proyecto: 10 estrategias clave

27/11/2019 - Coaching Organizacional

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

Los planes y los imprevistos

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.

Modelo de Triángulo Invertido

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

Combatiendo la venta de humo en la agilidad

04/11/2019 - Agil de-mente

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

 

Mis 10 Herramientas de Facilitación

11/09/2019 - Coaching Organizacional

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.

La deliciosa paradoja de la lentitud

05/09/2019 - el próximo paso


Hace unos días, con Ricardo Colusso compartimos un webinar sobre La Deliciosa Paradoja de la Lentitud.

Ricardo me entrevistó sobre este concepto Slow y pude compartir un poco cómo invertir tiempo en pequeñas actividades de calidad, centradas, relajantes y/o para descansar nos permite luego ganar mucho tiempo y lograr mejores resultados.



Esta pequeña inversión de tiempo que repaga muchísimo luego es La Deliciosa Paradoja de la Lentitud, termino inventado por mi amigo y referente slow Carl Honoré.

A continuación les dejo la grabación del webinar:



Quiero más...

Si te interesa profundizar más sobre el tema, te recomiendo:

  • La Comunidad BeingSlow, donde compartimos con cariño experiencias, dudas, fracasos, éxitos, técnicas, ideas, delirios, sueños y más, alrededor del camino que transitamos al ir siendo slow.
  • Un recorrido vivencial y paso a paso para identificar los ritmos adecuados para tu vida personal y tu trabajo con el Taller de Slow en Buenos Aires el 8 de noviembre del 2019. 

¡Abraslow!

Webinars sobre Product Discovery

26/08/2019 - Blog de Pablo Lischinsky

Hemos hecho 2 Webinars sobre Product Discovery junto a Ricardo Colusso. El primero fue en diciembre del 2018 y cubrió estos temas: ¿Por qué Product Discovery? Proyecto vs. Producto y ciclo de vida Outputs vs. Outcomes Técnicas, herramientas y prácticas Mindset Product Discovery Dual Track: Discovery & Delivery Conocimiento y aprendizaje Product Backlog Product Teams … Leer más "Webinars sobre Product Discovery"

Scrum es un camino efectivo hacia equipos más productivos y personas más felices

14/08/2019 - Innovación y Transformación Digital

Scrum es un marco de trabajo especialmente indicado para acelerar la productividad de equipos de trabajo, mejorar la calidad de los resultados y brindar mayor felicidad a las personas que trabajan en proyectos complejos.

image
(dibujo de Martín AlaimoKleer)

Si bien fue creado en 1993, la popularidad de Scrum comenzó a crecer rápidamente recién en la década pasada –especialmente en la industria del software debido a la gran cantidad de proyectos no terminados a tiempo, de calidad incierta y con personas disconformes con los resultados. 

Y ya reconocido como una mejor forma de trabajo en la industria del software, en esta década Scrum se afianzó como un camino probado y efectivo que ya recorren equipos de trabajo en agencias de marketing, bancos, gobiernos, empresas de manufactura, escuelas, hospitales, emprendimientos, ONGs, estudios contables, producciones de películas y todo lugar donde se quiere lograr mayor productividad, calidad y felicidad para entregar mayor valor a personas, organizaciones y la sociedad toda.


Pero… ¿de qué se trata Scrum? Definido por Steve Denning en la revista Forbes como “uno de los mayores descubrimientos recientes del management”, Scrum propone:

  • 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
Utilizando Scrum hay una mayor visibilidad del avance de los proyectos sin interrumpir a los equipos de trabajo, se describe lo que hay que hacer desde la perspectiva de los beneficiarios de los resultados, y las personas disponen de  momentos de reflexión con mecanismos de mejora continua para incrementar su performance regularmente.

Material relacionado: 
- Guía de Scrum (por Ken Schwaber y Jeff Sutherland)
- entrenamiento online gratuito (por Martín Alaimo, Kleer)
- póster sobre "Agile Product Ownership" (por Pablo Lischinsky, Kleer)
- artículo sobre el rol de Scrum Master (por Damián Buonamico, Kleer)


¿Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención?

13/08/2019 - Coaching Organizacional

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.

Bonus: Guía de Preguntas de Autoevaluación

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.

Webinar: #LeSS is more

03/08/2019 - Agil de-mente

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

 

Sesgos cognitivos en la toma de decisiones participativas

30/07/2019 - Agil de-mente

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.

¿Cuales de estos sesgos cognitivos identificas en tu dia a dia?

 

 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

Los elementos esenciales de una transformación organizacional

16/07/2019 - Innovación y Transformación Digital



Una camino de transformación organizacional transitado sin un propósito claro, con las herramientas incorrectas y a un ritmo inapropiado puede tener un efecto muy negativo en  personas, equipos y la empresa completa.

El propósito de la transformación lo trae casi siempre una necesidad de que la organización pueda reaccionar y responder rápido a los desafíos que se presentan en contextos VUCA - Volátiles, con incertidumbre (Uncertainty), Complejidad y Ambigüedad por reglas que cambian sin aviso previo.

En cuanto a las herramientas contamos con marcos de trabajo y metodologías ágiles como Scrum y Kanban que fuimos enriqueciendo con elementos de Design Thinking, Product Discovery, Toyota Kata, Métodos Lean, el mindset de Lean Startup y la toma de decisiones colaborativa, entre otros.

Finalmente, podemos saber si estamos avanzando en el camino correcto cuando:
  • 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





Potenciando la Colaboración Remota

29/06/2019 - el próximo paso

La colaboración en equipos remotos ha pasado a ser una ventaja competitiva para muchas organizaciones. Y, si bien contamos con herramientas tecnológicas cada vez más adecuadas para sortear la distancias geográficas, facilitar reuniones distribuidas suele ser un gran desafío.

Para festejar los 10 años de Kleer, con Verónica Argañaraz, te proponemos participar de nuestro webinar Potenciando la Colaborazión Remota, en el cual exploraremos algunas claves para la facilitación de reuniones distribuidas, en base a prácticas grupales y conversaciones con las y los participantes.

Miércoles 3 de julio | 3 pm de Argentina (GMT-3) | Duración 60 minutos

El webinar es gratuito, solo hay que inscribirse aquí.