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

Transformaciones Organizacionales: Estereotipos de organizaciones

Uno de estos días meditando sobre las transformaciones organizacionales y sobre la evolución al agilismo de algunas empresas es que llegue a pensar en una metáfora. Que las organizaciones (corporaciones, compañías, empresas, etc.) pueden ser una de tres tipos: un Robot Comandado, Moho del Fango y un Pulpo Inteligente.

El Robot Comandado

Algunas empresas u organizaciones son como robots comandados. Por un lado son robots, o sea, piezas mecanica encastradas como engranajes para cumplir algún fin. Esto las hace rígidas, que necesitan de mucho tiempo para cambiar, debido a que tienen varias áreas con procesos muy lentos y engorrosos y burocráticos. La gestiones suele ser basadas en modelos contractuales cerrados con procedimientos de gestión de cambios muy definidos. Por lo tanto, cualquier modificación requiere grandes sumas de dinero y medidas que pueden afectar a sus empleados y al clima laboral. Además son empresas comandadas, donde importa mucho el control, la jerarquía y la autoridad para la ejecución de sus planes. Son empresas que siguen planes rígidamente. Son empresas, en su generalidad, poco amigas de la agilidad.

El Moho del Fango

Por otro lado, hay empresas u organizaciones que se parecen al hongo Moho del Fango. Este Moho es un organismo ameboideo que es capaz de demostrar cierta inteligencia al resolver determinados problemas. Pero no es muy inteligente y pasa buena parte de su vida como miles de organismos unicelulares distintos; cada uno se mueve independientemente de sus otros compañeros [1]. Bajo determinadas condiciones se transforma en un solo organismo mayor que comienza a reptar. El moho del fango oscila entre ser una colonia y una criatura única. Estas organizaciones pueden ser ágiles, aunque a gran escala dificultan su camino a la eficiencia organizacional.

El Pulpo Inteligente

Finalmente, hay otras que son como un pulpo inteligente. Es que hay organizaciones y organismos que se comportan como un ser único, como el Pulpo. Estos animales son sistema inteligentes gracias a que tiene sistema nervioso central, cerebro y memoria, se adaptan a su entorno, innovan, son flexibles y ágiles. Son una forma de organización inteligente.

Autonomía y alineación

Uno de los elementos claves en las organizaciones es la finalidad organizacional dada por la visión. En el alineamiento y cumplimiento de objetivos es importante el grado de autonomía que existe en una empresa. La autonomía crea compromiso a diferencia de la obediencia que crea sumisión, pero las dos sin alineamiento conducen a la ineficiencia. En este sentido la autonomía puede ser una espada de doble filo. Por un lado, estimula la creatividad y la participación; pero por otro lado, la falta de autonomía sin liderazgo autoritario ni visión compartida puede conducir al caos, ambigüedad e ineficiencias. Es algo crucial y difícil equilibrar autonomía y alineamiento.

Cuando estoy en alguna empresa me preguntaría... ¿desde que estereotipo a cual otro nos dirigimos?




Referencias: 
[1] La Quinta Disciplina: El Arte y la Practica de la Organizacion Abierta al Aprendizaje
Peter M. Senge - Ediciones Granica, S.A.
 
 

Scrum: Daily Tips

Daily Tips

En este post me gustaría hablar de la ceremonia más conocida del mundo de la agilidad, la reunión diaria de Scrum o "Daily". El objetivo de esta reunión es facilitar la transferencia de información, cumplir el objetivo del sprint y la colaboración entre los miembros del equipo para aumentar su productividad poniendo de manifiesto puntos en que se pueden ayudar unos a otros, levantando problemas o riesgos y coordinando actividades.

Checklist

A continuación comparto un checklist a tener en cuenta en una daily genérica de Scrum:

1. Respeto el tiempo de inicio.
2. Hablo sobre la respuesta a las siguientes preguntas:
1. ¿Qué hice ayer?
2. ¿Qué voy a hacer hoy?
3. ¿Tengo algún obstáculos, impedimentos o veo algún riesgo?
3. Controlo el daily-timebox, aconsejable en máximo 15 minutos.
4. No me extiendo más tiempo que del daily-timebox dividido la cantidad de participantes (2-3 min).
5. Actualizo el board/kanban.
6. Soy conciso, preciso y concreto. No profundizar en detalles.
7. Mantengo el foco mientras todos participan.
8. Lo que diga debe ayudar a la sincronización de tareas, transparencia de status, colaboración del team y mantener el foco en  el "objetivos del Sprint".
9. Soy positivo y mantengo el buen humor.  
10. ¿Qué no hago?
1. No le reporto a un SM, PO, líder o PM.
2. No hago una planificación detallada.
3. No discuto técnicamente.
4. No estoy sentado (es stand-up).

Daily alineada a los valores y principios

Para lograr una daily eficiente tenemos que guiarnos por los valores y principios de Scrum y la agilidad. Por ejemplo:

• Foco: si vemos que alguien se extiende o que se inicia un debate técnico podemos decir: "Discutamos esto después de la reunión.".
• Coraje: si vemos que el progreso de trabajo no progresa como debería, tenemos el coraje de exponerlo y hablarlo.
• Respeto: nos tratamos bien, dejamos susceptibilidades de lado y mantenemos el buen humor.
• Compromiso: siempre estamos comprometidos con cumplir el objetivo del sprint y no desviarnos de él.
• Colaboración: le decimos a compañeros con complicaciones o impedimentos... ¿cómo podría ayudarte? Además tomamos tareas que no necesariamente son nuestro fuerte, pues queremos aprender y balancear el trabajo y conocimiento del equipo.
• Abiertos: decimos a todos todo acerca de todo nuestro trabajo sin miedos ni tapujos y escuchamos a los demás teniendo en cuenta sus puntos de vista.
• Auto-Organización: todos estamos atentos a iniciar la daily a horario, respetar el timebox y moderar. no debemos depender exclusivamente de un Scrum Master o líder.
• Simplicidad: buscamos ir al grano con las opiniones y comentarios, y los detalles técnicos o reuniones de análisis u organización las dejamos para después.
• Excelencia: buscamos la excelencia en nuestro trabajo diario y del resultado del sprint.
• Colaboración con el cliente: podemos incluir al Product Owner para que tenga presente el estado del avance y pueda ayudarnos si nos desviamos del objetivo o tenemos impedimentos de negocio.
• Motivación: tratemos de motivarnos para iniciar el día con ganas y energía. Que no se torne en una Daily aburrida. 
• Sostenibilidad: si surgen ideas para mejorar y promover el desarrollo sostenible las sugerimos.

Pienso que si tenemos en cuenta todos los puntos anteriores podemos lograr dailys productivas y útiles y mejorar nuestro día a día laboral.

Referencias:
Principios del manifiesto agil.
Scrum Guide Org.
Agilest, Agile Scrum Methodology, Daily Scrum Meeting.
Quick-scrum: Daily Stand-up.

Scrum & Lean: Mejora contínua con “Minimum Viable Change”

Cuando actuamos como agentes de cambio debido, entre otras cosas, a retrospectivas o procesos de mejora contínua, identificamos y evaluamos problemas para proponer acciones “Action Items” como experimentos de mejora. Para eso podemos usar el concepto de “Minimum Viable Change” tomado de Lean. Un “Cambio Mínimo Viable” es el cambio más pequeño posible que maximizará el aprendizaje y generará beneficios, como también así podría ayudar a construir un programa de cambio viable y a ejecutar un conjunto viable de tácticas de cambio. O sea que, un ítem de acción MVC es un experimento de cambio, como si fuera una hipótesis a probar mediante la cual aprenderemos en la práctica.

El experimento de mejora continúa se hace hasta que haya probado (mediante mediciones) ser verdadero o falso, o que la limitación de tiempo haya transcurrido.

La forma de hacerlo, ya sea digital o con tarjetas, puede ser usando "ítems de acción" en un "tablero Kanban" con un "workflow" simple. Para los ítems podemos usar un formato alternativo de redacción como el siguiente: Para resolver <Problema> haremos <una acción> con que <un destinatario específico del cambio> resultará en <un resultado> con cierta restricción de tiempo <restricción> si se cumple que <Criterio de Aceptación>.

En mi opinión un formato útil de "ítem de acción" puede ser:

El flujo en kanban puede ser:

Resumido en un diagrama:

...y ya podemos implementar nuestro proceso de mejora continua.

Referencias:

http://agileconsulting.blogspot.cl/2013/08/refining-change-canvas-to-represent.html

http://agileconsulting.blogspot.cl/2013/07/how-danny-developer-used-lean-change.html

Agile: Pareto y los Early Adopters

Pareto y los adoptadores tempranos

En los proyectos de innovación en que se usa Scrum o algún marco ágil, se puede trabajar con MVPs, en el ciclo de vida del producto, que se orientan a "Early Adopters" siguiendo la "Lay de Pareto" y teniendo en cuenta la "Ley de difusión de la innovación"[1].

Los adoptadores tempranos

Everett Rogers define una categoría de adopción como una clasificación de individuos dentro de un sistema social sobre la base de Innovación. Para Rogers [1], los adoptadores tempranos son quienes tienen el mayor grado de opinión y liderazgo entre las categorías de los adoptantes de innovaciones y son los que están dispuestos a probar una nueva tecnología, a pesar de que tenga fallos o sea una versión de prueba. Los adoptantes tempranos suelen ser más jóvenes en edad, tienen un estatus social más alto, tienen más lucidez financiera, educación avanzada, son más socialmente avanzados que los adoptantes tardíos.

Ley de pareto en el desarrollo del producto

La ley de Pareto [6], en software y scrum, también conocida como la regla del 80/20, establece que, de forma general aproximadamente el 80% del valor proviene del 20% de features. Basándonos en ella, con Scrum, buscamos centrarnos y adelantarnos en construir el 20 % de funcionalidad más importante y core de nuestro producto, mediante diferentes MVPs que probaremos en primera instancia con los adoptadores tempranos. En otras palabras, con el 20% del esfuerzo se puede proporcionar el 80% del valor y obtener resultados anticipados (“time to market”) sacando rápido algo al mercado probando hipótesis con early adopters y obteniendo feedback temprano.

Ley de difusión de la innovación

La difusión de innovaciones es una teoría que examina cómo, por qué, y a qué ritmo las nuevas ideas y la tecnología se propagan a través de las culturas. En esta teoría se explica cómo los sucesivos grupos de consumidores adoptan la nueva tecnología a medida que pasa el tiempo. Los adoptadores tempranos son los primeros en adoptar una innovación y comprende un grupo de aproximádamente entre el 13,8% de la población total de consumidores adoptadores de la innovación o el 13,5% de la población total. En el desarrollo de software podemos apuntar a estos usuarios adoptadores tempranos para probar rápidamente nuestro producto ya que son usuarios tolerantes y motivados para adoptar nuestras innovaciones.

Referencias:

[1] [Everett Rogers, 1962] Diffusion of Innovations, Everett Rogers, 1962.
[2] Simon Sinek, Cómo los grandes líderes inspiran la acción, TED 2009.
[3] Difusión de innovaciones, wiki.
[4] Ley de la Difusión de la Innovación, Fabiola Martinez, Youtube 2011.
[5] Article on Trans-cultural diffusion or Roland Burrage Dixon (1928): The Building of Cultures.
[6] Bousquet, G.H. (1999). «Vilfredo Pareto (1848–1923): Biographical Notes on the Occasion of the Publication of his Letters to Pantaleoni». En: John Cunningham Wood y Michael McLure (Eds.). Vilfredo Pareto. Critical Assessments of Leading Economist (Londres y Nueva York: Routledge) 1: 197-. ISBN 0-415-18500-9.
[7] Scrum, un proceso de trabajo 2.0.