jueves, 7 de diciembre de 2017

Modelo Spotify: Guild (Comunidad)

La comunidad


Aunque la traducción que se suele hacer de Guild es gremio, prefiero llamarlo "Comunidad". En el modelo Spotify, un Guild es una "comunidad" de interés, orgánica y de amplio alcance. Es una organización de personas que quieren compartir conocimientos, buenas prácticas, herramientas, códigos, iniciativas e ideas, generar capacitaciones, organizar code katas/hackathons, ayudar en la construcción de estándares comunes y acuerdos organizacionales. Serían como las "comunidades de práctica" o los grupos de aprendizaje, no necesariamente están en el mismo área de competencia pero mantienen intereses comunes. Una comunidad normalmente no pertenece a una tribu en particular, sinó que recorre toda la organización. Y se reuninen exporádicamente o periódicamente, con cierta regularidad, sin ser un equipo fijo ni una estructura formal de la organización. La vida o disolución de una comunidad depende de la participación, cohesión y motivación de sus miembros.


Líder de la comunidad 


Es aconsejable que la comunidad tenga un líder que sea responsable. Esto hace que sea más fácil seguir el progreso hacia la misión de la comunidad. El líder no es un cargo formal, sino un rol. Tanto la participación, como líder o como miembro, es voluntaria. Hay que tener en cuenta que el líder de comunidad debe ser un líder servicial, quien sostiene la misión y la visión de las respectivas competencias de la comunidad y quien facilita su funcionamiento. También es deseable que el líder sea alguien proactivo y/o un agente de cambio, ya que la comunidad funciona también como mecanismo de mejora continua para hacer aportes de mejora a la organización, generar ideas o liderar alguna innovación. Las principales funciones de un líder de comunidad son:

  • Convocar a las personas. 
  • Permitir y promover que personas de diferentes equipos se reúnan de manera fluida y colaboren en un propósito compartido. 
  • Facilitar y/o moderar las reuniones. 
  • Encargarse de alguna administración mínima (seguimiento de temas). 
  • Coordinar a las personas o miembros para que se realicen las reuniones. 
  • Asegurarse que la comunidad tenga una misión clara y visible para todos. 
  • Asegurarse y promover que sea valiosa para los miembros y la organización. 
  • Facilitar puentes o medios de comunicación. 
  • Fomentar y usar prácticas ágiles (como uso de backlog, kanban boards, retrospectivas, etc.).
  • Delegar y generar trabajo en equipo. No debe ser un cuello de botella ni un acaparador. Debe fomentar el trabajo distribuido, colaborativo y formar otros líderes. Debe lograr que la comunidad pueda llegar a funcionar y existir sin él.
  • Germinar una comunidad si ve la necesidad en la organización.

Germinar una Comunidad


Para hacer nacer una comunidad se necesita crear un ambiente abierto y acogedor. No intente estructurarlos o hacerlos excesivamente formales; en principio, deberían ser entidades autónomas, orgánicas, que prácticamente carecen de jerarquía. Una de las mejores cosas acerca de la vida de las comunidades es que serán evaluadas por su comunidad de ingenieros o colegas, por lo que, tan pronto como una deje de cumplir una función, se vuelva redundante o no necesaria, naturalmente se desvanecerá. O también puede ser absorvida por otra comunidad. Es aconsejable que al momento de formación se defina un propósito y/o misión y se de a conocer al resto, invitando a los integrantes de la organización a participar de forma abierta.

Ejemplos 


Las comunidades pueden ser por capas tecnológicas de desarrollo o especialidad como: Backend Guild, Frontend Guild, QA Guild, UX Guild, DevOps Guild, Iteration Manager Guild (Team Facilitator), Product Owner Guild, Agile Management Guild, etcétera. También por lenguajes: Javascript Guild, Java Guild, etcétera. Por tecnología o prácticas: Continuous Integration, Machine Learning, etc.

Ejemplo de una declaración de comunidad:


Comunidad de Iteration ManagersEs una reunión semanal de 1 hora de Facilitadores de Equipos, Iteration Managers y Scrum Masters. Su objetivo es capacitar a los IM para desarrollar mejor el perfil profesional a través de la discusión y el intercambio de conocimientos. Nos reunimos en la sala desiganad de 16:00 a 17:00 cada martes. Alternamos entre talleres en los que pasamos la hora aprendiendo una habilidad, dinámica o técnica, reuniones regulares donde los IM presentan lo que han estado haciendo y discutimos ideas (sobre métricas, buenas prácticas, calidad, procesos, agilidad, etc.) para mejorar nuestros procesos de trabajo y la transformación ágil.

Mission: Empoderar a los IM para ser agentes de cambio y mejorar nuestra organización y trabajo de los equipos.

Objetivos: Compartir conocimiento, prácticas e ideas. Generar iniciativas de mejoras. Unificar criterios y generar acuerdos. Influir en el cambio cultural de la organización hacia una cultura ágil.

Métricas: Tener una presentación al menos una vez al mes. Generar al menos una iniciativa mensual. Celebramos algun logro de la comunidad mensualmente.



Referencias



viernes, 23 de junio de 2017

Movimiento Ágil: los 4 aspectos claves de la agilidad empresarial



Hoy en día, la agilidad se transformó en un movimiento más allá de Ingeniería de Software y área de producción. En este sentido, el Manifiesto Ágil ya ha quedado algo obsoleto, pero no así su esencia, su corazón. El núcleo esencial ágil se sintetiza en cuatro aspectos claves que pueden aplicarse y guiar las prácticas de cualquier disciplina o proyecto de componente intelectual en cualquier organización empresarial o Sistema Social Empresarial. En el siguiente video esquematizo estas cuatro claves que considero conforma el espíritu del movimiento.






Tengo que recalcar que no inventé nada nuevo. Esto es simplemente la síntesis (que cualquiera puede hacer) del Manifiesto Ágil y la literatura al respecto que fluye en el movimiento ágil. No obstante hace poco rescaté un fragmento de video de Ángel Medinilla, en un meetup de Agilidad y escala, donde sintetiza la agilidad en estos cuatro aspectos claves con los que estoy totalmente de acuerdo y que me alegra que haya alguien que profese lo mismo. Siempre consideré que el movimiento ágil, tanto en la industria de software como en cualquier ámbito empresarial, se resume a estos cuatro aspectos esenciales. El manifiesto ágil está orientado solo al desarrollo de software y por esa razón considero que está algo obsoleto, por lo que algunos intentan brindar alguna otra fórmula valorativa alternativa, como "Modern Agile" o "Heart of Agile", sin embargo pienso que esas ideas no engloban realmente la esencia ágil, no guardan el verdadero espíritu ágil. Y viendo a Ángel encontré, por fin, a alguien que resume tan bien la agilidad y que está en sintonía con algo que hace años vengo fomentando, y es que: estos cuatro aspectos valorativos pueden emplearse en cualquier sistema social empresarial y es lo que constituye el corazón del movimiento ágil.

A continuación comparto el video:



Referencias:

  1. Manifiesto por el Desarrollo Ágil de Software: http://agilemanifesto.org/iso/es/manifesto.html
  2. Ángel Medinilla, meetup agilidad a escala: Conversatorio con Ángel Medinilla sobre Agilidad a escala, incluyendo experiencias reales de los asistentes y perspectivas sobre los marcos de trabajo más conocidos (SAFe, LeSS, Nexus...).





domingo, 7 de mayo de 2017

Valores ágiles: Mandala Ágil

En estos días (primera semana de Mayo 2017) asistí al Agile Open Camp de Chile 2017. Es un evento diferente, con energía, buena onda y muchas conversaciones interesantes. Fue un espacio para compartir y generar semillas para nuevas ideas.

En algunas charlas interesantes sobre la vigencia del “Manifiesto Ágil” y sus posibles actualizaciones con generalizaciones y simplificaciones, surgieron debates sobre “Modern Agile”, “Heart of Agile” (de Alistair Cockburn) y como se podría mejorar la forma de presentar el Manifiesto Ágil. A mi no me convencía la propuesta de “Modern Agile”, con el agregado que hace de la seguridad como requisito (“Make Safety a Prerequisite”) ni tampoco me cerraba la simplificación propuesta con el “Heart of Agile” con dos incisos muy relacionados como la reflexión y la mejora continua, pero mostrados separados. En consecuencia pensé en hacer una síntesis.

La idea es que la agilidad se ha vuelto excesivamente decorada y el manifiesto, hasta cierto punto, tiene muchos incisos (4 valores y 12 principios) como para ser aprendido fácilmente. Además fue concebido para el desarrollo de software, específicamente, y no para cualquier organización.

Algunas preguntas que me resonaban en esos días fueron… ¿Qué podemos enfatizar para volver al corazón de la agilidad y reinterpretar al manifiesto ágil rescatando lo esencial? ¿Cómo mostrar el corazón de la agilidad de una forma didáctica y simple? 

Respondiendo a estas preguntas, pienso que es bueno tener un mandala, como un escudo, que resuma algunos conceptos claves de la agilidad, sin perder nada del manifiesto. Cuando terminaba el evento “Agile Open Camp” hice un borrador de lo que para mí podría ser un buen mandala (con forma escudo) que muestra cuatro conceptos clave, que cohesionan a los 4 valores y 12 principio. El dibujo que hice (con sharpie en hoja A4) es el siguiente:


Los conceptos clave son:
  1. Collaboration
  2. Delivery (Value Flow)
  3. Adaptation
  4. Improvement

Estos conceptos contemplan a los valores y principios ágiles como comento a continuación:
  1. Factor humano (Colaboración): este concepto abarca a la priorización de "individuos e interacciones sobre procesos y herramientas" y a la "colaboración con el cliente sobre negociación contractual". Ambos valores son necesarios para lograr la colaboración. También sostiene al principio que dice que "los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.". Además para lograr mejorar la colaboración, y con ella un equipo de alto desempeño de trabajo sostenibe, es necesario lograr individuos motivados. La colaboración se da en procesos de autoorganización. Y finalmente para promover la colaboración se prioriza y fomenta la conversación cara a cara y el fortalecimiento de las relaciones humanas dentro de la organización.
  2. Flujo de valor (Entrega): esta es una idea pragmática de operatibilidad. Abarca a "Software funcionando sobre documentación extensiva" donde se amplía a producto funcionando como foco principal por sobre documentación excesiva (de esta manera no se limita a solo software). Se tiene como prioridad satisfacer a nuestros clientes mediante la entrega temprana y continua de un servicio o producto con valor. Las entregas de valor deben ser frecuentes, con preferencia al periodo de tiempo más corto posible. Que las cosas funciones, nuestros productos y servicios, es la medida principal de éxito y progreso.
  3. Adaptación: este abarca a la "Respuesta ante el cambio sobre seguir un plan". Los procesos Ágiles promueven el desarrollo sostenible mediante ciclos de retroalimentación y auto-regulación para manejar el cambio de requisitos y el entorno cambiante. Se busca la adaptabilidad en un proceso sostenible con procesos de auto-ajustar el comportamiento según el contexto cambiante y el continuo feedback del cliente y usuario.
  4. Mejora continua: este concepto incluye la búsqueda de la excelencia, mediante la mejora contínua con etapas de reflexión y acción. También incluye a la simplicidad, como parte de la búsqueda de excelencia, además de que es parte de la ciencia y de la ingeniería.

Pienso que esta síntesis es una buena herramienta visual y conceptual para enseñar agilidad. Recordar estas cuatro ideas se hace muy simple, más si mantenemos visible el mandala en nuestro lugar de trabajo.

El equipo de participantes del AOC...

Referencias:




jueves, 13 de abril de 2017

Scrumban en DevOps



¿Qué metodología ágil podemos usar en operaciones para que funcione con Equipos de desarrollo Scrum? Pues, podemo usar Scrumban.

Scrumban se trata de una metodología mixta y flexible entre Scrum y Kanban. Combina las la flexibilidad de Kanban y las características básicas de Scrum. Por un lado, se toma de Kanban lo de mantener un trabajo continuo, exponer el flujo de trabajo, el tablero de trabajo persistente, auto-asignaciones de tareas solamente por el sistema del tomar y jalar (pull), limitar el trabajo en curso y buscar optimizar el flujo teniendo en cuenta la métrica “cycle time”. Por otro, se agrega de Scrum la ceremonia de planning (principalmente bajo demanda), la retrospectiva como reunión de mejora contínua (Kaizen), el trabajo en ciclos o iteraciones sin ser limitativo o restrictivo de trabajo y la priorización, que se recomienda hacer en cada planificación. Dentro de la flexibilidad que brinda, hace optativo el usar otras partes o prácticas de Scrum. Bajo esta metodología no es necesario estimar, puede ser algo optativo, ya que no se necesita calcular el trabajo que entra en una iteración porque el trabajo es continuo. Aunque sí se pueden estimar tiempos de entrega y/o tamaños de paquetes de trabajo. Por otro lado, al ser el trabajo contínuo y no tener un compromiso formal de trabajo comprometido en una iteración, los cambios y re-priorizaciones pueden hacerse en cualquier momento. También es muy flexible el tipo de roles de los miembros del equipo debido a que no prescribe roles específicos ni es necesaria la multidisciplinariedad que recomienda Scrum. Además, como se mencionó antes y al igual que en Kanban, el tablero permanece persistente, mientras que sólo cambian las tareas y sus prioridades. A diferencia de Scrum que el tablero de sprint se renueva en cada iteración. Relacionado a la planificación, en Scrumban se planifica focalizados en los releases y no es obligadamente necesario hacerse en la planning de cada iteración; pues, la planificación se puede realizar solo bajo demanda. 

Ámbito de aplicación


Este método se muy útil principalmente para procesos de ritmo rápido, para startups, proyectos que requieren fabricación de productos constante, equipos y proyectos con ambientes muy dinámicos y cambiantes, equipos de solución de problemas de contingencias en producción, equipos de mantenimiento, soporte o desarrollo de infraestructura. También es útil para integrar (coordinar y sincronizar) otros equipos de soporte a los equipos Scrum, por ejemplo bajo el marco DevOps. En estos casos, los equipos soporte pueden usar Scrumban y los de desarrollo Scrum.


Valores y principios


Los principios principales de Scrumban son: mostrar el flujo de trabajo, cuidarlo y mejorarlo. Aunque para seguir el marco Ágil de trabajo con mindset DevOps se puede usar el manifiesto ágil disciplinado (Ver the Disciplined Agile Manifesto) o tener en cuenta los aspectos principales del manifiesto ágil. También se pueden incluir los valores de Scrum y/o principios Lean. Esto es bastante flexible y depende de cada equipo.


Integración Development con Operaciones


Las transformaciones en la organización clásica de TI a menudo son difíciles; Inicialmente, un pequeño equipo o conjunto de equipos multifuncionales haciendo Scrum, compuesto por desarrolladores y por otro lado equipos de especialistas en operaciones. Para integrarlos bajo el marco ágil no se suele usar Scrum en operaciones, complejiza la coordinación entre Dev y Ops. A lo que sí recurrimos es a Lean, Kanban o Scrumban. Mientras los equipos “Dev Scrum” cubren la demanda de necesidades de negocio de la organización (desarrollando y desplegando), los equipos “Ops Scrumban” cubren la demanda de los equipos Dev para soporte del continuous Delivery, infraestructura u otras dependencias técnicas. Por ejemplo, grupos como Infraestructura o Soporte, gestionan un flujo continuo de solicitudes de los usuarios Devs o de clientes internos de la organización. Estos equipos encuentran difícil calzar su trabajo dentro de iteraciones Sprint de tiempo fijo, con cierta rigidez, cuando su trabajo tiene dependencias que pueden no ser satisfechas dentro de una iteración definida o sus clientes no pueden esperar al final de una iteración para recibir una corrección de software.

Roles

Kanban no prescribe roles como títulos pero se sugieren los siguientes [D. A.]:
  1. Service Request Manager o Product Owner: es el encargado de la priorización del backlog y entender las necesidades del cliente. Si el cliente es interno a la organización como el sector de producción, el PO se encarga de tratarlos como stakeholder y ser el único punto de entrada para los requerimientos que hace la organización al equipo.
  2. Service Delivery Manager o Flow Master: es un facilitador (equivalente a un Scrum Master en Scrum). Se encarga de facilitar las ceremonias, el flujo de trabajo y propiciar la mejora continua.

Flujo de trabajo y tablero kanban


Estos equipos pueden usar tableros kanban para exponer sus flujos de trabajo. Estos tableros no necesariamente tienen alta cohesión a un objetivo como si se suele hacer en Scrum. Aunque, sí deben tener objetivos para el trabajo en curso. Estos tableros están más orientados a entrega de soluciones out-come en releases, en vez de tiempo fijos. Deben permitir flexibilidad para adaptarse a la demanda de Dev y de la organización.
(Nota: lo ideal es que en la columna in progress se coloquen los estado del flujo de trabajo)

Métrica


En Scrumban se usan las métricas de Kanban para medir el valor, proceso y flujo relacionados con el propósito. En este sentido, el rendimiento (Throughput) es el más relevante y se mide a través de indicadores de tiempos de duración promedio de actividades o trabajo sobre elementos. También se usa el Cycle Time, que es el tiempo período requerido para completar un ciclo de trabajo u operación desde que se inició; O para completar una función o tarea desde el principio del trabajo hasta el final (El tiempo total que transcurre desde el momento en que el trabajo se inicia en una tarea hasta su finalización). También se usan herramientas de monitoreo como "Histograma de Lead Time", o de cycle time, y el "Cumulative Flow Diagram" (CFD). El CDF o diagrama de flujo acumulados muestra el total de elementos que están en curso, así como el tiempo que tarda en completarse. La estimación promedio del tiempo de ciclo de avance muestra cuánto tiempo, en promedio, se tarda en completar un elemento. También se puede usar un indicador de eficiencia de flujo: Flow efficiency = [work time / (work time + wait time)] × 100%.

Mejora continua


En Scrumban se busca tener ciclos de mejora continua y que se pueden implementar mediante reuniones frecuentes de retrospectiva como en Scrum. El foco principal, en la mejora continua, es mejorar el flujo de trabajo prestando atención a los cuellos de botella y a la optimización del flujo de trabajo. Para ello también se buscan resolver impedimentos del flujo y solución de causas raíces.





Referencias:





miércoles, 29 de marzo de 2017

Facilitación gráfica sistémica

En nuestro pensar conversan constantemente el zorro racional y el colibrí emocional. Y, tal vez, para compensar tanta planificación y frivolidad racional, el agilismo trajo el pensamiento y facilitación visual a la mesa de la ingeniería de software. Pienso que encontrar el equilibrio entre estos dos mundos es inmensamente fructífero en el desarrollo de software. Si nos quedamos entrampados en el pensamiento visual y sus herramientas, como post-its y colores nos podemos perder en el holismo y con él en el desorden. Y no salir de la baldosa de la racionalidad ingenieril nos puede hacer ciegos de la creatividad y cortos en la innovación. El arte es encontrar el camino del medio.




Bajo el marco de la agilidad se emplean las facilitaciones gráficas para traducir conceptos complejos y ayudar a razonar o analizar problemas complejos en un lenguaje visual de palabras e imágenes. Esta estrategia puede ser una manera muy eficaz de resumir y comunicar ideas, permitir a los participantes ver e interiorizar el panorama general de una discusión o presentación y facilitar el análisis de la realidad y de sistemas. Pero considero que las dinámicas divertidas y coloridas no debería reemplazar a la ingeniería ni los post-its reemplazar el modelado de sistemas.

Facilitar gráficamente no debería ser graficar por graficar. Cuando dibujamos, lo que hacemos es modelar. Hacemos una representación simplificada de un sistema en algún punto particular en el tiempo o el espacio destinado a promover la comprensión del sistema real (Bellinger 2004); por tal motivo, hay que tener en cuenta que modelar de una forma acertada, para comprender el sistema real, requiere usar herramientas apropiadas. Sinó podríamos llegar a modelar ideas que no se condicen con la realidad, perder tiempo, llegar a problemas que no son causa raíz y llegar a soluciones que no lo son y que hasta pueden llegar a ser problemas futuros.

La facilitación gráfica no nos sirve de nada en ingeniería de software (más que como entretención y embellecimiento) si no usamos “herramientas conceptuales de diagramado”, “conceptos de sistemas” y herramientas ingenieriles. No es necesario usar lenguaje técnico ni usar los diagramas en forma estricta, se pueden adornar y enriquecer gracias al uso de la creatividad. Pero, a mi criterio, no se debería perder de vista que debemos mantener cierta concordancia con la realidad y el profesionalismo que la disciplina requiere.

A continuación comparto un conjunto de “herramientas conceptuales de diagramado” que todo facilitador gráfico y sistémico podría emplear:

  1. ADL: Architecture Description Language.
  2. BD: Block Diagram.
  3. BPMN: Business Process Modeling Notation.
  4. CD: Conceptual Diagram, Concept Map or Concept Draw.
  5. CLD: Causal Loop Diagram.
  6. ERD: Entity Relationship Diagram.
  7. FBD: Functional Block Diagram.
  8. FC: Flow Charts (for control flow).
  9. DFD: Data Flow Diagram.
  10. MMD: Map Mind Diagram.
  11. SBD: Signals Block Diagram.
  12. SC: Structure Chart.
  13. SFD: Stock and Flow Diagrams.
  14. SSADM: Structured Systems Analysis and Design Method.
  15. UML: Unified Modeling Language.


Referencias:



jueves, 2 de marzo de 2017

Lean: Lean Systems Engineering

Lean para Ingeniería de Sistemas


El MIT llevó a cabo estudios de Toyota Production System, que produjo un enfoque llamado "Sistema de Producción Lean" (Lean Production System, Krafcik 1988; Womack et al. 1990). El desarrollo posterior de "Lean thinking" y el trabajo relacionado en el MIT llevó a la Fuerza Aérea a patrocinar el Lean Aerospace Initiative (Murman 2003, Womack-Jones 2003). Simultáneamente, se utilizaron ideas Lean para reforzar los aspectos de escalabilidad y confiabilidad de los métodos ágiles para el software (Poppendieck 2003; Larman-Vodde 2009) y con el enfoque de Kanban se orientó al manejo de flujo y se ha aplicado con éxito al desarrollo de software (Anderson 2010) desde entonces.

Principios


Considero que Lean a influenciado a ingeniería de sistemas como el pensamiento sistémico ha influenciado a Lean. Para la ingeniería de sistemas, la fuente actual de Lean es “Lean Systems Engineering” y sus principios que son los siguientes:

1. Valor: Guíe el proyecto mediante la determinación de las propuestas de valor de los clientes y otros stakeholders. Mantenlos involucrados y gestiona cambios en sus proposiciones de valor.
2. Organice el flujo de valor: especifique los requisitos del proyecto, la
exploración de espacios comerciales entre las propuestas de valor, evaluación de costos y evaluación de madurez tecnológica, resultando en un plan de proyecto completo y un conjunto de requisitos. Pienso que en ámbitos ágiles esto se debe traducir a realizar un RELEASE PLAN.
3. Flujo: Centre la atención cuidadosa a las actividades de la ruta crítica del proyecto (cuellos de botella) para evitar costosas paradas de trabajo, Incluyendo la coordinación con proveedores externos.
4. Jale (Pull): Tire de las tareas siguientes que se realizarán en función de las necesidades y dependencias priorizadas. Si la necesidad de la tarea no puede ser encontrada, rechace como desecho.
5. Perfección: Aplique la mejora continua del proceso para acercarse a la perfección. Maneje los defectos tempranamente y busque y corrija las causas raíces de los problemas en lugar de sus síntomas.
6. Respeto por las personas: Distribuya la responsabilidad, la autoridad y la rendición de cuentas a todo el personal. Nutrir un ambiente de aprendizaje. Tenga a las personas como los activos más valiosos de la organización (Oppenheim 2011);


Referencias: 
  • Guide to the Systems Engineering Body of Knowledge (SEBoK), 2016. URL: http://sebokwiki.org
  • Murman, E. 2003. Lean Systems Engineering I, II, Lecture Notes, MIT Course 16.885J, Fall. Cambridge, MA, USA: MIT.
  • Oppenheim, B. 2011. Lean for Systems Engineering. Hoboken, NJ: Wiley.
  • Poppendieck, M. and T. Poppendieck. 2003. Lean Software Development: An Agile Toolkit for Software Development Managers. New York, NY, USA: Addison Wesley.
     



lunes, 13 de febrero de 2017

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:

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.