El Cono de Incertidumbre para Organizaciones, Managers, Product Owners y DevTeams.

Una de las herramientas sobre las que siempre me he apoyado para facilitar el entendimiento de los conceptos más abstractos de la agilidad es el Cono de Incertidumbre, hoy os quiero contar cómo usarlo y aplicar sus conceptos en distintos ámbitos de los proyectos. Hace dos semanas escasas la Product Owner de un equipo me pidió que le contase, al conjunto del equipo, los conceptos y cómo se aplican. Decidimos hacerlo previo a una Retrospectiva del equipo y, por supuesto, el Cono de Incertidumbre se convirtió en referencia constante durante la misma.

Sincronizar personas: “Individuos e interacciones sobre procesos y herramientas”

Las organizaciones son sistemas complejos adaptativos con los que se puede interactuar pero de difícil gobierno dada su naturaleza de entorno complejo. En este contexto acostumbro a explicaros que un grupo completo de personas de un equipo no manejáis toda la información necesaria, ya que la misma aun no ha emergido (está oculta nadie la conoce aún) se ha perdido/olvidado, ha cambiado (de la mano de las propias decisiones y acciones que tomáis o toman otros) o simplemente está por llegar promovida por el propio entorno que os rodea y sobre el que no tenéis control (nuevos sistemas, modelos, procesos, productos, legislaciones, necesidades, restricciones etc).

Dream Job: buscando el compromiso y el objetivo de los equipos y las personas.

Lo peor que nos puede pasar como equipo es que no consigamos serlo. Trabajar de forma independiente e inconexa, no disfrutar de la cercanía de los compañeros, de los éxitos comunes, no felicitar las buenas acciones, no sentirnos parte, y tantas y tantas otras cosas que deberíamos hacer como ente para poder funcionar como tal.

Una de las cosas que me preocupa de los equipos nuevos es que tengan una visión conjunta, un referente que seguir, un propósito, un espejo en el que mirarse, implicarse y empatizar.

En su práctica Work Expo, Management 3.0 dice algo así como…

Juego Serio en retrospectiva para resolver tensiones

Hace un par de semanas participé en un Taller de Retrospectivas de dos días de duración que organizó ThinkingWithYou y que impartieron Israel Alcázar y Thomas Wallet (un abrazo chicos).

El taller me aportó mucho en varios sentidos, por supuesto por los contenidos trabajados y las formas de los organizadores, y desde luego por el nivel del resto de participantes, experimentados y con la mente muy abierta. Me ha permitido conocer prácticas organizativas que me hubiera costado más tiempo descubrir a base de ensayo/error y me ha proporcionado enfoques que desconocía para llegar a las personas, no sólo en las retrospectivas, también aplicable a otros momentos.

Fast-Agile con @AgileSpain

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.

‘SizeGram Complexity Game’ para entender la complejidad en los desafíos.

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.

Dinámica para introducción a Scrum: ‘Presentación Ninja’

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 “Chaos Report ’15” recomienda SCRUM.

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.

Sesión preparatoria del Taller Lego Serious Play. LSP II

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.

Presentación del Taller Lego Serious Play. LSP I

 ¿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.

Cuando el foco no es el usuario o el producto.

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.

Retrospectiva de un compromiso no finalizado.

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.

¿Cuál es el impacto de no finalizar un Sprint?

¿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?

Claves para alcanzar el éxito en tus proyectos.

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.

Un par de días de evolución

Parece que no hay mucho tema de conversación y debate sobre la forma de la Tierra. En términos evolutivos, …

El Manifiesto Ágil: 24 mini principios

Espero que os guste el formato y os sirva de plataforma para vuestra propia divulgación de los mismos.

Agilidad… eso es una moda que no va conmigo…

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.

Desarrollo Orientado a Test de Aceptación (ATDD) I

Delimitar, Asignar y Coordinar

El agilista más grande del mundo I: “Una nueva vida, buenos hábitos”.

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.

El agilista más grande del mundo

¿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?…

Ante todo, sentido común.

Hola a todos:

Aprovecho mientras monto el Árbol de Navidad para presentaros la nueva historia del blog, una historia con mucho sentido común…

Triada de Responsabilidades Scrum

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.

¿Puede una persona ejecutar el rol de Propietario y Scrum Master?

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.

El Sprint Taskboard en cinco minutos.

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.

¿El ScrumMaster puede formar parte del Equipo de desarrollo?

Como continuación y extensión al StoriePost anterior quiero analizar la posibilidad de que el ScrumMaster forme parte del equipo de desarrollo.

¿El Product Owner puede formar parte del equipo de desarrollo?

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.

¿Quién es quién en los Roles de Scrum?

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?.

Historias de Usuario.

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.