Buscar en Gazafatonario IT

sábado, septiembre 12, 2020

El Scrum Master y el Scrum Diario

 

Según la guía de Scrum, “los Scrum Diarios mejoran la comunicación, eliminan la necesidad de realizar otras reuniones, identifican impedimentos a remover relativos al desarrollo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo. El Scrum Diario es una reunión clave de inspección y adaptación”.

“El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo”.

Pero el Scrum Master, ni mucho menos el Dueño de Producto ni ninguna otra persona facilitan, conducen o gestionan este evento de Scrum. Es el mismo Equipo de Desarrollo en pleno el encargado de llevarla a cabo, si bien alguien como el Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión.

En el nivel Shu de Scrum, para que haya una reunión Diaria efectiva y se mantenga el espíritu de Scrum y ágil, el Scrum Master enseña al Equipo de Desarrollo a:

1.    Mantener a mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos.

2.    Planificar trabajo para las siguientes 24 horas

3.    Optimizar la colaboración y el desempeño del equipo mediante la inspección del progreso en el trabajo diario y haciendo una proyección del trabajo del Sprint a realizar a continuación

4.    Realizar el Scrum Diario a la misma hora y en el mismo lugar todos los días para reducir la complejidad

5.    Usar el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Lista de Pendientes del Sprint.

6.    Entender cómo intenta trabajar diariamente en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint

7.    Establecer la estructura de la reunión

8.    Conducirla de diferentes maneras siempre que se enfoque en el progreso hacia la Meta del Sprint

9.    Usar preguntas para llevar a cabo la reunión, pero también a basarse en discusiones y en otras tácticas para conducirla

10. Volverse a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint

11. Ser los responsables de dirigir el Scrum Diario

12. Adueñarse de la reunión. A tratarla como una reunión interna del equipo, aunque haya otras personas presentes.

Cuando el Equipo de Desarrollo ha interiorizado y practica todos estos comportamientos, para lo cual puede pasar un tiempo considerable que depende más de la actitud y el compromiso de los miembros del equipo, que del acompañamiento, necesario por demás, de un líder como el Scrum Master o un coach ágil, entonces es posible pasar a un nivel Ha de la reunión, pero eso, mi estimado amigo, podrá o podrá no ser motivo de otro trabajo.

Para saber más de la Reunión Diaria, lee también mi artículo de 2014, Compendio Sobre el Scrum Diario, en este mismo Gazafatonario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html

Y te invito a descargar el póster en alta resolución para que lo compartas con tu equipo y con toda tu empresa:


jueves, septiembre 10, 2020

Planificar historias de usuario en tareas


El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.



domingo, agosto 23, 2020

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados

viernes, julio 31, 2020

El Planning Poker me arruinó por completo

Si llegaste hasta aquí pensando que voy a estigmatizar esta práctica de estimación ágil, aún estás a tiempo de hacer clic en algún otro lugar de tu navegador. Quizás aquí, mi artículo sobre “Estimaciones en los tiempos de la agilidad”, en cuya sección final decía que si sigues estimando como hace algún tiempo seguramente no estás en el camino ágil o te alejaste de este, es más, quizás ni estés haciendo estimaciones propiamente dichas. A lo que seguí con una serie de recomendaciones que terminaban con una enfática pero respetuosa propuesta de simplemente no estimes del todo, enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Se trata precisamente de evolucionar, de seguir experimentando y aprendiendo de los resultados de nuestros experimentos. Ya dimos el primer paso y fue dejar de usar técnicas tradicionales que requerían de tener mucha información y de hacer mucho trabajo que, a la postre, se convertía en desperdicio para la organización o que, en general, no era de valor para nadie. El nivel de predictibilidad era muy bajo, tuve la oportunidad de comprobarlo una y otra vez hasta la desesperación durante dos décadas. Luego empezamos a usar técnicas de estimación relativa y juegos como Planning Poker nos enseñaron a hacer mejores predicciones acerca del trabajo sin generar tanto desperdicio de tiempo.

A veces es posible hacer algo sin hacerlo. Una de las formas de estimar es no estimar. Sé que para llegar a eso el camino es cuesta arriba, pero eso muchas veces es bueno, porque cuando lo logras, ves que valió la pena porque la vista es fantástica.*

Así que avancemos un poco por ese camino…

Enfócate en generar Valor, no estimes

Imagen de Nattanan Kanchanaprat en Pixabay

Motiva al Dueño de Producto o a quien sea tu “cliente” a Ordenar por Valor todo lo que quiere. Acompáñalo en el proceso. Haz que se enamore profundamente de esta forma de pensar y de hacer basada en el valor, pero sin que llegue a odiar las formas anteriores. Hay muchas técnicas para ordenar el backlog:

  • En función de lo que quieran tus clientes o consumidores
  • Lo que los interesados internos quieren
  • Lo que creas que impactará más
  • La antiquísima MuSCoW
  • Por Costo-Beneficio
  • RoI (Retorno de la Inversión)
  • VIP (el método del servicio preferencial)
  • El costo de la demora
  • Puedes elaborar una matriz Valor – Complejidad  

Puedes usar una combinación de estos, por ejemplo, entre dos elementos Requeridos (MuSCoW), implementa primero el que menor costo de implementación tenga y mayor beneficio te genere (Costo-Beneficio) o el que mayor retorno de la inversión te genere (RoI); entre dos elementos que te generen el mismo RoI, construye primero el de mayor costo de la demora (CoD) o el que te haya solicitado la persona más importante para tu organización de entre tus interesados. Aunque, ojo, esta persona no siempre es la de mayor rango jerárquico.

Hazlo gradualmente, de manera orgánica. Experimenta.

Imagen tomada de https://pixabay.com/images/id-512503/

Pasa de puntos de historias a tallas de camiseta. Pero no hagas un equivalente entre una talla y un número de puntos. Sería como tratar de saltar en paracaídas con una soga atada al avión, ¡no lo vas a lograr! Si lo que quieres es “medir” la velocidad del equipo, entonces cambia la escala también: ya no serán 30 o 47 puntos, sino seis elementos Talla M u ocho talla S, por ejemplo. Más adelante, busca una forma cada vez menos cuantitativa y más cualitativa de realizar la estimación, que tienda o evolucione siempre hacia el valor del incremento de producto a entregar y se aleje de una vez por todas y para siempre del esfuerzo necesario para hacer el trabajo o de la complejidad inherente a cada elemento del producto.

Evidentemente necesitarás kilometraje ágil. Tú, tu equipo y muy probablemente tu organización ya habrán llegado, al menos, a la cima de la curva de la innovación, en este caso, de cambio de forma de pensar y de hacer las cosas “a lo ágil”. Es decir, una gran mayoría temprana y un sector de la mayoría tardía, ya han entendido de qué se trata, ya han interiorizado, practican y promueven el pensamiento ágil, los valores y principios del Manifiesto Ágil, los pilares de Colabora, Entrega, Reflexiona y Mejora del Corazón de la Agilidad; y ya hay un sistema de valores de poca o ninguna variabilidad y consistente con las prácticas empresariales como base que guía el accionar de todos o de casi todos en la empresa y en su entorno.

Algunos patrones Scrum para estimar

Imagen de Achim Scholty en Pixabay

Usa patrones Scrum como el Gradiente de granularidad. (II)

Hemos experimentado y sabemos que los elementos pequeños son más fáciles de estimar, pero desglosar los elementos de trabajo es mucho trabajo en sí mismo. Las estimaciones de trabajo para pequeños incrementos de producto y tareas tienen menos errores que para los más grandes por tres razones:

·       La magnitud del trabajo (y, por lo tanto, del posible error) es menor que para un incremento o tarea más grande.

·       El equipo puede comprender mejor las entregas y tareas más pequeñas que las más grandes.

·       El porcentaje de error en las entregas y tareas más pequeñas es menor que en las grandes porque hay menos elementos de adivinanzas (y el tamaño máximo de cualquier error se mitiga implícitamente).

Por lo tanto:

Divide los primeros PBI en elementos pequeños de medio Sprint o menos de trabajo para una persona (aproximadamente el 10 % del trabajo total del Sprint) cada uno. El equipo debe desglosar los PBI posteriores para que su tamaño sea proporcional a su profundidad en el backlog Producto.

Otro patrón es el del Trabajo fijo. (III)

Scrum divide el tiempo en dos. Hay un cronograma continuo para el análisis y el negocio, y un cronograma cíclico de Sprint para la producción. El tiempo para el análisis y la innovación es imposible de estimar y puede desarrollarse durante largos intervalos, porque surge de manera impredecible en un proceso que Steve Johnson llama "la corazonada lenta" en su libro “Where Good Ideas Come From: The Natural History of Innovation”, Capítulo III, “The Slow Hunch”.

Todo el trabajo debe tenerse en cuenta si el Dueño del producto va a utilizar la velocidad del equipo para la planificación del lanzamiento del producto, pero no todo el trabajo de desarrollo puede tener un límite de tiempo.

Así que:

Divide todo el trabajo del Equipo de Desarrollo en aquel cuya duración estiman (es decir, trabajan en el producto) y lo que no pueden estimar (como el trabajo para entender los requisitos a medida que el equipo mueve los PBI a Preparado). En cada Sprint, reserva tiempos periódicos para el trabajo no estimable, fuera del presupuesto del Sprint, y completa la mayor parte de cada tipo de trabajo que permita el bloque de tiempo.

O este otro patrón del Alto valor primero.(IV)

Que hace alarde del antiguo y conocido refrán “más vale pájaro en mano que un ciento volando”, y hoy por hoy los desarrollos a corto plazo deberían ofrecer valor lo antes posible.

Las cosas así:

Haz que tu equipo desarrolle primero los elementos del Producto de alto valor más esenciales.

Imagen basada en “A Scrum book”. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

También usa patrones como El Clima de Ayer, Equipos que terminan más temprano aceleran más rápido e Illegitimus Non Interruptus no solo para hacer mejores predicciones de lo que planeas entregar sino también para llevar a tu equipo a niveles de desempeño grandiosos y entregar más valor en menos tiempo, quizás el doble del valor en la mitad del tiempo. Para saber más de estos y otros patrones puedes ir a:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Donde encontrarás sendas presentaciones para descargar y videos para ver sobre el tema.

Para finalizar

Como siempre, permite que las personas comprometidas con el trabajo decidan qué hacer respecto a la estimación. Guíalos. Muéstrales beneficios de uno u otro enfoque, de una u otra práctica. Y también perjuicios. Contrasta con el camino ágil recorrido. No es lo mismo un equipo u organización que apenas están saliendo de los enfoques tradicionales a uno que ya lleva ciertos kilómetros transitados.

Si este último es tu escenario, la próxima vez que quieras estimar algo, estima el valor de lo que vas a entregar, no el esfuerzo que te lleva realizarlo o la complejidad de lo que vas a hacer.

Y aunque no hablé de #NoEstimates, este es un movimiento, una filosofía, una visión de pensar acerca de cómo hacer algo, no es una técnica o metodología. Bueno, quizás estas ideas y propuestas constituyan un aporte a esa tendencia.

Referencias

* Basado en una frase de la película Hannah Montana (2009) que viera con mi hija Pamela, de 12 años entonces: “la vida es cuesta arriba, pero la vista es genial”.

(II) ¶59 Granularity Gradient. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(III) ¶23 Fixed Work. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(IV) ¶51 High Value First. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

Imagen de la portada basada en:

  • Imagen de Natalia Ovcharenko en Pixabay
  • Imagen de Mike Cohn en www.mountaingoatsoftware.com
  • Imagen de Agile Poker Estimation Planning Cards by Clearly Agile, Inc.

miércoles, julio 15, 2020

Cómo los dueños de producto pueden gestionar mejor las historias de usuario



Los Dueños de Producto virtuosos:

  • Expresan claramente las historias de usuario
  • Ordenan las historias de usuario para alcanzar los objetivos y misiones de la mejor manera posible
  • Aseguran que las historias de usuario sean visibles, transparentes y claras para todos
  • Los Dueños de Producto virtuosos (que Crecen) se aseguran de que los miembros del Equipo de Desarrollo entiendan las historias de usuario al nivel necesario.
  • Se aseguran de tener una visión clara del producto que quieren
  • Consiguen información de los interesados, usuarios, consumidores, del entorno, del mercado, de la competencia
  • Saben más que cualquier persona a su alrededor, pero menos que todas ellas juntas

Estas y otras ideas, en la presentación que puedes ver aquí.



Un video resumen de la presentacuión puedes ver aquí.



lunes, junio 08, 2020

El lenguaje y la transformación organizacional


Escucha el audio de este artículo aquí:

Muchas personas no creen que la terminología o el vocabulario usado importe. Pero el lenguaje se refleja directamente en los modelos mentales que hacemos de las cosas. Y los modelos son una representación de la realidad que nos rodea. Así que los modelos ayudan o soportan la construcción o elaboración de esas realidades a nuestro alrededor y de los escenarios en los que vivimos.

En los procesos de cambio o de transformación, es importante modificar no solo nuestros comportamientos sino también el vocabulario que usemos. Así la alta dirección y todos en la organización no se sentirán ansiosos pensando que nada está cambiando. Veamos un ejemplo:

De pensar en proyectos a pensar en productos

Imagen de Nattanan Kanchanaprat en Pixabay

No se trata solo de un cambio en la terminología, sino también en la forma cómo vemos e interpretamos el mundo. Se trata de la forma en que percibimos y pensamos sobre las cosas: los proyectos inician con buenas ideas, de esas que dan ganas de volver una realidad. Pero las formas de gestión tradicional de proyectos los han catapultado como “exitosos” si el plan inicial de alcance, tiempo y costo del proyecto estuvo cerca o muy cerca de los números al final del mismo: se trata del así llamado Triángulo de Hierro del management vetusto.

En principio, esto no tiene nada de malo. Son las prácticas de gestión que han predominado durante décadas en las organizaciones, aunque a muchas de estas les ha costado más de un dolor de cabeza. Pensemos en que el 88% de las compañías que el siglo pasado estaban en la lista de las 500 más grandes de Estados Unidos (Fortune 500), en 2017 habían desaparecido de la lista o de la faz de la tierra para siempre o simplemente se habían convertido en un pequeño departamento dentro de una corporación mucho más grande que las absorbió. Más sobre esto en:

http://www.aei.org/publication/fortune-500-firms-1955-v-2017-only-12-remain-thanks-to-the-creative-destruction-that-fuels-economic-prosperity/

O si no pregúntale a Nokia. Cien mil empleados, una infraestructura considerable y millones en activos y por la que Microsoft pagó incluso menos que por Skype, otra compañía muchísimo más pequeña, con apenas algunos cientos de empleados. ¿Cómo es posible que la empresa cuyas ventas de celulares se encuentran en la cima de todos los listados de ventas y que se cuentan por cientos de millones de unidades, se haya convertido en unos pocos escritorios dentro del gigante del software y luego desaparecido para siempre?

Bueno, si tú o tu empresa siguen pensando en términos de proyectos y menos en términos de productos y valor, tu destino puede cambiar rápidamente. Y más en los actuales escenarios de altísima incertidumbre y volatilidad e igualmente o más complejos y ambiguos que los de hace apenas algunos años. Es por ello que queremos reemplazar conceptos (vocabulario) como el “triángulo de hierro” de los proyectos por el triángulo ágil o por mi versión extendida que puedes encontrar en:

http://www.gazafatonarioit.com/2016/04/del-triangulo-de-hierro-al-triangulo.html

O por los conceptos mencionados de producto y de valor. El objetivo de toda organización, y el paradigma al cual se enfrentan hoy por hoy, es entregar productos o servicios de valor para sus consumidores. Productos que generen retorno de la inversión, disminuyan los costos, ganar más clientes, eliminen desperdicios en los procesos y, en fin, todo lo que signifique generar valor para la empresa.

Hoy es preferible pensar en términos del mínimo producto viable (MVP), incluso es mejor pensar en términos de experimentos y de sus conceptos subyacentes. Es lo que te permitirá cambiar la forma de hacer las cosas porque tus modelos mentales serán diferentes y, por ende, la realidad que te rodea, la realidad que construyes basado en esos modelos. Esta forma de pensar, ágil por demás, conduce a generar menos desperdicio, a mayor creatividad y a más entregas y de mejor calidad.

Sobre técnicas para encontrar el MVP y, en general, sobre la creación de productos, puedes consultar en:

http://www.gazafatonarioit.com/2016/08/inceptions-con-jorge-abad.html

Y sobre productos y su contexto, puedes leer en:

http://www.gazafatonarioit.com/2019/12/el-contexto-de-tu-producto-importa-aqui.html

De pensar en trabajo en equipo a trabajo colaborativo

Imagen de Gerd Altmann en Pixabay

Ya desde los mismos conceptos, el primero de ellos no da señales de que ese trabajo se haga efectivamente de manera colaborativa. Es posible tener un “equipo” de especialistas, como ha ocurrido históricamente, donde cada miembro elige o se le asignan tareas por hacer de acuerdo con sus habilidades específicas. Pero eso no tiene nada de colaborativo, no exige mucha comunicación entre uno y otro integrante del equipo y quizás requiera de poca o ninguna interacción entre unos y otros.

El verdadero trabajo colaborativo va más allá. Implica interacción constante, poner de manifiesto la inteligencia y las habilidades de cada persona para un bien mayor, el del equipo y el de la organización. Requiere de confianza entre las personas, de mucha comunicación, ojalá cara a cara, del establecimiento y práctica de valores como la apertura y el respeto, incluso el coraje. Requiere de mucha proactividad y de sentido de pertenencia y de familia. Bajo este paradigma no hay espacio para individualidades, el responsable de una tarea y de todas las tareas es el equipo en pleno, ningún miembro del mismo es dueño del resultado, solo el equipo.

Esta forma colaborativa de hacer las cosas hace posible la experimentación y la falla, requiere del liderazgo de todos los participantes en el equipo, rompe barreras, elimina silos, promueve recompensas a todo el grupo, no solo a unos pocos individuos, maximiza las habilidades de escucha y, en general, de comunicación, comportamientos que, a la postre, traerán como consecuencia un cambio en la cultura de la empresa, una transformación organizacional.

Estos cambios se van generando de manera natural, orgánicamente. Primero como un reflejo en nuestras mentes y en las mentes de los comprometidos con el cambio, más adelante, si lo sabemos promover, el cambio empieza a ocurrir en los demás interesados y, a partir de allí, en el resto de la organización. Finalmente esos cambios son el reflejo de nuestra forma de pensar, la que conseguimos encontrando nuevos conceptos y formas de ver e interpretar el mundo, un nuevo lenguaje que impacte positivamente nuestro modo de pensar.

Otros cambios necesarios en tu vocabulario

Estos apenas fueron un par de ejemplos sobre cómo el lenguaje impacta nuestro pensamiento y nuestra forma de actuar. Pero, en la práctica, quizás nos topemos con aspectos de la cultura organizacional, de la forma de trabajar de las personas y los equipos y de los paradigmas de gestión y de ejecución de tareas para los que no tengamos un vocabulario común o simplemente no hallemos una forma de verbalizarlo. Es allí donde es importante lo acentuado que tengamos una u otra forma de interpretación de los escenarios que enfrentemos y del contexto que tengamos de las cosas.

Con todo esto en mente, te invito a cambiar tu léxico:

·       De trabajo por habilidades o especialidades, aislado, a trabajo colaborativo, en red.

·       De una entrega final de producto a entregas tempranas y frecuentes de valor.

·       De analizar los resultados al final de un gran ciclo de trabajo (proyecto), a reflexionar sobre el estado de las cosas repetidamente: inspección y adaptación.

·       De tratar de mejorar todo y de una sola vez, a realizar mejoras graduales y pequeñas pero continuas.

·       De planificar una sola vez y ejecutar el plan, a realizar planes periódicos, quizás tanto como todos los días.

·       De pensar solo en tener éxito, a pensar en experimentar y fallar para aprender

·       De fomentar el trabajo de expertos en distintas áreas a promover el aprendizaje continuo de las personas para que adquieran habilidades T o Pi (especialistas generalistas)

·       De gastar tiempo estimando las actividades del equipo a ordenar los elementos del producto y empezar a crearlo de inmediato

·       De hacer multitarea a tener foco en una sola tarea a la vez, tanto individualmente como en equipo

Y de pensar que hay una palabra, una expresión verbal o escrita para todo, a tener presente que hay aspectos del universo que no somos capaces de modelar porque no hay forma de representarlos y allí es donde nuestras emociones y nuestro sentido común juegan un papel importante: es el fundamento o la esencia por el cual estamos aquí y la razón por la cual queremos cambiar para mejorar.

Al hacerlo, seguramente notarás un cambio en la realidad circundante. Por ahora, cuéntame en el foro qué otros cambios estás promoviendo en tu equipo y en tu organización.

Puedes ver y descargar la presentación aquí:



miércoles, junio 03, 2020

Conociendo OKR

Imagen de 3D Animation Production Company en Pixabay
Imagen de 3D Animation Production Company en Pixabay

Los OKR son un protocolo de colaboración para establecer objetivos en empresas, equipos y personas.

OKR son las siglas de Objective and Key Results, u Objetivo y Resultados Clave.

Un Objetivo responde a Qué hay que lograr. Es concreto, trascendente, realiza un llamado a la acción e inspira.

Entre tanto, los Resultados Clave son un marcador de referencia y monitorizan cómo llegamos a ese objetivo. Son específicos y se establecen en un marco temporal. Los Resultados Clave son agresivos pero realistas. Por sobre todas las cosas, deben ser medibles y verificables.

Esta es una sesión introductoria a los OKR, explico de manera sencilla de qué se tratan los OKR, cómo lucen, con algunos ejemplos y qué hacer con ellos una vez se establecen. En este apartado, hago una propuesta simple pero adaptativa para el ciclo de vida de los OKR, desde su definición hasta el cierre del ciclo temporal para el cual fueron definidos.

Al final, enumero ocho aspectos importantes a tener en cuenta cuando quieres utilizar OKR.

Puedes ver y descargar la presentación aquí:



domingo, mayo 24, 2020

Delegación en tiempos del covid-19

Son tiempos difíciles. Estamos atravesando una crisis sin precedentes en la humanidad. Con asombrosa rapidez, hemos tenido que adaptarnos a un entorno que no imaginábamos posible hace apenas algunas semanas.

Afortunadamente, para quienes hemos navegado en la incertidumbre y la volatilidad, estos escenarios no son del todo novedosos. Hemos insistido hasta la saciedad en la última década que debemos practicar y promover la adaptación a los cambios. Sabemos que la vida, como la conocemos, es capaz de transformar hábitats de una perfección inescrutable, en ambientes aún más complejos y virtuosos.

Los cambios están ocurriendo por doquier, sin parar y sin que haya un comando y control superior para dar órdenes y, para ello, en las organizaciones hemos puesto de manifiesto la necesidad de delegar. Y los tiempos actuales requieren de medidas actuales. El trabajo remoto, cuya necesidad es a todas luces evidente, demanda un alto nivel de confianza y de empoderamiento en las personas.

El objetivo es lograr que nos ocupemos de todas las tareas habituales sin supervisión, que se establezca una meta, una dirección y se fijen prioridades, se analicen los problemas, se hagan planes, se ejecuten y se tomen decisiones difíciles. Todo sin la mirada del Gran Hermano sobre nosotros. Se trata de que las personas y los equipos sean efectivamente autónomos y autoorganizados.

De eso se trata la delegación y el empoderamiento. Es sobre cómo no controlar mientras nos cuidamos de una pandemia para sobrevivir en este universo pletórico de ambigüedades y complejidades. Se trata de cómo hacerlo gradualmente aunque hoy no tenemos mucho tiempo, pero es posible pensar en delegar una gran tarea mientras nos tomamos treinta segundos para lavar bien nuestras manos y cuidarnos de la enfermedad.

Donde estamos

El empoderamiento es tan antiguo como los primeros gurús de la gestión. Con el tiempo ha sido relegado a libros de biblioteca y carteles ocasionales en compañías que han desaparecido hoy.

Durante esta crisis mundial (abril de 2020), se descubrieron las máscaras de delegación y empoderamiento. La autoridad de los colaboradores de la empresa no era más que una mascarada. Las cosas así, confirmamos que hoy, el culto a "estar presente" es altísimo. Esa cultura de estar en la oficina de 8 a 5 o algo similar no ha terminado. En Colombia lo llamamos "horas nalga". No eres un buen empleado, un buen colaborador si no estás en la oficina de trabajo al menos dos o tres horas más que eso. Tienes que irte después de tu jefe.

Es una realidad: el teletrabajo le da mucho vértigo a los jefes. Tal cómo aprendimos rápidamente de las técnicas de Management 3.0, los gerentes creen que están delegando cuando asignan actividades a sus colaboradores. Muchas veces esto es simplemente descargar tareas en las personas. Y no en el buen sentido.

¿Qué salió mal?

Las organizaciones no lograron garantizar que los supervisores y gerentes supieran delegar de manera efectiva. Y eso sucedió porque muchos gerentes nunca han recibido capacitación sobre delegación o asuntos similares. Pero no lo dudes, ¡muchos de nosotros tampoco!

Razones para no delegar

He observado varios comportamientos que los gerentes o miembros del equipo tienen cuando consideran delegar y finalmente no lo hacen:

·       Empleados incapaces: la creencia de que los empleados no pueden hacer el trabajo tan bien como el gerente

·       Falta de tiempo: la creencia de que lleva menos tiempo hacer el trabajo que delegar la responsabilidad.

·       Falta de confianza: falta de confianza en la motivación y el compromiso de los empleados con la calidad.

·       El “Solo yo puedo”: la necesidad de hacerse indispensable.

·       “Orgasmo laboral”: el placer de hacer el trabajo uno mismo.

·       Sentimiento de culpa: la culpa asociada con dar más trabajo a un personal con exceso de trabajo.

Lo que los gerentes aún no entienden es que tienen un objetivo claro que no están logrando: tienen algunas tareas que deben hacer, pero su trabajo principal es asegurarse de que otros estén haciendo lo que se les ha asignado para cumplir la misión y los objetivos de la organización.

Los gerentes efectivos saben qué responsabilidades delegar para darse tiempo para planificar, colaborar con otros en la organización y monitorear el desempeño de sus colaboradores, asegurándose de brindarles retroalimentación adecuada y oportunidades de desarrollo.

Hemos aprendido que La delegación real es asignar la responsabilidad de los resultados junto con la autoridad para hacer lo que sea necesario para producir los resultados deseados.

También hemos observado que el empoderamiento psicológico es esencial para la efectividad organizacional. Cuando esto es una realidad en varios niveles de la organización, la madurez del equipo es mayor y comenzamos a encontrar comportamientos como:

·       Relación: el empoderamiento puede ser una indicación de una relación relativamente fuerte entre el jefe y los subordinados.

·       Ausencia de miedo: los empleados empoderados tienen menos miedo de recibir retroalimentación negativa.

·       Confiabilidad: cuando se delega autoridad y responsabilidad, las personas sienten que son confiables e importantes para la organización

·       Motivación: los empleados empoderados están motivados y orientados activamente a su rol laboral.

Cuando se trata de retroalimentación, Si los empleados no se sienten empoderados, la delegación en sí misma puede no conducir a un comportamiento de búsqueda de retroalimentación. Mientras tanto, si hablamos de identidad, Cuando se delegan tareas o autoridad, los empleados experimentarán más autonomía e identidad de tarea, lo que los hace sentir más responsables de los resultados y más sensibles a la retroalimentación negativa.

Entonces, ¿qué puedes hacer para mejorar las cosas en esta materia?

No hay empoderamiento sin un proceso de enseñanza-aprendizaje o sin acompañamiento continuo. Los gerentes efectivos deben convertirse en coaches o entrenadores. Extrapolando, todas las personas en la organización deben convertirse en coaches, en líderes. Sabemos que convertir a los miembros del equipo en entrenadores ahorra costos y aumenta la moral al darles la oportunidad de brillar y ser reconocidos por su experiencia.

Sí, puedes usar los siete niveles de delegación:

Y podemos usar El Tablero de Delegación para tener las cosas en su lugar y fomentar la transparencia. De hecho, a medida que esta crisis continúa, en casa tuvimos que pasar de esto:

A esto:

... Cuando se trata de responder rápidamente y, en consecuencia, a la emergencia actual. Gracias por preguntar, ¡estamos bien ahora!

Pero las cosas no son solo blancas o negras cuando delegas en tu empresa. Tienes que tener en cuenta el nivel de madurez del equipo. Si consideramos, por ejemplo, el así llamado modelo de Tuckman:

No es lo mismo delegar a los miembros de un equipo en Formación que empoderar a las personas de un equipo en la fase de alto Desempeño. Hemos realizado experimentos con éxito: no ir más allá del nivel 2 en equipos que están en la fase de formación, por ejemplo. Además de no bajar el nivel 5 en equipos que ya tienen un alto rendimiento. En cualquier caso, la madurez del equipo no es lo único a tener en cuenta, pero es una variable que muchas veces los gerentes actuales no están considerando, y mucho menos durante esta crisis. Es un hecho: no hay confianza.

Lista de chequeo de delegación y empoderamiento

Finalmente, una pregunta que escucho mucho de los equipos que acompaño es: ¿cómo puedo conocer el nivel de empoderamiento de mi gerente o de mis compañeros de equipo? En la práctica, hay muchas maneras, las mejores son por observación, a través de una “caminata Gemba”, pero nunca está de más tener un instrumento a mano con preguntas simples que nos permitan verificar los hechos. Puedes comenzar con estos:

  • Te dieron un teléfono celular y una computadora portátil para que puedas responder cada vez que el jefe te necesite, sin importar la hora y el lugar donde te encuentres.
  • Por tu propia cuenta, no pides hacer una tarea por temor a represalias.
  • Puedes pedir tu almuerzo en la oficina sin problemas, pero no puedes comprar un bolígrafo sin la aprobación de tu jefe inmediato.
  • La última persona que se atrevió a ser proactivo y falló al proponer algo fue despedida de la compañía.
  • No estás entrenado para adquirir habilidades T y ni siquiera sabes qué es eso.

Si la respuesta a alguna de esas preguntas es "Sí", aún puede hacerlo con capacitación y entrenamiento. Si la respuesta a todas ellas es "Sí", tiene un largo camino por recorrer. Pero puedes intentarlo; Lo peor que te puede pasar es que mañana encuentres una mejor organización en la cual colaborar.

Eso es todo. Puedes encontrar más información sobre delegación en el sitio de Management 3.0. En particular, puede encontrar más información sobre Delegation Poker haciendo clic aquí.

https://management30.com/practice/delegation-poker/.

Déjame saber cuáles son tus experiencias al delegar cosas. Me encantaría conocerlas.

***

Escribí la versión original de este artículo en inglés. La encuentran en:

https://www.linkedin.com/pulse/delegation-time-covid-19-luis-antonio-salazar-caraballo/

La presentación que inspiró este artículo: