Equipo Ágil: Constitución de equipo

La constitución de un equipo o la realización de dinámicas de formación de equipo al inicio de un proyecto o producto o nuevo equipo, son prácticas esenciales en metodologías ágiles y en la gestión de equipos en general. Estas actividades ayudan a sentar las bases para una colaboración efectiva y una configuración inicial para constituir un equipo que se vaya transformando en uno de alto rendimiento.

Algunas dinámicas que sirven a este fin son las siguientes: Rompehielo o team-building, Team Canvas, Team Agreements (Working Agreements), Team Manifesto, Team Purpose, Definition of Done, Definition of Ready y Próximos pasos.

Rompe hielo/team-building

Cada persona responde:

1. ¿Cuales son mis fortalezas para trabajar en este equipo?
2. ¿Cuáles son mis debilidades?
3. ¿Que deben saber los demás para trabajar conmigo?
4. ¿Cuáles son mis expectativas?

Alternativa: se puede usar dinámica de superpoderes:

1. Si fueras un superhéroe o superheroína, ¿Cómo serías? ¿Cuál sería tu nombre de superhéroe o superheroína?
2. ¿Cuál es tu superpoder y por qué?
3. ¿Cuál es tu criptonita y por qué?
4. ¿Te queda algo por decir? ¿Que deben saber los demás para trabajar conmigo?

Otras alternativas: Mapas personales (de Management 3.0).

Team canvas

Se puede utilizar un lienzo de equipo al crear un equipo nuevo o con un equipo existente cuya cohesión se ha perdido. Este ejercicio ayuda a resolver conflictos y ayuda a crear alineación entre los miembros del equipo. De esta manera podrá construir rápidamente una cultura productiva.

La creación de un lienzo de equipo da como resultado un póster en el que se puede ver lo que representa el equipo, quiénes lo integran y qué pueden esperar los miembros del equipo unos de otros.

Propósito del equipo

Como equipo, defiendes algo. Hay una razón por la que existe este equipo, el impacto que se espera de él y lo que te hace querer contribuir a él: el propósito del equipo. Este ejercicio te ayuda a concretarlo y desarrollarlo junto con el equipo.

Con este ejercicio, el equipo crea una declaración de lo que representa y cuál es su valor agregado para la organización. Puede compartir esa afirmación con otras personas de la organización y utilizarla como prueba diaria de si el trabajo que realiza el equipo contribuye al propósito del equipo.

Representamos... [área de enfoque]...

Lo hacemos mediante... [tipo de trabajo]...

Para que... [quién]...

pueda... [beneficiarse del valor/impacto]...

También puede usarse un Elevator Pitch.

Manifesto del equipo (Optativo)

Un manifiesto de equipo es un cartel con los principales acuerdos que ha tomado un equipo sobre actitud y comportamiento. Este ejercicio contribuye a la formación de equipos y fortalece la cultura de equipo.

Un cartel, que se vuelve transparente colocándolo en una pared, con acuerdos dentro de un equipo sobre comportamientos (no)deseados, que se utiliza para establecer expectativas claras entre sí sobre quién quiere ser el equipo. Esto aumenta los vínculos del equipo, evita la confusión causada por expectativas tácitas y ayuda al equipo a crear y fortalecer su cultura de manera explícita.

Acuerdos de Equipo (Working Agreements)

Este ejercicio consta de llegar a acuerdos que son importantes para un equipo. Se busca claridad sobre los acuerdos respecto a horarios, comunicación (canales de comunicación), reuniones, eventos de scrum y cómo el equipo quiere trabajar en conjunto.

Aternativas: Creando un Working Agreement (Scrum.org).

Definition of Done

Para equipos que tienen un flujo de trabajo claro o equipos que practican Scrum o Kanban en desarrollo de software debería definir inicialmente una definición de terminado o hecho. Con una Definición de Hecho (DoD), un equipo crea un entendimiento común de lo que significa estar hecho: que un trabajo esté terminado. El DoD es un conjunto genérico de requisitos que se aplica a todos los elementos de la cartera de productos.

Definition of Ready

Para equipos que tienen un flujo de trabajo claro o equipos que practican Scrum o Kanban en desarrollo de software podría definir inicialmente una definición delisto o Definition of Ready (DoR). Con una DoR, un equipo crea un entendimiento común de lo que significa que una solicitud o requerimiento está lista para poder ser abordada o comprometida para trabajarse. El DoR es un conjunto genérico de requisitos que se aplica a todos los elementos de la cartera de productos.

Próximos pasos.

Referencias:

• https://my-coaching-toolbox.com/tools/team-canvas
• Bendermacher, Charlotte; Kampschuur, Cleo; Kossen, Maarten; van Solingen, Rini. Toolkit for Agile Coaches and Scrum Masters: 99 Creative Exercises and Training Formats.
• https://theteamcanvas.com/ 
• https://www.plays-in-business.com/team-canvas-how-to-create-your-team/ 
• https://dandypeople.com/blog/the-team-canvas-free-download/ 
• https://www.youtube.com/watch?v=CZBYE7RO_48

Agile Team: El rol Agile Team Leader o Líder de Equipo Ágil

Hay diferentes autores que proponen o hablan de "Agile Team Leader" como una idea de líder de equipo ágil más amplia que la figura de Scrum Master o roles semejantes que están atados a un framework en particular.

Por ejemplo Henrik Kniberg habla de "Líder de Equipos Ágiles" en el libro "The Agile Team Leader: A Practical Guide to Building High-Performing Teams", como un profesional que asume el rol de liderazgo en un equipo que trabaja bajo enfoques ágiles, como Scrum o Kanban. Este líder tiene la responsabilidad de guiar al equipo hacia la excelencia, promoviendo los valores y principios ágiles, y facilitando un entorno propicio para el alto rendimiento.

El líder de equipos ágiles no es un líder autoritario o jerárquico tradicional, sino alguien que actúa como un facilitador, un mentor y un defensor del equipo. Su objetivo principal es apoyar a los miembros del equipo en su desarrollo individual y colectivo, fomentando la colaboración, la autonomía y la mejora continua.

Este líder tiene la capacidad de influir en el equipo, pero su enfoque no es dar órdenes o imponer su voluntad, sino más bien empoderar a los miembros del equipo para que tomen decisiones y asuman responsabilidad. También se espera que el líder de equipos ágiles sea un ejemplo de los valores ágiles, como la transparencia, la adaptabilidad y el enfoque en el cliente.

En resumen, para Henrik Kniberg, un líder de equipos ágiles es alguien que dirige y guía al equipo de manera colaborativa y facilitadora, fomentando la autogestión, la innovación y la entrega de valor en un entorno ágil.

Por otro lado, la autora Lyssa Adkins habla de liderazgo ágil de equipos en su libro "Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results". Para ella un líder de equipos ágiles es alguien que se encarga de guiar, empoderar y apoyar a los equipos en la adopción y práctica de metodologías ágiles. Este líder se enfoca en fomentar un entorno de trabajo colaborativo, motivador y de alto rendimiento.

El líder de equipos ágiles es aquel que entiende y abraza los principios y valores ágiles, y los utiliza como base para influir positivamente en el equipo. Tiene la capacidad de inspirar y motivar a los miembros del equipo, ayudándolos a desarrollar su autogestión, toma de decisiones y colaboración efectiva.

Este tipo de líder se enfoca en facilitar la comunicación y la transparencia, promoviendo la confianza y la apertura en el equipo. Además, brinda soporte en la resolución de conflictos y en la gestión del cambio, asegurándose de que el equipo esté alineado con los objetivos del proyecto y de la organización.

Un líder de equipos ágiles también es un facilitador, coach y mentor para el equipo. Ayuda a identificar oportunidades de mejora, impulsa la experimentación y el aprendizaje continuo, y busca formas de optimizar el rendimiento y la productividad del equipo.

En resumen, Lyssa Adkins, un líder de equipos ágiles es aquel que se enfoca en liderar y empoderar a los equipos para que trabajen de manera efectiva, colaborativa y ágil, utilizando las prácticas y principios ágiles como guía para lograr resultados sobresalientes.

Líder de Equipo Ágil versus Agile frameworks

Cada marco de trabajo propone un rol que asume el liderazgo ágil de un equipo. El rol más conocido es el de Scrum Master, aunque también tenemos al Service Delivery Manager en Kanban, por ejemplo.

Si queremos abstraernos de la metodología ágil o marco de trabajo en particular, podemos usar el término Agile Team Leader (o Agile Team Lead). Es una buena opción para no inventar nombres nuevos. Ponerle nombre a los roles parece una tarea no trivial en los contextos de adopción ágil. Esta podría ser una opción.

Referencias:

• The Agile Team Leader: A Practical Guide to Building High-Performing Teams by Henrik Kniberg and Mattias Skarin
• Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results by Lyssa Adkins
• Agile Leadership: The Team-Centric Approach to Software Development by Jeff Patterson

Agile: ¿Cómo sumar Prácticas Ágiles al equipo?

Si tengo un equipo que no desarrolla software... ¿Qué prácticas ágiles podemos comenzar a hacer en el equipo para comenzar a crear hábitos ágiles sin necesidad de comenzar con toda una metodología ágil?

Una manera simple de pensar qué prácticas sumar al equipo puede ser basándonos en 4 claves de la agilidad: equipo colaborativo, entrega continua de valor, adaptación y mejora continua. Pensamos en alguna práctica o técnica que el equipo pueda hacer y que refuerce o apoye alguna de estas 4 claves. Hacemos esto hasta tener un conjunto pequeño de prácticas que abarquen los 4 pilares y comenzamos a practicarlas en el equipo a modo de experimento para luego de un tiempo evaluar cómo nos ha ido y si necesitamos sumar una nueva práctica o sacar alguna existente. Este trabajo de revisar las prácticas justo lo podemos hacer en una práctica propuesta, la retrospectiva.

Ejemplo de Prácticas Ágiles para Equipos No Software

Por ejemplo en una dinámica de este tipo podemos llegar a las siguientes prácticas a probar:

1. Retrospectiva: Reunirse periódicamente para reflexionar sobre cómo se trabajó hasta el momento, ver qué se puede mejorar, qué lecciones se pueden capitalizar para luego decidir cómo aplicar lo que aprendieron en el futuro. 
2. Acuerdos de equipo: El equipo define un acuerdo de trabajo donde determinan cosas como: la fechas y hora de las retrospectivas, tipificación de los ítems de trabajo, horarios de trabajo o de reuniones importantes, uso de tablero, etc. 
3. Tablero de trabajo: El equipo comienza a usar un tablero para reflejar el trabajo actual y la asignación de personas. Puede comenzar con un tablero tipo tabla con las siguientes columnas: Pendiente, En progreso, Terminado. Es bueno que el equipo comience a usar un valor límite de cantidad de ítems que pueden estar en la columna “En progreso” (WIP Limit). De este modo el equipo no se sobrecarga de trabajo y se enfoca en el trabajo que puede hacer según su capacidad. 
4. Trabajar con objetivos: El equipo define 1, 2 o 3 objetivos a corto plazo a cumplir para hacer foco en ellos. Periódicamente los estará evaluando para pivotar o reforzar la dirección y el esfuerzo. Estos objetivos a corto plazo están alineados a algún objetivo más amplio. Podemos sumar bajo esta idea el trabajo con MACRO-HIPÓTESIS, donde una macrohipótesis funcionaría como un objetivo mayor que el equipo quiere cumplir y validar.
5. Trabajo de a pares: Los miembros del equipo trabajarán de a pares por momentos determinados en determinadas actividades o tareas que el equipo decida. También pueden tener “revisión de a pares” antes de terminar un trabajo, actividad o tarea para validar la calidad o efectividad del trabajo. 
6. Priorización frecuente: El equipo comienza a usar alguna técnica de priorización como la Matriz de Eisenhower (importancia vs. urgencia) para seleccionar hacer primero el trabajo que aporta valor. De este modo, todo el trabajo que se encuentre en la columna “En progreso” va a estar priorizado. 
7. Realizar entregas pequeñas: El equipo va a generar entregables pequeños para que sean frecuentes en vez de trabajar por mucho tiempo en un gran entregable final. En vez de trabajar en grandes proyectos y épicas de trabajo, el equipo va a desglosar o particionar el trabajo, en función de objetivos a corto plazo, para poder entregar algo de valor lo más pronto posible y seguir avanzando. 

Referencias: 

https://infodegerencia.blogspot.com/2016/05/matriz-de-eisenhower-priorizar-tareas.html

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.

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.