Hace pocos días asistí a un fantástico meetup en el que los amigos de Agile Spain nos presentaron el framework de escalado Fast-Agile.
El evento se organizó en el espacio de co-working “Se aceptan ideas”, un sitio que no conocía y que me resultó de lo mas atractivo. Muchas, muchísimas gracias por su colaboración y atención.
A través de este artículo os quiero contar cómo fue el evento y mis percepciones sobre el framework tras la experiencia.
Hoy quiero presentaros un juego en el que se pone en evidencia la complejidad en los retos que resolvemos y la variabilidad en las estimaciones en los esfuerzos de esos mismos retos. Lo ideé jugando con un Tangram, os va a encantar y estoy seguro que lo vais a usar en muchas ocasiones en las que tengáis que lidiar con el cambio cultural en el las organizaciones y equipos.
Os quiero contar una dinámica que creé y utilicé para un curso sobre el Framework Scrum que impartí a un grupo de personas de distintos proyectos y servicios de tecnologías de la información. Creo que igual se puede utilizar en cualquier actividad en la que se practiquen o enseñen conceptos nuevos y disruptivos.
Kanji de la palabra ninja.
Mi idea era introducir una dinámica/juego nada más comenzar el curso, justo después de presentarme, para romper el hielo con los asistentes, conocernos, saber el rol de cada uno en sus proyectos y que todos estuviesen relajados y receptivos. Además evaluaba la idea de dedicar unos minutos a tratar de predisponerles para que mantuviesen su mente abierta a los conceptos asociados a las Metodologías Ágiles.
El Informe del Caos analizó en 2.015 50.000 proyectos de TI en distintas partes del mundo y como todos los años presentó sus cifras de éxito y fracaso en los mismos. De muchos son ya conocidas las cifras que os presento, no obstante, aporto una serie de datos y gráficos extraídos de la web de Julián Gómez (www.laboratorioti.com) y de InfoQ para aquellos que aún no habéis tenido la oportunidad de conocerlos.
En la entrada anterior te avancé los puntos calientes de la metodología Lego Serious Play, hoy empezamos con la práctica. Sintiéndolo mucho, no vas a tocar las fichas, el canal digital no me permite reproducir la experiencia analógica en la mesa de tu ordenador… Pero tranquilo, vas a poder disfrutar, en primera persona, de mi participación en la sesión preparatoria que tuvo lugar un par de días antes del Taller de Habilidades Directivas LEGO.
¿Has oído hablar de Lego?, ¿has jugado alguna vez con sus fichas?, ¿has realizado construcciones?, ¿has sabido crear metáforas con ellas?, ¿qué eran las fichas planas?, ¿un barco, un coche, una casa, un avión?, ¿has oído hablar de la Metodología LSP (Lego Serious Play) ‘Juego Serio‘?. Quédate por aquí, te lo voy a presentar.
Una y otra vez se repite la misma historia en las empresas, el foco se pierde, apunta a direcciones inadecuadas, se priorizan cuestiones técnicas por encima de cuestiones de negocio… es la pescadilla que se muerde la cola.
Pueden ser varios los motivos por los que una historia no ha sido finalizada. El Equipo Scrum debe enfocarse en identificar las causas y proponer soluciones, nunca culpables.
¿Se debe preocupar el Equipo de Desarrollo por no haber finalizado su compromiso?. ¿Se debe encolerizar el Product Owner por no tener el nuevo incremento pactado?. ¿Cómo debe actuar el Scrum Master?. ¿Qué está haciendo mal?
Tendemos a creer (gracias a la industria cinematográfica y de la imagen) que una persona exitosa es alguien que ha alcanzado un gran objetivo, de difícil consecución, que ha tenido que luchar y trabajar duramente, que gana mucho dinero, que es bien valorado en su entorno social y que además es feliz; y eso es un gran error.
Parece que no hay mucho tema de conversación y debate sobre la forma de la Tierra. En términos evolutivos, …
Espero que os guste el formato y os sirva de plataforma para vuestra propia divulgación de los mismos.
Es habitual que todo el mundo se muestre interesadísimo en las metodologías ágiles, ya que, según han oído, mejoran los resultados del desarrollo y por ende del producto.
Hola a todos , tal como prometí en la entrada de introducción a la serie de artículos, os traigo la primera de las leyes de éxito que Og Mandino propone en su libro ‘El vendedor más grande del mundo’, que me he permitido orientar a los roles intervinientes en Scrum.
¿Quieres ser el mejor en todas las áreas? ¿alcanzar el éxito en todos los propósitos? ¿ver cómo se abren las puertas a tu paso? , ¿dejar tu marca personal para que te recuerden con agrado?…
Hola a todos:
Aprovecho mientras monto el Árbol de Navidad para presentaros la nueva historia del blog, una historia con mucho sentido común…
Como final de la serie dedicada a los multiroles, quiero hablaros de la’ Tríada de responsabilidades Scrum’. De forma gráfica trataré de explicar, desde el punto de vista de las responsabilidades del trabajo, los problemas a los que se enfrenta una persona cuando quiere asumir más de un rol, y concretamente me centraré, de nuevo, en el binomio conflictivo… ScrumMaster + Product Owner.
Continuando la serie de entradas dedicada a los multiroles en Scrum, quiero hacer unas reflexiones sobre la conveniencia, o no, de que el ScrumMaster y el Product Owner sean representados por la misma persona.
Ya sé que no hay mucho más que aportar sobre los tableros de Sprint en Scrum, si sabes buscar en google encontrarás montones de versiones.
Como continuación y extensión al StoriePost anterior quiero analizar la posibilidad de que el ScrumMaster forme parte del equipo de desarrollo.
Seguir leyendo
Varias veces desde que trabajo con Scrum, me han preguntado acerca de la posibilidad de que una persona juegue varios roles. Inicio este Story Post como una serie en la que hablaré sobre el tema.
Hoy quisiera hacer unas reflexiones sobre los roles Scrum. Sobre las eternas dudas de los novatos como yo. ¿Quién debe ser Product Owner? ¿Quién Scrum Master?.
Os invito a conocer, en 19 imágenes, qué son y como usar Historias de Usuario como método crucial para la gestión de entidades de valor para vuestros productos de desarrollo de software.
