El bloc de notas de un Agilista Jedi
-
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
