viernes, 6 de julio de 2018

Retrospectiva: RETRO básica de tres columnas

Retrospectiva o RETROSPECTIVE


Este evento es una oportunidad para que el Scrum Team se inspeccione a sí mismo y cree un plan para mejorar en aquellas áreas que lo necesiten. Por ello se celebra después del Sprint Review y antes del Sprint Planning.

El Scrum Master se asegura que el evento de una duración de máximo 1:30 o 2 horas para sprint de dos semanas, o 3 horas para Sprints de 1 mes de duración, tenga lugar y que los asistentes entiendan su propósito, participando como un miembro más del equipo.

El "propósito de la Retrospectiva es inspeccionar y mejorar". Inspeccionar cómo fue el último Sprint con respecto a personas, relaciones, procesos y herramientas Identificar y ordenar los elementos principales que fueron bien y las posibles mejoras.

Crear un plan para implementar mejoras en la forma en que el Srum Team realiza su trabajo. La tarea de Scrum Master es animar al Scrum Team a mejorar su proceso de desarrollo, buscando prácticas para hacerlo más efectivo y agradable para el próximo Sprint, y a aumentar la calidad del producto al adaptar la definición de “Done” según corresponda.

Al final de la Retro, el Scrum Team debe haber identificado las mejoras a implementar en el próximo Sprint, por ello normalmente se suelen poner 3 columnas, las cosas positivas realizadas que se deben mantener haciendo, las negativas, y las acciones a mejorarlas con un responsable que se ocupe de que se cumplan. Y es que si hay una práctica que el equipo ya está haciendo bien, los beneficios de esta práctica y cómo asegurarse de seguir realizándola o mejorarla se discute también. Estas mejoras pueden haberse detectado e implementado antes, pero la Retro permite una oportunidad formal para enfocarse en la inspección y la adaptación.

Lienzo de RETRO 3 columnas.

Dinámica


Posibles pasos a seguir:
  1. OPENING: Iniciar el evento con una instroducción y los acuerdos de reunión.
  2. REMEMBER: Recordar estado y acciones previas, además de métricas.
  3. BRAINSTORMING: 
    1. Colocar un lienzo y dibujar las tres columnas: carita feliz, cara triste e ideas (como muestra el gráfico).
    2. Dedicar 10 min. a colocar postits sobre qué salió bien en el sprint/iteración.
    3. Dedicar 20 minutos a conversar sobre lo que salió bien. Unificar o superponer postits parecidos.
    4. Dedicar 10 min. a colocar postits sobre qué NO salió del todo bien en el sprint/iteración.
    5. Dedicar 20 minutos a conversar sobre lo que salió mal. Unificar o superponer postits parecidos.
    6. Dedicar 15 min. a colocar postits sobre qué podemos hacer en el próximo sprint/iteración.
  4. ACTIONABLES: 
    1. Dedicar 20/35 minutos a conversar sobre ideas para mejorar. 
    2. Unificar o superponer postits parecidos, priorizar y elegir acciones.
    3. Asignar guardianes responsables del seguimiento de cada acción.
  5. CLOSURE: Concluir la ceremonia. Se puede hacer una ronda de feedback o palabras finales.

Esta retro la he hecho muchas veces porque es una de las más simples y útiles para comenzar la práctica.
Con el equipo Nuevos Negocios de Cencosud 2019. Los buenos equipos buscan mejorar.

¡Con un equipo extraordinario en LATAM 2016!

Referencia:
https://www.holistic-software.com/retrospectives
https://www.saraclip.com/eventos-en-scrum-ii/
7 pasos para una retrospectiva efectiva (Caroli).




lunes, 18 de junio de 2018

Equipo Ágil: Propósito y Lienzo de propósito

Un equipo sin propósito no es un equipo, es un grupo. Y un grupo no es otra cosa que un agregado de personas, no es un sistema. Y un equipo necesita ser un sistema, que tenga objetivos comunes alineados por un propósito de equipo, con identidad y sinergia. Pues, tanto un equipo como una empresa necesitan identidad, tienen que tener un objetivo global o propósito para existir. La razón de por qué hacen lo que hacen.

En general, el propósito es una misión o una meta global general que buscamos alcanzar, que nos representa y nos da una razón de ser. Es el motor motivacional y el factor cohesionador de nuestras acciones. Permite que nuestro comportamiento tenga foco y coherencia con una finalidad.

En un equipo orientado al valor y de larga vida, el trabajo a realizarse debe estar bajo la sombrilla del propósito. Si se desarrolla un proyecto, también debería estar alineado al propósito. Todo lo que no esté alineado al propósito atenta contra el foco y la eficacia del equipo. Ahora bien... ¿Cómo es la redacción de un buen propósito.

Redacción de propósito


La estructura de propósito de un equipo no difiere tanto de la de una empresa o área funcional de una empresa. Veamos algunos ejemplos de propósitos de empresas.


  • 3M: Resolver problemas sin solución de forma innovadora.
  • Cargill: Mejorar el estándar de vida alrededor del mundo.
  • Fannie Mae: Fortalecer el tejido social democratizando continuamente la propiedad de viviendas. 
  • Hewlett-Packard: Hacer contribuciones técnicas para el progreso y el bienestar de la humanidad.
  • Lost Arrow: Ser un modelo y herramienta del cambio social.
  • Pacific Theatres: Proveer un espacio para que prosperen las personas y mejore la comunidad.
  • Mary Kay: Darle oportunidades ilimitadas a las mujeres.
  • McKinsey & Company: Ayudar a que los gobiernos y corporaciones líderes del mundo tengan más éxito.
  • Merck: Proteger y mejorar la vida humana.
  • Nike: Experimentar la emoción de competir, ganar y aplastar a los competidores.
  • Sony: Experimentar la alegría de promover y aplicar la tecnología para el beneficio del público. Telecare Corporation: Ayudar a que las personas con discapacidad mental desarrollen plenamente su potencial.
  • Wal-Mart: Darle la oportunidad a la gente normal de comprar las mismas cosas que la gente rica. 
  • ING: Darle a la gente el poder de mantenerse un paso por delante en la vida y los negocios. Kellogg’s: Alimentar las familias para que puedan prosperar y florecer.
  • IAG: Ayudar a la gente a gestionar riesgos y a recuperarse de las penurias de pérdidas inesperadas. 
  • Walt Disney: Hacer feliz a la gente.


Si bien estos propósito son más amplios y generales, de alto nivel; podemos notar un patrón: se usa el verbo en infinitivo para denotar una acción del "qué es lo que hace". También se observa, en varios casos, a quién va dirigida la acción del "qué hace" para identificar para quién va dirigida o "quién es el cliente" o "quién es el beneficiario de la acción". Y, tal vez lo más importante o motivador, "cuál es el beneficio de la acción".

Estructura de propósito y Purpose Canvas


Entonces, se puede componer un propósito de:

  1. Una acción: acción de "qué es lo que hace" redactada en infinitivo (proporcionar, construir, desarrollar, ayudar, resolver, presentar, facilitar, etc.).
  2. Un cliente o beneficiario: a quién va dirigida la acción o "quién es el beneficiario de la acción".
  3. Una capacidad o competencia asociada a la acción y al "qué es lo que hace".
  4. Un beneficio: el beneficio esperado de la capacidad que recibirá el cliente o "cuál es el beneficio de la acción".

Purpose Canvas o Lienzo de propósito


Ejemplo 1: Veamos un ejemplo con un propósito pedagógico de docentes para el plan de una materia académica:

Ejemplo 2: Propósito de una panadería y pastelería.





lunes, 4 de junio de 2018

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:


lunes, 28 de mayo de 2018

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:



domingo, 6 de mayo de 2018

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.


jueves, 7 de diciembre de 2017

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.




















viernes, 23 de junio de 2017

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