Archive for Artículos

Ejercicio de simulación: “El juego del nombre en multitarea”

¿Traducimos “The Multitasking Name Game”?

Así lanzó la iniciativa Ángel Águeda Barrero al foro de colaboradores de Scrum Manager. No faltaron voluntarios para sumarse a un “Scrum” distribuido y en pocos días estábamos ya “quemando” horas sin prisa pero sin pausa en la tarea de traducción de este material compartido generosamente por Henrik Kniberg con la comunidad de entusiastas de la agilidad.

La simulación que nos propone a través de este juego permite ilustrar en forma divertida y vivencial los efectos adversos del trabajo en modalidad “multitarea”.  El artículo se orienta a formadores y facilitadores en agilidad aunque permite a cualquiera que lo lea adquirir una comprensión clara del problema y sus consecuencias.

“¿Cuánto se tarda en escribir un nombre?” es la provocación a través de la cual Henrik nos lanza a una entretenida demostración de lo costoso que resulta perder el “foco”, decir siempre que “sí”, no limitar nuestra cantidad de “tareas en progreso” (WIP) y nos revela el secreto detrás de la aparente contradicción:

Vamos a comenzar con su proyecto más tarde para poder terminarlo antes”.

 

Multitasking game

 

Tal vez el punto más interesante de este ejercicio sea dar visibilidad a un problema que la mayoría de las veces se confunde con una virtud. Pero como nos recuerda el autor “el primer paso y el más importante es conseguir que las personas estén de acuerdo en que hay un problema”. Esta es sin duda una práctica y amena herramienta para aprehender el concepto en profundidad.

Como rezan las notas a la traducción en español: va nuestro mayor agradecimiento a Henrik Kniberg por su contribución a la comunidad ágil y nuestro humilde aporte desde Scrum Manager a la comunidad ágil hispana a través de esta traducción.

Muchas gracias a todos los que participáis en los cursos de OK’s

GraciasAprovechando el cierre del último curso de OK’s, estamos haciendo retrospectiva para incluir de cara al año que viene las sugerencias que nos aportáis y actualizando las páginas de testimonio que nos dejáis (atentos a la nueva plataforma que estrenaremos en breve ;-)

Y la conclusión a la que llegamos es que lo mejor de los cursos de OK’s sois vosotros, con vuestro reconocimiento y agradecimiento que es la mejor motivación para seguir trabajando y aportando toda ayuda que podamos.

“Me ha parecido muy positiva la labor de la profesora del curso, favoreciendo siempre… Considero un esfuerzo y un aporte importante de scrum manager para los que propugnamos el pensamiento agile. Voy a difundirlo… El curso ha sido muy interesante e instructivo. Lo recomendaré a todo el mundo que crea que le puede interesar…. Scrum Manager te aporta una amplitud de miras que no obtienes en otros cursos sobre project management. Al tiempo que uno afianza conceptos de gestión ágil, obtiene… Me ha encantado el curso y la plataforma, sin duda seguiré… Excelente material y muy interesante experiencia… El profesor muy pendiente y con nivel suficiente para aclarar todas las dudas planteadas. Como todos los cursos que he hecho de scrum manager muy muy recomendable … Realmente me parece un curso muy completo y didáctico. Ademas esta actualizado y tiene un grupo de docentes muy capaces… Excelente material y muy interesante experiencia. Muchas gracias por vuestro excelente trabajo…”

Desde aquí queremos agradeceros todas y cada una de las declaraciones de reconocimiento que nos tranmitís (en el curso de métricas, de kanban, de introducción y de scrum) y que nos dejan emocionados.

Muchas gracias a todos vosotros por vuestro reconocimiento.

Los profesores de OK’s:
Gregorio Mena, Marta Ariza, Juan Palacio y Raúl Herranz

Predictibilidad vs. Agilidad vs. Flexibilidad

Presentación de Raúl Herranz en el pasado Tenerife Lan Party en la que trató de las características de la gestión predictiva, la agilidad y la flexibilidad al aprovechar lo mejor de ambos enfoques.

vi@ Utópica Informática.

Scrum como patrón pedagógico para el aprendizaje basado en proyectos

No es fácil trabajar en un marco de Scrum con un equipo distribuido y es precisamente el tema que analiza Sergio Yazyi en su trabajo de Fin de Master en las TIC en Educación de la Universidad de Salamanca ”Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido “.

El trabajo emplea para su análisis el taller que realizamos en  Open Knowledge Scrum  en el que participó el año pasado, y que fué dirigido por Claudia Ruata.

El documento compone una visión general y análisis, objetivo y riguroso tanto del aprendizaje basado en proyectos como de los retos del trabajo con equipos distribuidos.

El aprendizaje basado en proyectos se presenta en varias disciplinas como una estrategia pedagógica óptima para ejercitar conocimientos a la vez que desarrollar habilidades, afrontando situaciones similares a las del mundo real no sólo en términos individuales sino también en la acción coordinada, al mismo tiempo que ofrece un escenario para facilitar la incorporacióntransparente de la tecnología dentro del proceso de trabajo, por sus virtudes para alcanzar el logro de los objetivos.

En contextos
donde los requisitos son estables, esto ha funcionado bien. Sin embargo, con la aceleración en el ritmo de evolución tecnológica de las últimas décadas, la aplicación de este enfoque en escenarios donde los cambios frecuentes no sólo son inevitables sino incluso deseables, y donde la capacidad de predecir el resultado y el momento es menos importante que
garantizar la producción de valor genuino en el proceso, el modelo tradicional en cascada, predictivo, se ha revelado insuficiente. En particular, en la industria del software se ha vuelto evidente que cuando las definiciones de los requisitos son más dinámicas, inciertas o inestables, este modo de desarrollar produce sistemáticamente  retrasos, altos costos para los proyectos e insatisfacción en el cliente

Entre las conclusiones del trabajo una particularmente interesante, que apunta una nueva dimensión de Scrum: en la formación.

Se podría incluso considerar Scrum dentro del aprendizaje basado en proyectos como un verdadero patrón pedagógico, que sintetiza en un conjunto de reglas simples, los principios y buenas prácticas para permitir a un grupo de trabajo transformarse en un verdadero equipo de alto rendimiento, en contextos de incertidumbre e interdisciplinariedad.

… continúa en: “Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido”

 

Estimación basada en tallas para el cálculo del esfuerzo de las Historias de Usuario

A raíz del post Estimación basada en tallas que publiqué ayer (06/07/2011) en el blog Utópica Informática, me he decidido a escribir y compartir con la comunidad el artículo Estimación basada en tallas para el cálculo del esfuerzo de las Historias de Usuario.

En este artículo se contextualiza y explica en detalle esta técnica, poniendo al desnudo un procedimiento que facilitará el trabajo a los equipos que quieran estimar las Historias de Usuario de sus proyectos aplicando esta técnica.

Safe Creative #1107079626649

Casos de utilización de Ruck (Scrum abierto)

Scrum se viene utilizando con éxito en muchos proyectos de desarrollo de software y hay muchos case studies y buenas prácticas de utilización de Scrum. Sin embargo apenas hay información sobre Ruck (Scrum en entornos abiertos), la diferencia entre Scrum y Ruck radica en que Scrum se aplica en un entorno cerrado (melé cerrada) mientras que Ruck hace referencia a entornos abiertos (melé abierta).

Sobre Ruck he encontrado que en Microsoft lo están aplicando, de hecho tienen esta guía sobre como lo aplican:

Pincha aquí para ver la imágen original

Los desafíos a los que se han enfrentado para implementar Ruck han sido:

  • Equipos virtuales y distribuidos
  • Miembros de equipo a tiempo parcial
  • Diferentes usos horarios

Para hacer frente a esos desafíos han desarrollado la guía de Ruck sobre  4 pilares:

  • Transparencia
  • Inspección
  • Adaptación
  • Colaboración

los mismos que con Scrum, pero aplicados a un entorno distribuido y virtual. Podéis acceder al artículo original aquí

Creo que cada vez más iremos viendo como Scrum se va a ir abriendo para poder gestionar proyectos en entornos abiertos, implicando a equipos en diferentes localizaciones, equipos de diferentes empresas de diferentes culturas, etc… ¿Tienes alguna experiencia en Ruck?, ¿utilizas Scrum en entornos abiertos?

Gestión de cambios en Scrum

El otro día me preguntaron en el evento E-TIC de Sevilla vía twitter (@emartos) por cómo podemos realizar una gestión de cambios desde Scrum. He creido que igual podíamos compartir la forma en que vemos la gestión de cambios desde la agilidad. Tomamos como partida mi contestación a @emartos :)

QUÉ ES UN CAMBIO?

Digamos que una modificación en el alcance de una o varias piezas de un proyecto.

Entendamos por pieza del proyecto tanto las historias de usuario como las tareas que las conforman. Los cambios pueden afectar a lógica del proyecto, funcionalidad, tecnología empleada, entorno del proyecto, etc…

No debemos considerar cambios a las incidencias, bugs, etc.. que nos aparecen a lo largo de todo proyecto. Aunque a la hora de tratarlos podamos seguir en parte la forma en la que los tratamos.

TIPOS DE CAMBIOS

Me voy a basar en los tipos de cambios que dice ITIL sin tener en cuenta los cambios estándar o pre-autorizados. Nos quedaremos pues, con dos tipos, cambios Normales y de Emergencia.

De forma resumida:

  • Los cambios Normales, son aquellos que tienen que ser revisados por el conjunto equipo-Scrum Manager (ScrumMaster)-Product Owner. Pueden llegar en cualquier momento pero no implican acción inmediata.
  • Los cambios Emergencia, son aquellos tan inesperados como los Normales pero que nos implican acción en el mismo momento en el que llegan.

Además en ITIL hay un responsable de autorizar los cambios. Es el Gestor del proceso. En nuestro mundo ágil ese responsable será el Product Owner.

IMPACTO DE LOS CAMBIOS

Otro aspecto que tenemos que valorar es el impacto del cambio en nuestro proyecto/Sprint.

  • Sin Impacto destacable. El cambio no afecta de forma sustancial al objetivo del proyecto o Sprint
  • Impacto sustancial. El cambio afecta de forma sustancial o al proyecto o al Sprint.

……

Bueno tenemos las piezas, arranquemos la gestión de cambios.

CAMBIOS NORMALES

Los cambios Normales, llegan en cualquier momento y se han de ‘encolar’ hasta la próxima reunión de preparación de Sprint donde habrá que tratarlos y ver si se aceptan y entran a formar parte o modifican de alguna forma el Product Backlog.

Recordemos que el propietario del Product Backlog es el Product Owner y el será, como hemos dicho, el responsable de autorizar la modificación, eso sí, asesorado por el Equipo

Creo muy recomendable dejar claro al inicio del proyecto, entre Product Owner y el Equipo la forma en la que se van a tratar los cambios y evitar que esos cambios Normales nos interrumpan el Sprint. Lo digo porque seguro que si has estado en cualquier proyecto te han llegado esos cambios ‘Normales‘ que hacen que des la vuelta al proyecto cada semana :)

 

CAMBIOS DE EMERGENCIA

Ahora los difíciles, los de ‘Emergencia’, alguno pensará que el 90% de los cambios que le llegan son de ‘Emergencia’ :) Si es tu caso, mal vamos :) .

Los cambios de Emergencia, como los Normales, llegan en cualquier momento, pero estos implican que tenemos que actuar.

Debe estar prefijado entre Product Owner y Equipo, QUÉ SON cambios de Emergencia o al menos QUÉ NO SON cambios de Emergencia, que permita determinar si algo realmente es susceptible de ser tratado en cuanto llegue o puede esperar a la finalización del Sprint.

Hay dos tipos de Cambios de Emergencia según su impacto, los de bajo/sin impacto y los de Impacto sustancial.

CAMBIOS DE EMERGENCIA SIN IMPACTO SUSTANCIAL

Para los primeros (bajo o nulo impacto) debemos tener un procedimiento preparado para asumir la llegada de ellos sin que nos distorsione mucho el flujo del Sprint:

  • Si usas Kanban quizás dejar un camino para estos cambios y preparar el WIP limit de la columna ready para asumir ese extra. Esto te permitirá asumir las tareas derivadas del cambio.
  • Otra cosa es calcular la velocidad de tu equipo en función del % de esfuerzo que te vayan a requerir estas acciones extraordinarias. En lugar de 40 Puntos por semana, igual solo puedes tener 30 puntos y sabes que 10 los vas a dedicar a estos cambios… Analiza tu historia en el proyecto o en tu entorno. Esto es semejante a como podemos tratar incidencias, bugs, etc…

Cada conjunto product owner + equipo usará el proceso que mejor encaje.

 

CAMBIOS DE EMERGENCIA CON IMPACTO SUSTANCIAL

El problema son los cambios Urgentes con Impacto sustancial.Creo que este tipo de cambios deben tratarse y resolverse en la reunión de planificación del Sprint. Así que cuando llega un cambio así hay que:

  • Preguntar si el cambio puede esperar ya que no afecta al Sprint.
  • Si la respuesta es SI. Terminar el Sprint y en la reunión de planificación del siguiente Sprint tratarlo y construir el siguiente Sprint.
  • Si la respuesta es NO (por su alto impacto en el proyecto o porque si que afecta al Sprint). La acción es fácil. Interrumpir el Sprint y volver a la planificación. La decisión de la interrupción del Sprint la ha de tomar el Product Owner. Debidamente informado por el equipo y valorando el impacto que trae dicha interrupción.

Una última cosa. Los cambios mejor al principio de los Sprints :)

Y tu? Gestionas los cambios? Cómo?

Scrum Manager contra el mundo

En España llevamos un gran retraso respecto a otros países europeos en algunas cosas. Es verdad, sí, les ganamos en tomarnos nuestras cañitas, en echarnos la siestecita y en algunas otras cosas que llamamos calidad de vida (aunque no será para tanto cuando salimos tan tarde de los trabajos) y mantenemos esa culturilla que enaltece al triunfador, al que ha sabido engañar al sistema, al que se lo ha montado bien y ha dado el pelotazo, en definitiva, al que vive como un marqués, sin apenas dar el clavo. Esta misma culturilla es la que nos impide dar pasos con mayor firmeza para salir de la crisis, la misma que nos sume en ese dejar hacer las cosas tal y como están, porque así ya funcionan.¡Nosotros sí que sabemos vivir!

Qué lamentable sensación la de saber que se están haciendo las cosas de forma mediocre, y ver que los demás piensan igual, pero nadie se atreve a dar el primer paso para cambiarlas. Esta sensación de pregonar al vacío cuando nos dirigimos a la jerarquía establecida, ofreciéndoles otras formas de gestionar, que hace falta más motivación entre el personal, que podemos dar pasos de gigante en nuestro negocio y no conformarnos con estar en el mercado, choca inevitablemente con este tufo de sabelotodo que nos impregna.

Cuando hablamos de Scrum Manager, en el fondo estamos ofreciendo la idea de que es necesario el cambio en la gestión, y esto choca inevitablemente con la pirámide de poder. Cuando hablamos de que cada vez es mayor el número de empresas que están cambiando la forma de hacer las cosas, estamos diciendo a nuestros gestores, que se están quedando rezagados, que empieza a llegar al negocio la terrible obsolescencia. Y ese es el primer revulsivo que estamos observando entre el empresariado. Parece como si doliera más a nuestro orgullo saber que otros nos toman la delantera, que el saber que durante años hemos estado haciendo las cosas de forma mediocre.

Si nos fijamos en el artículo Adopción de metodologías ágiles: un estudio comparativo entre España y Europa, pág.6, publicado por la revista REICIS – Volumen 6, Número 4 de Diciembre 2010 (www.ati.es/reicis), podemos ver lo mucho que nos queda por hacer en España. Tenemos que seguir luchando cada uno desde su trinchera para cambiar las cosas.

Como decía Gandhi: “Cada logro sea grande o pequeño tiene etapas de esclavitud y de triunfo; un comienzo, una lucha, una victoria.”

Hagámoslo vs Hazlo

Si es verdad, como empieza a vislumbrarse según las experiencias de Masaru Emoto en base a su libro “Los mensajes del agua”, que el agua, y por extensión los seres vivos que la poseen, mantiene una estructura interna acorde a las sensaciones y al tipo de pensamiento que sobre ella proyectamos, pronto entraremos en una fase decisiva en la evolución humana.

Empezaremos a comprender las maravillas de ciertas aguas curativas, o el porqué de la incorruptibilidad de ciertos personajes, así como la explicación de terapias alternativas como el reiki. Las investigaciones sobre el poder de la oración se harán cada vez más creíbles, y asistiremos a un nuevo proceso de bendición de alimentos, personas, casas, y cuantos objetos imaginemos.

Sorprende comprobar algo en lo que venimos insistiendo durante años, cuando nos referimos a la forma de trabajar, a la forma en la que se manifiesta la autoridad, tal y como se desprende de las imágenes obtenidas sobre los pensamientos “Hagámoslo” frente a “Hazlo”. ¿Es posible que la Naturaleza posea un mecanismo interno antiquísimo mediante el cual sobrevivan mejor las especies que colaboran frente a las que trabajan de forma aislada? ¿Es posible que el orden de las pequeñas cosas, a nivel molecular, se refleje también en el orden funcional?

Si es verdad que el agua cambia a la par que nuestro pensamiento, iremos más allá y pensaremos, por qué no, cómo alterar el rumbo de las cosas. El problema es que cada uno querremos cambiarlo en un sentido, y, entonces, ¿cómo se decantará el agua? ¿Será mejor actuar juntos pensando con unos mismos objetivos? Sin duda nuevos experimentos inundarán los artículos de revistas especializadas. Estaremos pendientes, y mientras tanto, seguiremos con nuestro pensamiento… siempre positivo.

Cambiar el mundo desde un teclado

Quienes tenían dudas sobre si era posible alterar el curso “natural” de la Historia, o quienes pensaban que las redes sociales no podrían ser sino un mero divertimento de adolescentes, se equivocaron. Se equivocaron cuando pensaron que un férreo mando conseguiría acallar a la multitud organizada en redes escondidas a la mirada de los fanáticos del poder, y también se equivocaron cuando pensaron que era imposible que un puñado de jóvenes de entre veinte y treinta años podría dar lugar a lo que ya se llama la Revolución del 25 de Enero, tras la cual ha sido depuesto el dictador Mubarak.

Esos Jóvenes del 25 de Enero, como ya se conocen en todo el mundo, fueron expandiendo por Internet poco a poco sus ideas, que finalmente han sido aceptadas por la mayoría. Esa mayoría que dicen es posible cambiar a partir de un número crítico de personas comprometidas con el cambio.

Por eso, cuando encontramos miradas socarronas o sonrisas de incredulidad entre algunos compañeros de nuestra propia empresa al hablar de la filosofía Scrum Manager, me divierto pensando en el poco tiempo que les queda para cambiar de actitud. Es imparable esta forma de pensar. Se tiende finalmente a construir equipos en los que se permita que aflore el talento de las personas. No podemos ya seguir manteniendo estratos que impidan que fluya la inteligencia en favor del negocio.

Vuelvo a mirar las imágenes de la tele, y ya no me parece imposible cambiar el mundo desde el teclado de este viejo ordenador.