Agile: Gamification - Dinámicas De Grupo

A vece, cuando las organizaciones adoptan agilidad y se comienza con dinámicas de trabajo, postits, sharpies, flipchart, dibujos, etcétera, pareciera que volvemos al kindergarten; pero esto tiene sus razones. Y las razones derivan de Game Thinking con Gamification.

Gamification

Gamification (Game Thinking), es el uso de elementos de diseño de juegos, pensamiento y mecánicas de juego para implicar a las personas en alguna actividad con un objetivo [1]. La gamification es bastante usada en entornos ágíles (Agile Game) para ayudar a los cambios culturales, cohesionar equipos y buscar el trabajo colaborativo. En este contexto se refiere al uso de la mecánicas de juegos y recompensas en un entorno de desarrollo de software ágil para aumentar el compromiso del equipo y conducir los comportamientos deseados. También se usa para lograr una cultura creativa e innovadora en la organización. Toda Organización Inteligente necesita mecanismos de creatividad para conducir hacia la innovación y la gamification y las "Dinámicas De Grupo" ayudan a eso.

Dinámicas De Grupo

Parte de la Gamification son las "Dinámicas De Grupo" (Group Dynamics) o "Dinámicas Didácticas Activas" que consisten en dinámicas donde un facilitador propone juegos con determinadas reglas para cumplir un objetivo. En estas dinámicas no necesariamente deben haber ganadores o reconpensas, pero sí se persigue un espacio de juego que funcine como enseñanza práctica y didáctica o consecucion de un objetivo de equipo mediante herramientas visuales (Visual Thinking), creativas (Creative Thinking) o de diseño (Design Thinking).

Una dinámica de grupo tiene como entrada un game con un objetivo, reglas e instrucciones. Un facilitador ayuda a que la dinámica se lleve a cabo, con las personas integrante, cumpliendo el objetivo. Además las dinámicas, por lo general, tienen una estructura compuesta por una etapa inicial de divergencia de ideas (open), una segunda etapa de exploración de ideas (executing) y una etapa de cierre donde se converge en alguna conclusión o resultado según el objetivo del game (close) [2]. Todo el proceso debe cumplirse en un time-box estipulado y para que sea efectiva se debe llegar al resultado esperado (según el objetivo del game).

Cartera de dinámicas

Un facilitador creativo debería contar con una cartera de dinámicas que puede traer a la mano cuando necesite alguna. Algunos lugares donde podemos encontrar dinámicas son:

• Gamestorming book [2].
• Tasty Cup Cakes: http://tastycupcakes.org
• Dinámicas de retrospectivas RETROMAT. 
• Fun Retrospectives.
• Innovation Games .com
• Canal de dinámicas en Youtube: Rincón de Castro.

Conclusión

Hay que recordar que las organizaciones Software Factory que quieren ser inteligentes y apostar a la innovación y al trabajo creativo pueden recurrir al “Game Thinking”, pues más del 50 por ciento de las organizaciones que tienen procesos de innovación los jugarán [1], pero nunca se debe olvidar que no hay que dejar de hacer Ingeniería de Software.


Referencias:

1. [1] Article: Agile Gamification, Boosting team performance and software development practices using game elements, Davi Gabriel da Silva, ScrumAlliance, 20 August 2014.
2. [2] Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Dave Gray, Sunni Brown, and James Macanufo. O'Reilly, 2010.

Kanban: Las tres reglas básicas del Método Kanban

En este post quería comentar didácticamente las bases del método Kanban. Pues el mismo, es un sistema de trabajo, con una mirada sistémica orientada al proceso de trabajo con el fin de optimizarlo. A "Kanban básico" se lo puede entender por sus tres tres reglas principales:

1. Mostrar el proceso,
2. Limitar el trabajo en curso; y
3. Optimizar el flujo.

Para “mostrar el proceso” de trabajo y sus ítems se suele usar un tablero físico o herramienta digital equivalente con tarjetas representando los ítems de trabajo.

Para “limitar el trabajo en curso” se busca acordar entre los involucrados límites sobre la cantidad de ítems de trabajo que pueden encararse a la vez. A este volumen de trabajo en curso se lo llama WIP (Work in Progress).

Y para “optimizar el flujo” se monitorea y sigue el avance de los ítems de trabajo en el flujo del proceso, para determinar si el progreso sigue un ritmo regular, estable y óptimo. Para ello se usan métricas tales como el Cycle time (Ct), Lead time (Lt) y el Throughput.

Métricas

Las métricas de Kanban provienen de teoría de colas y son las siguientes:

El Cycle time (Ct) es el tiempo de ciclo cuando el trabajo real comienza hasta cuándo está listo para entregarse (tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado sin los tiemos de cola o espera). El Cycle time es más una medida mecánica de la capacidad del proceso de trabajo del sistema.

El Lead time (Lt) es el tiempo total de espera del demandante o tiempo total de procesamiento de todo el sistema en que una tarea o ítem es introducido en el sistema hasta que el trabajo está completado y es entregado. El Lead time comienza cuando es hecha la petición y termina cuando se entrega el trabajo listo. Ver el siguiente gráfico ejemplo:

El Touch Time (Tt) es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo (cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo).

La relación entre estas tres métricas es: Tt <= Ct <= Lt

Por otro lado, el Throughput es el rendimiento del sistema de trabajo, como capacidad de producción, que consta de el número medio de unidades procesadas en un tiempo determinado.  O sea que, representa la cantidad de ítems que un equipo puede terminar en un periodo dado, por ejemplo 4 ítems por semana.

Finalmente y complementariamente, para optimizar el flujo, se pueden utilizar diferentes herramientas de análisis como el CFD. El CFD o Diagrama de Flujo Acumulado, es una herramienta que permite evidenciar cuellos de botella mostrando el flujo de trabajo en el sistem según períodos de tiempo. Esta herramienta es muy utilizada en Kanban.

Resumen

En fin, esto es Kanban y lo bajé a un gráfico auto-explicativo.

Quería recordar que Kanban puro es una alternativa a la agilidad o una técnica a sumar en un marco ágil, pero no es ágil por definición. De los cuatro valores del manifiesto ágil, el único que se puede argumentar que si sigue Kanban por naturaleza es el de responder al cambio frente a seguir un plan.

Kanban en Ingeniería de Software

Hay que aclarar que en Ingeniería de Software se usa el "Método Kanban" definido por David Anderson. El mismo agrega tres prácticas más a las básicas anteriores: 

• Dirigir y gestionar el flujo.
• Hacer las Políticas (reglas y directrices de su trabajo) de Proceso Explícitas.
• Utilizar modelos para reconocer oportunidades de mejora.

Además fundamenta el método Kanban en cuatro principios:

1. Comience con lo que hace ahora.
2. Se acuerda perseguir el cambio incremental y evolutivo.
3. Respetar el proceso actual, los roles, las responsabilidades y los cargos.
4. Liderazgo en todos los niveles.

Y, además, propone los roles de Product Owner y Flow Master (facilitador).



Referencias: 

• Kanban In Action, by Marcus Hammarberg, Joakim Sunden, Publisher: Manning Publications.
• Kanban: Successful Evolutionary Change for your Technology Business, by David J. Anderson, Publisher: Blue Hole Press.
• Blog: Kanban - Definition of Lead Time and Cycle Time.
• The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen.
• Kanban, an alternative path to agility by David Anderson.
• Kanban… ¿realmente es ágil?
• Anderson, David (septiembre de 2003). Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall. ISBN 0-13-142460-2.
• Anderson, David (abril de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 0-9845214-0-2.
  http://web.archive.org/web/http://www.djaa.com/principles-kanban-method 
• David Anderson "The principles of the Kanban method" December 10, 2010
• Anderson, David (septiembre de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1.
   

Agile Tool: APM tool - Taiga Open Source

Estuve investigando herramientas gratuitas de gestión de proyectos Ágiles (APM tool) y encontré una, gracias a un amigo que la usa, que me pareció bastante buena. Se llama Taiga.

Taiga es Open Source, Agile and Free. Es una plataforma de gestión de proyectos completa para principiantes y desarrolladores ágiles y diseñadores que quieren una herramienta sencilla y simple que hace que el trabajo sea afable. Es colaborativo, gestor de tareas e issues, manejador de kanban boards y tiene posibilidad de wiki. Se ve bastante interesante.

Se puede ver una DEMO en el siguiente link: https://www.youtube.com/watch?v=jaww4V4yf3I

Taiga es personalizable hasta cierto punto. Configurando un proyecto se pueden usar sprints backlog y se le pueden configurar varias columnas como:  TO-DO, Blocked, In Progress, To Testing, Ready To Deploy y DONE. Además se pueden personalizar los perfiles de los miembros de los equipos.

Parece una buena tool.

Referencias:

Alternatives Taiga: http://alternativeto.net/software/taiga-io/?license=free

See it in action / video review: https://www.youtube.com/watch?v=jaww4V4yf3I

Community generated guide: http://taiga.pm/

Alternatives to JIRA for all platforms with Free or Open Source: http://alternativeto.net/software/jira/?license=free