Axia

Agile

Los 10 principales errores al convertirse en una organización Agile

Los 10 principales errores al convertirse en una organización Agile

Caer en los 10 principales errores al convertirse en una organización agile es una de las principales novatadas que cometemos al querer implementar un cambio en la cultura de nuestra empresa. Por eso, para evitar ser uno más a la hora de pasarnos a la agilidad, te proponemos que revises con nosotros si has caído en alguna de las más habituales trampas o si aún estás a tiempo de esquivarlas. ¿Has cometido alguno de estos errores al convertirse en una organización agile? 10. Implementación de Agile “from TOP to DOWN” Hay organizaciones que implementan metodologías ágiles de arriba hacia abajo. La dirección de la organización dice a los equipos que tendrán que estar trabajando de forma ágil y también establece el cómo y el cuándo. Pero ágil se trata de trabajar a modo de equipos autoorganizados con el objetivo de crear “valor”. Tiene sentido que la dirección comunique el propósito o el objetivo. Pero este es un viaje que debe emprenderse juntos. Cada equipo es único, como lo es cada producto. Esto requiere que los equipos decidan qué es lo que funciona para ellos. 9. Implementación de la cultura del cambio Estrechamente relacionado con la implementación Top/Down de Agile está la idea de que se puede implementar una cultura de cambio publicando un manual de cultura o creando algunos procedimientos nuevos. No funciona de esa manera. La cultura de una organización es algo que ha sido desarrollado durante años por todas las personas que han formado o forman parte de ella. No puedes simplemente cambiar la cultura. La nueva cultura se debe de crear con la ayuda de los profesionales mostrando desde uno mismo el comportamiento deseado y apoyando el comportamiento ejemplar de los demás. Y debemos ser pacientes. 8. Centrarse en la producción Muchas empresas cuentan con equipos ágiles que se centran totalmente en la creación y entrega. Se centran en el tiempo de comercialización y la automatización de pruebas… todo ello para entregar cada vez más rápido. Pero este enfoque solo en la entrega rápida es un antipatrón ágil. Porque no importa mucho la rapidez con la que se entreguen los nuevos productos cuando estos no son lo que el cliente quiere. Lo que realmente importa es el impacto de más valor que se genera con el resultado. 7. Ignorar a los clientes y usuarios Muchos equipos ágiles solo tienen una vaga idea de quiénes son sus usuarios o qué quieren sus clientes. Nunca están en contacto con las partes interesadas vitales. Pueden tener sus demostraciones o revisiones periódicas, pero los asistentes son interesados internos. Ya se considera un éxito ver a gente de ventas en la reunión, pero ventas no son el cliente. Los equipos construyen sus productos para clientes y usuarios. Los clientes y usuarios deben participar. La idea de Agile es verificar el producto con los usuarios de forma regular. Sin esta verificación, no hay base para ser ágiles. 6. Agile es solo cosa de TI Agile a menudo se considera erróneamente solo para departamentos de Tecnología e Información (TI). Que TI debe ser ágil y el resto de la organización no necesita cambiar. Esto no contempla el hecho de que, además de TI, muchas otras personas ayudan a crear una experiencia de cliente. Y sin alineación, no se le atenderá correctamente. La TI es solo una parte de la experiencia del producto, la experiencia que el usuario tiene con el mismo. También debemos incluir a ventas, soporte… Todos están en el mismo barco: “maximizar el valor del producto como un todo en un entorno en constante cambio”. Esto requiere colaboración entre todas las personas y mantener ciclos rápidos de retroalimentación o feedback. Significa que todas las partes necesitan ser ágiles. 5. Agile solo a nivel de equipo Uno de los conceptos erróneos más grandes es que Agile solo se aplica a los equipos que crean el producto. Mientras estos equipos sean ágiles, se considera que todo está bien. Pero no funciona de esta manera. Los equipos trabajan en una organización y se ven constantemente afectados por esa organización. Cuando las organizaciones muestran un comportamiento anti-ágil, esto puede perjudicar a los equipos. Puede dañar el potencial de ese equipo para crear valor. La dirección, el liderazgo, los recursos humanos y otros departamentos deben fomentar los equipos ágiles. Además, toda la organización debe estar alineada en cómo crear una experiencia de producto y lograr sus objetivos de manera ágil. 4. Agile se trata de una entrega más rápida Agile no significa entregas más rápidas. Se trata de comprender que no se puede saber todo por adelantado; por lo tanto, el objetivo debe ser crear pequeños incrementos para revisar con los usuarios. Se trata de una retroalimentación más rápida y, después, tener una mejor idea de qué hacer a continuación. Se trata de saber lo antes posible qué funciona y qué no, y todo ello en colaboración con sus usuarios. Centrarse en una entrega más rápida e ignorar el ciclo de retroalimentación lo convierte en una fábrica de funciones. Eres muy bueno creando resultados, pero crearás productos que la gente no quiere. 3. Implementando Agile en cascada El viaje para volverse ágil no se realiza con un análisis prolongado y un plan detallado a largo plazo con flujos de trabajo controlados por fases. Una forma ágil de trabajar es un cambio claro del pensamiento tradicional de «cascada». Los equipos no deben de “analizar en exceso” su trabajo, sino que deben de aprender de la creación de nuevos incrementos de producto. Obtendrán información sobre el valor del producto más rápido y también encontrarán mejores formas de colaborar. Establece objetivos al comienzo del viaje ágil y encontrarás las mejores formas de lograr estos objetivos. Tienes que aprender de las cosas que hiciste, de lo que funcionó y de lo que no. Y hacer esto involucrando a los equipos como un esfuerzo conjunto. 2. Implementar procesos y herramientas “inalterables” Una de las formas más dolorosas de volverse ágil es implementar un enfoque listo para usar. Los equipos pueden recibir

Los 10 principales errores al convertirse en una organización Agile Leer más »

Resumen desayuno AXIA: Cómo trabajar el liderazgo agile y saludable

Resumen desayuno AXIA: Cómo trabajar el liderazgo agile y saludable

El pasado 15 de junio pusimos la cafetera a trabajar a primera hora de la mañana en una nueva edición de nuestros Virtual Breakfast – AXIA. Bajo el título “Cómo trabajar el liderazgo agile y saludable”, Sabino Beaskoetxea presentó a los y las asistentes a Mercedes Miguel (Consultora Agile y colaboradora en AXIA), nuestra facilitadora de la sesión. “Las personas y las relaciones están por encima de los procesos y las herramientas”. Con esta sentencia del Manifiesto Ágil, Mercedes dio por comenzada la jornada. Porque, precisamente, el bienestar de nuestros colaboradores es primordial para conseguir un liderazgo saludable en nuestras organizaciones. Porque un líder “tiene que velar por la prevención de los riesgos psicosociales de la empresa”. Y para ello, un líder saludable debe tener una serie de características: La importancia de los motivadores para el liderazgo agile y saludable Para que un líder lo sea, también debe tener en cuenta las motivaciones de nuestros trabajadores y trabajadoras. Motivaciones que pueden ser extrínsecas (como bonos o compensaciones económicas) o intrínsecas (motivaciones internas de desarrollo personal). Y, a pesar de que en muchas ocasiones no está en su poder responder a ciertos requerimientos como los económicos, un líder “sí que tiene poder sobre cómo se sienten las personas en su día a día, qué trato reciben desde un punto de vista profesional y humano”, comenta Mercedes. Para ello, podemos trabajar los Motivadores según el modelo de liderazgo ágil del Management 3.0., que plantea 10 motivadores intrínsecos: Un buen líder además debe trabajar la gestión de los reconocimientos a los empleados y empleadas, y puede hacerlo mediante una serie de herramientas como Kudo Box, Kudo Wall, aprovechar el cierre de una reunión para agradecer el esfuerzo… Y no olvidar la importancia del Feedback, lo que puede favorecer la autonomía y la creación de espíritu de equipo, la involucración de los miembros de este en los diferentes proyectos… La jornada terminó con un debate entre los participantes, a los que no podemos dejar de dar las gracias: Farmaconsulting Transacciones, Viscofan, Distribuidora Farmaceutica De Gipuzkoa-Gipuzkoako Farmazi Banatzailea SL, , Uvesco S.A., Forum Sport S.A., Financiera Maderera S.A. (FINSA), Lantegi Batuak, ZABIK SA y Vidrala. ¡Gracias por participar y hacer tan interesantes estas sesiones! ¡Os esperamos en nuestro próximo Desayuno Virtual! ¡Seguimos! – Always with you

Resumen desayuno AXIA: Cómo trabajar el liderazgo agile y saludable Leer más »

Resumen del “Virtual Breakfast AXIA – Cómo liderar y gestionar equipos remotos en marco Agile”

Resumen del “Virtual Breakfast AXIA – Cómo liderar y gestionar equipos remotos en marco Agile”

El pasado 7 de octubre tuvo lugar el penúltimo de nuestros Virtual Breakfast – AXIA de 2021 titulado “Cómo liderar y gestionar equipos remotos en marco Agile”.  Igor Arrizabalaga (CEO de AXIA) junto a Mercedes Miguel (Consultora Agile de AXIA) facilitaron este encuentro de dos horas con miembros de empresas interesadas en adentrarse en el mundo de la agilidad. En la presentación, intentamos desmontar los mitos del trabajo en remoto. Unas prejuicios que en muchas ocasiones generan rechazo en las organizaciones a la hora de implantar el home-office como alternativa al trabajo en la oficina. A continuación sentamos las bases para liderar equipos remotos de manera efectiva. Para ello, hay que seguir una serie de indicaciones que pueden ayudarnos a gestionar al equipo remoto de manera eficaz: construyendo la ‘Home Base’ de nuestros colaboradores y trabajadores, evitando interrupciones innecesarios y facilitando la comunicación cara a cara incluso desde casa, asegurando el cumplimiento y respeto de los horarios… SCRUM y sus ceremonias para un trabajo en remoto de éxito Existe dentro del marco agile una serie de ceremonias o reuniones a tener en cuenta, que pueden ayudarnos con el trabajo diario y el buen desempeño en nuestras organizaciones. Desde la daily, pasando por una planning, una review hasta una retrospectiva, todas estas ceremonias son de gran utilidad para el seguimiento de los proyectos en marcha. Management 3.0, ¿cómo puede ayudarnos a liderar y gestionar equipos remotos? Muchas de las claves del éxito del trabajo en remoto vienen de la mano del Management 3.0. Por ejemplo, no debemos olvidar energizar y motivar adecuadamente a las personas que trabajan en nuestras organizaciones, empoderándoles a la hora de su desempeño. Una clara definición de los objetivos de los trabajadores y trabajadoras es de vital importancia, de la misma manera que lo es la facilitación del desarrollo de las competencias de todos ellos. Y para todo ello no hay que olvidar la necesidad de implantar sistemas que faciliten y mejoren la comunicación, teniendo en cuenta la necesidad de una mejora continua para solventar los conflictos y problemas que surjan a lo largo del tiempo. Para concluir la sesión, presentamos a los asistentes un listado de herramientas de gran valor para gestionar sus equipos remotos: herramientas de comunicación como Zoom o Meet, de colaboración como los tableros de Mural o Miró, de liderazgo como Zeppelean o ThriveIndex… Una gran sesión que no pudo ser posible de no ser por la gran participación de los asistentes. Gracias a Inycom, Gestamp, VEGAP, Serban Biometrics – Serban Group y Daimler AG por vuestro interés. ¡Seguimos! – Always with you 

Resumen del “Virtual Breakfast AXIA – Cómo liderar y gestionar equipos remotos en marco Agile” Leer más »

Problemas de Agile por los que esta metodología sigue fallando (y sus soluciones)

Problemas de Agile por los que esta metodología sigue fallando (y sus soluciones)

Si hablamos con desarrolladores sobre el enfoque ágil de su organización, vemos que en muchas ocasiones nos trasladan los mismos problemas de agile. A continuación os hacemos una reflexión de estos Uno de los principales problemas de agile: reuniones, reuniones, y más reuniones  Liderazgo Agile Se supone que Agile es para un marco definido para y por los técnicos, ¿verdad? A un grupo de técnicos se les ocurrió Agile para reemplazar metodologías “waterfall”, y se suponía que sería la panacea para mejorar los procesos de desarrollo de software.   El principal problema es que muchas personas no tienen ni idea de cómo funciona el desarrollo de software en el mundo real. Solo saben lo que se les enseña en un curso de Agile de 2 días. Esto se hace evidente cuando insisten en cosas que simplemente no tienen sentido. Una de esas cosas es involucrarse en discusiones técnicas. Muchas veces nos pasamos de 10 a 15 minutos tratando de explicar los detalles técnicos a alguien que no es técnico. También terminamos teniendo que repetirnos constantemente porque no cuentan con la base técnica necesaria. Esto es algo que no tiene absolutamente ningún sentido y algo que vemos frecuentemente.  Muchas veces el liderazgo ágil intenta incluir a demasiadas personas en una reunión, a menudo los Scrum Master intentan incluir tantas personas como le sea posible en una reunión. Pongamos un ejemplo. Una empresa ha decidido introducir una nueva función en el producto principal. Se han dado todos los requisitos y ahora los equipos técnicos deben encontrar una forma de introducir la función. Es lógico que haya una discusión técnica sobre cómo encajar mejor esta pieza en el rompecabezas. Este es un ejemplo de una reunión que SOLO debería ocurrir entre los líderes técnicos para preparar los requisitos técnicos para sus equipos.  Sin embargo, lo que a menudo sucede es que los Scrum Master piensan que todo esto debería hacerse mediante la democracia, y se incluyen a los Scrum Masters, Product Owners, Developers… Esto esta relacionado con lo que comentábamos antes: Dedicamos tiempo a explicar las cosas técnicas a las personas que no necesitan conocer los detalles técnicos, y esto es una pérdida de tiempo que no aporta ningún valor a nadie.  Como líder de un equipo, trataremos de asegurarnos de tener todos los detalles técnicos resueltos antes de que el trabajo llegue al equipo. Asegurarnos de ser nosotros quienes programemos las reuniones y solo incluyamos a las personas que realmente necesitemos que estén. Esto suele dar como resultado una liberación más rápida del producto.   Solucionar los problemas de agile  Hay problemas y estos tienen que tener una solución, ¿verdad? Bueno, esta es una respuesta más complicada de lo que parece. Debemos hablar sobre algunos problemas específicos que hemos detectado y sobre todo de cómo resolver esos problemas o como los hemos resuelto en anteriores ocasiones en caso de ser repetitivos.   Resolviendo las reuniones  Una solución particularmente útil es realizar reuniones de pie asincrónicas. Por ejemplo, Slack tiene muchas herramientas realmente buenas, como puede ser la encuesta automatizada. Uno de los principales beneficios del stand-up es lo último de lo que se habla, los bloqueadores. Si hay bloqueadores, sin duda es beneficioso descubrirlos antes de que avance la jornada. De lo contrario, encontraremos que el stand-up generalmente es una pérdida de tiempo.  Enviamos una encuesta al equipo antes del stand-up para preguntar si deberíamos tener una reunión síncrona o de stand-up. Se acuerda que esta pregunta significa si hay bloqueadores o elementos pendientes que requieran conversación. De lo contrario, publicamos nuestras actualizaciones normales en el canal de slack del equipo y las analizaremos allí.  Este proceso lleva mucho menos tiempo, obtiene el mismo beneficio y no es perjudicial para el flujo de trabajo. Esta es una sugerencia que puede ser increíblemente beneficiosa para un equipo que va en contra del agile estándar.  Ideas finales Al final del día, lo que funciona para cada equipo suele ser diferente. Me encuentro que la forma en que se implementa Agile hoy en día es muy rígida e intenta implementar lo mismo en todas partes, y así nunca funcionará. Animaría a los equipos técnicos a rechazar este paradigma y hacer cosas diferentes que tengan sentido en sus equipos y proyectos, y no seguir al pie de la letra la teoría de un manual.  Y si tienes dudas y te apetece que te asesoremos, no lo dudes. Aquí puedes ver cómo es nuestra forma de trabajar en lo que a consultoría de cambios culturales se refiere. O, si lo prefieres, puedes contactar con nosotros.

Problemas de Agile por los que esta metodología sigue fallando (y sus soluciones) Leer más »

Resumen del “Virtual Breakfast AXIA – Marcos de trabajo ágiles para la gestión efectiva de proyectos IT”

Resumen del “Virtual Breakfast AXIA – Marcos de trabajo ágiles para la gestión efectiva de proyectos IT”

El pasado 3 de junio celebramos una nueva edición de nuestros Virtual Breakfast – AXIA para hablar en esta ocasión sobre los “Marcos de trabajo ágiles para la gestión efectiva de proyectos IT”.  Igor Arrizabalaga (CEO de AXIA) y Mercedes de Miguel, Lead Expert en Agile Project Management fueron los facilitadores de este desayuno en el que participaron muchas empresas tecnológicas.  Tras la vuelta de la Semana Santa, volvimos al ritmo de trabajo, y con ello, una nueva edición de los Virtual Breakfast – AXIA. La sesión se inició analizando la situación actual, y se lanzó la primera de las preguntas: ¿Cuáles son los retos y desafíos ante los que se enfrentan las organizaciones en relación a los modelos de desempeño y feedback? Tras una breve presentación de los participantes, realizamos una breve introducción a la agilidad, definiendo qué puede y qué no puede entenderse por el término ‘Agile’. Como bien dijo Mercedes Miguel:  La agilidad en sí es una cultura, una filosofía… una forma de pensar. En definitiva, es una forma de trabajar diferente en los equipos y las organizaciones. Cuando decimos que queremos convertirnos en una organización ágil lo que realmente estamos diciendo es que vamos a afrontar una transformación cultural, más allá de los marcos de trabajo a utilizar. La agilidad es un paraguas que engloba una serie de metodologías en las que lo más importante es la parte cultural, la que tiene que ver con cómo nos relacionamos, cómo conversamos entre nosotros, cómo nos organizamos, cómo es el liderazgo… Mercedes de Miguel, Lead Expert También vimos cuáles son las características principales de esa cultura que debe poseer una organización para poder ser considerada como ágil: gestión del cambio, aportación de valor para el cliente, entregas iterativas, colaboración…   SCRUM y KANBAN: dos marcos de trabajo ágiles para gestionar nuestros procesos  A continuación, hicimos un recorrido por dos de las metodologías ágiles más conocidas:  Scrum, con su marco de trabajo basado en roles dirigido a proyectos que den pie a trabajar en iteraciones por equipos autogestionados multidisciplinares. “  Kanban, orientado a detectar y eliminar cuellos de botella en nuestros procesos de producción.   A modo de resumen, presentamos las diferencias entre estos dos marcos de trabajo ágiles:  Finalmente, la sesión terminó con un breve debate sobre las posibilidades que estos dos marcos de trabajo podían ofrecer a los participantes en sus organizaciones, y sobre sus experiencias aplicando las metodologías ágiles en su día a día.   Desde AXIA, queremos agradecer su participación a Euskotren, Derten, CIKAUTXO, CDM Consultores (cdm.guru), Smurfit Kappa, CTL-TH Packaging, Tubos Reunidos, S.A., HIJOS DE JUAN DE GARAY, S.A.   En breve presentaremos nuestro nuevo Desayuno Virtual, en el que esperamos continuar compartiendo colaborativamente nuestras experiencias y conocimientos. 

Resumen del “Virtual Breakfast AXIA – Marcos de trabajo ágiles para la gestión efectiva de proyectos IT” Leer más »

Liderazgo ágil: 10 claves de comunicación para lograr un agile leadership

Liderazgo ágil: 10 claves de comunicación para lograr un agile leadership

Es imposible convertirse en un gran líder sin ser un gran comunicador.   ¿Cómo sabemos cuándo nuestras habilidades han madurado los suficiente para convertirnos en excelentes comunicadores y, así, poder alcanzar un liderazgo ágil en nuestra organización ? La respuesta creo que puede estar cuando en nuestras interacciones utilizamos de forma consistente los siguientes diez principios:  «A las personas no les importa cuánto sabemos hasta que saben cuánto nos preocupamos por ellas». La teoría empresarial clásica indica que los líderes deben mantener la distancia. No es así en el liderazgo ágil. Si no desarrollamos relaciones personales significativas, nunca sabremos lo que realmente tienen en mente hasta que es demasiado tarde.  3. Seamos específicos: la especificidad es mejor que la ambigüedad. Aprendamos a comunicarnos con claridad. Lo simple y conciso siempre es mejor que lo complicado y confuso. El tiempo nunca ha sido un bien tan preciado como lo es ahora. Es fundamental que los líderes aprendamos a ir al grano y alcanzar los puntos clave; y, por tanto, es importante esperar lo mismo de los demás.  “Nuestro objetivo es eliminar lo superfluo y hacer que nuestras palabras calen”.  4. Concentrarnos en lo que dejamos atrás, no en lo que tenemos en curso: los mejores comunicadores no solo son hábiles para aprender y recopilar información mientras se comunica, también son expertos en transferir ideas, alinear expectativas, inspirar acciones y difundir su visión. La clave es abordar cada interacción con el corazón. Concentrándonos más en contribuir que en recibir, habremos logrado la meta. Aunque esto pueda parecer contradictorio a la intuición, si nos concentramos más en los deseos y necesidades de la otra parte, aprenderemos mucho más que si solo nos concentramos en lo nuestro.  5. Tener mente abierta: a menudo hemos dicho que la rigidez de una mente cerrada es el factor limitante más importante para las nuevas oportunidades.  Un líder lleva su juego a un nivel completamente nuevo desde el momento en que busca voluntariamente a aquellos que tienen opiniones discordantes y posiciones opuestas.  El objetivo no es el de convencerlos para que cambien de opinión, sino el de comprender lo que piensan. Recordemos que en el liderazgo ágil no es la opinión lo que importa, sino la voluntad de discutirla con la mente abierta y aprender.   Comprender este principio de comunicación es lo que ayuda a convertir la ira en respeto y la duda en confianza.  8. Leamos entre líneas: Los grandes líderes tienen la asombrosa capacidad de comprender lo que no se dice, no se ve ni se escucha. Los líderes astutos saben que se puede ganar mucho más cediendo la palabra que con la verborrea. En esta era de la comunicación instantánea, todos parecen tener tanta prisa por comunicar lo que piensan que no se dan cuenta de todo lo que se puede obtener leyendo las mentes de los demás.  Mantengamos los ojos y los oídos abiertos y la boca cerrada y nos sorprenderemos de cómo se eleva nuestro nivel o conciencia organizacional.  9. Hablemos sabiendo: desarrollemos el dominio técnico sobre los temas. La mayoría de las personas exitosas no tienen interés en escuchar a personas que no pueden añadir valor a una situación o un tema, pero se obligan a entablar una conversación solo para escucharse hablar. Aunque todos hemos escuchado el dicho «lo que importa no es lo que dicen, sino cómo lo dicen», y aunque algo de verdad puede tener esta frase, creo que es mucho más importante lo que se dice que cómo se dice. Los buenos comunicadores abordan los aspectos del «qué» y «cómo» para no convertirse en charlatanes que dejan a las personas con la impresión de enfocarse más de la forma que la sustancia.  10. Hablar a los grupos como individuos: los grandes comunicadores pueden adaptar su mensaje de forma que pueden hablar con 10 personas en una sala o con 10.000 personas en un auditorio y hacer que se sientan como si estuvieran hablando directamente con cada una de ellas.  Saber cómo trabajar en una sala y establecer credibilidad, confianza y simpatía son claves para interacciones exitosas.  En pocas palabras: cada vez que tengamos que comunicar un mensaje asegurémonos de que dicho mensaje sea verdadero y correcto, bien razonado y respaldado por una lógica sólida, específica, consistente, clara y precisa.   Lo más importante de la comunicación no se trata de nosotros sino de las opiniones, las posiciones o las circunstancias de los demás. Se trata de ayudar a los demás satisfaciendo sus necesidades, comprendiendo sus preocupaciones y añadiendo valor a su mundo.  En la siguiente infografía te presentamos unos consejos para conseguir que tu comunicación pase al siguiente nivel: ¿Te interesa el mundo agile y quieres formarte o ampliar tus conocimientos? En nuestro próximo workshop sobre Agile Leadership podrás aprender a reconocer e impulsar el liderazgo ágil.

Liderazgo ágil: 10 claves de comunicación para lograr un agile leadership Leer más »

Resumen del “Virtual Breakfast AXIA -“Claves para implantar un modelo de “feedback” / “Remote Working” efectivo”

Resumen del “Virtual Breakfast AXIA -“Claves para implantar un modelo de “feedback” / “Remote Working” efectivo”

Tras la vuelta de la Semana Santa, volvimos al ritmo de trabajo, y con ello, una nueva edición de los Virtual Breakfast – AXIA. En esta ocasión, el pasado 21 de abril, tuvimos la posibilidad de compartir durante dos horas un espacio en el que reunirnos y compartir experiencias con varios clientes. Bajo el título “Claves para implantar un modelo de “feedback” / “Remote Working” efectivo”,  Igor Arrizabalaga (CEO de AXIA) y Cecilia De Arriba (Trainer y consultora en AXIA) facilitaron este desayuno, aportando la visión y experiencias de nuestra organización. La sesión se inició analizando la situación actual, y se lanzó la primera de las preguntas: ¿Cuáles son los retos y desafíos ante los que se enfrentan las organizaciones en relación a los modelos de desempeño y feedback? … “demostrar a la dirección y managers que el proceso de ED es muy importante y atingente con el negocio”, … “mejorar la comunicación y colaboración entre los empleados/as y los equipos de la organización”, …. “mejorar las habilidades de liderazgo de los managers para propiciar una buena experiencia del empleado respecto del proceso”, …. “ayudar a los colaboradores y líderes a conocerse mejor a sí mismos y sus colegas” …. Tras esta primera fase del desayuno, se analizaron cuáles podrían ser los cambios clave a realizar en los modelos de feedback y desempeño. En este punto, el coaching y apoyo continuo alineado a las metas del negocio, el feedback en el momento oportuno, realizar procesos más continuos, el reconocimiento, el mirar a futuro, fueron algunos de los aspectos que se analizaron. La sesión fue avanzando, y pasamos al siguiente punto de reflexión. ¿Cómo medir los logros en las evaluaciones del desempeño? Por último, se pasó a hablar sobre cómo es el proceso de feedback que se trabaja actualmente en las organizaciones, para pasar, por último, a analizar ejemplos y buenas prácticas. Desde AXIA, queremos agradecer su participación a GRUPO CLECE,FORUM SPORT, AUTORIDAD PORTUARIA DE BILBAO, CEPSA, y esperamos continuar periódicamente con este tipo de iniciativas, que desde nuestro punto de vista sirven para hacer un alto en el camino, compartir experiencias y aprender. ¡Seguimos! – Always with you

Resumen del “Virtual Breakfast AXIA -“Claves para implantar un modelo de “feedback” / “Remote Working” efectivo” Leer más »

Resumen del “Virtual Breakfast AXIA – Como reorganizar el área IT para trabajar Agile con éxito”

Resumen del “Virtual Breakfast AXIA – Como reorganizar el área IT para trabajar Agile con éxito”

En AXIA continuamos con nuestra actividad, y uno de los aspectos que llevamos trabajando un tiempo es la celebración de los desayunos de trabajo. Bajo el título “Como reorganizar el área IT para trabajar Agile con éxito”, y en un formato virtual, el pasado 24 de marzo tuvimos el placer de reunirnos y compartir experiencias con varios clientes En esta ocasión, la sesión fue facilitada por nuestro CEO Igor Arrizabalaga y por nuestra Trainer y consultora Mercedes Miguel, y durante dos horas tuvimos la oportunidad de conocer la realidad actual de las organizaciones, los principales retos, las características de las organizaciones exitosas y cómo reorganizarlas, … La sesión se inició hablando de la situación en la que actualmente se encuentran las organizaciones, hablado sobre los puntos fuertes y débiles de las mismas, reflexionando sobre las problemáticas y dificultades ante las que nos encontramos. Se continuó hablando sobre los principales retos ante los que se encuentran los equipos IT de las organizaciones, y se analizaron las principales características de las Organizaciones IT Exitosas, las Organizaciones IT Ágiles, las dificultades ante las que podemos encontrarnos a la hora de crear equipos autónomos y multidisciplinares, y cómo reorganizar los equipos IT para hacer frente a estos retos. Para finalizar estas dos horas intensas en contenidos y aportaciones por parte de las personas asistentes, se habló de aspectos como la asignación de objetivos, los conceptos de liderazgo y la delegación. Desde AXIA, queremos agradecer su participación a SEMICROL, ULMA CONSTRUCTION, ALCORTA FORGING GROUP y LIEBHERR GROUP, y esperamos continuar periódicamente con este tipo de iniciativas, que desde nuestro punto de vista sirven para hacer un alto en el camino, compartir experiencias y aprender. ¡Seguimos! – Always with you

Resumen del “Virtual Breakfast AXIA – Como reorganizar el área IT para trabajar Agile con éxito” Leer más »

¿Demasiado Tiempo “perdido” en reuniones de Scrum?

¿Demasiado Tiempo “perdido” en reuniones de Scrum?

¡Pasamos tanto tiempo en reuniones que no consigo escribir código! ¿Demasiadas reuniones? ¿Cuánto tiempo debería dedicar oficialmente un desarrollador a las reuniones? La Guía de Scrum es bastante explícita sobre los eventos de Scrum, pero es posible que los totales no sean evidentes de inmediato. Partiremos del supuesto de que trabajamos 8 horas al día, 5 días a la semana: En definitiva. Tiempo dedicado a los eventos de Scrum Evento Horas/Sprint de 4 semanas horas al día % Horas Totales por semana Daily Scrum   0:15   2:15 Sprint Planning 8:00     2:00 Sprint Review 4:00     1:00 Sprint Retrospective 3:00     4:00 Refinamiento Backlog     10%         Total tiempo dedicado 10:00 En total, en una semana la dedicación estimada es de 10 horas a los eventos de Scrum. Esto es el 25% del tiempo disponible. Suena como mucho, ¿verdad? Quizás hay algunas cosas a tener en cuenta. El refinamiento de Backlog no es una reunión El refinamiento del Backlog no es en realidad un evento en el sentido estricto de la palabra. Es una variedad de actividades que realiza a lo largo del Sprint con un propósito: comprender el trabajo que tenemos por delante. El refinamiento del Backlog no tiene por qué ser una reunión de 4 horas con todo el equipo cada semana. Una sesión de mapeo de ejemplo puede contar como refinamiento de la Pila tanto como una charla informal con el Product Owner durante el café de la mañana sobre alguna idea que tengan para una nueva función. Dediquemos el tiempo que se necesite hasta este máximo Los tiempos mencionados anteriormente son los que la Guía Scrum considera la cantidad máxima de tiempo. No vayamos más allá de esto. De hecho, puede haber razones para dedicar menos tiempo: Nuestro equipo es pequeño. La alineación y el acuerdo nos llevan poco tiempo. Nuestro trabajo es más una cuestión de volumen que de complejidad y requiere poco esfuerzo para comprenderlo completamente. Nuestro equipo está familiarizado con el tipo de trabajo que realizamos. La experiencia en la materia es un bien común. Nuestro equipo está familiarizado entre sí y puede discutir problemas rápidamente y alinearse en soluciones. Nuestro equipo ha demostrado ser capaz de completar los detalles durante la implementación. Tengamos fe en nuestra capacidad para resolver las cosas a medida que avanzamos. También debemos tener en cuenta: el refinamiento del backlog no es el momento para un análisis técnico profundo. Si sabemos lo suficiente sobre el qué y el por qué, continuemos; la Planificación del Sprint y el Sprint en sí serán cuando entremos en el Cómo. Nuestro equipo se comunica continuamente. No es necesario tener una reunión explícita para comunicarnos. Nuestro equipo llega a las reuniones bien preparado. No puedo enfatizar esto lo suficiente: nada mata más la motivación que asistir a las reuniones sin estar preparados o sorprenderse mutuamente con elementos que podrían haberse abordado o anunciado antes. Si nuestra reunión tiene una agenda y la hemos trabajado: no lo tratemos. No es necesario que se traten temas solo porque se le asignó un tiempo en la agenda. Trabajando a tiempo parcial Si trabajamos a tiempo parcial, las 10 horas antes mencionadas significarán un porcentaje relativamente mayor de nuestro tiempo. Daily Scrum, Sprint Planning, Sprint Review y Sprint Retrospective son eventos que llevan la misma cantidad de tiempo ya sea que trabajemos 24, 32, 36 o 40 horas a la semana. En cuanto al refinamiento del Backlog: generalmente no consume más del 10% de la capacidad del Equipo de Desarrollo. Y como se hemos comentado, no tiene por qué ser una reunión de un gran equipo. Evitemos las interrupciones Profundizar en un problema, pensar en cómo resolverlo y luego implementarlo son actividades que generalmente se benefician de una atención ininterrumpida. Esto sugiere que debemos planificar las reuniones de tal manera que esto sea posible. Otra forma de interrupción es la reunión ad hoc. Tomar un descanso para dejar que nuestra mente funcione es una gran idea. No es lo mismo que tener que dejar el trabajo en cualquier momento. Si nuestro equipo tiene que lidiar con tales interrupciones, veamos si podemos nombrar a alguien diaria o semanalmente para que sea el primero en ser interrumpido para que otros miembros del equipo puedan concentrarse. Hora del día Averigüemos a qué hora del día funcionamos mejor para que todos tengamos una reunión. La hora exacta del día es diferente de una persona a otra. Llevemos un registro de cuándo es más productivo al implementar soluciones y planifiquemos reuniones en torno a eso. La estructura es importante, pero es posible que deseemos cambiar esta de vez en cuando. Probablemente no necesitemos esa otra reunión Antes de aceptar cualquier otro tipo de reunión que no sea un Evento Scrum, especialmente las recurrentes para todo nuestro equipo, preguntémonos si todavía no hay un Evento Scrum para ello. La Dirección quiere saber lo que está haciendo. Recordemos la transparencia, apertura e inspección de los Valores Scrum. Deberíamos querer compartir lo que sea que se esté haciendo. Disponer de elementos de comunicación de la información y estar dispuesto a explicarlo a quienes muestren interés. No necesitamos una reunión de equipo específica para esto. Dicho eso: Una necesidad de saber no es lo mismo que un problema de confianza. Los problemas de confianza y miedo entre el equipo y la dirección pueden obstaculizar el progreso y lo harán. Deben ser abordados y resueltos por el Equipo Scrum. El Scrum Master puede ayudar a identificar estos problemas. Nuestro equipo no debe temer que la dirección malinterprete o abuse de lo que nosotros hacemos transparente. Viceversa, no debería ser una tensión para el equipo producir información que satisfaga la curiosidad de la dirección. Debe ser información que se pueda crear fácilmente y que les resulte útil. ¿Los “stakeholders” quieren saber sobre la velocidad, los puntos de historia…? Como desarrolladores, no debemos sentirnos tentados a dedicar horas, puntos de historia u otras medidas de velocidad o de costes que

¿Demasiado Tiempo “perdido” en reuniones de Scrum? Leer más »

Guía Scrum 2020: Scrum es cosa de todos/as

Guía Scrum 2020: Scrum es cosa de todos/as

La Guía Scrum 2020 La Guía Scrum 2020 ya está disponible y se cambia para hacer que Scrum sea más accesible e inclusivo aparte de su uso casi exclusivo en el desarrollo de software. Podemos descargarnos de forma gratuita la nueva Scrum Guide 2020 y la Guia Scrum 2020 (ES) Principales cambios de la Scrum Guide 2020 En primer lugar, la nueva Guía es menos prescriptiva, eliminando muchas sugerencias como las preguntas estipuladas del Daily Scrum, al menos un elemento de acción obligatorio de la Retrospectiva que se convierte en parte del Sprint Backlog o el consejo sobre por qué las cancelaciones de Sprint son eventos raros. El Sprint Review pierde su receta detallada sobre cómo llevar a cabo el evento. Además, lo obvio ya no debe de comentarse: Scrum de hecho no es trivial de dominar. Curiosamente, los autores también eliminan otros elementos de la edición de la Guía Scrum 2017, por ejemplo, la magnitud del trabajo asignado al refinamiento del Product Backlog y al liderazgo de servicio. Aquí presentamos los diez cambios en la Guía Scrum 2020, sin ningún orden en particular, que se pueden considerar los más importantes: No más roles:  El equipo Scrum consta de un Scrum Master, un Product Owner y Desarrolladores. Dentro de un equipo Scrum, no hay sub-equipos ni jerarquías. Es una unidad cohesionada de profesionales centrados en un objetivo común, el objetivo del producto. (No hay más roles. Sin embargo, ahora hay responsabilidades). No hay más “Equipo de Desarrollo”: Los desarrolladores son las personas del Equipo Scrum que están comprometidas a crear cualquier aspecto de un Incremento de valor a utilizar en cada Sprint. El enfoque en el equipo Scrum: El equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración de las partes interesadas, la verificación, el mantenimiento, la operación, la experimentación, la investigación y el desarrollo, y cualquier otra cosa que pueda ser necesaria. Esta idea de equipo fortalecido también se refleja en el punto que el Equipo Scrum es ahora autogestionado y no autoorganizado. El liderazgo de servicio ya no se menciona: Los Scrum Masters son verdaderos líderes que sirven al Equipo Scrum y a la organización en general. Este cambio probablemente posicione el rol de Scrum Master más cerca de los Project Managers y Delivery Managers El objetivo del producto: El objetivo del producto describe un estado futuro del producto que puede servir como un objetivo para que el equipo Scrum planifique. […] El objetivo del producto es el objetivo a largo plazo del equipo Scrum. El concepto de “producto”: Un producto es un medio para ofrecer valor. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto. Las revisiones de Sprint no son escapatorias: La revisión de Sprint nunca debe considerarse una escapatoria para liberar valor. Las liberaciones incrementales ya no son una prerrogativa del Product Owner: Si un elemento del Product Backlog no cumple con la Definición de Terminado, no se puede publicar ni presentar en la Revisión de Sprint. Compromisos: Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la transparencia y el enfoque frente al cual se pueda medir el progreso. (Ahora hay un lugar para el Sprint Goal, la Definición de Terminado, y el Product Goal mencionado anteriormente, ya que todos están vinculados a uno de los tres artefactos Scrum como compromisos). “Terminado” ahora crea un Incremento de Producto (potencialmente liberable): La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto. En el momento en que un elemento de la Pila de Producto cumple con la Definición de Terminado, nace un Incremento. (Otra aclaración bienvenida: cuando el trabajo del Sprint Backlog cumple con el estándar de calidad del Scrum Team, constituye un Incremento liberable). Como se menciona, existen numerosos ajustes adicionales aquí y allá. Para mencionar algunos: los elementos del Product Backlog ya no se estiman, sino que se dimensionan, el Scrum Master ya no está eliminando impedimentos, pero ahora está causando la eliminación de impedimentos. Además, la pregunta ¿Por qué es valioso este Sprint? La pregunta se ha convertido en parte de la planificación del Sprint. Conclusión La Guía Scrum 2020 incluye cambios significativos en el marco para ampliar su atractivo a las aplicaciones más allá del desarrollo de software.

Guía Scrum 2020: Scrum es cosa de todos/as Leer más »