Agile Team: Swarming work o Trabajo Enjambre

El trabajo enjambre o swarming se menciona en el contexto de Agile o Extreme Programming para indicar el trabajo en donde todos los miembros del equipo trabajan, colaborando, sobre un mismo problema o artefacto. Es decir, todo el equipo frente a una pizarra o una computadora analizando y resolviendo un solo problema, diseñando y diagramando una arquitectura, escribiendo un documento o desarrollando una sección de programa (Mob Programming). 

Scrum en Enjambre

Por ejemplo, en un equipo que trabaja bajo Scrum, todos en en el equipo trabajan en la misma historia al mismo tiempo. Es decir, todos toman una historia y se reparten trabajo de la misma historia o se enfocan en una tarea a la vez hasta que se completa, para luego pasar a la siguiente tarea, donde todos trabajan juntos en ella; así hasta completar la historia y poder pasar a la próxima. El equipo puede manejar un WIP de 1, todos en una historia y una historia por vez. Esto es particularmente importante y útil cuando un equipo recién comienza, ya sea como equipo o en un producto nuevo.

Mob Programming

Mob programming es una estrategia de programación en la que un equipo de desarrolladores trabajan sobre una única tarea al mismo tiempo, en el mismo ordenador y, sobre todo, colaborando entre ellos. Es decir, todos sentados con una computadora y en lo posible con un monitor grande, pantalla grande o proyector.

La dinámica puede consistir en que uno de los desarrolladores se encargue de liderar o “pilotar” (por 15 min. rotativo) y el resto actúe de “navegadores” o colaboradores. El piloto guía el desarrollo de la tarea, mientras el resto va opinando y dando ideas sobre la mejor forma de afrontar el código: detectando malas prácticas (smells) a tiempo, aportando posibles refactors o consideraciones de calidad y ayudando a que emerja un diseño lo mejor posible.

Puede parecer poco productivo que todo un equipo esté todo el tiempo con una tarea en una computadora, pero no es necesario que sea una práctica constante. Puede ser utilizada, por períodos de tiempo estipulados, para nivelar conocimiento en un equipo, para desarrollos de partes complejas o creativas y para diseños grupales.

Swarming work meeting

El equipo suele tener ceremonias (de Scrum, por ejemplo), reuniones técnicas o de análisis de problemas. Las reuniones en equipo altamente colaborativos, son donde participan todos, de manera equilibrada, usando un único artefacto que posibilite la colaboración (como una pizarra, herramienta de colaboración, lámina canvas, etc.) pueden ser llamadas "swarming work meeting".

El equipo de Dr. House haciendo swarming.

Las herramientas digitales que favorecen el swarming son Google Drive, herramientas de texto por código (como LaTeX, etc), pizarras digitales, herramientas de diseño y diagramación colaborativas, herramientas de votación colaborativas, etc.

Referencias:

• Seven Strategies for Team Swarming, tobeagile.com.
• How Swarming Helps Agile Teams to Deliver, InfoQ.
• Swarming: A Team-based approach to getting work done.
• SKILL SWARMS – A NEW WAY TO SHARE EXPERTISE AND WORK SMARTER TOGETHER.
• Tiered Support Vs Swarming – Which Will Suit You?
• Mob-Programming book by Kevin Meadows and Woody Zuill.

Agile team: El rol Iteration Manager

El rol Iteration Manager

El Iteration Manager (IM) es un Facilitador del Delivery iterativo que vela por que el equipo tenga todas las capacidades para entregar el mejor valor posible. En resumen, es una función dentro de los equipos de desarrollo Agile que se enfoca internamente en el equipo, facilitador de equipo, y en la facilitación del proceso de desarrollo y de entrega. 

Es un rol que algunas empresas usan como abstracción del rol de Scrum Master (de Scrum). El Iteration Manager busca lograr que su equipo logre ser un equipo ágil de alto desempeño y que mejore continuamente. Algunas empresas lo usan como un híbrido de Coach o Scrum Master y Manager (Project Manager).

Origen del término

El término Iteration Manager se originó en 2001 en la oficina de Thoughtworks en Chicago, donde uno de los equipos de Martin Fowler estaba usando eXtreme Programming (XP). El rol del administrador de iteraciones ha aparecido con más frecuencia en el espacio ágil australiano. En Australia se dio cuenta del rol a mediados y finales de la década de 2000 cuando varias organizaciones, incluido Suncorp Group, comenzaron a adoptar Agile. El término también fue manejado en apuntes de PMI para equipos de delivery. En PMI el rol de Scrum Master lo llaman Team Facilitator o Team Lead, pero también han sugerido en algún apunte el uso de Iteration Manager.

Cuando se implementa el rol

El rol no es propio de un marco de trabajo específico sino que es un término ad-hoc, híbrido o producto de sircunstancias particulares en la adopciones de Agile. Algunos escenarios son los siguientes:

• La organización adopta enfoques Agile híbridos (es decir, el uso de elementos de PMI, Scrum, Kanban, XP, etc.) en lugar de usar un marco Agile único como Scrum o un framework puro con su terminología indicada; y en el sorteo o en la elección de nombres gana Iteration Manager.
• La organización tiene Project Manager y consideran que el Project Manager es necesario. Los dos roles están destinados a complementarse entre sí y trabajar en estrecha colaboración o como un único rol: el Iteration Manager.

¿Qué hace un Iteration Manager?

En términos prácticos, los Iteration Managers se aseguran de que su equipo madure en los principios y prácticas Agile. Se aseguran de que el equipo siga correctamente los eventos (reuniones), eliminan los impedimentos y los mantienen enfocados en sus prioridades día a día.

El Iteration Manager se asegura de que se programen, organicen, lleven a cabo y faciliten las siguientes ceremonias ágiles comúnmente utilizadas (ya sea por el Iteration Manager o idealmente por otra persona del equipo):

• Daily Standup (también conocido como Daily Scrum).
• Story Kickoffs. El Story Kick-off es una oportunidad para aclarar cualquier duda o ambigüedad relacionada con la historia y alinear las expectativas de todos los involucrados y el entendimiento del equipo. Esto es una práctica ágil y en Scrum no existe como evento aunque el Product Owner con ayuda del Scrum Master es quien habitualmente hace algo semejante.
• Retrospectivas (retrospective en Scrum).
• Showcases (también conocido como Sprint Review).
• Planificación de Iteración / Lanzamiento (también conocida como Sprint Planning).

Capacita a los miembros del equipo para que sean autosuficientes y organicen todos los eventos (ceremonias o meetings) mencionadas anteriormente.

Se asegura de que se completen todas las acciones de seguimiento resultantes de los eventos del marco de trabajo.

Se asegura, como mínimo, de que se realice la planificación para la Iteración actual y la siguiente (también conocida como Sprint).

Se asegura de que las Historias hayan sido estimadas por el equipo:

• La prioridad es estimar las Historias en la Iteración actual y la siguiente (si aún no se ha hecho).
• Estimar todo el backlog permite la planificación y el reporte de lanzamientos/proyectos (ver más abajo).
• Estas dos actividades se pueden realizar como parte del Refinamiento del Product Backlog (también conocido como Backlog Grooming).
• La estimación puede realizarse de diferentes formas dependiendo de la organización, como Story Points, tamaños de camisetas, Cycle Time, o cualquier enfoque adecuado y acordado.
• Se asegura de que el equipo se enfoque en las prioridades más altas trabajando en estrecha colaboración con el Project Manager y el Product Owner.

Se asegura de que el equipo actualice regularmente el estado de sus tarjetas de Historias (es decir, en qué columna se encuentran) moviendo las tarjetas física y/o electrónicamente.

Se asegura de que las Historias correctas estén en la Iteración acordada (en el Muro de Historias físico y en las herramientas electrónicas como JIRA/Rally/Trello), basándose en las prioridades.

Elimina cualquier impedimento que bloquee el progreso del equipo del proyecto (o lo escalan al Project Manager cuando corresponda).

Con la ayuda del Project Manager y el Product Owner, protege al equipo de distracciones e interferencias externas con la entrega del proyecto.

Capacita a todos los miembros del equipo del proyecto (incluidos el Project Manager y el Product Owner) para que comprendan los valores, principios y prácticas ágiles.

Brinda entrenamiento en autoorganización, multidisciplinariedad y entrega de proyectos/productos.

Instruye qué hacer cuando Agile aún no se ha adoptado y entendido por completo en toda la organización.

Se asegura de actualizar el gráfico Burn down (vista de iteración del progreso) a lo largo de la iteración para mostrar cómo está realizando el seguimiento el equipo

Se asegura de actualizar el gráfico Burn up (versión/vista de progreso del proyecto) al final de cada iteración.

Mantiene constantemente informado al Gerente de Proyecto/Propietario del Producto sobre los impactos en el Alcance y el Tiempo.

Al centrarse internamente en el equipo, el administrador de iteraciones ayuda al equipo a trabajar de la manera más eficaz y eficiente posible. 

Cuida de su equipo para garantizar que pueda cumplir y superar las expectativas y producir valor para la organización. 

El objetivo es ayudar al equipo a ser más ágil.

Hay que recordar que como no es un rol de alguna metodología o guía en particular, las responsabilidades que tenga dependerá de la organización que lo implemente. Estas actividades y responsabilidades mostradas aquí son solo orientativas.

¿Es semejante al Scrum Master?

Como vimos, en gran medida un Iteration Manager hace lo que hace un Scrum Master. Aunque el Scrum Master está atado al framework Scrum. Pero un Iteration Manager estaría atado, conceptualmente, al desarrollo iterativo. O sea que no haría método Kanban, por ejemplo. Un Iteration Manager no solo podría usar metodologías livianas como Scrum y Crystal, sino que también podría implementar metodologías semi-pesadas o híbridas como RUP, Blue Watch o PMI/Scrum (DAD/Scrum).

Algunas personas usan los dos títulos indistintamente. Hay quienes opinan que aunque tienen responsabilidades muy similares, sin embargo, hay una diferencia sutil en la cantidad de entrenamiento que brindan al equipo y al resto de la organización. El Scrum Master es responsable de entrenar al resto de la organización en el proceso Scrum, sin embargo, el Gerente de Iteración generalmente solo se enfoca en el equipo (Ryan McKergow, 2015).

Otros opinan que solo se usa el término Iteration Manager para no usar el de Scrum Master.

Diferencias con el Project Manager

El rol Iteration Manager está pensado para liderar un equipo ágil con foco en el equipo y el desarrollo iterativo (Scrum, Iteration in DAD, etc.), en cambio el Project Manager está pensado para actividades más orientadas a proyectos y organizacionales, para desarrollo predictivo (PMI ed. 6, waterfall, RUP, etc.).

El Project Manager puede tener actividades como las siguientes:

• Planear fuerza de trabajo (workforce) y personal (staffing).
• Controlar y monitorear el financiamiento de proyectos.
• Gestionar la salud y conflictos del equipo o entre equipos.
• Evaluación de personal y crecimiento profesional del personal.
• Gestión organizacional de stakeholders de proyectos.
• Planeación de proyectos con delegación.

Estas actividades no compatibilizan con las de un Iteration Manager. Podrían coincidir si se trata de un rol fusión entre Project Manager y Scrum Master.

Referencias:

• Elabor8: What is an iteration manager.
• When is it time for a dedicated Iteration Manager?
• Iteration Managers and Scrum Masters: The Nurofen to Your Talent Shortage Headache.
• Youtube: Confused between Scrum Master, Iteration Manager, Project Manager roles?
• Scrum.org (Scrum Guide).
• Youtube: Iteration Management - Your Key to Predictable Delivery - Jon Kruger.

Escalamiento: PODAC

Principios PODAC

A la hora de organizar una empresa ágil nos encontramos con algunos interrogantes: ¿Cómo nos podemos organizar y formar equipos? ¿Qué diferentes opciones estructurales tenemos? Si bien tenemos diferentes framework y modelos de escalamiento como: Modelo Spotify, Nexus, Scrum@Scale, SAFe Scaled Agile Framework, Large-Scale Scrum (LeSS) y The Disciplined Agile (DA) Framework, entre otros; tenemos la dificultad de evaluarlos y adaptarlos a nuestra realidad. La mayoría de los framework están pensados para escalar de abajo hacia arriba o como modelo completo de organización. Pienso que en vez de evaluar un marco de escalamiento y elegir uno, es más importante preguntarse: ¿Qué principios de diseño podemos seguir? o sea... ¿Qué principios de diseño organizacional para una empresa ágil nos puede guiar para reestructurar la compañía?Aquí propongo utilizar los principios PODAC (Principles of Organizational Design for an Agile Company):

1. Eficacia sobre eficiencia (outcome sobre output).
2. Negocio y tecnología trabajan juntos.
3. Alineamiento.
4. Control descentralizado.
5. Organizando por valor del cliente. 
6. Basado en equipos orientados por valor.
7. Alta cohesión y bajo acoplamiento.
8. Usar patrones de escalamiento según necesidad.

Modelo Spotify: Guild (Comunidad) o comunidades de prácticas

Las comunidades de prácticas

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. Aunque las comunidades son útiles y pueden usarse al margen del esquema Spotify. 

Una comunidad 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, organizar eventos en pos de la misión, 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, sino que recorre toda la organización. Y se reúnen 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 al menos un líder que sea responsable (pueden ser más de uno). 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. 
• Agendar las citas y reservar salas.
• 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 absorbida 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. Preferentemente es bueno comenzar con alguna lista de temas de interés priorizada, acuerdos de trabajo y herramientas colaborativas a usar.

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 Scrum Masters (o Iteration Managers o semejante): 

• Propósito: Reunir a Facilitadores de Equipos, Iteration Managers y Scrum Masters para capacitarnos y desarrollar mejor el perfil profesional a través de la discusión y el intercambio de conocimientos. Alternamos entre talleres en los que pasamos la hora aprendiendo una habilidad, dinámica o técnica, reuniones regulares donde presentamos lo que hemos estado haciendo y discutimos ideas (sobre métricas, buenas prácticas, calidad, procesos, agilidad, estándares, etc.) para mejorar nuestros procesos de trabajo y empujar 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.
• Agenda: Nos reunimos en la sala desiganad de 16:00 a 17:00 cada martes.
• Herramientas: usamos Trello (Jira, Google Drive, etc.) para administrar nuestro backlog de temas e iniciativas.
• Dinámica: Generalmente se puede usar un formato de Lean Coffee.

Referencias

• Using Guilds.
• A new agile guild.
• Organizarse en equipo al estilo spotify (Guild).
• Guilds: Get Stuff Done Together.

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

Hoy en día, 'Agile' y la agilidad en general se transformó en un movimiento más allá de Ingeniería de Software y área de producción. En este sentido, el Manifiesto Ágil (textualmente) 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.

(video del año 2017)

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

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:

• The aglile mindset - BeanieTech Blog.
• HeartOfAgile by Alistair Cockburn - Blog.
• The Heart of Agile Technical Report by Alistair Cockburn - PDF.  
• AOC Chile 2017.  
• Modern Agile.
• Angel Medinilla, el corazón de la agilidad.

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:

• What is Scrumban? by Savita Pahuja. https://www.agilealliance.org/what-is-scrumban/
• Agile for infrastructure: http://www.solutionsiq.com/agile-for-infrastructure/
• Disciplined Agile Manifesto (http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/spanish/).
• The Scrumban [R] Evolution Getting the Most Out of Agile, Scrum, and Lean Kanban Ajay Reddy, 2016.
• Implementing Scrumban: A short guide to implementing Scrumban at your organization, William Patrick Swisher, 2014. 
• Scrum vs. Kanban vs. Scrumban, Eylean, 2017.
• Youtube: Carlos Iglesias - Peligros y ventajas de Scrumban. CAS 2013.
• [D. A.] Essential Kanban Condensed, Davis J. Anderson, Andy Carmichael, 2016.