El bloc de notas de un Agilista Jedi
-
Management 3.0, Trabajo en Equipo
El arte de empoderar a un equipo
¿Te ha sucedido que tienes muchas cosas por hacer en tu trabajo y pareciera que no tienes tiempo para hacer nada más? ¿Has sentido que el trabajo parece no terminar nunca y no puedes ni tomarte un día libre? Si la respuesta es sí, no te preocupes, existe una solución: Delegación, y algo fundamental acerca de esta es que la delegación no tiene por qué ser binaria (delegar o no delegar), sino que tiene varios matices. Amy Gallo en su artículo (link: https://hbr.org/2012/07/why-arent-you-delegating text: ¿Por qué no estás delegando? (*Why Aren’t You Delegating?*)) de Harvard Business Review de 2012, menciona un estudio que fue llevado a cabo en 332 compañías en el cual identificaron que aproximadamente la mitad de estas tienen serias preocupaciones acerca de las habilidades de delegación de sus empleados, y al mismo tiempo, solo el 28% de esas compañías trataban de solucionar el problema proporcionando entrenamiento los trabajadores. En la empresa en la que trabajo, la delegación y empoderamiento del personal siempre han sido temas con los que se han tenido inconvenientes y, por esta razón, son puntos que se han buscado desarrollar. El equipo en el que estoy se llama Avengers, trabajamos juntos desde hace poco más de 2 años, está integrado por 5 personas en el área de desarrollo de software, y yo soy el Scrum Master del equipo. Dadas las circunstancias actuales de la pandemia estamos trabajando desde casa desde inicios de 2020. Después de escuchar sobre la herramienta **Delegation Poker** de **Management 3.0** decidí platicar sobre esta con mi gerente y le agradó la propuesta, por lo que para ver su implementación en mi equipo de trabajo primeramente fue necesario revisar con él qué tipo de decisiones podrían delegarse para probar y cuáles no, con la única condición mencionada por el gerente de no afectar al trabajo. Así, después de definir una lista en conjunto con mi gerente decidimos probar que ciertas decisiones consideradas como críticas se mantendrían como hasta ahora, tomadas por el gerente (por ejemplo, la elección de un nuevo proyecto) y otras serían probadas con la herramienta propuesta de decisiones (por ejemplo, cómo tomar los días de vacaciones). Tuve oportunidad de aplicar Delegation Poker en mi equipo. Los detalles de esta práctica pueden encontrarse en el sitio oficial de Management 3.0 (link: https://management30.com/practice/delegation-poker/ text: aquí). El objetivo de la práctica fue empoderar al equipo para que tome decisiones, clarificando quién es responsable de qué y en qué nivel. **Los siete niveles de delegación que propone Management 3.0 son**: • **Decir**: El líder toma una decisión por los demás y explica su motivación. • **Vender**: El líder toma una decisión por los demás, pero trata de convencer al equipo de que tomó la decisión correcta y los ayuda a sentirse involucrados. • **Consultar**: Inicialmente, el líder pide una opinión al equipo, que luego tendrá en cuenta antes de tomar una decisión, respetando las opiniones de las personas. • **Acordar**: El líder entabla una conversación con todos los involucrados y, como grupo, llegan a un consenso sobre la decisión. • **Aconsejar**: El líder ofrece su opinión a los demás, pero es decisión del grupo. • **Preguntar**: El líder permite que el equipo decida, y luego les pide que lo convenzan de su decisión. • **Delegar**: La decisión es tomada enteramente por el equipo. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida: (image: m30-delegation-poker-board-practica-02.webp) Para realizar la práctica se siguieron los siguientes pasos: 1. Introducción y explicación de la práctica. 2. Se define un área de decisión, se escribe en la parte superior del tablero y se expone al equipo. Por ejemplo: El área de decisión “Permisos”. (image: m30-delegation-poker-board-02_01.webp) 3. Cada integrante evalúa el nivel de delegación que considera adecuado y elige una de las siete cartas. 4. Todos los integrantes colocan su carta en la parte superior del tablero al mismo tiempo. (image: m30-delegation-poker-board-02.webp) 5. Aquellos integrantes que hayan colocado las cartas con menor y mayor valor explican sus razones al resto del equipo. Por ejemplo: En este caso la carta de menor valor es “2 Vender” y la de mayor valor es “6 Preguntar”, los integrantes que las eligieron explican su razón al equipo. 6. Si se logró un consenso, se coloca la carta que representa el nivel de delegación acordado en la sección derecha del tablero, bajo el título de “Acuerdos”. Por ejemplo: En este caso el consenso entre el equipo fue “6 Preguntar” ya que 3 de 5 integrantes la eligieron, por lo que entonces este es el acuerdo. (image: m30-delegation-poker-board-03.webp) 7. Si no se logró un consenso, se repiten los pasos 3 al 5. 8. Una vez que se hayan analizado todas las áreas de decisión, ha concluido la dinámica. 9. Cierre. La siguiente imagen muestra el tablero terminado: (image: m30-delegation-poker-final-board-01.webp) La toma de decisiones fue mediante un consenso por el equipo en cada área de decisión. Las áreas de decisión que se evaluaron, así como el nivel de delegación al que se llegó como acuerdo por el equipo son los siguientes, se explica a detalle la primera área, tomando en cuenta que el resto fueron realizadas de la misma manera: ● Días de vacaciones: Delegar La postura del gerente fue abierta a los temas que previamente se habían definido con él que podían discutirse con el equipo, los temas que él considera como críticos deben de ser definidos por él (por ejemplo, elección de un nuevo proyecto, bonos, etcétera). Lo que se platicó con nuestro gerente es que los temas no-críticos pueden servir para abrir camino y proporcionar valioso aprendizaje tanto para el equipo como para el área gerencial, y hacer ajustes en los niveles de delegación conforme ambas partes se vayan sintiendo. Delegar en este caso quiere decir que, todos los miembros del equipo contamos con determinada cantidad de días de vacaciones al año, la forma en que estos días puedan ser tomados por los miembros, será definido por el propio equipo poniéndose de acuerdo entre ellos con la única condición de que no se afecte al trabajo, sin necesidad de tener que involucrar al gerente para decidir, y ya solo se le notifica al gerente el resultado de cómo se tomarán los días de vacaciones. Esta fue la forma en que se definió por el equipo, y se realizó de la misma manera con el resto de las áreas de decisión. ● Flexibilidad de horario: Acordar ● Permisos: Preguntar ● Team building: Delegar ● Capacitación: Acordar ● Selección de fiestas y eventos: Delegar Es importante mencionar que estos niveles de delegación no son estáticos, se pondrán a prueba y podrán cambiar durante el tiempo hasta encontrar el nivel adecuado dependiente de los resultados y de cómo se sienta el equipo. Por otro lado, el equipo se mostró animado, pero con un cierto grado de inseguridad, por lo cual es necesario acompañarlo y apoyarlo en las decisiones que se tomen para que poco a poco adquiera confianza en sí mismo. Posteriormente, en revisión de los resultados con nuestro gerente, se definió comenzar con la prueba e inspeccionar regularmente para determinar si hace falta realizar algún ajuste. Es importante hacer notar a la gerencia que no se está perdiendo el control, solo está empoderando a las personas. Como facilitador aprendí a escuchar al equipo para decidir y ayudar a definir distintos niveles de delegación, enfatizando nuevamente que la delegación no es algo solamente binario, sino que hay varios matices entre hacer todo por parte del gerente y delegarlo completamente al equipo. Lo esencial es no forzar a ninguna de las partes, principalmente al equipo, el empoderamiento de la gente es un proceso que debe de hacerse con paciencia y paso a paso, y sobre todo recordando que estamos en una cultura ágil, debemos de inspeccionar y adaptar. Todos en el equipo aprendimos y nos dimos cuenta de que hay ciertas actividades que se pueden definir entre los miembros y no es necesario esperar la autorización del gerente en todo momento, lo que hace que tanto el gerente tenga más tiempo disponible para enfocarse en cosas que requieran su atención, como que el equipo se empodere poco a poco y pueda mejorar su desempeño en la toma de decisiones. Mi próximo experimento con esta práctica es volver a hacerla cada mes, para ver cómo se ha sentido el equipo y ver si es necesario hacer ajustes a los niveles de delegación que se definieron, y una vez que el equipo se sienta seguro, espaciar la práctica hasta hacerla una vez cada trimestre, una vez al semestre y después solo cuando sea necesario. Espero que esta experiencia les resulte de interés y los invito a que apliquen **Delegation Poker** con su equipo de trabajo, los resultados que obtendrán serán fantásticos.
16 de diciembre de 2020 -
Scrum
¿Qué es Scrum?
¿Has escuchado hablar sobre el término Scrum?, la verdad es que está en auge pero esta forma de trabajar existe desde hace poco más de un par de décadas. En este post hablaremos sobre lo que es (y lo que no es) Scrum, cabe aclarar que es una breve introducción, ahondaremos más en futuras entradas a este blog. Comenzamos! ###La guía de Scrum De acuerdo con la guía de Scrum: “Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.” Sus creadores, Ken Schwaber & Jeff Sutherland desarrollaron este marco a principios de la década de 1990, y oficialmente vio la luz bajo el nombre de “Scrum Development Process” en una conferencia que se celebra anualmente en Estados Unidos llamada OOPSLA (Object-Oriented Programming, Systems, Languages & Applications), celebrada en Austin, Texas en 1995. Esta es la primera vez que se utiliza el término Scrum. ###No es ninguna metodología Ojalá tuviera una galleta de chispas de chocolate (keto, sin gluten, sin conservadores y sin azúcar) por cada ocasión que he escuchado que Scrum es una metodología :D Scrum no es ninguna metodología. De acuerdo con el diccionario Merriam-Webster, una metodología es un conjunto de métodos, reglas y postulados empleados por una disciplina o conjunto de procedimientos, y Scrum definitivamente no es eso, es un marco de trabajo que proporciona unos límites dentro de los cuales podemos desenvolvernos, habilita la auto-organización y prioriza la entrega de valor. Complementando lo anterior, de acuerdo con Schwaber & Sutherland (2020), Scrum no es un proceso, técnica o método, es un marco de trabajo (framework) bajo el cual se pueden abordar problemas complejos de manera adaptativa. En las propias palabras de Jeff Sutherland (2016) cuando se le pregunta por qué Scrum, él mismo dice: “Creé Scrum, con Ken Schwaber, hace veinte años, como una manera rápida, confiable y eficaz de crear software en la industria de la tecnología. Hasta ese momento –y aún en 2005-, la mayoría de los proyectos de desarrollo de software se ejecutaban usando el método en cascada, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los consumidores o usuarios de software.” El proceso tradicional era lento e impredecible (con retrasos de meses o inclusive años), y a menudo no resultaba en un producto que la gente necesitara. Sutherland continúa, “Scrum se asemeja en cambio a los sistemas evolutivos, adaptativos y capaces de autocorregirse.” ###Viene del Rugby El término Scrum no es ningún acrónimo, ni siquiera un término tecnológico. El término procede del rugby y se refiere al modo en que un equipo se desempeña en común para mover el balón por la cancha con acoplamiento, unidad de propósito y claridad de metas. La metáfora del balón que es movido por todo el equipo en conjunto fue lo que les encantó, fue la manera en que visualizaron a un equipo trabajando todos en conjunto para crear un producto. ###Inspeccionar y Ajustar Scrum se basa en una idea simple: ¿Por qué no revisar con regularidad lo que el equipo está construyendo para que el cliente o usuario final nos de retroalimentación directa y saber ver si lo que se está haciendo va en la dirección correcta? ¿Por qué no revisar frecuentemente si se puede hacer mejor? Esto es en lo que se basa Scrum, cada determinado tiempo el equipo hace una pausa, revisa lo que hizo y determina si debe de seguir haciéndolo (así como la manera en que podría hacerlo mejor). Este tiempo es una iteración o Sprint, y tiene un duración como máximo de 4 semanas, es decir, cada 4 semanas (máximo) el cliente o usuario tendrá un incremento del producto que espera, lo podrá ver y utilizar, y nos proporcionará retroalimentación valiosa. ###Una forma de ser ágil Scrum es un marco de trabajo para ser Ágil o Agile, pero no es la única manera de serlo. Actualmente existen diversos marcos y métodos para habilitar la agilidad, entre los cuales Scrum es precisamente el más utilizado alrededor de todo el mundo. De acuerdo con el estudio Agile Adoption Reporte 2020 de CertiProf realizado a más de 80,000 profesionales ubicados en América del Sur y del Norte, España, África y Asia sobre la agilidad, el 66% de los encuestados están familiarizados o trabajan con Scrum, después le siguen Kanban con el 15%, y el resto está distribuido en porcentajes mejores 4%, por lo que la popularidad de Scrum es, con mucho, predominante, tal como se puede observar en la siguiente imagen. (image: scrum2.webp) (Imagen: Agile Adoption Reporte 2020 de CertiProf) Este marco de referencia consiste en un equipo Scrum formado de 3 roles (Scrum Master, Product Owner y Desarrolladores), 4 eventos + 1 contenedor (Sprint, Planeación del Sprint, Scrum Diario, Revisión del Sprint y Retrospectiva del Sprint), y 3 artefactos (Product Backlog, Sprint Backlog e Incremento de Producto). Cada componente dentro del marco sirve a un propósito específico y es esencial para su uso, cada uno de los cuales revisaremos a detalle más adelante en futuras entradas de este blog. ###Empirismo Cuando trabajamos con problemas complejos no hay una "mejor práctica" para abordarlos, ya que hay demasiada incertidumbre, variables e información que no se conoce. Aquí es donde Scrum proporciona un enfoque adecuado, ya que está fundado en el empirismo o teoría de control empírico de procesos, lo que significa que el conocimiento procede de la experiencia y toma de decisiones basadas en lo que es conocido. Scrum utiliza una aproximación iterativa e incremental para generar incrementos de producto y obtener retroalimentación lo más rápido posible. Esto apenas ha sido la primera aproximación a lo que es Scrum, en futuras entradas a este blog hablaremos mucho más sobre este marco de trabajo. ###Conclusiones Scrum no es ninguna metodología, es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Scrum y agilidad no son lo mismo, Scrum es, de hecho, una forma de ser Ágil o Agile, pero existen distintos marcos o métodos que permiten habilitar la agilidad dentro de un equipo u organización. Finalmente, Scrum consiste en roles, eventos y artefactos. Se basa en el control empírico de procesos, y permite construir incrementos de producto de manera iterativa para obtener retroalimentación del cliente y usuario final lo más rápido posible.
19 de septiembre de 2021 -
Management 3.0
Happiness door: Una cultura de retroalimentación
¿Por qué es tan importante la retroalimentación? Por algo tan simple: somos seres humanos y necesitamos evaluarnos y ser evaluados en nuestras acciones, por ejemplo, en el ámbito profesional, desde algo tan general como nuestro desempeño en el trabajo, hasta cuestiones específicas como un determinado proyecto, una presentación o sesión de entrenamiento. Puesto que los equipos de trabajo y las empresas están compuestas por humanos, la importancia de proporcionar retroalimentación honesta y abierta es fundamental. Como se menciona en el artículo de 2018 "¿Por qué la retroalimentación es importante en el lugar de trabajo? ((link: https://www.t-three.com/soak/insights/why-feedback-is-important text: Why feedback is important in the workplace)), una cultura organizacional rica en retroalimentación, donde las personas se sientan cómodas pidiendo y recibiendo retroalimentación realmente puede cambiar para bien el funcionamiento de un lugar de trabajo, y recomienda que las organizaciones necesitan una cultura abierta y saludable en la que las personas brinden y reciban comentarios de retroalimentación de manera regular. Aunado a lo anterior, un estudio llevado a cabo por Jack Zenger y Joseph Folkman publicado en 2014 por Harvard Business Review, en el artículo "Sus empleados quieren la retroalimentación negativa que usted odia dar" ((link: https://hbr.org/2014/01/your-employees-want-the-negative-feedback-you-hate-to-give text: Your employees want the negative feedback you hate to give)), menciona respecto a la retroalimentación y el impacto en su desempeño laboral,** cuando a las personas se les preguntó qué fue lo más útil en su carrera, el 72% dijo que pensaba que su desempeño mejoraría si sus gerentes proporcionaran comentarios correctivos, lo cual demuestra la importancia de la retroalimentación en nuestro desempeño en todas las actividades que realizamos**. Jurgen Appelo en Management 3.0 habla de la importancia de compartir lo bueno, lo malo y "lo feo", y cómo esto fomenta la felicidad colectiva y la colaboración, así como la razón por la que se solicita retroalimentación honesta, específica y oportuna. Es por esto por lo que se recomienda la práctica de Happiness Door que consiste en que las personas escriban notas Post-it que coloquen en una puerta o en un espacio visible que fomente la retroalimentación. **Happiness Door combina colaboración en equipo, compromiso de los empleados, y es una manera rápida para que las personas proporcionen retroalimentación honesta al final de una presentación, una sesión de capacitación, una reunión de negocios o cualquier interacción social.** Los detalles de esta práctica puedes encontrarlos en la página oficial de Management 3.0 (link: https://management30.com/practice/happiness-door/ text: aquí). El equipo en el que estoy se llama Avengers, trabajamos juntos desde hace poco más de 2 años, está integrado por 5 personas en el área de desarrollo de software, y yo soy el Scrum Master del equipo. Dadas las circunstancias actuales de la pandemia, estamos trabajando desde casa desde inicios de 2020. A pesar de estar trabajando de manera distribuida, en equipo de trabajo estuvimos manteniendo algunas sesiones realizando diversas prácticas de Management 3.0, y a pesar de que en general el equipo se ha mostrado emocionado al respecto, no estoy seguro de que todas las personas en el equipo se sientan convencidas y que les haya gustado la sesión, es por esto que se necesita obtener retroalimentación en tiempo real de qué es pareció, para de esta manera poder mejorar las sesiones. Es por esto por lo que decidí aplicar Happiness Door después de una sesión, tal como lo recomienda Jurgen Appelo, para conocer el sentir del equipo sobre las sesiones de Management 3.0 que hemos tenido, lo que les ha gustado, lo que no les ha gustado del todo, y lo que definitivamente no les ha gustado que se debería mejorar. El objetivo de la práctica fue obtener retroalimentación de manera sencilla y rápida de parte de las personas que participaron en la sesión remota que tuvimos en equipo. Es importante mencionar que los comentarios que cada persona escriba deben de ser completamente anónimos para que tengan la apertura de escribir lo que realmente sienten, por lo que las notas deben de ir sin nombre. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida, y se definió una escala utilizando 3 emojis: (image: 06-happiness-door-caritas_large.webp) En el tablero inicial en miro, se dividió una puerta en 3 secciones, una para cada uno de los emojis, para que los integrantes del equipo pusieran sus notas en cada sección según como se sintieran. (image: 06-happiness-door-tablero-inicial-01.webp) (image: 06-happiness-door-practica-00.webp) Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción y explicación de la práctica al final de la sesión. 2. Dar un timebox de 5 minutos máximo para que cada miembro del equipo coloque las notas que considere necesarias en cada una de las 3 secciones de la puerta. 3. El tablero está disponible para que cualquier integrante pase a dejar más comentarios en cualquier momento. 4. Revisar los comentarios de manera posterior, al inicio de la siguiente sesión. 5. Cierre. Las acciones que fueron llevadas a cabo como facilitador incluyen la disponibilidad de un tablero o Happiness door, impulsar a los miembros del equipo a proporcionar retroalimentación y promover un ambiente que fomente la apertura. El tablero terminado es el siguiente: (image: 06-happiness-door-final-board-01.webp) El equipo menciona que esta es una práctica muy sencilla pero efectiva. El hecho de obtener retroalimentación de forma oportuna y rápida sobre la sesión que se tuvo permite analizar y hacer ajustes en tiempo, ajustes que pueden ser aplicados en las siguientes sesiones. Al inicio de nuestra siguiente sesión, leímos abiertamente los comentarios, conversamos sobre la práctica, las sesiones y en general tuvimos una interesante conversación, lo cual ayuda a fomentar una cultura de apertura y retroalimentación oportuna. Como facilitador aprendí la importancia de la retroalimentación en tiempo real, y confirmé que esta es la mejor “encuesta de satisfacción” que hemos utilizado en el equipo: Sencilla, oportuna y rápida. Así mismo aprendí que escuchar al equipo en sus comentarios tiene un efecto positivo para fomentar una cultura de retroalimentación y confianza. Entre los comentarios que se obtuvieron, se destacan varias cosas interesantes, por ejemplo: 1) Cosas que al equipo le gustaron: “Me gustó la actividad”, “Me gustaron todas las actividades, que se repita más seguido”, “Música en las dinámicas”, “Buena herramienta para conocer mejor a los miembros del equipo y crear compromiso”, “Me gustó el nivel de involucramiento”, “Buena herramienta y gestión por parte de nuestro facilitador”. 2) Cosas que al equipo le no gustaron del todo: “Que duren menos las reuniones y que sean más frecuentes”, “Mencionar más ejemplos prácticos”, “Me hubiera gustado saber antes que existía una versión de la app para mi SO”. 3) Cosas que al equipo definitivamente no le gustaron (y se deben de mejorar): “Respetar los tiempos definidos”, “Que sea a distancia, espero que sea en algún momento de manera presencial”, “No comentarios”, “Nada que reportar”, “Mandar información anterior a la práctica”. Como se puede observar en los comentarios del equipo, las personas están realmente optimistas con las sesiones que hemos tenido de Management 3.0, algunas sugerencias son tener sesiones menos largas y más frecuentes, respetar los tiempos asignados a la práctica (evitar que nos extendamos), pero uno que llamó mi atención fue el ver que a la gente le gustaron las prácticas, pero que les gustaría que se llevaran a cabo de manera presencial. Si bien este último punto es importante porque en estos momentos las reuniones presenciales no son posibles, es importante observar el potencial que estas prácticas de Management 3.0 han tenido en la dinámica del equipo, y sin duda alguna el hacerlas de manera presencial reforzará aún más la integración del equipo. Todos en el equipo aprendimos bastante ya que fue muy enriquecedor leer las notas de todos al inicio de la siguiente sesión cuando se revisaron los comentarios. Esto fue enriquecedor porque permitió escuchar el sentir oportuno de las personas, lo cual aplicado a la sesión de forma inmediata permite que se generen cambios positivos en la sesión (por ejemplo, “respetar los tiempos definidos”), y al mismo tiempo ayuda a mejorar la moral de las personas al darse cuenta de que sus opiniones son tomadas en cuenta y no hay ninguna represión al respecto. Mi próximo experimento con esta práctica será añadir una nueva sección al Happiness Door, además de los 3 emojis ya explicados anteriormente, una sección adicional donde los miembros del equipo puedan agregar notas sobre “cuestiones nuevas que les gustaría que probáramos” o intentáramos en las siguientes sesiones. Esto ayudará además de obtener retroalimentación de lo que a la gente le gustó y no le gustó, para probar cosas nuevas en las sesiones, igual puede que estos experimentos puedan gustarle o no a los miembros del equipo, la cuestión es probar y hacer ajustes, recordemos que estamos en una cultura ágil de inspeccionar y adaptar. Como consejos, les puedo recomendar los siguientes tips: 1. Recordemos que la importancia de promover retroalimentación totalmente honesta radica en que sea anónima o confidencial, recordar a las personas no agregar nombres a las notas. 2. En el caso con mi equipo, las personas agregaron notas de “No comentarios” o “Nada que reportar” en algunas secciones, como en las cosas que no les gustaron. Para estos casos, sería más conveniente no agregar una nota diciendo que “no hay comentarios”. 3. Recordar al equipo que la puerta o tablero está siempre disponible para recibir más notas de retroalimentación, no debe de ser en un momento específico. 4. Hay que fomentar un ambiente de retroalimentación abierta y positiva, no debe de forzarse a las personas a que todos dejen un comentario, no es una obligación, sino una invitación abierta. Happiness Door es una poderosísima y bastante simple herramienta para obtener retroalimentación, espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que la apliquen con su equipo de trabajo, los resultados que obtendrán serán totalmente positivos.
16 de diciembre de 2020 -
Agile
¿Qué es Agile?
(Imagen: Depositphotos) El concepto de **Agilidad** o **Agile** no es del todo nuevo, pues sus principios han sido ampliamente utilizados desde hace varias décadas, sin embargo, todo comenzó a tomar forma en la industria de Tecnologías de la Información (TI), específicamente en el desarrollo de software, cuando los individuos de este sector se dieron cuenta de que se estaban presentando problemas críticos con la forma tradicional de gestionar proyectos (como la (link: https://www.leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: metodología de cascada o waterfall)), problemas que se veían reflejados en retrasos, entregables de mala calidad y baja satisfacción de parte del cliente. La metodología en cascada fue un parteaguas en la forma de trabajar, una propuesta para poner orden en el desarrollo de software, y aunque la idea tiene mucho sentido sentido: analizar el problema antes de diseñar una solución para después implementar ese diseño, en la realidad se tenían diversas áreas de oportunidad al momento de llevarla a cabo. Aun así, esta forma de trabajar dominó la industria durante varias décadas, desde su surgimiento en 1970… pero debía de haber otra forma de hacer las cosas. Durante finales de los años 80 y principios de los 90, comenzaron a surgir nuevas aproximaciones enfocadas en “procesos de peso ligero” (así se llamó inicialmente el enfoque ágil, dato curioso ¿no?), distintos al efecto cascada. Es entonces cuando surgen las primeras señales en Diseño Orientado a Objetos (ODD), Crystal Methods, Extreme Programming (XP) y Scrum. Ya estamos en 1995, y lo mejor está por venir! En febrero de 2001 un grupo de diecisiete líderes de desarrollo de software se reunieron en Snowbird, Utah, donde definieron las mejores prácticas para el desarrollo de software en base a su experiencia. La finalidad era llegar a un punto común sobre las diversas aproximaciones que estaban tomando forma por aquel entonces, y en conjunto formar un manifiesto que antepusiera la unidad. Es así como este grupo de personas elaboraron el (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto por el Desarrollo Ágil de Software), en el cual propusieron un enfoque diferente para el desarrollo de software. El manifiesto describe cuatro características principales que se deberían de priorizar sobre otras cuestiones: 1. **Individuos e interacciones** sobre procesos y herramientas 2. **Software funcionando** sobre documentación extensiva 3. **Colaboración con el cliente** sobre negociación contractual 4. **Respuesta ante el cambio** sobre seguir un plan De acuerdo con lo establecido, los equipos de desarrollo ágil deberían valorar los elementos del lado izquierdo (en negrita) antes que los del lado derecho, lo cual puede dar lugar a mejores resultados en el desarrollo del software (aunque extrapolado, esto aplica para el desarrollo de cualquier producto). Agilidad o Agile no es una metodología, por lo tanto, no se refiere a una serie pasos que indican qué hacer exactamente durante el proceso de desarrollo de software. Agile es un marco de trabajo, y en su sentido más amplio es un *mindset* o forma de pensar, es un enfoque en la colaboración con base en un conjunto de valores. Algunas de sus principales ventajas son: 1. Mejora la calidad: Minimiza los errores en los entregables, mejora la experiencia y la funcionalidad para el cliente. 2. Mayor compromiso: Mejora la satisfacción de los integrantes y genera conciencia de equipo. 3. Rapidez: Acorta los ciclos de producción minimizando los tiempos de reacción y toma de decisiones. 4. Aumento de la productividad: Al asignar mejor los recursos, y de forma más dinámica, mejora el rendimiento. Los marcos de trabajo ágiles buscan proporcionar en poco tiempo piezas pequeñas funcionales del producto entregable (software en su concepción original), reduciendo el tiempo en que el cliente o usuario “interactúa” con este producto y de esta manera acortando el ciclo de retroalimentación. Esto lleva a que se obtenga directamente del cliente/usuario una respuesta del funcionamiento del entregable, una respuesta que sirve para ver si el camino que se está tomando es el correcto, por un lado, para quienes lo están construyendo (¿lo que se está construyendo es lo que el cliente espera?), y por el otro para el propio cliente o usuario (¿lo que están construyendo es aún relevante para el negocio y realmente lo que necesito?). Si en algún punto el cliente se da cuenta de que la dirección que se está tomando no es vigente por cualquier circunstancia, los cambios son bienvenidos en cualquier momento, y no es necesario esperar hasta el final del proyecto cuando el producto esté terminado para saber si lo que se construyó es lo que se tenía en mente y lo que se necesitaba. **Conclusiones** Si bien el concepto de Agilidad o Agile no es del todo nuevo pues sus principios han sido ampliamente utilizados desde hace varias décadas, este término surge de la industria del desarrollo de software. Aunque desde finales de la década de los 80 comienzan a aparecer las primeras aproximaciones de marcos de trabajo ágiles, no es sino hasta febrero de 2001 cuando oficialmente nace la agilidad con el (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto por el Desarrollo Ágil de Software). Los marcos de trabajo ágiles de desarrollo de software buscan proporcionar en poco tiempo piezas pequeñas de sistemas de software en funcionamiento para mejorar la satisfacción del cliente/usuario. Estos marcos utilizan enfoques flexibles pues aceptan los cambios que puedan surgir en cualquier momento en lugar de resistirse a ellos.
21 de febrero de 2021 -
Management 3.0
Kudos! El poder la gratitud
**¿Hace cuánto que no te detienes un minuto para reconocer públicamente a un compañero de tu equipo de trabajo que te ayudó a completar un proyecto? ¿Te han agradecido tu compromiso y dedicación para completar las tareas en las que estabas trabajando?** Si la respuesta a las dos preguntas anteriores es negativa, no te preocupes, siempre es un buen momento para agradecer y reconocer a tus compañeros, y sus efectos en tu equipo de trabajo son muy positivos. Está demostrado que la gratitud puede tener un impacto poderoso en el desempeño y el bienestar en el lugar de trabajo. Los investigadores Francesca Gino y Adam Grant dirigieron un estudio en 2010 sobre los efectos de la gratitud en el ambiente laboral, como se menciona en el artículo "Los secretos de dar y recibir agradecimientos en el lugar de trabajo" ((link: https://ethicalleadership.nd.edu/news/the-secrets-of-giving-and-receiving-thanks-at-work-why-followers-love-it-and-leaders-hesitate-to-accept-it/ text: The secrets of giving and receiving thanks at work)). Los investigadores descubrieron que las **expresiones de gratitud podían tanto iniciar como sustentar una amplia variedad de "comportamientos prosociales", comportamientos como compartir, ayudar, ofrecerse como voluntario y cooperar con los miembros del equipo**. Así mismo, los estudios realizados por Grant y Gino sugieren que ser agradecido aumenta nuestro sentimiento de valía social. **A medida que otros reconocen el valor de nuestro trabajo, estamos dispuestos a contribuir más de nuestro tiempo, energía y habilidad.** Naz Beheshti en el artículo "Beneficios de una actitud de gratitud durante todo el año en el lugar de trabajo" ((link: https://www.forbes.com/sites/nazbeheshti/2018/11/20/benefits-of-a-year-round-attitude-of-gratitude-in-the-workplace/?sh=52ae84491bc5 text: Benefits of a year-round attitude of gratitude in the workplace)) escrito para Forbes, indica que la gratitud en el trabajo se trata de establecer relaciones entre colegas, así como también entre los empleados y la organización en su conjunto. **Cuatro de cada cinco empleados, es decir 81%, informan que están motivados para trabajar más comprometidos cuando su jefe muestra aprecio por su trabajo**. Con todo esto, se muestra claramente la importancia de expresar nuestra gratitud no solo a nuestros familiares y personas más cercanas, sino también a las personas con las convivimos al menos 40 horas a la semana, es decir, a nuestros colegas de trabajo, ya que esto puede ayudar a fomentar un mejor ambiente laboral donde las personas estén más dispuestas a contribuir con los miembros de su equipo de trabajo. El equipo en el que estoy se llama Avengers, trabajamos juntos desde hace poco más de 2 años, está integrado por 5 personas en el área de desarrollo de software, y yo soy el Scrum Master del equipo. Dadas las circunstancias actuales de la pandemia, estamos trabajando desde casa desde inicios de 2020. El nivel de compromiso del equipo es muy bueno, pero sentimos que el nivel de motivación de las personas no lo es tanto, especialmente debido a que desde que comenzó la pandemia todos se fueron a trabajar desde sus casas, el equipo se ha distancia un poco por el tema del confinamiento. Es por esto que cuando escuché sobre esta práctica de Management 3.0 me ayudó a identificar la necesidad de espacio para el reconocimiento en nuestro equipo, lo cual fue la principal razón para realizar esta práctica, reconocer a las personas para tratar de integrar y motivar más al equipo. Es en este punto donde entra una simple pero poderosísima práctica de Management 3.0 llamada kudos. **Un kudo es un reconocimiento escrito y público de una colega por algo que ha aportado al equipo, no necesariamente se da de arriba hacia abajo, sino de igual a igual y de abajo hacia arriba. **De igual manera, en todos los departamentos y organizaciones, cualquiera puede reconocer el trabajo de otra persona. Los detalles de esta práctica pueden encontrarse en el sitio oficial de Management 3.0 (link: https://management30.com/practice/kudo-cards/ text: aquí). Como menciona Jurgen Appelo, existen diversas formas de mostrar gratitud a través de kudos: una opción puede ser una caja de kudos donde las personas introduzcan sus tarjetas kudo para ser leídas enfrente de los demás de manera posterior cuando la caja sea abierta, y otra puede ser tener una pared de kudos, con notas o tarjetas pegadas y visible para todo el mundo. Lo importante es que se cuente con una forma de mostrar la gratitud a nuestros compañeros de trabajo y que se realice de forma pública. Para facilitar la práctica, se creó un tablero colaborativo en miro a manera de una pared de kudos (Kudo wall), dado que el equipo trabaja de manera distribuida: (image: 05-kudos-inicial-board-01.webp) El objetivo de la práctica es mostrar nuestro reconocimiento público de manera escrita a los integrantes del equipo con notas que muestren nuestra apreciación y gratitud hacia los miembros. Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción de los kudos y explicación de la práctica. 2. Timebox de 5 minutos para que cada integrante escriba sus notas o kudos y los coloque en la sección de la persona a la que escribió el kudo. 3. Timebox de 3 minutos para que cada integrante lea cada uno de sus kudos, uno a la vez, y la persona que se lo escribió indica que él o ella lo escribió y colocó en la pared virtual. 4. Se revisa el sentir del equipo. 5. Cierre. Las acciones que fueron llevadas a cabo como facilitador incluyen la disponibilidad de un tablero o pared de kudos, impulsar a los miembros del equipo a reconocer y agradecer a sus compañeros y promover un ambiente que fomente la apertura. Es importante mencionar que la esencia de los kudos es que estos puedan ser dados en cualquier momento, no solo durante el tiempo que duró la práctica, así que el tablero o pared de kudos está disponible y hay libertad de que continúen escribiendo kudos para alguien más en cualquier momento, cuando la persona sienta que es momento de reconocer a un compañero por su trabajo, su apoyo, su actitud, su tiempo o por cualquier cuestión que considere que es importante agradecer. (image: 05-kudos-practica-01.webp) Después de realizar la práctica, la pared de kudos es la siguiente: (image: 05-kudos-final-board-01.webp) De manera inicial los integrantes del equipo se mostraron un poco reservados o tímidos en lo que pensaban, pero solo fue un momento, ya que conforme un miembro comenzó a escribir esto fomentó que la práctica fluyera. El equipo se mostró muy motivado, fue muy divertido cuando alguien leía su kudo y después la persona que lo escribió le decía que él o ella fue el autor de ese kudo. Fue una dinámica muy breve pero productiva y muy poderosa. Y sobre todo porque el tablero se queda para que cada quién agregue kudos cada vez que así lo sienta necesario. Como facilitador aprendí la gran importancia de la gratitud, ya que en nuestra vida cotidiana llena de actividades rara vez nos detenemos un minuto a pensar, agradecer y reconocer a las personas que nos rodean, así mismo, damos por hecho que las personas saben que les reconocemos, obviamos esto que es tan importante. El equipo aprendió que cualquier puede reconocer a sus compañeros de equipo, no solo de nuestro gerente hacia nosotros, sino que puede ser realizado entre iguales. También el equipo aprendió la importante de expresar el reconocimiento de manera pública (tenemos trabajando juntos poco más de 2 años y nunca lo habíamos hecho hasta este momento). El equipo estaba muy emocionado y fomentar este tipo de cultura tendrá un impacto positivo en la motivación de las personas. Esta práctica ayudó a integrar al equipo. Todos en el equipo nos divertimos bastante, hubo sonrisas y emoción cuando alguien leía algo positivo dedicado para él o para ella, así como la sorpresa cuando se revelaba quién le escribió el kudo. Mi próximo experimento con esta práctica será utilizar las tarjetas de kudos para promover la facilidad de entregar un mensaje, lo ideal es hacerlo de manera presencial en cuanto todos volvamos a trabajar en la misma oficina, y fomentar un ambiente que promueva la gratitud y el reconocimiento: (image: 05-kudo-cards.webp) Te invito a que ayudes a promover una cultura de agradecimiento en tu equipo de trabajo mediante los kudos, mi recomendación es que no esperen a estar presencialmente juntos si en este momento están trabajando de forma remota o tu equipo es 100% distribuido debido a locaciones geográficas, en general las herramientas de Management 3.0 como kudos se pueden realizar de forma remota. Espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que apliquen kudos, los resultados que obtendrán serán bastante gratificantes.
16 de diciembre de 2020 -
Management 3.0
Mapas personales: Conociendo mejor a un equipo
Dedicamos al menos 40 horas a la semana a nuestros trabajos, interactuando con diferentes personas y de manera más cercana con nuestro equipo de trabajo, y a pesar de todo, las personas no se conocen tan bien, aunque conviven juntas día a día durante meses o inclusive varios años. Patrick Lencioni, en su libro **Las cinco disfunciones de un equipo** menciona que la primera disfunción (y la base de las demás disfunciones) es la ausencia de confianza entre los miembros del equipo, para lo cual es fundamental que los miembros del equipo estén dispuestos a abrirse ante los otros, ya que como el autor menciona: La confianza es el fundamento de un equipo cohesionado y que funciona. Sin ella, el trabajo en equipo es imposible. Es por esto, que para que la confianza y apertura exista entre los integrantes de un equipo, es necesario que se conozcan, que conozcan a la persona detrás de la corbata y el teclado, que sepan que es una persona con familia y valores, una persona con pasatiempos y metas. El equipo en el que estoy trabajamos juntos desde hace poco más de 2 años y está integrado por 5 personas en el área de desarrollo de software. Hemos detectado que los miembros nos hemos distanciado un poco, especialmente dadas las circunstancias actuales de la pandemia en que estamos trabajando desde casa desde inicios del 2020, por lo que después de escuchar sobre la cercanía mental en vez de cercanía física que promueven los **Mapas Personales** de **Management 3.0** decidí aplicarla en el equipo. Los detalles de esta práctica pueden encontrarse en el sitio oficial de Management 3.0 (link: https://management30.com/practice/personal-maps/ text: aquí). El objetivo de la práctica es que los miembros del equipo conozcan más los unos de los otros. Las categorías que se definieron para cada mapa personal fueron las siguientes: Familia, amigos, hogar, trabajo, valores, metas, hobbies y educación. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida. Para esto se siguieron los siguientes pasos: 1. Introducción y explicación de los mapas personales. 2. Timebox de 10 minutos para desarrollar cada miembro su mapa. 3. Timebox de 5 minutos para exponer el mapa personal de cada integrante (la presentación es más poderosa si es realizada por alguien más, no por el dueño de su mapa). 4. Identificar afinidades. 5. Cierre. (image: m30-personal-map-articulo-01.webp) (image: m30-personal-map-articulo-02.webp) Como facilitador aprendí una nueva herramienta para ayudar a integrar al equipo. En menos de cuarenta minutos pudimos tener una sesión muy enriquecedora para conocernos, que sirve como una dinámica de integración de equipo o *team building*. Todos en el equipo aprendimos y nos dimos cuenta de que no nos conocíamos tan bien realmente. Tenemos un par de años de estar trabajando juntos y había cosas que no sabíamos sobre los demás, como por ejemplo respecto a temas de familia, o las metas de los diversos miembros. Mi próximo experimento con esta práctica será agregar nuevas categorías: el equipo se quedó emocionado y quieren más categorías para conocernos aún mejor. Trabajaré con el equipo para proponer y votar entre todos para elegir estas nuevas categorías, por ejemplo: Películas, libros, viajes de vacaciones, superhéroes o cómics, música, comida favorita. Con lo anterior, haremos una nueva sesión de mapas personales extendida. Espero que esta experiencia les resulte de interés y los invito a que apliquen **Mapas Personales** con su equipo de trabajo, los resultados que obtendrán serán sorprendentes.
16 de diciembre de 2020 -
Project Management
Gestión de Proyectos en cascada (waterfall)
De acuerdo con el Instituto de Gestión de Proyectos o PMI por sus siglas en inglés (Project Management Institute, el cual es una organización estadounidense sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos), un proyecto es un esfuerzo temporal, con una fecha de inicio y fin determinadas, y que tiene como finalidad crear un producto, servicio o resultado único. La Gestión de Proyectos se define como un conjunto de conocimientos, habilidades, herramientas y técnicas para describir, organizar y monitorear el avance de las actividades de un proyecto para lograr los objetivos del mismo. Todo proyecto tiene un ciclo de vida que se refiere a la serie de fases por las que éste atraviesa desde su inicio hasta su conclusión, y proporciona el marco de referencia requerido para dirigir el proyecto en cuestión. La mayoría de los proyectos están divididos en estas fases, y sin importar si son pequeños o grandes, todos tienen un ciclo de vida y estructura similar. Las fases de un proyecto consisten de segmentos de trabajo que permiten una fácil gestión del mismo, algunos proyectos pueden tener una sola fase en tanto que otros pueden contener múltiples. Este número de fases puede variar dependiendo de la complejidad del proyecto, así como de la industria en la que se crea el mismo. Los ciclos de vida pueden ser predictivos, iterativos, incrementales, adaptativos o híbridos. Si bien hablaré de diversos ciclos de vida en otras entradas de mi blog, para el tema en cuestión, nos centraremos en este momento en los ciclos de vida predictivos: · **Ciclo de vida predictivo**: El alcance, tiempo y costo del proyecto son determinados en las fases iniciales del mismo, por lo que también se les denomina ciclos de vida en cascada (del inglés “waterfall”). La metodología en cascada es la metodología de Gestión de Proyectos de mayor difusión y uso durante los pasados 40 años, y hasta bien entrada la década de 1990, la mayoría de los proyectos se ejecutaban utilizando esta metodología, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los clientes finales. El nombre de “cascada” proviene de la similitud en que las fases son representadas, una después de la otra, como se muestra en la siguiente figura: En el método de cascada, cada paso o etapa debe de ser completado al 100% antes de moverse al siguiente, y todas estas etapas deben de ser completadas antes de entregar valor al cliente. Este método es conocido como “conducido por el plan” (del inglés plan-driven) debido al nivel de diseño y conceptualización que se realiza al inicio del proyecto, y se pasa por todas los grupos de proceso de gestión que indica el PMI: Inicio, planeación, ejecución, monitoreo y control, y finalmente el cierre. Este proceso, de levantar todos los requerimientos en la etapa inicial, si bien era funcional hace unas décadas, hoy en día es complicado de mantener debido a la evolución del entorno: El dinamismo de los mercados actuales, proyectos más complejos y ciclos de vida de productos cada vez más cortos. La etapa de análisis era por lo general lenta y tenía un alto grado de imprevisibilidad, lo que resultaba, por un lado, a menudo en un producto final o entregable distinto de lo que el cliente esperaba, y por otro lado, en un retraso de meses o inclusive hasta años para que el cliente viera resultados tangibles. Es por esto que, la tradicional metodología de cascada para la gestión de proyectos ha necesitado evolucionar, a la par que los marcos de referencia ágiles han ido creciendo en popularidad desde la década de 1990, siendo actualmente bastante utilizados (punto que por cierto abordaré a detalle en otras entradas de este blog). ### **Conclusiones** La metodología de cascada ha liderado la gestión de proyectos durante los últimos 40 años, nos ha enseñado la gestión de la integración del proyecto, del alcance, del tiempo, de los costos, de la calidad, de los recursos humanos, de las comunicaciones, del riesgo, de las adquisiciones, y de los interesados o stakeholders. En esta metodología los requerimientos se definen al inicio y se realizan todos los planes subsidiarios para posteriormente comenzar con la ejecución del proyecto, pero las condiciones del entorno actual requieren mejor manejo de la incertidumbre, especialmente en entornos complejos en los cuales los marcos de trabajo ágiles han demostrado ser bastante eficientes, razón por la cual estos marcos de trabajo han ido aumentando en popularidad en los últimos años.
16 de junio de 2020