El bloc de notas de un Agilista

Todos

Scrum

Management 3.0

Agile

Project Management

Scrum

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

En Scrum, hablar de calidad del producto es hablar de la **Definición de Terminado**, la cuál es popularmente conocida como **DoD**, así a secas, DoD, un acrónimo debido a su nombre en inglés: **Definition of Done**. Esta Definición de Terminado es una descripción formal de lo que debe de cumplirse para que el producto que se está entregando cuente con las medidas de calidad requeridas. Es decir, lo que debe de cumplirse y validarse para asegurar que el producto que se está construyendo pueda ser puesto en producción, que lo pueda utilizar directamente usuario final, y que sea un producto de calidad (que no tenga fallas o bugs, que cumpla con los lineamientos de la organización, que el programa no “se rompa”, etcétera). No pretendo que este sea un artículo teórico, pero es necesario ver algo de teoría. Así que, partiendo de una “definición de libro”, veamos qué es la Definición de Terminado. De acuerdo con el Glosario de Scrum.org, la Definición de Terminado es: **“Un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.”** Aquí hay un par de ideas clave que es relevante enfatizar: • **“Entendimiento compartido”:** Esto significa que es co-creada por todo el equipo Scrum, que todos la comprenden y están de acuerdo con ella. Es decir, que no es algo que definen solo los desarrolladores como área técnica, sino que negocio, a través del Product Owner, debe de compartir este entendimiento. **• “Las expectativas que el incremento debe cumplir”:** En Scrum buscamos entregar un incremento de producto en cada sprint, esto es un incremento funcional que puede utilizar el usuario final a partir de ese momento en caso de ser requerido. Por eso, al definir en la DoD lo que el producto debe de cumplir, se crea una línea base en términos de calidad, ya que cualquier incremento de producto cumple siempre con la DoD, lo que quiere decir que hay un nivel de calidad “mínimo” establecido para todos los incrementos. **• “Para ser liberado a producción”:** Como mencionaba en el punto anterior, cada incremento de producto que se entrega debe de ser un incremento completamente funcional, que puede utilizar el usuario final, a partir de ese momento en caso de ser requerido. Al ser un entendimiento compartido, es claro y transparente para todo el equipo lo que “terminado” significa. No existe algo como “**casi-casi-terminado**”, está terminado o no lo está, por lo tanto, se puede entregar o no. Aquí me gustaría compartir 5.1 puntos muy chéveres para que puedas co-crear con tu equipo una poderosa Definición de Terminado. Estas son algunas ideas que han funcionado después de colaborar con diversos equipos. Veamos una por una: # 1. Co-creación: Ya que se trata de un entendimiento compartido por el equipo, es mucho más enriquecedor que sea co-creado por todo el equipo. Parecerá obvio este punto, pero una vez colaboré con un equipo en el cual el líder técnico definía la DoD porque era quien “tiene más experiencia”, y el resto del equipo, por ser juniors, solo se apegaba a lo definido. Nos tomó un tiempo el que pudiéramos avanzar todos juntos hacia la co-creación, pero ya llegando a ese nivel, el crecimiento del equipo y de la calidad del producto fue innegable. **La co-creación fomenta la diversidad de ideas y perspectivas, además de que ayuda s que las personas sientan que formaron parte en el proceso de crear algo nuevo, por lo que el sentido de pertenencia y compromiso aumenta.** # 2. Evolutiva: **La DoD debe de inspeccionarse y adaptarse regularmente**, no está escrita en piedra, y conforme el equipo va madurando, también la DoD debe de hacerlo. En un escenario real, ya que hablamos de responder al cambio, es necesario que la DoD se ajuste conforme el contexto técnico cambia, por ejemplo, ¿Se ha detectado un nuevo defecto o bug que no había ocurrido antes?, o ¿Qué tal cuando una actualización tecnológica hace necesaria una nueva validación? Si es el caso, agregar eso a la DoD. # 3. Visión del futuro: Ya que la DoD debe de ir madurando y evolucionado, es poderosísimo que el equipo tenga una visión compartida del estado futuro que pretende alcanzar, el nivel de calidad al cual el equipo aspira a llegar, quizá no este sprint ni el siguiente, pero sí como un estado hacia el cual el equipo va avanzando, paso a paso. Tal vez técnicamente el equipo aún no tiene los conocimientos y/o experiencia necesaria, pero está capacitándose, aprendiendo y eventualmente llegarán a ahí. # 4. No es una receta de cocina: La DoD no debe de ser prescriptiva. Indicar con puntos y comas lo que se debe de hacer como un procedimiento o receta, puede limitar la autogestión del equipo. Aquí no hay “mejores prácticas”, solo recordemos que no buscamos la documentación extensiva. Lo adecuado, como todo en la vida, es el balance. Documentar en la DoD lo justo y necesario para el equipo, no más, no menos. # 5. Transparencia real: La transparencia significa que la información debe de estar visible y disponible para las personas interesadas. En este caso, con transparencia “real” me refiero a que no solo visible y disponible es suficiente, sino que debe de ser entendible y comprensible para todos. Por ejemplo, ¿El Producto Owner sabe a qué se refiere que todo el código esté integrado?, la verdad es que no es necesario que sepa cómo hacerlo técnicamente, pero sí es importante que comprenda la esencia de lo que esto implica, y que comprenda su importancia, así como el impacto de no hacerlo. # 5.1 Y aquí un Bonus: ¡Diversión! Esto es fundamental. El cumplir con objetivos de calidad y código limpio no implica que debe de ser algo aburrido. Desde las dinámicas de facilitación para co-crear una DoD, inspeccionarla y adaptarla, hasta el aseguramiento de su cumplimiento, son oportunidades para que el equipo se divierta, se abra a lo lúdico, a nuevas ideas, fomentar las condiciones para que el equipo entre en estado de “Flow” y detone la creatividad. ¿Lo has experimentado con tu equipo? Que el equipo cuente con una DoD es esencial, si no cuenta con una,** el mejor momento para empezar a co-crearla fue el sprint pasado. El segundo mejor momento es hoy**. El hacer código limpio siempre evita problemas y dolores de cabeza, ayuda a no dejar trabajo pendiente para el final o “**escondido debajo de la alfombra**” que regresará al equipo después como problemas debido a mala calidad. El retrabajo es un tipo de desperdicio e impacta en la productividad. (image: icono-iceberg-05-large-to-web-site.webp) Para cerrar, me gustaría reforzar que el objetivo de Scrum es entregar cada sprint un incremento de producto que sea funcional, que cumpla con el objetivo del sprint y que, en última instancia, sea un paso adelante hacia el objetivo del producto… y la Definición de Terminado, es piedra angular en esto. Recordemos que** en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento de producto.** Cuéntanos, ¿Qué te parecieron estos 5.1 puntos para una poderosa DoD? ¿Qué otro punto agregarías? Me encatará leerte y que conversemos :)
2 de junio de 2023
Management 3.0

Tarjetas de colaboración: Fomentando conversaciones & armonía

En el trabajo, no somos solo empleados. También tenemos una vida, tenemos personalidad, preferencias personales, entre otras infinitas cosas. Al ser primeramente personas, nuestro estado de ánimo y desempeño en la oficina puede verse impactado por estas preferencias y rasgos personales. Conocernos unos a otros, en nuestros equipos y fuera de estos, ayuda a que las personas seamos identificados como eso, personas con una vida, y nos proporciona la sensación de que somos escuchados y que el mundo es empático con nosotros. Esto ayuda a fomentar un ambiente de trabajo que funciona mejor para todos. Por otro lado, al ignorar estos rasgos y necesidades personales, cuando sentimos que otros los ignoran constantemente, es un detonante potencial de conflictos e infelicidad en el lugar de trabajo. Y esto se ve reflejado en nuestro desempeño. **Management 3.0** llega con una propuesta: (link: https://management30.com/practice/personal-collab-cards/ text: Tarjetas Personales de Colaboración (Personal Collab Cards)), el cual puede verse como “un manual personal” con un resumen de aspectos relevantes para el trabajo, aspectos que debemos de conocer de cada persona con la que colaboramos. Las tarjetas de colaboración personal “estándar” que propone Management 3.0 contienen, entre otra información: • Zona horaria y disponibilidad para reuniones. • Canales de comunicación preferidos y formas de usarlos. • Funciones y temas de los que una persona es responsable o en los que desea ser incluida. • Intereses personales y cosas que pueden desmotivarlos • Partes interesadas con las que una persona trabaja regularmente, especialmente fuera del equipo. Poniendo un ejemplo concreto, **mi Tarjeta de Colaboración Personal **menciona cosas como: • Me llamo Leonel y gusta que me digan Leo. • Radico en Guadalajara, México, y mi zona horaria es Hora Central Estándar (CST), es decir UTC-6. • Si necesitan contactarme, mi forma predilecta es por mensaje de Whats App, así podemos ponernos de acuerdo fácilmente para una llamada o reunión (a menos que sea algo urgente). Para algo urgente no hay nada mejor que una llamada. • Si me envían un correo electrónico, entiendo que es algo que debo de atender, que es importante, pero asumo que no es algo urgente. • Mis horarios regulares para atender reuniones son de 09:00 a 18:00 horas, pero al colaborar con personas de distintos husos horarios, puedo tomar sin problema alguna reunión antes de mis 07:00 o después de mis 18:00 para alguna situación especial, solo necesitamos ponernos de acuerdo previamente. • Entre otros puntos… pero mejor, aquí comparto **mi Tarjeta Personal de Colaboración**: (image: management-3.0-personal-collab-card-leo-v01-a.webp) La **T-R-A-N-S-P-A-R-E-N-C-I-A** es la clave para a que, algo tan sencillo como las Tarjetas Personales de Colaboración, funcionen. Las tarjetas deben de estar disponibles y visibles para todas las personas con quienes colaboramos. Pegadas en un área común, si hablamos de un entorno presencial al 100%, o por ejemplo, en un tablero en Miro/Mural, en Trello o Confluence para contextos digitales o equipos distribuidos. **Como en toda herramienta visual, el punto no es el tablero o, en este caso, la Tarjeta de Colaboración, sino las conversaciones que se generan.** Y eso es lo poderoso de este tipo de herramientas. ## No hay que perder de vista el enfoque Ágil Recordemos el primer valor del (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto Ágil): **“Individuos e interacciones sobre procesos y herramientas”**, esta herramienta, la Tarjeta de Colaboración, es solo eso… una herramienta. Lo enriquecedor y realmente poderoso es la conversación entre personas que esta tarjeta fomenta. **Procuremos pues, esas conversaciones agradables, con un café, un mate o como en mi caso, un té verde, donde seamos personas charlando antes que profesionales llegando a un acuerdo.** ## Tips para pasar al nivel Jedi en Colaboración Ya para comenzar a cerrar, aquí un par de puntos importante para que los tomes en cuenta cuando apliques esto en tu equipo: 1. Las Tarjetas de Colaboración Personal no sustituyen a otras prácticas o herramientas para que los integrantes de un equipo se conozcan mejor, por ejemplo, los (link: https://www.leonelzapien.com/blog/mapas-personales-conociendo-mejor-a-un-equipo text: Mapas Personales de Management 3.0). En este sentido, se complementan. Los Mapas Personales hablan más a detalle de las personas, las Tarjetas de Colaboración se pueden ver como un “resumen” o como un “manual” de lo esencial que necesitamos conocer sobre una persona con quien colaboramos. 2. Los campos que conforman las Tarjetas de Colaboración se pueden adaptar, no es obligatorio que sean de la manera en que se muestra en la plantilla de Management 3.0, depende del contexto de tu equipo y organización. Solo recuerda conservar la esencia:** ¡Mantenerlo simple!** 3. Las Tarjetas de Colaboración no están escritas en piedra, al igual que cualquier elemento o artefacto, son dinámicas. ¿Por qué? Porque nosotros como personas somos dinámicas, evolucionamos con el tiempo, cambian nuestro contexto, nuestras ideas… por lo tanto, recuerda revisar esto con tu equipo regularmente. 4. Estas tarjetas son poderosas para hacer más suave la llegada de nuevos integrantes al equipo (súper poderoso revisarlas durante el **onboarding**). ## Conclusión Para finalizar, no es mandatorio un tiempo o espacio específico para que un equipo cree sus tarjetas, pero si lo haces: **Si das al equipo un tiempo y espacio específico para que juntos revisen, actualicen y conversen sus Tarjetas de Colaboración, por ejemplo, durante un workshop o durante una sesión de integración de equipo o team building, la atmósfera hará el ejercicio aún más enriquecedor**. Se puede enlazar esta dinámica en equipo junto con los Mapas Personales, que anteriormente ya había mencionado, y estos pueden servir como base para desarrollar dinámicas más profundas para los equipos, como el (link: https://management30.com/practice/team-agreement-canvas/ text: Lienzo de Acuerdos de Equipo (Team Agreement Canvas))… pero esto es tema de otro artículo en este blog. Te invito a que experimentes aplicando las Tarjetas Personales de Colaboración con tu equipo, siempre inspeccionando y adaptando los resultados. Si te animas, nos compartes qué resultados obtuvieron. Cuéntanos… ¿Habías escuchado hablar antes de las Tarjetas Personales de Colaboración?, ¿Qué opinas sobre sobre esta herramienta? ¿Qué información sugieres agregar para utilizarla en tu equipo?
7 de mayo de 2023
Scrum

El primer libro de Scrum del mundo

**“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”**. Así es como introducen Ken Schwaber y Mike Beedle por primera vez el evento Daily Scrum en el libro **“Agile Software Development with Scrum”**, el cual fue el primer libro escrito en la historia de la humanidad sobre el marco de trabajo Scrum, por allá del año 2001. Hace unos días estuve releyendo el libro “Agile Software Development with Scrum” (Desarrollo de Software con Scrum), el cual es conocido en el mundo de la Agilidad como **“El libro negro de Scrum” **por su característica portada. Es una joya histórica por ser el primero de miles y miles y miles de libros que se han escrito sobre Scrum a lo largo y ancho del mundo. ¿Te ha pasado alguna vez que una película o canción que “te gustaba mil” cuando eras adolescente, cuando la ves o escuchas 10-15 años después… como que ya no “conecta” contigo? De igual manera, cada que leemos de nueva cuenta un libro lo vemos con una perspectiva distinta, puesto que somos una persona “diferente” de cuando lo leímos por primera vez (nuevas experiencias de vida nos han llevado a nuevos modelos mentales, nuevos paradigmas, nueva ideología, nuevas prioridades, etcétera). En este caso, después de releer “El libro negro de Scrum” no puede ser más cierto que lo veo desde una perspectiva distinta, no solo porque yo he evolucionado como persona… sino que **Scrum, como marco de trabajo, también ha evolucionado** (a verdaderos pasos agigantados) desde que lo presentaron al mundo oficialmente en 1995 sus co-creadores Jeff Sutherland y Ken Schwaber (quien es, por cierto, uno de los co-autores de este libro). Aquí te comparto varias ideas sobre Scrum tal como fueron concebidas originalmente, así como una comparativa con el enfoque actual. Lo interesante es que, si lo vemos con las gafas o lentes de hoy,** a 21 años de la publicación de este libro, muchas de sus ideas pueden considerarse como disfuncionales o incluso antipatrones**… Entonces, ¿está mal el libro? ¡Nada de eso!, solo recordemos que estamos en la “tierra del empirismo”, debemos de crear para enseguida inspeccionar y adaptar. Así que el hecho de que Scrum haya evolucionado de la manera que lo ha hecho (y lo seguirá haciendo), es una muestra clara del empirismo aplicado a su máximo potencial. ¡Poderosísimo! Sin más rollos, aquí van algunas de estas comparativa de ideas acerca del “Scrum del primer libro” y el enfoque actual: ## 1. El Daily Scrum es una junta de estatus… que solo debe de llevar ¡el Scrum Master! **1.1 **“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum” **1.2 **“El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum. El Scrum Master mantiene el Daily Scrum breve, hace cumplir las reglas asegurándose de que las personas hablen brevemente.” Si un Scrum Master llegara este 2023 al evento internacional Scrum Day y dijera que el evento Daily Scrum es una junta de estatus, una muchedumbre con antorchas y trinchetes lo acusaría de anti-Agilista. (image: muchedumbre-con-fuego-y-trinchetes.webp) Imagen de WikiSimpsons (https://simpsons.fandom.com/es/wiki/Turba_furiosa) Me sorprendió ver que al Daily Scrum se le concibió inicialmente como una junta de estatus. Todo esto ha evolucionado, actualmente el Daily (así se le conoce en el medio, Daily “a secas”) no es para entregar estatus, tiene como propósito generar transparencia, que en equipo se inspeccione el progreso hacia el Objetivo del Sprint y adaptar según sea necesario. Respecto a la segunda idea del libro,** “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum”**, la evolución nos ha llevado a buscar el enfoque en la autogestión del equipo, es decir, que sean capaces de gestionarse sin necesidad de que un Scrum Master lo haga por ellos, por esto actualmente el Daily es un evento de los Desarrolladores para los Desarrolladores, ellos mismos inspeccionan su progreso hacia el ya mencionado Objetivo del Sprint, el Scrum Master no dirige la sesión, y, de hecho, puede no asistir y el evento no se detiene. ## 2. No es un Marco de Trabajo o Framework… es un ¿Método? En la introducción del libro, Mike Beedle (co-autor) menciona: “Tuve la buena fortuna de leer un mensaje de Jeff Sutherland y reconocer que era de hecho información muy importante. Él anunció que junto con Ken Schwaber estuvieron trabajando en **un método llamado Scrum**” Este punto me llamó mucho la atención, pues es añejo el debate sobre Scrum sobre si es un Framework y por qué no es una Metodología, pero antes de este libro nunca había visto que lo llamaran método. Para aquellos que ya conocen Scrum, disculpen que lo vuelva a mencionar, pero siempre partimos de aclarar que Scrum es un Marco de Trabajo o Framework, pues proporciona una serie de eventos y artefactos con los que se debe de trabajar, indicando 3 roles (Scrum Master, Product Owner y Desarrolladores), con esto se identifican los resultados que se desean obtener, pero no entra en ningún tipo de detalle sobre la manera en que esto debe de hacerse, es decir, deja “espacio abierto” a los propios equipos para sean ellos quienes decidan la mejor manera de hacer esto, el “cómo” hacerlo, en su contexto particular. Eso es un Framework, en tanto que un Método es un modo ordenado y sistemático de actuar o proceder para llegar a un resultado o fin determinado. Siendo muy simplistas podemos decir que es un procedimiento que se sigue para conseguir un objetivo. Un Framework deja más espacio a que las personas definan la manera de hacer las cosas, fomenta la experimentación y el empirismo, pues solo es una base para resolver un tipo de situaciones. ## 3. Enfoque en Proyectos y más Proyectos **3.1 **“Cada proyecto es diferente […] Diversas tácticas ayudan, pero sin Scrum esos proyectos fueron eventualmente abrumados por la complejidad inherente en proyectos de desarrollo de sistemas” **3.2 **“La gerencia debe de negociar de las cuatro variables [costo, fecha, funcionalidad y calidad] con los clientes “ Es oficial: **Scrum inició como un enfoque para gestionar proyectos de manera ágil**. Esto ha evolucionado en el último par de décadas y el enfoque actual no es hacer proyectos, sino productos. Esto quizá pueda sonar contradictorio, pues un producto puede ser el entregable que se genera al finalizar un proyecto, un resultado único. Esto es cierto, vivimos en un mundo de proyectos, pero la enorme diferencia es el enfoque… un proyecto se centra en entregar “algo” dentro del tiempo, costo y alcance definido, en tanto que, desde la perspectiva de producto, nos centramos en el impacto que este “algo” que entregamos produce para el usuario final. Buscamos construir productos que resuelvan algún problema del usuario/cliente, que hagan su vida más fácil. Un producto define su éxito en base al **V-A-L-O-R **que proporciona. ** P.D. #1** Personalmente siempre he creído que debemos de ir un paso más allá… un producto que resuelva un problema lo puede hacer cualquiera, **debemos enfocarnos en ¡crear productos que enamoren!** Estas son solo algunas de las ideas del “Scrum del primer libro” que plantean Schwaber y Beedle, la verdad es que hay mucha tela de la cual cortar. Es de esos temas profundos que dan para largas conversaciones acompañadas de un buen café, té, mate o la bebida de tu predilección (en mi caso, me inclino por el té verde). Por esto, y para no hacer un artículo tan extenso, en una próxima entrada de Blog continuaré con la segunda parte de “El primer libro de Scrum del mundo”. ¡Nos vemos en el capítulo 2! **P.D. #2** Mike Beedle (1962-2018), co-autor de este libro y firmante original del Manifiesto Ágil, fue mi primer maestro de Scrum. Con él tuve el enorme gusto de tomar mi primer curso de Scrum por allá del año 2014, una experiencia súper chévere! **Pero, por favor cuéntanos: ¿Conocías la esencia original de Scrum? ¿Qué opinas sobre la forma en que Scrum ha evolucionado? ¿Qué te pareció?**
26 de abril de 2023
Management 3.0

Niko-Niko calendar: Un registro de la felicidad del equipo

¿Te ha sucedido alguna vez que algún miembro de tu equipo de trabajo se muestra serio y hasta molesto en la oficina, y resulta que tenía algún problema o preocupación en su vida personal? ¿No sabes si algún compañero de trabajo ha tenido un mal día? Y si lo sabes, ¿Sabes si hay algo que puedas hacer para ayudarle? Recuerda que la forma en nos sentimos, felices o no felices, tiene un efecto en todas las áreas de nuestra vida, desde lo familiar hasta lo profesional. Es por esto que los trabajadores felices hacen más y logran más. Precisamente en este punto quiero detenerme un momento para enfocarme en la felicidad y hablar sobre si es posible medirla. ¿Existe algún tipo de encuesta de la felicidad que sea confiable? En el artículo de 2012 "La ciencia detrás de una sonrisa" ((link: https://hbr.org/2012/01/the-science-behind-the-smile text: The science behind the smile)) de Harvard Business Review, entrevistan a Daniel Gilbert, autor del libro "Tropezando con la felicidad" (Stumbling on Happiness), quien** habla de sus investigaciones sobre la felicidad y responde a la pregunta de cómo es posible medir algo tan subjetivo como la felicidad, menciona que la mejor manera para medirla es mediante los informes en tiempo real de las personas ya que son muy buenas aproximaciones de sus experiencias y nos permiten ver el mundo a través de sus ojos**. Daniel Gilbert continúa con que **es posible que las personas no puedan decirnos lo felices que estaban ayer o lo felices que estarán mañana, pero pueden decirnos cómo se sienten en el momento en que les preguntamos "¿Cómo estás?"**. El autor concluye con que hay muchas formas de medir la felicidad e indica que podemos preguntarle a la gente "¿Qué tan feliz estás ahora?" y pedirles que lo califiquen en una escala. Finalmente, un(link: https://wrap.warwick.ac.uk/63228/7/WRAP_Oswald_681096.pdf text: estudio de la universidad de Warwick) indica que las personas más felices son más productivas hasta en un 12% que las personas promedio. **Niko-Niko calendar es una herramienta de Management 3.0 la cual sirve para rastrear y llevar el registro de la felicidad de un equipo a lo largo del tiempo**, lo cual puede ser divertido y ayudar a que las personas se comprometan, ya que cuando los compañeros de equipo comparten cosas personales que suceden a diario, la comunicación genera confianza y empatía. Los detalles de esta práctica pueden encontrarse en la página oficial de Mangement 3.0 (link: https://management30.com/practice/niko-niko-calendar/ text: aquí). Estoy en un equipo de trabajo integrado por 5 personas en el área de desarrollo de software y yo soy el Scrum Master. El equipo se llama Avengers, trabajamos juntos desde hace poco más de 2 años. 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. Cuando comenzó la pandemia todos en el equipo se fueron a trabajar desde sus casas y esto creemos que esto ha afectado al equipo, pero no se dispone de ninguna herramienta para saber cómo están las personas, especialmente durante el tiempo de confinamiento. Es por esto por lo que cuando escuché sobre esta práctica de Management 3.0 me ayudó a identificar la manera de conocer y registrar el estado de felicidad del equipo de manera oportuna, lo cual fue la principal razón para realizar esta práctica, ¿Cuán felices están las personas? para tratar de conocer y motivar más al equipo de trabajo. Para facilitar la práctica, se creó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida. Se definió una escala utilizando 3 emojis, aunque en tu equipo pueden ajustar esto de acuerdo a como les resulte mejor, por ejemplo, utilizando 4 emojis en lugar de 3, es totalmente válido: (image: 07-niko-niko-caritas_large.webp) En este caso, fueron 3 emojis y cada uno de estos representa: 1) Verde: “gran día” 2) Amarillo: “día regular” 3) Rojo: “mal día” El objetivo de la práctica es que las personas registren diariamente cómo se sienten, saber cómo ha sido su día, para de esta manera poder medir la felicidad de las personas y del equipo. Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción al Niko-Niko calendar y explicación de la práctica. 2. Cada integrante coloque en la casilla del día correspondiente el emoji de acuerdo con cómo ha sido su día. 3. Se platica en equipo cómo se sienten. 4. Cierre. Las acciones que fueron llevadas a cabo como facilitador incluyen la disponibilidad de un tablero Niko-Niko calendar, impulsar a los miembros del equipo a reconocer y registrar cómo se sienten. Un punto importante es mencionar que como equipo se estuvo probando cómo les parecía mejor, si actualizar el calendario por las mañanas al iniciar la jornada, o por la tarde al finalizar el día. Ambas maneras se probaron, y en base a esta experiencia el equipo coincidió en que les parecía mejor llevarlo al final del día, para que su sentir fuera más representativo. (image: 07-niko-niko-practica-01.webp) (image: 07-niko-niko-practica-02.webp) (image: 07-niko-niko-practica-final.webp) El registro que se comenzó a llevar desde el 12 de octubre. El calendario está hecho para registrar solamente los días hábiles y no contar los fines de semana. Se completó el mes de octubre y se creó un nuevo calendario para el mes de noviembre. Durante este periodo de muestra se puede observar lo siguiente: 1. Hubo un periodo en que un miembro del equipo registró un par de días regulares antes de “mal día” durante 3 días seguidos. El compañero mencionó que se estaba comenzando a sentir enfermo, y los días malos corresponden a una gripa. Los días y el fin de semana ayudaron a que el primer lunes de noviembre ya estuviera recuperado y con buena actitud. 2. Se registró un periodo de varios “día regular” de forma consecutiva para otro miembro del equipo, esto nos permitió darnos cuenta de que, al estar estudiando una maestría, en esos días estuvo entregando trabajos y en exámenes, por lo cual se sentía estresado. Los resultados son bastante reveladores, ya que el cómo se sienten las personas, por ejemplo, cosas que les preocupen en su vida personal, afectan en la vida profesional, es por esto por lo que es fundamental darnos un minuto al día para platicar cómo nos sentimos y ver si podemos ayudar en algo como equipo, al menos apoyo emocional. Como facilitador aprendí cuán importante es la felicidad y cómo se sienten las personas y el impacto que esto tiene en la vida laboral. Así mismo, aprendí la importancia de preguntar a los integrantes del equipo cómo se siente o cómo ha estado su día. El equipo aprendió que algo tan sencillo como reunirnos un par de minutos al día para platicar cómo nos sentimos puede ayudar bastante, por ejemplo, en el caso del compañero que estuvo enfermo de gripa todos se mostraron preocupados, inclusive le ayudaron un poco con algunas actividades para que su día fuera menos pesado. Lo mismo sucedió con el miembro del equipo que estaba estresado por las actividades escolares, el apoyo de tus colegas ayuda a que las cosas sean más llevaderas. Mi próximo experimento con esta práctica será utilizar una escala numérica para cada uno de los emojis, de esta manera se pueden “sumar” los emojis y obtener un indicador numérico que funcione como índice de la felicidad del equipo, y poder llevar registros semanales o mensuales sobre cómo se siente el equipo, así como cada una de las personas. La escala numérica puede ser, por ejemplo: 1) Verde: “gran día” = 2 2) Amarillo: “día regular” = 1 3) Rojo: “mal día” = 0 Como consejos, les puedo recomendar los siguientes tips: 1. Prueba con tu equipo registrar su estado de felicidad al iniciar la jornada y al finalizar, antes de decidir con cuál opción se sienten más cómodos y elegirla. 2. Pueden optar por registrar su estado de felicidad de manera individual, pero si se toman 5 minutos para hacerlo todos juntos como equipo, es un buen momento para platicar de cómo se sienten, lo cual es muy positivo para integrar al equipo. 3. Hay que fomentar un ambiente de actitud positiva y apertura, no debes de forzar a las personas a que registren su estado de la felicidad, no es una obligación, sino una invitación abierta. Mi recomendación es que** pruebes en tu equipo qué momento del día se sienten mejor de llenar el calendario, si al inicio o al final de la jornada**. Así mismo, si tienen agendas complicadas pueden no esperar a estar reunidos todos a la misma hora, sino que cada integrante puede llenar individualmente su casilla en el calendario cuando le sea más sencillo, aunque en nuestro caso el hacerlos todos al mismo tiempo permitió dedicar un par de minutos a platicar cómo nos sentimos, lo cual fue enriquecedor. Espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que apliquen Niko-Niko calendar en su equipo, los resultados que obtendrán serán bastante felices.
16 de diciembre de 2020
Management 3.0

¿Cuáles son los motivadores intrínsecos de tu equipo?

Un **motivador intrínseco **es aquel que nos lleva a hacer algo sin una recompensa externa, por ejemplo, haces algo porque te parece disfrutable o interesante, está relacionado con los deseos innatos de las personas de hacer las cosas bien y tener un afán de autocontrol y autodirección para lograr los objetivos. La motivación intrínseca exitosa es el resultado del cumplimiento de los deseos básicos. Por otro lado, los motivadores extrínsecos están basados en recompensas externas como pagos, bonos o promociones. Como líderes, nuestra primordial tarea es mantener motivados a los miembros del equipo, la idea es que fomentemos un ambiente o entorno donde se permita desarrollar los motivadores intrínsecos sobre los extrínsecos, y los identifiquemos correctamente, porque lo que es disfrutable para alguien puede no serlo para otra persona, es por esto que es importante conocer qué motiva a cada individuo. Christine Comaford, en su artículo (link: https://www.forbes.com/sites/christinecomaford/2018/01/20/why-leaders-need-to-embrace-employee-motivation/?sh=3ec0c4e91272 text: "Por qué los líderes necesitan adoptar la motivación de los empleados" (Why Leaders Need To Embrace Employee Motivation)) de 2018 escrito para Forbes, habla sobre un estudio llevado a cabo por la empresa Gallup donde se encontró que solo **2 de cada 10 empleados coindicen firmemente en que su desempeño es gestionado por su gerente en una manera que los mantiene motivados para hacer un trabajo extraordinario**, lo que se ve reflejado en lo que Gallup estima como el **costo de una pobre gestión de empleados** que no están comprometidos, tan solo en Estados Unidos, **produce una pérdida de productividad de entre $960 billones y $1.2 trillones de dólares por año**. 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 no se cuenta con ninguna manera de conocer qué motiva a las personas. Durante algún tiempo hemos estado en búsqueda de herramientas para motivar al equipo, es por eso que decidí aplicar esta práctica creada por Jurgen Appelo, la cual ayuda a identificar los motivadores intrínsecos de las personas en el ambiente laboral. Los detalles de esta práctica pueden encontrarse en el sitio oficial de Management 3.0 (link: https://management30.com/practice/moving-motivators/ text: aquí). Los diez motivadores intrínsecos que menciona Jurgen Appelo, se derivan del acrónimo CHAMPFROGS, este acrónimo es en inglés, los motivadores en español son los siguientes: ● **Curiosidad**: Tengo muchas cosas para investigar y pensar. ● **Honor**: Me siento orgulloso de que mis valores personales se reflejen en mi forma de trabajar. ● **Aceptación**: Las personas que me rodean aprueban lo que hago y lo que soy. ● **Maestría**: Mi trabajo desafía mi competencia, pero aún está dentro de mis habilidades. ● **Poder**: Hay suficiente espacio para que pueda influir en lo que sucede a mi alrededor. ● **Libertad**: Soy independiente de los demás con mi trabajo y mis responsabilidades. ● **Relaciones**: Tengo buenos contactos sociales con las personas de mi trabajo. ● **Orden**: Hay suficientes reglas y políticas para un entorno estable. ● **Meta**: Mi propósito en la vida se refleja en el trabajo que hago. ● **Estatus**: Mi posición es buena y reconocida por las personas que trabajan conmigo. El objetivo de la práctica es identificar y reflexionar sobre la motivación de los integrantes del equipo y cómo afecta al cambio organizacional. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida: (image: 03-moving-motivators-practica-01.webp) (image: 03-moving-motivators-practica-02.webp) Para llevar a cabo la práctica se siguieron los siguientes pasos: 1. Introducción, explicación de cada uno de los 10 motivadores (CHAMPFROGS), así como de la práctica de **Moving Motivators**. 2. Cada participante ordena las imágenes de las cartas de motivadores en orden de importancia para él o ella. (image: 03-moving-motivators-board-01.webp) 3. Lo siguiente es evaluar cómo se siente cada miembro respecto a los motivadores, se mueve cada imagen hacia arriba de la línea central para un cambio positivo, es decir, algo que en mi trabajo haya mejorado mi sentir sobre este motivador en las últimas semanas. De igual manera, la imagen se mueve hacia debajo de la línea para un cambio negativo, es decir, algo que en mi trabajo haya empeorado mi sentir sobre este motivador en las últimas semanas. (image: 03-moving-motivators-board-02.webp) 4. Cada integrante explica sus motivadores y cómo se ha sentido (cambio positivo o negativo) y agrega una nota o comentario para explicar cómo se siente. (image: 03-moving-motivators-board-02_02.webp) 5. Entre todos los integrantes se eligen los motivadores del equipo de trabajo, es decir, identificar en consenso cuáles considera el equipo que son sus principales motivadores, y se ordenan en orden de importancia. (image: 03-moving-motivators-board-03.webp) 6. Se revisan los motivadores del equipo. 7. Cierre. En la siguiente imagen se muestra el tablero final ya terminado: (image: 03-moving-motivators-board-final.webp) Como facilitador aprendí una gran herramienta para ayudar a conocer los motivadores intrínsecos de las personas, ya que nunca con anterioridad se había aplicado alguna herramienta para identificar y conocer qué motiva a cada individuo. Cada persona es única, por lo que es fundamental saber qué la motiva a salir adelante día con día. Los resultados fueron diversos, y se puede observar lo siguiente: ● (C) Curiosidad: Fue el primer lugar con dos miembros, y el segundo y cuarto lugar con otros dos integrantes. ● (G) Meta: Fue el primer lugar con un miembro, el segundo lugar con dos miembros y tercer lugar con otro integrante. ● (M) Maestría: Fue el primer lugar con un miembro y segundo lugar con otro integrante. ● (F) Libertad: Fue el primer lugar con un miembro, y ocupó el segundo y tercer lugar con otros dos integrantes. ● (A) Aceptación: Fue el tercer lugar con dos integrantes. Todos en el equipo aprendimos y nos dimos cuenta de que cada individuo posee sus propios motivadores, y lo que motiva a un integrante puede no motivar en primera instancia a otro integrante. Además, fue muy revelador porque tenemos un par de años de estar trabajando juntos y había cosas que no sabíamos sobre los demás. Finalmente, en el consenso como equipo los motivadores: Curiosidad, Meta y Maestría fueron los tres elementos elegidos en las primeras posiciones, lo cual demuestra el grado en el que a las personas les motiva que su trabajo les proporcione cosas sobre las cuales investigar y les hagan pensar, que su propósito personal de vida se refleje en su trabajo, y que se desafíen a sus competencias. Mi próximo experimento con esta práctica será evaluar de forma periódica cómo se siente cada integrante con respecto al orden de sus motivadores, al menos cada seis meses, así como si ha habido cambio positivo o negativo. Esto servirá de línea base para dar seguimiento a la evolución de cada persona, así como a su sentir respecto a sus motivadores y cómo su trabajo impacta en ellos. La idea es llevar este experimento un paso adelante y revisar con mi gerente los avances para que se tome en cuenta lo que motiva a cada persona y de esta manera tratar de orientarnos en ese sentido: Permitir investigar más, brindar mayor capacitación, permitir trabajar desde casa, etcétera, dependiendo de los motivadores de cada persona, y hablar sobre los resultados en las evaluaciones de desempeño del personal. Esta es una de mis prácticas favoritas de Management 3.0, espero que esta experiencia les resulte de interés y los invito ampliamente a que apliquen **Moving Motivators** con su equipo de trabajo, los resultados que obtendrán serán increíbles.
16 de diciembre de 2020
Management 3.0

Los 12 pasos de la Felicidad :D

La felicidad es una condición subjetiva y relativa, por lo que varía mucho de una persona a otra, es una emoción que se busca alcanzar. Un estudio realizado por la universidad de Harvard demuestra que el 40% de la felicidad de las personas viene de las decisiones que tomamos. Matthew Solan, en su artículo de 2017 (link: https://www.health.harvard.edu/blog/the-secret-to-happiness-heres-some-advice-from-the-longest-running-study-on-happiness-2017100512543 text: "¿El secreto de la felicidad? Aquí algunos consejos del estudio más largo sobre la felicidad") (The secret to happiness? Here’s some advice from the longest-running study on happiness) escrito para Harvard Health Publishing habla sobre el estudio de la **Universidad de Harvard ** para el desarrollo adulto, uno de los estudios de mayor duración sobre la felicidad, el cual siguió a 724 hombre desde que eran adolescentes en 1938.** El estudio encuentra que, conforme la gente envejece, tiene a enfocarse en aquello que los hace felices, cuestiones como relaciones cercanas o hobbies, más que dinero o fama, es aquello que mantiene a la gente feliz a lo largo de su vida. ** 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. La búsqueda de la felicidad en la vida de las personas es una parte fundamental, y la forma en nos percibimos, felices o no felices, tiene un efecto en todas las áreas de nuestra vida, desde lo familiar hasta lo profesional. De la misma manera, de acuerdo con una extensiva investigación realizada por Jurgen Appelo, **la felicidad no es algo que se alcance, sino que es un camino, algo que se vive**, por lo que es primordial que contemos con formas de implementarla en nuestra vida diaria. Es en este punto donde Jurgen Appelo sugiere la práctica de **12 Pasos para la Felicidad**, enfatizando la necesidad de implementar estas prácticas en nuestra vida y transportarlas hasta la cultura de la empresa. Los detalles de esta práctica pueden encontrarse (link: https://management30.com/practice/happiness-steps/ text: aquí). Los doce pasos de la felicidad son los siguientes: ● **Agradece** a alguien y se agradecido hacia tus colegas todos los días. ● **Dar algo** a otras personas o hacer posible que otros ofrezcan regalos. ● **Ayuda** a alguien que necesite ayuda, o permitir que los colegas se ayuden mutuamente. ● **Come bien** y hacer que los alimentos buenos y saludables estén fácilmente disponibles para todos. ● **Ejercita **y trabaja con regularidad y facilita que las personas cuiden sus cuerpos. ● **Descansa bien**, duerme lo suficiente y permite que tus colegas refresquen sus mentes. ● **Experimenta cosas nuevas**, pruebas cosas y deja que la gente ejecute todo tipo de experimentos. ● **Camina al aire libre**, disfruta de la naturaleza y permite que la gente escape de la oficina y de la ciudad. ● **Medita** y consigue que las personas aprendan y adopten prácticas de meditación. ● **Socializa**, relacionarse con otras personas, hacer que sea fácil para los colegas desarrollar conexiones. ● **Apunta a una meta** y consigue que la gente entienda y se dé cuenta de su propio propósito. ● **Sonríe** siempre que puedas, aprecia el humor y consigue que tus colegas participen en actividades divertidas. (image: 12-pasos-de-la-felicidad-template-espanol-v02.webp) Puedes descargar esta plantilla de los 12 Pasos de la Felicidad del sitio oficial de Management 3.0 (link: https://management30.com/download/22948/ text: aquí). El objetivo de la práctica es reflexionar sobre la felicidad, revisar cómo se siente cada integrante del equipo en cada uno de los 12 pasos. Además, identificar qué puede hacer cada integrante en cada uno de los 12 pasos para mejorar el nivel en el que se siente. Se propone realizar la práctica con una puntuación numérica que funcione como indicador de la felicidad tanto de manera individual como para el equipo. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida: (image: 04-12-steps-to-happiness-practica-02.webp) Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción, explicación de cada uno de los 12 pasos de la felicidad, así como de la práctica. 2. Cada integrante tiene dos columnas: (image: 04-12-steps-to-happiness-board-02.webp) a. “¿Cómo me he sentido?”: Debe de colocar un valor numérico del 1 al 5 de acuerdo con cómo se ha sentido en cada uno de los 12 pasos, donde 1 es el número menor y 5 es el número de mayor puntuación. Por ejemplo: Para el paso “Dar”, un integrante colocó un “4”. b. “¿Qué haré esta semana?: Debe de escribir lo que hará para incrementar el valor numérico asignado a ese paso, algo que pueda realizar durante esa semana. Por ejemplo: Para tratar de incrementar el paso “Dar” de “4” a “5”, el integrante escribió: “Donar las cosas que ya no necesito”. (image: 04-12-steps-to-happiness-board-01.webp) 3. Los integrantes del equipo llenan los 12 pasos. 4. Enseguida se suman las columnas, es decir los 12 números, lo que resulta en un valor numérico o índice individual (el máximo valor individual puede ser 60). (image: 04-12-steps-to-happiness-board-03.webp) 5. A continuación se suman las filas de cada paso, lo que resulta en un valor numérico o índice del equipo (el máximo valor que se puede obtener por el equipo es 25, ya que el equipo está conformado por cinco integrantes). (image: 04-12-steps-to-happiness-board-04.webp) 6. El resultado de la sumatoria de todas las filas es un valor numérico que indica la forma en que se siente el equipo en ese preciso momento con respecto a los 12 pasos de la felicidad. Por ejemplo: En este caso el valor obtenido por el equipo fue “215” (el valor máximo que se puede obtener es 300). (image: 04-12-steps-to-happiness-board-05.webp) 7. Cada integrante explica al equipo cómo se siente en cada uno de los 12 pasos y qué acciones llevará a cabo para incrementar su número. Por ejemplo: Como equipo obtuvimos un “11” en el paso “Caminar al aire libre”. 8. Como equipo se definen las acciones para incrementar el número de cada uno de los 12 pasos de todo el equipo. Por ejemplo: Para el paso “Caminar al aire libre”, el consenso al que llegó el equipo es: “Todos coincidimos en salir a caminar más con nuestras mascotas y familia". 9. Se revisan los resultados finales de todo el equipo. 10. Cierre. El tablero terminado es el siguiente: (image: 04-12-steps-to-happiness-final-board.webp) El equipo se mostró muy motivado con la práctica. El hecho de analizar y hablar de diversas áreas de su vida, como caminar al aire libre, meditar, socializar o hacer ejercicio, fue muy agradable y sirvió para que todos saliéramos de la rutina del trabajo. Como facilitador aprendí la gran importancia de encontrar maneras de vivir e implementar todos esos elementos que integran nuestra felicidad, pero aplicado al equipo al que pertenezco.** El hecho de utilizar valores numéricos para cada uno de los pasos fue muy interesante ya que arrojó valores que pueden ser analizados, como, por ejemplo: ¿Cuáles fueron los pasos con menor calificación?, ¿Cuáles fueron los pasos con mayor calificación? Esto puede ayudar a llevar a cabo acciones particulares para incrementar la calificación de los distintos pasos, lo cual puede ayudar a incrementar la felicidad de los individuos.** Estos resultados numéricos fueron bastante reveladores, y se pueden observar varias cosas, como lo siguiente: ● Los resultados de los 12 pasos de la felicidad de cada miembro del equipo estuvieron entre los valores de “33” y “46”, siendo 60 el valor máximo que se podía alcanzar. Los miembros con los valores más bajos se mostraron abiertos a reconocer que hay áreas de su vida que están descuidadas, como meditar, caminar al aire libre o experimentar cosas nuevas. ● **El paso con mayor calificación como equipo fue “Ayudar”** con un total de “25”. Los miembros del equipo reconocieron que les gusta ayudar y buscan continuamente hacerlo, lo cual les brinda satisfacción. ● **El paso con menor calificación como equipo fue “Meditar”** con un total de “9”. Los miembros del equipo reconocieron que es la actividad a la que asignan menor prioridad y por lo tanto es a la que menos tiempo dedican durante su semana. Los miembros afirman que deben de programar su día y reservar tiempo para meditar, ya que saben que es algo importante. ● El resultado total de los 12 pasos de la felicidad como equipo fue el valor “215”, siendo 300 el valor máximo que se podía alcanzar. Si bien mientras el número sea más alto puede ser considerado como mejor, este resultado no es “bueno” ni “malo”, solo es un indicador del sentir del equipo en un momento particular. Todos en el equipo aprendimos bastante ya que fue muy enriquecedor escuchar a los diversos integrantes hablar sobre cada uno de los 12 pasos en su propia vida. Esta dinámica ayudó a conocernos más ya que se descubrieron cosas que no sabíamos de otros integrantes, como por ejemplo que hay algunos que meditan, o que hay algunos que les gusta darle mantenimiento a su bicicleta a fin de poder usarla durante la semana como ejercicio regular. Mi próximo experimento con esta práctica será establecer un “índice de los 12 pasos de la felicidad”, tomar el valor de 215 como línea base, que fue el resultado actual del equipo, y revisar mensualmente cómo nos sentimos como individuos y como equipo y ver en qué acciones se han estado llevando a cabo, así como si hay algo que se pueda hacer para incrementar ese índice. Espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que apliquen “12 pasos de la felicidad” con su equipo de trabajo, los resultados que obtendrán serán totalmente sorprendentes.
16 de diciembre de 2020
Management 3.0

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