Transición de proyectos en cascada a proyectos ágiles

Contenido
Transición de proyectos en cascada a proyectos ágiles.....................................................................1
Fundamentos de la Gestión Ágil.....................................................................................................1
La gestión de proyectos ágil.......................................................................................................1
El concepto: La selección y el diseño del proyecto.....................................................................7
La especulación: guía el proyecto ágil......................................................................................10
La exploración: gestiona el proceso de creación......................................................................13
La revisión y el cierre: haz ajustes y entrega............................................................................16
Consejos y trucos para la gestión de proyectos ágil.................................................................19

Fundamentos de la Gestión Ágil

La gestión de proyectos ágil
¿Qué es la gestión de proyectos ágil?
La gestión de proyectos Ágil es el proceso de gestionar proyectos desglosándolos en cantidades
pequeñas de trabajo. El distintivo de los proyectos Ágiles es que van aportando a la empresa
pequeñas entregas.

En la metodología tradicional en cascada se documentan los requisitos del proyecto por

adelantado. Después, se completa el diseño de toda la solución. A continuación, tienen lugar las
fases de desarrollo y de pruebas y por último, la etapa de implementación del producto. Si
completar este proceso lleva un año, la empresa no verá ningún valor tangible hasta el final del
proyecto.

Con los proyectos Ágiles se crean unidades de trabajo lógicas y pequeñas llamadas "Iteraciones" o
"Sprints". La técnica Ágil es práctica cuando los proyectos cambian con frecuencia y cuando se
quieren obtener beneficios con más anterioridad. De esta forma, te puede centrar en las
necesidades actuales y si estas cambian, se pueden acomodar en la siguiente iteración.

Es común aplicar la gestión Ágil para gestionar proyectos de IT, pero también es aconsejable para
otro tipo de proyectos. Algunos ejemplos de proyectos no relacionados con IT para los que se
recomienda usar esta metodología son las "Reubicaciones", las "Reorganizaciones de empresa" y
los "Cambios en los procesos de un departamento de la organización." Podrías aplicar la gestión
Ágil con cualquier proyecto en el que los productos se creen e implementen en un período corto y
se puedan ampliar con futuras aptitudes. Al igual que si fuéramos acoplando bloques en los
proyectos Ágiles, se van articulando aptitudes una a una o en pequeños grupos.

Veamos las cualidades de los proyectos Ágiles de éxito. Primero, los "Sprints" o iteraciones suelen
durar de 4 a 12 semanas. Segundo, se fomenta la comunicación cara a cara por encima de la
documentación. Queremos producir un producto, no documentación sobre un producto. Tercero,
los miembros de cada equipo trabajan en la misma ubicación o usan herramientas virtuales para
simular que están juntos. Cuarto, es fundamental tener un patrocinador que esté comprometido
por completo con el proceso Ágil. Y por último, los cambios de requisitos tienen que hacerse con
anticipación y acomodarse correctamente.

Hay otros rasgos para que los proyectos Ágiles funcionen que son comunes con los proyectos
tradicionales, por ejemplo tener una visión del resultado final, seguir un ciclo de vida del proyecto
que todos conozcan, entender los requisitos, tener un calendario compartido, contar con un
equipo centrado en completar el trabajo, y, por último, la comunicación con las partes
involucradas es fundamental. Hoy en día, se usan varios procesos y metodologías Ágiles.

Resumen del ciclo de vida ágil

Los proyectos ágiles se gestionan en cinco etapas que constituyen el ciclo de vida ágil. Son el
"Concepto", la "Especulación", la "Exploración", la "Revisión" y el "Cierre".

- Durante la etapa de Concepto tú y tu cliente determinan qué es lo que intentan crear.

También tienes que determinar quién estará en tu equipo, y los valores y las normas de
equipo que se van a aplicar. En un proyecto ágil, la etapa de Concepto tiene lugar una vez.
Al concluirla deberías tener un acta de proyecto en la que se describen: el alcance, los
objetivos generales y las partes involucradas del proyecto. También deberías haber
establecido las herramientas de colaboración necesarias y, además, las normas de equipo.
Algunos ejemplos de las normas pueden ser las horas laborales y cómo se resolverán las
incidencias que surjan.
- La etapa de Especulación consiste en un ejercicio de planificación. Sí, los proyectos ágiles
necesitan planificación. En la etapa de Especulación, desarrollarás o revisarás el plan de
suministro de las prestaciones, estimarás cada prestación y definirás los riesgos a los que
te puedes enfrentar. Una prestación es una unidad de funcionalidad o un resultado
evaluado por el cliente. En cada Sprint se completan una o más prestaciones. Al final de la
etapa de Especulación, deberías tener una serie de requisitos para el Sprint y una lista de
prestaciones qué desarrollar basadas en esos requisitos. También creas estimaciones para
cada prestación y debes identificar y actualizar los riesgos de las prestaciones en las que
estás trabajando.
- Durante la etapa de Exploración, desarrollas el producto. Las tareas de la etapa de
Exploración incluyen reuniones de seguimiento diarias y las evaluaciones de compañeros
sobre las prestaciones que se han desarrollado. Las evaluaciones ocurren en las
interacciones diarias o frecuentes entre el personal comercial de la empresa y el equipo
técnico y las pruebas frecuentes.
- Ahora que ya se han desarrollado las prestaciones de esta interacción es el momento de
detenerse y reflexionar. Ese es el objetivo de la etapa de Revisión. Un gran beneficio de la
gestión ágil es que obtienes "feedback" de forma frecuente y es fácil recordar qué
funciona y qué no, arreglar las cosas y continuar. Algunas tareas comunes de la etapa de
Revisión son: Una evaluación final del cliente sobre las prestaciones y una reunión
documentada sobre el rendimiento de los miembros del equipo. Partir de este material se
recopila y se comparte lo aprendido y se pueden ajustar los próximos Sprints. La etapa de
revisión se completa de forma muy rápida muchas veces en un día.
 - El proyecto no pasará por las etapas de Especulación, Exploración y Revisión hasta que se
completen todos los Sprints. Cuando se completan todas las iteraciones y están
implementadas las prestaciones, tiene lugar la etapa de Cierre. En ella te aseguras de que
se han completado los productos finales y se han recopilado las lecciones aprendidas.
Ahora que sabes qué debe ocurrir en cada etapa de la gestión ágil, vamos a describir cómo
desarrollar cada una.

La etapa Concepto
La etapa "Concepto" es la primera de las cinco etapas del ciclo de vida ágil de un proyecto y nos
proporciona los fundamentos del proyecto. Al final de esta etapa, deberías tener un acta de un
proyecto documentada que describa el alcance, los objetivos generales y cuáles son las partes
involucradas del proyecto. Las herramientas de colaboración del equipo también deberían estar ya
funcionando y deberías haber establecido las normas de equipo.

El acta de proyecto debería incluir el:

- Alcance del proyecto. El alcance define: los límites generales del proyecto; la visión, que
es una declaración sobre el producto final; el cliente; los beneficios clave y el propósito del
proyecto; cómo ahorrar costos y la ventaja competitiva.
- Identifica al patrocinador del proyecto y las responsabilidades del gestor. Se autoriza el
gestor para cumplir sus responsabilidades y se define el nivel de autoridad que se le
otorga.
- Las herramientas colaborativas son esenciales para asegurar que la comunicación sobre el
proyecto sea sencilla y todos los miembros la comprendan. Estas herramientas sirven para
hacer un seguimiento del estado del proyecto facilitar el desarrollo de las prestaciones y
hacer llegar información a los miembros del equipo. Es importante tener herramientas
fáciles de usar. En el mercado existen muchas opciones.
El tamaño del proyecto el número de partes involucradas y la cantidad de colaboración
deseada determinará lo avanzadas que deberán ser tus herramientas. Te sugiero que
empieces con pocas herramientas sencillas y vayas añadiendo otras a medida que las
vayas necesitando.

En la etapa de concepto todas las partes involucradas empezarán a trabajar juntas para desarrollar
el diseño global del proyecto. En este momento es muy importante establecer normas para el
equipo sobre cómo trabajar conjuntamente, así como dónde trabajará físicamente. Como los
proyectos ágiles implican una colaboración cercana es importante que el equipo entienda cómo
funcionará. Ese es el apartado más importante de las normas del equipo. Algunas normas del
equipo pueden ser:

- Escuchar atentamente lo que dicen los demás. Atacar al problema, no a la persona.

- Buscar la comprensión. Centrarse solo en este "sprint" y esta prestación. Si se ve un
problema, decirlo y sugerir ideas para que se solucione.
- Participar activamente en las reuniones diarias (involucrarse).
- Resolver los conflictos con el otro cuando sea posible. Si no lo es, ambas partes deben
pedir ayuda a los directivos.
- El mail no es el vehículo de comunicación más deseado. No debería usarse para resolver
problemas.
 - No responder a mensajes de texto durante las reuniones.
- Dedicar atención plena a la reunión.
- Ser respetuoso con los compañeros.
- Considerar el proyecto como la prioridad principal.
- Y compartir y respetar los roles y responsabilidades de cada compañero.

Los equipos ágiles son mejores si tienen quince empleados o menos. Es posible tener equipos más
grandes pero te recomiendo que los dividas en subequipos para tener quince miembros o menos.
Los grandes equipos suponen un riesgo, ya que la coordinación de más personas y las prestaciones
que produzcan serán más complicadas. La mayoría de los riesgos de los proyectos ágiles deriva de
tener calendarios de producción de prestaciones demasiado ambiciosos o no tener empleados que
sepan tomar decisiones sin esperar la aprobación de los directivos. Debes evitar estas situaciones.
Con un acta de proyecto documentada las herramientas de colaboración listas para usar y el
equipo definido con pocos elementos de riesgo el proyecto estará bien posicionado para
comenzar la planificación de la primera iteración en la primera etapa de especulación.

La etapa Especulación
En la fase de "Especulación", los equipos comercial y técnico identifican las prestaciones de esa
iteración. Si esta no es la primera iteración deberías revisar las prestaciones anteriores que no
estén completadas. En la etapa de especulación tú y el equipo comercial tienen que tener en
cuenta las nuevas prestaciones. Las prestaciones pendientes y las prestaciones incompletas de la
iteración anterior que se añaden a la lista de pendientes.

Una prestación es similar a un requisito, pero se centra en una necesidad comercial específica.
Una prestación es una función de uncliente expresada en forma: acción o resultado que permite al
usuario satisfacer un objetivo comercial. Para mostrarte lo que quiero decir, aquí tienes unos
ejemplos de prestaciones.

- Calcular los índices de materiales pedidos.

- Mostrar en la factura el nombre y la dirección del comprador.
- Mostrar en la factura el nombre y la dirección de expedición.
- Inscribir a un alumno en un curso.
- Hacer un seguimiento del proceso de término del curso.

En el enfoque ágil lo más común es hacer una ficha o una nota adhesiva con cada prestación. Con
papel, puedes mover la otra categoría o volver atrás y organizar y priorizar más fácilmente. En
proyectos más grandes las herramientas de colaboración ágiles pueden simular la técnica del
fichero.

Cuando tengas una serie de prestaciones, organízalas en grupos de forma lógica. Los equipos
comercial y técnico las deberán revisar y priorizar. Durante este proceso, las partes involucradas
hacen preguntas sobre las prestaciones y añaden algunas nuevas. Valorar prestaciones adicionales
es útil y es una parte del proceso ágil así como priorizar todas esas ideas. Si tu proyecto es como la
mayoría dejarás algunas prestaciones para otro proyecto por no disponer de tiempo o dinero.
Cuando tengas una lista de prestaciones priorizada y la parte comercial y el patrocinador estén de
acuerdo, puedes continuar. Tienes que revisar la lista de prestaciones al principio de cada
iteración; así que solo has acabado por ahora.
Ahora que las prestaciones ya están acordadas, tendrás que estimar el trabajo necesario para
completar cada una. Si esta es tu primera iteración tendrás que hacer cálculos para todas las
prestaciones. Trabaja con los miembros del grupo y expertos en la materia para obtener cálculos
precisos. Al acabar, puedes crear tu plan de iteraciones, hitos y lanzamiento. Este plan, menciona
todas las prestaciones ¿cuándo se completarán? ¿y cuándo se implementarán? La etapa de
especulación no lleva mucho tiempo. Por ejemplo; si tu iteración consta de 8 semanas en total a la
etapa de especulación sólo le dedicarás alrededor de 5 días. Sin embargo, en cualquier proyecto
ágil la primera iteración de la etapa de especulación llevará más tiempo, ya que tienes que
identificar y estimar las prestaciones de todo el proyecto, no solo de la primera iteración. La etapa
de especulación consiste en planificar detenidamente cada iteración y re priorizar nuevas
prestaciones. Esta planificación te ayuda a que la siguiente etapa de exploración sea más clara.

La etapa Exploración
Ahora podemos producir el producto. Por suerte, con la gestión ágil no lleva mucho tiempo pasar
de las etapas de concepto y especulación a la de exploración. Esta etapa consiste en una
colaboración entre los equipos comercial y técnico. Las reuniones de seguimiento diarias que se
celebran en todas las etapas del proyecto, juegan un papel sustancial en la de exploración. Vamos
a ver cómo suelen ser estas reuniones. la reunión debería durar 15 minutos, 30 como máximo.
Cada miembro expone lo que consiguió ayer y lo que planea conseguir hoy. Después habla sobre
lo que necesita para continuar su trabajo. La reunión de seguimiento no es el momento de
resolver problemas. Si se identifica alguno, se anota y se aborda después de la reunión. Al día
siguiente, se informa al grupo sobre él. No hay nada que documentar, a no ser que haya algo que
quieras introducir en el registro de problemas para extraer algo aprendido.

¿Qué hace el gestor de proyecto en estas reuniones? El gestor de proyecto cumple un papel
observador y deja que sea el equipo el que dirige la reunión. El gestor del proyecto está pendiente
de los problemas que no se han resuelto y elimina dificultades. También debería confirmar que los
riesgos van disminuyendo con el tiempo. Después de la reunión, comunica el estado a las partes
involucradas para que estén informadas del progreso. En las reuniones, escucha detenidamente.
Tu tarea durante la etapa de exploración es proteger la productividad de cada miembro del equipo
y que se centre en continuar, gracias a la eliminación de distracciones que pueden ralentizarlo. Las
reuniones de seguimiento te ayudan a comprender cómo hacerlo teniendo una visión de lo que
hace el equipo diariamente. También te da las bases para mantener el control del proyecto. Tu
mecanismo de control es hacer un seguimiento del progreso de las prestacioness del plan de ese
"sprint". Las prestaciones ya completadas se anotan en las reuniones, así como en un tablón de
prestaciones localizado en la oficina del equipo, para que pueda ver el progreso que está
consiguiendo. Si las prestaciones van con retraso, tienes que descubrir por qué. Has ajustes tan
pronto como sea posible y toma notas para extraer conclusiones y aplicarlas.

Al igual que con los proyectos no ágiles, es necesario mantener un registro de problemas. Es
importante que los problemas se resuelvan de forma oportuna. El registro de problemas te ayuda
a determinar si el número de problemas abiertos aumenta. Esto podría ser un indicativo de que
algo falla y que se debería valorar si implementar cambios.

Es fácil que los equipos estén tan inmersos en crear el producto, que se les escape el tiempo. Es
esencial hacer un seguimiento de la puntualidad y un calendario del "sprint". Termina la fase de
exploración cuando se hayan completado las prestaciones del "sprint" o cuando se haya
consumido el tiempo programado para esa etapa de exploración. Es fundamental que, bajo una de
estas condiciones, des la etapa por finalizada. Si planeas que la etapa de exploración dure siete
semanas y no se han completado las prestaciones, detén la fase de acuerdo a tu calendario y
procede a empezar la fase de revisión. Recopila las lecciones aprendidas. Asegúrate de que todos
los miembros las entiendan y cambia o ajusta las expectativas con las partes involucradas. Este es
el propósito de la etapa de revisión que sigue a la etapa de exploración.

Las etapas Revisión y Cierre

La fase de revisión ocurre al final de cada "sprint" inmediatamente después de la fase de
exploración. En cada fase de revisión, tendrás que repasar con el equipo lo que se ha entregado y
compararlo con lo que se había planeado para ese "sprint". Dialogar sobre qué funciona y qué no.
Y acordar cualquier cambio que haya que aplicar. También es astuto revisar las lecciones
aprendidas de la etapa anterior para ver si se percibe alguna tendencia. La etapa de revisión es la
ocasión de analizar el producto con el cliente y confirmar si las prestaciones están funcionando
según lo esperado y determinar si ha cambiado algo que reduzca o cambie la eficacia de las
prestaciones. Dedica un tiempo a verificar si se están produciendo los beneficios que se
pretendían.

Es fundamental que inicies un debate sobre las lecciones aprendidas en cada etapa de revisión
para que se comparta "feedback" de forma abierta. Cualquier opinión es útil y debería tenerse en
cuenta. Pueden hacer una tormenta de ideas para resolver problemas y eliminar dificultades
potenciales para el éxito del equipo. A partir de estas sesiones de "feedback" encontrarás
bastantes ajustes que aplicar. Algunos ejemplos son

- Añadir o eliminar prestaciones.

- Ajustar los cálculos o repriorizar las prestaciones en la lista.
- Modificar el horario de las reuniones diarias para maximizar la efectividad.
- Cambiar a los empleados en función de las necesidades del proyecto la disponibilidad y la
efectividad del equipo.
- Modificar o eliminar procesos que no sean efectivos
- Añadir procesos, pero solo si son esenciales para el progreso del proyecto.

Es importante que todas las partes involucradas conozcan los cambios que se aplicarán en los
próximos "sprints" y los cambios que se están haciendo.

Si el equipo ha tenido muchas dificultades este es el momento perfecto para celebrar los éxitos de
los "sprints" anteriores y dar a conocer los logros. Algunos empleados pueden necesitar una pausa
mental antes de empezar a trabajar en el siguiente "sprint". Como gestor de proyecto tendrás que
asegurarte de que el equipo está preparado para el siguiente "sprint" y de que la moral es positiva
y todos pueden continuar. En un proyecto más amplio te sugiero que ocasionalmente des un
"sprint" libre para que los trabajadores completen otras tareas o se lo tomen de vacaciones. Esto
hará que vuelvan al proyecto revitalizados.

Asumiendo que este no es el final del proyecto al completar la fase de revisión pasarás a la fase de
especulación del siguiente "sprint". Recuerda, si se ha consumido el presupuesto o el calendario
acordado es el momento de dar por terminado el proyecto y pasar a la etapa de cierre. Si este es
el último "sprint", el proyecto está listo para concluirse. Ahora empezará la etapa de cierre.

Algunos ejemplos de actividades administrativas de la etapa de cierre son:

- Confirmar que se han realizado los pagos y que los proveedores los han recibido. Conciliar
las finanzas del proyecto.
- Trabajar con los gestores y los miembros de otros equipos para reubicar a los empleados
en otros proyectos y tareas.
- Comunicar los resultados del proyecto a los miembros del equipo y a otras partes
involucradas.

Ahora es el momento de hacer alabanzas. Siguiente, confirmar que los beneficios siguen estando
monitorizados y se sigue cumpliendo. Es importante trasladar estas supervisión al cliente. Y, por
último si la gestión de proyectos ágil es nueva en tu empresa ofrece una recapitulación de por qué
ha funcionado y qué han aprendido. Deberías oponerte a la tentación de saltarte o acortar las
actividades de la etapa de cierre. El cierre es importante para que el proyecto no se detenga
innecesariamente. También ofrece la oportunidad de apreciar el significado de lo que se ha
conseguido.

El concepto: La selección y el diseño del proyecto

Selecciona un proyecto ágil
Uno de los principales factores de éxito es la selección del proyecto al que aplicar los métodos
ágiles. Los buenos candidatos para proyectos ágiles comparten las siguientes características.

- Primero, tienes que entregar un producto de calidad rápido pero no todo a la vez.
- Segundo, esperas que los requisitos cambien o evolucionen.
- Tercero, tu organización está dispuesta a ofrecer empleados capacitados que de forma
autónoma puedan tomar decisiones sobre el producto que se va a producir.
- Y por último, crees que el producto puede hacer que el valor comercial aumente.

Vamos a ver un ejemplo de proyecto ágil y de un proyecto no ágil. Digamos que quieres
implementar un sistema de información ejecutiva. Tienes un presupuesto acordado. Ejecutivos
interesados: siete. Cada uno con necesidades muy distintas. Quieren tener el producto cuanto
antes mejor. Quieren que el proyecto esté completado antes de que acabe el año. Este proyecto
es ágil con todas las letras. Los requisitos cambiarán sin lugar a dudas y evolucionarán cuando los
ejecutivos empiecen a ver más posibilidades. El proyecto se desglosa en sprints fácilmente y
puedes categorizar e implementar prestaciones para cada ejecutivo.

Veamos otro ejemplo. Tienes que actualizar un proceso comercial y sustituir los procesos
administrativos con otros más actualizados para cumplir la demanda del cliente. Esto es algo que
tu empresa hace cada tres o cuatro años con una serie de pasos y procesos que seguir. El
presupuesto ya está acordado. Hay que completar el alcance y conoces las áreas y el número de
procesos que hay que actualizar. Este no es un buen candidato para la gestión ágil. No hay motivos
para establecer sprints y preguntar si se requieren nuevas prestaciones al final de cada sprint. El
proyecto ya se ha completado en el pasado con otros métodos. Funcionó y ya todos están
acostumbrados a hacerlo así. ¿Este proyecto podría implementarse en iteraciones similares a los
sprints? Sí, pero hacer iteraciones a algo no lo convierte en un proyecto ágil. El ciclo de vida del
proyecto a veces se llama iterativo y puede ser una forma astuta de gestionar un proyecto.
También sabemos que todos los procesos tienen que ser actualizados. Entonces no conviene
desglosar el proyecto y permitir que solo algunos de los procesos se actualicen en base a un
calendario preestablecido que podría ocurrir con un proyecto ágil. Lo mejor es aplicar un enfoque
más tradicional que ya funcionara en el pasado.

No todos los proyectos tienen que implementarse como un proyecto ágil o uno no ágil. Es posible
crear un híbrido entre ambos. Por ejemplo, para la presentación de una nueva línea de productos
de un negocio ya existente. Se podrían usar técnicas ágiles para desarrollar nuevos productos de
marketing y tener tantos como sea posible en la fecha de entrega del producto. Y usaría un ciclo
de vida más tradicional para la reorganización de empleados en el nuevo departamento de
producto. Ya que hay que evaluar a cada uno se le tienen que cambiar las responsabilidades y
crear un nuevo trabajo. Yo aplicaría primero los cambios de personal a un área determinada y
después, los cambios del proceso los haría una nueva plantilla reasignada. Usar la gestión ágil para
los cambios de procesos obliga a que la empresa priorice el trabajo e implemente primero las
prestaciones más importantes y los cambios del proceso. Para reubicar a los trabajadores es mejor
un enfoque más tradicional.

En resumen, los proyectos ágiles pueden aplicarse en distintas situaciones e implementarse de

formas distintas. Todo depende del proyecto y la organización en la que estés trabajando y si las
características ágiles son la mejor forma de crear cambio para tu cliente.

El alcance del proyecto

En la etapa de concepto, creaste el acta del proyecto que describe la visión del cliente y los límites
del proyecto. Después viene la creación de la ficha técnica del proyecto. Es un documento de
planificación que proporciona un resumen del proyecto. Una ficha técnica bien redactada nos da
detalles sobre el alcance del proyecto y es una buena herramienta de comunicación y fácil de usar.
La ficha técnica se suele crear durante la fase de "Concepto" anterior al primer "Sprint". Es breve y
concisa: suele tener de dos a tres páginas. En ella se describen el proyecto y el alcance a nivel
global que se suelen extraer del acta de proyecto junto con los objetivos y el valor comercial que
va a tener. También debería detallar el cronograma con los hitos, la estimación de los costos del
tiempo de los empleados y de otros puntos que puedas necesitar. Por último, incluye las
restricciones o limitaciones y la priorización entre el alcance del proyecto, los recursos, el
calendario y el nivel de calidad necesario. Vamos a ver los dos últimos puntos: Las restricciones y
la priorización que son fundamentales para definir tu proyecto ágil.

Una restricción es una limitación de la libertad que tienes para crear la solución del proyecto. Las
restricciones pueden ser ambientales, de seguridad, económicas técnicas o políticas y atañen al
calendario de tu proyecto los miembros del equipo o el producto que se está creando. Algunos
ejemplos de restricciones son: El proyecto tiene que estar completado a finales de esta fecha. Se
deben seguir ciertas normas técnicas, como códigos de seguridad eléctrica. Otra restricción es
delimitar cuándo se puede implementar o no el producto. Un ejemplo es evitar las horas pico.
Sería arriesgado cambiar un software de la caja registradora de una tienda en época de Navidad.
Las restricciones también atañen a tu equipo como la disponibilidad de empleados concretos solo
en unos períodos determinados. También puedes tener algunas especificaciones como usar una
infraestructura o un equipo existentes y que el presupuesto no exceda a "x" dólares.

Equilibrar las restricciones del proyecto dependerá de la priorización del alcance los empleados y
otros recursos, el calendario y la calidad. Vamos a ver un ejemplo para describir esto. Si el
calendario es la máxima prioridad, la gestión ágil te permite aplicar flexibilidad al alcance y los
empleados. Podrías reducir el número de prestaciones de un "Sprint" o aumentar el número de
empleados para asegurar que el "Sprint" se completa a tiempo. Si la calidad del producto es la
prioridad más baja, tendrás una mayor flexibilidad para centrarte en el calendario y corregir
cualquier defecto en los "Sprints" siguientes.

El cliente y el equipo deberían participar en la creación de la ficha técnica del proyecto. El cliente
debería revisar toda la ficha para confirmar la exactitud describir los beneficios y confirmar los
recursos que se proporcionarán. Los proyectos ágiles son conocidos por su planificación mínima
pero vital y eso es bueno, probablemente la ficha técnica sea el documento más detallado de la
gestión ágil y es fundamental para que el proyecto tenga éxito. Si te opones a la tentación de
introducirte en el primer "Sprint" y dedicas tiempo a crear la ficha técnica y la compartes con las
partes involucradas seguro que tu proyecto transcurrirá sin sobresaltos.

Diseña tú estructura sprint

La mayoría de los sprints suele durar de 4 a 12 semanas, esta duración comprende las etapas de
especulación, exploración y revisión. Determinar la duración de tus sprints y el número de
prestaciones que intentarás desarrollar durante cada uno, recibe el nombre de "Estructura
sprint", debes crear una estrucutra sprint apropiada para tu proyecto específico.

Vamos a ver algunos consejos para que determines tu estructura sprint. Como punto de partida,
planea una semana para la especulación y una para la revisión. Con el tiempo descubrirás lo que
puedes conseguir en esas franjas de tiempo y ajustarlas según sea necesario. Una excepción es la
etapa de especulación del primer sprint, ya que tendrás que hacer la planificación de todo el
proyecto y no solo de un sprint, así que añade algunos días. Para determinar la mejor estructura
sprint, tienes que completar una lista de prestaciones que hay que desarrollar junto con su
tamaño estimado, después, crea una agrupación lógica para las prestaciones para que puedas
evaluar el tamaño de los sprints que quieras usar. Puedes agrupar las prestaciones según la
prioridad comercial, los técnicos disponibles para el sprint, los recursos disponibles para un sprint
o según el área de negocio, porque a veces es más fácil desarrollar prestaciones para un área en
un sprint determinado. No tienes que detallar el tamaño para las prestaciones, es suficiente con
poner "Grande, Medio, Pequeño" y tener un número estimado de horas para cada categoría. Por
ejemplo, a una prestación grande se le asignan 80 horas, a una media 40 horas, y a una pequeña
20 horas. Cuando las estimaciones se van definiendo durante la fase de especulación puedes ir
ajustándolas en función del número de empleados en el equipo y en función de las prestaciones
que quieras desarrollar en cada sprint, puedes determinar el mejor tamaño de tus sprints. Elije
uno y mantenlo, establece la misma duración para todos los sprints, así el equipo se organizará
con ritmo y se ha demostrado que esto es más productivo.

Un ejemplo, digamos que tu proyecto durará 6 meses y que consumes 1 en la fase de concepto,
ahora te quedan 5 para el resto del proyecto, basándote en el tamaño y al agrupar las
prestaciones, decides hacer 3 sprints de 7 semanas cada uno. De esas 7 semanas, tienes 5 para
realizar el trabajo. La etapa de exploración, en función de los cálculos y recursos disponibles, ahora
podrás confirmar las prestaciones que puedas desarrollar en cada sprint, si no concuerda con las
prestaciones que quieres desarrollar en un sprint, puedes ajustar la duración y el número de
sprints. Te aconsejo que desarrolles las prestaciones de mayor prioridad en el primer sprint,
asumiendo que cuentas con los registros técnicos y comerciales disponibles para cumplirlas. Otro
consejo, muchos equipos trabajan mejor con sprints pequeños y centrados, prueba si con tu
equipo funciona así. Durante el primer sprint prueba cosas y ve haciendo ajustes, puedes
aumentar o disminuir las prestaciones planeadas para un sprint para que todo vaya mejor, solo
tienes que recordar que la duración global de los sprints y del proyecto deberían mantenerse.

Define cómo gestionarás los riesgos

Al igual que en los proyectos tradicionales, en el entorno ágil se deberían asignar y evaluar los
riesgos de las tareas de tu plan o de las prestaciones.

En la gestión ágil, otra forma de gestionar riesgos es mediante las prestaciones que asignas a cada
Sprint. Si tienes un equipo que es nuevo en la gestión ágil puedes reducir el riesgo del proyecto,
haciendo que los primeros Sprints sean más fáciles, por ejemplo, digamos que has planeado 50
prestaciones para los seis primeros Sprints y que tendrás un producto listo para la implementación
a finales del tercer Sprint. En este caso lo mejor es que el primer Sprint tenga menos riesgo y se
trabajen con prestaciones menos complejas. Asumiendo que el primer Sprint fue bien en el
segundo ya puedes trabajar con algunas más difíciles. Si tu equipo necesita más práctica en
entornos ágiles deja las prestaciones más sencillas. En este ejemplo, las prestaciones que
requieren mucha comunicación entre departamentos, capacidades técnicas avanzadas o son
complicadas de producir, deberían moverse al siguiente Sprint. Esta distribución de prestaciones
en Sprints reduce el riesgo del proyecto porque es una oportunidad para que el equipo se
acostumbre a trabajar con las técnicas ágiles y trabaje de forma colaborativa y desarrolle su
confianza.

Ahora, supongamos que tienes el mismo caso, 50 prestaciones que completar en 6 Sprints, sin
embargo, esta vez tienes trabajadores con experiencia en la gestión ágil y ya han colaborado
juntos en el pasado, en este caso lo mejor para reducir el riesgo es desarrollar las prestaciones
más complejas en el primer Sprint, puedes completar primero las prestaciones más difíciles para
saber a qué te enfrentas en el proyecto como conjunto; también puedes aprender de las
dificultades que tengas y eso te debería ayudar a evitar sorpresas en próximos Sprints. Tu gestión
del riesgo, debe variar en función de la experiencia del equipo o tu empresa con los proyectos
ágiles.

Otra forma de gestionar el riesgo es ajustar el número de prestaciones que intentas producir en
cada Sprint. Para que un equipo trabaje a buen ritmo y sea completamente productivo hacen falta
dos o tres Sprints. Esto ocurre incluso en los equipos que tienen algún empleado con experiencia
en la gestión ágil; todo el equipo necesita tiempo para aprender a trabajar conjuntamente,
dependiendo de esto deberías reducir la cantidad de prestaciones que completar en los primeros
Sprints hasta que el equipo sea productivo al 100 %. Y por último, deberías centrarte siempre en
los riesgos empresariales específicos. Si no se suele usar la técnica ágil y recibir un producto en
muchas implementaciones, es algo a lo que se tienen que acostumbrar. Al crear un plan de
lanzamiento e intentar mitigar los riesgos tendrás que trabajar con el equipo comercial para
determinar la mejor secuencia para implementar un conjunto de prestaciones dadas. El impacto
comercial es algo fundamental que hay que tener en cuenta. Puede cambiar la prioridad de la lista
de prestaciones. A veces el conjunto de prestaciones prioritarias para el negocio también puede
implicar el mayor cambio y el mayor riesgo. Puede ser astuto mover esas prestaciones a los
siguientes Sprints para que el negocio tenga tiempo de acostumbrarse, implementando primero,
prestaciones básicas y sencillas, después, puedes crear e implementar prestaciones que impacten
en varios departamentos o que impliquen un mayor cambio en cómo funciona la empresa.

La especulación: guía el proyecto ágil

Recopila los requisitos de los proyectos agiles
Los proyectos ágiles están diseñados para acomodar el cambio. Saber identificar y documentar los
requisitos de un proyecto ágil, basándose en las necesidades es un ingrediente clave.

En la fase de especulación, hablamos sobre el uso de fichas para documentar las prestaciones.
Veamos otros enfoques y técnicas para documentar las prestaciones y los requisitos. Una buena
técnica es tener un analista que vaya uno o dos "sprints" por delante del equipo de desarrollo.
Cuando el equipo principal complete un "sprint", el analista debería confirmar que las
prestaciones del siguiente "sprint" son las adecuadas. Además, si han cambiado las necesidades
comerciales, el analista puede trabajar para definir nuevas prestaciones o identificar prestaciones
existentes que ya no se necesitan. Existen varias técnicas para identificar los requisitos.

- Una técnica común es utilizar casos de uso. Los casos de uso capturan un diagrama o
imagen para mostrar la relación entre un actor y el sistema o el proceso para conseguir
una meta específica. Un actor puede ser un empleado, una empresa u organización, un
departamento, un software o un sistema informático, cualquier entidad que pueda tomar
una decisión. Los casos de uso se pueden usar para documentar los requisitos de los
proyectos de IT y los que no se relacionen con IT. Aquí tienes un ejemplo de un caso de
uso global. Los componentes clave son: el actor que realiza la acción, por ejemplo, ir a un
cajero automático; el sistema o el proceso con el que el actor interactúa, como el cajero
automático; la caja que representa los límites del requisito, cualquier cosa que esté fuera
de la caja está fuera del alcance. Lo que hay en el interior de la caja indica los tipos de
acciones que el actor puede realizar con el sistema, como hacer un depósito, comprobar el
saldo o retirar dinero. El exterior de la caja muestra los actores que pueden interactuar
con el sistema, como alguien de mantenimiento, el directivo que recibe la información
extraída e incluso un ladrón. El texto de los casos de uso también puede servir para
describir con detalle la situación. Los casos de uso hacen que las partes involucradas
imaginen todas las formas en las que un requisito aborde las necesidades comerciales
mediante las prestaciones.
- Otra forma de recopilar requisitos es la tarjeta de rendimiento del requisito. Es similar a
la tarjeta de la prestación, pero describe un requisito que se aplica a varias prestaciones.
Por ejemplo, tu departamento de contabilidad quizás tiene un requisito de rendimiento
para la cantidad de tiempo permitida para procesar una factura entrante. Para la
asistencia técnica, el requisito podría ser "Todas las llamadas se responderán en x
minutos". Lo que ves en pantalla es un ejemplo de tarjeta de rendimiento. Cada requisito
tendrá que tener una identificación única, un nombre o título y una breve descripción.
Además, puedes introducir el factor de dificultad que ayudará a que se prioricen los
 requisitos contrastándolos con otros requisitos y prestaciones. Y, por último, la sección de
la aprobación de la tarjeta describe cómo verificar que el requisito se ha conseguido una
vez que ya se ha desarrollado el producto. Documentar los requisitos es esencial en
cualquier proyecto. En tu proyecto ágil, los requisitos continuarán evolucionando. Con el
analista, estarás listo para cada "sprint", gracias a la información que te hará llegar sobre
prestaciones y requisitos.

Cómo estructurar y celebrar las reuniones de seguimiento

Las reuniones diarias de seguimiento son el motor de un proyecto ágil. Son cruciales para que el
proyecto tenga éxito ya que en ellas se comparte información crítica y se eliminan los obstáculos.
Se recomienda que duren 15 minutos deberían ser concisas, claras y directas. Lo mejor es que los
asistentes estén de pie, de esta forma la reunión es breve, animada y activa. Deberían asistir todos
los miembros del equipo técnico especialista junto con el gestor del proyecto, a veces llamado
"Scrum Master". La idea es que el gestor no dirija la reunión, serán los miembros del equipo los
que hagan la actualización de estado en una secuencia distinta cada día. Hacer que roten añade
energía a las reuniones. Asigna a alguien del equipo que controle el tiempo para que el equipo se
centre. Puede que esto solo sea necesario hasta que todos se habitúen al formato diario, 30 o 60
segundos por persona deberían ser suficientes. El controlador del tiempo debería rotar en cada
sprint.

El hábito que más cuesta romper es no resolver problemas durante la reunión, lidia con los
problemas después, asegurándote que solo sean parte del debate los miembros pertinentes.
Celebra las reuniones todos los días a la misma hora la regularidad es muy importante. Aquí tienes
algunos puntos que observar durante las reuniones diarias. ¿El equipo colabora o hay tensión en el
ambiente? ¿Aparecen riesgos que podrían afectar a los siguientes sprints? ¿Hay algún problema
común que puedas ayudar a resolver? Después de la reunión, por supuesto. ¿La lista de problemas
va creciendo? Si el concepto "ágil" es nuevo para el equipo, ¿hay algún empleado que tenga
problemas con este proceso? Como ves, si prestas atención, hay mucha información que obtener
de las reuniones de seguimiento. Mantente alerta y actúa cuando sea necesario.

Te aconsejo que siempre acabes la reunión con una observación positiva. Comparte con el equipo
los logros que se hayan conseguido desde la última reunión. Por ejemplo, ¿a los comerciales les
gustó lo que vieron en la evaluación del producto? ¿El equipo técnico solucionó un gran problema
y está orgulloso? Qué los empleados compartan sus logros deja ver al equipo que se hacen
progresos y genera se hace un impulso positivo.

Si tienes un pequeño equipo en la misma ubicación, y todos colaboran todos los días, puede que
las reuniones diarias tengan menos sentido ya que todos saben lo que se va a compartir, en este
caso, podrías celebrar reuniones con menos frecuencia, quizás dos o tres veces por semana para
que se vea que se está haciendo un progreso y para ver cómo va el equipo. Semanalmente, invita
a la reunión a las partes involucradas. Por ejemplo, los gestores comerciales, los gestores del
equipo técnico, y algunos usuarios del producto que no sean parte del equipo principal, les podría
ayudar saber cómo va el proyecto y qué está haciendo cada uno, cuanta más gente haya
involucrada, mejor. Te aconsejo que al final de la reunión, dejes 5 minutos para que los nuevos
asistentes hagan preguntas, es increíble lo valiosas que son las reuniones de 15 minutos, haz tus
reuniones de seguimiento centradas y fructuosas.
Controla y ajusta el plan en la gestión
Muchas personas que no entienden la gestión Ágil, creen que los proyectos Ágiles no tienen
mecanismos de control, nada más lejos de la realidad. Existen técnicas específicas para gestionar y
supervisar tus proyectos Ágiles.

El alcance se gestiona en la lista de pendientes y se controla completando prestaciones para

reducir la lista y añadiendo prestaciones según se vayan identificando. El equipo comercial en
conjunto con el técnico, re-priorizan las prestaciones para determinar cuáles se implementarán en
el próximo Sprint. Es común hacer cambios en la lista, pero recuerda que el Sprint actual debería
estar siempre bloqueado. Cuando se haya acordado la lista de prestaciones de ese Sprint, no
debería cambiarse.

La velocidad es el término que se usa para describir cuántas funciones está completando el
equipo en un Sprint común. Esto puede calcularse examinando los Sprints anteriores, suponiendo
que los recursos y la duración de los Sprints son los mismos. Si conoces la velocidad media, puedes
determinar si tu Sprint actual cumple esa media. Si el progreso no es como esperabas, tendrás que
profundizar para determinar por qué la media de la velocidad está disminuyendo. Si la media de
velocidad tiene que ajustarse para los siguientes Sprints, tendrás que re-planear y reducir el
número de prestaciones que completar en el siguiente Sprint. El beneficio de la velocidad es que
te permite conocer cuál es tu índice de producción y en función de este, puedes ajustar tu plan de
lanzamiento a los recursos del equipo.

En la gestión Ágil, el "Burndown Chart" o "Gráfico de trabajo pendiente", es una herramienta de

comunicación que se usa para mostrar el trabajo que queda por completar. Este gráfico compara
las prestaciones y el tiempo esperado para completarlas, En el eje "X" se representa la línea de
tiempo y en el eje "Y" se presenta el trabajo que hay que completar en ese proyecto o Sprint, el
tiempo estimado para el trabajo pendiente se presentará en ese eje. La fecha de inicio es el punto
extremo de la izquierda del gráfico, el final del proyecto es el punto más lejano que esté a la
derecha, y ocurre en el último día del proyecto o el último Sprint programado. En el punto de
inicio del trabajo pendiente actual, está la cantidad de trabajo pendiente. Cuando el tiempo
progresa, la línea del trabajo completado actual, en este caso, marcada en rojo, puede
contrastarse con la línea del plan general de Sprints aquí en amarillo. Entonces puedes ver si vas
según lo previsto o con retraso. Después puedes ajustar las prestaciones para completar cada
Sprint, extender el tiempo y el costo o re-planear las prestaciones que vas a producir para alinear
el plan a tu capacidad de producir prestaciones. El gráfico del trabajo pendiente muestra
claramente si se están completando las prestaciones del proyecto según lo previsto o no, y cuándo
se completarán. La clave es usar esta información para monitorizar el progreso, para que puedas
hacer ajustes, si son necesarios, para maximizar la productividad del equipo. Si usas estas técnicas
de control, podrás manejar bien el progreso de tus proyectos Ágiles.
La exploración: gestiona el proceso de creación
Controla sin interferir con la creación de las prestaciones
La etapa de exploración del ciclo de vida de un proyecto ágil es distinta a las etapas de los ciclos de
vida no ágiles. Tu papel como gestor de proyecto es observar y guiar y no dirigir. En el proceso eres
expectador y diriges mediante el asesoramiento. Este puede ser uno de los ajustes que más
cuestan a los gestores de los proyectos tradicionales tienes que dejar de controlar tanto. Esto
resulta difícil. En vez de buscar el control, tu papel es eliminar obstáculos para el equipo. Puedes
hacerlo escuchando atentamente durante las reuniones de seguimiento para identificar
problemas. Después de la reunión, actúa para ponerte al día con los empleados y que las cosas
avancen. Esto hace que el equipo esté centrado y sea productivo al desarrollar el producto.

Los equipos siempre necesitan recursos y no tienen porque ser siempre otros empleados. Los
equipos necesitan información y herramientas para desempeñar su trabajo así como acceso a
especialistas y otras cosas como formación. Si eres el gestor del proyecto deberías asegurarte de
que se satisfacen las necesidades de cada empleado para que todos puedan ser productivos. Una
de las áreas donde el equipo debería tomar el mando es en la priorización de prestaciones y la
estimación de pérdidas. Tu tarea como gestor de proyectos es confirmar que se estén realizando
estas actividades y ayudar a los empleados solo cuando tengan problemas con ellas. Una de las
formas más importantes de que el equipo tome el mando es apoyar sus decisiones. Incluso si no
estás de acuerdo con una decisión que se ha tomado a veces, lo mejor es permitir que la decisión
siga su curso y aprender de los resultados. Todos aprendemos mucho de nuestros errores así que
dejar que ocurran algunos puede producir grandes oportunidades de crecimiento. Dicho esto, si
crees que una decisión va a tener un dato significativo lo mejor es que debatas tu preocupación
con el equipo y cambies su decisión. A veces tienes que apoyar a partes involucradas expertas
además de al equipo.

Si la gestión ágil es algo nuevo en su entorno tienes que pasar un tiempo extra con los gestores
para confirmar que se están adaptando a los procesos ágiles. Algunos problemas a localizar son:
¿El cliente no está colaborando con el equipo de desarrollo diariamente? ¿El cliente está
demasiado ocupado para pasar tiempo con el equipo principal? Los gestores están confusos sobre
el enfoque iterativo y preocupados de que sus prestaciones no se evaluarán. Pasar un tiempo
adicional con los gestores puede ser de ayuda sobre todo durante los primeros "sprints" y puede
calmar las preocupaciones. Las preocupaciones también pueden surgir de la intensidad del
enfoque ágil. Los equipos ágiles productivos abordan esto adoptando un ritmo o cadencia. Si un
"sprint" duda seis semanas el trabajo puede ser muy intensivo de la semana 2 a la 5 cuando se
desarrollan las prestaciones del producto. El gestor del proyecto debería estar pendiente de los
factores que causen estrés para asegurar que cada empleado gestione su carga de trabajo de
forma efectiva. Asegúrate de que haya semanas menos intensas para que el equipo se pueda
relajar un poco y se prepare para el siguiente "sprint". Como ves en la exploración, el gestor del
proyecto no es el dueño de las tareas sino que hace lo posible para maximizar la efectividad de
cada empleado y que el equipo sea productivo de forma autónoma.

Gestiona la colaboración constructiva

Durante la etapa del desarrollo para que el sprint se lleve a cabo con éxito, la colaboración es
esencial, el gestor del proyecto puede hacer mucho para apoyar al equipo durante esta fase, y
asegurar que la colaboración funciona como se desea.

El círculo "Plan, Do, Check, Act" "Planea, Haz, Comprueba, Actúa, " o "Ciclo Deming" es una gran
técnica para albergar la conducta colaborativa. Siempre que se produzca trabajo, los miembros del
equipo deberían planificarlo con los demás, o en pareja, comprender el trabajo, cumplirlo, hacer
que otra persona lo verifique, que lo compruebe, y si el resultado no es el esperado, actuar para
cambiarlo inmediatamente. Si cada vez que se desarrolla una prestación se aplica el ciclo Deming
habrá una colaboración frecuente entre el desarrollador del producto y el cliente, y eso es
exactamente lo que debes buscar. Los equipos ágiles deberían estar en la misma ubicación, sin
embargo, no siempre es factible. Si los miembros del equipo principal no pueden compartir la
ubicación, tendrás que proporcionar herramientas y técnicas adicionales para que colaboren. Ya
vimos las herramientas en la etapa de concepto proporciona herramientas que permitan que
todos los empleados accedan a la información de forma sencilla. Yo incluso coloqué una cámara
web que se ve desde otras localizaciones y los equipos remotos siempre pueden ver que pasa,
esto ayuda a que se sientan parte del equipo como si estuvieran con los demás, los equipos son
más eficientes si están en la misma ubicación, pero las herramientas visuales también pueden
ayudar en caso contrario. Haz que se vean cara a cara al menos una vez al mes, idealmente al
inicio del proyecto cuando comienza la planificación.

Otra gran medida es hacer que los empleados trabajen juntos el primer sprint para que el equipo
se conozca. Los miembros del equipo principal tomarán muchas decisiones durante la exploración,
como gestor de proyectos, tienes que asegurarte que se hayan establecido normas y acuerdos
sobre cómo se tomarán las decisiones. Es mejor establecer un marco o un enfoque para la toma
de decisiones no unánimes. Aquí tienes algunos consejos. Hay que fomentar que los empleados
compartan ideas y se sientan cómodos expresando su opinión. Cada empleado tiene la
responsabilidad de hablar y compartir sus pensamientos. Los empleados tienen que escuchar
atentamente las ideas que se comparten ya que esto podría impulsar otras grandes ideas y
soluciones potenciales. Se puede tomar una decisión si la mayoría está de acuerdo, así se impide
que el grupo de vueltas sin fin. El equipo debe explicar y entender los motivos que hay detrás de
cada decisión. Los que estén en desacuerdo con la decisión tienen que apoyar las decisiones por
mayoría. Nadie tiene la autoridad de vetar una decisión. Las decisiones unánimes, aunque serían
ideales, pueden llevar más tiempo, este tiempo adicional puede no ser apropiado para el rítmo
rápido de los proyectos ágiles. Estarás de acuerdo que se debería permitir buscar decisiones
unánimes pero limita el tiempo de debate para que se tomen las decisiones en función del tiempo,
así se conocen las normas y el grupo puede tomar buenas decisiones basándose en la información
disponible.

Como ves, la colaboración constructiva no ocurre por casualidad, requiere usar el ciclo Deming
para las interacciones diarias, herramientas de comunicación visuales y efectivas y normas
acordadas sobre cómo se toman las decisiones

Gestiona los problemas y riesgos

En todos los proyectos hay que lidiar con problemas. La clave es tener las habilidades necesarias
para manejarlos según van surgiendo. Como gestor de proyecto, tienes que educar al equipo
sobre qué hacer cuando aparezcan. La gestión de problemas consiste más en relaciones y cómo
interactúan unos con otros y no en cómo lidiamos tácticamente con los inconvenientes. Consiste
en confiar en el otro para que cuando aparezca una dificultad te sientas cómodo teniendo una
conversación directa y sincera sobre ella.

Establecer técnicas para tener conflicto positivo es muy importante para resolver los obstáculos
rápidamente aplicando información válida. Aquí tienes algunas técnicas para aplicarlas con el
equipo. Recuerda a los empleados que ataquen el problema, no a la persona. Pide que aborden el
conflicto con el otro directamente de forma profesional y respetuosa. Todos deberían aportar
hechos, no rumores. Si los empleados no llegan a un acuerdo pídeles que presenten su situación
con pros y contras bien analizados. Los empleados enfrentados deben presentarte juntos su
información y explicar el punto de vista de su contraparte. Esta pauta es muy efectiva ya que
muchos empleados llegan a una resolución por su cuenta mientras hacen la presentación juntos.
Tú solo deberías tomar decisiones cuando tus trabajadores no sean capaces de hacerlo. Cuando
tomes una decisión, hazla clara y presenta los motivos lógicos pide su apoyo en función de la
decisión tomada.

A mí me gusta exponer los tres problemas principales en la oficina del equipo para asegurarme de
que son conscientes de los mayores obstáculos y que se centren en la importancia de resolverlos.
Que todos estén en la misma ubicación es fundamental en los proyecto Ágiles, sin embargo,
también tienes que asegurarte de que el equipo tenga la capacidad de completar algunas de sus
tareas en un área tranquila. Pueden aparecer dificultades si el equipo está ubicado en una área
abierta donde todos oyen todo, todo el tiempo. Puede ser difícil concentrarse si hay muchas
actividades teniendo lugar en la oficina del equipo. Prepara cubículos que puedan usarse para
completar tareas intensas o deja que los empleados usen auriculares en la oficina para que eviten
interrupciones. Si los trabajadores tienen un buen ambiente de trabajo serán más productivos y
podrán enfrentarse mejor a los problemas cuando surjan, ya que tendrán un buen estado de
ánimo.

Cuando tu equipo trabaja en las prestaciones es importante que des un paso atrás y vigiles el
progreso general y hacia dónde va el equipo. Tu tarea es buscar las cosas estratégicamente y
asegurar que se está lidiando con los obstáculos más grandes y se están considerando y evaluando
tanto los riesgos nuevos como los existentes. Si tienes el espacio, publica los tres mayores riesgos
en la oficina del equipo. Mantener al equipo informado ayuda a recordarle que también cuenta
con la capacidad de reducir los riesgos.

La gestión de los problemas y riesgos trata sobre relaciones, cómo interactuamos con los demás,
establecer pautas claras sobre cómo resolver los conflictos, proporciona al equipo las
herramientas que necesitan para resolver problemas, centrarse en los riesgos y obtener buenos
resultados.

La revisión y el cierre: haz ajustes y entrega.

Haz un seguimiento de los que aprendió en los sprints.
Una de las mejores características de la gestión de proyectos ágil es la oportunidad de obtener
"feedback" frecuentemente y aplicar cambios basándose en lo que ha aprendido el equipo. La
clave es formular las preguntas adecuadas y usar tus herramientas de control para asegurar que tu
proyecto se está realizando con una mirada crítica.

En las etapas de revisión y cierre debatimos qué necesitamos que ocurra en la fase de revisión.
Aquí tenemos que ver algunas de las técnicas disponibles para obtener "feedback" sólido. El
primer truco es no esperar hasta la etapa de revisión para recopilarlo. En la oficina del equipo, ten
un área donde los empleados puedan tomar nota de las lecciones aprendidas en cualquier
momento. Garantiza que la información está completa, que tienes el contexto. Ten en mente que
no necesitas saber cómo vas a resolver el problema solo escribe el "feedback". Algunos ejemplos
pueden ser:

- Completar las prestaciones de tamaño medio está llevando más tiempo del previsto. Las
reuniones diarias están llevando más de 15 minutos.
- Siento que no llegamos a ningún sitio porque siempre aparecen nuevas prestaciones.

Después, al final del sprint, cuando se debata sobre las lecciones aprendidas tendrás muchos
puntos que discutir. Lo normal es que la lista de asuntos que vas creando durante el sprint
provoque que los demás asistentes piensen en otras ideas aprendidas. Cuando hayas identificado
las lecciones, prioriza el "feedback" de lo aprendido basándote en el impacto del proyecto y
después determina cómo abordar cada punto. Céntrate en los asuntos de alta prioridad para el
equipo.

Aquí tienes una técnica sencilla para priorizar el "feedback". Digamos que tienes 30 puntos que
priorizar da a cada asistente del taller 10 votos y deja que voten por los temas que crean que son
más importantes para el proyecto Pueden repartir sus votos entre varios o dárselos todos a uno, si
quieren. Los asuntos de mayor prioridad serán los que hayan recibido más votos. Ahora que has
priorizado la lista de temas que necesitan una corrección tendrás que identificar la causa del
problema y cómo aplicar las correcciones. A veces, la solución es obvia. Otras, podría ser muy
difícil determinar la mejor forma de lidiar con el problema. Necesitarás habilidades conciliadoras
para que todos tengan voz y voto y se recopilen buenas ideas. Lo mejor es que fluyan las ideas y
que se fomente la creatividad. Algunas veces, las ideas más descabelladas se convierten en
grandes soluciones. Si es posible, deja que alguien ajeno al equipo sea el que facilite el taller así
podrás participar como miembro del equipo.
Si quieres determinar el nivel de entusiasmo sobre una solución cuando se aborden las lecciones
aprendidas, te aconsejo que uses la técnica que llamo "La regla de los cinco dedos". Cada persona
vota usando los dedos 5 indica que le encanta la solución recomendada 4 significa que le gusta 3
significa que podría vivir con ella 2 indica que tiene sus reservas 1 indica que tiene grandes dudas.
A partir de ahí puedes abordar los 1 y los 2 para determinar sus preocupaciones y modificar la
solución hasta que todos voten 3, 4 o 5. Sean cuales sean las decisiones, es fundamental que se
comuniquen todos los cambios relacionados con el proyecto al equipo principal y las partes
involucradas para que todos conozcan las nuevas pautas.

Acomoda los cambios de las prioridades

Sabemos que la gestión Ágil consiste en el negocio y en adaptar sus necesidades a medida que
suceden los Sprints. Sin embargo, al adaptarse a los cambios hay cosas que considerar.
Supongamos que tienes 100 prestaciones que ya se han priorizado; tu plan es implementarlas
durante cinco Sprints. Desde una perspectiva técnica podría tener sentido agrupar las prestaciones
entre los Sprints de forma distinta, por ejemplo, si se desarrollan prestaciones para informar sobre
los datos de facturación podría ser mejor completar todas las prestaciones relacionadas con
informes en un solo Sprint, sin embargo, si se han priorizado otras prestaciones, habrá que
respetar esa priorización, es decir, tienes que alertar al equipo comercial sobre las consecuencias
de la priorización que hagan. Tendrás que re-estimar las prestaciones de generación de informes,
si puede haber pérdidas desde una perspectiva técnica o de recursos. Por ejemplo, si se
completaron prestaciones de generación de informes en el mismo Sprint, el trabajo podría llevar
100 horas, pero si esas prestaciones se completan durante varios Sprints, el trabajo podría llevar
115 horas, o un 15% más. Es debido a la cantidad de tiempo que lleva a que un trabajador se
centre en un asunto cada vez que empieza a trabajar en una prestación.

Otro caso para tener en cuenta, digamos que estás remodelando, cubriendo el suelo y pintando el
interior de una casa amplia, pensemos que cada habitación es un Sprint, el cliente ha priorizado la
secuencia en la que las habitaciones se completan junto con todas las prestaciones para la casa. El
aire acondicionado está en último lugar, ya que no se sabe si tendrán el presupuesto para esta
prestación y viven en un área donde no suele hacer calor. Sin embargo, cada habitación se ve
afectada por el aire acondicionado porque hay que instalar conductos en todas, en este caso, tiene
sentido hacer el aire acondicionado primero. Como gestor de proyecto tienes que informar al
cliente sobre el impacto, normalmente en términos de costos o recursos. Si instalar el aire al final
le va a costar un 50 % más, quizá decida hacerlo antes, pero depende del cliente. En otras
situaciones puede ser obligatorio implementar primero una prestación dada como pre-requisito
para otras.

Vamos a volver al caso de las prestaciones de generación de informes. Una prestación pre-
requisito sería el proceso de introducción de los datos de facturación. Si la información no está
disponible en el sistema, no habrá nada de lo que informar. Y por último, los cambios de
prioridades pueden causar una reestructuración de las prestaciones, debido a la agrupación de
prestaciones, algunas prestaciones antiguas tendrán que rediseñarse para acomodarse a las
nuevas que estarán desarrollándose o implementándose. Esto es normal en la gestión Ágil pero
hay que planearlo. Cuando se crea un plan de lanzamiento al principio del Sprint, el experto en la
materia tendrá que revisar la secuencia de las prestaciones propuestas para determinar
consecuencias en el diseño y el desarrollo, y asegurar que las estimaciones se apliquen en los
siguientes Sprints.

Con una antelación y planificación adecuadas, podrás mantener los aspectos clave de la gestión
Ágil controlando la prioridad de las prestaciones con el equipo de proyecto y adaptando los
cambios en cada Sprint.

Cierre el proyecto ágil

Al empezar la etapa de cierre del proyecto, tendrás que tener una perspectiva general para
entender y documentar las lecciones aprendidas de todo el proyecto. En la gestión ágil, esto se
llama retrospectiva.

Invita a las partes adicionales a la retrospectiva dado que ahora ves el proyecto holísticamente.
Una vez que se ha completado la retrospectiva, puedes comenzar el cierre del proyecto.
Alcanzarás este punto si se da una de las siguientes condiciones. Se han implementado todas las
prestaciones deseadas. Bien hecho. Se ha acabado el tiempo acordado. Se te han acabado los
fondos en base al presupuesto original. Si has agotado el tiempo o los fondos tienes otros aspectos
a tener en cuenta al cerrar el proyecto. Revisa la lista de pendientes y trabaja con el equipo
comercial, para determinar la importancia de las prestaciones restantes. Además, descubre si hay
nuevas prestaciones que le gustaría implementar al equipo comercial. Si las prestaciones
pendientes son importantes y si hay nuevas prestaciones adicionales que debes tener en cuenta,
es posible hacer un nuevo proyecto si se pueden conseguir los fondos. Si en la lista de pendientes
hay prestaciones de poca prioridad, es más probable que no se empiece un nuevo proyecto, en
este caso, entrega la lista a alguien que pueda implementar esos cambios, si se desea,
progresivamente, en vez de con un proyecto.

Otro enfoque para el negocio es esperar. Si la lista de pendientes es importante pero no tienen
muchas nuevas prestaciones en ese momento, el equipo comercial puede querer esperar varios
meses para determinar si aparecen nuevas prestaciones y se garantiza un nuevo proyecto.
Independientemente de esto, es muy importante que se entregue la lista al equipo comercial para
que la mantenga hasta que se tomen decisiones.

En el video sobre las etapas de revisión y de cierre, hablamos sobre los puntos administrativos que
se necesitan para cerrar el proyecto, ahora vamos a centrarnos en el lado humano del cierre del
proyecto. Un evento de equipo es fundamental, incluso aunque el proyecto no haya tenido tanto
éxito como se esperaba. Los eventos de cierre de proyecto implican una clausura y dejan ver que
el proyecto se ha acabado. Es una gran ocasión para recordarles a todos por qué se hizo ese
proyecto y reconocer qué se ha conseguido con él. Si la gestión ágil es nueva para la organización,
es fundamental hablar sobre los beneficios, qué funcionó y algunos puntos que habría que
mejorar en los próximos proyectos. Los empleados se reubicarán en otros proyectos o volverán a
su puesto habitual.

Como gestor de proyectos, es importante que trabajes con los empleados de tu equipo principal y
sus gestores, para que todos sepan a partir de cuando no los necesitas en el proyecto, y conozcan
su próxima tarea. Este podría ser un momento emocional para algunos trabajadores si pasan de tu
proyecto a otras actividades, así que puede que estén más distraídos de lo normal. El cierre del
proyecto puede ser más fácil en los proyectos ágiles dado que la retrospectiva ha ocurrido luego
de cada uno de los sprints, puedes centrarte en la efectividad general del proyecto, frente a todos
los detalles que ocurrieron desde el principio del proyecto y si analizan las mejoras que han
conseguido como individuos y para el negocio.

Consejos y trucos para la gestión de proyectos ágil

Localiza los indicativos de que hay problemas
Al igual que en los proyectos tradicionales, en los "proyectos ágiles" pueden surgir problemas de
vez en cuando. Aquí tenemos algunas "técnicas ágiles" específicas para que busques problemas
potenciales en tu proyecto.

- Comprueba que el trabajo completado concuerda con el plan y que no te quedarán más
prestaciones en la lista de pendientes al final del "sprint". En inglés se llama snowplowing,
quitanieves. Es probable que ocurra al final del primer y segundo "sprint" al revisar que las
estimaciones concuerden con la productividad del equipo. Sin embargo, si continúa debes
de reunirte inmediatamente con el equipo para ver por qué está ocurriendo y tomar
medidas.
- Otro indicador de problemas es cuando el equipo produce partes de una prestación y
luego las elimina. Podría deberse al desarrollo de prestaciones que resultan ser de
prioridad baja, prestaciones que no se necesitan, prestaciones incorrectas, o prestaciones
que hay que revisar con información nueva. Muchas veces las causas principales de estos
problemas se relacionan con que los representantes comerciales no hacen las preguntas
adecuadas para entender el problema del negocio el cliente no entiende qué es lo que
desarrollas, o no tienes información precisa sobre la necesidad real del negocio. Si crees
que las posibilidades son estas, deberías dirigir una evaluación del producto con el cliente
para entender la causa del problema. Basándote en la opinión del cliente durante esta
evaluación, deberías revisar la lista de pendientes apropiadamente.
- Otra forma de evitar problemas es fijarse en la asistencia del equipo a las reuniones ¿Los
empleados del equipo principal están presentes y participan en las reuniones diarias para
hacer un seguimiento de las actividades? Puede haber motivos para faltar, mental o
físicamente, pero las ausencias repetidas son un indicativo de problemas. La asistencia de
los miembros del equipo en las reuniones diarias y las "retrospectivas" es crítica para la
buena comunicación y es clave para el éxito del proyecto. Deberías hablar individualmente
con cada empleado que se ausente. Si fue una buena elección para formar parte del
equipo principal una discusión franca y abierta y una buena conducta de liderazgo, por tu
parte, llevarán a una resolución. No dudes en consultar el problema con los directivos si la
ausencia persiste.
- Otro tema que vigilar es cuando gastas las reservas del proyecto. Hacerlo frecuentemente
puede afectar a tu calendario y la fecha de entrega. El papel del gestor de proyecto es
facilitar la funcionalidad del cliente gestionando el uso de las reservas. Es esencial que se
completen todas las tareas antes de que acabe el "sprint". Cualquier problema que lo
impida debe solucionarse rápidamente. El registro de incidencias es una herramienta ideal
para ello. En él deberían figurar la fecha y la descripción de cualquier dificultad, además
del motivo. Puedes revisar el tamaño y el número de problemas del registro y ver cuándo
y cómo estás usando las reservas. En la gestión ágil el último asunto sobre el que
reflexionar al buscar problemas es si eres el solucionador de los problemas que ves. Los
 equipos ágiles se organizan solos. Deberías tener confianza y fe en los miembros del
equipo y darles espacio para controlar el trabajo. Esto significa resistir la tentación de ser
siempre el solucionador.

Los enfoques ágiles tienen mucho potencial y ofrecen grandes resultados. Una buena supervisión
de los puntos problemáticos puede asegurarte que produzcas los valores comerciales con éxito.

Ajusta tus técnicas de gestión

Imaginemos que tienes el proyecto piloto perfecto para usar las técnicas ágiles, pero es la primera
vez que tu organización usará este método. Si dices a los directivos que todo será distinto, se van a
poner nerviosos, así que... En vez de eso, piensa qué es importante para ellos y como puedes
dárselo con un proceso ágil. Así, poco a poco, conseguirás que piensen en dónde están ahora y a
dónde quieren ir.

En mi trayectoria, he visto que hay algunas cosas que son prioridades para los directivos. Primero
resolver el problema empresarial con la satisfacción del cliente. Segundo, mantener el control por
ejemplo, producir valor dentro de tiempo y presupuesto. Y tercero, la moral del equipo. Vamos a
ver cada uno de estos elementos y como mostrarlos con enfoques ágiles.

- Empecemos por resolver los problemas con la satisfacción del cliente, antes de empezar,
asegúrate de que el cliente o el propietario del producto está comprometido a participar
activamente a lo largo del proyecto. Sin su opinión, colaboración y asistencias a las
reuniones diarias no tendrás éxito. El cliente define la lista de prestaciones y prioriza las
que resuelven el problema. Cuando se entrega cada prestación o el cliente lo acepta, no
solo se cumplen las necesidades del negocio, sino que la organización recibe los beneficios
más rápido y la satisfacción del cliente se incrementa significativamente.
- Mantener el control implica la gestión de la relación y hablar con lo directivos. Averigua
qué informes y medidas de control son esenciales para ellos para que se sientan cómodos.
La mayoría de los ejecutivos se preocupa por la gestión de las limitaciones, el alcance, el
tiempo y el costo. Si es necesario puedes aplicar mucho de los informes y las medidas de
control de la gestión tradicional, pero con una leve diferencia de formato. Por ejemplo, en
la gestión del alcance puedes demostrar un alcance definido gestionado con el control del
cambio, sin embargo en vez de un tablero de control de cambio y las peticiones de
cambios documentadas, utiliza los comentarios que hace el cliente sobre las muestras del
producto para añadir nuevos elementos a la lista de pendientes. Para la gestión del tiempo
una herramienta como ''MS Project'' sirve para generar un diagrama de Gantt con hitos.
Puedes mostrar las prestaciones de cada Spring, las dependencias entre Springs del
proyecto entero y puedes actualizarlo regularmente para la revisión. Para transmitir
seguridad en la gestión de los costos, demuestra que los proyectos ágiles tienen un
presupuesto fijo, limitado a la disponibilidad de los empleados que tienes, aunque no
verás un seguimiento, ni informarás de los costos actuales en una curva "S" como en los
proyectos tradicionales, puedes mostrar que tanto el cliente como el equipo de desarrollo
identifican los costos de cada prestación requerida y compárala con el valor añadido al
negocio. Cuando se ofrecen las prestaciones, evalúa cuánto dinero queda en el
presupuesto usando fondos aprobados hasta que no quede nada, en la gestión ágil, la
gestión del equipo es sencilla.
 - Los buenos equipos ágiles tienen las habilidades técnicas apropiadas y están cómodos con
el concepto de compartir el control del proyecto, suelen ser un equipo con energía y
servicial. Los Proyectos ágiles permiten que el equipo aporte valor al negocio
rápidamente. La moral es alta ya al principio del proyecto, el éxito en la entrega de las
prestaciones continúa reforzando y fomentando la moral y los empleados trabajan mejor a
medida que el proyecto progresa. Así que como gestor del proyecto, si lo haces despacio y
dejas que el equipo aprenda sobre la marcha, la motivación aumentará y estará orgulloso
de sus logros.

Próximos pasos para la gestión de proyectos ágiles

Los proyectos ágiles tienen muchos beneficios. Cuando las técnicas de gestión son nuevas puedes
aumentar el valor de tu organización con cada proyecto ágil que gestiones.

En este curso hemos visto el enfoque típico de la gestión de proyectos ágiles. Sin embargo, cada
proyecto es único y saber alterar tu enfoque con cada proyecto te ayudará a tener éxito. La
práctica hace al maestro. Concéntrate en ayudar a tu equipo a comunicarse. Mantén informados a
los directivos del progreso que haces y estarás bien encaminado. Las técnicas ágiles no son tan
importantes como que todo tu equipo entienda sus roles y tus expectativas. La gestión ágil es
flexible. Las técnicas son flexibles y tú también deberías ser flexible. Un liderazgo firme con tu
equipo y con los directivos es fundamental con tus proyectos ágiles. Busca otras oportunidades de
expandir tus capacidades de liderazgo. Te servirán cuando gestiones más proyectos ágiles y
proyectos ágiles más complejos. Te puedo recomendar dos libros: Agile Project Management, de
Jim Highsmith y The Art of Agile Pratice, de Bhuvan Unhelkar. Puedes aprender más sobre la
gestión ágil en estos y otros libros y sobre cómo el método ágil se ha introducido en varios
entornos.

Un último recordatorio: Hay muchas organizaciones por todo el mundo que entregan
certificaciones profesionales para gestores de proyecto. Todas requieren información sobre la
experiencia real en gestión de proyectos que hayas acumulado. Así que no te olvides de archivar el
número aproximado de horas que has pasado gestionando proyectos e incluye el objetivo del
proyecto y las fases en las que has trabajado junto con el nombre del supervisor que puede
confirmar el trabajo que has realizado. Esta información te será útil si quieres obtener una
certificación de gestor de proyectos. Te deseo lo mejor gestionando proyectos ágiles. Cada
proyecto ágil que se cumple con éxito contribuye a que los gestores de todos los proyectos
adopten estas técnicas. El éxito lleva al éxito.

Transición de gestión de proyectos en cascada a gestión de proyectos ágiles.

El mundo está en constante cambio y los proyectos en los que trabajamos también. Los cambios
de planes ya no son una excepción, sino la regla. Poder adaptarnos al cambio es una de las
ventajas competitivas que más pueden ayudar a la resiliencia de una organización, proyecto o
equipo.

A diferencia de la clásica organización en cascada, la mentalidad ágil cuestiona que los proyectos
deban realizarse siguiendo un plan estricto y acepta que los cambios son inevitables. En lugar de
tratar de predecirlos, proponen trabajar en iteraciones, que nos permiten aprender sobre el
mundo real y actualizar nuestros planes en consecuencia.

Conocimientos para entender el cambio de mentalidad

De proyectos en cascada a proyectos ágiles
Seguro que en los últimos años has escuchado hablar de la gestión ágil de proyectos y de las
llamadas metodologías y organizaciones ágiles. Puede que hayas visto ofertas de trabajo que
buscaban Scrum Master o que indican que el equipo trabaja en sprints o usa Kanban para repartir
las tareas. Aunque la gestión ágil de proyectos no es nueva, sí es cierto que en los últimos años se
ha convertido en una habilidad que cada vez más empresas reclaman a sus trabajadores.

Antes de nada, ¿sabes qué significa la palabra ágil? Según el diccionario, una persona o animal ágil
es aquella que es capaz de moverse con soltura y rapidez, que entiende las cosas y actúa con
rapidez o que funciona de manera efectiva y rápida. Cuando utilizamos la palabra ágil en el
contexto de la gestión de proyectos, lo hacemos para referirnos a un conjunto de metodologías y
maneras de pensar en la estrategia y planificación de las organizaciones que es precisamente
adaptable, efectiva y rápida. Muchas de las palabras técnicas que se usan en estas metodologías
son complejas y pueden intimidarte, pero al final la clave es que entiendas qué principios y
mentalidad están detrás de estas maneras de gestionar proyectos y los uses en beneficio de tus
proyectos.

En un mundo que es volátil, incierto, complejo y ambiguo, conseguir que las estructuras y sistemas
con las que gestionas tus proyectos te permitan actuar e iterar de forma rápida y efectiva te dará
una enorme ventaja competitiva.

Muchas metodologías ágiles de las que te hablaré tienen su origen en el mundo del software. Sin
embargo, bien porque cada vez más empresas tienen proyectos digitales o bien porque las
metodologías ágiles permiten su adaptación a diferentes industrias, cada vez vemos más empresas
que afirman gestionar sus proyectos de manera ágil. Empresas como bancos o aseguradoras,
tradicionalmente consideradas lentas y burocráticas, pueden, gracias a la gestión ágil de
proyectos, proponer decenas de nuevos productos a sus clientes cada año y enfocarse en mejorar
poco a poco con inversiones modestas los que mejor acogida o rentabilidad tienen.

La industria de la moda ha revolucionado su funcionamiento gracias a la gestión ágil de proyectos.

Crean tendencias en todo el mundo y tardan apenas un par de semanas después del primer
boceto hasta la primera venta. Ser tan ágiles les permite crear diferentes versiones de las prendas,
medir cómo funciona cada versión y lanzar una versión refinada antes de que su competencia
pueda tener tiempo de identificar la nueva moda.

Puede que escuchando esto sientas que llegas tarde a cambiar a esta nueva manera de gestionar
proyectos y quieras apresurarte a empezar rápidamente una lista de herramientas y pasos para
llevar a cabo esta transformación en tu organización. Paciencia. La agilidad también tiene sus
retos. Y el paso de la gestión en cascada a la gestión ágil debe ser un proyecto en sí mismo fruto de
una decisión estratégica evaluada, meditada y planificada. Ágil no significa improvisado. Voy a
ayudarte a entender el cambio de mentalidad del que nace esta manera de gestionar proyectos, a
evaluar la transición de cascada a ágil, a preparar la gestión del cambio y del equipo del proyecto
piloto. Te contaré qué esperar durante las primeras semanas de tu transición de Waterfall a Agile y
cómo evaluar y aprender para hacer que este proceso sea ágil en sí mismo.

Marcos de gestión de proyectos

A veces, una manera fácil de entender qué son las cosas pasa por entender lo que no son. Si
vamos a hablar de las metodologías ágiles de gestión de proyectos, una buena manera de empezar
una vez definida la propia palabra ágil es hablando de las metodologías tradicionales o no ágiles.

Si hemos dicho que las agiles son metodologías que buscan la flexibilidad y la respuesta rápida al
cambio, las metodologías tradicionales defendían que un buen proyecto parte de una buena
planificación y una ejecución en fases que, aunque puedan solaparse, suceden en general una
detrás de otra. Las metodologías tradicionales de gestión de proyectos abogan por definir los
proyectos como esfuerzos temporales que buscan generar un producto o cambio específico y que
operan en entornos controlados. Estas metodologías proponen pasos que se suceden, proyectos
que tienen inicios y finales claros y en los que se trabaja siguiendo un mapa, una ruta que se traza
al principio y en la que un desvío se ve como una terrible noticia. Los marcos de gestión de
proyectos tradicionales como PMI, Prince2, el modelo en V, el llamado Big Design Up Front o el
modelo Waterfall o en cascada dividen el proyecto en fases como análisis, requerimientos,
preparación, diseño, implementación, verificación, mantenimiento. Buscan la anticipación de los
problemas, la estimación y programación de tareas de manera que hagan un uso óptimo de los
recursos y tiempos y la monitorización de resultados y desviaciones. Son opuestas a las
metodologías ágiles, que abrazan el cambio y ven la capacidad de responder a él rápidamente
como una propuesta de valor. Asumen que vivimos en un entorno de entropía constante, de caos,
en el que es imposible pensar en todos los riesgos y en los que, por tanto, estamos destinados a
fracasar por mucha planificación que hagamos. Es lo que se llama VUCA, por las siglas en inglés
de las palabras que caracterizan este entorno: volatilidad, incertidumbre, complejidad y
ambigüedad. Estos cuatro factores hacen que predecir sea cada vez más difícil y hace necesario
una manera de gestionar proyectos que funcione bien en este entorno.

Las metodologías tradicionales responden a este entorno VUCA invirtiendo un porcentaje

importante del tiempo y los recursos disponibles en la planificación del proyecto. Las
metodologías tradicionales eran predictivas, trataban de listar todos estos riesgos y estas posibles
respuestas, mientras que las metodologías ágiles buscan ser adaptables. En las metodologías
tradicionales frecuentemente se genera documentación extensiva. Se definen los requisitos en
detalle, se generan diseños finales y se estudian los riesgos en profundidad. Un proyecto
gestionado de manera tradicional tiene un plan detallado y planes de contingencia para hacer
frente a todo tipo de situaciones antes de empezar a producir.

La gestión de proyectos a cascada a waterfall

Una de las metodologías de gestión de proyectos tradicionales, tal vez la más conocida, es la
gestión de proyectos en cascada, o Waterfall, por su nombre en inglés. En esta metodología, las
fases del proyecto se suceden en el tiempo y cada una vierte su resultado o producto como un
input de la siguiente. Este flujo de productos de una fase a otra desde el inicio hasta el cierre del
proyecto, como una serie de cascadas en un río, da su nombre a la metodología. El modelo en
cascada nace en el contexto del desarrollo de software. Tiene orígenes vagos y suele utilizarse de
manera crítica, pero la realidad es que las organizaciones más tradicionales ven en esta manera de
gestionar proyectos muchas ventajas y muchos proyectos públicos exigen la gestión en cascada.

Los proyectos en cascada se inician con un análisis de requisitos, que tienen como objetivo
generar un documento extensivo describiendo en detalle los requisitos funcionales y no
funcionales del proyecto. Esta fase puede durar meses o incluso años, dependiendo del grado de
innovación necesario y de la complejidad del proyecto. Este documento de requisitos generado se
usa como input para la siguiente fase de los proyectos en cascada: el diseño de la solución. En
función de los requisitos, se diseñará en detalle la solución propuesta. El producto de esta fase es
un documento de arquitectura y diseño de la solución. Dependiendo del tipo de proyecto, será un
tipo diferente de documento, pero en general será un plan detallado con toda la información
necesaria para comenzar la producción propiamente dicha. Este diseño se entrega al equipo
encargado de la implementación del proyecto, la tercera fase de los proyectos en cascada. Una vez
iniciada esta fase, no se esperan cambios en los requisitos o en el diseño, y si los hubiera, por
cambios en las necesidades o en el contexto o en el entorno, será necesario reaccionar. En algunos
casos habrá que consultar el plan de contingencia, tratar estos nuevos requisitos o cambios como
un nuevo proyecto, negociar un cambio de alcance o incluso en algunos casos extremos parar el
proyecto directamente. En los proyectos tradicionales, esta fase de implementación se desarrolla
a lo largo de semanas, meses o incluso años, al término de los cuales el proyecto finalizado es
evaluado.

Como ves, Waterfall es una metodología con fases claras y sucesivas. Quédate con este concepto
como el más interesante para entender las metodologías ágiles y recuerda que este modelo de
gestión de proyectos no es necesariamente malo. Puede ser muy útil en los casos en los que los
proyectos requieran este tipo de planificación como, por ejemplo, las películas o los proyectos de
construcción. Las metodologías ágiles cuestionan. No buscan desterrar esta metodología, solo
cuestionan que sea óptima para todos los proyectos.

Qué es SCRUM y en qué consiste.

Scrum es uno de los marcos ágiles de gestión de proyectos más antiguos. De hecho, nació antes de
que la mentalidad ágil se definiera como tal. A pesar de esto, Scrum cambia las normas e introduce
el concepto de ciclos, por lo que suele usarse como uno de los ejemplos más típicos de
metodologías ágiles o incluso considerarse como la metodología ágil por excelencia.

Definamos la palabra Scrum para ver qué nos dice. En rugby, un scrum o melé es la reunión que
hacen los jugadores para analizar la partida y planificar los próximos movimientos. Los equipos
tienen sus estrategias para la temporada, también sus tácticas, los movimientos para los que están
entrenados y coordinados, pero cada tanto en un partido se reúnen para decidir cuál es de estas
tácticas van a utilizar y comentar si es necesario hacer algún cambio en el equipo. Estos equipos
han entendido que sus planes pueden cambiar durante el partido y de esta idea parte de la
metodología Scrum.

En Scrum hay pequeños equipos de entre 5 y 8 personas que colaboran para ganar. Cada uno tiene
su rol. Trabajan con unos artefactos determinados, así se llaman los productos de cada fase en
Scrum, y se reúnen en una serie de ceremonias muy bien definidas, incluso en lo que a su duración
se refiere por la metodología Scrum.
Cada miembro del equipo Scrum, como en los equipos deportivos, tiene una especialización, pero
todos juegan con un mismo objetivo y no hay jefes, solo un rol servil, el del entrenador que motiva
al equipo, organiza y se encarga de todo lo que no es jugar. En Scrum este rol lo juega el Scrum
master. Hay un segundo rol, el de product owner, que se encarga de fijar los objetivos. Puedes
hacer la analogía de que el product owner decide qué partidos se van a jugar. La lista de términos
de Scrum no acaba aquí. Estos equipos de proyecto Scrum, como los de rugby, tienen su propia
estrategia y sus tácticas, pero se reúnen cada tanto para ajustar estos planes a la situación. En
Scrum estos ciclos de trabajo se llaman sprints y las reuniones, o ceremonias, según las llama la
metodología, se llaman scrums. Estos ciclos pueden ser diarios o al inicio y al final del sprint, cada
uno con sus propios nombres. Es posible que hayas oído hablar de la pila de producto, llamada
backlog en inglés. Este es un artefacto de Scrum que agrupa todas las tareas y problemas por
resolver en relación al proyecto. Esta pila de producto es definida por el product owner,
planificada para un sprint con ayuda del Scrum master y producida por el resto del equipo Scrum.

En Scrum se suele usar para ver el progreso de este backlog de proyecto un Kanban que solo
contenga el backlog del sprint. Es una representación en columnas, con fases como por hacer,
haciendo y hecho que indican el progreso de la tarea. El objetivo de los equipos es conseguir pasar
todas las tareas, del por hacer al principio del sprint a hecho al final del mismo, evitando que
entren tareas nuevas, tener que mover tareas hacia atrás o dejar tareas a medias.

Qué es XP y en qué consiste

XP (Extreme Programming), o programación extrema traducido al español, es otra metodología de
desarrollo de software de la que se habla mucho al estudiar las metodologías ágiles. En XP se
busca conseguir una alta calidad en un entorno de constante cambio. Se propone hacerlo en base
a ciclos de trabajo y a una serie de buenas prácticas que le han valido a esta metodología el título
de ágil.

XP, como programación extrema, lleva las recomendaciones al extremo. Por ejemplo, propone la
programación en pares o pair programming, una práctica que se usa en software y que se puede
aplicar fácilmente a otras funciones. Consiste en poner a dos personas a trabajar juntas en una
misma tarea. No en paralelo, sino compartiendo herramientas de trabajo y abordando cada
problema juntos. La recomendación de revisar el código no es nueva en XP, pero sí lo es hacer esta
revisión de manera continua y en tiempo real. Trabajar en pares aumenta el uso de los recursos,
pero, como se dice, cuatro ojos ven mejor que dos. Esta práctica ayuda a dar con mejores
soluciones y a reducir el número de errores, disminuyendo además la intensidad del trabajo de
revisión.

XP propone además la revisión del código con pruebas unitarias, componente a componente y en
base a su comportamiento, en lugar de hacer grandes revisiones completas que son más
susceptibles de tener fallos y serán más difíciles de encontrar. Igual que antes, hacer pruebas de
versiones relevantes es una práctica antigua en ingeniería, pero XP introdujo la propuesta de hacer
que estas versiones fueran mínimas, unitarias. XP, por supuesto, lleva esto al extremo y propone
que los test se definan antes de empezar a producir.

Otra de las prácticas propuestas en XP es la creación de soluciones de manera iterativa y en el

momento en el que son necesarias, en vez de por adelantado y en previsión de una posible
necesidad futura que muchas veces no se llega a realizar.
 Las estructuras en XP son planas y se basan en una muy buena comunicación con el cliente, que
es necesaria para acomodar esta iteración tan extrema. XP ha progresado desde su nacimiento en
los 90 y, aunque es una disciplina menos popular que Scrum, se utiliza como base en la creación de
metodologías propias en muchos equipos de software. Como en otras metodologías ágiles, XP
nace del software y está diseñada para este mundo, pero puede adaptarse a organizaciones que
realicen diferentes actividades.

XP tiene cinco valores: comunicación, simplicidad, feedback, coraje y respeto. Como ves, esto
tiene poco que ver con el software y puede aplicarse a cualquier tipo de proyecto. Una buena
comunicación, la preferencia por las soluciones y procesos simples, la retroalimentación entre el
equipo, los clientes y los usuarios, el coraje para trabajar en ciclos e implementar soluciones de
manera iterativa y el respeto entre todos los participantes del proyecto son clave. Te animo a que
las incorpores aunque trabajes en proyectos que no sean de software o en los que vayas a utilizar
otra metodología tradicional o ágil.

Otras metodologías ágiles

Scrum y XP son dos metodologías o disciplinas que se suelen mencionar como parte de las
metodologías ágiles, pero no son las únicas.

Es posible que te suenen términos como Lean Startup, Kanban, desarrollo de software adaptativo,
desarrollo basado en funcionalidades, desarrollo orientado a comportamientos, desarrollo basado
en test, integración continua, SaFe, Nexus, Escaled Scrum. Todas estas palabras y siglas son
diferentes principios o metodologías para gestionar proyectos, sobre todo digitales, que beben de
los principios y de la mentalidad ágil y que son alternativas a las metodologías tradicionales de
gestión de proyectos como la gestión en cascada. Cada una de ellas tiene una propuesta diferente
y se enfoca en organizaciones más o menos digitales, de mayor o menor tamaño o con normas
más o menos estrictas. Algunas de ellas se concentran más en las prácticas relacionadas, otras en
sus ciclos o fases y otras en la calidad.

Como verás, no se trata de decidir cambiar de la gestión en cascada a la gestión ágil, es necesario
hacer una evaluación del proyecto, del equipo y de las necesidades para poder decidir cuál de
estas metodologías es la más adecuada. ¿Por qué se habla entonces de las metodologías ágiles? Es
posible que te hayas dado cuenta de que ninguna de estas metodologías incluye la palabra ágil en
su nombre, ni la he mencionado como valor. Cada una de estas metodologías y las que vengan
después que estén alineadas en la idea de la adaptabilidad en lugar de la predictibilidad son
dignas de ser consideradas ágiles. En un mundo en constante cambio, que premia la agilidad, no
hay tiempo para discutir las etiquetas.

El manifiesto ágil y la mentalidad ágil

En 2001, representantes de Scrum, XP y otras metodologías de gestión de proyecto alternativas a
las metodologías tradicionales, como la gestión en cascada, se reunieron y redactaron el
Manifiesto Ágil. El Manifiesto Ágil es un conjunto de cuatro valores y 12 principios que agrupan las
propuestas de varias metodologías y que ha dado nombre al conjunto de estas metodologías y ha
ayudado a su expansión.

Sin el manifiesto ágil, hoy no estaríamos aquí. A pesar de su importancia, cuando leemos en
detalle esta declaración de intenciones y creencias vemos que no se prescriben métodos ni
herramientas. Elementos de Scrum como los roles del equipo o sus ceremonias y artefactos o
conceptos como los ciclos de XP no aparecen en el Manifiesto Ágil. En lugar de prescribir, los
firmantes del manifiesto plantearon que gracias a su trabajo en proyectos propios y para terceros
estaban descubriendo mejores maneras de hacer software. Así, estaban comenzando a valorar
más los individuos y las interacciones sobre los procesos y herramientas. El software funcionando
sobre la documentación extensiva, la colaboración con los clientes frente a la negociación
contractual y la respuesta ante el cambio sobre seguir un plan. Reconocían además que esta
documentación, contratos y planes eran importantes, pero que sus alternativas, los individuos, el
software funcionando, la colaboración con los clientes y la capacidad de responder ante el cambio,
lo eran más. Añadían además 12 principios para el software ágil, similarmente generales.

El manifiesto, fiel a lo que propone, no se centra en los detalles, sino en facilitar una mentalidad
que prima la productividad sobre la forma, que acepta el cambio y reconoce la flexibilidad como
una ventaja competitiva, así como la importancia de los equipos y de las relaciones con usuarios y
clientes.

A partir de la firma del Manifiesto Ágil, los practicantes de metodologías como Scrum o XP
empiezan a reconocerse como seguidores de unos principios comunes y nace el «agilismo».
Unidas, estas metodologías y prácticas empiezan a cobrar importancia y a aprovechar las
oportunidades de escala que les da el estar todas integradas en un mismo marco.

Evaluar la transición de cascada a agile

Ventajas de las metodologías ágiles
Las metodologías ágiles tienen numerosas ventajas para las organizaciones y los mánager, pero
también para los clientes y empleados de los equipos en los que se utilizan.

Antes de nada, como recordarás, el Manifiesto Ágil empieza diciendo que valora más a las
personas que los procesos o las herramientas. Y la mayoría de las organizaciones en las que se
usan estas metodologías hacen grandes esfuerzos por cuidar bien a su plantilla. Por supuesto, hay
excepciones y, a medida que se han hecho más populares y las han incorporado más empresas,
esto ha podido diluirse. No obstante, una organización realmente ágil suele invertir mucho en
cuidar a sus personas.

En un equipo ágil, un retraso por una baja inesperada o un bloqueo con una tarea de un
compañero suele inspirar una revisión de las causas de base del problema. Tal vez hay habilidades
del equipo que solo tiene una persona. Además, en las metodologías ágiles será de esperar ver
cambios en la hoja de ruta, ya que es muy probable que se revisen las estimaciones de otras tareas
similares. Las metodologías ágiles se centran en reaccionar a un problema que ya no se puede
deshacer. En la gestión más tradicional es posible que este error se hubiera podido evitar, pero si
no, cabría esperar una reprimenda al equipo por el retraso y una invitación a apurar para volver a
alcanzar el ritmo de entregas acordado al inicio del contrato. Este tipo de intervención solo bajará
la moral del equipo y no resolverá el verdadero motivo del retraso.

Aunque hacer un análisis de riesgo es muy positivo, los acontecimientos que hemos vivido nos
recuerdan que hay situaciones que no se pueden prever y que ser flexibles es una gran ventaja en
nuestra vida personal y profesional. Por último, las metodologías ágiles priman la entrega de valor
y de calidad, así que mantenerse en tiempos o tener muy claro desde el principio cuál es la
solución y trabajar en ella sin desviarse del plan no son el objetivo, pero sí contaremos con una
solución funcional desde fases muy tempranas del proyecto.

En el mercado actual, que avanza a una velocidad vertiginosa, poder entregar valor rápidamente e
ir entregando mejoras poco a poco aporta una enorme ventaja competitiva a las organizaciones.
Poder lanzar una idea de una colección de ropa o de una aplicación móvil en semanas e ir
mejorándola a lo largo de meses con información real de usuarios es mucho mejor que trabajar
durante años en una idea y lanzarla en estado avanzado, solo para darnos cuenta de que nadie le
ve utilidad o de que nuestra competencia ya lo ha hecho antes.

Riesgos de las metodologías agiles

Aunque las metodologías ágiles tienen muchas ventajas y pueden ayudar a las organizaciones a
centrarse más en las personas, entregar más valor o responder mejor al cambio, también tienen
algunos riesgos que es necesario conocer y evaluar antes de lanzarse a utilizarlas. Además de
riesgos, algunos de estos son impedimentos para la adopción de las metodologías ágiles en una
organización.

Uno de los riesgos que más frena a las organizaciones es la incertidumbre. En los entornos de
gestión de proyectos tradicionales el detalle de la solución se conoce al 99 % antes de empezar a
poner la primera pieza, cocinar el primer plato, escribir la primera línea de texto o código o
empezar a afilar el lápiz. Como los proyectos pasan por fases previas de definición y diseño, los
planes, tiempos y presupuestos están claros antes de empezar y la gestión del proyecto consiste
en asegurar que estamos dentro del rango esperado. En los proyectos ágiles estas actividades se
empiezan antes, pero no se conocen los detalles de lo que se hará, tan solo los objetivos o
necesidades y una idea aproximada de cómo se tratará de abordar.

Como el análisis y el diseño se realizan en cada iteración, según se va aprendiendo de los usuarios
y del entorno es difícil saber cómo se resolverá cada problema, cuánto tiempo llevará hacerlo o
qué coste tendrá. Esta falta de definición previa aumenta la incertidumbre en fases intermedias
del proyecto y puede ser difícil de aceptar en algunos proyectos. Para que esto funcione es
necesario que exista confianza y no todas las organizaciones están dispuestas o tienen
posibilidades de operar así. Esta incertidumbre, acercamiento iterativo y flexibilidad hace que
muchos proyectos tengan un alcance, tiempo de ejecución o presupuesto variables, y este modelo
no encaja en todas las organizaciones. Por último, las metodologías ágiles requieren,
contrariamente a lo que se puede pensar, de mucha madurez y capacidad de autocrítica y
comunicación en las organizaciones y las personas que las forman.

Uno de los principios del Manifiesto Ágil aboga por los equipos autorganizados y sostiene que de
ellos nacen las mejores arquitecturas y diseños. Durante mi carrera he coincidido con
programadores sénior que necesitaban de muy poca dirección, trabajaban concienzudamente y se
tomaban muy en serio la producción de valor real de la manera más eficiente posible. Con
ingenieros que no tengan esa experiencia, sin embargo, posiblemente hubiéramos acabado
desperdiciando recursos en busca de soluciones. Y si hubiera trabajado con personas que no
estuvieran comprometidas con el equipo, habría sido fácil que la productividad sufriera, al no ser
tan exigentes con las fechas de entrega. Cada organización, cada proyecto es un mundo y las
metodologías ágiles no son aplicables en todos los casos. Es necesario conocer bien las diferentes
opciones de metodologías, el porqué de los elementos que las conforman para poder utilizarlos de
manera aislada según el caso y sobre todo el proyecto y la organización en los que se quieren usar.

Cómo decidir las metodologías ágiles que vamos a usar

Si una vez que has analizado las ventajas y los riesgos de las metodologías ágiles sigues pensando
que pueden ayudar a tu organización, es el momento de elegir cuál de todas las metodologías y
propuestas disponibles encaja mejor.

Antes de nada, tienes que saber que puedes usar una metodología tal y como se propone o
decidirte por diseñar una metodología a medida que se inspire los elementos que encuentres más
interesantes en cada una. Esta segunda opción no es mala idea dependiendo de cada caso, solo
recuerda comunicar con transparencia que estás usando una metodología a medida. Hay una
broma habitual en el mundo de las metodologías ágiles sobre cuántas organizaciones dicen que
usan Scrum pero en realidad hacen lo que se ha llamado Scrum but o Scrum pero, una
metodología que adopta lo que interesa y que adapta el resto. Si se hace con transparencia y con
una justificación, está bien. Recuerda que expresar de forma clara tu manera de trabajar te
ayudará en la comunicación o en el reclutamiento de miembros para tu equipo o consultores.

Es necesario conocer bien las diferentes opciones de metodologías y el porqué de los elementos
que las conforman para poder usarlos de manera aislada según el caso. Por ejemplo, cuando se
habla de equipos de entre 5 y 7 personas, el motivo de fondo es asegurar que la comunicación es
sencilla. Si sigues este principio puedes tener equipos de 4 o de 8 personas sin problemas. Aunque
es una elección compleja y con muchos matices, si tengo que resumir los criterios que debes
incluir para tomar la decisión de qué metodología elegir, te diré que son:

- El tamaño de la organización
- Sus necesidades de seguimiento o de regulación el tipo de proyecto
- La cultura interna del equipo y el conocimiento de las metodologías ágiles que haya
adentro del mismo o la capacidad de acceder a él externamente, sea contratando a
trabajadores o a consultores o realizando programas de formación.

Algunas metodologías como Scrum tienen un alto grado de formalidad, que requerirá una
madurez mayor y un conocimiento específico, mientras que herramientas como el Kanban son
más fáciles de insertar en las rutinas de un equipo más tradicional o con menos conocimientos.
Algunas de las metodologías ágiles solo se utilizan en las aplicaciones de software y algunas
requieren de equipos de más de un cierto número de personas. Te recomiendo que analices todas
las alternativas o contrates a una persona especializada en hacer este tipo de recomendaciones
que pueda ayudarte a tomar esta decisión. También te recomiendo que sigas las propuestas del
propio Manifiesto Ágil en la toma de decisión sobre qué metodología ágil aplicar. Pon las personas
en el centro, colabora con todos los roles implicados, acepta los cambios de tu decisión inicial y
céntrate en lograr un proceso que funcione, no en seguir paso a paso una metodología si no
funciona en la práctica.

Criterios para elegir un proyecto candidato a primer piloto

Una de las decisiones que deberemos tomar antes de realizar una transición de gestión de
proyectos en cascada a una gestión ágil de proyectos es qué proyecto de nuestro portafolio
usaremos como proyecto piloto. En organizaciones pequeñas es posible hacer el cambio de
waterfall a ágil para todos los proyectos, pero en equipos más grandes te animo a buscar un solo
proyecto piloto para probar tus hipótesis y ganarte el apoyo de la dirección y del equipo.

Los proyectos piloto se usan para validar la viabilidad de una propuesta. Tu primer proyecto será
tu prototipo de gestión ágil que podrás usar para evaluar si esta manera de gestionar proyectos se
puede aplicar efectivamente a tu organización. No todos los proyectos serán susceptibles de ser
elegidos como proyecto piloto, así que a continuación te cuento algunos criterios que puedes usar
para seleccionar a tus candidatos.

Hay algunos proyectos que directamente podrás descartar en función de su entregable. Las
metodologías ágiles funcionan muy bien en la creación de aplicaciones de software, campañas de
comunicación y marketing, procesos de gestión o incluso programas educativos que se imparten
en persona. Pueden ayudar incluso en la fabricación de productos en los que haya que realizar un
diseño que se valide por usuarios en todos los ciclos de prueba, como en casos de innovación
industrial. Sin embargo, si vas a construir edificaciones, infraestructuras o productos tangibles o
intangibles costosos y más definitivos, como una película o un automóvil, es posible que la gestión
en cascada sea una mejor opción. No te recomiendo que experimentes con este tipo de proyectos
en un piloto. Una vez descartados los proyectos que por su entregable no sean óptimos para un
piloto, analiza su riesgo y su complejidad. Para empezar, proyectos con un bajo riesgo y
preferiblemente impacto solo interno ayudan a reducir el estrés de la transición.

Además, para un primer proyecto piloto, un proyecto de baja complejidad será más ligero y
ayudará al equipo a centrarse en el proceso al tener que invertir menos tiempo en el análisis y en
la parte técnica de la definición. Además, te recomiendo que analices la historia del proyecto antes
de incluirlo entre tus candidatos a piloto. Hay proyectos que no son necesariamente complejos ni
incorporan mucho riesgo pero que tienen una historia agitada y pueden ser sensibles. Por
ejemplo, es posible que durante años tu organización se haya planteado un cambio de
herramienta o un nuevo programa de formación para nuevos empleados. Tal vez no sean cambios
complejos, pero si el proyecto tiene que prestar atención a relaciones, problemas o sensibilidades
antiguas, es posible que se pierda parte del foco en la iteración y haya que dedicarle mucho
tiempo a analizar estas relaciones y sensibilidades. Esto no es un problema en un proyecto ágil una
vez el equipo está habituado a trabajar de esta manera, pero para un piloto cuanta menos historia
tenga el proyecto, mejor.

Por último, es posible que haya proyectos que no hayan sido eliminados con estos filtros. Si es
porque no tienes mucha información sobre el proyecto, plantéate que tal vez ese proyecto tenga
vicios ocultos, que solo saldrán durante la fase de análisis.

En resumen, trata de encontrar un proyecto del que tengas suficiente información, que tenga
pocos riesgos conocidos, un entregable preferiblemente intangible, poca historia y baja
complejidad. En el proyecto piloto queremos centrar la atención en el proceso de gestión ágil y en
adaptarlo, así que cuanto más reduzcamos la necesidad de gestionar el proyecto en sí, más tiempo
tendremos para observar y mejorar la manera en la que trabajamos de manera ágil.
Prepararse para gestionar el cambio y los equipos
La decisión de explorar la gestión ágil de proyectos
La decisión de adoptar una gestión ágil de proyectos suele llegar a las organizaciones por tres vías
diferentes: de abajo arriba, de arriba a abajo o desde afuera. En algunos casos son los propios
miembros del equipo quienes proponen a la dirección de las organizaciones hacer esta transición,
sea porque han gestionado proyectos de manera ágil en organizaciones anteriores donde han
visto sus beneficios o porque lo hayan aprendido en cursos como este. En estos casos en los que la
decisión viene de abajo a arriba, será necesario convencer a la directiva de las ventajas del cambio.
Estas decisiones son complejas y muchas veces será necesario probar los beneficios con casos de
éxito, por lo que el trabajo en el proyecto piloto es clave en esta toma de decisiones.

En otras organizaciones, la motivación parte precisamente de la dirección. En estos casos casi

siempre se trata de una decisión orientada a la mejora de la productividad. Como la directiva
tienen capacidad para imponer esta propuesta, esta toma de decisiones es mucho más sencilla,
como casi todas las decisiones que se toman de arriba a abajo. Aunque la toma de decisiones sea
más fácil, la gestión del cambio requerirá de información y entrenamiento y sería muy
recomendable identificar a posibles aliados entre los miembros de los equipos que puedan
adoptar y defender esta iniciativa como propia.

En un tercer caso, es un consultor externo o un cliente quien recomienda o incluso exige el

cambio. Esta situación es la más difícil de gestionar, ya que implica que hay que convencer y
formar tanto a la directiva como a los miembros del equipo. En esta situación será más importante
que en ninguna otra realizar una gestión del cambio excelente, contar con algunas personas en
diferentes niveles de la organización y realizar la selección del equipo adecuado y el proyecto
idóneo de manera mucho más meticulosa.

La toma de decisiones se suele, además, realizar en varias fases. Primero se decidirá explorar este
tipo de gestión. Una vez tomada esta decisión y evaluados los candidatos a proyecto piloto, se
decidirá a continuar con esta validación. Si este piloto es exitoso, se decidirá si expandir esta nueva
forma de gestionar proyectos a otros proyectos del portfolio.

Conseguir el apoyo de los líderes de la organización

Antes de cambiar la manera en la que se gestionan los proyectos de tu organización será necesario
conseguir el apoyo de los líderes. Si la decisión del cambio ha sido tomada de arriba a abajo, este
apoyo no será un problema, pero si la decisión parte del propio equipo o del exterior, la falta de
apoyo puede suponer un problema o incluso frenar por completo la transición.

El primer paso para conseguir el apoyo del liderazgo de tu organización es informarles de las
ventajas de las metodologías ágiles. El foco en las personas puede no ser tan interesante en este
momento, pero conceptos como el foco en la calidad, en los entregables frecuentes a clientes
finales o la incorporación de cambios en cualquier fase del proyecto son argumentos que sí
pueden poner la balanza a tu favor en este momento. Si consigues además relacionar estas
ventajas con un retorno directo de la inversión, será mucho más fácil que consigas el apoyo para
realizar el primer proyecto piloto gestionado de manera ágil. Además de poner en valor las
ventajas, pon encima de la mesa los riesgos y propón maneras de identificar situaciones de riesgo
y reaccionar a ellas. Tener un plan de contingencia le dará solidez a tu propuesta.
Saber que hay una manera de parar la máquina ágil y volver a la manera habitual de gestionar el
proyecto rebajará el estrés sobre el piloto. Los cambios definitivos dan miedo, así que explica de
manera clara que, si todo va mal, hay una estrategia de retirada. Puedes compartir casos de éxito
de empresas conocidas, especialmente de tu sector, para sostener tu propuesta. Si la gestión ágil
ha sido una ventaja competitiva en su éxito, será más fácil convencer al liderazgo de tu
organización de que puede serlo también en vuestro caso.

En las organizaciones más grandes suele ser importante formalizar este tipo de cambios y se suele
recurrir a formaciones y certificaciones externas. Muchas metodologías ágiles tienen sus propios
programas de certificación y saber que están disponibles puede dar tranquilidad a la dirección de
tu empresa. Si alguno de los miembros del equipo está certificado, puede ser mucho más fácil
confiar en que el cambio estará controlado y será exitoso. En esta línea, puede ser interesante que
menciones además algunos conceptos ágiles específicos como la agilidad empresarial o business
agility, una propuesta para incorporar los principios ágiles a la dirección empresarial.

Aunque las metodologías ágiles nacieron en el desarrollo de aplicaciones y el propio Manifiesto

Ágil fue redactado por desarrolladores de software para desarrolladores de software, muchos de
sus principios van teniendo cada vez más importancia en otros sectores y están llegando por fin a
la dirección y gestión estratégica de las empresas. Este puede ser un argumento definitivo. La
gestión ágil de proyectos ya no es solo relevante para los equipos de las organizaciones, adoptar
esta forma de gestión y sobre todo esta mentalidad supone una ventaja competitiva para las
organizaciones, tiene impacto directo en su modelo de negocio y cuenta de resultados. Dedícale el
tiempo necesario a este paso de la transición de gestión de proyectos en cascada a gestión ágil.
Conseguir el apoyo del liderazgo es clave para el éxito del cambio.

Simpatizantes y detractores del cambio

Una vez comuniques a tu organización la intención de transicionar de gestión de cascada a gestión
ágil, verás diferentes reacciones entre la directiva y los miembros del equipo.

Algunas personas de tu organización se entusiasmarán al escuchar la propuesta de pasar de

gestión en cascada a gestión ágil. Esto suele ser común en personas que ya hayan trabajado de
esta manera en el pasado y puede ser muy interesante contar con su conocimiento previo en el
primer proyecto piloto.

Otras personas se mostrarán indiferentes, bien porque su día a día no vaya a verse afectado por el
cambio o bien porque estén conformes con el cambio pero no especialmente entusiasmadas. Te
recomiendo que continúes informándoles y trates de evitar que caigan en el siguiente grupo: los
detractores.

Los detractorire tendrán dudas sobre el cambio o estarán directamente en contra de él. Esta
resistencia puede tener su origen en diferentes causas, como malas experiencias anteriores,
miedo al cambio en general, inseguridad sobre la implantación en el proyecto que propongas en
concreto o incluso cuestiones personales. Como parte del proceso, debes decidir cómo gestionar a
estos detractores. Los más radicales recomiendan ignorarles o incluso prescindir de ellos en el
proyecto o en la organización. Personalmente, creo que es más interesante tratar de conseguir su
apoyo o al menos cooperar con ellos para entender cómo podemos reducir su desconfianza. Si
decides tratar de ganarte su apoyo, algo que te recomiendo, ya que gestionar un proyecto piloto
en un entorno con muchos detractores puede ser un dolor de cabeza, es importante que aportes
mucha información y transparencia y que dialogues con ellos para responder a sus dudas. Algunas
de estas personas en contra del cambio sostendrán que la gestión ágil eliminará documentos y
definiciones o que las iteraciones no encajan en vuestro modelo de trabajo. Puede que tengan
miedo de no tener una definición clara y completa antes de empezar. Si siempre ha habido
especificaciones muy claras, diseñar de manera iterativa suele causar mucha desconfianza.
Además, puede que piensen que permitir cambios en requisitos una vez iniciado el trabajo
arruinará el proyecto. Te recomiendo que no les contradigas, sino que te centres en hacerles sentir
escuchados y convencerles de que estarás atenta a estos problemas. Puedes recurrir al propio
Manifiesto Ágil en este proceso o a los casos de éxito en otras empresas para apoyar tus
argumentos y poner foco en las ventajas de las metodologías ágiles y del diseño iterativo. Negocia
tus procesos ágiles con estos detractores. A fin de cuentas, el propio Manifiesto Ágil pone a las
personas por delante de las metodologías. Asegúrate de que la información, tanto la buena como
la mala, está siempre disponible. Establecer reuniones o comunicaciones frecuentes con ellos
puede ayudar a aportar transparencia. Por último, celebra los pequeños progresos que realices en
la transición para hacerlos visibles. Piensa en celebrar de manera ágil. En lugar de esperar al final
del proyecto piloto para comunicar mejoras, comparte avances frecuentemente.

Gestión del cambio

La gestión del cambio es un área de estudio empresarial que observa y recomienda procesos para
apoyar a los individuos y las organizaciones en sus transiciones. Los primeros estudios de esta
disciplina son de los años 60, pero han ido evolucionando y a día de hoy existen incluso diferentes
escuelas. La gestión del cambio sostiene que las transformaciones y transiciones pasan por
diferentes fases y proponen acciones o incluso evaluaciones que se pueden realizar en cada paso
para guiar los procesos.

Uno de los modelos de gestión del cambio más populares es el modelo de 8 pasos de Kotter. Esta
teoría propone:

- Comenzar creando sentido de urgencia, informando de las ventajas del cambio y

ayudando a visualizar el potencial retorno de la inversión.
- Como segundo paso, Kotter invita a identificar la coalición de promotores del cambio,
líderes de la empresa que comparten la visión y están a favor del cambio. Idealmente, en
varias funciones y departamentos de la organización para capilarizar su influencia.
- ¿Recuerdas el sistema circulatorio? Las venas y arterias llevan la sangre a todas las partes
del cuerpo, pero son los capilares los que llegan a las partes más alejadas del corazón. Esta
capitalización consiste precisamente en eso, en aprovechar las vías disponibles para llegar
no solo a los niveles principales de una organización, sino a cada pequeño grupo y, en
última instancia, a cada persona. Una vez formada esta coalición, se propone la creación
de una visión compartida del cambio en colaboración con estos promotores. Cada uno
conoce bien sus funciones y problemas y podrá contribuir a definir la estrategia de la
transición.
- El cuarto paso es comunicar esta visión al resto de la organización y abrir vías de
comunicación para
- Como quinto paso, responder las dudas de los detractores y eliminar los obstáculos.
 - El sexto paso es la celebración de las pequeñas victorias del proyecto. Si se han definido
de manera correcta unos objetivos y se han establecido formas para medir el progreso en
ellos, será muy fácil celebrar hitos intermedios. Estos motivarán a los promotores y
contribuirán a ganar la confianza o incluso a conseguir el apoyo de los detractores.
- El séptimo paso de la propuesta de gestión del cambio de Kotter es la construcción sobre
el cambio, la mejora continua. Cambiar no es suficiente. La clave de la gestión del cambio
es refinar y mejorar en cada iteración.
- Por último, una vez la organización es capaz de mejorar de manera continua iterando
sobre sus propios cambios, estará en condiciones de anclar esa cultura del cambio y de
utilizarla para continuar descubriendo e implementando iniciativas que le aporten valor y
ventaja competitiva. Hacer grandes cambios suele generar estrés o incluso intimidar a las
personas más conservadoras, pero seguir el modelo de 8 pasos de Kotter o alguna de las
propuestas similares puede ayudar a generar confianza y facilitará la transición.

Definición de motivación y objetivos

Una vez hayas comunicado la propuesta de transicionar a la gestión ágil de proyectos e
incorporado todas las dudas y propuestas de miembros del equipo o del liderazgo de la
organización, será el momento de definir la motivación y objetivos compartidos para el cambio.

Los objetivos deben ser claros y relevantes y te recomiendo que sigan el conocido marco SMART,
siendo específicos, medibles, alcanzables, realistas y temporales. Además, puedes usar marcos
como OKR, siglas en inglés de objetivos y resultados clave, que además liga la consecución de
estos objetivos a indicadores clave, facilitando su medición.

Tratándose de un proyecto piloto, te recomiendo incluir de manera explícita un objetivo

relacionado con la toma de decisiones sobre la transición a gestión ágil de proyectos. Primero
debemos conseguir información para analizar si la gestión ágil de proyectos es viable en nuestra
organización para el tipo de proyecto propuesto. En el primer proyecto verás si las ventajas
enunciadas se materializan y seguramente descubrirás riesgos o problemas que no se conocían al
inicio de la transición. Incluye además al menos uno de estos dos objetivos en relación con tu
producto o servicio. La solución de problemas críticos o la creación de nuevo valor para los
usuarios o de una ventaja competitiva para la organización. Estos dos objetivos se relacionan a
veces con elementos de la literatura infantil que suenan ya un poco anticuados, matar el dragón y
salvar a la princesa. Haz que los objetivos de tu proyecto piloto estén relacionados con una de
estas dos opciones.

Algunos ejemplos de objetivos del tipo «matar el dragón» son evitar quedarnos desfasados con
nuestras propuestas por tardar demasiado en definirlas, ahorrar dinero en materiales porque los
cambios se reciben muy tarde en el proyecto y los materiales se piden al inicio o reducir
problemas de calidad porque se lanzan nuevas versiones muy grandes en vez de cambios
pequeños. Si buscamos ejemplos de objetivos del tipo «salvar a la princesa», podríamos hablar de
flexibilizar los cambios, salir más rápido al mercado o poder realizar un mayor número de
experimentos en un periodo determinado. En cada organización, o incluso en el diálogo con cada
persona, encajará mejor una de las dos propuestas y dependerá enormemente del contexto y de
la cultura de las mismas.
 Invierte tiempo en tus objetivos y motivaciones y asegúrate de que son conocidos por todos.
Incorpóralos a tu discurso y a las comunicaciones sobre el proyecto, es preferible que comuniques
estos objetivos y motivación de más a que no consigues que lleguen a todos. Además, deberás
medir el progreso y éxito de tu proyecto a través de la consecución de estos objetivos, así que
asegúrate de monitorizarlos de manera frecuente y de comunicar los avances y problemas de
manera temprana.

Roles en equipos ágiles (SCRUM y no SCRUM)

En cada una de las metodologías ágiles se proponen composiciones y roles diferentes para los
equipos. Quiero comentarte algunas de las propuestas más habituales para que puedas
entenderlas y elegir cuál es la más adecuada para tu proyecto o qué componentes de cada una
puedes aprovechar y adaptar en tu propia propuesta.

En la metodología XP, por ejemplo, se proponen 7 roles con perfiles y tareas muy específicas. El
cliente interno o externo, aunque parezca sorprendente, se incluye como parte del equipo y
participa de sus rutinas, definiendo las prioridades. Si el cliente no está disponible o capacitado
para jugar este rol, el rol de cliente lo puede ejercer un gestor de proyecto o un programador
experto en el equipo. El equipo de XP incluye además uno o varios programadores, un encargado
de pruebas o tester y un encargado de seguimiento o tracker. Como ves, las funciones técnicas
quedan muy definidas y especializadas. Además, en un equipo XP encontraremos un entrenador o
coach, un consultor y un gestor, también llamado big boss o gran jefe. En este caso los perfiles son
bastante especializados y tienen su propio nombre.

En Scrum, en cambio, se propone una estructura algo más flexible y que no incluye al cliente, sino
a los usuarios y a los stakeholder o partes interesadas, que pueden incluir o no al cliente. Scrum
introduce además la figura del product owner, la persona que se encarga de definir las
necesidades del producto y de definirlas y priorizarlas. Estas definiciones y prioridades son
entregadas por el Scrum master al resto del equipo. Curiosamente, Scrum no diferencia otros
roles dentro de este equipo. A diferencia de XP, no hay programadores ni testers y todos los
miembros del equipo se reparten esta responsabilidad.

Por darte otro ejemplo, en Disciplined Agile Development otra metodología, se introduce además
el rol de arquitecto o el de experto en el dominio.

Como ves, no hay una sola manera de configurar los equipos y roles de un proyecto ágil. Evalúa las
alternativas y escoge la que mejor se adapte a las necesidades del proyecto y a la cultura y
estructura actual de la organización. Además de atendiendo a sus roles, te recomiendo que
configures tu equipo atendiendo a las personalidades de los miembros que lo componen. Reúne a
un grupo de personas compatibles, que compartan puntos de vista y formas de comunicación o
que se complementen. Sobre todo tratándose de un proyecto piloto, asegurar que el equipo es
compatible y capaz de trabajar para conseguir los objetivos propuestos supone partir con varios
puntos de ventaja.

La formación del equipo ágil para el cambio

Una vez hayas entendido los diferentes tipos de equipos ágiles y sus roles, has decidido cuál encaja
mejor con tu proyecto piloto y la cultura de tu organización y has identificado a los individuos de
tu organización que quieres incorporar a tu primer equipo ágil, es necesario que inicies la
formación y construcción de este equipo.

La construcción de equipos se usa para mejorar el rendimiento de los equipos, así como las
relaciones interpersonales dentro del mismo. Empieza asegurándote de que todos los miembros
del equipo conocen el objetivo y el propósito del proyecto y de la transición de gestión en cascada
a gestión ágil. Trabaja en definir las expectativas de la organización en relación al equipo, del
equipo en relación a la organización y al proyecto, y del equipo en la relación de los miembros del
equipo. Este paso puede incluir acuerdos sobre qué se considera un requisito listo para trabajar en
él, cómo se define una tarea finalizada o cómo se gestionan los problemas. Fomenta además el
lado personal del trabajo en equipo. Conocer y entender a las personas con las que trabajamos
aumenta la empatía y mejora la comunicación. Esto es especialmente importante en los equipos
de trabajo en remoto, ya que en estos los espacios para desarrollar relaciones personales no son
naturales y hay que crearlos de manera artificial. Asegura, además, que la comunicación entre
todos los miembros del equipo es excelente. Fomenta y da la bienvenida al feedback positivo o
negativo y asegúrate de que todos los miembros del equipo sientan que pueden comunicar sus
preocupaciones y hacerlo en un espacio libre de crítica. Celebra cada pequeño éxito y reconoce el
trabajo del equipo para mantenerlo motivado. Muchas veces ponemos demasiado foco en
resolver los problemas y demasiado poco en celebrar los pequeños avances. Asegúrate de darles a
las cosas positivas y a las cosas negativas el espacio y la atención que merecen. Por último,
fomenta y celebra la diversidad. Los usuarios de los productos y servicios que creamos suelen ser
muy diversos y los miembros de los equipos de trabajo, por el contrario, tienden a mimetizarse y a
ser muy parecidos. Incluye a personas que tengan diferentes tiempos dentro de la organización,
que vengan de funciones o departamentos diferentes y que tengan perfiles demográficos y
socioculturales variados. Celebra cada diferencia y trata de asegurar que tu equipo es capaz de
empatizar y entender a diferentes perfiles de usuarios y de relacionarse con diferentes grupos
dentro de tu organización.

Tu proyecto piloto, su equipo y sus roles

Durante esta primera fase de la transición de gestión de proyectos en cascada a gestión ágil, el
foco se ha puesto en conseguir el apoyo de la organización, estudiar y decidir un proyecto piloto y
definir las necesidades del mismo, los roles que necesitamos dentro del equipo y las personas
dentro de la organización que nos pueden ayudar a ejecutarlo.

Antes de continuar con el siguiente paso, asegúrate de que esta fase del proyecto tiene un
resultado satisfactorio para todos. Para empezar, asegúrate de que todo el mundo entiende en
qué consiste el cambio, cuál es la propuesta de proyecto piloto y en base a qué criterios se ha
hecho esta selección. Comunica claramente los objetivos de este cambio y los resultados clave que
esperas obtener.

Recuerda que los objetivos que resuelven un problema o que aportan a la organización ventaja
competitiva serán más fáciles de vender. Pon de manifiesto las ventajas de este modelo de gestión
y los beneficios, pero reconoce también sus limitaciones y explica cuál es tu plan de contingencia
para los riesgos que has identificado. Explica que el proyecto se desarrollará de manera ágil, pero
que eso no quiere decir que no se generará documentación, que se descuidará la calidad o que no
se realizarán mediciones. Comparte las diferentes maneras en las que vas a medir la consecución
de los objetivos que se han marcado para el primer piloto y cómo compartirás esta información.

Recuerda que una de las claves de la gestión ágil es la confianza, así que responde todas las dudas
y repite tu mensaje las veces que sea necesario para asegurarte de que todo el mundo está
debidamente informado y preparado. Informa sobre cómo has evaluado el modelo de equipo
necesario para el proyecto piloto en concreto y explica qué roles incluye y cuál es la función de
cada uno de estos roles. Identifica a cada una de las personas a las que has elegido para formar
parte de este primer equipo ágil para la gestión de tu proyecto piloto. Explica las experiencias,
capacidades o cualidades que te han hecho elegir a cada uno de los miembros del equipo y explica
tu plan para cohesionar el equipo y gestionar los posibles conflictos.

Como se encarga de recordarnos el Manifiesto Ágil, lo más importante en un proyecto ágil, más
que la metodología, el proceso o las herramientas, son las personas que lo forman y las maneras
en las que colaboran en la ejecución del proyecto.

El proceso que seguirá el proyecto

Una vez sabemos qué proyecto vamos a usar como proyecto piloto, hemos consultado con todas
las partes afectadas por el cambio para recoger sus impresiones, dudas y recomendaciones y
tenemos clara la composición y roles de nuestro equipo ágil, es momento de acabar de definir y
refinar el proceso o metodología con el que gestionaremos el proyecto.

Como sabes, hay diferentes metodologías que se incluyen en el marco de gestión de proyectos
ágiles y, si sigue los principios y la mentalidad ágil, tu propia metodología puede incluirse en este
marco también. Diferentes organizaciones, proyectos y equipos tienen diferentes necesidades y en
cada caso es posible que haya una o varias metodologías que encajen mejor y otras que no sean
adecuadas en absoluto. Scrum, es una de las metodologías más populares. Sin embargo, algunas
de sus propuestas, como la composición de equipos en roles especializados o los ciclos de trabajo
de duración constante, pueden no ser apropiadas para algunos proyectos. La mayoría de los
proyectos de ingeniería o creación digital, por ejemplo, requieren alta especialización. Hay perfiles
que se encargan de diseñar, otros de analizar, otros de programar o fabricar, y muchos de ellos no
tienen formación para realizar las otras tareas del proyecto.

Scrum tampoco será apropiado en proyectos en los que hay fuertes dependencias en la entrega
del valor producido al cliente final. En Scrum el valor creado debe llegar directamente al usuario
final después de cada iteración. En los proyectos que tienen que ver con entregables físicos, es
probable que las entregas se realicen en temporadas o durante el anuncio de novedades
específicas, por lo que este tipo de cadencia no tendría sentido. En estos casos, usar XP si se trata
de aplicaciones o Manufactura Lean en el caso de productos puede ser más apropiado.

Para organizaciones con equipos de más de 12 personas, ni Scrum ni XP acabaran de funcionar, ya

que fueron diseñadas con equipos más pequeños en mente. Tendrás que recurrir a metodologías
como Less o Scaled Agile, diseñadas a la medida de las grandes organizaciones con grandes
departamentos que funcionan como Scrums de Scrums.

En algunos casos, ninguna metodología puede implementarse de la manera en la que se diseñó.

Estos casos son mucho más complejos y sería recomendable que contaras con asesoría externa y
diseñaras tu propia metodología. Aquí sería interesante que trabajaras para conocer muy bien los
principios de las metodologías ágiles y te enfocaras en su espíritu, más allá de las
recomendaciones específicas de las metodologías, como nombres de los roles, ceremonias o
artefactos. En este proceso de definición de tu metodología ágil, recuerda que esta misma
metodología puede necesitar cambios una vez la enfrentes al mundo real. Mantén una escucha
activa para identificar oportunidades de mejora e incorporar el cambio continuo como parte de la
cultura de tu nuevo equipo y, poco a poco, de toda tu organización.

La transición en acción
El primer sprint
La primera iteración de tu proyecto piloto será un momento frenético y lleno de excitación.
Durante esta primera iteración, que suele durar entre una semana y un mes según el ritmo de tu
organización, habrá muchas preguntas, muchos ajustes que realizar y tendrás que hacer un
seguimiento continuo del progreso y de las métricas de salud que hayas definido para tu proyecto
y tu equipo.

La primera vez de las ceremonias de metodologías como Scrum incluye rutinas que son en general
muy poco naturales para los equipos. Por ejemplo, las retrospectivas o las estimaciones usando
conceptos tan abstractos como los puntos de esfuerzo o las historias de usuario. Por ello, estas
ceremonias requieren de mucha preparación y de explicar a los equipos en detalle las dinámicas,
pero sobre todo sus motivaciones y beneficios. Dale a cada una de estas ceremonias el tiempo que
necesitan y dedícale tiempo en equipo también a analizar los artefactos o entregables con los que
vayas a trabajar según la metodología que hayas elegido. Para esta primera iteración trata de
elegir un objetivo muy claro en el que trabajar. Asegúrate de que el equipo tiene una visión
compartida del mismo y del estado final o beneficio que esperamos obtener en términos de valor
entregado. Centra la atención en la funcionalidad para los usuarios, no en los detalles, y permite a
todos los miembros del equipo aportar sus ideas a estos detalles para crear este valor de manera
colaborativa.

Además de asegurar que las cosas fluyen de manera ágil dentro del propio equipo de proyecto,
durante este primer sprint deberías dedicar tiempo a comunicar el progreso del equipo al resto de
la organización. Siempre, pero especialmente en tu proyecto piloto, debes tratar de dar
información de manera proactiva y de confirmar con las diferentes partes afectadas que están
satisfechas con el nivel de información que tienen. La confianza en que las metodologías ágiles no
nos harán perder el control sobre nuestros proyectos es clave para asegurar la continuidad del
cambio que hemos comenzado, más allá de este primer proyecto piloto. Si el resto de tu
organización no ve un beneficio claro o tiene la sensación de que ha perdido visibilidad sobre el
progreso del trabajo, tendrás problemas para aplicar la gestión de proyectos ágil a más iniciativas.

Los 100 primeros días

El proceso de cambio no termina con la primera iteración del proyecto, es necesario hacer un
seguimiento más detallado de lo habitual durante un periodo de transición. Dependiendo del tipo
de proyecto y de la organización, este periodo de transición será más o menos largo, de entre unas
semanas y varios meses de duración. Si necesitas definir una duración para esta fase, piensa en el
número redondo de 100 días. Creo que 100 días son suficientes para salir del modo de excitación
inicial, entregar algún valor y aprender las primeras lecciones, y no tan largo que el periodo de
transición se diluya en la normalidad del día a día. Haz lo posible para conseguir que la gestión ágil
sea normal cuanto antes.

Aunque tú lo tengas muy claro, durante tus 100 primeros días recuerda permanentemente al
resto de la organización la motivación del cambio y los objetivos que se acordaron perseguir. En
estas semanas verás las primeras dudas y quejas y llegarás a identificar varias necesidades de
mejora en la formación del equipo, la comunicación del objetivo y del progreso del proyecto o la
gestión del cambio. Además, sin lugar a dudas, descubrirás nuevos riesgos en los que no habías
pensado en la fase de definición y tendrás que diseñar nuevos planes de contingencia para
hacerles frente. Como las metodologías ágiles están diseñadas para ser flexibles y muy resilientes
frente al cambio, no debes asustarte en estas situaciones. Transmite calma también al resto de
miembros del equipo y fuera de él. Además de problemas, durante estos 100 primeros días
también descubrirás potencial que pasó desapercibido en la fase previa al proyecto piloto. Puede
que haya habilidades de los miembros de tu equipo que desconocías y que sean de utilidad para el
proyecto, o que descubras nuevas ventajas de esta nueva manera de organizaros y lleguéis a ideas
que os aporten ventajas o abran nuevas vías de entrega de valor. Observa estos eventos como
oportunidades para mejorar y adapta el proceso donde sea necesario. Recuerda que los procesos
y herramientas están siempre al servicio de las personas, no al contrario.

Si todo va bien y estás haciendo el trabajo de iterar en tus procesos de manera correcta, en estos
primeros 100 días realizarás varios ajustes en tu metodología ágil. Es posible que necesites añadir
o eliminar reuniones, que los estándares de calidad cambien o que introduzcas nuevos acuerdos
para mejorar la definición de tus tareas. Durante estos ajustes estarás realizando observaciones y
revisando mediciones de progreso, te recomiendo que vayas compartiéndolas con tu equipo y con
los líderes de la organización. Estarás aprendiendo y confirmando si vas por buen camino,
ajustando tus planes a la realidad de tu proyecto, siguiendo los principios de la mejora continua y
la gestión de proyectos ágil. En este periodo trata de hacer al menos un par de retrospectivas con
tu equipo para poder evaluar juntos vuestro progreso y acordar próximos pasos. Además, haz todo
lo posible por entregar algún tipo de valor a tus usuarios finales para poder confirmar así que los
procesos mantienen o mejoran el valor entregado.

Fricciones ágiles
En el proceso de cambio a gestión de proyectos ágiles es probable que encuentres ciertas
fricciones que tengas que resolver. Estas fricciones son problemas normales que no deben
asustarte. Los estadounidenses suelen referirse a este tipo de problemas como dolores de dientes.
La comparación viene de cuando los niños van haciéndose mayores y necesitan pasar por una fase
de fuertes dolores para sacar sus dientes y poder comenzar a masticar alimentos sólidos. De
manera similar, todas las organizaciones pasan por dolores en su fase de maduración, pero estos
dolores son necesarios para poder pasar a la siguiente fase y nos darán herramientas que
necesitaremos.

Estas fricciones del paso a la gestión ágil son necesarias para encontrar nuestros dientes, nuestras
nuevas fortalezas. Las fricciones más frecuentes vienen de la falta de visibilidad o de
predictibilidad del proyecto o de la necesidad de revisar requisitos o definiciones que se creían
acordados o superados. Para resolver las fricciones del primer tipo tienes herramientas a tu
alcance como los cronogramas u hojas de ruta, donde puedes indicar las fechas más importantes
de entrega de tu proyecto. En la planificación ágil se usan este tipo de herramientas, pero se
utilizan como una herramienta táctica que sigue una estrategia y se actualiza según evoluciona del
proyecto. Al ser un punto de encuentro con las metodologías de gestión tradicional, que suelen
recurrir a diagramas de Gantt, pueden ayudarte a mejorar la confianza en tu proyecto. Asegúrate
de que estas hojas de ruta se entienden como propuestas, que cambiarán al confrontar la
realidad. Para gestionar fricciones relacionadas con la integración del cambio nada mejor que
recurrir al propio Manifiesto Ágil. Recuérdales que el cambio debe ser bienvenido en todo
momento y visto como una ocasión de mejorar el valor final entregado y como algo necesario y
positivo, no como un problema a evitar o un síntoma de que algo va mal. Las metodologías ágiles
han traído al siglo XXI la idea clásica de que rectificar es de sabios.

Presentación de resultados
Las metodologías ágiles son sospechosas de evitar el reporte, pero nada más lejos de la realidad.
Hay herramientas que puedes usar para presentar los resultados al equipo directivo con el fin de
conseguir su apoyo o al equipo del proyecto para motivarles o ayudarles a corregir problemas.

Algunas metodologías definen sus propias herramientas de reporte. En Scrum, por ejemplo, se
habla de gráficas de quemado del trabajo o burnup y burndown. Estas gráficas representan el
trabajo estimado al inicio del proyecto y el progreso en el mismo a lo largo del ciclo del sprint. Si se
ha realizado la planificación del trabajo de manera correcta y el equipo está trabajando a un ritmo
continuo y sostenible en el tiempo, la línea de estas gráficas debería tener una tendencia
descendiente uniforme.

Esta herramienta ayuda a identificar problemas como que se añada nuevo trabajo en mitad del
ciclo de iteración o sprint o que el equipo acumule la resolución de todas las incidencias abiertas al
final del mismo. Podríamos identificar también el caso contrario, en el que un equipo haga la
mayoría del trabajo en pocos días y necesite menos tiempo del previsto para completar las tareas.

Otra medición interesante es la del trabajo no previsto, no para eliminarla por completo, sino
para ser conscientes de la cantidad de tiempo que es necesario reservar a imprevistos.
Además, en proyectos en los que haya mucho foco en la calidad será recomendable saber cuántos
de estos elementos de trabajo no planificado pueden achacarse a una mala definición o
planificación.

Además, recuerda que definimos unos objetivos al inicio del proyecto piloto y unas métricas de
salud del proyecto. Asegúrate de medirlas y compartirlas con el equipo y la organización de
manera frecuente. Queremos ser honestos y poner de manifiesto las métricas positivas y las
negativas, se trata de observar y de aprender juntos. Recuerda que uno de los objetivos del
proyecto piloto es evaluar si esta nueva manera de gestionar proyectos encaja en la organización y
el tipo de proyecto y de equipos con los que trabajamos. No estamos tratando de imponer una
nueva manera de hacer las cosas, sino validando que esta manera beneficiaría a la organización y a
nuestros usuarios. Necesitamos que la medición de datos en esta fase sea escrupulosa, ya que si
no podremos tomar una decisión en la dirección equivocada e impactar de manera muy negativa a
la organización.

Aprendizajes y evolución
La evaluación del proyecto piloto
La evaluación del proyecto debe realizarse en base a los objetivos que se definieron al inicio del
mismo. Siguiendo mi consejo, deberías haber definido unos objetivos relacionados con la
propuesta de valor o la resolución de un problema y otros relacionados con la adopción de las
metodologías ágiles específicamente. Aunque estos criterios y objetivos serán diferentes en cada
caso y deben definirse a medida para cada organización y proyecto, en términos generales, puedes
evaluar tu proyecto respondiendo a las siguientes preguntas.

- ¿La organización ha entendido y percibido las ventajas de las metodologías ágiles? Puedes
evaluar esto realizando entrevistas entre personas que formen parte o no del proyecto
piloto.
- ¿El equipo ha sido capaz de mantener o mejorar la calidad de su trabajo? Si has tenido
muchos errores y el resultado final del proyecto no ha pasado los estándares de calidad y
habitualmente eran satisfactorios, es posible que debas reconsiderar la conveniencia de
usar metodologías ágiles, o quizás hayas elegido un proyecto que no era apropiado para tu
primer piloto.
 - ¿Hemos conseguido entregar valor a usuarios finales de manera iterativa? Como deja claro
el Manifiesto Ágil, la principal medida de progreso es la existencia de una solución usable.
- ¿Hemos podido responder a las necesidades de cambio? Como sabes, prácticamente por
fuerza, habremos tenido que cambiar de planes en al menos una ocasión. La cuestión es si
hemos sabido hacerlo de una manera efectiva y con el menor impacto posible.

Si la respuesta a la mayoría de estas preguntas es afirmativa, seguramente a la hora de analizar tus

indicadores te encuentres ante un caso de éxito. Si ha respondido que no a todas o casi todas las
preguntas, en cambio, es posible que necesites revisar tu estrategia y analizar qué factores del
proyecto o de la manera en la que se ha implantado la metodología ha afectado negativamente.

¿Hay vuelta atrás?

Me gustaría poder decirte que tu proyecto piloto será un éxito, que al finalizar toda tu
organización estará lista para cambiar todos los proyectos a una gestión ágil y que después de
haber seguido mis consejos es imposible que algo salga mal. Sin embargo, muchos proyectos
pilotos ágiles acaban en una anécdota. Algunas organizaciones no están preparadas para el
cambio y algunos proyectos son realmente difíciles de gestionar de esta manera.

Una de las ventajas de la mentalidad ágil es que espero que a estas alturas sepas que detrás de
este fracaso se encuentra una gran oportunidad de aprendizaje. Colabora con todo el equipo del
proyecto para devolver este a la fase de gestión de proyectos tradicional en la que mejor encaje
después de la experiencia piloto. Algunos proyectos se paran tras una o dos iteraciones y es mejor
empezar desde cero. En otros casos se habrá realizado un avance considerable y podremos
gestionarlo como si se tratara de un proyecto en la fase de evaluación de calidad. Además, te
recomiendo que trabajes con el equipo del proyecto para realizar lo que se llama un análisis post
mortem del fallo en el que saques a la luz las áreas de la organización que lo ocasionaron. Si
afectaron al éxito del proyecto en modo ágil, puede que también sean un problema en esta nueva
etapa y merece la pena que les dediques atención. Presenta este informe junto con las métricas al
liderazgo de la organización y asegúrate de que queda disponible para cualquiera que lo necesite.
Puede que en unos años alguien en tu organización vea este curso y decida retomar lo que has
empezado.

Waterfall por fuera, ágil por dentro

En algunos casos, en el momento de analizar el éxito del proyecto piloto la organización no estará
del todo decidida a aceptar el marco de gestión de proyectos ágiles en su portfolio. Sin embargo,
el equipo quizás sí haya notado un impacto positivo y quiera continuar trabajando de esta manera.
En estos casos es posible llegar a un punto intermedio, que llamo «en cascada por fuera pero ágil
por dentro». Este modelo respeta las fases de un proyecto en cascada: análisis, diseño,
implementación y evaluación, pero realiza iteraciones dentro de cada una de estas fases y de
manera especialmente significativa dentro de la fase de implementación.

Tal vez queramos incorporar el concepto de trabajo en pares de XP a la hora de revisar datos o
realizar reuniones rápidas diarias de actualización, como hacen los equipos de ingeniería,
informática o servicio en hoteles y restaurantes, o realizar sprints de diseño en los que durante 3
días nos dediquemos a analizar las fortalezas y debilidades de nuestra marca. Uno de los aspectos
que más me gusta de la mentalidad ágil es que puede tener un gran impacto a través de cosas tan
sencillas como las que acabo de mencionar. Estas prácticas pueden incluirse en un proyecto
gestionado de manera tradicional, con documentación extensiva, contratos estrictos y fases
diferenciadas en un modelo mixto. Este tipo de marcos de gestión de proyectos es un buen
compromiso y puede ser efectivo en proyectos que por su tamaño, duración o industria tengan
requisitos más estrictos.

En industrias como la farmacéutica, la construcción o la producción audiovisual no es posible

adoptar modelos 100 % ágiles, pero con el trabajo adecuado sí es posible incorporar algunos de los
elementos de estas metodologías en el funcionamiento interno de los equipos. Asegurando que de
cara al liderazgo, al cliente o a las entidades certificadoras la experiencia no cambia y es la misma
que en cualquier proyecto gestionado de forma tradicional, es posible trabajar de manera interna
beneficiándonos de las ventajas de la mentalidad ágil.

¿Sólo para equipos pequeños? Agile a escala

La mayoría de las metodologías ágiles y de los consejos para su implementación en equipos tienen
en mente a organizaciones pequeñas y medianas y equipos de no más de 12 personas. ¿Quiere
esto decir que no pueden aplicarse a grandes organizaciones? Nada más lejos de la realidad.

Algunas grandes empresas han adaptado las metodologías ágiles a sus necesidades, gestionando
equipos de cientos de personas siguiendo estos principios y obteniendo resultados en forma de
ahorro, mejora de la velocidad, de tiempo al mercado, etc.

- SAFe, por ejemplo, el framework de escalado ágil, propone diferentes prácticas a la

medida de grandes corporaciones o agencias gubernamentales.
- Less es algo menos complejo y pone el foco en la excelencia técnica. Ha ayudado a
empresas de miles de trabajadores en la creación de productos intangibles, como
aplicaciones, o tangibles, como relojes inteligentes.
- Otra metodología llamada ágil disciplinada tiene aplicación incluso en entidades tan
tradicionales como bancos y ha servido en algunos casos para gestionar la impresionante
cifra de 800 equipos de manera ágil.

La mentalidad ágil puede transformar tu manera de trabajar a nivel individual, pero también la de
organizaciones con cientos de miles de trabajadores si se realiza la transición adecuada.

Conclusiones

Últimos consejos para la transición a la mentalidad ágil

Creo que lo más importante es que todo el mundo entienda la motivación del cambio y que es
algo que va más allá de usar una metodología en concreto o ciertas herramientas. Aunque hay
mucha información en línea, contar con formación especializada puede ser de ayuda. Hay muchas
personas que ya han pasado por este proceso y que son especialistas en formar y acompañar a las
organizaciones en su propia transición.

Tras la formación, diría que es importante que hagas una planificación del cambio, a ser posible de
manera iterativa y con mentalidad ágil. Cambiar la manera de trabajar de toda una organización,
especialmente si se trata de una grande, puede suponer un enorme reto.

Trata de hacer el cambio gradualmente, ganándote la confianza en esta manera de trabajar de un

equipo tras otro y haciendo partícipe al resto de vuestros progresos y aprendizajes.
 Por último, mi consejo es que busques estar continuamente aprendiendo sobre los retos que
otras organizaciones tienen al planificar proyectos de manera ágil. Gracias a la cantidad de
información, grupos de usuarios y eventos de comunidad que se organizan sobre estos temas
puedes tener más puntos de vista de miles de profesionales.

Ágil en acción: construye tú equipo ágil

Prepárate antes de trabajar con ágil
La historia de Agile
Al comienzo, muchos equipos creen que Agile es otra herramienta útil e intentan aprenderla como
si fuera un nuevo deporte. Primero se conoce el material, luego los golpes, luego se aprende a
atrapar la pelota y, al final de todo, el equipo se reúne para jugar. Pero si crees que Agile es
simplemente otro conjunto de herramientas, es probable que no veas beneficios en tu
productividad.

Aquí ya asumimos que cada miembro del equipo conoce las reglas. La clave es cambiar la forma
en la que los miembros juegan juntos. Deben tener más armonía y responsabilizarse por su
trabajo. Empieza a considerar que Agile le cambiará la mentalidad a todo el equipo, que verá su
trabajo de una forma completamente diferente de como lo veía antes. Porque solo después de
cambiar la forma de pensar, los empleados podrán ser capaces de aumentar la eficiencia y la
productividad. Cambiar lo que piensan de su trabajo es mucho más difícil que cambiar su forma de
trabajar. Es como ese antiguo refrán: es más fácil darle a alguien un pez que enseñarle a pescar.
Los equipos pueden cambiar los nombres y las tareas de los puestos, pero un equipo ágil logra
cambiar la forma en la que se ven esos conceptos. Debes modificarles la forma de pensar desde el
principio. Si no, el equipo volverá siempre a sus métodos tradicionales de toda la vida. En casi
todas las organizaciones, para ganar impulso se necesita mantener el rumbo.

La actitud de tu equipo será clave a la hora de evaluar si tu empresa tiene éxito con este método.
Si cambias tu propia mentalidad, podrás cambiar tu forma de trabajar. Si logras cambiar tu forma
de trabajar, también puedes ser más ágil. Y si tú puedes ser más ágil, el resto de la empresa
también querrá cambiar. Cuando analices este modelo, no te centres solamente en los nuevos
roles y responsabilidades. Piensa en la mentalidad detrás de cada uno de esos roles.

¿Cómo hacer para que los miembros del equipo cambien la forma de ver su trabajo? El término
«ágil» es un concepto genérico que abarca varios de los ámbitos más conocidos. Uno de los
procesos más famosos de este método es el Scrum. Seguramente también conozcas la
programación Extrema, la metodología Kanban y la estructura progresiva Agile o SAFe. cada una
de estas metodologías utiliza términos propios para designar los roles. La Kanban es la más ligera y
no trabaja con roles definidos. En este curso, utilizaremos los nombres de un equipo de Scrum.
Pero ten en cuenta que no son los únicos títulos que existen para los roles. Si escoges otro proceso
de Agile, como la programación Extrema, los roles serán similares, pero los nombres pueden
cambiar. En cuanto al trabajo en equipo, puede que Agile te parezca un poco libre. Quizá oigas a
un equipo inexperto que dice: «Cambiamos un poco los roles, pero es para ser más ágiles».

Agile es un método ligero, pero no es tan libre. Los roles del equipo están muy definidos. Así que si
tu equipo es nuevo, quizá te convenga respetar los roles definidos. La parte «ágil» de este proceso
tiene que ver con los métodos ligeros, pero no significa que haya flexibilidad en la estructura del
equipo, en general hay pocas reglas, pero deben respetarse al pie de la letra. Cada uno de los roles
tiene un objetivo claro y que va más allá: que el equipo logre una mejor autoorganización y
adquiera mucho más valor. Si el gerente del equipo sigue los métodos tradicionales, no obtendrán
muchos beneficios al cambiar a Agile. Para que funcione este método, todo el equipo debe ser
ágil. Los roles del equipo no son simplemente pautas a considerar. Son ingredientes
importantísimos para crear tu equipo ágil. Si te saltas uno o cambias otro, estarás poniéndote
obstáculos en el camino hacia un futuro más ágil.

Cómo adoptar Agil en la organización

La actividad que genera el modelo Agile es como el frenesí de un deporte de grandes ligas.
Muchos hablan de Agile, algunos escriben sobre Agile, muchos equipos lo prueban, pero solo unos
pocos juegan Agile a nivel profesional. Una transformación ágil es un cambio importante en los
negocios de siempre. Para empezar, debes prepararte para enfrentar grandes desafíos. Para jugar
como profesionales, tu equipo debe entrenar y comprometerse a cambiar. Para crear un equipo
ágil profesional, debes reestructurar toda la forma en la que piensan su trabajo. La agilidad es una
mentalidad que puede mejorarse, pero no perfeccionarse. Tu equipo siempre estará recorriendo
este camino. No hay fiestas de cierre o informes completos. No hay columnas con casillas de
verificación. Por eso, es muy difícil adoptar este proceso en las empresas. Hay un período de
preparación muy largo para que los empleados cambien la forma de pensar y el marco de tiempo
no está muy claro. Es como una actualización del proceso interminable.

Para empezar a implementar el método Agile, identifica las razones por las que la empresa debe
cambiar. Te ayudará a crear las bases en las que se sustentará la compañía durante este largo
recorrido. No prometas resultados inmediatos: ese tipo de expectativas suele hacer agua y
quedarse en nada. Comienza con una enumeración de los problemas que tienes en los proyectos
actuales. Luego, intenta que todos se pongan de acuerdo en que es necesario un cambio. Es
posible que tu lista de problemas sea algo así:

- Los requisitos de nuestros proyectos son malos.

 Al principio del proyecto no se hizo un esfuerzo por tener en cuenta toda la
información desconocida.
 Al empezar el proyecto, el gerente se hizo cargo de las piezas que faltaban para que la
tarea se cumpliera.
- Nuestros proyectos tienen plazos poco realistas.
Los accionistas o el equipo de ventas no proporcionaron un cronograma realista.
- Las prioridades cambian todo el tiempo.
 Cuando se empieza un proyecto, se transforma en algo completamente distinto de lo
planeado.
 Los proyectos cambian para cumplir con las nuevas prioridades y se salen de control.
- Hay una gran falta de visión a largo plazo, que ocurre cuando se comienza a trabajar antes
de que el equipo comprenda las previsiones para el producto. Algunos miembros
intentarán cumplir según su propia visión del proyecto, que puede no coincidir con la
visión de los interesados.
- Hay una gran falta de comunicación con los interesados. Algunas de las partes interesadas
en el proyecto arrojan las ideas contra la pared a ver qué les rebota. No contestan al
gerente ni al equipo y tardan mucho en dar respuesta.
 - No hay control de calidad para los proyectos. En cuanto parece que el proyecto puede
cerrarse, se entrega.
- El gestor de proyectos lleva muchos encargos al mismo tiempo. Un gestor de proyectos
con muchas tareas a cargo puede ser un problema no solo para sí mismo sino para todo el
equipo.

Puedes utilizar esta lista como punto de partida para tu transformación hacia el método Agile.
Empezar será mucho más fácil si todos están de acuerdo en que hay un problema que solucionar.
Muchas empresas se traban porque invirtieron mucho para llegar a la situación en la que están,
pero igualmente ven que necesitan cambiar. Empieza enumerando qué es lo que falla en la
situación actual. Te ayudará a motivar al equipo para seguir adelante. Cuando todos estén de
acuerdo en que se necesita un cambio, pueden comenzar a transitar por el método Agile. Pero ten
en cuenta que si no hay consenso en la aceptación del problema, deberás esperar un poco.

Presenta Agile a los agentes

Hay diferentes formas de presentar el modelo Agile en tu organización. Tendrás que convencer a
unos cuantos grupos de interés. Los dos grupos más frecuentes son el de patrocinadores
ejecutivos y el de gerentes de desarrollo. Cuando empieces a poner en práctica el método Agile en
tu organización, estos grupos se interesarán por cosas muy diferentes. Querrán oír soluciones a
sus propios problemas.

Los ejecutivos se interesarán más por la previsibilidad y los resultados. En general, este grupo
quiere lograr métodos para que los equipos cumplan con fechas de entrega. Algunos aceptarán
planes anuales, pero la mayoría querrá analizar predicciones de trabajo mensuales. Por eso, a los
ejecutivos debes presentarles el método Agile como un proceso reglamentado de planificación de
entregas. A la mayoría no le preocupa cómo estructuras las reuniones y no tienen mucho interés
en participar en reuniones de equipo, en la planificación o retrospectivas. Con ellos, deja a un lado
estos detalles. Concéntrate en equilibrar la agilidad con la previsión y las entregas.

Los gerentes de desarrollo tienen intereses muy distintos. No les gusta trabajar sin rumbo y bajo
presión. El desarrollo de software implica resolver problemas de forma elegante. Es arte manual. A
los desarrolladores no les gusta que los representantes de los clientes sigan su trabajo y los
presionen para acabar. Estos gerentes exigirán tareas específicas y reuniones de seguimiento cada
dos semanas. Preséntales Agile como un método para definir sus tareas y regular su trabajo.

Cuando hayas identificado estos grupos, podrás empezar a sentar las bases para la transformación
ágil. Estos procesos de agilidad también se denominan «métodos ágiles». Los métodos abarcan las
reuniones de equipo y las nuevas prácticas. Puedes celebrar reuniones de balance de quince
minutos. Eso sería un método ágil. Todos estos métodos se combinan en un proceso ágil o
Framework, que es el conjunto de métodos ágiles relacionados y es una de las muchas facetas de
Agile. Algunos de los procesos más comunes son el Scrum, el método Kanban, la programación
Extrema y la estructura progresiva Agile o SAFe. Es muy importante comprender y asimilar los
términos al principio. Cuando tu equipo se familiarice con ellos, ya podrás empezar. Te
recomiendo que intentes no crearles muchas expectativas sobre esta transformación. Como
cualquier cambio organizativo, llevará tiempo observar los resultados en productividad. Si les creas
demasiadas expectativas, es muy probable que cuestionen y exijan resultados antes de tiempo.
También debes explicarles qué se perderá durante el proceso de transformación. Si no lo aclaras al
principio, puede que más tarde se desbaraten los planes.

El proceso Agile eliminará mucha de la planificación por adelantado. Los equipos ya no trabajarán
con sistemas conocidos como los diagramas de Gantt, los informes de proyectos de Microsoft y
presupuestos que dependen de objetivos a corto plazo. Debes comunicárselo lo antes posible.
Puede ser muy frustrante empezar la transformación y que de pronto un gestor te pregunte por
los diagramas de Gantt. Cuando les hayas hablado de los beneficios y de los desafíos de la
transformación ágil, hazles una recomendación. La mejor forma de acabar tu presentación será
recomendarle al patrocinador ejecutivo que cree un equipo pequeño para probar el proceso. Es
recomendable que el proyecto que se trabaje tenga poca relación con otros proyectos. Además, es
más fácil hacer pruebas en equipos reducidos. Intenta convocar a no más de siete personas. Y
recuerda siempre que Agile es un cambio a nivel de organización. En resumen, fija expectativas
reales y prepara a los ejecutivos para un largo proceso de transformación. Si les pides que
empaquen la mochila para un largo viaje, es más probable que acepten que llevará un tiempo.

Forma el equipo ágil

Define los roles del equipo ágil
Muchas ideas del método Scrum se basan en un artículo de la Harvard Business Review de 1986.
La revista describía la creación de un equipo empoderado en que el que cada miembro tenía una
visión diaria y global del producto. Usaban la analogía con la jugada del rugby y citaban el Scrum
como un ejemplo de trabajo integral o simultáneo. La jugada del Scrum intenta alcanzar un
objetivo en grupo, sin marcar los roles, es decir, como un equipo autoorganizado. El artículo
también introdujo el concepto de equipos interdisciplinarios. Los describía como grupos de
fracciones dentro de la organización, diferentes grupos que, en forma de capas, constituyen un
equipo. En otras palabras, un equipo podía estar formado por representantes del cliente,
verificadores y diseñadores gráficos, por ejemplo.

El Scrum fue una de las primeras estructuras, y es por ello que muchos equipos ágiles utilizan su
terminología para describir los roles, aunque no vean necesario poner en práctica todos los
métodos del proceso. En un equipo de Scrum, hay tres roles oficiales. El propietario del producto,
los encargados del proyecto y el ScrumMaster.

Por lo general, la mayor atención siempre se centra en el ScrumMaster. Se suele creer

erróneamente que este rol es similar al de cualquier jefe de equipo tradicional, pero en realidad se
trata de una combinación entre un administrador, un formador y un entrenador. Se le llama
«maestro» en inglés porque conoce a fondo el proceso del Scrum. Este título tan impresionante ha
causado furor en las certificaciones de Scrum. Nadie quiere ser un facilitador certificado de Scrum,
pero ser ScrumMaster suena a que se tiene muchísimo poder. Tiene mucho peso, como ser
maestro jedi. Pero en realidad, el rol de ScrumMaster es mucho más práctico. Se pasa la mayor
parte del tiempo eliminando obstáculos para el equipo y asegurando que cuenten con un buen
ambiente de trabajo. Recuerda siempre que el ScrumMaster trabaja para el equipo. Si esta
persona proviene de un ámbito de gestión, puede significar un gran cambio. Un ScrumMaster que
muestre demasiada autoridad causará una gran confusión. El equipo debe organizarse a sí mismo
y con el apoyo del ScrumMaster, quien no debe intentar controlar la forma en la que se entrega el
producto. Si eres el ScrumMaster de tu equipo, recuerda que la clave es la moderación. Ten en
cuenta siempre que si tú tomas el control de la gestión, los estás alejando de la organización
autonómica.

Uno de los roles más importantes en un equipo ágil es el de propietario del producto. que es quien
tiene todo el poder en el equipo. Representa los intereses del cliente como dueño del producto.
En nombre del cliente, se asegurará de que el equipo se esfuerce por entregar un producto de la
mayor calidad posible. El representante debe tener comunicación directa con el cliente. Trabajará
con los usuarios finales del producto para definir las líneas de trabajo del resto del equipo. La
prioridad del representante del cliente será trabajar para la lista de trabajo pendiente o producto
backlog, que es una lista, en orden de prioridad, de funciones y características que el cliente
requiere para el producto final. El mayor desafío que se le presenta es el de establecer las
prioridades. Como puedes imaginar, no todos los clientes estarán de acuerdo en las prioridades. El
dueño del producto tiene la última palabra para determinar qué se hace primero. Tienen que
entregar un software que cumpla con los requisitos de todos. Su papel consiste en ser la mano
firme que corta el pastel en una fiesta de cumpleaños alborotada.

Y por último, tenemos a los desarrolladores, que son todas las personas involucradas en el
desarrollo del producto. Si provienes de un ambiente de desarrollo de software, es muy probable
que pienses que se trata de los programadores de toda la vida. Pero también abarca a quienes
evalúan el software, a los diseñadores gráficos y a los especialistas en bases de datos. La idea de
un equipo ágil es que sea multidisciplinario. Los programadores deben poder probar el software y
los ingenieros en bases de datos deben poder programar. Por eso no se distinguen estos roles,
todos están agrupados en el de desarrollador. En un proceso Agile, los desarrolladores son quienes
poseen todo el conocimiento y es muy importante que puedan calcular y valorar su trabajo antes
de comprometerse con las entregas. Quienes ejerzan este rol deben tener muchas habilidades
diferentes, porque tienen la responsabilidad compartida de producir y ningún miembro debe
esperar a los demás si él puede cumplir.

Sé ágil con el ScrumMaster

El rol del ScrumMaster de Agile se suele interpretar mal. Muchas organizaciones consideran que
son los gerentes responsables del equipo ágil. Si los proyectos salen mal, creen que es a ellos a
quienes tienen que culpar. Un equipo ágil tiene una organización autónoma. Si consideramos que
el ScrumMaster es el jefe, disolvemos la responsabilidad compartida. Es muy importante recordar
que este rol es el encargado de gestionar la estructura y el proceso, pero no al equipo. El
ScrumMaster administra el proyecto, elabora los informes, y elimina obstáculos y distracciones.
Pero las etiquetas importan, y si un rol lleva incluido el título de «maestro», es claro que deberá
ejecutar ciertas tareas de gestión. Por lo general, a los ScrumMasters les resulta muy difícil
intentar reducir su propia responsabilidad y autoridad. Un buen ScrumMaster se posiciona detrás
del equipo y no al frente. Debe actuar a su sombra.

Hace un tiempo, trabajé en un proyecto en el que, al adoptar el método Agile, los gerentes
simplemente se cambiaron el título a ScrumMasters. Creían que el nombre mismo indicaba que el
rol debía ejercerlo un gerente con experiencia. Y siguieron actuando como lo habían hecho
durante toda su carrera. Lideraron el proyecto, se comunicaban con los interesados y encabezaban
las reuniones. Estos entusiastas ScrumMasters acabaron ralentizando todo el proceso ágil y
confundiendo al equipo. Los ScrumMasters debieron desaprender las habilidades adquiridas
durante su carrera. En lugar de conducir al equipo, aprendieron a asesorarlo. En vez de encabezar
reuniones, debían proponerlas y oír al equipo. Empezaron a hablar menos y a escuchar más. Al
principio fue un choque cultural, pero después de algunos meses, la mayoría estuvo de acuerdo en
que el resultado era lo que siempre habían esperado. Podían motivar al equipo sin tener que
responsabilizarse por su trabajo.

Un ScrumMaster debe facilitar las reuniones del equipo ágil. Si un ScrumMaster comienza a pedir
informes y actualizaciones al equipo, está liderando la reunión, no facilitándola. Por eso, la mejor
opción es que se sienten a un lado durante la reunión, para no imponer una imagen de autoridad.
Si el equipo decide cambiar el programa de la reunión, es el ScrumMaster quien debe volver a
encauzarlo. Su responsabilidad es que el trabajo se ajuste a los parámetros de la metodología
Agile, pero no la productividad del equipo. También debe elaborar diagramas para ilustrar, por
ejemplo, las cuestiones que se lograron durante las últimas dos semanas o para demostrar si las
previsiones fueron acertadas o no. La función de estos informes no es humillar al equipo. No es
tarea del ScrumMaster elegir al mejor empleado del mes, porque eso no tiene que ver con el
proceso. Felicitar a miembros individuales del equipo no tiene nada que ver con el ámbito de
trabajo del ScrumMaster.

Por último, el ScrumMaster debe eliminar los obstáculos que se interpongan en el camino del
proyecto. Si un miembro del equipo señala un obstáculo, el ScrumMaster debe ponerse manos a la
obra. Por ejemplo, debe asegurarse de que las computadoras lleguen a tiempo o, aunque sea
incómodo, hablar con ese miembro del equipo que levanta la voz por teléfono. Debe eliminar las
barreras que impiden que el equipo alcance la cima de la productividad. Es responsable de buscar
un mejor espacio de trabajo, por ejemplo, o de asegurarse de que el cliente se reúna con el
equipo. Sus tareas también incluyen las más corrientes y mundanas, como pedir la pizza para las
fiestas de oficina. El ScrumMaster es el «jefe sirviente» del equipo. Es quien se gana la autoridad
por conocer todo el funcionamiento. Debe conocer a fondo el método Agile y ganarse la autoridad
enseñándole al equipo cómo seguir los procesos. También debe adquirir competencias
aparentemente menos importantes. Un miembro del equipo que se siente menospreciado por el
resto o la falta de espacio en la oficina son obstáculos. Pero también los problemas emocionales o
malentendidos entre empleados. El ScrumMaster debe poseer inteligencia emocional para tratar
estos problemas y proponer soluciones.

El trabajo del propietario del producto

Un equipo ágil debe fomentar siempre una conexión estrecha entre el cliente y los
desarrolladores. No debe pensarse que el cliente es alguien de fuera del equipo, porque es un
motor crucial para su funcionamiento. El cliente le ordena al equipo que presente resultados de
alto valor en metas cortas de dos semanas. Por ende, el cliente siempre estará muy involucrado en
los resultados del proyecto. No asigna una tarea y se sienta a esperar. El cliente siempre debe
participar e involucrarse en el proceso. Si el producto falla, también se hará cargo de la
responsabilidad. Está muy claro que esta forma de verlo es muy diferente de la relación tradicional
entre clientes y compañías. Por lo general, entre el cliente y el equipo responsable del proceso
siempre hay un intermediario.

En un proyecto tradicional, el cliente hace un pedido y se queda esperando que se cumpla con lo
exigido. El modelo Agile para la ejecución de las tareas es muy diferente. El cliente es un miembro
más del equipo, es responsable de la ejecución del proyecto. Dependiendo del proceso Agile que
se ponga en práctica, el cliente puede llamarse de formas diferentes. En la programación Extrema,
se le llama «representante del cliente». En Scrum, se le llama «propietario del producto». El
propietario del producto ayuda a crear la visión del producto. Divide el producto en pequeños
trozos y elabora una lista de prioridades para el trabajo. Esa lista suele llevar el nombre de «lista
de pendientes del producto», y en ella se enumeran historias de los usuarios, narraciones cortas
de la función del producto desde el punto de vista del usuario. El dueño del producto se encargará
de mantener la lista de pendientes durante el proyecto. Si ciertos aspectos tienen una menor
prioridad o si los desarrolladores no pueden completar una tarea en dos semanas, puede
modificar la lista.

El dueño del producto es, entonces, la estrella que marca el camino del proyecto. Es el encargado
de que el equipo no pierda el rumbo y siga la lista para que el resultado sea el mejor. El dueño del
producto también establece los criterios de aceptación. Así, los desarrolladores no tienen que
estar adivinando qué quiere el cliente. El dueño del producto les comunica qué podrá satisfacer al
cliente y da la orden de comenzar. Cuando un desarrollador empieza a tachar elementos al
comienzo de la lista, puede estar seguro de que se está encargando primero de las partes más
importantes del proyecto. Es recomendable que el dueño del producto tenga una conexión directa
con la persona que financia el proyecto, el patrocinador. El propietario del producto es miembro
del departamento del patrocinador, cosa que, en la práctica, es muy difícil. Es un trabajo de
tiempo completo, y es normal que el patrocinador no quiera que un experto tenga dedicación
completa en un proyecto. Cuando esto ocurre, hay que recordar que el dueño del producto debe
estar completamente integrado en el equipo. Es mucho mejor contar con alguien menos experto
pero con más disponibilidad. No es necesario contar con un experto, pero sí con alguien que hable
con los expertos y tome decisiones en tiempo real. El propietario del producto es el mejor recurso
para extraer el talento de la organización. Será responsable de seleccionar expertos en la materia
y de asegurarse de que todo el conocimiento de la organización esté disponible para el equipo. El
propietario del producto suele ser el rol más desafiante en un equipo de Scrum. Es el dueño del
producto.

Deja que el equipo se autogestione

Piensa en cómo eran los empleos a principios del siglo XX. Se trabajaba en la industria del
automóvil, en la construcción o en tiendas minoristas. En Estados Unidos, la gente migraba a los
grandes centros de contratación como Chicago, Nueva York o Detroit. Hoy por hoy es muy difícil
presentarse para un puesto y obtenerlo, y más difícil incluso es mantener un puesto así. Muchos
de esos empleaos seguían una jerarquía clara. Había empleados y jefes. Los jefes mandaban a los
empleados. Y si los empleados querían conservar su trabajo, hacían caso a sus jefes a rajatabla.
Muchos de los empleados de la época trabajaban duro pero podían reemplazarse. No se les
contrataba por lo que sabían, sino por la capacidad de aguantar un día entero de trabajo duro. Los
que tenían los conocimientos y habilidades eran los jefes. A ellos se los ascendía y formaba.

ahora a un proyecto moderno y ágil. En un equipo ágil hay diseñadores gráficos, desarrolladores e
ingenieros de bases de datos. Los miembros del equipo pasan años capacitándose. Los
diseñadores estudian en la universidad y trabajan con programas sofisticados. Los desarrolladores
estudian ingeniería y son expertos en varios lenguajes de programación. Los ingenieros de bases
de datos seguramente tengan certificaciones de Oracle o de Microsoft. No se puede pretender que
el jefe tenga toda esta experiencia. No puede tener todos esos títulos, conocimientos de
programas y de lenguajes de programación. Por ello, es muy difícil liderar equipos de trabajo como
lo hacían los jefes de hace unos cien años. Hoy por hoy, un miembro del equipo puede tener más
conocimientos que sus jefes. Y es por ello que un equipo ágil está mucho mejor capacitado para
tomar muchas de las decisiones en un proyecto y es la razón por la que se organiza a sí mismo.

Para los gestores de proyectos que llevan toda la carrera gestionando equipos, esto de la
autoorganización puede parecer una fantasía. Piensan en unicornios con estrellitas bajando por
arcoíris. Les puede parecer que es una promesa que nunca se cumplirá, como un horno que se
limpie solo o una planta que se riegue a sí misma. Creen que la autoorganización es pura cháchara.
En algún momento, alguien tendrá que limpiar el horno o regar las plantas. Pero la autonomía en
la organización no significa eliminar al gestor del equipo, sino que los miembros que realizan el
trabajo tengan la responsabilidad de organizarlo.

Cuando trabajé como gestor de proyectos, cada vez que empezaba un encargo se repetía el
mismo ritual. Primero celebraba una reunión con el equipo para estimar cuánto tiempo llevaría
completarlo. Siempre me decían que me había olvidado de llamar a la única persona que lo sabía,
así que convocaba otra reunión con ese miembro que faltaba. Entonces, el equipo me decía que
no había información suficiente como para poder dar una estimación. Yo contestaba: «Claro que
no hay información suficiente. Por eso es una estimación». Insistían en que les diera más
información, pero lograba sacarles una fecha a regañadientes. Yo sabía que ese plazo era el doble
de lo que necesitarían en realidad. Tenían razón. Necesitaban más información. Pero yo
igualmente apuntaba esa fecha inflada en el programa y armábamos el calendario. Yo era el gestor
y me comprometía a entregar dentro de ese plazo. Un equipo autoorganizado asume mucha de la
responsabilidad que antes era solo del gestor.

En un proyecto ágil, es el equipo quien presenta la estimación. Dividen el trabajo en tareas más
simples y así se mejora su rendimiento. En el método Agile se reconoce que ese ritual de la
estimación deja al gestor en una posición injusta. Es el gestor el responsable del resultado, aunque
no sepa muy bien qué es lo que se está estimando. El gestor puede presionarlos a todos para
acabar, pero no sabe programar ni diseñar los gráficos. La autoorganización no significa que se
reduzca la autoridad del gestor del proyecto, sino que se divide la responsabilidad del trabajo
entre todo el equipo. El problema aumenta a medida que el equipo adquiere más capacidades y el
trabajo se torna más complejo. Si eres el ScrumMaster de tu equipo, intenta evitar que una sola
persona lo gestione. Si el equipo tiene un gestor, asegúrate de que entienda que no se trata de un
equipo tradicional. El gestor del proyecto no es el responsable de establecer estimaciones y de
liderar el trabajo.

Protege al equipo con el gestor de proyecto

Dentro del proceso Agile, el puesto del gestor del proyecto no tiene una definición clara, y es
entendible que esto cause fricción y problemas para muchos gestores. Es difícil que los gestores
acepten el modelo Agile si creen que su rol se hace poco necesario. Y la gestión tiene ciertos
problemas estructurales que pueden ser un obstáculo para muchos gestores que buscan su
camino en este modelo. Uno de los problemas es que muchas compañías creen que en ese puesto
se generan talentos para puestos con más responsabilidad. Por eso, los gestores de proyectos
suelen ser muy ambiciosos y tener muchas conexiones. Hay muchos gerentes y directores que
empezaron como gestores de proyectos y suelen ver la estructura de la empresa desde esa
perspectiva. Esto provoca que los cambios sean más difíciles e inciertos.

Para poder aceptar algunos principios clave del método Agile, el gestor debe tener la mente muy
abierta. Los equipos autoorganizados, las listas de prioridades y el rol del ScrumMaster son muy
diferentes de los principios de una gestión tradicional. Pero a pesar de estos desafíos, es muy
posible que un gestor aporte mucho valor a un equipo ágil. Por lo general, el gestor puede tomar
dos caminos. Puede seguir trabajando como gestor a nivel de equipo, dentro del equipo, o
también puede trabajar a nivel de cartera. Los proyectos se dividen en grupos que se denominan
carteras, y el gestor de proyectos puede coordinar todos los grupos de proyectos de la cartera ágil.
No todos los gestores de proyectos tienen la capacidad de ascender al nivel de cartera y no todas
las organizaciones ofrecen esta posibilidad, así que lo más común es que los gestores de proyectos
sigan trabajando con los equipos. Esto requiere mucho esfuerzo para cambiar. El gestor debe
repensar y volver a evaluar la forma en que se enfocan los proyectos.

Dentro del equipo, el gestor puede traducir el trabajo ágil en términos que sean más fáciles de
comprender para una empresa tradicional. En su nuevo rol, estará protegiendo al equipo de volver
a caer en la gestión tradicional del trabajo. Debe ir en contra de mucho de lo que ha aprendido y
hecho durante la mayor parte de su carrera, y esto requiere mucha profesionalidad. Es casi como
cuando contratan a hackers para encargarse de la seguridad informática. El gestor de proyectos
debe valorar la utilidad del método Agile si quiere que sea efectivo. Deben mantener la calma y
evitar las confrontaciones entre los demás. Y para muchos, este es un proceso largo. para que esta
transición sea más fácil ten en cuenta lo siguiente. Lo principal es recordar que el modelo Agile es
muy diferente del proceso tradicional de gestión de proyectos. Es muy fácil pensar que se trata de
lo mismo pero con nombres diferentes.

Una vez, trabajé con un gestor que decía que no creía en las herramientas. Le daba lo mismo si
usábamos Agile, Waterfall o cualquier otro método. Decía que solo le interesaba que se cumpliera
con el trabajo. «No me importan los métodos siempre y cuando todo el equipo esté de acuerdo y
haga lo que le toca». Fue muy difícil convencerlo de trabajar con un equipo ágil, porque el que
cada uno cumpla con su tarea se contradice con la autoorganización. Su intención no era sofocar al
equipo, pero sus expectativas no tenían nada que ver con el método Agile. No se daba cuenta de
que lo que él veía como falta de fe en las herramientas era el cúmulo de expectativas y reglas de
su carrera. Si eres gestor de proyectos y trabajas con un equipo ágil, esto debe ser muy diferente.
Es como cuando empiezas a levantar pesas. Si no pesa, es que no estás levantando el peso
adecuado. Debes aceptar que habrá cambios significativos para luego poder decidir si quieres
trabajar o no con Agile en tu empresa.

Empieza el trabajo
Forma al equipo ágil
La mejor forma de poner en marcha Agile es hacerlo de a poco. Empieza con un equipo básico y
pequeño y asegúrate de que se adapten al proceso ágil. Si trabajas en una empresa de tamaño
medio, el equipo debería ser de unas cuatro personas. Luego podrás expandir el modelo a través
del efecto contagio.

Primero concéntrate en que un equipo pequeño se especialice en el proceso para que luego pueda
transmitirlo al resto de equipos. Forma a un equipo ágil y que luego contagien su entusiasmo al
resto de la empresa. Trabaja codo con codo con ese primer grupo para asegurarte de que puedan
explicarlo correctamente. Debes entrenar muy bien a sus integrantes. Intenta que estén siempre
satisfechos. Si les gusta el método, serán tus principales cómplices para el cambio. Este equipo
pequeño será quien hable con el resto de compañeros durante el almuerzo. Y esa emoción
contagiosa debe tener de base un muy buen conocimiento del modelo Agile. Dales tiempo para
que tengan éxito. Deben ver los beneficios del cambio, no inviertas demasiado tiempo en
convencerlos. Invierte toda tu energía en que el modelo funcione a la perfección. para que el
equipo tenga éxito, debes trabajar tanto con los optimistas como con los escépticos. Como van a
ser los embajadores del modelo, debes asegurarte de que sigan el proceso correctamente. Si el
primer equipo no entiende el método, seguramente transmitan información errónea, y muchas
veces es más difícil eliminar información errónea que hechos comprobados. Un equipo básico bien
formado evitará que tengas que invertir mucho tiempo en volver a formar a todos.

Una vez trabajé en una empresa en la que los desarrolladores escribían la mayoría de las historias
de usuarios. En Agile, es el propietario del producto quien las redacta. Contestaron que fue por un
ejercicio mal entendido durante la formación. El primer equipo que recibió la formación entendió
mal el concepto y lo transmitió así al resto de la empresa. Cuando esta práctica ya se hizo habitual,
fue muy difícil cambiarla. Volver a explicar y a enseñarlo llevó mucho más tiempo del que habría
llevado explicar correctamente el primer ejercicio. Por ello, el equipo básico es el más importante
cuando hablamos de formación. Es recomendable que se dicte la formación antes de adoptar el
método. El equipo central debe tener dos metas. La primera es que todos entiendan las reglas del
modelo Agile. La segunda es facilitarles un foro para que puedan debatir las dudas y
preocupaciones que tengan. Si la empresa aún no está lista, deben debatirlo durante la formación.
Para poder evitarlo, intenta que el formador no sea la misma persona que les vende otros
productos Agile. Un buen vendedor nunca va a proporcionar un foro para que los usuarios
debatan si su producto es bueno o malo. Busca formadores en alguna universidad cercana.
También podrás encontrar formadores certificados en sitios web como el de la Scrum Alliance. Un
buen formador no les tiene miedo a las preguntas desafiantes. Intenta que todo el equipo asista a
la misma formación al mismo tiempo, en especial los propietarios del producto, que suelen ser los
últimos que se identifican, pero no por ello deben perderse la formación. De hecho, son los
miembros que más se benefician de ella y puede que sean los que menos conocen el modelo.

Un equipo bien formado es una gran inversión. El equipo empezará a asentar los buenos hábitos
antes de que aparezcan los malos. Y de ahí surgirán también expertos muy entusiastas. Un equipo
entusiasmado que conoce y trabaja bien el método influirá mucho en el resto de la empresa. Si
eres el ScrumMaster de tu equipo, invierte tiempo y esfuerzo para asegurar que tu equipo esté
muy bien preparado.

Crea las condiciones de trabajo para el equipo ágil

Si vienes del entorno de la tecnología, seguramente conozcas las instalaciones de Bell Labs, en
Nueva Jersey. Este laboratorio fue el responsable de gran parte de las innovaciones tecnológicas
de las décadas del sesenta y del setenta. El edificio estaba lleno de académicos, ingenieros,
diseñadores y expertos en tecnología. Si miras las fotos del edificio antiguo, verás que todas las
oficinas daban a un corredor muy largo. Al salir de la oficina, siempre ibas a encontrarte con
alguien. Muchas de las innovaciones tecnológicas que no fueron planificadas surgieron de esas
conversaciones espontáneas cara a cara. Bell Labs sabía muy bien que la innovación no nace de las
circulares formales, sino que es producto de la colaboración en persona y en tiempo real. Compara
este método con muchos de los ambientes de trabajo modernos.

En una oficina de hoy, es más probable que veas filas y filas de cubículos. Los empleados trabajan
desde su cubículo rodeados de gente en puestos similares. Los desarrolladores de software están
en un área. Los diseñadores están agrupados en otra. Seguramente los clientes estén en otro piso
o en otro edificio. Este ambiente moderno está diseñado para impedir la colaboración. Les da a
todos su espacio para trabajar en sus tareas específicas. También está diseñado para dividir el
trabajo. Un grupo desarrolla unas tareas y pasa el proyecto al grupo siguiente. Eso es lo opuesto a
lo que necesitas para tu equipo ágil. En un equipo ágil debe haber comunicación interdisciplinar y
se debe fomentar la colaboración en tiempo real. Por eso es muy importante que el equipo trabaje
en una zona común. Si a alguien se le ocurre una idea, puede acercarse a la mesa y debatirla.
Durante todo el proyecto debe fomentarse la comunicación en persona, porque será muy
beneficiosa. El cliente debe asistir a presentaciones en persona y los miembros del equipo deben
debatir las propuestas cara a cara.

Al trabajar en proyectos ágiles, piensa que los correos, memos y el contestador son solo
herramientas para organizar reuniones. La verdadera forma de trabajo será a través de la
comunicación en persona. Si eres amante de las comunicaciones electrónicas, verás que muy
pronto te darás cuenta de que por ese medio se comunica muy poco. Piensa en cuántas veces has
tenido que hablar con alguien después de intercambiar correos. Así las confusiones se aclaran
mucho más rápido. El ScrumMaster es el principal responsable de que el equipo trabaje en un
espacio compartido. En algunas empresas esto puede ser difícil de lograr. Hay organizaciones que
luchan contra el cambio a cada paso, pero el ScrumMaster debe ganar esa batalla. En muchas
empresas no será posible, y en esos casos, deberás replantearte si el modelo Agile les será útil. Si
decides seguir con el método, debes asegurar dos cosas.

- Primero, que el propietario del producto se siente cerca de algunos miembros del equipo.
El equipo necesita saber qué hace falta para que el proyecto tenga éxito y esa información
solo la tiene el dueño del producto, que tiene ciertas expectativas aunque no las comparta
del todo. Será él quien te dé la mayor información acerca de las expectativas del cliente.
- Segundo, el ScrumMaster debe al menos tratar de contar con un espacio para que se
reúna el equipo. Puede ser en una oficina especial o en el espacio entre los cubículos. Y
después de varias reuniones de pie, es esperable que muchos miembros del equipo se
queden ahí para hablar y debatir. Es una muy buena forma de obtener tiempo compartido.
Aunque hagas todos estos cambios, igualmente debes esforzarte por ofrecer un espacio
de trabajo compartido. Esos cambios te harán ver al menos una parte de lo que obtendrías
si tuvieras ese espacio compartido, que será uno de los aspectos esenciales para avanzar
en esta transformación ágil. Es un acto simple que mejorará la colaboración y la
comunicación del equipo. Si trabajan en cubículos, será muy difícil convencerlos de que
Agile es algo distinto. Y si siempre están sentados en el mismo lugar con las mismas
personas, también costará que entiendan que Agile implica un gran cambio. Es una jugada
simple que será una gran victoria y contribuirá a comunicar la dedicación de la empresa al
modelo.
Adopta la mentalidad agile
Piensa como un equipo agile
A principios de los noventa, el desarrollo de software era una tarea monumental. Un proyecto de
software era como construir un puente hacia una isla escondida detrás de las nubes. El gestor y el
resto del equipo pasaban mucho tiempo planificando, diseñando y estimando antes de poder
comenzar a construir. Y una vez empezado, era muy difícil cambiar la dirección. Si la isla se movía,
el gestor tenía que ponerse a doblar acero y partir cemento. Este enfoque tan poco flexible dio
como resultado muchos proyectos fallidos y gestores insatisfechos. Los equipo de software
necesitaban martillos para efectuar los cambios y debían trabajar largas horas para acabar los
proyectos.

A finales de los noventa, algunos equipos empezaron a introducir procesos con un enfoque meno
pesado. Les llamaban «desarrollo ligero de software». Los procesos de desarrollo ligero abarcaban
el Scrum, la programación Extrema, el desarrollo de software adaptable, desarrollo basado en las
características, Crystal Clear y un método de desarrollo de sistemas dinámicos. Varias empresas
empezaron a adoptarlos al mismo tiempo. Y representaban un grupo reducido de empresas por
todo el país. En 2001, 17 líderes de estos equipos ligeros se reunieron en un centro de esquí en
Utah para buscar puntos en común que demostraran que sus proyectos tenían más éxito. Al grupo
no le gustaba mucho el nombre «liviano». Ser un equipo «liviano» no tenía la connotación
apropiada para lo que querían comunicar. La primera tarea fue buscar un nuevo nombre. Querían
un término que pudiera ser adaptable, fácil y flexible. Así eligieron el término «Agile» y empezaron
a llamarse Alianza Agile. El lenguaje y la terminología que utilizaron en esa reunión fueron
indicadores de lo que intentaban lograr. Querían obtener un entusiasmo revolucionario. Eligieron
llamarse «alianza» y no «grupo de trabajo». Redactaron y firmaron un documento, el Manifiesto
Agile, en el que intentaron reflejar la lista de valores comunes a cada uno de sus proyectos ligeros.

El manifiesto empezaba así: «Descubrimos mejores métodos de desarrollar software mientras lo

creamos y ayudando a los demás». También crearon los Valores Agile. La lista de valores empieza
así: «Más personas e interacciones que procesos y herramientas. Más programas de trabajo que
documentación integral. Más colaboración con el cliente que negociación de contratos. Más
reaccionar al cambio que seguir un plan. Imagina que las dos columnas de valores son como los
extremos de un péndulo. El valor de la izquierda le quitará recursos al de la derecha. No es que el
equipo no deba valorar los elementos de la derecha, sino que los de la izquierda necesitan un
mayor énfasis. Muchos gestores de proyectos se pierden y no siguen un plan. Creen que trabajar
con este modelo elimina la planificación. Pero la lista de valores no indica eso, sino que reaccionar
al cambio, por ejemplo, es más importante que seguir un plan. La Alianza Agile consideraba que
los gestores invertían demasiado tiempo en planificar, pero no lo suficiente a reaccionar al cambio.
La lista de valores y el manifiesto son la clave de toda tu planificación. Todos los procesos y
prácticas del modelo deben estar conectados con alguno de estos valores. Son como los cuatro
pilares de Agile. Aunque sean valores abstractos, el equipo debe tenerlos en cuenta siempre
porque constituyen la guía para pensar como un equipo ágil.
Trabaja como un equipo agile
En los años cuarenta, en la radio había un programa muy famoso de Superman. En cada episodio,
algún personaje de pronto estaba en peligro. Y el presentador repetía la misma frase: ¿Es un
pájaro? ¿Es un avión? ¡No, es Superman!» Y entonces, como un rayo, aparecía y los salvaba. Así
era la vida de los superhéroes. Cuando alguien estaba en peligro, aparecían a último momento y lo
salvaban del desastre. Puede parecer extraño, pero no es muy diferente de cómo se trabajan los
proyectos en las empresas. Por lo general, intentan contratar superhéroes para los equipos.
Confían demasiado en un solo superhéroe para que les salve el proyecto.

El modelo Agile intenta romper con estos métodos. para que un proyecto tenga éxito, debe
distribuirse entre todo el equipo. Así, hay menos presión para que una sola persona lo conduzca y
cumpla. En un equipo ágil, debe intentarse compartir los conocimientos y la responsabilidad. Esa
es la clave de la responsabilidad de autoorganización. La programación Extrema es uno de los
primeros modelos de Agile. Es incluso anterior al manifiesto. Cuando se creó, tenía su propia lista
de valores, diseñados exclusivamente para ayudar a los equipos ágiles a trabajar en armonía. Los
cinco valores principales son la comunicación, la sencillez, la reacción, el valor y el respeto.
Puede parecer el estribillo de una canción de country, pero si se lo considera como un todo, se
observan los patrones de Agile.

- El primer valor es la comunicación, uno de los factores más importantes en este modelo.
Esta importancia se observa en los espacios compartidos de trabajo, en las historias de los
usuarios, la programación en equipo, la propiedad colectiva del código y las reuniones
diarias. Los equipos tienen un ScrumMaster cuya principal tarea consiste en observar
cuándo los miembros no se comunican.
- El segundo valor es la sencillez, y se hace mucho énfasis en esto también. Los resultados
deben ser siempre la solución más simple. Si el diseño es demasiado complejo,
seguramente habrá problemas con el desarrollo del software. El equipo debe buscar
siempre la solución más simple para resolver los problemas. La clave es la sencillez.
- Otro valor es la reacción. Este valor principal depende mucho de la comunicación. El
equipo debe compartir reacciones y opiniones. El propietario del producto debe
comunicar sus reacciones al equipo. El equipo debe colaborar con el propietario del
 producto y aplicar los cambios necesarios. Siempre debes recibir opiniones y darlas al
resto del equipo.
- El cuarto valor es justamente el valor, que te permitirá observar cómo interactúa el
equipo ágil. Hace falta valor para comunicar y aceptar las opiniones. También es necesario
el valor para mejorar los códigos de trabajo. Los equipos ágiles crean y mejoran los
productos poco a poco. Por ello, es probable que las soluciones que se dan al principio del
proceso deban descartarse y mejorarse. A este proceso se le llama refactorización del
software, y se trata de un trabajo continuo en equipo. Aunque el software funcione bien,
el equipo continuará mejorándolo.
- El último valor es el respeto, y se añadió hace unos pocos años. Se trata del respeto por el
otro y por uno mismo y es un valor que elimina los superhéroes. Cada equipo tiene
diferentes grados de experiencia y de conocimientos. Los desarrolladores tienen más
conocimientos que el cliente, y algunos desarrolladores tienen más experiencia más que
otros. para que el equipo funcione bien, los miembros deben compartir los conocimientos
y respetarse los unos a los otros. Deben aceptar que no hay un solo superhéroe y que todo
el equipo merece respeto. Es decir, que cada uno de los miembros del equipo es un
superhéroe y que deben respetarse los conocimientos de cada uno. Si alguien siente que
no se le toma en serio, es como si a todo el equipo le dieran kryptonita.

Entrega el producto como un equipo agile

En los proyectos tradicionales, suele haber una grieta entre el equipo responsable de cumplir con
la tarea y los clientes que hacen uso del producto. Esta grieta es la que provoca que sea difícil ver
qué piensa el cliente del producto. Muchos proyectos vienen con especificaciones detalladas y
claras. El problema de este enfoque es que no todos los clientes saben todo lo que quieren antes
de dar inicio al proyecto, y esto se ve mucho más claro en los proyectos de software. El modelo
Agile trata con este problema de forma simple: se cambia la forma en la que el cliente percibe los
resultados. El propietario del producto no está pendiente de cada detalle del proyecto. En cambio,
se concentra primero en los elementos de mayor valor, que se encuentran por orden de prioridad
en la lista de pendientes, siempre actualizada.

La búsqueda del valor Agile es parte de una historia que comenzó hace un siglo. Un economista
italiano llamado Vilfredo Pareto estaba recogiendo arvejas en el jardín. Pareto se dio cuenta de
que menos del veinte por ciento de las plantas producían alrededor del ochenta por ciento del
total de arvejas. Es decir, el veinte por ciento de las plantas de arvejas producían el 80 por ciento
de la cosecha total. Esta regla del 80/20 lo obsesionó un poco. Lo que no sabía es que años más
tarde, también se aplicó al software.

En 2002, Standish Group publicó un gráfico en el que se reflejaba la composición de funciones y

características de los productos de software. En el gráfico se observaba que, en promedio, los
clientes nunca llegaban a usar un 45 por ciento de las funciones que ofrece un software. Un 19 por
ciento de las funciones y características se usaban muy poco. El 16 por ciento, unas pocas veces. El
13 por ciento se usaba la mayoría de las veces. Y solo el siete por ciento se usaba siempre. Si
observas bien el gráfico, verás que es la regla de Pareto. Solamente el 20 por ciento del software
se usaba a veces o siempre. Los clientes usaban principalmente un 20 por ciento de las mismas
funciones y características. Si consideramos que pagaban por obtener el 100 por ciento del
software, este dato resulta muy interesante. Los proyectos Agile le sacan partido a la regla de
Pareto. Si solo el 20 por ciento de tu esfuerzo resulta en el 80 por ciento de tu valor, el propietario
del producto tiene la responsabilidad de cumplir primero con ese valor.

Si fueras el propietario del producto, ¿por dónde empezarías el desarrollo? Empezarías aquí. En un
proyecto Agile, siempre se empieza con el siete por ciento de las funciones y características que
los clientes usarán siempre. Al acabar con ese siete por ciento, sigues con el 13 por ciento de las
funciones y características que usan la mayoría de las veces. La regla de Pareto también puede
resultarte útil a ti en lo personal. Analiza los productos de software que usas. ¿Cuántas
características de tu teléfono usas? Seguramente haya algunas que no has probado nunca. En el
modelo Agile, identificar los elementos de mayor valor y convertirlos en la mayor prioridad es una
misión, no un objetivo.

El propietario del producto siempre querrá priorizar los elementos de mayor valor. Cada cambio
tendrá un efecto en cascada que afectará la lista de remanentes y alterará el proceso de trabajo.
Por eso la clasificación del trabajo pendiente en orden de prioridad no es un objetivo, sino una
actitud que determinará el cumplimiento del trabajo. En un proyecto ágil, ejecutar las tareas en
orden de prioridad es una actitud constante. Un proyecto tradicional obliga al cliente a planificar
antes de que el equipo empiece a desarrollar. Los interesados deben saber exactamente cómo
será el software antes de que se escriba el primer código. Piensa en cómo reaccionas cuando
recibes una lista larga de trabajo. Es muy natural empezar por las tareas que sabes cómo hacer y
manejar. Puede que también empieces por las tareas que sabes que te llevarán menos tiempo. Si
lo sabes todo de antemano, entregarás un producto basándote en tu propia capacidad para
completarlo. Es decir, que el cliente quizá deba esperar hasta que esté completado para poder
empezar a utilizarlo. El rol del propietario del producto es justamente evitar esto. El equipo
comienza a trabajar en la tarea que el propietario del producto coloca a la cabeza de la lista, no en
lo más fácil.

Evita los obstáculos

No introduzcas Agile con calzador
Al empezar un proyecto con el modelo Agile, es muy importante la relación que tengas con el
departamento de gestión de proyectos. Muchas empresas llevan distintos proyectos al mismo
tiempo, que se agrupan en lo que se llama «cartera de proyectos». Cuando las empresas tienen
varias carteras de proyectos grandes, por lo general cuentan con un departamento de gestión de
proyectos. Se trata de un grupo de empleados que ayudan en la gestión de todos los proyectos de
la empresa. El departamento de gestión determinará el éxito o el fracaso de tu transformación
ágil. En las grandes empresas, este departamento puede ser un grupo muy poderoso. Si el de tu
empresa no favorece el método Agile, es probable que tu proyecto no vea la luz del día, y esto
puede ser un gran desafío para los proyectos ágiles. Por lo general, estos departamentos
favorecen más la gestión tradicional. Muchos de sus informes no son fáciles de traducir a la
metodología Agile. Por ende, los departamentos de gestión de proyectos deberán cambiar sus
informes o pedirle al equipo ágil que cambie su forma de trabajo. Es muy difícil convencer al
departamento de gestión para que cambie sus informes. Suelen pensar que su trabajo consiste en
defender la organización del proyecto, que casi siempre tiene su base en la gestión de proyectos
tradicional.

Una vez trabajé para una empresa en la que el departamento de gestión de proyectos enviaba un
informe semanal de actualizaciones, que consistía en una lista de los objetivos del proyecto. Cada
objetivo venía con una descripción y su actualización. Al reunirme con el director de gestión, le
comenté que en Agile no se trabaja por objetivos. En cambio, se prioriza el trabajo en la lista de
tareas pendientes, que puede modificarse según los elementos que el propietario del producto
considere de mayor valor. El dueño del producto puede reunirse al día siguiente y cambiar las
prioridades. Al director esto le pareció muy frustrante. Su trabajo dependía de la estabilidad de los
plazos del proyecto. Necesitaba saber cuándo el proyecto alcanzaba el 25, el 50 y el 100 por
ciento. El presupuesto dependía muchísimo de esos objetivos. Cuando el proyecto estuviese al 50
por ciento, el presupuesto también debía estar al 50 por ciento. Un proyecto ágil no puede
introducirse con calzador. Habíamos lanzado el proyecto, pero no estaba ordenado según fechas y
objetivos. Para dividir el trabajo se debe saber de antemano todo lo que implica la entrega del
proyecto. El departamento de gestión necesitaba un plan, aunque no lo hubiera pedido. Esto es lo
que suele ocurrir cuando se trabaja con un grupo de gestión. Sus miembros no dicen que
necesitan un plan, pero sí exigen detalles que solo surgen si hay un plan. Quieren que les muestres
un diagrama de Gantt o los cronogramas del proyecto. Es como cuando Henry Ford prometió que
los clientes podrían comprar autos de cualquier color, siempre y cuando fueran negros.

Al enfrentarte a estos problemas, debes respetar siempre el trabajo del grupo de gestión, porque
su papel también es muy importante. Si tu equipo intenta burlarlo, es probable que se encuentren
con muchos obstáculos. Una buena táctica es lograr que el departamento de gestión se encargue
de la formación en Agile. Suele ser una forma inocua de provocar cambios en las empresas. Si el
grupo de gestión se encarga de la formación ágil, puede que se convierta en uno de tus mayores
aliados. Otra buena táctica es solicitarle ayuda al gestor de proyectos de tu equipo. Es muy
probable que el gestor del equipo tenga una relación estrecha con el departamento de gestión de
proyectos y pueda aprovechar ese conocimiento para construir un puente entre sus expectativas y
el proyecto ágil. Lo mejor es que tu gestor pueda interactuar con el departamento, pero puede
ocurrir que este último no esté muy interesado en tu transformación al modelo Agile. Puede que
tengan demasiados proyectos con los que lidiar. Quizá tu proyecto sea demasiado pequeño como
para atraer su atención y acaben poniéndolo al final de la lista, con tu equipo remando en un bote
detrás del gran transatlántico del departamento de gestión. Esperarán informes de alto nivel, pero
poco más.

El problema con este tipo de proyectos es que siempre lo considerarán una novedad. Puede que a
tu equipo le vaya bien, pero normalmente significa que el resto de la empresa no adoptará el
modelo. Si lanzan a tu equipo al bote de remos, es muy probable que al finalizar el proyecto, la
empresa vuelva a la gestión de proyectos tradicional. Invierte tiempo al principio del proyecto para
forjar una buena relación con el departamento de gestión. Será un factor determinante para que
luego acepten el modelo. Si al departamento no le agrada el método o ignora tu trabajo, será todo
cuesta arriba. Pero si respetas su rol en este juego, puede ser un gran impulso para tu
transformación ágil.

La confusión de roles
El que empieces un nuevo proceso no significa que debas trabajar con un equipo nuevo. Esto es
algo normal en el funcionamiento de las empresas. Nadie quiere trabajar en una compañía en la
que cada cambio implique que se incorporen nuevas personas. Y esto también lo observarás
cuando adoptes el modelo Agile.

Gran parte de tu equipo serán los empleados de siempre probando algo nuevo. Tendrás a los
mismos desarrolladores, gestores de proyectos y analistas. cada uno de ellos tendrá hábitos y
costumbres que vienen de su experiencia previa y pueden ser difíciles de combatir. La mayoría del
equipo aceptará el cambio de modelo, pero los efectos del cambio deberán combatirse en batallas
diarias. Si nunca han trabajado con Agile, es probable que tengan vicios heredados. Los
desarrolladores no están acostumbrados a asumir la responsabilidad de la entrega, porque según
el método tradicional, el responsable es el gestor del proyecto. Pero Agile rompe con estas
expectativas. Se espera que los desarrolladores tengan una relación directa con el propietario del
producto, y que repartan los elementos de gran valor en sus tareas cotidianas. También deberán
formular estimaciones de su propio trabajo. Los desarrolladores no tienen que cumplir con la
gestión, sino centrarse en los resultados. Estos cambios pueden resultar difíciles para un
desarrollador que lleva años trabajando detrás de bambalinas.

Una vez, trabajé en un proyecto en el que un desarrollador no empezaba su trabajo si no recibía

información sobre todos los requisitos. Con el paso del tiempo, descubrió que era mejor no hacer
nada a tener que rehacer un trabajo, y no empezaba hasta que no le entregaban todo el papeleo.
Fue un hábito muy difícil de eliminar. En el modelo Agile, quienes hacen el trabajo también lo
encargan. Si el desarrollador tiene una duda, es responsable de contactar con el propietario del
producto. El equipo lo tiene bastante difícil. No hay ningún documento que puedan señalar y decir
que cumplieron con todo. Si los desarrolladores no pueden eliminar estos hábitos, ten en cuenta
lo siguiente.

- Primero, la regla de gestión de Spider-Man. Un gran poder conlleva siempre una gran
responsabilidad. Asegúrate de que no haya obstáculos para que el equipo pueda
organizarse a sí mismo. Debes comunicarle al equipo que son ellos los responsables de
cumplir con el proyecto. La autoorganización y la responsabilidad están muy relacionadas.
 Si tus desarrolladores no asumen la responsabilidad, fíjate bien que no trabajen con un
gestor encubierto.
- Segundo, recuerda que no pasa nada si el equipo tiene pequeños fallos. Aprenderán
mucho más de las tareas fallidas que si falla el proyecto entero. Muchas empresas tienen
mecanismos que hacen saltar la alarma al menor signo de fracaso. A veces es mucho
mejor que el equipo aprenda a aceptar las consecuencias de los fallos. Hay desarrolladores
que nunca experimentaron la ira de un cliente enfadado. Si pasan por una reunión
incómoda con el propietario del producto, verán que no existen las zonas de protección.
Puede que un ScrumMaster que provenga de la gestión de proyectos tiemble ante la
perspectiva de fracasar. Quizá lo vea como un tren que descarrila en cámara lenta, una
situación que podría evitar con una buena gestión del proyecto. Pero los ScrumMasters
deben deshacerse de esa costumbre. No son responsables de la entrega, sino de
asegurarse de que el equipo respete y siga el modelo Agile. En este último ejemplo, el
ScrumMaster debería enseñarle al equipo a formular estimaciones. Si el equipo se
tambalea, otros miembros pueden corregirlo. Y si eso no funciona, el ScrumMaster puede
facilitar una reunión entre el propietario del producto y el equipo. Hay una gran diferencia
entre gestionar el proyecto y aplicar el método. El ScrumMaster no debe liderar al equipo.
Si ves que al ScrumMaster le cuesta eliminar viejos hábitos, ten en cuenta lo siguiente.
Primero, busca sus puntos débiles. ¿Se centra en la entrega o en el equipo? ¿Se preocupa
por cumplir con los plazos o por la formación? Aquí te sirve que se centre en el equipo y
en la formación. Las entregas y los plazos son los puntos más débiles de un gestor de
proyectos. La transformación de gestor a ScrumMaster es una de las más difíciles de
aceptar. La mejor forma de evitar problemas es asegurarse de que la empresa conoce a
fondo el rol del ScrumMaster, y esto puede ser difícil si se trata de la misma persona en un
puesto diferente.

Cambiar de terminología en vez de cambiar de herramientas

Una vez trabajé en una empresa en la que cada mañana empezaban con reuniones de
actualización de una hora. El administrador de carteras mostraba una hoja de cálculos multicolor
en la pantalla del proyector e iba por toda la mesa preguntando a cada encargado de proyecto
cómo iban las tareas. Dando sorbos a una taza gigante de café, explicaban en qué estado estaba
cada uno de los objetivos. La empresa tenía una gran tradición en construcción. Los objetivos, las
reuniones de actualización y la mesa eran todas partes normales de un proyecto. Al construir
condominios, las reuniones eran iguales. Ese era el ritmo que se esperaba para cumplir con los
proyectos complejos.

Cuando la empresa incursionó en el desarrollo de software, los ejecutivos propusieron aplicar la

metodología Agile. Iba a ser un cambio difícil para la organización, ya que estaban muy
acostumbrados a los procesos tradicionales. Todos los gestores de proyectos se basaban en
cumplir objetivos. Presentaban gráficos en salas de reuniones. Se hicieron muchas sesiones de
formación, pero les costaba aceptar los conceptos clave de Agile. Los administradores de carteras
no querían rechazar el método, así que siguieron con sus procesos de siempre pero usando la
terminología de Agile. Las reuniones alrededor de la gran mesa se llamaban «reuniones de pie».
Los mismos gestores de proyectos eran ScumMasters. Los objetivos eran tareas cortas a plazos.
Cambiaron el vocabulario, pero no las formas de trabajo. Y esto ocasionó mucha confusión.
Durante las «reuniones de pie», no había gente de pie. También pusieron nombre a nuevos
puestos y reuniones dentro del modelo. Tenían un SuperscrumMaster en vez de un administrador
de tareas y líderes de equipo ágil en vez de desarrolladores sénior. Al final, la organización no
obtuvo ningún beneficio de la aplicación del método. Lo único que obtuvo fue un puñado de
administradores frustrados con tanto cambio de nombre. Cuando una organización no quiere
cambiar, es común que se cambien los nombres pero no las herramientas. Es mucho más fácil usar
los títulos de Agile en vez de que el equipo pase por una transformación difícil.

Si crees que en tu empresa se está optando por el camino más fácil, ten en cuenta lo siguiente.

El primer aspecto es el más fácil de reconocer. después de la transformación,

- ¿sigues haciendo las mismas tareas en el mismo tiempo, con las mismas personas y en el
mismo lugar? Puede que parezca una tontería, pero muchos equipos subestiman el
trabajo que implica el cambio. Una transformación exitosa requiere un gran compromiso a
largo plazo. Si los equipos no cambian, pronto volverán a los hábitos y prácticas de
siempre.
- ¿La reunión del equipo ágil te parece demasiado conocida? Seguramente no hayas
cambiado nada.

El segundo aspecto a tener en cuenta es que debes buscar el apoyo de los puestos ejecutivos. Es
muy difícil lograr cambios si los gerentes no invierten su propio tiempo y recursos. Los gerentes
intermedios suelen tomar la salida fácil de cambiar los nombres. Todo el esfuerzo y trabajo que le
dediquen se verá recompensado.

El tercer aspecto es analizar si estás intentando cambiar el modelo Agile para que se adapte a la
empresa. Suele ser frecuente cuando hay nuevos roles de Agile. Si ves que estás cambiando el
modelo, probablemente signifique que no estás cambiando el equipo. Si implementas roles como
el de SuperscrumMaster o el de líder de desarrollo Agile, estarás perjudicando el método. antes de
crear nuevos roles, pregúntate si ese rol ayudará al cambio o lo perjudicará.

Por último, analiza la empresa con objetividad. Intenta predecir los problemas que enfrentará. ¿A
qué se dedica tu empresa? ¿Todos los altos cargos eran antes ingenieros de construcción?
Entonces, puede que tu empresa no acepte que haya menos planificación. ¿Hay muchos gestores
de proyectos? Entonces, la empresa quizá vea la autoorganización como un problema. Para
algunas compañías es más fácil aceptar el modelo. Si a tu empresa le resulta difícil, es importante
que se comprometan al cambio. Si intentas introducir Agile a la fuerza en una empresa que no está
lista, ocasionarás mucha confusión. Asegúrate de que todos se comprometan al cambio. Ya lo dijo
Yoda, el gran maestro Jedi: «Hazlo o no lo hagas, pero no lo intentes».

Agile en acción: Planificación con historias de usuarios ágiles.

Introducción
Cuando empezamos un proyecto, normalmente lo hacemos con la intención de mejorar la vida de
nuestros usuarios. ¿Por qué los perdemos de vista tantas veces? Lo más importante de una taza
debería ser facilitar a nuestros clientes su rutina, no el material, el color o la posición del asa. Usar
historias de usuario centradas en las necesidades de las personas y no en las soluciones me ha
ayudado a colaborar mejor con los equipos con los que trabajo y a diseñar mejores productos y
servicios.

Historias de usuario y sus características

De contratos a necesidades y valor aportado
En 2001, el Manifiesto Ágil dio nombre a una nueva manera de entender la gestión de proyectos.
Afectó a la relación de los equipos y sus clientes, a la estructuración de los procesos y a la
autonomía de los equipos. Y, aunque fue pensado para el software, cambió la manera en la que se
gestionan muchos otros proyectos.

El Manifiesto ágil decía explícitamente que su mayor prioridad es satisfacer al cliente y que los
cambios en los requisitos son bienvenidos incluso bien avanzado el proyecto. Una de las maneras
en las que estos dos principios son realmente aplicables es a través del uso de historias de usuario
en lugar de requisitos técnicos tradicionales.

Las historias de usuario son una manera de definir las necesidades de los usuarios que ayuda a los
equipos de proyecto a estudiar diferentes soluciones para una necesidad y que hace posible que el
alcance del proyecto, el problema que acordamos resolver no varíe demasiado en realidad por
mucho que varíen las soluciones propuestas. Las historias de usuario siguen a una estructura
sencilla que incluye: el tipo de usuario, la necesidad que tiene y el beneficio que espera obtener
de cubrir esta necesidad. Un ejemplo de historia de usuario podría ser: como desempleado en
busca de un nuevo trabajo, quiero actualizar mis conocimientos para poder optar a un trabajo
mejor. Trabajar con este formato de requisitos permite a los equipos de proyecto centrarse en
entender muy bien el perfil del usuario, entender cuál es su necesidad y el impacto que desea y
evitar centrarse en las soluciones específicas. Esta historia de usuario podría resolverse con un
curso online como este, un grado universitario o unas prácticas no pagadas. Con las historias de
usuario tenemos una manera de documentar las necesidades y trabajar iterativamente en
diferentes implementaciones basadas en hipótesis. En un proyecto, trabajar y acordar historias de
usuario y no requisitos técnicos y detalles de implementación de la solución permitirá al equipo
trabajar en desarrollar diferentes soluciones posibles para un mismo problema, manteniendo
siempre el foco en el usuario y desvinculándose de soluciones específicas.

Requisitos y especificaciones
Antes de las historias de usuario, todos los requisitos y especificaciones de proyectos de
ingeniería, producción o incluso software eran muy detallados y ocupaban páginas y páginas de
documentación. Un proyecto partía de una serie de requisitos funcionales y no funcionales y unas
especificaciones. Cómo debían ser los objetos o estructuras producidas, qué tamaños debían
tener, cómo debían operar, pero también cómo debían comportarse en situaciones determinadas
o, en los casos en los que fuera aplicable, en qué idiomas debía estar disponible o con qué otros
productos o servicios debía poder operar.

Un caso clásico es el de la taza. Imagínate. Antiguamente, para poder hacer una taza, alguien tenía
que definir que debía ser un recipiente capaz de contener líquido, de un material algo aislante
para poder agarrarla con materiales calientes, con una apertura superior para poder beber, que
pudiera inclinarse, que tuviera una base plana para poder apoyarla. Alguien tenía que pensar en
todos estos detalles y plantearlos correctamente. Y el más mínimo cambio requería volver a
empezar. ¿Necesitamos un asa para nuestra taza? De vuelta a la aprobación de requisitos.
¿Queremos que tenga un pie? Es necesaria una reunión, ya que podría tratarse de una copa y no
de una taza y eso requeriría aprobar un nuevo contrato. En proyectos como la construcción de una
carretera o un puente o incluso de un automóvil, esto puede tener cierto sentido. En el caso del
software, cuando este se entregaba en CD en cajas, también. Hoy en día, tanto la manufactura
como el software funcionan de manera mucho más rápida y no hay tiempo para documentar
todos estos requisitos ni queremos atarnos demasiado a ellos. Gracias a las historias de usuario
podemos acortar todas las especificaciones de nuestra taza a "Como profesional, quiero poder
beber mi café mientras aprendo en LinkedIn para mantener mi nivel de energía" o "Como
deportista, quiero beber agua mientras corro para poder mantenerme hidratada". Este tipo de
especificaciones centradas en las necesidades de los usuarios en cada momento dará lugar a
soluciones más apetecibles para los usuarios en concreto a los que queramos llegar y que
resuelven mejor sus problemas específicos.

Las historias de usuario

Las historias de usuario son una manera de redactar los requerimientos de un proyecto de manera
centrada en los usuarios y sus necesidades y alejada de los detalles de la implementación de la
solución propuesta.

Las historias de usuario tienen tres partes: la definición de los usuarios, su necesidad y el beneficio
que esperan. Estas tres partes se unen en una oración que tiene la estructura: «Como (usuario),
quiero (necesidad) para (beneficio)» . Las historias de usuario se crean al inicio del proyecto y se
actualizan a medida que se conoce más información y pueden documentarse en documentos,
hojas de cálculo o aplicaciones de gestión de proyectos. Puedes escribirlas completas o separarlas
en tres partes explícitas para poder revisar por separado a los usuarios afectados por el proyecto,
las necesidades a resolver y los beneficios. La principal diferencia con las especificaciones técnicas
es que esta colección de historias de usuario se centra en necesidades, no en soluciones. Además,
está escrita en lenguaje simple, que es comprensible para cualquier persona con contexto del
proyecto independientemente de su nivel técnico. Recuperemos el ejemplo clásico de la taza de
café. Algunas de las historias de usuario que podríamos definir para este proyecto serían:

- Como bebedor de bebidas calientes, quiero que la taza sea algo aislante para poder
cogerla llena de líquido caliente sin quemarme las manos.
- Como bebedor multitarea, quiero poder apoyar la taza para poder soltarla mientras hago
otras cosas .
- Como bebedor que va en automóvil, quiero poder cubrir mi taza mientras conduzco para
evitar salpicaduras.

Escribir historias de usuario de esta manera ayuda a asegurarnos de que los beneficios esperados
quedan claros para todos antes de empezar a especificar soluciones. No tenemos más que leer las
historias de usuario al revés para constatar que los beneficios de nuestro proyecto son poder
beber líquido caliente sin quemarnos las manos, poder usar la taza mientras se hacen otras cosas y
específicamente poder evitar derrames en movimiento. Si lo comparamos con especificaciones
como el alto y ancho de la taza, la mezcla de porcelana o aleación de metales que se propone usar
o el mecanismo de cierre específico que se propone, nos daremos cuenta de que son maneras de
ver el diseño completamente diferentes. Una se centra en entender muy bien el problema y el
contexto, mientras que la otra se centra en las soluciones. Las historias de usuario centradas en el
problema ayudan a entender mejor a los usuarios de nuestra solución y a empatizar con ellos, se
adaptan mejor a los cambios que se propondrán en el diseño inevitablemente a medida que
vayamos aprendiendo y son más accesibles para roles no técnicos de nuestros proyectos.

Escribir buenas historias de usuario

Las historias de usuario no son simplemente una manera de estructurar una frase, sino una
manera de pensar que se centra en el usuario, los beneficios que queremos aportarle y sus
necesidades específicas, lejos de los detalles sobre nuestra solución. La estructura de la frase es
solo una manera de guiar nuestro pensamiento. Algunas personas cuando descubren las historias
de usuario se quedan en esta parte, en lo superficial. Las historias de usuario de estas personas
son de este tipo:

- como usuario, quiero tener una asa para poder beber líquido caliente
- como usuario, quiero una tapa que se abra al deslizarla para poder cerrarla .

Observa que estas historias de usuario cumplen la estructura de la oración propuesta y pueden
parecer historias de usuario válidas. Sin embargo, presentan varios problemas. Para empezar, solo
hablan de usuarios. ¿Qué usuarios? ¿Todos los usuarios? ¿Cómo son o qué tienen en común?
Como usuario, quiero…, es una manera de recordar el inicio de la estructura de historias de
usuario o una manera de abreviar si tenemos definidos los segmentos de usuario aparte y estamos
en contexto, pero si ves, como usuario, quiero…, en las historias de usuario de un proyecto real,
considéralo una bandera roja. Una buena historia de usuario irá más allá y definirá a diferentes
usuarios según su contexto, perfil o necesidades.

Otro problema de estas historias de usuario es que no hablan de los beneficios que les vamos a
descubrir más allá de poder beber y además proponen soluciones específicas, así que si decidimos
no poner un asa ya no nos servirán. Las asas facilitan agarrar las tazas y son convenientes para
beber líquidos calientes, pero un diseño ergonómico o un material aislante pueden ser mejores
soluciones. Con esta historia de usuario no solo estamos limitando la creatividad de las soluciones,
sino que además nos arriesgamos a que la conversación gire en torno al diseño y posición del asa y
el mecanismo y material de la cubierta y no en torno a las necesidades de los usuarios, su contexto
de uso o los mejores materiales y diseños.

Una buena historia de usuario estará abierta a diferentes soluciones y detallará un beneficio no
necesariamente relacionado con nuestro producto o servicio. Observa esta otra historia de usuario
que trata de reparar los puntos que acabamos de comentar. Como persona que quiere usar la taza
para beber varias bebidas, quiero que mi taza sirva para poder beber líquido frío y caliente para
usar la taza con líquido caliente y no quemarme las manos al beber. Mucho mejor. Tenemos un
perfil de usuario más claro, una necesidad que no está ligada a una solución y beneficios para el
usuario más allá del propio uso de la taza. En este caso el problema es precisamente que tenemos
dos beneficios en nuestra historia de usuario. Cuando esto ocurre, normalmente es necesario
refinar y seguramente acabemos con dos historias independientes o con un beneficio que sea una
variación de lo que teníamos inicialmente. Como minimalista, quiero poder consumir bebidas frías
o calientes en mi taza para reducir el número de objetos en mi hogar.
Planificación de productos digitales con historias de usuario
Dependencias y prioridades
En cualquier proyecto es necesario evaluar el trabajo a realizar para determinar dependencias y
prioridades, y este paso también será aplicable cuando creamos historias de usuario. Al redactar
las historias de usuario para nuestro proyecto siempre habrá unas historias que sean más
prioritarias que otras porque aporten más valor a los usuarios o resuelvan un problema más
urgente. Además, algunas historias de usuario serán un prerrequisito para poder comenzar a
trabajar en otras.

Es conveniente trabajar con todas las partes implicadas en el proyecto en esta fase y realizar una
revisión de prioridades y dependencias regularmente para identificar cambios y adaptar nuestros
planes a la nueva realidad. Identificar dependencias, además, puede ayudarnos a pensar en
nuevas maneras de abordarlas o incluso eliminarlas. Veamos esto con un ejemplo de historias de
usuario para una taza. Al redactar el siguiente conjunto de historias de usuario, podemos empezar
a identificar dependencias entre ellas.

- Como conductor, quiero poder encajar mi taza en el vehículo para poder dejarla mientras
conduzco
- Como conductor, quiero poder tapar mi taza en el vehículo para evitar salpicaduras
- Como conductor, quiero ver el contenido de mi taza mientras está tapada para ver cuánto
queda .

Mirando a los beneficios, podríamos decir que la más urgente de todas es la primera, ya que forzar
a nuestros usuarios a conducir con solo una mano sería una temeridad. Esto, además, requerirá
que usemos medidas estándar en nuestro producto a lo largo de todo el proyecto, ya que los
soportes para bebidas de los vehículos son de un ancho específico. La segunda más prioritaria
sería poder tapar la taza, ya que los derrames de bebidas serán aparatosos para nuestros usuarios.
Por último, ver el contenido de la taza sería útil para los usuarios, pero dar un trago a una taza
vacía es un problema poco apremiante y, por tanto, esta historia de usuario sería la menos
prioritaria de las tres.

Ahora bien, si este es un compromiso del proyecto, un requisito duro sin el cual no
conseguiríamos aprobación, esta historia de usuario creará una fuerte dependencia en nuestro
proyecto, nos forzará a usar materiales transparentes en la cubierta o a diseñarla de manera que
haya una ventana para ver el contenido. Te recomiendo que uses la parte del beneficio de las
historias de usuario para priorizar, empezando por los problemas más frecuentes o que tengan un
peor impacto en la experiencia de usuario. Ordena las historias de usuario de más a menos
prioritaria en lugar de asignarles una prioridad alta, media o baja. En mi experiencia, esta última
manera de organizar el trabajo conduce demasiadas veces a listas de historias de usuario en las
que un 80 % de las historias tiene alta prioridad. Al usar prioridades relativas, forzamos un orden
más estructurado y claro que te ayudará a mantener las prioridades de tu proyecto bajo control.

Épicas y mapeo de historias de usuario

Una vez tengamos nuestra colección de historias de usuario y sepamos cuáles son las
dependencias y prioridades, tendremos una idea mucho mejor sobre nuestros usuarios, sus
necesidades y los beneficios que esperan obtener a través del producto o servicio que estamos
creando o mejorando a través de nuestro proyecto. Al conocer mejor esta información, podremos
identificar épicas1, grupos de historias de usuario que facilitan alguna acción o estado nuevo.
Puede que al definir las historias de usuario de nuestro proyecto para crear la taza perfecta para
las personas que necesitan beber su café en su camino al trabajo identifiquemos problemas
relacionados con beber y problemas relacionados con lavar la taza después de su uso o con su
capacidad para usarse con líquidos fríos o calientes. Estas serían tres épicas diferenciadas que
podríamos usar para mapear nuestras historias de usuario. El mapeo de historias de usuario es
una actividad compleja que suele realizarse varias veces a lo largo de la vida de un proyecto y que
puede llevar horas si se hace correctamente. En corto, mapear historias de usuario es
organizarlas por épicas que forman columnas y prioridades de las historias de usuario dentro de
estas épicas. En general, los productos mínimos viables deben tratar de resolver varias épicas de
forma mínima y no una en mucho detalle para poder explorar y aprender más del
comportamiento de nuestro producto o servicio en el mundo real. Así que al mapear estas
historias de usuario empezaremos a ver un patrón.

Podremos dividir el mapa de historias de usuario una vez organizado en franjas horizontales
irregulares que cubrirán las historias de usuario más importantes para varias épicas cada vez.
Suele compararse este modelo con una tarta de cremas y bizcochos de varios pisos, y seguro que
viendo esta imagen puedes entender por qué. En los equipos que hacen trabajo iterativo en sus
proyectos, por ejemplo en los equipos que usan la metodología ágil Scrum y sus sprint, estas capas
suelen usarse para definir el alcance de estos sprint o ciclos de trabajo.

El mapa de historias de usuario suele crearse con herramientas de gestión de proyectos, es

interesante que lo mantengas actualizado y que trates de que sea visible a todas las personas
implicadas, incluso a tus clientes. A falta de una documentación de requisitos más detallada, el
mapa de historias es una de las maneras más claras para comunicar el alcance e iteraciones
previstas para un proyecto. Como en casi todos los casos de documentación en proyectos ágiles,
es importante que lo mantengas actualizado e incidas en comunicar que se trata de una referencia
de intenciones, no de un compromiso de implementación.

El Backlog de producto
La colección de las historias de usuario de un proyecto y de las tareas, errores y propuestas que
se vayan incorporando a medida que se trabaja en él forman lo que se llama backlog o pila de
producto. Esta nomenclatura viene en concreto de la metodología SCRUM, una de las más
populares de las metodologías ágiles, pero se aplica frecuentemente en otros tipos de proyectos.

El backlog de producto puede tener diferentes formas.

- Puede ser un simple listado de las historias de usuario conocidas en un documento de

texto u hoja de cálculo. En estos casos debería ordenarse por prioridad y dependencia y el
equipo trabajará para completarlo de arriba abajo.
- En otros casos, los equipos representan sus backlog de producto como un mapa de
historias de usuario. Esto es posible también en documentos, pero es generalmente más
fácil crearlo con una herramienta específica para mapear historias de usuario, presente en
muchas herramientas de gestión de proyectos. En los mapas de historias de usuario hay

1
Se denomina Epic a una historia de usuario que por su gran tamaño, el equipo descompone en
historias con un tamaño más adecuado para ser gestionada
 una serie de épicas o conjuntos de beneficios o de áreas de impacto de las historias de
usuario del proyecto en las que las diferentes historias de usuario se ordenan además de
más a menos prioritarias. La ventaja de los mapas respecto a las listas es que añaden una
dimensión más y permiten ver el proyecto de manera más general, aportando valor en
diferentes puntos de la experiencia de los usuarios en cada iteración.
- Otra manera habitual de representar o consumir el backlog del producto es a través de
roadmap u hojas de ruta. Estas hojas de ruta representan las diferentes historias de
usuario en el tiempo y a su vez pueden ser de diferentes tipos.
 Un primer tipo de roadmap simplemente define tres o cuatro fases en una línea de
tiempo y las historias de usuario se asignan a fases como ahora, después y en el
futuro, o primer trimestre, segundo trimestre, segunda mitad del año.
 En otros roadmap se trata de refinar un poco más el periodo en el que se espera
trabajar en una determinada historia de usuario y pueden incluso utilizar gráficos de
Gantt para representar el backlog del producto. En estos casos, si se trata de un
proyecto ágil, cabe recordar que el mapeo inicial variará, pero puede ser útil para
equipos con altas dependencias entre equipos o proyectos y, en mi experiencia, suele
gustar mucho a los clientes, ya que les da confianza en que se ha hecho un buen
trabajo de análisis.

El Backlog de sprint
Si trabajamos en iteraciones o sprint, en cada uno tendremos una colección de historias de usuario
relacionadas con el tema u objetivo del sprint en el que trabajaremos durante la iteración. Es lo
que se llama el backlog del sprint o pila del sprint. Este backlog del sprint puede representarse
simplemente como una lista de historias de usuario y cualquier información adicional que
necesitemos compartir con el equipo para que pueda trabajar en ellas. Sin embargo, la manera
más habitual de ver este backlog de sprint es en un tablero Kanban. El tablero Kanban usa
columnas para representar diferentes fases del trabajo. Suele empezar con Por hacer, En progreso
y Hecho, aunque algunos equipos añaden columnas intermedias para controlar mejor su trabajo.
Al empezar el sprint pondremos todas las historias de usuario en las que el equipo va a trabajar en
la columna de trabajo por hacer y las iremos moviendo a las siguientes columnas a medida que
progresamos en ellas. En los tableros Kanban además podemos representar otros datos
interesantes para cada una de las historias de usuario, como las personas de referencia o que van
a liderar cada una de las historias, notas o referencias sobre dependencias con otras historias de
usuario o códigos de colores para indicar prioridades o bloqueos. El Kanban de un equipo debe
adaptarse al equipo que va a usarlo y no al revés, así que no tengas miedo de cambiar el Kanban
original y de ir adaptándolo a tu equipo en cada sprint. Es recomendable que todas las historias de
usuario de una iteración o sprint hagan referencia a uno o dos objetivos comunes a todos los
miembros del equipo. En mi experiencia, esto ayuda a mantener al equipo unido y enfocado,
empujando hacia un objetivo común, y simplifica mucho la gestión del sprint. Esto no siempre es
posible, ya que cada proyecto es un mundo y a veces las expectativas de entregas no permiten
mucha flexibilidad en los objetivos, pero, si puedes permitírtelo, de esta manera conseguirás
mejores resultados.
De historias de usuario a tareas de desarrollo
Las historias de usuario son geniales para definir las necesidades de un proyecto, pero se quedan
algo cortas a la hora de pasar a la implementación. Normalmente, existe un paso intermedio en el
que una vez acordada la historia de usuario el equipo refina la definición con un contexto sobre las
soluciones actuales a esa historia de usuario, con propuestas de implementación o incluso con
diseños de alta o baja resolución. En algunos casos, esta refinación implica también definir unos
criterios de evaluación o aceptación de la implementación de la historia de usuario que usaremos
para hacer la revisión del trabajo realizado. En este proceso brilla especialmente una de las
mayores ventajas de las historias de usuario frente a las especificaciones o requisitos tradicionales.
Es el equipo técnico el que, teniendo en cuenta la necesidad y el beneficio del usuario, explora las
diferentes alternativas de implementación que podrían satisfacerlas. Esto permite, por ejemplo,
descubrir la manera que menos afecta a la infraestructura o la más rápida de validar o la más
barata.

Las metodologías ágiles abogan por equipos independientes que trabajan aportando sus
conocimientos y experiencia para resolver problemas. Las historias de usuario dan libertad a los
equipos para iterar y proponer soluciones a las que nosotros solos como gestores de proyectos o
analistas nunca habríamos llegado. Muchas veces trabajamos en soluciones y ponemos muchas
horas de nuestra parte que una persona que trabaje a diario con el material con el que hacemos
nuestros proyectos, desde materiales de construcción a lenguajes de programación, pueden
resolver por nosotros en pocos minutos. Los arquitectos diseñan puentes, pero no deciden la
mezcla de cemento que se usará para fijar la estructura ni la marca de las herramientas que se
usarán porque seguramente son los ingenieros los que mejor pueden tomar estas decisiones.

En mi experiencia en software, muchas veces he recibido encargos de un cliente que eran

demasiado específicos en cuanto a la solución, hasta el punto de definir qué botones colocar en
qué partes de la interfaz. Por supuesto que podemos pedirle a un ingeniero informático que
coloque un botón donde lo queramos, pero muchas veces perderemos la oportunidad de usar su
experiencia para conseguir un resultado mejor. ¿Querrías todavía el botón si te dijera que es
posible automatizar por completo una parte de tu trabajo? Cuando nos centramos en definir el
problema y dejamos que los expertos nos recomienden soluciones, podemos llegar a hacer cosas
realmente interesantes. Asegúrate de defender la libertad de tu equipo y de motivarles a aportar
soluciones en esta fase de refinamiento y deja que te sorprendan.

Definición de listo y de hecho

Cada equipo decidirá internamente cuánta definición incluir en sus historias de usuario antes de
considerarlas listas para producción. Esta definición de listo es uno de los primeros acuerdos a los
que debe llegar un equipo para asegurar que siempre se empieza a trabajar en las historias de
usuario solo cuando la hemos meditado lo suficiente y tenemos toda la información que
necesitamos. Saltarse este paso implicará que a veces incluiremos trabajo en el sprint para el que
no estamos preparados. Si hay decisiones por tomar, estas robarán tiempo del equipo en el
trabajo y conducirá inevitablemente a retrasos. Si al empezar a trabajar nos encontramos con que
el beneficio no está claro, con que faltan algunos diseños necesarios o datos sobre el contexto o
los usuarios, tendremos que dar un paso atrás y conseguir esta información. Tener una definición
de listo evitará estos pasos hacia atrás y mejorará la comunicación del equipo. Del mismo modo,
tener una definición de listo evitará problemas al final del sprint. Si es necesario documentar algún
proceso, actualizar algún registro o notificar a algún departamento como parte del trabajo en las
historias de usuario propuestas, definirlo como equipo antes de empezar el trabajo ahorrará
malentendidos.

Muchas de las frustraciones en los proyectos vienen por malentendidos entre personas que
pueden solucionarse fácilmente con una conversación. A medida que los equipos de trabajo
crecen y el tiempo pasa, desarrollar una documentación escrita ayudará a mantener alineado el
equipo de trabajo incluso cuando se incorporen a él nuevas personas. Tu definición de listo y tu
definición de completado no deberían ocupar mucho más que unos puntos, así que organiza una
reunión de una hora con tu equipo para debatir estos puntos específicamente y ahorra horas de
discusión, retrasos y malentendidos en el futuro. Como siempre, en los proyectos ágiles recuerda
que estas definiciones pueden cambiar con el tiempo. No te frustres, mantente flexible y recuerda
que en este mundo en constante cambio tu capacidad de adaptarte y de adaptar los procesos de
tu equipo es tu ventaja competitiva.

Las historias de usuario en el sprint

Estimaciones en puntos de historia
Una vez que tenemos un objetivo para el sprint y hemos identificado las historias de usuario más
prioritarias que nos ayudarán a llegar a ese objetivo, es necesario hacer una estimación que nos
ayude a saber si el alcance propuesto para el sprint es realista.

Tradicionalmente, los equipos invertían mucho tiempo en estimar la duración en horas de las
tareas que tenían que realizar. Como contaban con especificaciones muy detalladas y trabajaban
en proyectos con fuertes dependencias y plazos muy estrictos, era importante que esta estimación
fuera lo más acertada posible. En las metodologías ágiles las estimaciones no tienen tanto peso, ya
que se da más importancia a la mejora continua y a la predictibilidad que a la estimación detallada
y el cumplimiento de plazos.

Una de las maneras más extendidas de estimar historias de usuario es a través de puntos de
esfuerzo o puntos de historia de usuario. Este concepto de puntos no tiene relación con horas de
trabajo, sino de esfuerzo. Una misma tarea puede ser realizada en diferentes tiempos por
diferentes equipos. Y en realidad la mayoría de las estimaciones en horas acaban desviándose, así
que estos puntos de historia de usuario proponen deshacerse de este concepto de tiempo
directamente. Normalmente, se usan los puntos 1, 2, 3, 5, 8, 13 y 21 para evaluar el esfuerzo de
las tareas. Estos son los números de la secuencia de Fibonacci, una secuencia matemática
interesante de la que quizás hayas oído hablar y en la que te invito a indagar en caso contrario.
Una historia de usuario de 1 punto es algo muy sencillo que probablemente tardará algunas horas
en realizarse y que no tendrá muchas dependencias ni complejidad técnica. Una historia de 21
puntos es una historia muy compleja, que toque varias áreas de trabajo o para la que haya mucha
incertidumbre.

Cuando me encuentro con historias que el equipo estima en 21 puntos, sé que es necesario
depurarla y que posiblemente incluya en realidad varias historias de usuario más pequeñas. Es
importante que sea el equipo el que estime los puntos de las historias, y hay varias dinámicas o
métodos con los que pueden hacerlo, como el póker de estimación, un juego de cartas para
motivar al equipo a discutir diferentes puntos de vista que afectan a la estimación, o la estimación
por tallajes, que ayuda a los equipos a desvincularse del concepto de horas más fácilmente. Al
finalizar la estimación, el equipo tendrá una idea mejor de la complejidad y el esfuerzo requerido
en el sprint o iteración propuesto y, con datos históricos, será capaz de ajustar el alcance a algo
que encaje con la capacidad histórica del equipo.

Cómo podemos estimar la cantidad de puntos de una historia

Al estimar las historias de usuario del sprint en puntos de historias de usuario, muchos equipos
tienen dificultades para desvincularse del tiempo y acaban asociando puntos a cantidad de horas.
Inconscientemente pero a veces también de forma explícita, asocian 1 punto a una hora, 5 puntos
a medio día, 8 puntos a un día. Acaban volviendo a las estimaciones tradicionales en horas y
vuelven a sufrir los mismos efectos de este método. Las estimaciones se toman por fechas de
entrega. El equipo se retrasa, el proyecto sufre.

Cuando empecé a trabajar con puntos de historia, viniendo de gestión de proyectos tradicional,
también fue complicado para mí. Sin embargo, algo que me ayudó a asimilar la abstracción de las
estimaciones ágiles fueron algunas de las maneras alternativas de estimar que algunos equipos
han propuesto. La más sencilla de comprender es la del tallaje. En las prendas de vestir es
frecuente ver las tallas XS, S, M, L y XL o incluso XXL. No seríamos capaces de decir cuántos
centímetros de largo tiene un pantalón de talla M, pero si sabríamos decir que una talla XS es
mucho más pequeña que una XXL y que una L es algo más grande que una M. Del mismo modo,
algunos equipos tallan sus historias de usuario. Una historia XS requiere poco esfuerzo, es sencilla,
y una XXL es una historia de usuario muy compleja. Con estas tallas es más fácil que el equipo deje
de pensar en horas o en días. Por contra, perderemos la capacidad de comparar sprint entre ellos,
ya que no podemos sumar las tallas. Te recomiendo no usar este sistema en equipos a largo plazo,
sino como una manera de ayudar al equipo a dar sus primeros pasos con las estimaciones de
historias de usuario.

En un taller una vez utilizamos la estimación con pescados: una sardina, un tiburón, una ballena
azul. Como ves, en el fondo, de lo que se trata es de dejar de pensar en horas y de comparar el
esfuerzo de las tareas entre sí tal y como las entiende nuestro equipo en base a sus conocimientos
y experiencia, no de tratar de acertar en el número de horas que tardaremos en realizarlas.

La velocidad del equipo

El objetivo de las estimaciones en los proyectos ágiles no es saber exactamente cuánto vamos a
tardar en realizar el trabajo o de poder dar una fecha exacta de entrega, sino de dar al equipo la
información que necesita para poder planificar cada ciclo de desarrollo y para poder mejorar en
cada una de estas iteraciones.

Las estimaciones ayudan a planificar cada ciclo de desarrollo porque ayudan al equipo a analizar si
la cantidad de esfuerzo estimada es adecuada para el equipo en base a su capacidad en ciclos
anteriores. Pongamos, por ejemplo, que nuestro equipo completó un esfuerzo de 50 puntos en el
ciclo anterior y 60 en el previo. Si al estimar el trabajo de este ciclo acabamos con 30 puntos de
historia, todavía tendríamos hueco para añadir algo más de trabajo. El equipo debería ser capaz de
completar entre 10 y 20 puntos de historia más. En cambio, si al acabar de estimar el trabajo
propuesto para conseguir el objetivo del ciclo de trabajo vemos que tenemos 100 puntos
estimados, el doble de lo que conseguimos realizar en el ciclo anterior, podremos decir sin duda
que el objetivo es demasiado ambicioso y tendremos un buen argumento para reducir el alcance.
Cada equipo estima de diferente manera y la misma tarea puede ser estimada con diferente
cantidad de puntos de historia de usuario por equipos diferentes. No podemos fijar límites
absolutos ni comparar las estimaciones de diferentes equipos, pero sí podemos aprender de cómo
varían las estimaciones de un mismo equipo a lo largo del tiempo o al enfrentarse a tipos de
problemas concretos y usar esto para incorporarlo a nuestra experiencia y mejorar en cada
iteración.

El número de puntos de historia que es capaz de completar un equipo se denomina velocidad.

Aunque es importante que recuerdes que la agilidad no consiste en hacer cosas más rápido y que
nunca uses esta velocidad o las estimaciones para premiar a tu equipo, sí puedes usarlas como
referencia de mejora. Si tu equipo es capaz con el tiempo de ejecutar más puntos de historia en
cada sprint, significará que estáis siendo más efectivos, que conocéis mejor el proyecto o que
habéis optimizado procesos. Si, por el contrario, cada vez se completan menos puntos o si el
número de puntos es muy variable, significará que hay problemas que será necesario analizar y
resolver. Un último comentario sobre los puntos de historia y la medición de la velocidad del
equipo. Aunque no debería darse el caso de que se añada trabajo al ciclo de desarrollo una vez
comenzado, si ocurre, es importante que estiméis este trabajo para poder calcular cuántos puntos
se realizan en realidad.

Validación de historias de usuario

Al momento de planificar nuestras historias de usuario habremos trabajado en unos criterios de
aceptación que nos ayudarán a la hora de validar el trabajo realizado. En lugar de hacer requisitos
y especificaciones técnicas y detalladas, las historias de usuario se centran en los objetivos de los
usuarios y sus beneficios y aportan una serie de criterios de aceptación que sustituyen a las
especificaciones por expectativas.

Los criterios de aceptación se suelen escribir desde el punto de vista del usuario final y en el
proyecto ágil ideal son los mismos usuarios finales del proyecto o el cliente que le represente
quien realice esta validación. Para escribir estos criterios de aceptación puedes inspirarte en cómo
los hacen los equipos de desarrollo de software.

Aunque tu proyecto no sea un producto digital, en el mundo del software se ha trabajado mucho
para mejorar la validación y se ha llegado a un formato de criterios de aceptación que hasta las
máquinas pueden entender. Primero se trabaja en escenarios, las situaciones en las que prevemos
que va a ser necesario usar la funcionalidad, producto o servicio que hemos creado con nuestra
historia de usuario. Luego se describen el contexto o las precondiciones, refinando el escenario.
Normalmente, por cada escenario encontraremos criterios de aceptación con diferentes contextos
atendiendo a los diferentes usuarios que vivirán el escenario o situaciones específicas. Como
tercer paso definiremos para cada uno de estos contextos el evento específico que queremos
validar. Por último, por supuesto, añadiremos una referencia al resultado esperado. Usemos el
ejemplo de la taza para ver qué aspecto tendrían estos criterios de aceptación. Podríamos decir
que un escenario para hacer las pruebas es un viaje en coche. El contexto o precondiciones sería,
por ejemplo, que tengo el vaso lleno de líquido y que el coche está en marcha. Como evento para
nuestro primer criterio de aceptación podríamos definir una frenada fuerte. ¿Funcionará nuestra
taza correctamente cuando nuestro usuario está en un vehículo con su taza llena de líquido si el
vehículo da un frenazo seco? Si nuestro requisito fuera solo que el vaso tuviera una tapa pero no
verificamos cómo funciona en un vehículo en marcha, podríamos enfrentarnos a clientes
enfadados. Correctamente, es bastante abstracto y diferentes personas pueden tener diferentes
opiniones, por eso es importante ser específicos con el resultado. En este caso el resultado
esperado sería que la tapa de nuestra taza evite que se vierta todo el contenido del vaso por el
suelo del coche y la palanca de cambios. Documentar criterios de aceptación de esta manera
simplifica la tarea de revisión y es además más efectiva que hacerlo de acuerdo a requisitos y
especificaciones técnicas solamente.

Puestas en producción
Una vez hemos validado cada historia de usuario de nuestra iteración usando los criterios de
aceptación, será hora de incorporarlas al producto o servicio y de ponerlas en funcionamiento con
usuarios y clientes reales. En el mundo del software esto se llama poner las funcionalidades en
producción. Si trabajas con productos físicos, el equivalente será comercializar el producto. Si se
trata de un servicio, comenzar a ofrecerlo. En cada proyecto se tratará de un proceso diferente y a
medida, muchas veces complejo, pero la idea es común. Abrimos el resultado de nuestra iteración
a usuarios reales con la intención de entregarles valor, pero también de aprender.

En el Manifiesto ágil que se escribió para el software se dice que se valora más el software en
funcionamiento que la documentación extensa. Creo que no hay mejor manera de explicar a los
usuarios cuál será el impacto de nuestra solución en su vida que dándoles el resultado para que lo
comprueben por sí mismos. Y no hay mejor manera de entender su impresión y si ha funcionado
nuestra propuesta que ver lo que hacen con ella cuando se la damos. Es posible que veamos fallos,
que se propongan mejoras que no se habían definido anteriormente o incluso que decidan que lo
que hemos creado no satisface el problema o que genera otros nuevos. En muchas ocasiones,
usuarios o clientes que no tenían opinión sobre el proyecto durante las primeras definiciones se
entusiasman al probar el resultado del primer ciclo de desarrollo. Creo que esta primera entrega a
tu cliente es una de las claves para convencerte del potencial de la gestión ágil de proyectos.

En mi experiencia trabajando con proyectos y productos, sobre todo digitales, aunque muchos de
ellos con una capa de servicio que no era necesariamente digital, he aprendido algo a la fuerza. No
importa cuanto detalle añada, cuantos diagramas, imágenes, simulaciones, prototipos o analogías
prepare, no existe cantidad de documentación o análisis que supere el valor de una solución que
pueda poner en las manos de mis usuarios, aunque sea mejorable o necesite refinamiento.

Preparación y resolución de problemas.

Cuando los clientes piden cambios
Si ya has trabajado en proyectos, estoy casi segura de que alguna vez te has encontrado con que
tu cliente o tus usuarios solicitan algo nuevo que no se había previsto o planificado al inicio del
proyecto. En los proyectos tradicionales se suelen gestionar estos cambios a través de solicitudes
de cambio que el equipo analiza y decide incorporar o rechazar. En los proyectos ágiles los
cambios no son una excepción, sino una regla y algo que cabe esperar.

Como las historias de usuario no detallan implementaciones, sino necesidades y objetivos, es fácil
incorporar cambios menores al proyecto sin tocar las historias de usuario. Estos cambios son
muchas veces maneras diferentes de resolver un mismo problema. En otros casos, los cambios
vienen en realidad de necesidades de usuarios que no se habían descubierto. En muchos casos, un
cambio en las historias de usuario afecta al alcance del proyecto y por tanto afectará al coste y a
los tiempos. Saber trabajar en este contexto de continuo cambio es tal vez el reto más importante
al que te enfrentarás al trabajar en proyectos gestionados de manera ágil. En los casos en los que
tengas un presupuesto cerrado, puedes negociar con tu cliente intercambiar la nueva historia de
usuario por alguna otra que tuvieras prevista. Esto afectará a la calidad del producto final y solo te
lo recomiendo en proyectos muy pequeños o que sean un producto mínimo viable.

Los productos y servicios para funcionar deben estar vivos y actualizarse constantemente. Hacerlo
usando historias de usuario te ayudará a aportar cada vez más valor. Muchas personas consideran
añadir nuevas historias de usuario a un proyecto una vez se ha iniciado un problema y lo achacan a
la falta de comunicación o definición al inicio del proyecto. Yo en realidad lo veo como una
oportunidad, creo que descubrir nuevas necesidades de nuestros usuarios o clientes a las que
podemos contribuir con soluciones nos aporta una ventaja competitiva. Creo que descubrir
historias de usuario debe ser visto como algo positivo. Recibir una nueva historia de usuario
significa que algún usuario del producto dentro de nuestro equipo o entre nuestros clientes o en el
público ha visto una oportunidad de mejorar su vida en nuestro producto o servicio y que le
importa tanto como para hacérnoslo llegar.

Historias de usuario problemáticas.

Las historias de usuario van más allá de una manera de escribir requisitos, son una manera
diferente de pensar en cómo resolver necesidades de nuestros usuarios. Escribirlas mal puede
causar problemas que quiero ayudarte a evitar y resolver. Imagínate que, usando el ejemplo de
historias de usuario para una taza, dijera que mi historia de usuario es «Como directora del
proyecto, quiero crear una taza para que los usuarios puedan beber». Si solo nos fijamos en la
estructura de la frase, nos podría parecer una historia de usuario correcta. Sin embargo, tiene
varios problemas que vamos a identificar y resolver.

- Para empezar, el director de un proyecto nunca debe ser el protagonista de una historia
de usuario. Usuario tampoco es un tipo de usuario válido. Intenta pensar en un perfil de
usuario específico para escribir mejores historias de usuario.
- Otro error de la historia de usuario, quizás el más importante, es que la historia de usuario
habla del entregable del proyecto, no del problema que queremos resolver al usuario. Una
taza es lo que queremos crear, pero esta historia no nos dice nada sobre qué
características debería tener nuestra taza.

Fíjate en lo diferente que es esta otra historia de usuario: «Como persona mayor, quiero un agarre
ergonómico para poder beber con facilidad» . Leyendo esta historia de usuario tenemos claro para
qué segmento de usuario estamos diseñando. Su mayor problema sería la dificultad para beber
derivada de un agarre complicado, proponemos un agarre ergonómico para poder solucionar este
problema. Cuando escribas historias de usuario pregúntate si apelan a un segmento de usuario
específico y si identifican necesidades. Si alguna de estas dos condiciones no se cumplen, te
recomiendo que la escribas de nuevo. Poco a poco irás escribiendo mejores historias de usuario de
manera natural.

Conclusiones y próximos pasos a seguir

Creo que lo más importante es que todo el mundo entienda la motivación del cambio y que es
algo que va más allá de escribir requisitos con una estructura de frase determinada. Anque hay
mucha información en línea, contar con formación especializada puede ser de ayuda. Hay muchas
personas que ya han pasado por este proceso y que son especialistas en formar y acompañar a las
organizaciones en su propia transición.

Tras la formación, diría que es importante que hagas una planificación del cambio, a ser posible de
manera iterativa y con mentalidad ágil. Cambiar la manera de trabajar de toda una organización,
especialmente si se trata de una grande, puede suponer un enorme reto. Trata de hacer el cambio
gradualmente, ganándote la confianza en esta manera de trabajar en un equipo tras otro y
haciendo partícipe al resto de vuestros progresos y aprendizajes.

Por último, mi consejo es que busques estar continuamente aprendiendo sobre los retos que
otras organizaciones tienen al usar historias de usuario. Dicen que cuatro ojos ven más que dos, y
gracias a la cantidad de información, grupos de usuarios y eventos de comunidad que se organizan
sobre estos temas puedes ver a través de los ojos de miles de profesionales.

Dirige reuniones ágiles y productivas

Introducción
En un proyecto ágil, no se planifica con mucha antelación. Al comenzar a trabajar en él, nunca se
sabe cuál será el resultado o el producto final. Se empieza con una noción general de hacia dónde
se va y se va refinando esa idea durante el camino. El modelo Agile es adaptable y nada predictivo.
Mucha de su energía deriva de las ideas nuevas y los cambios. Este curso forma parte de la serie
Agile en acción y se titula Dirige reuniones ágiles y productivas. Vamos a dedicarnos a analizar y a
profundizar en algunas ceremonias ágiles. Veremos cómo planificar las reuniones y también cómo
programar las tareas de forma controlada. El objetivo de esta serie es ayudar a tu equipo a
aumentar el ritmo y la calidad de su trabajo. Si el método te resulta nuevo o no conocías algunos
de los términos, quizá sea mejor que veas la serie desde el principio. Comencemos a dirigir
reuniones ágiles y productivas.

Las reuniones ágiles

Un método ligero
Muchos equipos ágiles celebran lo que llaman «actividades de Scrum», reuniones muy
estructuradas y organizadas que representan muy bien los límites del equipo. No debemos
confundir estas actividades con las charlas informales y cotidianas de cuando se comparte el
espacio de trabajo. Estas reuniones improvisadas son lo que necesitan los desarrolladores para
resolver los problemas y negociar los detalles. El espacio compartido de trabajo depende mucho
de la comunicación por ósmosis, situaciones muy similares a las conversaciones que se tienen
durante la cena. Significa que puedes oír las conversaciones de los demás aunque estés trabajando
en tus proyectos.

Los seres humanos absorbemos muchísima información en los espacios compartidos, y esta
habilidad lleva el nombre de comunicación por ósmosis. Podría decirse que un equipo ágil está
siempre reunido. La comunicación osmótica se ha perfeccionado durante milenios. Tu equipo ágil
debe aprovechar esta habilidad natural y darle importancia a la ubicación de sus miembros.
Compartir el espacio de trabajo es más que suficiente para que el equipo sea consciente del
progreso de todos. Los seres humanos tenemos el instinto natural de asimilar las conversaciones a
nuestro alrededor. El objetivo de las reuniones programadas sería reemplazar la comunicación
artificial a través de mensajes de voz o correos electrónicos. Piensa en cuántas veces has
necesitado reunirte con alguien en persona para entender lo que te decía. La combinación de
comunicación por ósmosis y un espacio compartido debería evitar unas cuantas reuniones
programadas, que, en su mayoría, no aportan mucho valor al trabajo.

Peter Drucker, consultor administrativo, dijo una vez que las reuniones representan concesiones.
O te reúnes o trabajas. No se pueden hacer las dos cosas a la vez. Y esto se ve muy claro en las
reuniones de balance, esas reuniones que todos los que hemos trabajado en grandes empresas
conocemos bien y en las que, por lo general, alguien presenta diapositivas a un público reducido.
El problema con estas reuniones es que no aportan valor para el cliente. Recuerda que en Agile se
trabaja con software funcional. Cualquier producto que no sea funcional no proporciona valor. En
los equipos modernos, estos programas requieren colaboración interna. Una reunión de balance
no es colaborativa, por lo general se trata de una persona presentando información al grupo.

Una vez, trabajé en una empresa que le daba mucha importancia a lo que llamaban «socialización
del proyecto», o el equivalente a «te cuento lo que hago y tú me cuentas lo que haces». En estas
reuniones, el equipo ágil invertía mucho tiempo en presentar su trabajo a otros grupos y se
celebraban durante varios días. El equipo compartía su trabajo con cuatro o cinco otros grupos de
trabajo. Cada grupo estaba formado por alrededor de cinco miembros y había muchos canales de
comunicación. Para cumplir con esos canales, cada equipo se reunía durante varias horas al día.
Era un ejercicio agradable y toda la gente de la oficina acabó conociendo a los demás, pero desde
una perspectiva ágil era una pérdida de tiempo. Cada equipo producía un veinte por ciento menos
en cada ciclo. Recordemos que, en la cultura de las empresas, este tipo de reuniones están muy
enraizadas. Tienes que elegir qué batallas librar. Intenta ser muy transparente al considerar el
tiempo que el equipo está perdiendo. El equipo ágil de esa empresa decidió trabajar con un panel
de reuniones. En el panel se explicitaba cuántas horas de cada ciclo se ocupaban para socializar en
el trabajo. Así, con un cálculo simple podíamos averiguar dónde se perdía productividad. Cada
empresa es diferente y algunas querrán conservar sus rituales de reuniones. Si eres el
ScrumMaster, explícales que Agile es un método ligero. Si hay demasiadas reuniones externas, el
resto del equipo se abrumará.

Celebra reuniones ágiles

En Scrum se engloban cinco actividades bien establecidas. Llevan el nombre de reunión,
planificación, refinamiento, demostración y perfeccionamiento. cada una de estas actividades
debe producir un resultado. Cada actividad es ligera, pero tiene una programación limitada. Cuatro
de las cinco están limitadas a un tiempo máximo. Si eres el ScrumMaster del equipo, asegúrate de
entender todas estas actividades y los resultados esperados. Al principio del proyecto, los
ScrumMasters ocuparán la mayor parte del tiempo en proteger estas actividades, que deberían
reunir al menor número posible de personas. Todos deben centrarse en los resultados que puedan
alcanzar.

En las reuniones tradicionales, se suele intentar darles voz a todos los miembros. Cuando un
proyecto se superpone con el trabajo de un departamento, debes invitar a un representante. En
Agile, las actividades deben ser mínimas y cortas. Por ello, la programación de estas actividades
tiene un tiempo y alcance limitados, y todo el equipo debe respetar estas restricciones.

- La actividad más frecuente son las reuniones diarias, que son reuniones de 15 minutos en
las que el equipo de desarrollo comunica las tareas que están en marcha. Recuerda que
 esta es una actividad de los desarrolladores. El resto del equipo debe sentarse y escuchar.
Esta es una actividad por y para el equipo, y en ella se responden tres preguntas: ¿Qué
hice ayer? ¿Qué estoy haciendo hoy? ¿Hay algún obstáculo en mi camino? Las dos
primeras preguntas son para los otros desarrolladores. La última generalmente va
destinada al ScrumMaster. De todas las actividades, esta es la única que el equipo efectúa
diariamente.

- La segunda actividad es la planificación del ciclo, en la que el equipo predice el trabajo

que se completará durante las dos semanas siguientes. Se le suelen dedicar cuatro horas
al comienzo de cada ciclo. El equipo extrae los artículos de mayor valor de la lista de
pendientes del producto y se asegura de que todo el mundo entienda la entrega prevista.
El propietario del producto debe asistir a esta reunión porque decidirá cuál es la mayor
prioridad y también debe responder las preguntas del equipo.
- El refinamiento de la lista de requisitos es la actividad más flexible en Agile. El resto de
actividades tienen límites. En esta, el propietario del producto convoca una reunión para
estimar si hay nuevos requisitos. Y necesita estas estimaciones para poder priorizar el
trabajo pendiente. Estas reuniones son las menos estructuradas. El propietario del
producto repasa los requisitos del producto con los desarrolladores, que pueden hacer
recomendaciones sobre cómo organizar la lista. Pueden segmentar las tareas grandes en
otras más pequeñas y convencer al propietario del producto para que quite algunos
elementos de la lista.

- La cuarta actividad es la demostración del producto, que también suele llamarse

«revisión del ciclo». Al final de las dos semanas, se le dan dos horas al equipo para mostrar
el trabajo completado a las partes interesadas del proyecto. Quien dirige la reunión suele
ser el propietario del producto, que es quien está más cerca del cliente y quizá también
mejor calificado para responder las preguntas. Durante la demostración, las partes
interesadas deben participar activamente. En cada demostración se muestra el trabajo de
las últimas dos semanas y también deben aceptarse las sugerencias y opiniones de las
partes interesadas.
 - La quinta y última actividad es el perfeccionamiento. Esta actividad se limita a dos horas y
se lleva a cabo justo después de la demostración del producto. También se le suele llamar
«retrospectiva del equipo». de las cinco actividades, esta es sin duda la más importante. Si
el equipo no puede mejorar, por lo general cometerá los mismos errores en el resto de
ciclos. Al principio, puede que el ScrumMaster deba darle un empujón al equipo para que
se comprometa con mejoras específicas. Cada empresa tiene sus desafíos y a menudo será
el ScrumMaster quien deba mantener la energía positiva y la capacidad de producción.

Las cinco actividades se interrelacionan para que el equipo se mantenga ligero y productivo. Si
eres el ScrumMaster, intenta asegurarte de que las actividades sigan las pautas de Scrum. Las
reuniones deben ser ligeras, pero bien estructuradas. Asegúrate de no dejar que estas actividades
consuman mucho tiempo o se conviertan en una reunión tradicional.
Los plazos en los proyectos ágiles
Un proyecto ágil depende de un plazo de tiempo repetible y limitado. Se trata de un plazo que no
puede extenderse. Si la reunión se limita a una hora, no puedes pasar más de una hora con esa
actividad. Cuando termina la hora, la actividad finaliza. Es la piedra angular en la que se basa toda
la planificación y la programación en Agile. Todo el trabajo de un proyecto ágil se segmenta en
plazos de tiempo más cortos. Los desarrolladores también tienen su propio plazo: deben trabajar
jornadas de ocho horas y cualquier prórroga influirá en la previsibilidad de la entrega.

Para entender la importancia los plazos, debes considerar el proyecto ágil en todo su conjunto. En
un proyecto ágil no se planifica demasiado. Cuando inicias un proyecto ágil, no puedes prever el
producto final. Empiezas con una noción general de hacia dónde vas y aplicas mejoras frecuentes
para poder llegar allí. Agile es adaptable y no predictivo. Gran parte de la energía proviene de
ideas nuevas y de cambios. Para obtener un alto grado de previsibilidad, un proyecto ágil necesita
una programación predecible con plazos cortos y repetibles. La entrega se construye de un bloque
a la vez, como una torre de Legos.

Imagina que tienes una caja de 500 bloques Lego y que cada uno de esos bloques representa una
unidad de trabajo. Con el paso del tiempo, tu equipo puede prever que se construirán 50 bloques
cada dos semanas. El plazo del ciclo, entonces, será de dos semanas. Durante cada plazo, se puede
construir con 50 bloques. Y tu presupuesto de 500 bloques de Lego se consumirá en diez ciclos.
Siguiendo este cálculo, en 20 semanas, habrán entregado una estructura impresionante de 500
bloques. Puede ser una casa, un auto o hasta un acorazado. Eso lo define el dueño del producto.
Lo único que sabe el equipo es que, al concluir los diez ciclos, deben tener una construcción de
500 bloques.

Imaginemos que en la ciudad hay una convención y todo tu equipo se tomó una semana libre. al
volver al trabajo, se encuentran con que llevan un retraso de 50 bloques. Pueden optar por
prolongar el plazo una semana para poder acabar el proyecto. Eso no es problema. El problema
real es que se ha roto el ciclo. En 10 semanas habrán colocado solamente 475 bloques y les
quedarán unos 25 por ubicar. Tu equipo se comprometió a entregar el trabajo en diez ciclos y
ahora el trabajo está incompleto. Sea como sea, el equipo no ha respetado la previsibilidad de diez
ciclos para 500 bloques. Ahora no queda claro qué se entregará ni cuándo. Es mucho menos
predecible y el patrocinador de Lego no estará muy satisfecho. Las bajas por enfermedad, las
vacaciones y las formaciones también deben considerarse en los proyectos. El truco consiste en
completar la cantidad de bloques que necesita el equipo durante cada ciclo. Quizá el equipo debía
comprometerse a colocar solo cuarenta bloques por ciclo. El equipo se compromete a un ritmo
para todo el proyecto. Si una semana hay una convención y solo pueden colocar 30 bloques,
durante el ciclo siguiente deberán colocar 50. Así, tendrán un promedio de 40 bloques por ciclo.
En ese proyecto, la velocidad el equipo es de 40 bloques. Se trata de la cantidad promedio a la que
pueden comprometerse durante cada ciclo. Se imponen plazos a todas las tareas del equipo en
todas las actividades ágiles. Las reuniones diarias deben durar 15 minutos. Si un día les lleva una
hora y al día siguiente 10 minutos, habrá variables en el proyecto. Lo mismo ocurre con todas las
demás actividades. Si la reunión de planificación lleva cuatro horas en un ciclo y dos horas en el
siguiente, también aumentará la variabilidad. En un ciclo, el equipo tendrá dos horas más de
trabajo y, en el siguiente, dos horas menos. Será muy difícil crear un ritmo predecible si no se
implementan estos plazos. Es injusto preguntarle al equipo cuándo completarán una tarea si no
pueden pensar en unidades predecibles de tiempo. El ScrumMaster es el responsable de que esos
plazos sean constantes. Deben ayudar al equipo a considerar que el tiempo es un recurso limitado
y se puede medir.

Planea el lanzamiento
Fija la fecha de entrega
Fijar una fecha de entrega puede parecer contrario a la premisa ágil de hacer cambios frecuentes.
El propietario del producto prioriza el trabajo durante cada ciclo. Si él no puede definir la entrega,
¿cómo es posible que programe una fecha concreta de lanzamiento? ¿Cómo puede
comprometerse el equipo cuando el cliente no puede definir el producto? La realidad es que con
el modelo Agile se produce software funcional en cada ciclo. No hay una presentación planificada.
No hay que esperar al final para ver todo el resultado. Durante cada ciclo, el producto se conforma
y se mejora poco a poco. Se presentan nuevas características y el propietario puede ver las
mejoras. Pero la forma de trabajo de un equipo ágil suele ser bastante contraria a lo que exigen las
organizaciones. Seguramente haya ferias de muestras y presiones del equipo de contabilidad. Hay
muchísimas razones para planificar una fecha de lanzamiento.

La diferencia entre la forma de entrega de un equipo ágil y los requisitos de la empresa crea una
gran brecha de expectativas, y tienes herramientas para subsanarla. Tienes la lista de requisitos
del producto, de la entrega y del ciclo. Para cada lista de requisitos, se espera que el cliente
resigne un poco de flexibilidad por un bien mayor. La lista de pendientes para el lanzamiento es un
compromiso con el propietario del producto. El equipo le presenta a la empresa compromisos más
firmes para las entregas de cada ciclo. A cambio, el propietario renuncia a parte de su libertad para
pedir cambios. Cuando el propietario del producto pasa de la lista del producto a la de
lanzamiento, se espera que no haga cambios demasiado importantes. Esta flexibilidad se controla
aún más con la lista de requisitos del ciclo. Al pasar a esta lista, cada artículo está ya establecido.
Debes recordar que la lista de requisitos para el lanzamiento es como un tobogán que cae hacia
una cascada. Si respetas los peligros, obtendrás un gran valor de las ideas adicionales. Si priorizas
demasiado esta lista, puede que acabes volviendo a aplicar los procesos tradicionales de gestión
de proyectos. Si eres el ScrumMaster, vigila de cerca la lista de requisitos de lanzamiento. Todos
deben estar atentos a los peligros y tener comunicación directa con el propietario del producto.
Esta lista puede ser una herramienta útil, pero también puede resultar en que el propietario se
involucre menos con el equipo. Es una gran tentación pasar la mayoría del trabajo a la lista de
lanzamiento y ponerse a trabajar en otros proyectos. Entonces, el proyecto ágil comenzará a
parecerse a cualquier otro proyecto de gestión tradicional. El propietario del producto formula la
lista para el lanzamiento y vuelve a los pocos meses para evaluar el progreso del equipo. Si ves que
el propietario presenta la lista y vuelve a su escritorio, ya puedes hacer sonar la alarma.

Elaborar una lista de requisitos para el lanzamiento no significa que el dueño del producto pueda
alejarse de equipo. Otra forma de lograr que el equipo programe un lanzamiento es planificar una
fecha de OVA, o una fecha en la que se comunicará el orden de valor aproximado del proyecto. La
ventaja de esta técnica es que la empresa continuará trabajando según el valor. El modelo Agile
intenta asegurar que los productos que se entregan sean del mayor valor posible. Puede que los
productos cambien durante el desarrollo. Si se planifica un OVA, nadie quitará la vista del objetivo.
Y no se trata de lo que se ha logrado con el producto, sino de un compromiso para dar un valor
aproximado del producto en una fecha exacta. Imaginemos que estás creando un software para
tabletas móviles. Un plan de lanzamiento típico consiste en describir las características finales del
software. Al presentar un OVA, el objetivo está en el valor que proporciona el producto. Puede ser
que quieres conectarte con tus amigos o que quieres compartir experiencias. La presentación no
tiene que ver con las características sino con el valor. Para cualquiera de estas técnicas, recuerda
que el poder del modelo Agile proviene de su habilidad para explorar y efectuar cambios
frecuentes. Cada empresa debe plantearse cuánta libertad puede tolerar. Algunas renunciarán a
un poco de flexibilidad a cambio de poder profundizar en las características finales. Y eso está
bien, siempre y cuando todos comprendan el equilibrio que se necesita. Otras empresas querrán
que el propietario del producto tenga libertad plena para poder entregar un producto de máximo
valor. En esos proyectos, la mejor opción será hacer una presentación de OVA

A entrega sin un alcance definido

En los proyectos tradicionales, el campo de acción es el qué y el cómo de tu producto. Es la fuerza
que evita que ofrezcas de más. Imagina un momento que tu proyecto es entregar una pila de
panqueques recién hechos. El «qué» es la pila de panqueques. Y entonces, el «cómo» será el
esfuerzo que conlleva prepararlos. La plancha caliente, la harina y los huevos son parte del ámbito
de tu proyecto. Y el ámbito es una limitación importante. Por ello, en proyectos tradicionales se
suele oír la frase «si no es parte del ámbito, no es parte del proyecto». Se crea el campo de acción
antes que la programación o el presupuesto. En la gestión de proyectos tradicional, se le llama « el
triángulo de hierro». El campo de acción, el presupuesto y la programación son una unidad. Si
cambias un factor, deberás cambiar también los otros dos. Un cambio en el campo de acción
llevará a cambiar la programación y el presupuesto. En un proyecto ágil, el ámbito es variable y se
empieza por definir el programa y los costos. El patrocinador establece cuándo quiere el producto
terminado. Luego, decide cuánto está dispuesto a pagar por él. El equipo conforma este ámbito
según el presupuesto y la programación. El presupuesto y la programación son invariables durante
todo el proyecto. El campo de acción puede cambiar según qué prioriza el propietario del
producto. En el modelo Agile, no se establece una fecha para delimitar el ámbito. El patrocinador
obtiene todo el campo de acción por el que paga según las restricciones originales. Al final, recibirá
lo que el propietario del producto priorice como el mayor valor.

El triángulo de hierro no funciona en un proyecto ágil. Debes eliminar la base del triángulo y
ponerlo patas para arriba. Tiene la forma de una vasija de hierro. Los dos lados representan el
costo y el programa de trabajo. Pero puedes llenar la vasija con todo el campo de acción que te
permitan el programa y el costo. En Agile, la calidad y el valor no están fuera del campo de acción.
Un equipo ágil no puede entregar productos de baja calidad porque no entrarían en la definición
de entrega ágil. Cuando llenas la vasija, la calidad está comprendida dentro del ámbito.
Analicemos la diferencia entre el triángulo y la vasija de hierro. Imagina dos proyectos. Uno se
basará en el triángulo de hierro. El otro, en la vasija. Los dos proyectos aspiran a crear una
aplicación de móvil para poder encontrar el puesto más cercano para comprar un burrito. La
primera se llama Burrito tradicional. La segunda, Burrito ágil.

- El patrocinador de Burrito tradicional quiere elaborar un plan muy detallado del proyecto.
Define todas las funcionalidades de la aplicación antes de que el equipo empiece a
pensarla. El alcance, el costo y la programación están íntimamente relacionados desde el
principio. Pasemos al proyecto ágil.
 - Para Burrito ágil, definen rápidamente el costo y el programa de trabajo. El patrocinador
quiere la aplicación en seis meses según un presupuesto definido. No es necesario definir
el ámbito de trabajo. El equipo empieza a desarrollarlo. Comienzan a llenar la vasija de
hierro con los elementos de mayor valor según la programación del proyecto. La prioridad
que fija el propietario del producto es hallar un buen burrito. La segunda prioridad es
calcular la distancia entre el burrito y el cliente hambriento. Poco después de comenzar, el
equipo de Burrito ágil descubre que hay otra aplicación similar. El dueño del producto
decide reevaluar rápidamente el alcance del proyecto. Cambian la aplicación. Ahora se
llama Faro burrito. En vez de buscar burritos, la aplicación funciona en segundo plano. El
vendedor envía cupones de descuento cuando el cliente está cerca del puesto de burritos.
Como no se cambió el campo de acción, el dueño del producto puede repriorizar el
trabajo. La aplicación se entrega a tiempo, pero Faro burrito es muy diferente del
producto original.

La aplicación Burrito tradicional no podría hacer cambios tan fácilmente porque una muy buena
parte del costo y de la programación del proyecto se consumieron durante la planificación. El
patrocinador tendría que abandonar el plan después de haber invertido considerablemente.
Tendrían que volver a empezar con un nuevo campo de acción, un nuevo costo y una nueva
programación. Es muy posible lograr una aplicación de burritos exitosa con el triángulo de hierro.
Pero el patrocinador debe saber que deberá renunciar a cierta flexibilidad. Los proyectos con un
alcance definido funcionan bien con pocos cambios. Sin embargo, el desarrollo de software suele
ser volátil y propenso al cambio. Por ello, es más fácil trabajar en ellos sin un campo de acción
demasiado definido. Un proyecto ágil le proporciona al equipo la flexibilidad para adaptar el
ámbito con los elementos de mayor prioridad.

Invita a los grupos apropiados

Si tu empresa acaba de empezar a trabajar con el modelo ágil, el equipo requerirá mucha
atención. Suele haber interesados fuera del equipo que quieren participar en sus actividades.
Puede ser por curiosidad o porque algún departamento tenga interés en el producto y quiera
darse una vuelta para observar el progreso. El equipo ágil casi siempre se beneficiará de esta
atención extra. El desafío consiste en mantener el interés en el producto sin agobiar al equipo con
demasiada participación externa. La responsabilidad de que las actividades sean eficaces es del
ScrumMaster, y debe analizar muy bien a quiénes se les permite colaborar. Piensa en los
beneficios a largo plazo. Debes asegurarte de que hable la gente adecuada y también escuche la
gente adecuada. Puede que no sea buena idea decirle a un alto ejecutivo que no puede hablar
durante la reunión. Si se acerca alguien importante, lo mejor será permitirle que colabore. Debes
tener cuidado con los interesados que participen en tus actividades con regularidad: como los
gerentes que se autoinvitan a tus reuniones de planificación. Lo mejor será que establezcas las
normas al principio del proyecto. Si permites que las actividades se conviertan en un foro abierto,
será muy difícil poner límites. Al principio del proyecto, el ScrumMaster debe explicarles a todos
que las actividades ágiles deben estar bien estructuradas. No se espera que hablen todos. Para
evitar las confusiones, el ScrumMaster deberá dividir al equipo en dos grupos: los que escuchan y
los que hablan.

- El grupo que escucha estará formado por quienes están interesados en la actividad pero
no deben contribuir.
- Los que hablen serán miembros del equipo de quienes se espera que colaboren. Al
designarles un rol a los miembros, lograrás que avance el proyecto.

La división en dos grupos no son simples etiquetas. Los que escuchan deben sentarse a un lado
como señal de que no deben hablar. Suele ser difícil para el ScrumMaster evitar que este grupo
hable. Debes ser delicado pero, a su vez, muy claro y defender la actividad ágil. El plazo que le
corresponde a esta actividad da muy poca libertad de acción y ese tiempo es muy vulnerable y
puede verse en peligro. Puede que el que escucha se apropie de la actividad para hacer un anuncio
o preguntar algo. Eso te robará un tiempo muy valioso. De todas las actividades, la reunión diaria
es la más vulnerable en este sentido. Los que hablen deben ser los desarrolladores. La reunión es
para ellos. El propietario del producto, el ScrumMaster y el jefe del proyecto deben simplemente
escuchar. Si el gestor del proyecto se apropia del tiempo, la actividad seguramente se salga del
plazo establecido. Trabajé en varios proyectos con esa situación. Los gestores se limitaban a
celebrar sus propias reuniones de balance. Escuchaban a los desarrolladores y, si oían algo
interesante, se dedicaban a expresar sus dudas y preguntas. En esos casos, el ScrumMaster debe
convencer al gestor de que tiene que sentarse, escuchar y esperar al final. Ellos programaban otra
reunión inmediatamente después de esa. La demostración del producto es otra actividad que
puede ralentizar el avance. Esta actividad la suele encabezar el dueño del producto. Debe
asegurarse de que está de acuerdo con el patrocinador en la visión del producto. Por lo general,
ocurre que los desarrolladores quieren un poco de visibilidad. Y tiene sentido, porque el equipo de
desarrollo estará orgulloso del producto y querrá mostrarle al patrocinador todos los detalles
importantes, querrán dar la vuelta de la victoria. Pero la demostración también tiene un plazo.
para que la actividad sea eficaz, el equipo de desarrollo debe escuchar y limitar sus contribuciones.
Solo podrán hablar cuando el propietario del producto les haga una pregunta. Si no ocurre así,
deben recordarles que la actividad está dedicada al propietario del producto y que el resto del
equipo está ahí para ver y escuchar, y esto muchas veces le da al resto del equipo una mejor
perspectiva de la actividad.

Participé en demostraciones en las que los desarrolladores retomaban los temas que el dueño del
producto dejaba en el aire. para que una actividad ágil funcione, debes evitar que el grupo que
escucha hable. Es más fácil decirlo que hacerlo, sí. El ScrumMaster deberá ser muy hábil.
Esfuérzate al principio por explicar el procedimiento a todos. Un esfuerzo al comienzo suele evitar
dolores de cabeza más adelante

Mantén sincronizado al equipo.

Las reuniones diarias ágiles
De todas las actividades de Agile, es probable que la reunión diaria sea la que menos se entienda.
El tema central es la autoorganización. El equipo de desarrollo está de pie en un círculo y se
actualizan los unos a los otros sobre el proyecto en marcha. Parece sencillo, pero la mayoría de las
empresas no opera así. Quien convoca las reuniones suele liderarlas. Las reuniones diarias ágiles
son todo lo contrario a lo que cree la mayoría. Muchos gerentes pensarán que un grupo se fue a
charlar de pie y seguirán así hasta que alguien comience la reunión.

El ScrumMaster y el jefe del proyecto deben vencer la tentación de liderar estas reuniones de pie.
Puede que al principio charlen de cosas irrelevantes, pero rápidamente mostrarán más disciplina.
Respeta siempre el plazo durante las primeras reuniones. Muchas se prolongarán hasta la
eternidad si hay trabajo por terminar, pero las actividades ágiles no pueden darse ese lujo porque
deben acabar cuando finalice el plazo de tiempo fijado. Míralo así: si el equipo no puede
organizarse en una reunión diaria, ¿cómo va a hacer para entregar un producto funcional? Las
reuniones diarias son un buen indicador del progreso del equipo autoorganizado. Si eres el
ScrumMaster, fíjate en cómo interactúa el equipo. ¿Van a tientas, no están seguros? ¿Con quién
hablan? Eso te dará pistas sobre lo que piensan los desarrolladores. Si solo miran al ScrumMaster,
significa que aún no se están organizando ellos mismos. Deberás ofrecerles formación a esos
desarrolladores. Trata de animarlos a mirar a otros miembros del equipo. Deben entender que
trabajan el uno para el otro.

Estas reuniones suelen celebrarse al principio de cada jornada laboral, pero no es la primera
actividad de la mañana. Dale al equipo un poco de tiempo para acostumbrarse. La mayoría de las
reuniones empiezan a las 9:30. El equipo se pone de pie en el espacio compartido de trabajo y
forma un círculo. Están de pie para que la reunión sea más corta. Si tu equipo decide sentarse,
puede que les cueste más acabar la reunión. A algunos equipos les gusta pararse delante del panel
de trabajo para señalar el trabajo. Otros se quedarán donde se sientan cómodos. Algunos se
congregan alrededor de la máquina de café. Si no eres desarrollador, deberás limitarte a escuchar:
te sentarás a un lado y tomarás notas. Los únicos que deben participar activamente son los
desarrolladores. El ScrumMaster y el propietario del producto pueden responder preguntas, pero
no deben iniciar conversaciones. Para cada equipo hay una reunión diaria. Nunca fusiones varios
equipos en una sola reunión. El plazo no te permitirá oír a tantos desarrolladores. Cuando el
equipo esté establecido, deben contestar tres preguntas en no más de quince minutos. ¿Qué hice
ayer? ¿Qué estoy haciendo hoy? ¿Hay algún obstáculo en mi camino? Lo importante es que la
reunión avance. Un equipo mediano de siete desarrolladores tendrá unos 45 segundos por
pregunta. Cuando un desarrollador hable de lo que hizo ayer, debe comentar tareas específicas.
No permitas que compartan o desarrollen conocimientos. Una buena respuesta a la primera
pregunta sería algo así: «Ayer acabé los campos de contraseña para la página de inicio de sesión
del cliente. Y muevo esa tarea a la columna de tareas acabadas». Compárala con esta respuesta:
«Ayer al fin descubrí por qué es tan difícil iniciar sesión en la página móvil. Resulta que la nueva
versión de JavaScript no está completamente documentada. Tuve que pasar mucho tiempo
buscando en la web. Y encontré un sitio llamado JavaDev. ¿Alguien lo conoce? Tienen información
muy actualizada». Esa persona seguirá hablando sobre la mejor forma de averiguar información
sobre JavaScript. Esa respuesta acaparará todo el tiempo. Si esto sucede, al acabar la reunión, el
ScrumMaster deberá explicarle al equipo cómo contribuir dentro de su plazo fijado. Pero debe
luchar contra el impulso de intervenir en medio de la reunión. Esto puede ocasionar que algunas
reuniones fallen, pero será mejor a largo plazo para fomentar la autoorganización.

A muchas empresas les cuesta mucho permitir que los equipos organicen sus propias reuniones.
Si el jefe de producto controla la actividad, ten cuidado. Si van por ahí y le preguntan a cada uno:
«¿Qué hiciste ayer? ¿Qué estás haciendo hoy? ¿Tienes algún obstáculo?», verás un mensaje muy
claro. «Voy a dirigir este equipo autoorganizado». Si este es el caso de tu equipo, todo el proceso
se ralentizará. Enviará un mensaje confuso a los desarrolladores. Esto confunde el rol del jefe de
proyecto. Puede que los desarrolladores crean que están trabajando para el gestor. Y recurrirán a
él con preguntas sobre el desarrollo del producto. Si el jefe de proyecto responde a esas
preguntas, tu proyecto se transformará rápidamente en uno tradicional. Si el equipo también trata
al ScrumMaster como un jefe de proyecto, puede haber más problemas. Porque te encontrarás
con que tienes un jefe tradicional y uno ágil. Tu equipo autoorganizado tendrá dos jefes. Un
equipo ágil debe centrarse más en la autoorganización. Si tú eres el ScrumMaster, intenta trabajar
con los jefes para asegurarte de que no se hagan cargo de tu equipo.

Elimina los obstáculos

Una empresa siempre va a buscar líderes. Los jefes se quejan de que necesitan más líderes. Los
ejecutivos buscan liderazgo en los postulantes que entrevistan. Envían a los gerentes antiguos a
seminarios de liderazgo y les recomiendan libros. Se suele pensar que el liderazgo es una cualidad
muy común. Líder es una persona que se hace cargo de los resultados. Los líderes hacen avanzar al
equipo. No hay duda de que el liderazgo es muy importante en las empresas. Un gran líder puede
lograr cosas brillantes. Pero quienes completan muchas de las tareas no son los líderes. No todo
requiere un gran liderazgo. No siempre es el líder quien impulsa al equipo. Hay muchas personas
que evitan que el equipo caiga. Y ahí entra en juego el ScrumMaster. Es él quien eliminará los
obstáculos para que el equipo pueda centrarse en la entrega. Y los obstáculos pueden ser muy
variados. A menudo, el ScrumMaster confunde las tareas de eliminar obstáculos y gestionar el
equipo. En vez de pensar en los obstáculos individuales uno por uno, sepáralos en grupos. En
general, encontrarás cinco grupos de obstáculos para un proyecto ágil. Si el obstáculo que tienes
no entra en ninguno de estos grupos, es probable que estés controlando al equipo. Para recordar
estos grupos, recuerda este acrónimo: P.A.C.E.C. O preparar, asesorar, contribuir, enseñar y
contratar.

- El primer grupo de obstáculos tiene que ver con la preparación del equipo. La «P» viene
de «preparar». En algunas empresas, preparar el espacio compartido de trabajo puede ser
un obstáculo gigante. Si tu equipo ágil trabaja en filas de cubículos, puede ser una tarea
ardua y difícil. Si la empresa aceptara esta forma de trabajo ágil, no los habría puesto en
cubículos. La preparación no se limita al espacio compartido de trabajo. También incluye
los roles en el equipo. Puede ocurrir que la empresa no acepte tener un propietario de
producto y será el ScrumMaster quien deba convencer a los directivos de que es un rol
muy necesario.
- El siguiente grupo de obstáculos lo representa la A de «asesorar» y tiene que ver con la
formación. El ScrumMaster debe tener un gran conocimiento del modelo Agile, pero es
probable que el resto del equipo no lo conozca bien, en especial el propietario del
producto, que es el miembro del equipo que más necesitará aprender. Seguramente
conozca el producto pero no tenga idea del desarrollo. El ScrumMaster debe asesorarlo
desde el principio. Debe ayudarle a definir su rol y a confeccionar la lista de requisitos.
- El tercer grupo de obstáculos es la C de «contribuir». Es probable que el Scrum Master
provenga de un entorno técnico. No va a ser un desarrollador, pero debe señalarles las
mejores prácticas. Sin embargo, debe recordar siempre que una cosa es contribuir y otra
dirigir. Como regla general, una contribución se pide y una dirección se ofrece. Si el
desarrollador le pide opinión al ScrumMaster sobre una biblioteca de JavaScrip, estamos
hablando de una contribución. Estaría dirigiendo si, en una reunión con el propietario del
producto, el ScrumMaster le recomendara una estructura de JavaScript en especial.
- El cuarto grupo de obstáculos es la E de «enseñar». Y es el ScrumMaster quien enseñará
al resto del equipo los conceptos ágiles. Muchos desarrolladores habrán trabajado en
 proyectos similares al modelo Agile, pero puede que esas prácticas fueran equivocadas y
acaben enseñando esos conceptos erróneos. O puede ocurrir que el equipo empiece a
trabajar sin ninguna formación. El ScrumMaster debe identificar ambos casos como
obstáculos. La capacitación es una muy buena forma para que todos comprendan la
estructura, y también para que todos hagan lo mismo al mismo tiempo.
- El último grupo de obstáculos es la C de «contratar». La participación del Scrum Master en
la contratación de empleados es un tema especial. Un equipo autoorganizado debe tener
control sobre sus propios desarrolladores o les estarás dando la responsabilidad de la
entrega, pero no les estarás permitiendo que decidan el rumbo. Pero tampoco quieres que
el equipo pierda tiempo con entrevistas y ofertas de trabajo. Les quitaría muchas horas de
trabajo. Piensa en el ScrumMaster como en un administrador de contrataciones. Anuncia
las ofertas y organiza las entrevistas. Cuando encuentra a un candidato, concierta una
reunión con el resto del equipo. Si el equipo aprueba la contratación, también negociará el
sueldo de esa persona. Esto no tiene que ver con quién controla el equipo, sino con
mantener a los miembros concentrados en el producto.

Como agregar trabajo a los ciclos

Planea los ciclos del proyecto
La planificación por ciclos es crucial para la predictabilidad y transparencia del equipo. Es el
momento en el que el equipo decide qué debe concretar durante ese ciclo. Por lo general, la
actividad debe durar dos horas. Primero, el propietario del producto les presenta a los
desarrolladores las historias de usuarios de más valor. Luego, el equipo se encarga de establecer
las tareas para esas historias. Muchos equipos ágiles usan un panel de tareas en estas reuniones.
El panel de tareas es una de las herramientas más conocidas de Agile. Los habrás visto en libros,
sitios web o si ya has trabajado con equipos ágiles. Son los paneles blancos con notas en papeles
amarillos. Estos papeles van de izquierda a derecha y, con una cinta azul, se dividen en columnas.
Las columnas llevan títulos diferentes, variaciones de «historias», «pendientes», «en curso y
«finalizadas».

Tu equipo también puede planificar el ciclo sin la ayuda del panel blanco. Muchos equipos ágiles
usan paquetes de software para crear tableros virtuales. La ventaja es que les permite a los
equipos visualizar las tareas aunque no estén en la oficina. Para comenzar, lo mejor es planificar el
ciclo con un tablero físico. Así, el equipo podrá participar en la actividad a través de una
experiencia palpable. Durante la planificación del ciclo, cada desarrollador decide cómo puede
contribuir a la historia. Escribe sus tareas diarias en una nota en el papel amarillo al lado de la
historia. Cada tarea no debe llevarle más de una jornada de trabajo. Si una tarea lleva más de un
día, el tablero no reflejará el progreso real del equipo. El mejor momento de comenzar la
planificación del ciclo es inmediatamente después de una demostración. Al final de cada ciclo,
planificarás las siguientes dos semanas. La planificación empieza cuando el propietario del
producto presenta las historias de usuarios que quiere completar. El dueño del producto es como
el cliente de un restaurante. Pide lo que quiere que se le entregue durante el siguiente ciclo. Como
en un restaurante, el cliente nunca va a ir a enfrentar al cocinero. Con el dueño del producto pasa
igual. Se presenta para responder preguntas, no para exigir la entrega.

Una vez trabajé en una empresa en la que el propietario del producto presionaba al equipo para
agregar historias al ciclo. Les decía: «Veamos qué podemos concretar». Al final, los desarrolladores
complacían al dueño del producto, pero sabían que había pocas posibilidades de completar todas
las historias. Cuando esto ocurrió un par de veces, el equipo de desarrolladores pasó a plantearse
sus propias historias. Al principio parecía un proyecto tradicional: el equipo se programaba las
historias para aprovechar mejor el tiempo. En Agile debe haber transparencia al planificar el
trabajo. Si un propietario de producto presiona al equipo, solo logrará minar la fiabilidad de sus
estimaciones. El propietario del producto presenta las historias de mayor valor y el equipo debe
decidir cómo va a cumplimentar su trabajo. Cuando el dueño del producto acaba su presentación,
el desarrollador debe comenzar a fijar las tareas. Esta no debe ser la primera vez que el equipo ve
las historias. Lo mejor es que hayan podido evaluarlas y hacer estimaciones durante una sesión
previa. La planificación por ciclos se lleva a cabo cuando ya se ha calibrado el valor de las historias.

Convertir una historia de usuario en tareas diarias no siempre es un proceso fácil. Muchas veces,
los desarrolladores no alcanzan a entender qué se quiso decir, el alcance total de la historia. En
esos casos, deberán segmentarla en historias más cortas y hacer una reestimación rápida. Uno de
los mayores peligros es que se den cuenta de que muchas historias no están listas para empezar y
se encuentren bajo una avalancha de historias. Cuando el equipo comienza a dar forma a las
tareas, se da cuenta de que necesita segmentar las historias. Así, esas historias pasan a ser otras. Y
el equipo deberá estimarlas y establecer tareas para cada una de ellas. El plazo de dos horas no les
resultará suficiente. La mejor forma de evitar todo esto es invertir más tiempo en el refinamiento
de la lista de requisitos. Cuando el equipo sea experto en refinar la lista de requisitos, perderá
menos tiempo en debatir las historias durante la planificación del ciclo. Así, invertirán menos
tiempo en decidir qué es una historia y podrán utilizarlo para planificar la entrega.

Mantén el ritmo de la reunión

Para ser totalmente ágil, el equipo debe abandonar gran parte de su idea tradicional de gestión de
proyectos. La gestión tradicional puede ser un gran riesgo. Si una estimación es incorrecta, puede
haber consecuencias peligrosas. Un equipo ágil es diferente. Se debe aceptar algún grado de
incertidumbre y seguir adelante igual. Una de las grandes diferencias es que un equipo ágil no
necesita precisión exacta. Se asume de antemano que un equipo nuevo no sabrá hacer
estimaciones exactas. En la planificación por ciclos es igual. Es probable que el equipo no sepa
establecer bien las tareas. Por ello, en Scrum y programación Extrema se hace mucha referencia al
valor. Hace falta valor para aceptar que uno puede estar equivocado. Y el equipo debe avanzar.
Muchas organizaciones penalizan los errores. Por lo tanto, la transición ágil no será fácil para
muchos desarrolladores. Un buen ScrumMaster se da cuenta a tiempo de si el equipo está
pasando por dificultades. En la gestión tradicional de proyectos, una reunión lenta suele ser el
resultado de una falta de dirección. Lo que suele ralentizar a un equipo ágil es la falta de
compromiso o valor. En cada una de las actividades se podrá discernir si el equipo tiene temor o
está débil.

Presta atención a los desarrolladores que no mencionen obstáculos en las reuniones diarias
porque eso no quiere decir que no haya obstáculos. Por el contrario, a veces significa que han
dejado de trabajar.

Una vez trabajé en un proyecto en el que un desarrollador debía crear un script para trasladar
datos a una nueva base de datos. En cada reunión mencionaba la misma tarea. «Ayer trabajé en el
script». «Hoy trabajaré en el script». «No hay bloqueos». Pasada una semana, el ScrumMaster le
preguntó si estaba seguro de que no había obstáculos. Había observado que la tarea no se había
movido en el tablero. Los desarrolladores dijeron que tenían un problema grave. Habían estado
tratando de encontrar una buena solución. La suposición del desarrollador principal sobre la base
de datos era incorrecta. En vez de comunicar los problemas en la reunión, decidieron arreglarlo
ellos mismos por su cuenta. Hace falta valor para levantarse en una reunión y decir que uno está
atascado. Muchos desarrolladores intentan corregir los errores sin que nadie se dé cuenta. Pero
estas correcciones toman tiempo. En vez de ser transparentes, el resto del equipo ni siquiera sabía
lo que estaba ocurriendo.

La estimación relativa es otra área en la que el equipo debe aceptar la incertidumbre. Muchos
desarrolladores escuchan la palabra «estimación» y piensan: «¿Hasta dónde podría llegar esto?»
Hacer una estimación relativa no es lo mismo que imaginar la peor situación posible. Ni siquiera es
una estimación. Es una suposición. Si el equipo dice que no tiene la suficiente información para dar
una estimación, piensa que puede que tengan miedo. Cuando los desarrolladores dicen eso, en
realidad quieren decir que no saben qué necesitan para acabar lo que estás pidiendo. En esos
casos, recuérdale al equipo que para estimar un resultado hace falta valor. No saber cómo va a
acabar no significa que no se pueda empezar. Las estimaciones relativas son como una ficción.
Marcan el estilo. No transmiten mucha información. Es muy fácil crear una estimación relativa
para casi cualquier cosa, aunque no tengas suficiente información sobre cómo empezar. Por
ejemplo, para hornear un pastel de bodas yo supongo que se debe necesitar unas seis veces más
de tiempo que para hacer galletas. Nunca hice un pastel de bodas. Y solo un par de veces horneé
galletas, pero puedo hacer una estimación bastante exacta. Puedo plantar la bandera y empezar a
hornear. Si todos debaten lo que no saben, el tiempo para la estimación nunca será suficiente.
«¿Es un pastel de chocolate?» «¿Alguien es vegano?» «¿Sabes si el novio no tolera el gluten?»
Todas estas son señales de que el equipo no quiere comprometerse. Si ocurre esto, las sesiones de
estimación serán eternas. Si tú eres el ScrumMaster, presta atención a esas señales de
advertencia. Entrena a tu equipo para que tenga valor. Para avanzar no necesitan tener
información tan precisa. Anima al equipo a ser transparente para erradicar rápidamente estos
problemas.

Presenta el trabajo
La demostración en la revisión del ciclo
Al final de un ciclo, el equipo programa una revisión del producto en la que el equipo muestra
todo lo que ha logrado en las últimas dos semanas. A esto se le suele llamar «revisión del ciclo».
También se le llama «demostración», pero llamar así a esta actividad puede ser una espada de
doble filo. Por un lado, es mucho más probable que todos asistan. Es más tentador ir a una
demostración que a una revisión. Pero por otro lado, no querrás que las partes interesadas
piensen que solo tienen que sentarse y mirar. En las empresas más grandes, durante las
demostraciones se presentan diapositivas para describir el producto. En las demostraciones del
ciclo, el equipo ágil explica al cliente el proceso de trabajo. No es una presentación. Es un
recorrido en tiempo real por el producto. Hay muchos equipos que no están muy cómodos al
demostrarle el software funcional a los interesados. Preferirían desarrollar software en un
laboratorio y mostrar capturas de pantalla en las diapositivas. Es importante que el equipo no ceda
a esta tentación. La actividad consiste en presentar un producto funcional. No se espera que los
interesados simplemente oigan las descripciones. No es un pagaré. Deben poder ver y analizar el
estado actual del producto, ver lo que están comprando.

La demostración del ciclo es una rendición de cuentas. Es el momento en el que las partes
interesadas justifican lo que han invertido. El cliente debería pensar: «Bueno, he gastado tanto
dinero y esto es lo que he conseguido». Quien preside esta reunión es el propietario del producto.
El resto del equipo debe estar sentado en el fondo. Los desarrolladores deben escuchar cómo el
propietario describe el producto. Más tarde, si tienen alguna pregunta, pueden hacerla durante la
planificación del ciclo. La demostración debe hacerse el último día del ciclo. Debe ser la primera de
una serie de actividades que culminan el ciclo. El ciclo acaba después de la demostración. Luego se
hace una actividad reflexiva, como una retrospectiva, y a continuación se planifica el siguiente
ciclo.

Muchos equipos optan por comenzar los ciclos los jueves por la mañana. Así, muchas de las
reuniones se llevan a cabo los miércoles. En las empresas más grandes, es difícil celebrar
reuniones importantes los viernes por la tarde. Se suele estimar que la demostración del ciclo dura
unas dos horas. Muchas organizaciones creen que ese es el tiempo máximo y no el mínimo. Puede
que sea difícil lograr que los interesados asistan a una reunión de dos horas. Si el proyecto tiene
partes interesadas de alto nivel, será mejor que el equipo programe reuniones de una hora. Pero
ten en cuenta que esto es una presión para el propietario del producto. Deberá tener una
comunicación más frecuente con los interesados durante el ciclo. Quien lidera esta actividad es el
propietario del producto. A pesar de que no es explícito en el Scrum, esta es una práctica muy
común. Es la única actividad en la que al equipo de desarrollo queda en segundo plano mientras el
propietario del producto habla. El dueño del producto preside esta actividad por cuatro razones.

- Primero, así sentirá que participa del resultado. El propietario del producto tendrá mucho
interés en el tablero de tareas al final del ciclo porque sabrá que en unos días será él quien
se pare delante de las partes interesadas.
- Segundo, el propietario del producto por lo general tiene una mejor relación con las partes
interesadas. Es más probable que haya una mayor comunicación y se hagan comentarios.
- Tercero, debes asegurarte de que las partes interesadas compartan la misma visión del
propietario del producto. Una vez estuve en una demostración donde el interesado clave
interrumpió al propietario del producto en medio de la presentación diciendo que no le
gustaba cómo iba el producto. Luego explicó su visión de cómo el equipo debía trabajar.
Fue un momento incómodo para el propietario del producto, pero fue muy bueno para el
equipo. Sin esos comentarios, el equipo podría haberse pasado semanas trabajando en un
producto que los interesados no querían. Este tipo de intercambio transparente es la
 razón por la que en Agile se ahorra tiempo y dinero. La cuarta razón es que el equipo de
desarrollo no suele ser muy bueno para liderar la demostración. A menudo, los
desarrolladores describen el producto como una capacidad y no como una solución.
Querrán hablar sobre lo que hace el software y no explicarán el valor del producto.
Además, algunos pueden usar la demostración para buscar reconocimiento. Por desgracia,
la demostración no suele ser satisfactoria. Las partes interesadas deben estar satisfechas
con el producto y no con el equipo.

Escucha comentarios
En el modelo Agile, no hay mucha planificación inicial. El equipo mantiene el proyecto en marcha
con los comentarios en tiempo real. Estos circuitos de retroalimentación son la mejor manera de
responder a los cambios. Y es por ello que en Agile representan un valor real. Son el motor que
impulsa al equipo a producir y mejorar. Las cinco actividades se Scrum están diseñadas para
provocar esta comunicación. Las reuniones diarias, las listas de requisitos del producto, la
demostración y la retrospectiva buscan crear un circuito de comentarios. Si el equipo no crea estos
circuitos de comentarios, te darás cuenta fácilmente. Durante una reunión, la evaluación puede
ser un poco complicada, porque es el momento en el que todos se actualizan. Es una conversación
unidireccional. Los miembros del equipo debaten su trabajo y los obstáculos. No van a resolver
nada. Necesitas que la comunicación ocurra después de esta actividad. Los desarrolladores deben
reaccionar a lo que han oído. Deben esforzarse en coordinar su trabajo. El ScrumMaster debe usar
esos comentarios para saber qué obstáculos necesita eliminar. después de la reunión, el equipo no
debe dispersarse como cuando abres una bolsa de cereales. Deben continuar hablando y
haciéndose comentarios los unos a los otros para cerrar los circuitos de opiniones. También
puedes fomentar estos circuitos con la lista de requisitos. Los dueños del producto deben trabajar
con el equipo para refinar la lista de requisitos, que estará en un cambio continuo. El equipo
siempre tendrá nuevas ideas que agregar. Si el propietario del producto no se reúne con el equipo,
este circuito comunicativo podría romperse. Si la lista de pendientes no avanza, puede que el
equipo no esté trabajando en las historias de mayor valor. Esto suele ocurrir cuando el propietario
del producto no tiene mucho tiempo para desempeñar su rol. Así, acabarás teniendo una lista de
pendientes que casi no cambiará.

Uno de los circuitos de reacción más importantes es la demostración del ciclo. En esta actividad, es
el propietario del producto quien expresa los comentarios. Es cuando comparte su visión con
todos los interesados. Si este circuito comunicativo no funciona, presta atención a lo siguiente. Si
el cliente repite las mismas preguntas una y otra vez, puede que sea necesario que el propietario
del producto les presente un tablero de comentarios y soluciones. Es una pizarra simple de dos
columnas. Durante la demostración, se enumerarán todos los comentarios en la primera columna.
Y en la siguiente demostración, el propietario del producto debe mover las tareas completadas a la
columna de soluciones.
La pizarra no reemplazará la lista de requisitos del producto, pero les dará mayor visibilidad a los
comentarios y propuestas de los interesados. Puede ser un buen punto de partida para que el
dueño del producto pueda hablar de prioridades.

Si después de cada demostración los comentarios no cambian de columna, podría significar que el
propietario del producto no les está haciendo caso. Muchos equipos piensan que la retrospectiva
es la actividad ágil más importante. Se trata de las reuniones en las que el equipo opina sobre el
trabajo de los demás. Es más fácil de decir que de hacer. Cuando el equipo está empezando, no
saben muy bien cómo hacer una retroalimentación fructífera. En los proyectos tradicionales, no
suele haber espacio para que todos den su opinión. A veces hay reuniones al acabar los proyectos,
pero ya es demasiado tarde para que sirvan de algo. El facilitador de la retrospectiva debe
asegurarse de que todos hablen. A menudo, quien habla menos es quien más tiene para decir. Si
no hay mucho diálogo, el facilitador puede hacer preguntas abiertas. Puede usarse a sí mismo
como ejemplo y preguntar: «¿Qué podría haber mejorado en el último ciclo?» Y luego: «¿Qué hice
bien durante el último ciclo?» Si eso funciona, pídele al equipo que se hagan esas mismas
preguntas los unos a los otros. Crear y mantener estos circuitos de comunicación es esencial para
que el proceso ágil sea transparente y adaptable. Recuerda estas señales de advertencia para
mantener la comunicación.

Evita los obstáculos típicos

Protege el cronograma de la reunión
En un equipo ágil, todos cumplen un papel importante y deben saber cuándo les toca participar,
hablar o simplemente escuchar. Para crear un buen circuito comunicativo, es necesario que el
equipo escuche y no esté abrumado con intromisiones externas. Hay una vieja broma sobre Agile.
Empieza con un cerdo y un pollo. El cerdo y el pollo deciden abrir un restaurante. Se sientan en su
restaurante vacío e intentan elaborar el menú. El cerdo le pregunta al pollo: «¿Qué podríamos
servir en el desayuno?» El pollo responde: «¿Servimos tocino y huevos?» Y el cerdo le contesta:
«Si servimos eso, tú serías la parte interesada y yo la comprometida». Recuerda esta broma
cuando analices a tu equipo ágil. ¿Quién está comprometido realmente? En Agile es muy común
oír cuentos de pollos y cerdos. Los pollos no se juegan la piel. Pueden escuchar, sí, pero la
actividad no es para ellos. Casi siempre está destinada a los cerdos, que son los que están
verdaderamente comprometidos con el proyecto.

Durante las reuniones diarias, el dueño del producto debe escuchar. No se espera que hable.
Escucha para asegurarse de que el equipo esté trabajando en las historias de mayor valor. Pero
eso no los convierte en pollos. Durante la demostración del producto pasa lo mismo. El equipo de
desarrollo se juega la piel, pero a pesar de que son los cerdos, en esta reunión les toca escuchar.
En algunas empresas, los gerentes quieren observar las reuniones diarias. Es una buena forma de
ver el progreso del equipo. El ScrumMaster debe comunicarles que no deben participar en estas
reuniones. Pueden ser altos directivos de la empresa, pero en el equipo de Scrum serán meras
gallinas. Dependiendo de la empresa, puede que haya muchos pollos en tus actividades Como
ScrumMaster, te toca asegurarte de que los pollos no acaparen a tu equipo de cerdos, que son los
que están realmente comprometidos. Sus ideas deben ser las más importantes. Muchos de los
pollos serán gerentes sénior, jefes de proyectos y asistentes ejecutivos. A veces es difícil que los
pollos acepten quedarse callados. Pero el ScrumMaster puede dejarlo más claro si se sienta entre
el grupo de pollos y los desarrolladores. Así, estará bloqueando físicamente su acceso al equipo.
Los gerentes que no conocen Agile pueden malinterpretar las reuniones diarias. Suponen que el
equipo simplemente informa el estado del proyecto al ScrumMaster, creen que el ScrumMaster es
el jefe y que el equipo le está contando los avances de sus tareas. Para evitar las interrupciones
innecesarias, pídeles a los pollos que se guarden las preguntas hasta el final de la reunión. Este es
uno de los desafíos del rol de ScrumMaster. A veces tendrás que enfrentarte al poder para
proteger al equipo.

En algunas empresas, el equipo ágil contará con diferentes jefes. Debes ser sutil y delicado para
decirle a un gerente que no debe cuestionar a sus empleados. La clave es centrarse en proteger el
cronograma de la reunión. Si eres el ScrumMaster, deja claro que no quieres decir que los jefes no
puedan hablar con los empleados, sino que les estás pidiendo que se abstengan de hacer
preguntas durante esa breve reunión de 20 minutos.

Los informes de actualización en las reuniones diarias

Poder dirigir reuniones diarias de calidad puede ser problemático. Puede que los jefes quieran
acaparar la actividad. Los pollos pueden considerar que se trata de una reunión de informes de
progreso. Te robarán un tiempo valioso con sus preguntas y comentarios. Si tú eres el
ScrumMaster, debes ser consciente de que te enfrentarás a todos estos obstáculos. Pero el equipo
también tiene sus propios desafíos. Aunque no haya distracciones externas, a los desarrolladores
les resultará difícil adquirir un ritmo diario. Por lo general, hay muchas personalidades diferentes
en un equipo de desarrollo, y algunas características pueden causar problemas. Lo comprobarás
durante las reuniones matutinas diarias. Observarás distintas personalidades. Por ejemplo, los
tardíos y los ganadores del Óscar.

- Yo soy más compasivo con los tardíos. Son los desarrolladores a los que les cuesta
centrarse a primera hora de la mañana. Podrás identificarlos porque siempre tendrán una
taza gigante de café. En un buen equipo ágil hay entre cinco y nueve desarrolladores. cada
uno debe hablar durante unos tres minutos. Son tres preguntas y hay un minuto para cada
una. O sea que recibirán 30 trocitos de información. Es mucha, y especialmente para
 alguien a quien le cuesta levantarse de la cama por la mañana. Los desarrolladores tardíos
se enfrentan al problema de que pueden perder el hilo. Por lo general, suelen perderse
toda la información: retienen solo lo que dicen quienes están a su lado. Durante estas
reuniones, el equipo conforma un círculo. Y a los tardíos les resulta más fácil retener la
información de los que están a sus lados que la de los que están más lejos. Si eres el
ScrumMaster, los identificarás fácilmente porque seguramente no hablen con nadie
después de la reunión. Querrán encender la computadora y ponerse a trabajar hasta
poder despertar del todo. Pero las conversaciones después de la reunión diaria son
importantísimas para el equipo. Si un desarrollador tardío se salta estas reuniones, se
pierde información crucial. Nadie podrá cambiar sus hábitos, ni siquiera el ScrumMaster.
Pero sí puede obligarlos a concentrarse durante esas actividades. Un método infalible para
estas reuniones es usar una pelota Koosh, que es una de esas bolas con muchísimas
cuerdas de goma. Son livianas y se pueden dar vuelta y girar. Usa la pelota para que el
orden de las respuestas sea aleatorio. Lánzala a la persona que quieras que empiece. Cada
desarrollador tendrá la palabra y luego podrá lanzarla a la siguiente persona. Anima a los
desarrolladores a que no le entreguen la pelota a quien tengan a su lado. Puede parecer
trivial, pero es una buena forma de mantener al equipo concentrado durante 20 minutos.
Retendrán más información y la reunión será más emocionante e interactiva.
- La segunda personalidad problemática son los ganadores del Óscar. ¿Has visto alguna vez
la ceremonia de entrega de premios? Una persona se pone de pie al frente y sostiene la
estatuilla. Agradecen a sus amigos y parientes, y luego empieza la música y acaban
acompañándolos hasta su asiento. Hay momentos durante la reunión en los que querrás
tener una orquesta que le indique a la persona que ya debe terminar. Algunos
desarrolladores no saben responder tres preguntas de forma concisa. A veces es porque
hablan muy lento. Otras, porque le agradecen al resto por la ayuda. Sea cual sea el caso,
esa charla adicional consume tiempo del resto del equipo. El ScrumMaster debe mantener
activa la reunión. Al final, debe acercarse a esa persona y recordarle que cada actividad
tiene un plazo. Pero hay veces en que ni eso es efectivo. En esos casos más difíciles,
también usa la pelota Koosh. No es agradable decirle a alguien que termine de una vez.
Parece una grosería. Es mucho más fácil decirle al desarrollador que ya puede lanzar la
pelota. Si se lo recuerdas suficientes veces, se convertirá en un hábito. Si tú eres el
ScrumMaster, tu compromiso es con todo el equipo. Si alguien se toma demasiado
tiempo, eso afectará el trabajo de todos. Identifica estas personalidades comunes. A
menudo, unas correcciones tan simples pueden ahorrarle mucho tiempo al equipo.

Qué hacer cuando se rompe el ciclo

Cuando se rompe el ciclo, el equipo no logra cumplir las tareas a las que se ha comprometido. A
esto suele llamársele «interrupción anormal». Si hay desarrolladores tradicionalistas, es posible
que oigas los términos «final anormal» o «interrupción anormal del ciclo». Algunos equipos lo
llaman «ampliar el ciclo». Tenga el nombre que tenga, el resultado es el mismo. Por alguna razón,
el equipo decide no completar las tareas en el ciclo actual. Lo terminan antes de tiempo y
empiezan otro ciclo al día siguiente. Existen muy pocas razones para romper el ciclo. Puede ocurrir
que las estimaciones sean difíciles de alcanzar o que los desarrolladores deban trabajar en otros
proyectos urgentes. O quizá el equipo encuentre obstáculos que no pueda superar. Las razones
más probables tienen que ver con el propietario del producto y la lista de pendientes. Quizá haya
cambiado el trabajo de mayor valor. Si esto sucede, el propietario del producto no querrá que el
equipo entregue algo que el cliente ya no desea.

Una vez trabajé en un proyecto en el que el propietario del producto había malinterpretado al
cliente. Creyó que lo que pedía era que se volviera a diseñar todo. El propietario del producto
programó una reunión para evaluar el diseño nuevo. Y en medio de la reunión, el cliente aclaró el
malentendido. Dijo que le gustaba el aspecto del producto y solo quería hacer algunos cambios. El
propietario del producto se dio cuenta de que la planificación del ciclo estaba errada. Le había
dado una prioridad alta a la historia del nuevo diseño. El equipo ya había comenzado a trabajar en
él al comienzo del último ciclo. Justo después de la reunión, el propietario del producto les pidió a
los desarrolladores que se reunieran en el espacio compartido de trabajo y le transmitió esta
equivocación al resto del equipo. Quería quitar esas historias del panel y reemplazarlas por otras.
En ese momento, intervino el ScrumMaster. Explicó que la estructura no permitía que se
modificaran las prioridades en medio de un ciclo. Si el propietario del producto quería mover el
poste de la portería, la entrega iba a correr peligro. El equipo estuvo de acuerdo en que quedaba
una sola opción. El propietario del producto no quería hacer trabajar de más al equipo. Borraron el
panel de tareas y anularon el ciclo. Programaron una nueva reunión de planificación para el día
siguiente. Eso también retrasó la fecha final del producto. Los días del ciclo roto significaron
trabajo perdido.

Romper el ciclo influye en gran parte de la previsibilidad del proyecto. El tiempo perdido provoca
una reacción en cadena que retrasa todo el trabajo futuro. En este proyecto, la entrega debía
hacerse tras veinte ciclos: los interesados esperaban ver el producto final en cuarenta semanas.
Cuando el equipo aplazó el ciclo, se perdió tiempo valioso. La solución era replantear los ciclos o
posponer la fecha de entrega. Durante ese ciclo, fue el propietario del producto quien cometió el
error. Al reconocer la brecha, los cambios ocurrieron rápidamente. En otras ocasiones, son los
desarrolladores quienes deciden acabar el ciclo. Y por lo general suelen ser los casos más
peligrosos. En estos casos, el ScrumMaster debe averiguar si siguen trabajando dentro de la
estructura. Hay muy pocas razones por las que los desarrolladores podrían querer terminar el ciclo
antes de tiempo. Si el equipo acaba de empezar, puede que sea porque las estimaciones no son
correctas. Quizá subestimaron algunas de las historias de mayor valor. O puede haber ocurrido
algún imprevisto. Quizá fueron todos a comer al mismo restaurante y se intoxicaron con la comida.

En general, las malas estimaciones y los hechos imprevistos no son buenas razones para acabar el
ciclo. Si esto sucede, el ScrumMaster debe intentar evitar que los desarrolladores rompan el ciclo,
porque significaría hacerle trampa al modelo. Estarían recibiendo tiempo extra por haber hecho
malas estimaciones. El ScrumMaster debe proteger el método y es la única vez que intervendrá en
una decisión. Otras veces, es el propietario del producto quien decide acabar el ciclo antes o no.
Los desarrolladores completan las historias de mayor valor para el propietario del producto. En
última instancia, es él quien decide si hay o no material suficiente para la demostración. Siempre
es suya la última palabra. Si llega a ocurrir que el ScrumMaster y el propietario del producto no
están de acuerdo, la opinión del propietario del producto es la que prevalecerá.

La multitarea
Si empezaras a trabajar a las nueve y tuvieras por delante tres tareas de una hora, ¿cómo
organizarías la mañana? Cuando se le pregunta esto a la gente, la mayoría dice que empezaría una
tarea a las nueve, otra a las diez y terminaría la última antes del mediodía. Se ocuparían de una
tarea por vez, y acabarían una antes de pasar a la siguiente. En realidad, no muchos trabajan así.
La mayoría empieza las tres tareas a las nueve y va avanzando en las tres en simultáneo. Así, creen
que les están dedicando más tiempo. Si algo tarda más, les quedará un hueco antes del mediodía.
A esto se le llama «multitarea». Muchas empresas fomentan esta práctica. Por eso, en los
anuncios de trabajo se suele poner esta capacidad al principio de la lista. Pero la multitarea tiene
un precio muy alto. No se puede trabajar en muchas tareas divididas en partes iguales. Una
persona no es como una pizza. Si tomas dos porciones a la vez, te quedarán seis. Las personas no
funcionamos así. Piensa en tu último proyecto importante. A veces se necesita mucho tiempo para
empezar. En cuanto tienes el impulso, alguien llama a la puerta o te suena el teléfono. Aparece un
correo electrónico con un signo de exclamación. Entonces, dejas lo que estabas haciendo y te
concentras en la tarea nueva. Te tocará volver enfocarte para poder recomenzar lo que estabas
haciendo. A esto se le llama «cambio de contexto». Dejas lo que estabas haciendo y pasas a algo
nuevo. El impacto del cambio de contexto es mucho mayor de lo que se suele creer. Muchos
piensan que pueden terminar dos tareas de 30 minutos en una hora. En 60 minutos, pueden
acabar dos tareas de treinta. Pero si trabajas en dos tareas simultáneas, realmente contarás con
unos 48 minutos. Los otros 12 minutos los pierdes en pasar de una tarea a la otra. Paras, analizas
dónde estás parado y vuelves al trabajo. Cuantas más tareas tengas, tendrás más sobrecarga, que
es el tiempo que inviertes en pasar de una tarea a la otra. Este tiempo aumenta con la carga de
trabajo. En este gráfico, verás que en el total de tiempo correspondiente a tres tareas, se pasa más
tiempo cambiando que trabajando. También observamos que si tienes cinco tareas simultáneas,
es preferible que no hagas nada. Usarás las tres cuartas partes del tiempo para averiguar lo que
estás haciendo. La estructura ágil está diseñada para reducir esta ineficiencia. Todo el equipo debe
centrarse en el menor número de tareas posible. Todas las actividades deben tener un límite de
tiempo. Esto obliga al equipo a acabar una tarea e iniciar otra. Reduce los cambios de contexto.
Todas las actividades deben cumplirse de la misma forma, y cada una tendrá una organización
específica. El ScrumMaster debe asegurar que en cada plazo se cumpla una tarea. Puede que sea
la planificación del siguiente ciclo o una lista de mejoras tras la reunión de retrospectiva. Los
plazos deben tener límites fuertes. Es más fácil planificar dos semanas si se segmentan en plazos
cortos de dos horas. Cuando el equipo participe, debe ser activamente. Todos cumplen la misma
programación. Todos reman hacia el mismo sitio.

Quienes confíen en la multitarea ralentizarán al resto. Una vez trabajé en una empresa en la que
los empleados llevaban los teléfonos a las reuniones. Se oía cómo escribían mientras los demás
hablaban. Respondían un correo, acababan un memo. Como vemos en el gráfico, no vale la pena
celebrar reuniones si el ambiente es ese. No vale la pena tener reuniones de una hora si los
participantes siguen trabajando en otra cosa. Será mucho más eficiente que la reunión dure
quince minutos y todos estén concentrados solamente en eso. Deja que luego vayan a responder
sus correos o a acabar los memos. Para la mayoría de las actividades ágiles hay que estar
desconectado. No lleves el teléfono ni la computadora. Todo el equipo debe centrarse en las
tareas. Luego, los desarrolladores podrán volver al trabajo.

Conclusión
Espero que te haya gustado este curso sobre cómo dirigir reuniones ágiles y productivas. Las
actividades ágiles están diseñadas para crear buenos circuitos de comunicación. Y la mejor forma
es mantener una programación ligera y respetar los plazos. Tenemos mucha bibliografía ágil que
puede ayudarte a profundizar en este tema tan importante. Te recomiendo Human Side of Agile,
de Gil Broza, y el libro que complementa este curso, que se titula Leading Agile Teams. En él se
amplían los conceptos que hemos visto y hallarás información nueva que no cabe en este
curso. Este curso forma parte de la serie Agile en acción. En el siguiente, aprenderás a presentar
información con gráficos y paneles ágiles. Veremos cómo usar gráficos e informes para aumentar
la transparencia y motivar al equipo. Puedes ver todos los cursos por separado, pero si quieres
tener una idea más completa de la metodología, mira la serie completa. 

Mejorar con retrospectivas ágiles

Introducción
Muchos equipos se esfuerzan mucho. Siempre puedes incrementar el esfuerzo, pero obtendrás
mucha más productividad si mejoras tu forma de trabajar. Por eso mismo, al final de cada ciclo, los
equipos ágiles tienen una reunión de retrospectiva. Porque trabajar más duro sin mejorar el
proceso es como tratar de mantener a flote un barco con filtraciones remando más rápido. En este
curso, aprenderás a ayudar a tu equipo a identificar esas fugas y a empezar a arreglarlas. En primer
lugar, daremos forma a tus reuniones de retrospectiva para que sean cómodas y productivas.
También aprenderás a recopilar información con una retrospectiva de estrella de mar o de
pancake. Por último, veremos cómo recopilar estos conocimientos y asignarles acciones para
ayudar al equipo a mejorar continuamente. Este es el curso final de la serie Agile en acción, que
tiene como objetivo ayudarte a que tu equipo aumente el ritmo y la calidad de su trabajo.

Qué son las reuniones de retrospectiva

El objetivo de la retrospectiva
Las retrospectivas han sido parte del método desde el principio, después de redactar el manifiesto
ágil, la alianza enumeró varios principios fundamentales para aclarar los valores ágiles a corto
plazo. Uno de los principios dice que, a intervalos regulares, el equipo debe reflexionar sobre
cómo ser más efectivo y ajustar sus acciones a esa meta. El equipo debe reflexionar, ajustarse y
adaptarse. En realidad, el objetivo es que el equipo autogestione esas mejoras para lograr ser ágil.
Con las mismas ideas, deben dirigir sus esfuerzos hacia adentro para reflexionar y mejorar como
equipo. Por lo general, el equipo se reúne durante dos horas el último día de cada ciclo y
reflexionan sobre qué salió bien y qué se puede mejorar.

Las retrospectivas ágiles son reuniones muy animadas. Norman Kerth utilizó por primera vez este
término en la época en que se fundó el movimiento. Desde entonces, se han escrito muchísimos
libros sobre cómo llevar a cabo una reunión de retrospectiva. Pero aun así, muchas empresas
siguen considerando que son una pérdida de tiempo porque creen que a los desarrolladores los
contratan para que se centren en el producto y no deberían dedicarle tiempo a reflexionar sobre
su trabajo. Y es que creen que el equipo debe trabajar, no perder tiempo en intentar mejorar.
Algunas organizaciones lo dicen explícitamente y otras le dan al equipo un apoyo bastante escaso.
Pueden reflexionar, pero mejor si lo hacen cuando el trabajo ya esté entregado. Tiene el mismo
efecto que si lo prohibieran. El ScrumMaster debe trabajar en estrecha colaboración con el
propietario del producto para que el equipo obtenga este momento de reflexión.Sin una
retrospectiva, el equipo seguirá cometiendo los mismos errores.
No tendrán tiempo para reflexionar, mejorar y adaptarse. Una vez trabajé en una empresa que
tenía problemas para programar la retrospectiva de su equipo. El equipo se pasaba demasiado
tiempo jugando con el nuevo software. Algunos gerentes decían en broma que estaban demasiado
ocupados descargando software como para poder crearlo. Pero en esa crítica había algo de
verdad, y esa era una de las razones por las que el equipo estaba probando el método Agile.
Cuando el ScrumMaster les habló de las retrospectivas, parecía que se repetía la historia. Los
gerentes escucharon el término «reflexión» y pensaron que el equipo pasaría horas investigando
herramientas de software. Como consecuencia, les permitieron que reflexionaran todo lo que
quisieran, pero tras entregar el producto. Sin embargo, el propietario del producto sí que
comprendió el valor de la retrospectiva. Había asistido a la formación y había visto las mejoras en
el equipo. Estaban mejorando, y el propietario del producto sabía que el tiempo era parte del
proceso. El ScrumMaster y el propietario del producto convencieron al gerente para que asistiera
a una retrospectiva. El ScrumMaster convocó la primera retrospectiva para explicar el proceso.
Apenas empezó, todos los desarrolladores comenzaron a hablar del proyecto. El ScrumMaster le
pidió al equipo que enumerara lo que había salido bien en las últimas dos semanas. Hizo una lista
en la pizarra y luego les preguntó qué se podía mejorar. Los desarrolladores de pronto cobraron
vida y se les ocurrieron muchas formas de mejorar. La mayoría tenían que ver con la comunicación
y el proceso, que era anticuado. después de la retrospectiva, el gerente cambió de parecer. Le
gustó la estructura de la reunión. También se dio cuenta de que gracias a la reflexión, el error no
se iba a repetir una y otra vez.

Si eres el ScrumMaster de tu equipo, ten en cuenta lo siguiente. La meta de la retrospectiva es

mejorar. La reunión debe estar bien estructurada y ser productiva. No es una reunión informal. El
equipo debe tomar nota de las ideas de todos. A continuación, deben formular ideas de acción e
incluso utilizar juegos de comunicación. El tiempo que se invierte en la retrospectiva debe
planificarse y estar organizado. Por eso, muchos equipos cuentan con un facilitador externo. Ten
en cuenta que las retrospectivas son uno de los eventos ágiles que más se malinterpretan. Algunos
equipos de desarrollo creen que son sesiones de debate cada dos semanas. Se centran en el
producto. Ese no es el objeto de la retrospectiva, sino mejorar el equipo y reflexionar para que
pueda trabajar mejor.

Las cinco fases de las retrospectivas

Una reunión de retrospectiva no es una reunión informal. Debe estar bien dirigida y muy bien
estructurada. Por eso, muchos equipos cuentan con un facilitador, una persona que trabaja con
ellos pero es externa al equipo. Puede ser un formador de Agile o alguien que se especialice en
retrospectivas. Muchos facilitadores usan el libro Agile Retrospectives: Making Good Teams
Great, en el que se describe una estructura muy simple para organizar las reuniones de
retrospectiva. El libro segmenta la retrospectiva en cinco fases: el inicio, la recopilación de datos,
la reflexión, las decisiones y la fase de cierre.

- La fase de inicio consiste en crear la estructura y un marco de seguridad. Es importante

que el equipo se sienta cómodo. Al mismo tiempo, deben sentir que están haciendo algo
nuevo y diferente. Algunos facilitadores comienzan pidiéndoles a todos que escriban qué
esperan obtener de esta retrospectiva. Cada miembro del equipo escribe una nota. antes
de proseguir, se recogen todas las notas. Y al acabar la reunión, se leen en voz alta. Y el
equipo analiza si se cumplieron sus expectativas.
 - La segunda fase es la recopilación de datos. El facilitador dibuja un gráfico en la pizarra
para establecer el orden del día. Algunos de los gráficos más utilizados son el diagrama de
estrella de mar o de pancake. Pancake es un acrónimo en inglés que representa diferentes
aspectos. En esta fase, la meta es que el equipo brinde información. Cada miembro recibe
una pila de papeles para anotar. Escriben notas y acciones que luego pondrán en el
diagrama de la pizarra. El facilitador puede poner en práctica distintos métodos para
inspirar al equipo y obtener la información. Puede hacerles diferentes preguntas o probar
un método asociación de ideas, como el de los «cinco porqués». Cuando hayan
identificado los problemas, el facilitador les pide que se fijen objetivos SMART. Son
objetivos que deben ser sucintos o específicos, mensurables, alcanzables, realistas y de
tiempo limitado. Uno de los desafíos clave para la recopilación de información es
asegurarse de que todo el equipo esté en sintonía. Cuando ocurre algo, es normal que
cada persona tenga una versión diferente de lo que pasó. cada uno tiene su propia versión
de los hechos. Presta atención a cuando la gente te cuenta lo que vio en las noticias o lo
que ocurrió en un juicio. Todos tienen una perspectiva distinta. El facilitador debe tomar
todos esos recuerdos diferentes y conformar así una comprensión común que permitirá
que el equipo pueda pasar a la siguiente fase.
- La tercera fase consiste en reflexionar y es una de las partes más importantes de la
retrospectiva. El equipo no se reúne para celebrar o quejarse, sino para mejorar como
grupo. Y la mejor manera es a través de un aprendizaje real y concreto. El facilitador debe
señalar los diagramas y preguntarle al equipo si distingue algún tipo de patrón. Debe
motivarlos a que entiendan que el problema es uno solo y compartido. Algunos equipos
creen que si arreglan un par de detalles, ya serán más productivos. Pero por lo general, los
problemas siempre son muchos. Es como tener una máquina con muchas piezas oxidadas
y tener que decidir cuáles son las más fáciles de arreglar. Todo el equipo debe centrarse
en el proceso y no culpar a ningún miembro en particular. Si lo que quieres es arreglar la
máquina, no culpes a las partes que están oxidadas. En vez de eso, concéntrate en por qué
se oxidaron. Haz lo mismo en las retrospectivas ágiles. Concéntrate en el proceso, no en el
individuo.
- Durante la cuarta fase, el equipo debe tomar decisiones. Para ello, lo mejor es establecer
acciones claras. El equipo debe segmentar los problemas y convertirlos en acciones para
luego analizar cómo pueden arreglar el proceso. Cada miembro debe ofrecerse para
aceptar al menos una acción y el facilitador es el encargado de señalar los elementos que
falte abordar. Asegúrate de que el trabajo se reparta de forma equilibrada entre todos los
miembros. Para terminar, el equipo cierra la retrospectiva. Entonces, el facilitador les
pregunta si se cumplieron sus expectativas durante la reunión. Si hubo algún problema, el
facilitador debe tomar nota para aplicar los cambios en la siguiente retrospectiva. Si tú
eres el facilitador, es tu tarea que todos salgan con actitud positiva de una reunión muy
productiva. La forma en que cierres la retrospectiva afectará el comienzo de la siguiente
reunión.

Elige el lugar ideal para la reunión

Las retrospectivas deben estar muy bien organizadas, más que cualquier otra actividad ágil. Hay
muchos detalles importantísimos. Importa quién asiste. Y también quién no participa. Importa
quién se encarga de facilitar la reunión. Y el lugar donde se celebra también tiene mucha
importancia. El facilitador debe asegurarse de que todos se sientan cómodos y se comprometan
con la actividad. A veces, las retrospectivas sacan a la luz mucha emoción. Algunos miembros del
equipo podrían tener una idea muy marcada de qué fue bien y qué debe mejorarse. Es importante
que haya una buena organización y un buen espacio para que todos se sientan cómodos, y así
estarán más abiertos a aceptar nuevas ideas. Por eso es tan importante el sitio en el que se
reúnen. Contar con un buen espacio para las reuniones ayuda a que todos se concentren en la
actividad y estén en sintonía. Imagina por un momento un viaje en avión. Avanzas por ese pasillo
estrecho con la esperanza de poder encontrar un hueco en el compartimiento de arriba del
asiento. Los conductos de ventilación están cerrados y sientes el agobio del encierro. Está lleno de
gente por todas partes. Muchos de ellos están demasiado incómodos. Te miran y luego vuelven a
la pantalla del teléfono. Cuando al fin llegas a tu asiento, imagina que alguien te hace una crítica
con toda la buena intención. Es probable que no te caiga nada bien. Seguro que contestarías de
mal modo: «Sí, ya sé que puedo poner esto bajo el asiento». Ahora te propongo que cambies el
contexto. Estás en casa bebiendo tu té favorito. Alguien se te acerca y te dice: «Vaya, qué bolso
grande. Deberías viajar con equipaje más ligero». Esa persona seguramente reciba una respuesta
muy diferente a la del avión. El contexto es muy importante. Dónde estás, qué estás haciendo y
quién está en ese lugar contigo. Todo eso es importante.

Para poder llevar a cabo una buena retrospectiva, uno de los aspectos más cruciales es que todos
se sientan cómodos. Si la reunión se celebra en un lugar estresante bajo luces parpadeantes, no
creo que los resultados sean del todo satisfactorios. Debe ser un momento para reflexionar y
hallar soluciones; y para eso, el equipo tiene que estar cómodo y dispuesto a escuchar. Cuando
vayas a elegir el sitio para la reunión, ten en cuenta lo siguiente: Primero, asegúrate de que haya
mucho espacio. Los espacios abarrotados provocan ansiedad. Todos deben tener libertad de
movimiento. El equipo debe poder acercarse al centro de la conversación. Además, siempre ten
material colorido y llamativo. Les resultará más fácil participar si trabajan con pizarras, tarjetas de
índices, cinta azul, notas y marcadores de colores. Si alguien tiene una buena idea, debe poder
caminar hasta la pared y esbozarla sin mucho esfuerzo. Los equipos rinden mucho más en espacios
con muchas ventanas y luz solar natural. A algunos equipos les resulta difícil trabajar en lugares sin
ventanas.

Una vez trabajé en una empresa que no contaba con un buen espacio para las retrospectivas.
Tenían salas cerradas que los directores siempre se encargaban de reservar durante meses
enteros. Eran salas pequeñas, sin ventanas, con una capacidad máxima de cinco personas. El
espacio compartido de trabajo también era pequeño y estaba dividido en cubículos. El equipo
intentó hacer una retrospectiva en ese espacio compartido. No tuvieron mucho éxito. Había otros
gráficos e informes por toda la pared. También fue difícil que se dieran cuenta de que era una
actividad especial. Le pedí al ScrumMaster que considerara sitios alternativos. Intentaron reunirse
afuera, pero el ruido de la carretera los distraía muchísimo. También probaron un restaurante
mexicano, pero a la larga la reunión acabó llevando demasiado tiempo. Al final, decidieron
reunirse en una mesa de la cafetería del edificio. No era el espacio perfecto, pero les permitió
tener un momento para pensar de forma creativa. Tras algunas reuniones de retrospectiva,
comenzaron a sentirse más cómodos. Los empleados de la cafetería les ofrecían algo de comer y
de beber. No digo que fuera el sitio ideal, pero era mucho más cómodo que el espacio compartido
de trabajo. después de un tiempo, las retrospectivas empezaron a parecerse a un almuerzo de
trabajo amistoso. Los miembros del equipo colaboraban y se ofrecían soluciones creativas. El
ScrumMaster notó que algunos de los desarrolladores se quedaban con sus computadoras y
trabajaban ahí mismo. Para salir de la rutina, es necesaria esta comodidad. Un buen espacio
aporta seguridad, creatividad y diversidad. Al igual que con los espacios compartidos, es bastante
difícil obtener un espacio así en las empresas tradicionales. Se eres el facilitador, insiste en esto
hasta el cansancio. Es uno de los aspectos más importantes para que la actividad sea productiva.

Identifica los problemas y cómo mejorar el proceso

Muchos equipos trabajan como si estuvieran en un buque de guerra de la antigua Grecia, que iban
por arriba de la línea de flotación y tenían muchísimos remos a cada lado. Los equipos de remeros
seguían un ritmo y los lados se coordinaban de forma instantánea. No había tiempo para
reflexionar sobre el rumbo o mejorar el proceso. El remador se sentaba, tomaba un remo y
empezaba a remar. No había debate ni consenso. En Agile se rompe este patrón con las
retrospectivas al final de los ciclos de dos semanas. La reunión de retrospectiva es el momento
preprogramado en el que el equipo levanta la cabeza y mira a su alrededor para identificar las
debilidades del proyecto. Puedes hacerle preguntas al equipo. ¿De qué forma podemos avanzar
más rápido? ¿Debemos cambiar de rumbo? Al igual que en un buque de guerra, solo unos pocos
conocen el panorama general. La mayor parte de la información se encuentra en la experiencia
colectiva del equipo. Cada miembro es dueño de una porción de la historia. Puede que conozcan
su propia versión y la de quien está a su lado, la de su fila o la de las personas que están enfrente.
La mayoría de los equipos trabajan así. No es necesario saberlo todo para poder contribuir al
resultado. La desventaja de este proceso es que muchas veces se corre el riesgo de concentrarse
solo en las tareas propias. Si el equipo se gestiona como un proyecto tradicional, puede que salga
bien. Pero los equipos ágiles se organizan a sí mismos. Hacen el trabajo y también fijan el rumbo.
Son ellos los responsables de mejorar su propio proceso. Para ello, necesitan tener un tiempo de
reflexión.

Norm Kerth dice que las retrospectivas son reuniones rituales para aprender de las experiencias de
los demás y contar una historia colectiva. El equipo recoge experiencias para alcanzar la sabiduría.
El autor pone mucho énfasis en la acción positiva, que significa mejorar los procesos y no señalar
con el dedo. Al final de muchos proyectos se hace un examen post mortem. Pero esto es un
problema, porque solo se aprende cuando el proyecto ya está acabado. No hay posibilidades de
mejorar el proyecto actual. Las retrospectivas ágiles se celebran a mitad del camino, cuando
todavía se sigue remando. Las autoras Esther Derby y Diane Larsen las llaman «retrospectivas
rítmicas». Puede que te quiten tiempo de producción, pero aumentan la eficiencia del equipo.
Estas retrospectivas son como versiones en miniatura de lo propuesto por Kerth. En lugar de
reunirse al final del proyecto, se celebran retrospectivas cortas al final de cada ciclo. Se respetan
las formas y el formato, pero son más frecuentes. Kerth aconseja que la organización de tareas sea
siempre igual. El equipo debe preguntarse qué se hizo bien, qué salió menos bien y qué aspectos
quedan por descifrar.

Es muy importante comenzar la actividad preguntando qué salió bien. Así, el comienzo será
positivo. Se celebran los éxitos del equipo y también se reconoce qué se debe mejorar. Reserva un
tiempo al principio para celebrar los logros. Es posible que necesites esa energía positiva para más
adelante.
Por lo general, la segunda pregunta, referida a lo que no salió tan bien, les llevará el resto de la
reunión. Es el momento de extraer la historia del ciclo para averiguar qué ocurrió. Todos intentan
identificar los problemas. Y cuando ya están expuestos, deben buscar patrones comunes. Así,
lograrán tener una mejor idea de la causa de esos problemas. Solo entonces podrán comenzar a
proponer las mejoras. La tercera pregunta, qué les queda por descifrar, es una pequeña trampa
para recuperar los temas que no se hayan resuelto. Muchas empresas inician proyectos cuando el
equipo de desarrollo aún no sabe de qué se tratan. Se toman decisiones aunque falte gente en las
reuniones o no reciban los informes. A ellos les tocará tomar un remo y ponerse en marcha. Es lo
que hace el resto, pero no saben ni por qué lo hacen. Por eso es muy importante que en las
retrospectivas se hable de los temas que quedan sin comprender.

Una vez trabajé en una empresa en la que el equipo de desarrolladores se esforzó muchísimo por
actualizar la base de datos. Se decidió que era muy importante integrar el directorio activo ya
existente. En una retrospectiva, un miembro del equipo señaló que la base de datos no necesitaba
incluir el directorio activo. El desarrollador quedó perplejo por el gran trabajo del equipo. Si no
hubiese sido por la retrospectiva, todo el mundo habría seguido remando.

Como trabajar con un equipo distribuido en varios lugares

Ni las empresas más ágiles pueden resistirse al encanto de los equipos distribuidos. Los mercados
laborales extranjeros son más baratos y una forma fácil de reducir costos. A muchas
organizaciones les atrae la opción de contratar a expertos locales. Es muy probable que tu equipo
ágil cuente con al menos un desarrollador en el extranjero. A menudo, se encuentran bastante
aislados y obstaculizan el trabajo en equipo. La retrospectiva también sirve para señalar esos
problemas. El equipo debe adaptar el proceso para que todos puedan comunicarse. Si tu equipo
ágil tiene un miembro en otra zona horaria, esto puede representar un gran problema. Uno de los
mayores problemas es la falta de comunicación cara a cara. Aunque contemos con herramientas
modernas, nos seguirá faltando algo. Los seres humanos recibimos mucha información a través de
las señales no verbales.

La coordinación también puede ser un problema. La reunión debe celebrarse en el mismo lugar y
al mismo tiempo. Esto es primordial para que haya un buen debate. Si el facilitador te lee un
correo horas después de la reunión, no estás participando activamente. Como muchos equipos
tienen este problema, te propongo algunas soluciones muy conocidas para ayudarte a mejorar el
tuyo. Si eres el facilitador, tu primera tarea será señalar que tener un equipo distribuido es un
problema. No es un juicio de valor; es una apreciación muy necesaria para que el equipo comience
a debatir los problemas. Intenta hablar también de la confianza. A muchos equipos les cuesta
confiar en los desarrolladores que trabajan de forma remota. A veces son solo una voz que se oye
a través del altavoz del teléfono. Es muy difícil tener una conversación sincera con alguien a quien
no has visto nunca.

En una empresa en la que trabajé, una vez el facilitador celebró una retrospectiva con un equipo
dividido en tres ubicaciones. No fue nada fácil. Le costó muchísimo que la gente lograra
comunicarse. Trabajó con el equipo para mejorar el proceso. Convirtió los problemas en acciones
para ayudar al equipo a realizar cambios. Algunos cambios parecían bastante útiles. Uno era que
pudieran trabajar todos juntos al menos una vez. Si parte del equipo trabaja en otro continente,
puede ser muy poco probable, pero si los desarrolladores se encuentran a menos distancia, insiste
en reunirlos a todos. Así, podrán tener al menos una imagen mental de quién es quién y cómo es
el resto del equipo. Les ayudará a asociar las voces con las caras, a saber que no son simplemente
un nombre en un papel. Si no es posible, intenta que las reuniones se lleven a cabo a través de
videoconferencias. Si solo se tiene acceso al audio, se está fuera de la conversación. También es
difícil conectar con una voz que sale de un aparato. En muchas retrospectivas, eso suele distraer
más que ayudar. De vez en cuando se oye una voz a través del aparato, como en Los ángeles de
Charlie. Si eres el facilitador y tienes participantes conectados solo por audio, detén la reunión de
vez en cuando para preguntarles su opinión. Ármate de paciencia cuando quiten el altavoz para
pensar. Algunos equipos lo resuelven poniendo fotos sobre el altavoz. Les recuerda que esa
persona está en línea y la humaniza un poco. Esto ayuda a que el equipo la considere un igual. Si
no tienes una foto, también puedes poner un objeto. Algunos equipos usan animales de peluche, o
hasta una pelota Koosh, para recordarle al equipo que hay otro participante del otro lado. Si no te
funciona ninguno de estos consejos, puede que te sirva dividir el equipo en dos reuniones. Deben
celebrarse sin mucho tiempo de diferencia. Puedes hacer una en persona y otra con los
participantes remotos. El último equipo debe ver un breve videorresumen de las acciones reunidas
en la otra retrospectiva. Y también deben grabar su reunión para el otro equipo. No tienes que
grabar la retrospectiva completa, haz un breve video sobre las decisiones que se tomaron. Trata
de evitar enviarles correos con resúmenes de las reuniones: es difícil entender las conversaciones
cuando no nos dan ningún contexto. Estos son pequeños arreglos para mejorar una situación
difícil. Una reunión con un equipo distribuido y una retrospectiva son muy diferentes. Que no te
gane la frustración: para obtener resultados concretos de una retrospectiva distribuida hacen falta
muchos ajustes.

El papel del facilitador

A veces se hace un mal uso de las retrospectivas. Algunos equipos simplemente se reúnen para
desahogar sus frustraciones. Otros creen que es una forma más de pasar un rato juntos. Se
centran en sus logros y mencionan un par de detalles que podrían mejorarse. después de un
tiempo, el equipo empieza a perder de vista el propósito original. Por eso, algunas empresas
contratan facilitadores independientes para ejecutar las retrospectivas y ayudarle al equipo a
aprovechar el tiempo al máximo. Suelen ser consultores independientes. Las empresas más
grandes pueden permitirse contratar a un facilitador que trabaje con varios equipos. Contar con
alguien imparcial es una gran ventaja. Pero así y todo, hay muchas organizaciones que no están
dispuestas a invertir tiempo ni dinero en hallar un facilitador independiente. Muchas veces, un
miembro del equipo debe actuar como facilitador de la retrospectiva. Y esto ocasiona nuevos
desafíos y problemas. Muchos equipos le piden al ScrumMaster que ocupe este rol. Y al principio
puede parecer una buena idea. Son el líder del equipo, conocen el modelo ágil y pareciera que el
rol fuera hecho a su medida. Pero el papel del ScrumMaster es muy diferente del de facilitador.

El objetivo de una retrospectiva es la reflexión. El equipo debe analizar el último ciclo y detectar
errores a modificar o mejorar. El rol del ScrumMaster es eliminar los obstáculos. Deben actuar,
arreglar los problemas. Nadie quiere que la persona encargada de arreglar los problemas sea la
misma que debe identificarlos, porque habrá un gran conflicto de intereses: ella misma deberá
arreglar muchos de los problemas que encuentre. Y puede que no se dé cuenta, pero se verá
inclinada a minimizar u omitir aquello que signifique mucho trabajo.
Una vez trabajé en un equipo con un ScrumMaster que también era el facilitador de la
retrospectiva. Sabía mucho sobre el modelo ágil y cómo preparar y elegir el lugar para la reunión.
Al principio de la retrospectiva, se identificaron los problemas del ciclo anterior. Uno de ellos era
que el equipo no podía encontrar el hardware que necesitaban para probar el software. Quien
estaba a cargo de ese obstáculo era el ScrumMaster. Le respondió al equipo que ya se había hecho
el pedido, y el equipo preguntó cuándo iba a llegar, «En algún momento de la semana que viene».
Si no hubiese sido parte de la retrospectiva, esa respuesta estaría muy bien. Pero recuerda que la
retrospectiva es para identificar los problemas y las formas de mejorarlos. Sin quererlo, el
ScrumMaster estaba impidiendo el proceso. El equipo dijo que no tenía el hardware, que no sabía
cuándo iba a llegar. Y el ScrumMaster estaba eliminando el obstáculo. No hizo ningún intento de
mejorar el proceso. Si el equipo pidiera el hardware durante el siguiente ciclo, seguramente se
encontraría con el mismo problema. El facilitador debe motivar al equipo para que analice cómo
mejorar el proceso. Debió preguntarles: «¿Cómo comunicaron que necesitaban hardware nuevo?»
O «¿A través de qué proceso pidieron el hardware?» Cuando el equipo respondiera esas
preguntas, les tocaría analizar qué acciones serían necesarias para mejorar el proceso. Pero eso no
fue lo que les preguntó el ScrumMaster. La retrospectiva no sirve para eliminar obstáculos sino
para arreglar el proceso. Cuando se lleva a cabo la retrospectiva, ya suele ser tarde para lidiar con
el obstáculo. La función del facilitador es averiguar cómo evitar que un mismo problema se siga
repitiendo.

Otra posibilidad es que uno de los desarrolladores tome las riendas y se haga cargo de facilitar las
retrospectivas. Y este caso también genera algunos problemas. A menudo, el desarrollador puede
llegar a preferir tratar ciertos temas por sobre otros. También será un líder muy parcial. Una vez,
presencié una retrospectiva en la que el facilitador era desarrollador. Cuando el equipo
presentaba los problemas, indicaba abiertamente qué temas prefería debatir. Si el equipo traía
ideas sobre nuevas herramientas y tecnología, el desarrollador se alegraba y alababa la
sugerencia. Si el equipo traía ideas para mejorar el proceso, su reacción era diferente. Decía cosas
como: «Pues no sé», o «¿Alguien tiene alguna idea interesante?» Esas formas diferentes de recibir
las sugerencias pueden cambiar toda la reunión. En vez de analizar cómo mejorar el proceso, se
convirtieron en presentaciones de ideas sobre nuevas herramientas y tecnología. Sin darse cuenta,
el desarrollador había cambiado el rumbo de todo el equipo. Si te piden que seas el facilitador de
las retrospectivas, sé consciente de tus parcialidades. Si no lo eres, es muy probable que lleves a
todo el equipo a cumplir tus propios objetivos. La clave es intentar luchar contra tus propios
instintos. Asegúrate de que el equipo haga algo más que seguir tus ideas. Ten en cuenta que
puedes ser facilitador o colaborador, pero no las dos cosas al mismo tiempo.

Utiliza la Prime Directiva como guía

Como en muchas otras actividades ágiles, para que una retrospectiva tenga éxito el equipo debe
organizarse a sí mismo y responsabilizarse de las mejoras a realizar. Norm Kerth creó una breve
actividad de retrospectiva llamada Prime Directive que es muy útil y debe tomarse muy en serio.
Para los fanáticos de Star Trek, les aclaro que no tiene nada que ver. El equipo no debe descartarla
ante la primera amenaza de problemas. Esta directiva es como una promesa. Es un acuerdo
compartido sobre la forma en la que todos trabajarán juntos. Algunos facilitadores proponen leer
la directiva al principio de cada retro, aunque parezca algo extraño. Es como si el equipo estuviera
prometiendo a la bandera. Si consigues que el equipo lo haga, hay estudios que demuestran que
esto ayuda a la buena predisposición. La Prime Directive reza así: «Independientemente de lo que
descubramos, entendemos y creemos sinceramente que todo el mundo hizo el mejor trabajo
posible con lo que se sabía en ese momento, sus capacidades y habilidades, los recursos
disponibles y la situación del momento». Esta declaración extensa tiene un propósito. Podrás
notar que es muy poderosa. Hace al equipo directamente responsable de la retrospectiva y sus
resultados. Y esto se aprecia por las palabras que se eligieron: «Independientemente de lo que se
descubra, creamos o entendamos». No hay ningún gerente en esa ecuación. No se trata de algo
que se planteó en la última reunión. Se busca que el equipo sea transparente, explore, aprenda y
se adapte. También representa una forma activa de separar a las personas del proceso. Dos de las
frases más peligrosas que se oyen en las empresas son: «No es personal» o «Esto es solo un
negocio». La mayoría se toma su trabajo muy personalmente. Y así debería ser. Mucha gente se
esfuerza muchísimo. Por eso es muy importante que la empresa tenga una cultura. Los empleados
siempre quieren ser parte de un todo que sea personal y gratificante. Y se necesita un poco de
esfuerzo para que el equipo piense de forma creativa y no se ponga a la defensiva. En la
retrospectiva no se buscan culpables: el equipo debe analizar el proceso. Deben debatir y
proponer opciones de mejora. Durante las retrospectivas, se suele decir que no hay que culpar a
nadie. Muchos temen que mantener las condiciones de trabajo en armonía sea difícil. Todo el
equipo puede aceptar que hay problemas, pero no muchos querrán cambiar. Los cambios
reorganizan las cosas. Aparecerán muchos problemas nuevos. Seguramente se esfuercen por
proteger el proceso aunque sepan que no funciona. Sobre todo, lo harán por miedo. Miedo a que
lo nuevo siempre puede ser peor. Para cambiar hace falta valor. Y ese valor solo aparecerá si el
equipo se siente cómodo. Cuando puedan prever el cambio y lo acepten, podrán empezar a
pensar ideas creativas. Si pierden tiempo en acecharse y acusarse, el proceso comenzará a
cerrarse. Los equipos que no tienen este nivel de seguridad son los que más se benefician con las
buenas retrospectivas. Y en especial con la Prime Directive. La mayor parte de los miembros de un
equipo tiene un interés genuino en hacer lo correcto. Y cuando todos aceptan la Prime Directive,
es mucho más fácil empezar a forjar esa confianza compartida. Puede que muchos equipos
obtengan lo que necesitan y la dejen a un lado cuando alcancen cierto nivel de seguridad y
confianza. Si tu equipo llega a ese nivel, pueden olvidar algunos aspectos fundamentales de esta
directiva, como el hecho de suponer que todo el mundo se esfuerza lo más posible.

Al comienzo del proceso, lo mejor es confiar en que todos dan lo mejor de sí aunque no sea tan
así. A medida que el equipo avanza, se pueden explorar algunos aspectos que sobrepasan los
límites marcados por la directiva. Puedes empezar a explorar con los desarrolladores que trabajan
desde casa. Se necesita mucha disciplina para trabajar desde casa y mantener un alto nivel de
productividad. Si el equipo está avanzado, puede que te digan que quienes trabajan desde casa no
son tan productivos. Si tú eres el facilitador, recuerda siempre las fortalezas y las limitaciones de la
Prime Directive. Puede ser una gran herramienta para los equipos que están empezando. Cuando
el equipo se sienta seguro, puedes volver a analizarla y decidir si todavía les resulta útil. Quizá
descubras que evita que el equipo se tome la crítica como algo personal. A medida que se vuelven
más transparentes y abiertos, esa podría ser una limitación algo exagerada.
Dirige la reunión de retrospectiva
Anima el debate en grupo
De vez en cuando, sucederá algo que capte la atención de todos. Puede que sea una decisión legal,
una elección o algún desastre natural. Y habrá expertos hablando por la televisión. Se escribirán
artículos y tus compañeros de trabajo contarán su versión de la historia. Cuando esto ocurra, fíjate
en que pareciera que nadie puede contar la historia completa. cada uno puede describir solo una
parte de la situación y tiene su propia perspectiva de los hechos. Deberán pasar meses o años para
que puedas leer libros o artículos que logren contar la historia completa. La gente solo comprende
los hechos cuando ya forman parte de la historia. En las retrospectivas, esto es la reflexión del
equipo. Es el momento en el que cada uno aporta su pequeña parte de la historia para lograr
cubrir la historia completa del último ciclo. La reflexión es muy importante para mejorar. Hace que
el equipo deje de preocuparse por los problemas cotidianos para crear una estrategia a largo
plazo. En Agile, esta reflexión se hace al final de cada ciclo. Y eso significa que no hay que esperar a
terminar el proyecto para ver las mejoras. Ya hemos visto la importancia de tener un buen espacio
de trabajo colaborativo. De esa manera, todos saben lo que están haciendo y que es algo
diferente.

Ahora ya podemos reunir a la gente para tener un debate serio. Para empezar, recuerda que las
personas nos comunicamos de maneras diferentes. Muchos de los que parecen más seguros son
en realidad los que están más despistados. Hace falta mucha habilidad para identificar las propias
debilidades. Esta brecha entre confianza y precisión se conoce como el «efecto Dunning-Kruger»,
que se basa en un estudio de la universidad de Cornell. El estudio demostró que los estudiantes
que creían tener las mejores habilidades lógicas eran a menudo los que obtenían el puntaje más
bajo en las pruebas y sugiere que las personas que más dudas tienen de sí mismas son a menudo
las que mejor comprenden. Es un poco como esa vieja cita de Shakespeare: «El sabio se reconoce
como tonto». Si eres el facilitador del equipo, asegúrate de que las personas más calladas también
puedan hablar. Estas voces más silenciosas a menudo serán la mejor fuente de ideas. Una buena
manera de empezar es hacer que todos identifiquen un proceso que les gustaría mejorar y lo
escriban en una nota. Pídeles que escriban todas las mejoras que se les ocurran. Evita que hablen
entre ellos para que cada uno aporte su propia idea. Si dejas que hablen durante este tiempo, es
más probable que se pongan de acuerdo en algunos problemas. Los que hablen más fuerte
ahogarán las voces de los más callados. Recoge las notas que escribió cada uno y pégalas en orden
en la pared. Pídeles que lean cada nota en voz alta. La primera persona dice, por ejemplo: «En esta
nota dice que deberíamos coordinarnos mejor con operaciones. ¿Todos entienden el problema?»
El facilitador debe darles a todos la oportunidad de entender qué quiso decir el autor de la nota.
Puedes preguntarle a la persona directamente o presentarle las preguntas a todo el grupo. Deja
que el equipo aclare las preguntas abiertas. Cuando el equipo haya identificado algo que quieren
cambiar, motívalos para que piensen en los pasos a dar para mejorar. El facilitador debe animarlos
a debatir sobre alguna acción que pueda ayudar a resolver o a mejorar el proceso. En esa nota, la
idea era averiguar cómo coordinarse mejor con operaciones. En este punto, el debate puede
tornarse difícil. ¿El equipo debe reunirse más? Sería complicado, porque la mayoría de los equipos
ágiles trabajan con plazos muy ajustados. Si deciden tener una reunión extra, deberán repasar los
temas a tratar en ella. Lo importante es que la solución sea posible y se propongan mejoras para el
siguiente ciclo. ¿Quién asistirá a esa reunión? ¿Con qué frecuencia se celebrará? ¿Cuánto tiempo
durará? Necesitan responder a estas preguntas para poder mejorar.
Cómo utilizar el diagrama de estrella de mar
El diagrama de estrella de mar es una herramienta muy útil en las retrospectivas. Se trata de un
gráfico para explicarle al equipo cómo mejorar. La estrella de mar tiene cinco secciones iguales y
cada una de ellas representa una categoría: continuar, reducir, aumentar, eliminar e implementar.

Las líneas divisorias parecen una estrella de mar. Para usar este diagrama, cada persona debe
identificar un elemento para señalar. A un miembro del equipo le puede gustar la forma en la que
se celebran las reuniones diarias. En la retrospectiva, escribirá en su nota: «Celebrar reuniones
diarias productivas» y pondrá esa actividad en la sección bajo el título de «continuar». La estrella
de mar tiene como ventaja que todos los miembros pueden identificar muchas actividades diarias.
A continuación, el equipo clasifica los eventos en función de lo que creen que les resulta bien o no.
Y un diagrama que muestre toda esa información al mismo tiempo es muy útil para que el equipo
decida lo que necesita para mejorar.

Algunos equipos prefieren colgar el diagrama en el espacio compartido de trabajo. Otros solo lo
utilizan durante la retrospectiva. Van quitando los elementos del tablero y crean las acciones para
el siguiente gráfico. La estrella de mar puede usarse de muchas maneras dependiendo de si el
equipo lo ve todos los días o no. Si dejas el diagrama en la pared, puede que algunos miembros del
equipo lo usen más que otros. Es normal que la gente se interese por mejorar el proceso en
diferentes momentos. Si a algunos desarrolladores les molesta algo, puede que ese problema
ocupe mucho espacio en el tablero. Habrá varios problemas similares que surjan de ciertas
actividades.

Otros equipos aplican la estrella de mar solo para la retrospectiva. Consideran que el debate debe
mantenerse durante el plazo de la retrospectiva. Si quieres que todos participen, trabaja con la
estrella solo durante las retrospectivas. Si limitas el tiempo, tendrás más control sobre cuántas son
las personas que efectivamente contribuyen. Puedes aplicar una regla fácil: cada persona puede
aportar solo una nota. Así, te asegurarás de que todos participen. Cada persona recibirá una sola
nota durante la retrospectiva. Y como todos la tendrán en la mano, será más fácil distinguir quién
no la agrega al diagrama. Las categorías de este diagrama tienen más matices que los gráficos
típicos de «más y menos» que se utilizan en la gestión de proyectos tradicionales. El diagrama de
estrella de mar es mucho más abierto.

- La categoría «continuar» es muy útil para mantener un espíritu positivo, y debes intentar
que sea lo primero que se complete. Ayúdale al equipo a identificar todas las cosas buenas
 que ocurrieron durante el ciclo. Por ejemplo, pregúntale al equipo qué cosas echarían de
menos si desaparecieran. Puede ser una persona, una actividad o una tecnología.

Las siguientes dos categorías están muy vinculadas entre sí. Una lleva el título de «reducir» y la
otra, «aumentar».

- La categoría «reducir» suele incluir las actividades que se refinaron o fueron poco útiles
durante el último ciclo. Pregúntale al equipo qué se debería mejorar del último ciclo.
- La categoría «aumentar» abarcará las actividades que aún no se hayan explorado o que no
se estén utilizando bien. Pregúntales qué les gustaría hacer más durante el ciclo siguiente.
Asegúrate de que estos elementos estén bien separados de la categoría «reducir». No
incluyas notas que digan, por ejemplo, «debemos invertir más tiempo en el desarrollo».
Eso es todo lo contrario a lo que se está pidiendo. Puede que el equipo quiera menos
reuniones o menos planificación.
- Una de las categorías más claras es la de «eliminar», que incluye las actividades que no
agregan mucho valor. A algunos equipos esta categoría les resulta problemática porque es
demasiado concreta. Prefieren agregar todo a la sección de «reducir», que es más flexible.
Como facilitador, debes lograr que el equipo se comprometa y explicite qué cosas quiere
dejar de hacer. Si el equipo tiene una discusión muy negativa sobre cierta actividad,
pregúntales si no sería mejor eliminarla.
- La última categoría lleva por título «implementar» y puede completarse mediante una de
lluvia de ideas. Abarca las ideas nuevas para solucionar problemas recurrentes. Puede que
el equipo quiera pasarse toda la reunión debatiendo esta categoría. Los desarrolladores
siempre tienen un montón de ideas para resolver los problemas. En este caso, el
facilitador debe intervenir para asegurar que esas ideas se traduzcan en acciones
concretas.

Como dirigir una retrospectiva PANCAKE

El diagrama de estrella de mar es ideal para las retrospectivas abiertas. Es un gráfico simple y a
muchos equipos les resulta muy útil. Es muy amplio, pero a su vez bastante libre. No limita la
organización del equipo, pero igual hay momentos en los que necesitarás un poco más de
orientación. En especial, con los equipos más nuevos. Para ellos, quizá sea más útil la retrospectiva
de PANCAKE, en inglés. Utilizamos esta palabra, pero no tiene nada que ver con los panqueques.
Es simplemente un acrónimo que nos servirá para recordar la programación de la reunión.

PANCAKE es el conjunto de varias categorías de retrospectivas. Y significa puzle, apreciación,

novedades, contratiempos, aspiraciones, conocimiento y estar de acuerdo.
Como facilitador, puedes elegir poner la lista en el tablero a la vista de todos. Dibuja una gráfica
con una línea que recorra el centro. de un lado, pon las partes de PANCAKE en horizontal. Del otro,
irán las notas que escriba tu equipo.

Este diagrama es una muy buena forma de iniciar el debate. Le proporciona al equipo una
dirección más clara. Recuerda siempre que tu objetivo es recopilar elementos de acción, igual que
con el diagrama de estrella de mar. Cada elemento que nombre el equipo debe tener al menos un
elemento de acción. Utiliza este diagrama para inspirar al equipo, no para controlar la
organización.

- La P viene de Puzle o Perturbar; es decir, sorprender. Enumera qué cosas sorprenden al

equipo. Pídeles que nombren los elementos que son fuente de confusión. Te sorprenderá
lo que puede avanzar el equipo aunque queden cosas poco claras. Como siempre, intenta
que todos se sientan seguros. Es probable que te encuentres con notas que digan: «¿Por
qué estamos haciendo las cosas de esta manera?» o «Nunca había visto esto antes».
- En PANCAKE, la A significa Apreciación, reconocimiento. Intenta que el equipo invierta
parte del tiempo en dar gracias y reconocer el buen trabajo de los demás. Así lograrás dos
objetivos. Primero, que la reunión sea más agradable. Es duro pasarse dos horas hablando
de todo lo que salió mal. Segundo, el reconocimiento suele ser la otra cara de un gran
problema. Puede que alguien diga: «Realmente aprecio que la empresa se comprometa a
poner en práctica el Scrum ¿Es posible que la empresa ofrezca más formación?»
- N significa Novedades. Suele ser la información sobre la empresa. Y pueden ser rumores o
hasta chismes. Intenta que solo se hable de las noticias importantes. Por ejemplo, alguien
puede decir: «He oído que estamos combinando los equipos del extranjero. ¿Alguien más
 se enteró?» Es muy útil que todos compartan esta información para poder planificar el
proceso. Si se combinan los equipos de fuera, la planificación del proceso podría verse
afectada.
- La C viene de Contratiempos o Complicaciones, que son casi siempre un reflejo de otros
elementos del orden del día. Pueden surgir preguntas como «¿Por qué nos reorganizamos
tanto?» En esos casos, asegúrate de que los contratiempos no se queden a vivir en la
pizarra. Cada complicación debe conectarse a un elemento de acción o volverá a aparecer
al final de cada ciclo.
- La A de PANCAKE significa Aspiraciones. Son las esperanzas y deseos del equipo. Pueden
ser simples y corrientes, como la forma de conseguir nuevos servidores. O pueden ser más
ambiciosos, como la oportunidad de conocer al equipo en el extranjero. Que no sean
deseos vacíos: deben vincularse siempre a una acción. En este caso, una acción sería crear
un presupuesto para una reunión del equipo completo.
- K viene del inglés Knowledge y significa Conocimiento. Se trata simplemente de una
conclusión de todo el debate. El equipo comienza a tener un conocimiento compartido
que proviene de las otras áreas. Esos conocimientos derivan de las novedades, los
contratiempos y las cosas que aún les sorprenden. Recuerda que en la retrospectiva cada
uno debe aportar su parte de la historia. Cuando todos la compartan, podrán crear nuevo
conocimiento. Si tú eres el facilitador del equipo, puede que quieras intervenir en esta
parte para preguntarles si entendieron y que te cuenten qué información nueva
recibieron.
- E es Estar de acuerdo o Escuchar, y es una de las actividades más difíciles. Se trata de
conseguir que el equipo coincida y priorice todos los nuevos elementos de acción. Deben
estar de acuerdo todos en cómo tratar los problemas que acaban de surgir. Digamos que
el equipo quiere celebrar una reunión general. Deberás asegurarte de que todos estén de
acuerdo en que esto aportará una gran mejora.

Este diagrama de PANCAKE es una gran manera de dirigir al equipo sin controlar la conversación.
No es necesario que le dediquen el mismo tiempo a cada área. Deja que analicen cuáles son los
elementos más importantes. Cuando tengan más experiencia, puede que quieran probar un
formato más amplio, como el de estrella de mar. O también puede que quieran crear su propio
formato.

Establece metas siguiendo los criterios SMART

Muchos equipos cometen el error de pensar que una retrospectiva es una reunión informal. Creen
que es un buen momento para darles forma a las nuevas ideas. Es casi como una versión
programada de una fiesta de cumpleaños en el trabajo. Vas por ahí con tu vaso y tu trozo de pastel
y conversas con unos y con otros. Pero la programación de una retrospectiva debe ser concreta. Es
verdad que el equipo debe estar cómodo, pero se necesita tener una organización estricta.

En las retrospectivas ágiles, se identifican problemas y oportunidades. El equipo trabaja en

conjunto para crear acciones que mejoren el proceso. Cuando se identifican y se establecen,
deben empezar a fijar metas para implantar las mejoras. No deben pensar en abstracto, sino
centrarse en los elementos que provocarán cambios mensurables. Si provienes de la gestión de
proyectos, puede que hayas oído hablar de los criterios SMART. Se trata de una lista de
verificación que se le atribuye al experto en gestión Peter Drucker. Estos criterios le ayudan al
equipo a identificar metas claras. Durante la retrospectiva, les ayudará a crear los puntos de
acción. Al final de cada retrospectiva, cada miembro debe contribuir con al menos una acción. Y
cada acción deberá pasar por la lista de verificación. Esta lista abarca cinco preguntas.

- ¿La acción es sucinta, específica?

- ¿Es mensurable? ¿Es alcanzable?
- ¿Es relevante para el proyecto?
- Y por último, ¿el tiempo que lleve podrá abarcarse en un ciclo?

Si responden que sí a todas las preguntas, es probable que esa acción conduzca a algún resultado.
A menudo, a los equipos les cuesta detallar una acción. Puede que sea porque hay problemas de
comunicación. Si eso ocurre, podrían agregar un elemento que diga: «mejorar la comunicación del
equipo». Y eso está muy bien como tema de debate, pero como acción, no queda muy claro qué
implica. Para crear acciones, el equipo debe responder al cómo. Para este ejemplo, sería: «¿Cómo
podemos mejorar la comunicación en el equipo?» Muchas veces, es una pregunta difícil de
contestar. Y por eso hay que ser muy claro y específico. Tal vez el equipo quiera reunirse más a
menudo. O quizá quieran crear una lista de correo. Cada acción debe estar muy bien detallada.
¿Cuántas veces quieren reunirse? ¿Quién estará a cargo de la lista? El equipo debe aclarar todas
estas acciones. Puede que tengas problemas para asegurar que los elementos sean mensurables.
¿Cómo sabrás que cierta acción está completa? Digamos que el equipo decide tener una reunión
adicional para mejorar la comunicación. Es bastante improbable que una reunión resuelva todos
los desafíos de comunicación del equipo. ¿Cómo medirías el progreso del equipo? El equipo debe
poder conectar esa acción a un resultado que pueda medirse. También deben preguntarse si la
tarea puede alcanzarse o no, y este es uno de los mayores desafíos. Es mucho más fácil describir
los problemas que resolverlos. Los problemas más grandes casi siempre necesitan muchos
arreglos pequeños. Hallar una gran solución para un gran problema es algo mucho más difícil de
lograr. Si quieres mejorar la comunicación, quizá debas comenzar con un grupo pequeño y
asegurarte de que están hablando de un número reducido de temas. Convoca una reunión
específica con pocas personas y mide el nivel de comunicación. Luego, intenta reducir los casos de
mala comunicación. Otro problema un poco menos frecuente es decidir si una acción es relevante
o no. Suele surgir cuando se analizan las herramientas o el software. Puede que el equipo incluya
entre las acciones que se debe instalar un nuevo software. Será una herramienta interesante, pero
es posible que no le agregue valor al producto. Estas acciones deben analizarse con ojo crítico. Los
desarrolladores suelen querer resolver todos los problemas con software. El equipo debe tener
mucho cuidado de que estas soluciones no le quiten demasiado tiempo al desarrollo del producto.
Por último, deben asegurarse de que todas las acciones respeten el plazo de tiempo limitado. La
retrospectiva se lleva a cabo al final de cada ciclo de dos semanas. Debes crear acciones que
puedan llevarse a cabo durante un ciclo. Trabaja con acciones pequeñas. Si no, puedes correr el
riesgo de que los problemas se repitan en la siguiente retrospectiva.

Genera buenas ideas

Juega para simular la reflexión
A algunas empresas no les gusta recurrir a juegos clásicos en el trabajo. Creen que es poco
profesional y se aleja de la imagen corporativa tradicional. Pero las retrospectivas favorecen
siempre la reflexión creativa. Se trata de pensar ideas para mejorar el proceso. Para motivar la
creatividad, necesitas que el equipo se sienta cómodo y tenga energía. Y los juegos pueden
ayudarte mucho.

Un juego muy conocido es el Círculo de preguntas, creado por Diana Larson y Esther Derby para
ayudar a potenciar las conversaciones. Obliga a todos los miembros del equipo a pensar algunas
preguntas. Es probable que en las retrospectivas te encuentres con que unas pocas personas
acaparan la conversación. A veces, un solo miembro del equipo sobresale y no deja hablar a los
demás. Otras veces, puede que a solo unos pocos les motive la mejora que se está tratando. Sea
como sea, siempre obtienes el mismo resultado: hay algunos miembros que aportan más y otros
que se quedan callados. Es difícil conseguir que todos participen mientras y al mismo tiempo
intentar callar a los más fuertes. Para mejorar esto, prueba el Círculo de preguntas.

Para empezar, haz que todos se sienten formando un círculo. Luego, pídele a un miembro del
equipo que le pregunte algo a la persona a su izquierda. Puede ser sobre cualquier tema. Esa
persona responde y le hace otra pregunta a quien está a su izquierda. Puede ser la misma
pregunta u otra distinta. Es probable que repitan la pregunta si creen que otra persona puede dar
una respuesta mejor. El juego funciona mejor si hacen dos rondas de preguntas. Haz que hablen
según el sentido de las agujas del reloj. Al llegar al final, cambia el sentido. A muchos equipos les
resulta más fácil hacer preguntas que sugerencias. Haz una pregunta simple: «¿Cómo crees que
podríamos mejorar las estimaciones del equipo?» Es muy probable que esta pregunta inicie un
debate. Compárala con: «Realmente necesitamos mejorar la forma en la que hacemos las
estimaciones». Eso no motiva ninguna conversación. Es más probable que se pongan a la
defensiva. Como facilitador, presta atención a las preguntas que se repiten. Si se pregunta lo
mismo más de una vez, anota el tema para debatirlo más tarde. Con este ejercicio, podrás extraer
mucha más información del equipo. Y también de las personas más calladas. No le dediques
mucho tiempo a dirigir las preguntas. No pasa nada si algunos hacen preguntas graciosas, porque
eso ayuda a que todos se sientan más cómodos.

El Círculo de preguntas es muy útil cuando hay diferentes niveles de participación. Todo el mundo
tiene sugerencias, pero a veces hay problemas para explicitar las ideas. Si eres el facilitador, no
propongas el juego cuando haya problemas para expresar ideas nuevas. Prueba un juego
diferente. A veces sirve mucho imaginarse el futuro. Y puedes proponer jugar a algo llamado
Futuspectiva.

Para este juego, dile al equipo que imagine que están en una retrospectiva, pero de aquí a un año.
¿Qué problemas han resuelto? ¿Qué preguntas siguen abrumando al equipo? Con este juego,
cambiarás el objetivo de reflexión a predicción y te puede ayudar mucho para que el equipo
proponga ideas nuevas. Empezarán a ver más allá de las limitaciones diarias. No estarán
reflexionando sobre lo que han hecho, imaginarán cosas nuevas que podrían hacer. Para empezar
la Futuspectiva, dile al equipo que harán un viaje en el tiempo. Pídeles que imaginen que están en
la misma sala pero un año más tarde. El proyecto se cumplió con éxito y están reunidos para la
retrospectiva final. Haz que reflexionen sobre el producto. ¿Cuáles eran sus mejores
características? ¿Cuáles fueron los acontecimientos clave que contribuyeron al éxito durante el
año pasado? Pregúntales también qué ideas descabelladas acabaron teniendo éxito. En el
presente, registra toda esta información futura. Y cuando el equipo haya acabado, diles que es
hora de volver al presente para hablar de los temas principales. Pregúntales qué necesitarían para
poder alcanzar esas metas futuras. A continuación, haz que les den la vuelta a esos desafíos y
configuren acciones para el presente. ¿Cómo pueden llegar a ese futuro exitoso? El Círculo de
preguntas y la Futuspectiva son métodos creativos para conseguir que el equipo haga aportes en
la retrospectiva. Ambos juegos motivan el pensamiento y el debate. El Círculo de preguntas les da
voz a todos. La Futuspectiva le ayuda al equipo a pensar abierta y creativamente. Si eres el
facilitador, intenta que los juegos sean divertidos y asegúrate de tomar nota de las acciones
propuestas para poder hacer cambios concretos.

El proceso de hacer buenas preguntas

Aunque estén en una retrospectiva, puede que el equipo no haga las preguntas correctas. Y tiene
sentido, porque en muchos equipos ágiles hay desarrolladores y gerentes, profesionales que han
pasado la mayor parte de sus carreras dando respuestas. No se los suele contratar para hacer
preguntas. Y si las hacen, puede que parezca que no hacen bien su trabajo. Busca en alguna página
de empleos y fíjate en los anuncios de las empresas. Busca los términos «experto», «solucionar» y
«experiencia». Luego, busca «curiosidad», «hacer preguntas» y «aprender». La segunda búsqueda
te arrojará muchos menos resultados. La primera seguramente incluya la mayoría de los anuncios.
Así comprobamos que no se suele valorar a los equipos por hacer preguntas. Pero si no se hacen
buenas preguntas, es muy difícil hallar mejoras concretas para los procesos. Debes dejar a un lado
las respuestas y analizar las soluciones por separado. Se necesita una personalidad fuerte para
analizar algo que todos aceptan y preguntar por qué. Pero esto es clave para que una
retrospectiva tenga éxito. Si no se hacen buenas preguntas, el equipo se limitará a intentar
mejorar la situación presente y correrán el riesgo de creer que todo el proceso marcha bien. No
los obligues a hacer preguntas. La capacidad de preguntar, como cualquier otra, requiere práctica.
No asumas que todos van a ser expertos en preguntar lo correcto, porque nunca es así. Para
empezar, hazles preguntas simples: ¿Qué? ¿Cómo? ¿Quién? ¿Dónde? Intenta quitarle esa carga al
equipo y empieza el proceso con preguntas básicas que te permitan obtener más información
sobre los aspectos que identifica el equipo. Puedes decirles que quieres asegurarte de entender
bien. Pídeles que te expliquen todo de una forma simple. Digamos que el equipo ya ha identificado
un área de mejora. En la sección de «aumentar» del diagrama de estrella de mar, escribieron «un
ScrumMaster de tiempo completo». Inicia el debate diciéndoles: «A ver si entendí correctamente.
¿El ScrumMaster no está disponible para el equipo?» Con esa pregunta, el equipo empezará a
darte más información. A continuación, pregúntales: «¿Qué han hecho, intentado o considerado
hacer?» Puede que te digan que hablaron con el ScrumMaster y le escribieron al gerente. De
cualquier manera, debes ayudarle al equipo a encontrar un elemento de acción. Pregúntales cómo
se les ocurre que pueden mejorar ese problema. Siempre haz preguntas al equipo. No les ofrezcas
las soluciones. Las preguntas les ayudarán a tener un modelo de estructura para poder proponer
la mejora del proceso. El equipo ya puede empezar a pensar en formas de mejorar. ¿Deberían
presionar para que el ScrumMaster trabaje con el equipo a tiempo completo? ¿Qué pasaría con el
otro equipo? ¿Por qué comparten el ScrumMaster? ¿Es por razones económicas? Todas esas
preguntas les ayudarán a pensar acciones.

A continuación, deben averiguar quiénes son las personas clave, entre las que sin duda se
encuentran el ScrumMaster, el otro equipo ágil con quien lo comparten y quizá hasta quieran
hablar del jefe directo del ScrumMaster. También podría incluirse al patrocinador ejecutivo. Por
último, deben decidir cuál sería la situación ideal cuando se haya arreglado el problema. En este
caso, quieren un ScrumMaster a tiempo completo. ¿Quieren que el ScrumMaster actual pase más
tiempo con ellos? Cuando el equipo se pregunta qué, cómo, quién y dónde, están segmentando y
resolviendo la situación. Sin darse cuenta, muchos equipos se conforman con mejorar un proceso
fallido. Pero con la retrospectiva debes ayudar a que se identifiquen los temas a resolver.

Una vez trabajé en una empresa que separaba a los desarrolladores de quienes probaban el
software. El tema surgió como un problema durante una retrospectiva. Acordaron que
necesitaban más testers a tiempo parcial. Entonces, el facilitador les preguntó qué, cómo, quién y
dónde. El equipo debatió y se dio cuenta de que el verdadero problema era que la empresa había
dividido el trabajo y también las habilidades. Un equipo ágil debe ser multifuncional y
autoorganizarse. Al comprender el núcleo del problema, fue mucho más fácil hallar una solución.

La técnica de los cinco por qué

Uno de los objetivos de la retrospectiva es hallar maneras de mejorar el proceso. La estrella de
mar muestra los elementos que el equipo quiere reducir, implementar o eliminar. Identificar el
contratiempo es solo el primer paso. Deben definir acciones para averiguar cómo mejorar el
proceso. Por suerte, Agile utiliza algunas herramientas de la producción ajustada. Recuerda que la
producción de software lea todavía se considera parte del método de Agile y por ello, muchas de
sus herramientas funcionan perfectamente en este modelo. Una de las más antiguas es la Técnica
de los cinco por qué. Esta técnica se utiliza para encontrar la raíz de un error de proceso. La raíz es
la causa principal del problema. Es el problema original que causó todas las correcciones
posteriores. A menudo, este problema inicial se entierra bajo una pila de soluciones. Y es por eso
que muchos fabricantes utilizan la Técnica de los cinco por qué, que llega hasta la causa raíz del
fallo. Una de las ventajas de esta técnica es muy fácil de aprender. Simplemente debes preguntar
cinco veces por qué. Al empezar es fácil y se vuelve cada vez más difícil. El mayor problema
consiste en encontrar el momento adecuado para preguntar el primer por qué. Y las respuestas
son casi siempre más difíciles que la pregunta. Debes eliminar toda la información adicional y
encontrar el momento adecuado hacer las preguntas.

Una vez trabajé en una empresa que usaba esta técnica en casi todas sus retrospectivas. En una
de ellas, el equipo presentó un problema para cerrar las historias de usuario de hardware. Estaban
creando historias para instalar servidores y otros tipos de hardware. El facilitador preguntó el
primer por qué: «¿Por qué hay historias activas de hardware en el panel de tareas?» Respondieron
que habían integrado al equipo a alguien de Desarrollo y Operaciones porque eran los únicos que
podían instalar el hardware. El equipo necesitaba el hardware para el proyecto y querían realizar
un seguimiento de las historias. El facilitador preguntó otra vez: «¿Por qué quieren hacer un
seguimiento de su trabajo?» Dijeron que el proyecto dependía de algunos de los artículos que
debía entregar esta persona. Si esa persona tenía demasiada carga de trabajo, necesitaban saberlo
para reorganizar las otras historias. El facilitador preguntó al tercer por qué: «¿Por qué el equipo
depende de algo que entrega otra persona?» Respondieron que la empresa no quería que nadie
del equipo ágil instalara o configurara hardware. El facilitador preguntó el cuarto por qué: «¿Por
qué la empresa prohíbe que el equipo ágil instale o configure hardware?» El equipo dijo que el
grupo de hardware era un área funcional muy diferente. Los altos directivos consideraban que el
equipo ágil no tenía la experiencia necesaria para instalar hardware de producción. No querían ser
responsables de los equipos que instalaba y configuraba gente externa. El facilitador preguntó
entonces por quinta vez: «¿Por qué necesitan instalar hardware de producción?» El quinto por
qué era la causa principal del problema. Hubo un fallo de comunicación entre los altos directivos.
Creían que como el equipo estaba haciendo revisiones del producto dentro del marco ágil,
necesitaban que el hardware estuviese listo. Pero el equipo no necesitaba tanto nivel de seguridad
o configuración. Era una simple revisión del producto. La acción que surgió de ahí fue investigar un
proceso en el que el equipo pudiera configurar un servidor temporal para revisar el software.
Debía coordinarse con el equipo de hardware, pero no hacía falta incluir sus historias en el tablero
de tareas.La Técnica de las cinco preguntas ayudó a erradicar la causa del problema. No debían
mejorar la creación de historias de hardware, sino mejorar la comunicación y eliminar
malentendidos sobre la función de las revisiones de producto.

Recurre a esta técnica cuando creas que hay partes del proceso que no tienen sentido. Pueden ser
arreglos extraños que al equipo no le preocupen mucho. Te será muy útil para analizar las
soluciones que todos aceptan sin dudar porque «siempre ha sido así». Y esta es otra razón
importante para contratar un facilitador externo. Para aplicar esta técnica, a menudo es mejor
tener una nueva perspectiva. De lo contrario, es posible que te resulte difícil encontrar los mejores
motivos.

Toma de decisiones en equipo

Crea elementos de acción
El resultado de cada retrospectiva debe ser una lista clara de acciones que se aplicarán durante el
siguiente ciclo. No deben ser acciones generales, sino pequeñas, mensurables y alcanzables. Para
algunos equipos, no es suficiente con enumerar objetivos inteligentes. No logran llegar al siguiente
paso porque no analizan las metas concretas y objetivas. En su lugar, les cuesta convertir las
palabras en acciones. Cuando intentes crear elementos de acción, ten en cuenta que pueden
surgir tres problemas.

- El primero ocurre cuando se habla mucho y se actúa poco. A veces se dice que es
simplemente una retrospectiva de quejas.
- El segundo es el contrario, y ocurre cuando hay demasiada acción y poca reflexión. El
equipo se abruma hasta con las soluciones más simples.
- El tercer problema ocurre cuando es el ScrumMaster quien propone toda la acción. En
esos casos, el equipo no se hace responsable de su propia mejora.

El más común suele ser el primero: la temida retrospectiva kvetch. Se trata de un término yiddish
que es muy común en el mundo de los negocios y describe una situación en la que alguien se
queja y se queja sin siquiera pensar en formas de cambiar. Por ejemplo, cuando alguien dice que la
sopa está demasiado caliente o está lloviendo mucho. Si eres el facilitador de la retrospectiva,
intenta limitar los comentarios negativos que no impliquen una mejora. Intenta que todos estén
centrados en mejorar y que no estén simplemente quejándose.

El segundo problema es el opuesto al primero y ocurre cuando el equipo se centra demasiado en

la acción. Suele ocurrir cuando el equipo identifica los desafíos, pero no puede ponerse de
acuerdo sobre el alcance del problema. Si en tu equipo hay muchos ingenieros, hay mucho más
peligro de que esto suceda. He visto esta situación en varios proyectos. En una retrospectiva, un
miembro del equipo mencionó que el panel de tareas no estaba actualizado. El desarrollador
empezó a hablar de diferentes paquetes de software. Aclaró que se podía acceder al panel de
tareas desde cualquier computadora, teléfono o tableta. El software también mostraba el historial
de tareas. Se podían revertir los cambios y corregir errores. Al equipo se le ocurrió una lista de
acciones. Estaban de acuerdo en comprar una suscripción de prueba de dos o tres paquetes de
software diferentes. El facilitador tuvo que pedir una pausa. Todos tenían que comprender y
ponerse de acuerdo en cuál era el problema. ¿Por qué no se actualizaba el panel de tareas? ¿Los
miembros del equipo no trabajaban en el espacio compartido de trabajo? Este es el tipo de
desafíos que debe debatir el equipo. La verdadera acción debía ser asegurarse de que el equipo
trabajaba en el mismo espacio. Si los miembros del equipo no estaban juntos, ¿qué consecuencias
tenía para el resto del proyecto? Una de las acciones era asegurarse de que todos trabajaran en el
espacio compartido durante el siguiente ciclo.

El mayor problema ocurre cuando el equipo depende demasiado del ScrumMaster. En esas
retrospectivas, los equipos pueden identificar varias acciones, pero son tareas que deberá hacer el
ScrumMaster. Cuando esto ocurre, el facilitador debe asegurarse de que el equipo identifique
acciones que mejoren el proceso. Si el ScrumMaster asume la responsabilidad de toda la acción, la
meta última no es mejorar el equipo, sino eliminar los obstáculos. Puede que deban comprar un
nuevo paquete de software o pedir un aumento de presupuesto. También envía un mensaje
equivocado que no tiene nada que ver con el objetivo de una retrospectiva. Se indica que el
equipo necesita un ScrumMaster para hacer cambios significativos. Esto no permite que el equipo
se autoorganice y asuma una responsabilidad compartida para su propio proceso. En su lugar, se
crea un efecto de embudo: el equipo espera a que el ScrumMaster complete sus tareas y no hay
creatividad ni responsabilidad.

Si eres el facilitador, asegúrate de evitar que el ScrumMaster asuma la responsabilidad de la mayor

parte de la acción. para que el equipo comprenda la idea, puede que te sea útil pedirle al
ScrumMaster que no asista a algunas reuniones. El equipo debe reflexionar sobre su propio
proceso y no esperar que otros tomen las medidas necesarias.

Cierra la reunión de retrospectiva

Haz un seguimiento de los elementos de acción
En una retrospectiva es necesario que haya acción. Es la mejor estrategia para abordar los
contratiempos continuos del equipo. Si no se identifica la acción, sería como correr en una cinta
sin ir a ningún lado. Los elementos de acción representan la forma en que se adapta el equipo.
cada uno es un pasito corto en la dirección correcta. También sirven para responsabilizar a cada
miembro por una parte de la solución. Es muy fácil tratar los problemas de forma abstracta. Lo
difícil es desglosar la solución en acciones individuales y hacer que cada miembro del equipo se
haga cargo de una parte de la solución. Por ello es importante que todos los miembros colaboren
en la corrección del proceso. Para alcanzar este nivel de responsabilidad, como facilitador puedes
hacer lo siguiente: Primero, intenta que cada elemento de acción tenga un propietario. Pide que
se ofrezcan voluntarios. Y recuerda: el equipo debe organizarse a sí mismo. Como facilitador,
nunca debes asignarle un propietario a la acción y también debes evitar que lo hagan los jefes de
proyecto, los ScrumMasters o los gerentes. Sería contraproducente. Cada miembro del equipo
debe ofrecerse como propietario de al menos una acción. Ten en cuenta que una persona puede
tener más de un elemento de acción.

Presta atención a las acciones para las que nadie se ofrezca como voluntario y haz que el equipo
debata el motivo. Esto suele ser una señal de peligro. No pienses que es porque el equipo no
quiere trabajar de más. Muchas veces, esto ocurre porque nadie entiende qué se necesita para
cerrar ese elemento de acción. Los elementos de acción y sus propietarios deben estar presentes
en el espacio de trabajo. A algunos equipos les funciona tener un Muro de ajustes o Tweak Wall,
que suele ser un gráfico muy simple. Se trata de una pizarra con el título en la parte superior. A
continuación, cada persona agrega una nota con su acción y su nombre. Algunos equipos colocan
las acciones en un tablero de tareas, pero de esta forma el tablero parece demasiado
desordenado. Lo ideal es que los propietarios de la acción se autoorganicen y entreguen las
correcciones en la siguiente retrospectiva. En muchas empresas sigue siendo muy difícil lograr que
el equipo autoorganice las acciones.

La mejor forma de motivar la acción es reservar un momento al final de las reuniones diarias. El
ScrumMaster debe trabajar con el equipo y averiguar qué días prefieren abordar el Muro de
ajustes. A veces se confunden las acciones con los obstáculos del ScrumMaster. Deben entender
que cada miembro es responsable de completar su acción, mientras que el ScrumMaster elimina
los obstáculos cotidianos del equipo. La diferencia clave radica en que los obstáculos impiden que
se pueda completar el producto. Las acciones, en cambio, son el resultado de una retrospectiva.
Mejoran el proceso del equipo. Imaginemos que el equipo trabaja con el diagrama de estrella de
mar y apuntó el título de «aumentar». El objetivo es vago. Hay que ser muy hábil para crear
buenas historias de usuario. Entonces, el facilitador los anima a identificar acciones para mejorar
el proceso. El equipo propone dos acciones principales. La primera es recomendar un buen libro.
La segunda, que un propietario de producto experimentado de algún otro equipo participe en las
sesiones de estimación. Compara eso con los obstáculos de un ScrumMaster, que debería
programar sesiones de formación o buscar tiempo para convocar a un formador de Agile. Las
acciones deben mejorar el proceso del equipo. El ScrumMaster, en cambio, se ocupa de que el
desarrollo no se detenga. Las acciones tienen más que ver con la superación personal. Los
obstáculos, con la mejora del proceso final.

Conclusión
Espero que hayas disfrutado de este curso sobre retrospectivas ágiles, que son una forma clave de
ayudar a que los equipos mejoren continuamente. No tengas miedo, experimenta con nuevas
formas de mantener la energía y la concentración en el rendimiento. Existen muchos cursos para
mejorar las retrospectivas. Uno de los mejores y más antiguos se titula Agile Retrospectives:
Making Good Teams Great. Este libro, de Esther Derby y Diana Larsen, propone muchos ejercicios
y consejos prácticos. Te ayudará a sacar el máximo partido a tus retrospectivas. Este curso
también tiene un libro complementario, Leading Agile Teams, que amplía estas ideas y añade
algunos detalles que no pude incluir en el video. Este fue el curso final de la serie «Agile en
acción». El objetivo es que tu equipo sea más ágil y alcance mejores resultados

Usa Microsoft Project con metodologías ágiles

Presentación
La transformación digital está revolucionando el panorama empresarial en los últimos años. Ante
la creciente necesidad de desarrollo de proyectos en entorno digital, las metodologías ágiles se
han introducido en todos los sectores de la economía y llegan pisando fuerte. Su implantación en
los proyectos de nuevo surgimiento es tan necesaria como beneficiosa.
 Soy Isabel Fernández, formadora certificada MOS, y he ayudado a usuarios a crear y gestionar sus
proyectos durante muchos años. Para ello, he usado casi siempre Microsoft Project. Si tus
proyectos a menudo terminan siendo una parte ágil y otra parte en cascada tradicional, puedes
aplicar técnicas ágiles con Microsoft Project. Aún mejor, puedes administrar las tareas
programadas tradicionalmente y el trabajo ágil en paralelo, dentro del mismo archivo de proyecto.
Project Online Professional versión de escritorio para suscriptores contempla los enfoques Scrum y
Kanban. Este curso cubre las características ágiles integradas en Project Online Professional y
también te guiará a través de la personalización de cualquier adición de Project para que sea ágil.
Con estas técnicas podrás planificar, rastrear y administrar proyectos ágiles usando Microsoft
Project. Si necesitas gestionar tus proyectos ágiles, acompáñame en este curso de LinkedIn
Learning, porque estoy segura de que te va a resultar muy útil.

Introducción a la gestión de proyectos ágiles

Lo que necesitas saber sobre el contenido de este curso
AAtes de comenzar, hay algunas cosas que creo que debes de saber sobre este curso. Lo primero,
que ya debes de estar familiarizado o familiarizada con los conceptos básicos de Microsoft Project,
como son la cinta de opciones, las vistas, la creación de tareas y la asignación de recursos. De esta
manera, podemos enfocarnos en cómo usar Microsoft Project para administrar nuestros proyectos
ágiles. A continuación, en este curso se cubren dos enfoques ágiles populares: Scrum y Kanban.
Pero quiero que sepas que no proporciono explicaciones en profundidad de estos enfoques.
Explico cómo aplicar estos enfoques utilizando Microsoft Project.

Lo último es que este curso no cubre el seguimiento y desarrollo de las herramientas ágiles de
Scrum o Kanban. Solo las utilizaremos cuando sean necesarias para trabajar. Una vez aclarados
estos puntos, vamos a comenzar a gestionar nuestros proyectos ágiles o híbridos con Microsoft
Project.

Una revisión rápida de lo que es un proyecto ágil

La gestión de proyectos ágil es el proceso de gestionar proyectos desglosándolos en cantidades
más pequeñas de trabajo. Esta metodología permite el desarrollo de proyectos que precisan de
una rapidez especial y flexibilidad en su proceso y, en especial, de aquellos proyectos que tienen
que ser desarrollados en entornos donde encontramos una gran incertidumbre, porque nos
permite ser flexibles y adaptarnos a los cambios que van sucediendo durante el desarrollo del
proyecto. Los proyectos ágiles se distinguen de los tradicionales en cascada en varios aspectos.

Con los proyectos ágiles, se crean unidades de trabajo lógicas y pequeñas llamadas iteraciones o
"sprints". Los "sprints" o iteraciones suelen durar de cuatro a doce semanas. Se van aportando a la
empresa en pequeñas entregas. La técnica ágil es práctica cuando los proyectos cambian con
frecuencia y cuando se requiere obtener beneficios con más anterioridad. De esta forma, te
puedes centrar en las necesidades actuales y, si estas cambian, puedes acomodarlas en la
siguiente iteración. También se fomenta la comunicación cara a cara por encima de la
documentación. Necesitamos producir un producto, no una documentación sobre ese producto.

Los miembros de cada equipo trabajan en el mismo lugar o usan herramientas virtuales para
asimilar que están juntos. Es como aplicar la gestión ágil para gestionar proyectos de IT, pero
también es aconsejable para otros muchos tipos de proyectos.
La metodología tradicional en cascada es un proceso lineal y secuencial. Se documentan los
requisitos del proyecto por adelantado. Luego se completa el diseño de toda solución y, a
continuación, se realizan las fases de desarrollo y de pruebas. Después, para finalizar, se pasa a la
etapa de implementación del producto. Si completar este proceso lleva un año o más, la empresa
no verá ningún valor palpable hasta el final del proyecto. Por lo tanto, para saber qué metodología
es más apropiada, primero tenemos que entender bien qué tipo de proyecto y necesidades
tenemos delante. Para proyectos estáticos donde es improbable que surjan muchos cambios, nos
servirá el método cascada, mientras que para proyectos pequeños donde los cambios son
habituales en el proceso de diseño, será mejor optar por el método ágil. Puede ser que, después
de explicarte cuáles son las diferencias, te estés haciendo esta pregunta: ¿se pueden implementar
estos dos métodos de manera complementaria sin ser excluyentes? Como experta en esta materia
y coincidiendo con otros expertos, pienso que ambos métodos pueden coexistir en la gestión de
proyectos, aunque no exista una fórmula definida para ello. El éxito de probar nuevas fórmulas
dependerá del margen de error y de las consecuencias que se esté dispuesto a asumir.

Algunos ejemplos de proyectos –además de los relacionados con IT– para los que se recomienda
usar la metodología ágil, son el desarrollo de productos, las reubicaciones, las reorganizaciones de
empresa, los cambios en el proceso de un departamento de una organización e incluso en la
construcción.

Configurar Project para la gestión ágil de proyectos

Configuración de las opciones de Project
Cuando administras un proyecto ágil, configurar algunas de las opciones avanzadas del proyecto
puede facilitarte considerablemente el trabajo. Para acceder a estas opciones vamos a dirigirnos a
la pestaña Archivo, pero si quieres puedes abrir antes el archivo 'Introducción. mpp' de los
archivos base para practicar esto que te estoy explicando. Vamos a acceder a la pestaña Archivo,
como te comentaba, y en la parte inferior izquierda vamos a seleccionar Opciones. En el cuadro de
diálogo Opciones del proyecto debemos ir a la categoría Programación. A continuación, nos vamos
a desplazar hacia abajo hasta que podamos ver las Opciones de programación para este proyecto.
Una vez en las Opciones de programación, vamos a fijarnos si la opción de Nuevas tareas creadas
está en programación manual. Esto vamos a cambiarlo a programación automática. Simplemente
desplegamos en la flecha y seleccionamos Programada automáticamente. La siguiente opción que
vamos a modificar es el tipo de tarea predeterminado. Vamos a cambiar el tipo de tarea
predeterminado, en lugar de Unidades fijas, por Duración fija. Recuerda que las características de
un proyecto ágil se estiman utilizando puntos, no esfuerzo. No tienes que asignar recursos a las
tareas de funciones si no quieres, ya que el equipo se administra solo. Por esa razón, la duración es
un valor que deseamos mantener igual o fijo. De todas formas, podemos cambiar el tipo de tarea
cuando lo necesitemos directamente desde el formulario de Tareas. A continuación, y muy
importante, asegúrate de que se encuentra desactivada la casilla de verificación Vincular
automáticamente las tareas insertadas o desplazadas. De esa manera, tendremos el control
absoluto entre las dependencias de las tareas en nuestro proyecto. Desactiva también la casilla de
verificación Mostrar las tareas programadas que tengan duraciones estimadas y también desactiva
la casilla de verificación Las tareas programadas nuevas tienen duraciones estimadas. Como ya
veremos, agregaremos duraciones a las tareas cuando las agreguemos a los "sprints". Ya hemos
terminado de configurar las opciones. A continuación, tenemos que hacer clic en Aceptar para
cerrar el cuadro de diálogo de Opciones del proyecto. Estas son las configuraciones de proyecto
que cambiaremos de Microsoft Project cuando pretendamos trabajar en un proyecto ágil.

Definir el horario de trabajo con Project

Los "sprints" pueden durar de dos a doce semanas. En este proyecto, estoy usando "sprints" de
dos semanas, es decir, diez días hábiles. Para mantener constante el número de días de trabajo de
"sprint", es importante añadir cierta información al proyecto sobre los días festivos o feriados y
otros días no laborables. Al igual que fijas tu tiempo de trabajo en Project, así lo vas a hacer para
un proyecto ágil. Ve a la pestaña Proyecto y luego haz clic en el botón Cambiar tiempo de trabajo.
Aquí, en el cuadro de diálogo Cambiar tiempo de trabajo, el calendario se configura sobre el
calendario estándar. Es decir, el que aparece predeterminado. A continuación vamos a ir a la
pestaña Semanas laborales. Este proyecto está utilizando por defecto una semana laboral que va
de lunes a viernes, ocho horas por día. Recuerda que, si tu empresa utiliza una semana laboral
diferente, puedes hacer clic en el botón que encuentras a la derecha llamado Detalles. Seleccionas
aquí la semana laboral arrastrando con el ratón por encima de los días que quieres cambiar en la
tabla. Por ejemplo, de lunes a viernes, o si por ejemplo trabajáis de lunes a sábado, pues de lunes
a sábado. A continuación, tienes que hacer clic en la opción Establecer días en estos periodos
laborables específicos para cambiar los días laborables y las horas laborables. En este proyecto no
voy a cambiar nada, es decir, nos coinciden los días laborables y los horarios laborales con los
nuestros propios. Así es que permíteme que haga clic en Cancelar y, de este modo, cierro el
cuadro de diálogo. Lo que sí que voy a hacer es añadir los días festivos o feriados al calendario
para que no se tengan en cuenta como días de trabajo. Para ello, voy a la pestaña Excepciones.
Tengo un proyecto de seis meses y varios días feriados o festivos que ocurren durante esos seis
meses. Los incorporaré a esta tabla. Voy a hacer clic en la primera celda, donde dice Nombre. Esta
celda que está en blanco es la que me servirá para configurar un día festivo. Por ejemplo, el día de
Navidad. Ahora estoy trabajando en 2018. A continuación, como el proyecto va a cambiar de año,
voy a añadir tanto el día de Navidad como el día de Año Nuevo para el 2019, ya que nuestro
proyecto comienza el día 2 de enero. En este caso, vamos a irnos al 2019 para marcar el 25. Y, en
el caso del año nuevo, ya marcaremos para el 2020. Así voy escribiendo todos los días festivos o
feriados uno debajo de otro. Creo que he olvidado el día de Reyes Magos, y ese sí que es el 6 de
enero del 2019. Como mi proyecto comienza el día 2 de enero del 2019, tengo que añadirlo. A
continuación, indicaré qué día se produce ese festivo: el día 6 de enero. Así puedo ir añadiendo
todos los días festivos que necesite, uno debajo de otro. Y si se me olvida alguno, siempre podré
venir aquí y añadirlo en el momento que sea necesario. A continuación, si ya no tengo que
cambiar nada más, todo lo que tengo que hacer es clic en Aceptar para cerrar el cuadro de diálogo
de Cambiar calendario laboral. Como ya sabrás seguramente, cuando agregas tiempo no laborable
al calendario, Project extiende la fecha de finalización de un "sprint" para compensar este tiempo
no laborable.

Crear campos personalizados para administrar características

Nuestro proyecto necesita unos campos personalizados para mostrar las características, los
"sprints" y los lanzamientos de la forma en que probablemente necesitemos verlos. El seguimiento
y la comunicación del progreso también funcionan de manera diferente en los proyectos ágiles en
comparación con la gestión de proyectos tradicional. Los campos personalizados son la clave para
hacer que el proyecto sea ágil.
Para acceder a campos personalizados, en la pestaña Proyecto haremos clic en el botón Campos
personalizados. Los campos básicos que necesitamos son bastante sencillos de crear. El primer
campo personalizado que vamos a crear es uno para designar una tarea como una función de
acumulación. Para eso me dirigiré a la lista desplegable Tipo y elegiré Marca. Comenzaremos con
el campo o Marca1, ese es el primero que vamos a personalizar, que es el que ya está
seleccionado. Esos campos contienen dos valores por defecto: Sí o No. Es decir, es un campo de
tipo lógico. Ahora voy a hacer clic en el botón Cambiar nombre y voy a cambiarle el nombre
llamándole "Característica". Hacemos clic en Aceptar. Podemos ver el alias en la lista. Usaremos
este campo para filtrar las tareas, de modo que podamos indicar si es una característica o no.
Ahora vamos a configurar los campos para especificar el lanzamiento y el "sprint" para nuestras
características. Voy a usar un campo numérico para esto. En la lista desplegable Tipo, voy a elegir
Número. Una vez más, comenzaré eligiendo el Número1. Voy a cambiarle el nombre por "Número
de lanzamiento". Esto va a especificar a qué lanzamiento pertenece una característica. Aceptamos
y a continuación seleccionaré el Número2 y cambiaré el nombre a "Número de sprint". Cuando
hago clic en Aceptar, ahora tengo ambos alias en su lugar. Número de sprint va a rastrear el
"sprint" dentro de un lanzamiento. Con estos campos podrás agrupar las características trabajadas
por lanzamiento y aceleración. Ahora voy a configurar un tercer campo numérico. Selecciono
Número3 y le cambiaré el nombre a "Punto de característica". Hago clic en Aceptar y ya tengo ese
campo personalizado en su lugar. Vamos a utilizar este campo para decidir qué característica
asignar a un "sprint". La prioridad es otro aspecto que influye en el "sprint" al que asignamos una
función. Para ese campo, voy a utilizar un campo de texto. En la lista desplegable Tipo, voy a
seleccionar en este caso Texto y voy a empezar con Texto1. Voy a renombrarlo con el nombre
"Prioridad de característica". Hago clic en Aceptar y ya tengo este campo en la lista de campos.
Ahora vamos a crear una tabla de búsqueda para que podamos especificar los valores válidos para
la prioridad. En la parte de Atributos personalizados, vamos a hacer clic en el botón Buscar. En la
primera celda de valor escribo "Baja" para una prioridad baja. A continuación presiono Enter, y
esto hace que baje a la siguiente celda. Aquí escribo "Media". Presiono Enter y en la última celda
escribiré "Alta". Si quieres, también podemos añadir una descripción. En este caso, podemos decir
que esto es "Prioridad baja", la siguiente es "Prioridad media" y la última, "Prioridad alta". Esto es
lo que tenemos que hacer para crear esta tabla. Haremos clic en Cerrar para cerrar el cuadro de
diálogo. Haremos también clic en Aceptar para cerrar el cuadro de diálogo de los Campos
personalizados. Estos son los campos personalizados básicos que vamos a usar para administrar un
proyecto ágil en Microsoft Project. Más adelante necesitaremos agregar algunos campos
personalizados adicionales para la velocidad de rastreo.

Rastrear la velocidad mediante campos personalizados

Podemos usar un campo personalizado para rastrear los valores de velocidad que un equipo logra.
Vamos a configurar un campo personalizado con la fórmula para hacer precisamente eso. En la
pestaña Proyecto, vamos a hacer clic en el botón Campos personalizados. Queremos configurar un
campo para rastrear los puntos completados, entonces va a ser un campo numérico. En la lista
desplegable Tipo, seleccionaré Número. Y en este caso los tres primeros ya no están disponibles,
así es que elegiré Número4. En este caso, una vez seleccionado, haré clic en el botón Cambiar
nombre y lo llamaré "Velocidad". Hacemos clic en Aceptar y ya tenemos el nombre cambiado. Para
agregar una fórmula a este campo, en la sección Atributos personalizados, haremos clic en el
botón Fórmula. Eso nos permite crear una fórmula para el campo Velocidad. antes de configurar la
fórmula, vamos a tomarnos un segundo para averiguar qué tiene que hacer la fórmula. Si una
tarea es una característica y está completa, la velocidad debe ser igual a los puntos de la
característica, porque esos son los puntos completados. Si la función no está completa, no se
obtiene crédito. O sea, es cero. En fin, se siente. Y si la tarea no es una característica,
definitivamente no tiene puntos. Tenemos un par de condiciones que tenemos que agregar. Lo
primero que vamos a hacer es agregar una función condicional. Para eso, vamos a hacer clic en el
botón Función. En este caso, vamos a seleccionar General. Y dentro de General, la función
condicional IIf. Lo siento, pero esa expresión no está traducida, así es que la usaremos como está
en inglés, pero ya sabes que es un condicional que significa "si". La expresión es la condición para
"si entonces". Hacemos doble clic para seleccionar Expresión. Y ahora pensamos: ¿qué queremos
para esta primera condición? La primera prueba es que el campo Característica es igual a Sí.
Vamos a insertar eso. Haremos clic en el botón Campo y, como este era un campo de tipo marca,
vamos a ir a donde dice Marca y a continuación iremos a la categoría Marca personalizada, y aquí
vemos Característica. Lo seleccionamos. Como la característica queremos que sea igual a "sí", pues
escribimos eso, '= Sí'. No olvides poner la tilde en el "sí", ya que este campo se ha creado con un
valor lógico que es Sí o No, y el "sí" lleva tilde. Esta es nuestra primera prueba. Ahora vamos a
hacer clic en la parte verdadera. Bueno, doble clic para que se seleccione. Y, si no, arrastrando por
encima de ella. Perfecto. Esto se va a sustituir ahora por lo que ocurrirá en el caso de que se
cumpla la condición. Como puedes imaginar, tenemos que agregar aquí una segunda condición
para la tarea que está completada. ¿Qué significa eso? Que hay que añadir otro IIf. Así es que
vamos de nuevo a Función, de nuevo a General y cogemos otro IIf o "si", traducido al castellano.
De nuevo, hagamos doble clic en Expresión para añadir la segunda condición. La tarea
Característica debe estar completada, por lo que vamos a usar el tanto por cierto completado. Y
para que esté completada, tiene que estar al 100 %. Así es que, en el botón de Campo, vamos a
elegir un campo de tipo Número. Y dentro del campo Número, % completado. Y esto es '=100'. Ya
tenemos nuestras dos condiciones. Si la tarea llega a la segunda parte verdadera, debemos
otorgar todos los puntos de Característica para la tarea. Así es que lo que vamos a hacer aquí es
seleccionar la parte verdadera e insertar aquí el campo numérico de tipo personalizado Puntos de
característica. Si no está completado, no se obtiene nada, así es que en la parte falsa escribiremos
"0". Y en la última parte falsa, bueno, si la característica es igual a No, no obtiene ningún punto. Así
es que también aquí en esta parte falsa escribiré "0". Fíjate que la fórmula te haya quedado bien,
no te falte ningún punto y coma y todo esté correcto. Una vez te hayas cerciorado de que todo
está correcto, haz clic en Aceptar. Ahora te va a aparecer un cuadro de diálogo. Este cuadro te
habla sobre eliminar datos existentes. No tenemos ningún dato asistente, por lo que podemos
hacer clic en Aceptar sin preocuparnos. Y una última cosa que nos queda por hacer: ve a la sección
Cálculo de las filas de resumen de grupo y tarea. Queremos acumular estos valores en la fila de
resumen, porque lo que queremos es que la fila Resumen del "sprint" muestre la velocidad para
todas las características completadas en ese "sprint". Así es que en este caso vamos a seleccionar
la opción Resumen. Una vez hecho esto, ya podemos hacer clic en el desplegable y seleccionar
Suma. Cada tarea de Función mostrará sus puntos completos. Al elegir la acumulación de suma, la
tarea de resumen para el "sprint" mostrará los puntos completos, es decir, la velocidad del
"sprint". Vamos a hacer clic en Aceptar para cerrar el cuadro de diálogo de Campos
personalizados. Recuerda que siempre es una buena idea hacer una prueba rápida para
asegurarse de que esta fórmula funciona. Vamos a cambiar a la tabla de resumen. En la parte
superior izquierda de la pantalla, como si de una hoja de cálculo se tratase, haz clic para
seleccionarla y, a continuación, con el botón secundario del ratón elige Resumen. Ya tenemos la
tabla de resumen en pantalla. Voy a arrastrar el divisor vertical entre la tabla y la escala de tiempo
hacia la derecha y, de esa manera, podré ver bien la tabla. Ahora lo que voy a hacer es insertar
columnas para Característica, Puntos de característica y Velocidad. Voy a hacer clic encima del %
completado y, con el botón derecho, elegiré Insertar columna. A continuación, empiezo a escribir
"Característica". Ya lo tengo. Vuelvo a hacer clic de nuevo encima de % completado para insertar
una segunda columna. En este caso, Puntos de característica. También lo tengo aquí. Y, por último,
otra vez clic con el botón derecho del ratón, Insertar columna. Y, en este caso, quiero la velocidad.
Ahora vamos a comenzar cambiando la celda Característica para las dos primeras tareas. Solo esas
dos para hacer una prueba rápida. Vamos a cambiar el primero a Sí y luego el segundo a Sí
también. Definir visión lo cambiaremos a Sí, y la siguiente también a Sí. Ahora voy a agregar los
puntos de Característica. Bueno, digamos que para la tarea uno el valor es de cinco puntos, por lo
que escribo "5" en esa celda y en la tarea dos pondré "3". Claro, dirás, todavía no ha pasado nada,
y eso es porque no he cambiado el % completado. Entonces lo que voy a hacer ahora es cambiar el
% completado para esa característica a 100. Fíjate lo que ha ocurrido cuando he presionando
Enter. La fórmula que pusimos en la velocidad ha funcionado y ha cambiado a cinco. Esa es la
cantidad de puntos para esa tarea, y ese número se ha acumulado en la tarea de resumen. Ahora
vamos a cambiar la siguiente tarea, también a 100 % completado. Y, por supuesto, la velocidad se
acumula para que la tarea de resumen ahora tenga una velocidad de ocho. Ahora recuerda que en
un proyecto ágil no se va a verificar la velocidad en la cartera de productos. En realidad, va a ser la
velocidad para un "sprint". La velocidad alcanzada en este "sprint" es ocho. Por lo tanto, la fórmula
está funcionando bien y está haciendo lo que queríamos. Ahora que ya hemos visto que funciona,
simplemente voy a reiniciar las cosas a como estaban anteriormente. Voy a volver a poner cero en
los tantos por ciento completados y voy a ocultar estas tres columnas simplemente seleccionando
las tres, arrastrando con el ratón y con el botón secundario voy a elegir Ocultar columnas. Más
adelante, veremos cómo mostrar la velocidad planificada y la velocidad alcanzada en un informe.

Configuración de una vista para la cartera de productos

Con la ayuda de los campos personalizados que creamos anteriormente, podemos crear una vista
de la lista de funciones. Para crear una nueva vista, iremos a la pestaña Vista y haremos clic en el
botón Diagrama de Gantt. En el menú desplegable, seleccionaremos Guardar vista. Esto va a
guardar la vista con un nuevo nombre. En el cuadro Guardar vista, vamos a escribir "Lista de
funciones". Cuando hagamos clic en Aceptar, fíjate en la parte de la izquierda como la vista se ha
aplicado. Aquí dice Lista de funciones. También en la pestaña Vista, si hago clic en el botón Tablas,
veo que está seleccionada la tabla para la lista de funciones. Cuando creamos una nueva vista, el
proyecto crea automáticamente una tabla personalizada junto con esa vista. Y lo mejor de esto es
que ahora puedo hacer cualquier cambio en la tabla 'Lista de funciones' sin que le afecte a ninguna
otra vista de mi proyecto. Vamos a hacer cambios en la tabla. Quiero ver todas las columnas en la
tabla. Voy a arrastrar el divisor vertical entre la tabla y la escala de tiempo hacia la derecha, de
manera que pueda ver todas las columnas. No necesito ninguna columna desde Comienzo hasta
Trabajo, así es que voy a seleccionarlas y voy a ocultarlas. Botón secundario del ratón, Ocultar
columna. Ahora podemos agregar las columnas que necesitemos. Vamos a agregar Características,
también Número de lanzamiento, Prioridad de características y Puntos de característica. También
añadiremos Número de sprint. Si necesitas cambiar alguna columna de posición, simplemente
puedes seleccionarla y arrastrarla a la nueva posición. Perfecto. Tengo agregados ya mis cinco
campos personalizados, pero como los valores que van a tener esas columnas son muy cortos y las
columnas muy anchas, voy adaptarlos a un tamaño más pequeño. Es decir, más reducido. Voy a
seleccionar todas las columnas y a continuación en el divisor que aparece entre la última columna
y la siguiente, voy a arrastrar. Y, de este modo, voy a ir haciéndolas más pequeñas. Ahora voy a
bajar hacia abajo para ver las tareas que necesito. En concreto, la última fase. Vamos a modificar
el ancho del campo Nombre para que se vean perfectamente. A continuación, lo que vamos hacer
es cambiar el campo Característica todo a Sí. Así es que, donde dice Pila del producto, ponemos Sí.
Y, a continuación, lo que vamos a hacer es arrastrar desde el controlador de relleno que aparece
en la parte inferior derecha de la celda hacia abajo para cambiar todo así. Si quieres puedes ir
haciéndolo poco a poco para no pasarte. Hasta aquí y luego hasta aquí. Una más. Perfecto. Ahora
vamos a crear un filtro para solamente ver todas las tareas que son características. En la pestaña
Vista, vamos a hacer clic en Filtro, y a continuación en Nuevo filtro. Lo vamos a llamar
"Características". El filtro es muy sencillo: el nombre del campo que queremos, que es
Características, el criterio es Igual a y los valores, pues Sí. Perfecto. Pues ya solo tenemos que
hacer clic en Aplicar y ahora solo vemos las características dentro de nuestro proyecto. Esto es
todo lo que tenemos que hacer para ver una lista de todas las tareas que son de tipo Característica
y que estén o no asignadas a "sprints".

Configurar una vista asignada a lanzamientos y springs

A medida que gestionamos la acumulación de productos, es útil ver los lanzamientos y los
"sprints" a los que están asignadas las características. De esa manera, podemos tener en cuenta
los puntos y prioridades de las características cuando asignamos estas a los "sprints". Vamos a
crear esta nueva vista usando la vista de la lista de características como base. Esta es la vista que
creamos en el ejercicio anterior. Para crear la nueva vista basada en esta, vamos a ir a la pestaña
Vista y, en el botón Diagrama de Gantt, en el menú desplegable, vamos a elegir Guardar vista.
Debido a que tengo una vista personalizada ya mostrada, hay dos opciones en el cuadro de diálogo
Guardar vista. La primera es para actualizar la vista actual con la nueva definición, pero como no
queremos hacer eso, si no que lo que queremos es guardar una nueva vista, voy a seleccionar la
segunda opción. Es decir, la que aparece seleccionada por defecto: Guardar como una vista nueva.
Y en el cuadro Nombre voy a escribir el nombre de la vista. La llamaremos "Pila de producto". En
cuanto hago clic en Aceptar, veo que la nueva vista ya está aplicada. Fíjate en el lateral izquierdo
de la pantalla. Además, si hago clic en el botón Tablas, veo que también se ha creado una tabla
asociada a esa vista, como siempre ocurre. antes de continuar con la personalización de la vista,
agregaremos algunos valores de marcador de posición para los números de lanzamiento y "sprint".
Comenzaré cambiando el número de lanzamiento de la primera tarea a 99. Ahora te estarás
preguntando por qué hago esto. Usaré 99 como un código que dice que esta característica no está
asignada a un lanzamiento. Voy a hacer lo mismo para el número de sprint: lo cambio a 99 y
presiono Enter. Esa característica tampoco está asignada a ningún lanzamiento ni ningún "sprint".
A continuación quiero copiar esos valores en todas las características. Para hacer eso puedo
arrastrar esas dos primeras celdas hacia abajo desde el controlador de relleno, así es que voy a
seleccionarlas y desde la esquina inferior derecha, cuando aparece el controlador de relleno, es
decir, la crucecita, arrastro hacia abajo. Y así consigo copiarlo al resto de las celdas. Todas mis
características están ahora sin asignar. Volvamos ahora a las características primeras y vamos a
asignar las dos primeras. En el número de lanzamiento vamos a poner como código un 1, y en el
número de sprint también. También voy a agregar puntos de características para estas dos
características. Permíteme que arrastre un poquito hacia la derecha la línea de separación para
que lo veamos mejor. En la primera característica voy a poner cinco puntos, y en la segunda tres.
Ahora que tenemos todos estos valores en su lugar, voy a terminar de crear la vista. Lo que quiero
hacer ahora es agrupar las características por lanzamiento y "sprint", y para hacer eso tenemos
que crear un grupo. Desde la pestaña Vista, vamos a desplegar la lista de Agrupar por. Esta lista
está justo debajo de los filtros. Es esta que tenemos aquí. Desplegamos y seleccionamos la opción
Nuevo grupo por... Esto nos abre el cuadro de diálogo Definición de grupo. Voy a darle un nombre,
lo primero. Lo llamaré "Lanzamiento y sprint". Los lanzamientos son las partes más grandes del
proyecto. Hago clic en la celda Nombre de campo y puedo comenzar a escribir aquí "Número de
lanzamiento". Y en la siguiente fila elegiremos, por supuesto, "Número de sprint". El orden que
aparece por defecto es ascendente, y es justo el que queremos. Quiero ver el lanzamiento número
uno antes que el lanzamiento número dos. Y, dentro de cada lanzamiento, quiero ver primero el
"sprint" uno, que el "sprint" dos y el "sprint" tres. A continuación, hacemos clic en Aplicar. Una vez
aplicado, puedo ver que tengo un grupo para el lanzamiento número uno y un subgrupo debajo
para el "sprint" número uno, con mis dos características que he asignado a esa velocidad y a ese
lanzamiento. Pero, si te fijas en la columna Puntos de características, hay un pequeño problema.
Lo que realmente quiero ver en la tarea de resumen es la suma de esos puntos, lo que supone que
hemos olvidado configurar algo en el campo Puntos de característica. La forma más fácil de llegar
a ese campo para corregir ese problema es hacer clic con el botón secundario del ratón encima de
la columna y seleccionar la opción Campos personalizados. Fíjate en la sección Cálculo de las filas
de resumen de grupo y tarea. Aquí vamos a seleccionar Resumen y, justo en el desplegable a la
derecha, como función, la Suma. De esta manera, se sumarán todos los puntos de las
características asignadas en el resumen. Solo me falta hacer clic en Aceptar y ahora ya veo que
esto soluciona el pequeño problema. Cuando miro la fila de resumen para el número de "sprint",
veo que los puntos de características que se han asignado son iguales a ocho. Si tenemos un
proyecto configurado de modo que la velocidad planificada para un "sprint" sea de diez puntos,
entonces este "sprint" tiene espacio para más características. Así es como se ve la acumulación de
los productos para facilitar su gestión.

Construir una lista de tareas ágiles

Configurar tareas para iniciación y lanzamiento de proyectos
La iniciación y la planificación del proyecto en los proyectos ágiles es tan importante como lo es
para los proyectos tradicionales en cascada. Además de definir la visión del proyecto, se define la
estrategia de lanzamiento y la duración. En Project podemos configurar estas tareas igual que lo
haríamos en proyectos en cascada, usando la dependencia de tareas y asignando recursos a estas,
y dejando que Project realice de modo automático los cálculos de la programación. Vamos a
cambiarnos ahora a la vista Diagrama de Gantt. Desde la pestaña Vista de la cinta de opciones,
haremos clic en el botón Diagrama de Gantt y cambiaremos a esa vista. Voy a arrastrar el divisor
vertical del nombre de la tarea para que podamos ver perfectamente esos nombres de tareas.
Como podemos ver, he agregado tareas para la iniciación y la planificación, solo para que no
tengamos que crearlas todas. Tengo la tarea de resumen del proyecto activada, por lo que puedo
ver la vista general del proyecto. Para añadir la tarea de resumen, he ido a la pestaña Formato y en
el lado derecho he activado la casilla Tarea de resumen del proyecto. También he aplicado a esta
vista la tabla de resumen. Para ello, he seleccionado como si de una hoja de cálculo se tratase y,
con el botón secundario del ratón, he seleccionado Resumen. Este proyecto comienza con una
tarea para el comienzo del proyecto. Si miras en el diagrama de Gantt –voy a hacer el diagrama de
Gantt un poquito más grande para que puedas verlo–, verás que tengo recursos asignados, y
también puedes ver como la primera tarea está vinculada con la tarea Definición de visión y todas
las tareas están vinculadas entre sí. Si vuelvo a arrastrar el divisor vertical hacia la derecha,
podemos ver el campo, costo y trabajo. Y esto puedo verlo porque tengo recursos asignados a
esas tareas. Por tanto, veo el costo que me suponen y las horas de trabajo que realizan. La visión
general del proyecto incluye que te hagas preguntas como: ¿cuánto tiempo dura el proyecto?,
¿cuánto se supone que cuesta?, ¿cuántos lanzamientos tendrá? Además de: ¿cuántos "sprints"
habrá dentro de cada lanzamiento? Un poco más abajo, he creado una tarea de resumen para
configurar el proyecto, que incluye la definición de los procesos que se van a utilizar y la
configuración del entorno de trabajo, así como la determinación de qué velocidad de "sprint" se va
a utilizar en los "sprint". Al final de la lista, tengo un hito. Y si voy a la pestaña Tarea y hago clic en
el botón Desplazarse a tarea, puedo ver en el diagrama de Gantt que lo tengo vinculado a la
siguiente tarea, Lanzamiento 1. Voy a bajar un poco en la lista de tareas para que podamos ver las
tareas de Lanzamiento 1. La planificación del Lanzamiento 1 no me lleva mucho tiempo, la
duración aquí es solo de tres días y medio. Lo que debes hacer para planificar un lanzamiento es
desarrollar la estrategia y la visión para ese lanzamiento en particular. Por ejemplo: ¿en qué se
centra el lanzamiento? Vamos a desplazarnos hacia abajo un poco más para pasar al "sprint"
número uno, y así podré mostrarte que hay otra tarea relacionada con el Lanzamiento 1. Es la
tarea de ID 36. Esto representa el trabajo que se dedica a construir y publicar un lanzamiento. No
sucede instantáneamente. Agregaremos las tareas de Lanzamiento 2 a este proyecto, y la buena
noticia es que no tenemos que empezar de cero: usaremos las de Lanzamiento 1. Así es que voy a
volver a desplazarme hacia arriba y lo que voy a hacer es seleccionar esas tareas, seleccionando
desde su ID 13 hasta el 18. A continuación, voy a copiarlas. Puedes utilizar el método de copia que
más te guste, puedes ir a la pestaña Tarea y seleccionar la opción de Copiar o utilizar quizás el
botón secundario del ratón y seleccionar Copiar. Una vez las áreas se encuentran en el
Portapapeles, voy a desplazarme hacia abajo, porque quiero copiar esas tareas después de
Lanzamiento 1 compilación, así es que voy a colocarme en esa fila en blanco y aquí voy a pegar.
Puedo utilizar o botón derecho, Pegar, o utilizar el botón de Pegar, o quizás utilizar Ctrl + V. Ahora
ya tengo una copia de las tareas que puedo usar para el Lanzamiento 2. Todavía no hemos
terminado de copiar, necesito copiar la tarea Lanzamiento 1 compilación justo debajo, así es que
voy a seleccionarla también. Voy a utilizar Ctrl + C y voy a colocarme en la fila en blanco y voy a
utilizar Ctrl + V. Ahora lo que ocurre es que la sangría no es correcta. En la pestaña Tarea en la
sección Programación, voy a buscar el botón de Anular sangría. Y esto hace que la tarea tenga el
nivel correcto. El siguiente paso que tenemos que hacer es cambiar todas las tareas donde dice
'Lanzamiento 1' por 'Lanzamiento 2'. En este caso, voy a pulsar la combinación de teclas Ctrl + B.
De este modo, voy a abrir el cuadro de diálogo Buscar y, a continuación, hacemos clic entonces en
el botón Reemplazar. Queremos buscar el número uno y reemplazarlo por el número dos. Pero no
podemos hacer clic en Reemplazar todo, porque nos remplazaría todos los números uno, y solo
queremos hacerlo para este lanzamiento. Por tanto, lo que vamos a hacer es ir haciendo clic en el
botón Reemplazar tantas veces como necesitemos reemplazar. Ahora ya hemos terminado. No
voy a volver a dar a Reemplazar. Podemos cerrar el cuadro de diálogo. Permíteme que me
desplace hacia abajo y ya tenemos modificado este lanzamiento. Ahora tenemos que hacer
algunos cambios con los enlaces entre tareas. Lo primero que tenemos que hacer es vincular el
Lanzamiento 1 compilación a la primera tarea de Lanzamiento 2, Desarrollar estrategia de
lanzamiento y visión. Esto ya sabes cómo hacerlo. Seleccionamos una tarea y la siguiente. Si
observas en la escala de tiempo, hay una línea azul que ha unido las dos tareas. Ahora me
desplazo a la derecha y veo dos líneas negras que bajan desde arriba. Pertenecen a las tareas de
resumen. Se copiaron cuando copiamos las tareas, así es que tenemos que limpiarlas. Voy a hacer
doble clic en esa línea y después hago clic en Eliminar. Y lo mismo con la otra línea. Si me desplazo
ahora hacia el Lanzamiento 2, podemos ver en la escala de tiempo que tengo mis tareas para el
Lanzamiento 2 correctamente en su lugar. Cuando el resto de los "sprints" del Lanzamiento 1
estén en su lugar, podremos vincularlos al lanzamiento del Lanzamiento 1. De esa manera, Project
puede programar el comienzo del Lanzamiento 2. Como puedes observar, las tareas de iniciación y
planificación funcionan igual que las tareas de un proyecto de cascada después de crearlas y
vincularlas.

Creación de tareas para sprints

Al igual que los lanzamientos, los "sprint" también tienen una breve planificación y tareas de
resumen y también están vinculados y programados como las tareas tradicionalmente
programadas en cascada. En Project podemos copiar las tareas de un primer "sprint" para
configurar "sprints" adicionales. En este proyecto ya he configurado las tareas de planificación y
resumen para el Sprint 1 para que así no tengamos que crearlas. La planificación comienza cuando
el propietario selecciona las características para el "sprint" y define la visión. Eso es lo que el
equipo pretende lograr en este "sprint". Una de las cosas que hacemos es validar la capacidad del
"sprint". ¿Cuál es la velocidad esperada del equipo? ¿Y pueden realizar las funciones seleccionadas
en este "sprint"? después de eso, el equipo decide quién va a trabajar en qué características. Si te
fijas, estas tareas son realmente cortas. En ese proyecto la planificación del "sprint" es solo de
medio día. La ejecución del "sprint" comienza con dos tareas que duran la duración del trabajo del
"sprint", que en total son aproximadamente nueve días. Son los diez días del "sprint" menos el día
que usas para la planificación, así como la recapitulación. El Scrum diario es la tarea de las
reuniones diarias cortas que el equipo lleva a cabo mientras las personas trabajan en funciones, y
luego hay otra tarea para revisar y mantener el plan del "sprint" mientras avanzan el trabajo. Uno
de los beneficios de los proyectos ágiles es que el alcance del proyecto y el lanzamiento son
bastante flexibles. Solo cuando ya entras en el "sprint" es cuando el alcance está bloqueado. Voy a
hacer doble clic en esta tarea, Revisar y mantener el Sprint, para abrir el cuadro de diálogo
Información de la tarea. En la pestaña Avanzado quiero destacar que el tipo de tarea para estas
dos tareas está configurado como Tarea de duración fija. Estas tareas siempre van a durar nueve
días. Voy a hacer clic en Cancelar para cerrar el cuadro de diálogo. Desplacémonos ahora a las
tareas del final del "sprint". Hay una tarea para revisar. El equipo presenta las características
completas al propietario y los interesados y ellos deciden si las características están listas. Por otro
lado, la tarea Retrospectiva es una reunión de lecciones aprendidas: el equipo revisa los éxitos y
habla sobre cómo usarlos para mejorar el rendimiento en el futuro. También revisan los desafíos
que enfrentan y descubren cómo resolver esos problemas. El equipo valida la velocidad alcanzada
para ver si se puede ajustar hacia arriba o hacia abajo para futuros "sprints". También revisan los
defectos escapados, esos que no se detectaron durante las pruebas y fueron informados por el
cliente. Ahora que hemos analizado las diferentes tareas del "sprint", copiamos esas áreas para
crear el Sprint 1.2 y 1.3 . Para copiarlos voy a arrastrar sobre las celdas con identificador de tareas
desde la 19 hasta la 35, es decir, comenzando por la tarea de resumen y bajando hasta el hito.
Ahora, como siempre, selecciona el método de copia que desees. Yo voy a utilizar Ctrl + C. Quiero
que estas tareas se encuentren justo entre el final del Sprint 1 completo y Lanzamiento 1
compilación, por eso voy a seleccionar la fila 36 y ahora haré clic en Pegar o utilizaré el método de
pega que prefieras, por ejemplo Ctrl + V. Bien, ya está copiado, pero ahora si miras con atención te
darás cuenta de que esta copia del "sprint" esta sangrada debajo del "sprint" anterior, esto no es
correcto. Para ello voy a colocarme en la copia del "sprint" 1 y, en la pestaña Tarea, voy a hacer
clic en el botón de Anular sangría. Ahora el "sprint" está en el nivel correcto. Ahora vamos a
desplazarnos hacia abajo y colocar la siguiente copia para el Sprint 1.3, es decir, este será el que
hará de Sprint 1.2, y ahora necesitamos un Sprint 1.3. Voy a seleccionar de nuevo la tarea para la
compilación de Lanzamiento 1 y voy a volver a pegar. No necesito copiar de nuevo, porque esa
copia está ya en el Portapapeles. Por tanto, acabo de presionar Ctrl + V y ya tenemos aquí esta
copia. De nuevo tenemos que anular la sangría para dejarlo en el nivel correcto, haremos clic en el
botón Anular sangría de la pestaña Tarea. Y luego, si nos fijamos un poco más hacia abajo, el
Lanzamiento 2 también tiene una sangría incorrecta, tiene que estar un nivel superior, así es que
vamos a darle otra vez al botón de Anular sangría de la pestaña Tarea. Ahora ya lo tenemos en la
posición correcta. Ah, y la Pila de producto igual, también tiene sangría y hay que quitársela. Ahora
sí está todo correcto. A continuación tenemos que empezar a renumerar. El primer "sprint" está
bien, es el 1.1, pero luego tenemos una copia de ese, que tendrá que ser el 1.2. Voy a situarme
aquí y voy a hacer como en otras ocasiones cuando hemos tenido que reemplazar: voy a pulsar la
combinación de teclas Ctrl + B, a continuación voy a hacer clic en el botón Reemplazar y ahora lo
que queremos encontrar es el punto 1.1 y reemplazarlo por el punto 1.2. Recuerda que no
podemos hacer clic en el botón Reemplazar todo, sino que tendremos que ir remplazandolo poco
a poco para no reemplazar el primer "sprint". Ya hemos terminado, porque este será el "sprint"
1.3. Voy a cerrar el cuadro de diálogo para que veas que este ya está reemplazado. Ahora vamos a
hacer lo mismo para este "sprint". Volvemos a pulsar Ctrl + B, volvemos al botón Reemplazar y
ahora el 1.1 debe de ser el 1.3. Volvemos a Reemplazar poco a poco. Y ya nada más, porque este
es el primer "sprint". Cerramos el cuadro de diálogo y ya tenemos todas las copias numeradas. Y
ahora nos queda arreglar las vinculaciones entre tareas. Tenemos que vincular el Sprint 1 con el
Sprint 2. Permíteme que vaya a la pestaña Tarea y haga clic en el botón Desplazarse a tarea para
que podamos ver mejor el diagrama de Gantt. Tenemos que vincular el Sprint 1 completo, la tarea
35, con la primera tarea del Sprint 2, es decir, la tarea 38. Con la tecla Control seleccionamos las
dos y hacemos clic en el botón Vincular tareas. A continuación hacemos lo mismo con el Sprint 2 y
3. Seleccionamos la tarea Sprint 1.2 completo y la tarea 55, Seleccione las características del sprint
1.3 y cree la visión del sprint, con la tecla Control, y desde la pestaña Tarea hacemos clic en el
botón Vincular tarea. Ahora fíjate en la tarea 69, Sprint 1.3 completo. Voy a desplazarme a la tarea
y esta no está vinculada con el siguiente, por tanto tenemos que hacerlo, es decir, hay que
vincularlo. Por tanto seleccionamos la tarea 69 y 70 y en la pestaña Tarea hacemos clic en el botón
Vincular. Ahora como siempre vamos a eliminar las líneas de resumen que se han creado al copiar
los "sprint" y que no son correctas. Nos desplazamos hacia arriba, hacemos doble clic en la línea y
la eliminamos. Y lo mismo con la otra línea de resumen, por tanto ya lo tenemos.

Gestión de la cartera de productos

La cartera de productos no es algo que se mantiene estático, cambia durante la duración de un
proyecto ágil. Los requisitos evolucionan a medida que avanza el trabajo, lo que significa que
puedes tener que agregar o eliminar características. Además debes estimar los puntos y las
prioridades de las características antes de poder determinar qué características asignar a cada
"sprint". Para gestionar el retraso vamos a utilizar la vista de registro de productos que creamos en
otro vídeo. Para ello, desde la pestaña Vista, vamos a hacer clic en el botón Diagrama de Gantt y
en las vistas personalizadas seleccionaremos Registro de productos. Y ahora podemos ver todas
las características asignadas a sus lanzamientos y "sprint". Supongamos que hay una nueva
característica para el trabajo pendiente. Voy a agregarla. Me coloco abajo y la característica se
llama 'Compartir una compra a través de las redes sociales'. Presionamos Enter y ahora permíteme
que me desplace hacia arriba para que podamos verlo. Como puedes observar, el proyecto rellena
automáticamente el campo Característica con No. Tenemos que cambiarlo, porque sí que es una
característica. Desplegamos y seleccionamos Sí. Además esa nueva tarea no está asignada, por
tanto el número de lanzamiento y el número de "sprint" deben de llevar el código 99, este que
creamos para las características que no están asignadas. Por otro lado, voy a eliminar la
característica Escribir una reseña. Para eso simplemente lo que voy a hacer es seleccionarla en su
ID y presionar la tecla Suprimir del teclado, creo que es lo más rápido. A continuación voy a añadir
las prioridades de las dos primeras tareas. Permíteme que haga más amplia la tabla de la izquierda
deslizando el limitador hacia la derecha. Ahora ya podemos ver bien todas las columnas. en este
caso vamos a establecer la prioridad de las dos primeras tareas. La prioridad es 'Alta'. Recuerda
que el campo 'Prioridad' es un campo personalizado al que le añadimos una tabla y estuvimos
añadiendo 3 valores: bajo, medio y alto. en este caso la prioridad de las dos tareas es Alta. Y ahora,
a continuación, lo que voy a hacer es ir añadiendo la prioridad y los puntos para cada una de las
tareas que tenemos. La tarea 'alidar correo electrónico es de prioridad Alta y tiene dos puntos. Las
siguiente es de prioridad Baja y tiene solo un punto. La tarea Buscar correo electrónico del cliente,
esta es de prioridad Media y la estableceremos en dos puntos. Capturar la información de
facturación para el cliente es de prioridad Alta y tiene tres puntos. Validar la información de
facturación es una tarea muy importante, por tanto es de prioridad Alta y además con cinco
puntos. Grabar productos en el carrito de la compra también es una tarea de prioridad Alta. Si no
pueden grabar productos en el carrito de la compra, ¿qué van a comprar? Pero a pesar de ser una
tarea de prioridad Alta, el número de puntos es dos. Editar el carrito de la compra es de prioridad
Media y tiene tres puntos. Crear historial de pedidos es de prioridad Media y tiene cinco puntos.
Añadir una orden al historial es de prioridad Media, es decir, es añadir el pedido a la historia, y
tiene dos puntos. El Orden de edición también es de prioridad Media y tiene tres puntos. Las
Preferencias del envío es de prioridad Baja, tiene dos puntos y el resto todos son de prioridad Baja,
por tanto voy a hacer como siempre: me coloco en la esquina y arrastro para que el controlador
de relleno copie eso mismo en todas las celdas, y ahora voy introduciendo la prioridad. Aquí son
dos puntos, aquí son cinco y aquí son tres. A medida que evolucionan los requisitos podemos usar
esta vista de registros de productos para agregar o eliminar funciones a la cartera, así como para
completar los puntos y prioridades de estas funciones.

Asignación de características a un sprint

Parte de la planificación del "sprint" es seleccionar las características para trabajar durante el
"sprint". La mayoría de las veces la elección de las características va en función de la prioridad de
la característica y de la velocidad esperada de los equipos. Aquí, en la Vista de Registros de
productos que creamos en otro vídeo, hay dos características ya asignadas a Sprint 1.1. Ambas son
funciones de alta prioridad, y eso es lo que normalmente queremos. Primero realizamos las
funciones de alta prioridad. Podemos ver desde los puntos, si nos fijamos, en la fila de resumen
tenemos ocho puntos asignados al "sprint". Supongamos que la velocidad que se estableció
durante la planificación del proyecto es de diez puntos por "sprint", pues entonces a Sprint 1.1
todavía le queda espacio para otra característica. Averiguamos qué característica podemos
agregar al "sprint". Vamos a seguir asignando funciones de alta prioridad primero. Para facilitarlo
lo que voy a hacer es filtrar por las tareas que son de alta prioridad. Para ello, desde la columna
Prioridad de característica haré clic en la flecha desplegable, con esto accederé al filtro. Como
puedes observar está seleccionado todo, voy a quitar la selección de ahí y voy a seleccionar
solamente las características de prioridad alta. A continuación hago clic en Aceptar y ya el filtro se
ha aplicado. Hay cuatro características más de prioridad alta que aún no han sido asignadas, y aquí
podemos ver cuántos puntos tienen. Y así también podremos ver si nos encajan en el Sprint 1.1 o
no. Como tenemos ocho puntos, necesitamos dos puntos más. Hay dos características que tienen
dos puntos y que están sin asignar. Voy a seleccionar Validar correo electrónico. Esta es la que
quiero añadir al Sprint 1. Lo primero que tengo que hacer es cambiar el número de lanzamiento a
1 y el número de "sprint" también a 1. Todavía la vista no se ha actualizado. para que se actualice
tengo que ir otra vez a Diagrama de Gantt en la pestaña Vista y cambiarme a la vista Diagrama de
Gantt, y a continuación vuelvo otra vez a la vista Registro de productos. Y ahora ya la vista se ha
actualizado. Fíjate cómo ahora ya tengo diez puntos para este "sprint". A continuación tengo que
sacar estas tareas del registro de productos y colocarlas en el lugar adecuado en la lista de tareas.
Para hacer eso voy a volver a la vista Diagrama de Gantt. Para ello, desde la pestaña Vista, voy al
botón Diagrama de Gantt y selecciono Diagrama de Gantt. Permíteme que me desplace hacia
arriba para que veamos las tres tareas. Ahora voy a seleccionar desde su ID de tarea, desde la 80
hasta la 82, y lo que voy a hacer es cortarlas para llevarlas al lugar adecuado, es decir, al Sprint 1.1.
Con la combinación de teclas Ctrl + X las corto. Ahora lo que quiero es desplazarme hacia arriba,
hasta el Sprint 1.1, y quiero colocar estas tareas justo debajo de Empezar a trabajar en las
características. Y aquí es donde voy a pegar. Voy a la pestaña Tarea, por ejemplo, y hago clic en
Pegar. Quiero verlo en la barra de tareas y en la escala de tiempo, así es que lo que voy a hacer es
ir a la pestaña Tareas y, en el botón Desplazarse a la tarea, y como la tarea ya está seleccionada,
me aparece justo eso, lo que quiero ver. Todavía son solo, y por defecto, de duración de un día.
Trataremos eso más tarde, porque ten en cuenta que el equipo se maneja solo y los miembros del
equipo descubrirán cuándo trabajar en esas funciones. No tenemos que agregar enlaces entre las
características. En cuanto a las filas en blanco que nos han quedado debajo, vamos a
seleccionarlas en su ID y desde el teclado presionaremos la tecla Suprimir. Para practicar a
continuación vamos a asignar características al Sprint 2. Para ello voy a regresar a la vista Registro
de productos. Desde el botón Diagrama de Gantt de la pestaña Tarea vuelvo a la vista Registro de
productos. Como observarás hay tres características más que son de alta prioridad, y al mirar la fila
de resumen del grupo suman 10, por lo que es perfecto para el Sprint 1.2. Vamos a reasignar los
números para el lanzamiento y el número de "sprint". Para la primera característica pondremos
número de lanzamiento 1 y número de Sprint 2, y a continuación, como es igual para todas las
demás, vamos a seleccionar las dos y arrastrando lo copiamos hacia abajo. Y al igual que antes,
tenemos que mover esas tareas de resumen de posición. Vamos a volver a la vista Diagrama de
Gantt. Desde la pestaña Vista, botón Diagrama de Gantt, vamos a la vista Diagrama de Gantt.
Ahora ya vuelvo a ver la Pila del producto, y tengo que seleccionar desde la tarea 82 hasta la 84, es
decir, las tres tareas que acabamos de asignar. Y, como hicimos antes, las cortamos, Ctrl + X, nos
desplazamos hacia arriba al final del Sprint 2, donde está la fila en blanco, la seleccionamos y aquí
las pegamos, Ctrl + V. Las celdas que están en blanco, al igual que antes, las seleccionamos y las
suprimimos, y a continuación ahora voy a volver a la vista de Registro de productos. Ahora las
tareas están correctas. Lo último que quiero hacer antes de terminar es eliminar el filtro que
tenemos para las tareas de prioridad alta. Así es que en la columna de Prioridad de características
voy a hacer clic en el botón que tiene forma de embudo y voy a marcar Seleccionar todo. Hacemos
clic en Aceptar y esto nos da una visión general del estado de las liberaciones y de los "sprint".
Aquí tenemos diez puntos asignados para el Sprint 1.1 y diez puntos asignados para el Sprint 1.2, y
después tenemos todas las tareas que están sin asignar. Quedan 28 puntos en esta reserva de
productos que aún no están asignadas. Más adelante ya veremos cómo establecer la duración de
una tarea o una característica y, si lo deseásemos, cómo asignar recursos.

Asignación de recursos a funciones en el sprint

Durante la planificación del "sprint", el equipo decide quién va a trabajar en qué funciones. En
Microsoft Project no tenemos por qué asignar recursos a tareas destacadas si no lo deseamos. Sin
embargo, una razón para hacerlo es realizar un seguimiento de las horas realizadas de trabajo. Así
es que vamos a asignar recursos a las funciones que agregamos al Sprint 1.1. Voy a cambiar a la
vista Diagrama de Gantt. Desde el botón de vista Diagrama de Gantt ,en la pestaña Vista,
seleccionaremos Diagrama de Gantt. Voy a desplazarme hacia el Sprint 1.1. Voy a colocarme, por
ejemplo, en la tarea 29, y luego desde la pestaña Tarea voy a hacer clic en el botón Desplazarse a
tarea para tenerlas enfrente. Para establecer las duraciones de estas características insertaremos
el campo personalizado Punto de características en esta tabla. Voy a seleccionar la columna
Duración, con el botón secundario del ratón voy a seleccionar la opción de Insertar columna y aquí
escribiré "Puntos de características". Ya la tengo aquí. Voy a arrastrar el divisor vertical entre la
tabla y el diagrama para poder ver todas las columnas. La primera característica, Capturar
información de contacto del cliente... Voy a hacer esto un poquito más ancho para que podamos
verlo bien y otra vez arrastraré el divisor vertical hacia la derecha. Esta característica está
configurada con cinco puntos. Hay dos desarrolladores en este equipo. Una tarea de cinco puntos
llevará un desarrollador asignado y por supuesto bastante más tiempo. Debido a eso cambiaré la
duración de esta tarea a nueve días, así es que voy a ir al campo Duración y donde dice "1 día" voy
a escribir "9". A continuación me sitúo de nuevo en la tarea y ahora quiero asignar recursos. Para
ello creo que lo más sencillo es utilizar el formulario de Detalles de tareas, así es que voy a ir a la
pestaña Vista y donde dice Vista de dos paneles voy a marcar Detalles. Con esto nos aparece el
formulario de tareas justo debajo. Voy a desplazarme un poquito hacia abajo para que podamos
ver la tarea y también el formulario, y a continuación voy a asignar los recursos a esta tarea. Fíjate
en la columna Nombre de recurso, aquí voy a hacer clic y aparece un desplegable. A continuación
voy a seleccionar al Desarrollador 1, y en esta tarea también voy a asignar al ingeniero de pruebas,
así es que me voy a la fila de abajo y selecciono Ingeniero. Hago clic en Aceptar. por defecto tanto
el desarrollador como el ingeniero están asignados al 100 %, es decir, dedican toda la jornada a
estas tareas, pero el ingeniero solamente va a poder dedicar la mitad de su jornada, por tanto
tenemos que cambiar las unidades al 50 %. A continuación hacemos clic en Aceptar. Tenemos
poco espacio en la pantalla, y no sé si puedes verlo bien, pero ahora ya tenemos aquí la tarea y
también tenemos los recursos asignados. Y fíjate como el ingeniero tiene un 50 %, indicándonos
que va a trabajar solo media jornada. En aquellos recursos que trabajan jornada completa no
aparece nada, por tanto entendemos que el trabajo es al 100 %. A continuación voy a la tarea
Validar dirección. Esta es de tres puntos, y voy a ponerle una duración de seis días. Vuelvo a la
tarea y en este caso voy a asignarle al Desarrollador 2 y también al Ingeniero de pruebas. Tanto al
Desarrollador 2 como al Ingeniero de pruebas tengo que asignarlos, pero recuerda que el
ingeniero de pruebas solo trabaja media jornada. Primero aceptemos y ahora cambiemos las
unidades del ingeniero por el 50 %. Después haremos clic en Aceptar de nuevo. Debido a estas
asignaciones ahora los recursos tienen tasas de costo, por lo tanto puedo ver el costo del trabajo y
también las horas que están trabajando en esas determinadas características. Si volvemos a
desplazarnos en la parte del gráfico de Gantt, tenemos ahora la asignación. Y hay una última cosa
que quiero mostrarte, y es que fíjate en el ingeniero que está trabajando en las dos tareas. Para
mostrarte lo que está ocurriendo voy a añadir una nueva columna. Quizás voy a añadirla por
encima del Modo de tarea. Con el botón secundario del ratón voy a hacer clic y ahora voy a
seleccionar Insertar columna, y aquí voy a buscar la columna de Indicadores. Y ahora, al
seleccionarla, fíjate lo que ha ocurrido. Las tareas no están programadas como habitualmente se
programan en un proyecto en cascada, no tenemos vínculos entre ellas, por tanto el ingeniero de
pruebas está sobreasignado, está trabajando en las dos tareas a la vez. Esto en principio es una
cuestión que podemos ignorarla porque los miembros del equipo administran sus propios horarios
durante el "sprint", por lo que no tienes que preocuparte por esta sobreasignación, pero sí que
quería mostrártelo. A continuación voy a ocultar esa columna, porque ya no la necesitamos. Con el
botón secundario del ratón seleccionamos Ocultar columna. Y así es como se establece la duración
de las tareas y se les asignan recursos.

Seguimiento del progreso en un proyecto ágil

Actualización del progreso de las características
Debido a que en un proyecto ágil no planificamos por adelantado, inicialmente podemos
establecer una línea base para las tareas hasta el final del primer "sprint". Una vez establecida la
línea base podremos actualizar las tareas de características para reflejar el progreso realizado por
el equipo. Quitemos primero la vista del Formulario de tareas. Desde la pestaña Vista
desactivamos Detalles. Para seleccionar las tareas sobre las que quiero guardar la línea base voy a
arrastrar sobre sus identificadores de tareas. Para ello voy a ir hasta la tarea 1 y seleccionaré hasta
la 35. A continuación voy a ir a la pestaña Proyecto y en la sección de Programación voy a hacer
clic en el botón Establecer línea base y en este desplegable seleccionaré también Establecer línea
base. Solo vamos a utilizar la primera línea base, pero si hacemos clic en la lista desplegable vemos
que tenemos once líneas bases, desde la 1 a la 10 y la primera, que es la que vamos a utilizar. por
defecto se selecciona automáticamente todo el proyecto, pero nosotros no queremos guardar la
línea base para todo el proyecto, sino solamente para las tareas seleccionadas, así es que esta
opción es la que voy a elegir. Cuando elijo esta opción se activan dos casillas aquí abajo, Resumir
líneas base. Voy a marcar Para todas las tareas de resumen y a continuación voy a hacer clic en
Aceptar. Con la línea base ya guardada podemos actualizar el estado, y para hacer eso tenemos
que establecer una fecha de estado. En la pestaña de proyecto vamos a ir al grupo de Estado.
Fíjate aquí, y aquí ves que hay un calendario y que pone NOD. Eso significa que aún no tenemos
ninguna fecha de Estado, es como un no aplicable, lo que significa que ahora necesitamos
establecer esa fecha de estado. Voy a hacer clic aquí y voy a seleccionar, por ejemplo, el 9 de
febrero, por supuesto del 2019. Recuerda que nuestro proyecto comienza el 2 de enero del 2019.
A continuación voy a hacer clic en Aceptar. Ahora ya podemos ver la fecha de estado en su casilla
correspondiente. Para facilitar la actualización de las tareas lo que voy a hacer es ocultar las tareas
de resumen. Voy a ir a la pestaña Formato y voy a desactivar la tarea de Resumen del proyecto y
también las Tareas de resumen. Voy a configurar el progreso de todas las tareas hasta el final de la
planificación del Sprint 1.1, que se completará según lo programado. Permíteme que quite la
selección y ahora volveré a arrastrar desde los ID de tareas, desde la tarea 1 hasta la tarea 23. Para
establecer todas esas tareas como completadas te voy a mostrar un atajo. Una vez que tengo
todas las tareas seleccionadas, voy a ir a la pestaña Tarea y a continuación voy a hacer clic en el
botón Información. Entonces el cuadro de diálogo que aparece es un cuadro de diálogo que es
Información para tareas múltiples, y ahora simplemente fíjate donde dice Porcentaje completado.
Si aquí pongo que están al 100 %, pues entonces ya se van a actualizar todas las tareas. A
continuación hago clic en Aceptar y fíjate como ahora todas las celdas han cambiado al 100 %.
¿Ves que se quedan como en azul? Eso significa que hemos hecho un cambio. Ahora bajemos y
actualicemos las características del primer "sprint". Voy a ir hasta la tarea 31, Validar correo
electrónico. Resulta que el Desarrollador 2 comienza a trabajar primero. Pues todo lo que tengo
que hacer es actualizarlo en la celda donde dice Porcentaje completado. Aquí voy y escribo 100 %.
Mira el diagrama de Gantt: la línea azul oscuro significa que ya está completada la tarea. Bueno,
ahora imaginemos que han pasado algunos días y queremos actualizar otras tareas. En primer
lugar vamos a cambiar la fecha de estado. Otra vez voy a la pestaña Proyecto y recuerda que en el
grupo Estado tenemos aquí la fecha de estado. Pongamos que ahora es 17 de febrero. Acepto y
vamos a actualizar la tarea Capturar la información de contacto del cliente. Escribimos en su celda
también porcentaje completado al 100 %. Finalmente vamos a actualizar la tarea Validar dirección.
Esta no comenzó al principio del "sprint", así que usaré un método diferente para actualizarla.
Selecciono la tarea y me dirijo a la pestaña Tarea. Fíjate en el grupo de Programación. Hay un
desplegable que dice Actualizar según programación. Al desplegar seleccionamos la opción
Actualizar tareas. Como la tarea no comenzó en el momento que tenía que hacerlo, lo primero
que voy a hacer es actualizar su comienzo real, fíjate. Vamos a ponerle que inició el 10 de febrero.
En la duración real voy a poner 6 días y todavía quedan dos días para que se complete, por tanto
voy a ponerlo en duración restante. Y por último su porcentaje completado solo es hasta el 75 %.
Ahora hagamos clic en Aceptar y ahora fíjate en la tarea: se ha desplazado, porque no comenzó
cuando debería, y además tiene la barra azul oscuro que llega solamente hasta el 75 % de
completada. Ahora ya conoces un par de formas para actualizar el progreso de las tareas. Más
adelante veremos cómo manejar las características o tareas que no están terminadas durante un
"sprint".

Cómo manejar características incompletas

Los "sprint" no toman tiempo extra si una característica no está completamente terminada. Si no
está completada al final del "sprint" no se obtienen parte de los puntos del crédito, y en su lugar la
característica se mueve al siguiente "sprint". Sin embargo, podemos reducir los puntos para
reflejar el hecho de que una parte del trabajo ya está hecha. Ya vimos que Validar dirección no se
terminó en el Sprint 1.1, vamos a pasarlo al Sprint 1.2. Comencemos por desplazarnos hacia abajo
para ver las características en el Sprint 1.1. Para mover Validar dirección voy a ir al ID de tarea, que
es la tarea 30, y lo voy a seleccionar. A continuación, por ejemplo, desde la pestaña Tarea voy a
hacer clic en Cortar, y en el cuadro de diálogo que aparece se me está haciendo una pregunta:
"Este elemento tiene un progreso informado. ¿Aún desea eliminarlo?" Realmente no quiero
eliminarlo, simplemente lo que voy a hacer es cambiarlo de ubicación, así es que vamos a hacer
clic en Sí. Queremos llevarlo ahora hasta el Sprint 1.2, así es que voy a bajar hasta la tarea 45, la
selecciono en su ID y hago clic en el botón Pegar. Se abre el cuadro de diálogo que nos indica que
el recurso está asignado fuera de las fechas originales de la tarea 45, Validar dirección de este
proyecto, y es que recuerda que habíamos configurado esta como una tarea de duración fija. Se
tiene que cambiar la duración fija para poder acomodar el trabajo retrasado, así es que vamos a
hacer clic en Aceptar. Observa en el diagrama de Gantt cómo se ve ahora. Puedo ver el trabajo
completado en el pasado y también puedo ver el trabajo restante. Lo hemos movido al Sprint 1.2,
pero también tenemos que ir y cambiar las asignaciones en el campo personalizado. Vamos a ir a
la vista Registro de producto para cambiar el número de "sprint" al que pertenece la tarea Validar
dirección. Vamos a la vista Registro de productos y nos fijamos en la tarea Validar dirección. Aún
se encuentra dentro del Sprint 1, no se ha modificado aún, así es que tenemos que cambiarlo,
tenemos que ponerle dentro del Sprint 2 y a continuación, como siempre, tenemos que volver a
aplicar otra vez la vista Registro de productos para que se actualice. Bien, ya está actualizada. Y
ahora fíjate que para el Sprint 1 ha quedado un resumen de siete puntos y al mismo tiempo el
Sprint 2 tiene 13 puntos. Como parte del trabajo de Validar dirección ya está hecho, no tiene
sentido que tenga tres puntos, por tanto voy a cambiarlo a uno. De ese modo podré reflejar mejor
el trabajo que queda por realizar, y quizás ahora tiene sentido añadir a esta tarea una nota y
explicar por qué hemos reducido los puntos, para acordarnos posteriormente. Vamos a hacer
doble clic en la tarea y, justo en Información de la tarea, vamos a ir a la parte de Notas y aquí pues
escribiré "Reduje los puntos de 3 a 1" y bueno, todo lo demás para no perder tiempo pero
imagínate, tendrías que escribirlo aquí. Hacemos clic en Aceptar y ya tenemos una nota para esta
tarea. Ahora también observa que el "sprint" número 2 tiene once puntos en la tarea de resumen
y eso es más de lo que habíamos programado. Habíamos programado que los Sprint tuvieran 10
puntos, esto significa que tenemos que trasladar una de las características al "sprint" número 3.
Por ejemplo, Grabar producto en el carrito de la compra es la que tiene un número menor de
puntos. Para trasladarla al Sprint 3 tenemos que cambiar el número de "sprint" para esta
característica a 3, así es que vamos a la celda y pongamos ahí un 3. Como siempre, volvemos a
aplicar la vista Registro de producto y ahora ya vemos que el Sprint 3 tiene asignada esa
característica. Y ahora nos falta mover esa tarea a su lugar correspondiente dentro de la lista de
tareas, por tanto tenemos que volver a la vista Diagrama de Gantt. Volvemos a la pestaña Vista y
nos cambiamos con el botón Diagrama de Gantt a la vista Diagrama de Gantt. Nos desplazamos
hacia abajo hasta encontrar la tarea. Es la 48, la seleccionamos en su ID. Igual que hicimos
anteriormente la cortamos, por ejemplo Ctrl + X, y ahora nos desplazamos otra vez hacia abajo
hasta la tarea 62, y aquí Ctrl + V. Ya la tenemos en su lugar correspondiente. Así es como se
ajustan las asignaciones de "sprints" cuando una característica no se completa durante un "sprint".

Generar un informe de evolución de proyectos ágiles

Microsoft Project tiene varios informes incorporados que muestran el rendimiento general del
proyecto. Los proyectos ágiles también usan lo que se conoce como un informe de evolución para
ver cómo va el trabajo. Podemos personalizar los informes gráficos de Project para mostrar la
velocidad de reducción y la velocidad del "sprint". Para configurar un informe en Project nos
vamos a dirigir a la pestaña Informe. Dentro de la pestaña Informe vamos a hacer clic en el botón
Panel, y a continuación en el menú desplegable seleccionaremos Evolución. El informe integrado
de evolución tiene un gráfico para ver la evolución del trabajo y ver la evolución de las tareas.
Vamos a utilizar este informe como base para crear un informe personalizado. Para ello, en la
pestaña Diseño haremos clic en el botón Administrar. Vamos a seleccionar la opción Cambiar
nombre del informe, aunque en realidad no estamos cambiando el nombre del informe,
realmente estamos creando una copia de este informe con un nombre nuevo. Vamos a ponerle
como nombre "Estado Ágil". Hacemos clic en Aceptar. Si vuelvo a la pestaña Informe y hago clic en
Panel, el informe de evolución, como puedes imaginarte, todavía está aquí. O sea que no he
sobreescrito nada, lo único que he hecho es una copia de ese informe al que llamado "Estado
Ágil". Vamos a modificar el gráfico de evolución del trabajo para mostrar su evolución en relación
a las características del proyecto. Esos informes de evolución de trabajo en proyectos se basan en
horas de trabajo, no en puntos. Solo podemos usarlos si asignamos recursos a las características.
Vamos a comenzar haciendo clic en el cuadro de texto que dice Evolución y lo cambiaremos por el
nombre del informe, "Estado Ágil". Borramos "Evolución" y ponemos "Estado Ágil". Hacemos clic
fuera y ya tenemos el nombre puesto. A continuación vamos a personalizar el gráfico. Para eso
podemos hacer clic en cualquier parte del gráfico, y esto nos va a abrir un panel a la derecha. Voy
a ampliarlo un poco para ver mejor. Vamos a empezar por cambiar el nivel de esquema, la última
parte, y aquí vamos a elegir Nivel 1. Pero aquí no queremos ver todas las tareas activas, por tanto
en el campo Filtro seleccionamos Características. Ahora de pronto ha desaparecido todo, pero no
entres en pánico, solamente tenemos que activar la casilla de verificación que dice Mostrar
jerarquía. Ahora podemos ver el trabajo que tenemos para el Lanzamiento 1. Desde el 2 de enero
más o menos hasta prácticamente el 10 de febrero es cuando tenemos trabajo en marcha, y del 10
de febrero en adelante es cuando se supone que comenzará el Sprint 2. Pero aún no hay trabajo
agregado, y eso es por lo que estas líneas se ven en horizontal a partir de ese punto. Bien, voy a
cerrar este panel de la derecha para que no nos moleste, y a continuación queremos agregar un
gráfico para mostrar los puntos de características del "sprint". Para hacer espacio lo que voy a
hacer es eliminar este gráfico de la derecha, y para ello voy a hacer como un recuadro imaginario
alrededor de todo ello y, cuando ya está todo seleccionado, quitando ese cuadro de abajo suprimo
con el teclado. Y ahora voy a insertar otro gráfico. Desde la pestaña Diseño voy a hacer clic en el
botón Gráfico. El proyecto selecciona automáticamente el de columnas agrupadas, está bien, este
es el que necesito. Hago clic en Aceptar y ahora lo desplazo hacia el lugar adecuado. Aquí está
bien. Ahora tenemos que cambiar los campos de configuración. Los campos que necesito son
campos personalizados, así es que voy a empezar desplegando la parte que dice Número, pero
antes de que se me olvide voy a ir a la parte que dice Trabajo real. Permíteme que pliegue de
nuevo Número para desactivar ese campo, no lo necesitamos. Tampoco necesitaremos Trabajo
restante ni Trabajo. Ahora sí que podemos ocultar los detalles de Trabajo y sacar los detalles de
Número. Dentro de Número recuerda que queremos unos campos personalizados, así es que
tenemos que desplegar Campos personalizados y aquí, si nos desplazamos hacia abajo, veremos
que podemos activar Puntos de característica y Velocidad. Estos serán los puntos reales para el
"sprint". Y ahora, al igual que antes, tenemos que filtrar para que solo se muestren características.
Y aunque todo desaparezca, recuerda que si marcamos la opción Mostrar jerarquía vuelve a
aparecer. Lo que vamos a hacer ahora es agrupar el gráfico. Hace tiempo, no sé si recuerdas, que
creamos un grupo personalizado y que lo llamamos 'Lanzamiento y Sprint'. Ese es el que vamos a
elegir ahora, así es que donde dice Agrupar por vamos a seleccionar de la lista desplegable
Lanzamiento y Sprint. Y ahora estoy viéndolo para los números de lanzamiento, pero quiero verlos
para el "sprint", así es que el nivel del esquema lo tengo que cambiar. Voy a hacer clic en la lista
desplegable y voy a poner Nivel 2. Y ahora ya sí veo lo que necesito, es decir, cada uno de los
"sprint": el Sprint 1, el 2, el 3 y lo que no tengo asignado. Observa que en el número de Sprint 1
son siete puntos, tanto para los puntos de característica como para la velocidad. Eso se debe a que
movimos esa característica incompleta al Sprint 2, ¿recuerdas? Luego en el Sprint 2 tenemos
nueve puntos y tenemos una característica que movimos al Sprint 3. Y ya por último tenemos 25
puntos en la categoría en la que no tenemos nada asignado. Lo que vamos a hacer es ponerle una
etiqueta al gráfico, es decir, aquí, justo debajo del gráfico, que ponga 'Velocidad del Sprint' igual
que en el otro pone 'Evolución del trabajo', ¿lo ves? La forma más fácil de hacer esto sería coger
esta etiqueta, copiarla, por ejemplo, Ctrl + C y pegarla con Ctrl + V, después la desplazo al lugar
adecuado, escribo dentro del cuadro de texto lo que necesito, que es "Velocidad del Sprint",
hacemos clic fuera y bueno, así es como puedes personalizar un informe de gráfico integrado en
Microsoft Project para mostrar el desgaste del trabajo y la velocidad del "sprint".

Desafío: Modificación del calendario laboral

En este vídeo quiero proponerte un desafío, me gustaría que realizaras una práctica. Te voy a dar
las pautas para realizarla y después, posteriormente en otro vídeo, corregiremos y te daré la
solución o posibles soluciones a esta práctica. Pero primero, veamos lo que hay que hacer en la
práctica. Abre el archivo de proyecto que encontrarás en los ejercicios del curso, llamado
'DesafíoProyectosÁgiles.mpp'. A continuación, tendrás que modificar el calendario laboral de este
proyecto de modo que el sábado sea día lectivo desde las 8:00 hasta las 12:00 horas. Añadiremos
un día festivo al calendario, que será el 7 de enero. A continuación, crearemos un campo
personalizado, llamado 'Prioridad de la característica', que tenga como valores 'Alta', 'Media' y
'Baja'. Por lo tanto, tendrás que crear una tabla con esos valores dentro del campo personalizado.
Después, debes crear una nueva vista que tenga esta columna junto con el resto de las columnas
que ves en el diagrama de Gantt y que muestre las tareas de prioridad alta. Para eso tendrás que
poner un filtro. Llámala 'Vista de prioridad alta'. Por último, guarda todos los cambios en el
proyecto.

Solución: Modificación del calendario laboral

Veamos ahora la solución, o posibles soluciones, que podemos darle al desafío que te he
propuesto en otro vídeo. Primero, comencemos abriendo el archivo de proyecto
'DesafíoProyectosÁgiles.mpp'. Lo encontrarás en los archivos del curso. Lo seleccionamos y lo
abrimos. Nos encontramos en la vista Hoja de recursos, por tanto, voy a cambiarme a la vista
Diagrama de Gantt. Ahora tenemos que modificar el calendario laboral del proyecto de modo que
el sábado sea día lectivo de 8:00 a 12:00 a. m. Lo que vamos hacer es irnos a la pestaña Proyecto y
vamos a hacer clic en el botón Cambiar tiempo de trabajo. Aquí nos iremos a la pestaña Semanas
laborales y después haremos clic en Detalles y tendremos que establecer como día laborable el
sábado. Por tanto, marcaremos Establecer días en estos periodos laborables específicos y el
sábado lo pondremos de 8:00 a 12:00. A continuación, haremos clic en Aceptar. También nos
piden que incorporemos un día festivo feriado al calendario. Para eso, tenemos que ir a la pestaña
Excepciones, y aquí vamos a meter el 7 de enero como festivo. Podemos llamarle "Festivo" o
"Feriado 7 de enero". Como nuestro proyecto se desarrolla durante el año 2019 y comienza el 2 de
enero del 2019, vamos a establecer ese día, el 7 de enero del 2019, como el día feriado. Bien, ya
tenemos todo lo que nos han pedido. A continuación, hacemos clic en Aceptar. Aceptamos porque
tenemos recursos asignados y ahora el sábado afecta. Lo siguiente que nos pedían era crear un
campo personalizado llamado 'Prioridad de características'. Para crear un campo personalizado,
podemos ir a la pestaña Proyecto y después al botón Campo personalizado. Este campo es un
campo personalizado de texto que va a tener tres valores, así es que en el Tipo nos sirve el que
está seleccionado, Texto. Nos piden que añadamos a ese campo los valores 'Alta', 'Media' y 'Baja'.
Lo primero que vamos a hacer es cambiar el nombre del campo, se llama "Prioridad de la
característica". Hacemos clic en Aceptar y, a continuación, para crear la tabla, vamos al botón
Buscar y aquí vamos introduciendo los valores "Alta", "Media" y "Baja", y si quieres puedes poner
la descripción, "Prioridad Alta", "Prioridad Media" y "Prioridad baja". Ya lo tenemos, podemos
cerrar. Ningún cambio más en este campo, así es qué hacemos clic en Aceptar. Y ahora tenemos
que añadirlo. Nos pedían que lo añadiésemos delante de Duración, así es que seleccionamos este
campo, botón secundario del ratón, Insertar columna. Y aquí ponemos el nombre del campo,
Prioridad de la característica. A continuación, si te parece, vamos a poner algunas tareas como,
por ejemplo, de prioridad alta, porque ahora nos han pedido que hagamos un filtro y que
guardemos la vista con ese filtro. Por tanto, lo primero es tener algunas tareas de prioridad alta
para que el filtro funcione. Para aplicar el filtro, voy a ir a la pestaña Vista y, en la parte de Filtro,
voy a crear un nuevo filtro. Aquí voy a buscar el campo Prioridad de las características y le voy a
decir que es Igual a Alta. Y como nombre del filtro vamos a ponerle "Alta Prioridad". Aplicamos y
ya solo vemos esas características. Ahora tenemos que guardar la vista, que no se nos olvide.
Desde la pestaña Vista, en la cual nos encontramos, vamos al botón Diagrama de Gantt y elegimos
Guardar vista, y nos decían que lo llamásemos 'Vista de Prioridad Alta". A continuación, hacemos
clic en Aceptar. Y ya por último solo nos pedían guardar los cambios del proyecto, así es que
mismamente desde la barra de acceso rápido, hacemos clic en Guardar. Con esto ya hemos
terminado nuestra práctica, espero que te haya salido bien. Estoy segura de que sí.

Uso de herramientas ágiles e Project online de escritorio

Comprender las herramientas ágiles incorporadas en Project
En este vídeo quiero mostrarte las herramientas ágiles incorporadas en Project y que estarán
disponibles siempre y cuando hayas instalado Project Online, cliente de escritorio, en tu
ordenador. Esta versión de Project Online, cliente de escritorio, la obtienes con una suscripción a
Project Online Professional. Para asegurarte de qué versión tienes, lo mejor es que vayas a la
pestaña Archivo y luego hagas clic en la opción Cuenta. A la derecha, justo donde dice Información
del producto, debe decir 'Producto de suscripción, Microsoft Project Online Desktop Client'. Las
funciones ágiles solo están disponibles en el cliente de escritorio de Project Online. Por ejemplo, si
estás utilizando Project Online, cliente de escritorio, pero estás en un entorno de servidor de
proyecto local, no tendrás acceso a las herramientas ágiles. Para comprobar que tenemos esas
herramientas, permíteme que salga de aquí y vayamos a la pestaña Proyectos, y fíjate en que ahí
tengas el botón Agile. al hacer clic en él, se abre el cuadro de diálogo Metodología ágil, y podemos
seleccionar la metodología que necesitemos. Puede ser Scrum o Kanban. Ahora, en este caso, el
proyecto que tengo en pantalla lo tengo configurado como Scrum y, como puedes observar, tengo
en pantalla una vista especial, y esta vista me muestra los paneles de tareas. Ahora mismo estoy
viendo la planificación del "sprint". Por ejemplo, en la cinta de opciones, si hago clic en la pestaña
Scrum, puedo hacer clic en el botón primero que encontramos, Planificación, y puedo cambiarme
entre la Hoja de planificación del sprint y el Panel de planificación del sprint, que es donde me
encontraba actualmente. Cuando cambio a la Hoja de planificación del sprint, veo que aparece una
tabla, y es muy similar a la tabla que aparece en el gráfico de Gantt, pero si nos fijamos más
detenidamente, podemos ver que hay campos especializados específicamente para trabajar con
un proyecto de metodología Scrum. En este caso, hay un campo Sprint para que pueda asignar
tareas a los "sprints" –también podríamos especificar el estado del tablero– y un campo Agile para
especificar si queremos ver una tarea en el tablero o no. Si no quieres ver alguna tarea en el panel,
por ejemplo algunas de tus tareas en cascada que estén al comienzo del proyecto, simplemente
tienes que cambiar el valor a No. Finalmente, hay algunos informes incorporados. Si nos vamos a
la pestaña Informe, a la derecha también verás un botón Agile, y aquí podemos seleccionar uno de
los informes integrados como, por ejemplo, el estado del "sprint", el estado de la tarea o el estado
del trabajo. En este vídeo ya te he hecho una introducción rápida al uso de las herramientas
incorporadas en Project para usar en nuestros proyectos ágiles.

Configuración ágil en un proyecto

Con Project Online, cliente de escritorio, podemos crear un proyecto ágil desde cero o agregar las
herramientas ágiles a un proyecto existente. Para crear un nuevo proyecto, iremos a la pestaña
Archivo y luego haremos clic en Nuevo. En la opción Nuevo, hay dos tipos de archivos que
podemos crear para utilizar metodologías ágiles: los proyectos de Scrum y los proyectos de
Kanban. En este caso, vamos a seleccionar uno de tipo Scrum. Esto crea un nuevo archivo de
proyecto en blanco. Puedes ver en la parte superior como se llama 'Proyecto 1' en este caso, o
'Proyecto X', dependiendo del número de veces que hayas utilizado ese botón de proyecto nuevo
de Scrum, siempre que estés trabajando en la misma sesión. Además, podemos ver el panel Sprint,
que está listo para comenzar a añadir tareas. Para acceder a las herramientas de Scrum solo
tenemos que ir a la cinta de opciones y hacer clic en la pestaña Scrum, y aquí vemos todo el grupo
de herramientas que tenemos para trabajar con proyectos ágiles de este tipo. Por supuesto, si
tienes ya un proyecto creado y quieres aplicarle una metodología ágil, no hay ningún problema, lo
único que tienes que hacer es ir a la pestaña Proyecto y hacer clic en el botón Agile, y esto te
sacará un cuadro de diálogo que te permitirá seleccionar qué tipo de metodología "agile" quieres,
o ágil. Puedes elegir entre Scrum o Kanban. Entonces digamos, por ejemplo, en esta ocasión, que
queremos crear un proyecto Kanban. Elijo esa acción y hago clic en Aceptar. Aparece entonces la
pestaña Kanban y, como puedes ver, es más simple que la Scrum. Permíteme que te muestre
algunas diferencias importantes. Scrum es más restrictivo y tiene más reglas que debes seguir, a
diferencia de Kanban, que es más adaptativo y te va a dejar más libertad para actuar. Podríamos
decir que la metodología Scrum busca establecer un marco de trabajo adaptable a las tareas que
deben de ser realizadas en un periodo entre una y cuatro semanas de trabajo intensivo. En
cambio, Kanban es un concepto de organización de trabajo parecido a Scrum, pero más flexible.
Esta metodología acepta la posibilidad de replantearse las prioridades de trabajo a medida que las
necesidades del momento cambian. Ambas son metodologías de trabajo ágiles y, por lo tanto,
parten de unos criterios comunes. De hecho, tienen más semejanzas que diferencias. Y ahora te
estarás preguntando: "¿Kanban o Scrum? ¿Qué metodología de trabajo es mejor?". Esta pregunta
no puedo respondértela fácilmente, porque cada una encajará mejor en un tipo de proyecto y con
las características concretas de cada equipo de trabajo. El flujo de trabajo de Scrum se centra en
intervalos de trabajo en los que las tareas deben progresar de manera constante. Kanban coincide
el trabajo en base a ítems individuales, que pueden agregarse o eliminarse de cada fase del
proyecto, según las necesidades en cada momento. Precisamente por esto y para evitar desfases
entre los diversos miembros del equipo, requiere de una monitorización de todo el proceso. Si
habías decidido utilizar una metodología ágil, pero ves que no es lo que necesitas, mo te
preocupes, porque puedes desactivarla o cambiar la metodología. Solamente tienes que ir a la
pestaña Proyecto y hacer clic en el botón Agile, y fíjate en que aquí hay una opción que pone
Ninguno. Con esta opción puedes desactivarla o puedes cambiarla, por ejemplo en este caso, que
es Kanban, por Scrum. Y piensa que aunque cambies la metodología, de momento algunas
opciones desaparecerán de la pantalla, pero todos los datos ágiles que hayas agregado al proyecto
permanecerán en el archivo, no perderás nada. Bueno, ahora espero que ya tengas un poco más
claro el concepto de herramientas ágiles, de cómo seleccionar un proyecto nuevo con esas
herramientas incorporadas o cómo agregarlas a un proyecto existente. También cómo
desactivarlas en el caso de que sea necesario.

Añadir tareas a la lista de trabajo pendientes

Uses Scrum o Kanban, básicamente lo que tienes que hacer es crear una lista de trabajos a realizar
y colocar las tareas por prioridad según las necesidades que tengas a la hora de completar el
proyecto. Esto se llama trabajos pendientes, o en inglés el "backlog". Vamos a crear un proyecto
usando Scrum. Acabo de abrir Project y, desde la opción de Nuevo, voy a hacer clic en el botón
Proyecto de Scrum. Al crear un proyecto de Scrum nuevo, lo primero que vemos es el panel de
planificación de los "sprints". Si por el motivo que sea no ves la misma vista que yo en pantalla, ve
a la pestaña de Scrum y, en el botón Planificación, selecciona Panel de planificación de sprints.
Ahora seguro que ya estás en la misma vista que yo. Actualmente no tenemos tareas. Debajo del
encabezado que dice No hay ningún sprint, hay un cuadro que dice Nueva tarea. Para crear una
nueva tarea, simplemente haz clic aquí y se abrirá este cuadro, donde podemos escribir el nombre
de la tarea. Por ejemplo, escribo "Capturar información del cliente", presiono Enter y ya está
creada la tarea. Para agregar otra tarea, vuelvo otra vez arriba y escribo "Validar dirección". Fíjate
en que también puedo hacer clic en el botón Agregar, pero es mucho más rápido presionar Enter
y, a continuación, "Validar dirección email". También podríamos haber añadido las tareas usando
la Hoja de planificación del sprint. Para ello, desde la pestaña Scrum, en el botón Planificación,
cambiamos a la Hoja de planificación del sprint, esta que recuerda que decíamos que se parece un
poco a la tabla de entrada del diagrama de Gantt. Y para agregar tareas en esta tabla, pues lo
haríamos como haríamos en cualquier otra tabla, simplemente nos situamos en el nombre de la
tarea y empezamos a escribir esa tarea. Por ejemplo, "Capturar la información de facturación del
cliente", "Validar la información de facturación" y, por último, "Grabar producto en el carrito de la
compra". Ahora veamos rápidamente cómo añadir tareas cuando seleccionamos un proyecto
Kanban. Para ello, me voy a Archivo, voy otra vez a Nuevo y, en este caso, selecciono Proyecto de
Kanban. Y ahora, desde la cinta de opciones, me cambio a Kanban para poder ver las herramientas
ágiles para este tipo de proyectos. Voy a agregar algunas tareas. En este caso, vamos a hacerlo con
nombres genéricos para ir más rápido. Hacemos clic donde dice Nueva tarea y ponemos "Tarea
pendiente 1", "Tarea pendiente 2" y ·Tarea pendiente 3·. Si quisiéramos verlo en forma de tabla,
pues aquí en la pestaña Kanban vamos a hacer clic en el botón Trabajo pendiente, y aquí
cambiamos a la Hoja de trabajo pendiente. Y con esta explicación yo creo que ya sabes cómo
agregar tareas tanto a un proyecto de tipo Scrum como a un proyecto de tipo Kanban.

Asignar tareas a sprints en un proyecto Scrum

antes de asignar tareas a los "sprints", debemos definir la longitud del "sprint" de nuestro
proyecto y cuándo comienzan los "sprints". después de esto, asignar tareas a los "sprint" es algo
muy fácil. Para especificar la longitud del "sprint" y cuándo comienzan, vamos a ir a la pestaña de
Scrum y, dentro de la pestaña Scrum, haremos clic en el botón Administrar. Como podemos ver
aquí, por defecto tenemos tres configuraciones de "sprints". Como nuestro proyecto hemos
establecido que comienza el 7 de enero, el primer "sprint" comienza en esa fecha. La fecha de
inicio del proyecto ya la establecimos anteriormente en la información del proyecto. Por defecto,
Project establece la duración de los "sprints" en dos semanas, pero en nuestro proyecto vamos a
trabajar con una duración de "sprints" de tres semanas, por lo que tenemos que cambiar esta
longitud duración del "sprint". Así es que vamos a poner tres. Ya lo tenemos, todos están
cambiados a tres semanas. Hacemos clic en Aceptar y, a continuación, vamos a asignar tareas a los
"sprints", y es tan simple como arrastrarlas y soltarlas. Por ejemplo, digamos que quiero mover la
tarea 'Capturar la información de contacto del cliente'. Esta la quiero poner en el Sprint 1, pues
solo hay que arrastrarla y soltarla en ese "sprint". Por otro lado, la tarea Captura de información
de facturación del cliente la quiero colocar en el Sprint 2. Pues igual, selecciono la tarea, la arrastro
y la coloco en el Sprint 2, justo debajo. Y finalmente, la tarea Grabar productos en el carrito de la
compra la voy a asignar al Sprint 3. Del mismo modo, la selecciono y la arrastro. Otra cosa que me
gustaría señalar es que se puede hacer doble clic en las áreas situadas debajo de cada "sprint"
para abrir el cuadro de diálogo Información de la tarea. Es el mismo que vemos cuando hacemos
doble clic en una tarea dentro de la vista Diagrama de Gantt. Voy a hacer clic en Cancelar el cuadro
de diálogo, pero quería que lo supieras. Ahora voy a cambiar de vista, voy a ir a la vista de Hoja de
planeación del sprint. Para ello, voy a hacer clic, dentro de la pestaña Scrum, en el botón
Planificación, y cambio a la Hoja de planificación del sprint. Y esta recuerda que era una vista
similar a la que teníamos en la tabla de entrada del diagrama de Gantt, pero aquí había algunas
columnas que eran diferentes, por ejemplo, la columna Sprint, y esa columna va a servirme para
que desde esta vista yo pueda asignar las tareas o características a los distintos "sprints". Por
ejemplo, la tarea Validar dirección quiero asignarla al Sprint 1, pues es tan sencillo como
seleccionar en esa columna la lista desplegable y elegir Sprint 1. Haré lo mismo para Validar
dirección de correo electrónico, también Sprint 1. Finalmente, la tarea Validar la información de
facturación la asignaré al Sprint 2. Así de sencillo es asignar tareas a "sprints" en un proyecto de
Scrum.

Registrar el progreso de las tareas para Kanban y Scrum

Las herramientas para Scrum y Kanban incluyen un conjunto integrado de características para
registrar el progreso, como el trabajo pendiente, lo que haremos próximamente, el trabajo en
curso o el trabajo terminado. A medida que las tareas se mueven a través de su flujo de trabajo,
todo lo que tenemos que hacer es moverlas a las categorías apropiadas. Tengo en pantalla un
proyecto Kanban. Kanban no tiene "sprints", por lo que el tablero muestra el progreso a través del
flujo de trabajo. Comienza con cuatro columnas: la columna Trabajo pendiente, después la
columna Próximamente, la columna En curso y la columna Listo. Si necesitásemos agregar una
columna adicional, haremos clic donde dice Agregar columna nueva y escribiremos aquí el nombre
de la columna. Voy a añadir una columna llamada "Pruebas". Cuando presiono Enter, ahora tengo
una columna adicional. También podemos cambiar el nombre de cualquiera de las columnas que
aparecen por defecto. Para hacerlo, puedo hacer clic con el botón secundario del ratón justo
encima del nombre de esa columna y seleccionar la opción Cambiar nombre. Esto hace que el
nombre, como puedes observar, sea editable, y ahora lo único que tengo que hacer es borrar este
nombre, escribir el nuevo y presionar Enter. Ahora no voy a cambiar el nombre, pero lo
importante es que ahora sabes cómo hacerlo. A continuación, voy a crear una nueva tarea en la
columna de Trabajo pendiente. Voy a hacer clic en Nueva tarea y voy a crear la Tarea pendiente 4.
presionamos Enter y ya la tenemos. Ahora imagínate que la Tarea pendiente 1 está en curso. Solo
tengo que seleccionarla y arrastrar y soltar la debajo de ese título, es decir, en esa columna. A
continuación voy a arrasar las tareas 2 y 3 a Próximamente, y así estamos registrando el progreso
de las tareas. Ahora voy a cambiar de proyecto para enseñarte cómo registrar el progreso para las
tareas en un proyecto Scrum. Voy a ir a Archivo, voy a hacer clic en Abrir, a continuación en
Examinar, y voy a seleccionar este otro archivo. Haremos clic en Abrir. Veo los tres "sprints" con
sus tareas asignadas, pero para registrar el progreso queremos cambiar la vista, así es que vamos a
ir a la pestaña Vista y aquí voy a hacer clic en el botón Panel de tareas y, a continuación, elijo Panel
de tareas. Ahora voy a ir a poner un filtro. En concreto, haré clic en el botón de Filtro y
seleccionaré Seleccionar Sprint, y aquí elegiré el Sprint 1. Hago clic en Aceptar y esto cambia la
vista. Ahora se parece mucho más al panel de Kanban, solo se muestra el Sprint 1. Ahora las tareas
se encuentran en la columna de Trabajo pendiente. Para cambiar el progreso, solo tenemos que
arrastrarlas a su estado correspondiente. Voy a ir arrastrando. Imaginemos que la tarea Capturar
información del cliente ya está completada, así es que voy arrastrarla a Listo, y ahora podemos
mover Validar dirección a En curso, y Validar dirección de correo electrónico a Próximamente.
Vayamos a la cinta de opciones y a la pestaña Scrum, y elegimos la vista Hoja de planificación de
sprint. Observa ahora como la tarea que está en curso aparece en la casilla Estado del tablero, al
igual que la que está en Próximamente. Las tareas asignadas a otros "sprints" todavía están
configuradas como no iniciadas, y así es como puedes registrar el progreso para las tareas usando
las dos vistas: Panel de planeación de sprints y Hoja de planeación de sprints.

Mostrar las tareas ágiles en un proyecto híbrido

Si tienes un proyecto con una combinación de tareas en cascada y otras ágiles, puedes decirle a
Project cómo deseas ver las tareas y qué tareas mostrar en las vistas ágiles. En este momento
estamos viendo en pantalla un proyecto con la vista Diagrama de Gantt. Si, en cambio, deseas ver
las tareas que tienes en una vista de panel de tareas, puedes ir a la pestaña Vista y en el botón
Panel de tareas seleccionar Panel de tareas, pero el problema es que si tu proyecto incluye tareas
en cascada y tareas ágiles, lo que probablemente quieras hacer es concentrarte en las tareas que
están asignadas a "sprints". Para hacer esto, vamos a ir a la pestaña Scrum, y luego haré clic en el
botón Planificación y seleccionaré la Hoja de planificación de sprints. En esta hoja tenemos una
columna que dice Agile y, que como ya sabes, sirve para indicar qué tareas son ágiles y cuáles no.
Por defecto, Microsoft Project pone todas las tareas como ágiles, pero para nosotros esto no es
así, así es que desde la primera tarea hasta la tarea 18 voy a cambiarlo. Para ello, cambio la
primera, pongo No y arrastro hasta la tarea número 18. Voy a desplazarme ahora un poco hacia
abajo por el proyecto para llegar hasta la tarea número 73, y esa tarea tampoco va a ser ágil, así es
que voy a poner No y después voy a arrastrar hasta el final. Ahora veamos qué sucede cuando
regresamos a la vista de planificación de "sprints". Volvemos al botón de Planificación y
seleccionamos la opción Panel de planeación de sprints. Ahora podemos ver que tengo tareas
asignadas a los "sprints" 1, 2 y 3. Si hubiera algún elemento pendiente restante, aparecería debajo
de donde dice No Sprint, pero no hay ninguno. Otra cosa que debes tener en cuenta es que
cuando tienes recursos asignados a tus tareas puedes verlos en esta vista. Están debajo del
nombre de la tarea. Fíjate, los ves, ¿verdad? Digamos que ahora deseas centrarte en el "sprint"
actual. Recuerda que nuestro proyecto todavía no ha comenzado, está planeado para un futuro,
pero quiero mostrarte dónde haríamos esto. Si necesitáramos ver el "sprint" actual, iríamos
dentro de la pestaña Scrum al botón de Sprint, y desde aquí podríamos elegir el panel del "sprint"
actual. Como ya te he comentado, nuestro proyecto se desarrolla en el futuro, por tanto no
tenemos ningún "sprint" actual, pero lo importante de esto es que ahora ya sabes cómo hacerlo,
es decir, cómo verías el "sprint" actual, es decir, el progreso que llevaría ese "sprint" según la
fecha de hoy. Por tanto, de este modo que te he explicado es como le indicas a Project qué tareas
deseas ver en las vistas ágiles y cómo ver las tareas en los "sprints".

Visión general de informes ágiles incorporados en project

Project Online de escritorio incluye varios informes ágiles incorporados que muestran el estado de
los "sprints", las tareas y el trabajo. Para acceder a esos informes, iremos a la pestaña Informe y, a
la derecha, haremos clic en el botón Agile. Seleccionaremos el informe Estado de la tarea, que nos
muestra el tanto por ciento del estado de las tareas en un gráfico circular: las que están ya
realizadas, las que están en curso, las próximas y las que aún no se han iniciado. La tabla que
vemos a la derecha muestra las que no se han completado al 100 %. Regresemos a la pestaña
Informe y volvamos a hacer clic en el botón Agile. Esta vez voy a elegir el informe Estado de sprint.
Este informe muestra las tareas y el trabajo por "sprint" junto con el progreso. Por ejemplo, la
parte azul muestra el trabajo restante y, si tuviéramos ya trabajo realizado, aparecería una parte
naranja que mostraría el trabajo real. También puedes ver un informe de trabajo. Vuelvo a la
pestaña Informe y al botón Agile, y aquí también tenemos el informe de trabajo, tanto con el
trabajo realizado como con el trabajo restante. Estos son informes gráficos, por lo que puedes
personalizarlos o crear los tuyos propios. Estas son solo algunos ejemplos de informes
"agile"incorporados, que vienen con Project Online, cliente de escritorio.

Comparación de herramientas ágiles

Introducción
En este curso desarrollaremos la capacidad de evaluar las diferentes herramientas ágiles para
tomar una decisión sobre cuál aplicación se adapta mejor a nuestro entorno laboral. Esto lo
lograremos conociendo cómo se trabaja en cada herramienta de manera ágil, realizando las
mismas actividades de Scrum en cada una de ellas. De esta manera podrás tomar la decisión sobre
cuáles ventajas se adhieren mejor a tu entorno profesional. A su vez, conocerás las desventajas
sobre las cuales podrías descartar una vez conozcas las funcionalidades importantes de una
herramienta y de otra. Finalmente, estarás en capacidad de explorar en el mundo de gestión de
proyectos cuáles son simples y aquellas funcionalidades especiales que algunas de estas
herramientas potencializan para diferentes tipos de industria.

Factores clave al tomar en cuenta en la decisión sobre la herramienta a utilizar

Potencia los principios ágiles eligiendo una herramienta de manejo de proyectos idónea
Vamos a iniciar este curso identificando cuáles son los factores clave que necesita tu proyecto para
tener un inicio y un fin exitoso, que se traducen en mejorar la comunicación interna del equipo y
los productos de utilidad para el cliente a quien va dirigido.

Como puedes ver en el siguiente gráfico, las habilidades blandas juegan un rol en el desempeño de
los proyectos exitosos y es por esto que vamos a trabajar para identificar la herramienta que
mejor se adapte a los objetivos de la empresa o al proyecto que tenemos asignado de manera ágil.
Además, el objetivo de la herramienta es contribuir al logro de las prácticas que refuerzan el
pensamiento ágil dentro del equipo.
Como ya tenemos identificado el problema, primero debes reconocer qué elementos son
importantes con tu equipo. Por ejemplo, en tu empresa das mucha importancia al trabajo en
equipo, a la calidad de los entregables, a la disponibilidad de información en línea, en general, a
trabajar con innovación y dinamismo, siendo abiertos a la ambigüedad. En ese sentido, debes
preguntarte qué herramienta te ayudará a adoptar ágil, de manera sencilla en caso que estés
iniciando. Por otro lado, si tienes la metodología ágil dentro de la empresa, vamos a evaluar cuál
herramienta conecta más con la organización. También debes tener en cuenta que "ágil" significa
un proceso de continuo aprendizaje y mejora en el cual generamos por cada entregable en un
"sprint", es decir, vamos a generar pequeños experimentos que generen valor y que ayuden a
obtener visibilidad en todo momento del proyecto. Por esto es importante tomar en cuenta la
cantidad de personas que van a utilizar la herramienta, qué tan digerible es la herramienta para
una persona que nunca ha trabajado sobre ella, qué métodos ágiles utiliza tu empresa y cómo se
puede generar un acoplamiento, dado que la mayoría de las herramientas tienen un tablero
Kanban con las actividades de por hacer, en proceso y realizada. Por esto es importante que
conozcamos las bondades y oportunidades de mejora de cada una de las herramientas a tratar
antes de decidirnos por la primera que aparezca en un anuncio publicitario, que suelen ser muy
atractivas a simple vista.

En la cultura ágil de manejo de proyectos debemos enfocarnos en la entrega continua de

pequeños entregables con usabilidad, es decir, cuando un cliente utiliza el producto significa que
está siendo exitoso. La comunicación y trabajo en equipo, lo cual es fundamental para que cada
quien aporte sus conocimientos y mejore sobre la marcha. Adaptación al cambio, que permite a
través de la revisión continua del alcance mediante las ceremonias de planeación, es decir, vamos
adaptándonos continuamente a medida que vayamos avanzando. Colaboración con el cliente
significa asumir una actitud, ganar-ganar. Es por esto que la herramienta ideal debe ser sencilla y
ayudarte a manejar un flujo de trabajo flexible y una comunicación efectiva del equipo.

Es importante recordar sobre estudios documentados, sobre causas que pueden implicar que un
proyecto fracase. Sin un orden o peso en particular, podemos comentar sobre la falta de apoyo de
los altos ejecutivos, herramientas y tecnología inadecuada, resistencia al cambio, cultura
organizacional muy rígida y poco flexible y pobre definición del alcance. Es por esto que,
dependiendo del tamaño de tu empresa, debes prestar mucha atención a los hitos positivos, así
como también a los riesgos que tienen más probabilidades de presentarse. A su vez, debes
conocer que Scrum es el método más común que la mayoría de las herramientas implementan en
su modelo de trabajo, ya que es un flujo genérico que envuelve incrementos del producto de
manera iterativa y donde vamos a realizar actividades de planeación, ejecución, entrega y
lecciones aprendidas a través de la retrospectiva. Es decir, es como una versión compacta, ligera y
simple de manejar proyectos de manera ágil.

Identifica los puntos esenciales de éxito en la organización al seleccionar la herramienta

Muchas empresas tienen muy bien definido qué características van a ser el factor diferenciador de
su producto. Por ejemplo, algunos se enfocarán en ser eficientes, en la calidad del producto, en
disminuir los costos de la materia prima o los costos operativos, o en la productividad y
satisfacción del cliente.
 En este punto, nuestro trabajo es enlazar esas características con la herramienta ágil que sirva de
ensamble entre esas características y la del producto. Las preguntas que usualmente nos debemos
plantear son: ¿Cómo escalaremos ágilmente en un futuro con esta herramienta? ¿Qué tan fácil es
trabajar en múltiples proyectos? ¿Qué tan importante es la gobernanza de los proyectos para
nuestra empresa? ¿Qué tan simple es la administración? ¿Qué tan sencillo puedo lograr que el
equipo adopte la herramienta en su día a día de trabajo? ¿Qué posibilidades tengo de visualizar y
accionar sobre los obstáculos? Una vez obteniendo mayor claridad sobre estas preguntas,
podemos dirigirnos a cómo organizar el proyecto de manera ágil siguiendo el ciclo de vida del
mismo. En ese sentido, existen muchas herramientas que conjugan los niveles de planeación que
en el proceso de manejo ágil de proyecto podemos plasmar el alcance. Es decir, con estas
herramientas podemos documentar y plasmar la información de cara al ciclo de vida de ágil como
son el "roadmap" de producto o la visión, la planeación de los entregables o "release planning", la
planeación de los "sprint" o iteraciones y los "daily meeting". Es por esto que al ejecutar las
ceremonias religiosamente podemos practicar con el ejemplo los valores fundamentales de ágil
con una herramienta facilitadora del trabajo sobre una documentación exhaustiva. A su vez, ser
abiertos al cambio, porque el objetivo de estas planeaciones es revisar continuamente el alcance y
aterrizar el producto deseado a lo ideado en un principio por el cliente, evitando enfocarnos en
minuciosa y extremadamente detalladas sesiones o fases de diseño y alcance que generan
montañas de información y que usualmente para proyectos de gran tamaño podrían tomarse
hasta meses sin iniciar una fase de ejecución. Por esto, mediante la inspección y adaptación de las
pruebas de hipótesis sobre el producto podemos de manera eventual contribuir a la mejora
continua del producto final. Siguiendo la misma línea de ideas, vale la pena resaltar que la
herramienta simple que permita un flujo eficaz de trabajo significa que va a carecer de actividades
que representen un desperdicio.

Recordemos un poco sobre las ceremonias Scrum dentro del ciclo de vida ágil del proyecto que
vamos a recorrer cada vez que iniciemos un "sprint" y podemos visualizar en la herramienta a
seleccionar. Estos son los "daily meeting" o "stand-up meeting", el "grooming" o cómo nosotros
desglosamos cada una de las historias para convertirla en tareas o actividades, la planeación del
"sprint" y la revisión del "sprint", y finalmente la retrospectiva, que es donde todo el equipo
comenta sobre qué aprendió y qué va a hacer para mejorar.

Conoce los diferentes paquetes que ofrece el mercado.

Es sumamente necesario educarnos como usuarios sobre las características comunes que ofrecen
las diferentes plataformas y sobre cuáles de estos atributos podemos tomar una decisión
prudente sobre qué herramienta se ajusta a las posibilidades y visión del proyecto o empresa.

Las características tecnológicas esenciales al momento de elegir una herramienta sobre las cuales
vamos a conversar son:

- licenciamiento, que este va a ser el costo que representa utilizar la herramienta por un
número determinado de usuarios. Además, se agrega el tipo de licenciamiento, que viene
siendo si la aplicación reside en la nube o si será necesario realizar instalaciones en la
infraestructura local de tu empresa. Vamos a concentrarnos en las herramientas en la
nube por su comodidad y conveniencia para cualquier empresa.
 - Radiadores de información. Significa qué tan robusta o cuál es la gama de reportería en
general que va a ofrecer la herramienta. Por ejemplo, ofrece gráfico de quemado,
velocidad, gráfico de tareas pendientes, cuadro de Gantt, entre otros. Con la reportería
podrás observar los avances reales y en línea del proyecto a través de gráficos de
información visual, que a simple vista puedes conocer la salud general del proyecto.
También debemos evaluar una herramienta que dé cabida a la estimación del esfuerzo y a
la descomposición del esfuerzo en épicas, historias y tareas.
- Desde el punto de vista de gobernanza de proyectos, qué capacidad de tener la visión
desde más alto nivel hasta su más diminuto nivel puede ser una tarea que agrega mucho
valor a la gestión de proyectos en una organización corporativa. En ese sentido, si la
herramienta ofrece este desglose desde una iniciativa de negocio o estrategia de negocio,
concede a los ejecutivos un sueño hecho realidad desde el punto de vista de gobierno
corporativo.
- Dentro de la comunicación debemos conocer qué puede ofrecer la herramienta para
generar un flujo de información bidireccional con todo el equipo. Por ejemplo, la
herramienta está en capacidad de realizar menciones, de generar alertas, de ver el
historial de cambios o actividad dentro de la historia por los miembros del equipo o
agregar nuevos campos al formulario para enriquecer las historias, entre otros.
- Cada herramienta debe permitirnos repetir el ciclo de mejora continua con el cual se
agregan nuevas historias al "product backlog" y se desestiman aquellas que dejan de
aportar valor.

La herramienta debe ofrecer capacidad de integración con otras plataformas. En la actualidad, la

mayoría de las herramientas ofrecen integración con otras aplicaciones que contribuyen a mejorar
la productividad y a realizar el trabajo más ameno y de sobremanera muy digital. Por ejemplo,
integrarse con herramientas de videoconferencia, herramientas de mensajería instantánea, entre
otras. A partir de estas consideraciones debemos evaluar qué grado de importancia colocamos a
cada característica y de esta manera estaremos seleccionando conscientemente basado en
atributos medibles y comparables entre una herramienta y otra. Es por esto que vamos a
experimentar de manera práctica las funcionalidades y beneficios que traen consigo cada una de
las herramientas.

Excel
Trazabilidad de ceremonias Scrum en Excel
Vamos a iniciar este curso con Excel porque esta herramienta es como un punto de partida para
aquellas personas que desconocen aplicaciones, herramientas o formas de trabajo que ayuden
con la productividad cuando se están iniciando en el mundo de manejo de proyectos de manera
ágil.

Usualmente, cuando llevas un tiempo trabajando de manera ágil, con una pizarra, por ejemplo, te
preguntas ¿cómo puedo iniciar a documentar ese proceso?, ¿cómo puedo sacar información del
proyecto y utilizar esa información para mostrar los avances a un cliente o un ejecutivo que
necesita conocer sobre ese progreso? Como puedes ver en la pantalla y de acuerdo a tu
preferencia, podemos utilizar una hoja de cálculo para cada ceremonia de Scrum y guardar las
historias, iniciativas y versiones de esa manera. Aquí puedes tener a mano un avance de manera
digital. En el siguiente Excel puedes ver una hoja que corresponde a las iniciativas donde vamos a
colocar los proyectos de negocio y cómo puedo tener el objetivo de negocio dividido en iniciativa y
luego en proyectos.

Luego tenemos la hoja del "product backlog". Pasamos a la hoja de "burndown chart" o gráfico de
quemados. Tenemos la hoja de "review" o revisión, retrospectiva e impedimentos.

A su vez, es importante resaltar que si estás iniciando como un piloto de transformación ágil o
digital y quieres hacer una prueba de concepto o simplemente no te has decidido por qué
herramienta utilizar, Excel puede ser tu gran aliado, ya que puedes ir ajustando la dirección de
acuerdo como gradualmente vayas sintonizando tu equipo y tú con la metodología ágil. Dentro de
los beneficios que tiene Excel es que es intuitiva en cierto grado debido a que muchas personas,
por más simple que sea, puede entender Excel. En ese sentido, la desventaja que tiene Excel es
precisamente ese trabajo manual y que tienes que duplicar cada vez que creas un "sprint" o tienes
que agregar nuevas historias. También, si muchas personas trabajan sobre el Excel, se corre el
riesgo de perder la información, ya que a muchas personas les gusta realizar ajustes o crear
nuevas versiones del mismo documento. Otro caso es que si Excel tiene macros o utilizas macros
dentro del Excel, dependiendo de la naturaleza de la empresa pueden existir ciertas restricciones
de este tipo. Además, si te gustaría llevar el Excel a un nivel de personalización profesional,
también vas a necesitar especialización en cierta manera sobre cómo utilizar el Excel de manera
avanzada para tu proyecto. Vale la pena mencionar que vas a necesitar personas dedicadas a darle
entrada a la información al Excel o eliminar información sobre los "sprint", que puede ser el dueño
del producto o el "Scrum master", mientras el equipo se mantiene en su día a día de trabajo.

Alimentando el “Product backlog” y observando los indicadores en Excel

Iniciamos comentando sobre la hoja de Excel que tiene el objetivo principal de negocio, que es ser
el número uno en ventas. Luego continuamos con las iniciativas, que son ampliar la gama de
productos y reducir los costos, y esas iniciativas están asociadas a su proyecto. En primer lugar,
tenemos que producir pasteles, es el principal proceso operativo de nuestro negocio, y los demás
proyectos que a su vez van a contribuir en el posicionamiento en el primer lugar en ventas.

Vamos a pasar al "product backlog" o listado de historias de usuario. Podemos ver que tenemos
las columnas, las cuales pueden agregar o remover de acuerdo a su conveniencia, pero en esta
ocasión utilizaremos las más relevantes en el mundo ágil. Tenemos Número de historia, que es
igual al código autogenerado más el código del proyecto. Épica, la épica es una historia que
inicialmente nos comentó un cliente o usuario y a medida que realizamos las ceremonias de
planeación o "grooming" realizamos preguntas con el equipo y observamos que la misma está a
muy alto nivel y a su vez necesita ser desglosada en más de una historia de usuario. Podemos
observar que tenemos dos épicas en esta hoja y que a su vez se derivan en varias historias de
usuario. Continuamos con Historia. Es la historia la que concentra el objetivo, una funcionalidad o
un entregable. En fin, va a tener un uso y un fin práctico. Continuamos con Criterio de aceptación.
Esta columna representa las condiciones que tiene que cumplir la historia cuando un "tester" o
una persona que tenga un rol de control de calidad en el equipo realiza pruebas sobre la historia, y
la misma tiene que satisfacer todos esos requisitos. Podemos ver unos cuantos ejemplos de
criterio de aceptación que básicamente son condiciones que deben cumplir los pasteles de la
historia. Prioridad. Es el grado de importancia que tiene la historia. Puntuación. La puntuación es
el grado de complejidad para lograr que la historia sea realizable. Usualmente se coloca una
puntuación en base a la numeración Fibonacci, pero se puede utilizar otra medida. Por ejemplo,
los tamaños de las camisetas, como son "small", "medium", "large", "x-large". Todo va a depender
como más a gusto se sienta el equipo. Estado es el estado como se encuentra la historia. Fecha de
completado es la fecha de conclusión de la historia. "Sprint" es el número de "sprint" en el cual se
va a trabajar la historia de usuario. En nuestro caso hemos distribuido nuestro listado de historia
en tres "sprint". Y he asignado que es el colaborador del equipo que va a trabajar con la historia.
Una vez personalices la hoja correspondiente al "product backlog", puedes agregar historias o
crear historias fácilmente. Con este "product backlog" o listado de historias tenemos varias
opciones para manejar los "sprint". Primero, podemos crear una hoja con las historias de cada
"sprint" por separado o, segundo, administrar el listado de historias en la misma hoja y aplicar los
filtros a conveniencia cada vez que necesitemos utilizar o buscar información más detallada. De
esta manera. Este es un "product backlog" relativamente pequeño y con el tiempo continuará
creciendo, ya que es un documento que tiene vida durante el transcurso de todo el proyecto y la
mejora continua del mismo. En lo particular, cuando trabajo en Excel prefiero tener el "backlog"
de esta manera y manejar los "sprint" y "burndown chart" por separado.
Consejos y trucos en Excel para el seguimiento de los proyectos
Vamos a continuar mostrando el gráfico de "burndown chart". Como puedes ver, el "burndown
chart" o gráfico de quemado representa de manera visual el avance de las historias tomando en
cuenta la cantidad de puntos comprometidos en el "sprint" o el esfuerzo que el equipo estimó
podía hacer en dos semanas. Recuerda que el plazo del "sprint" lo define el equipo y en este caso
decidimos que un "sprint" son dos semanas, pero este puede ser de una semana y
preferiblemente como máximo cuatro semanas o un mes. En el "sprint" 1 tenemos que nos
comprometimos a 101 puntos. Esto lo comprobamos sumando la puntuación que tenemos en las
historias. En el gráfico tenemos el avance ideal, que es una línea recta. Ese es el mundo ideal, pero
el mundo de proyectos, como saben, es muy complejo. Luego tenemos la línea azul y, como
puedes ver, esta varía con el tiempo. También puedes notar que un día nuestro equipo puede ser
sumamente productivo y en el otro carecemos de avances. El o la "Scrum master" deben estar
muy pendiente a esto, ya que puede existir un impedimento en el cual podría colaborar a
desenmarañar. En la línea horizontal de las X tenemos los días y en la línea vertical de las Y
tenemos la puntuación. Ahora veremos cómo se alimenta este gráfico. Analicemos el siguiente
recuadro. En primera instancia notamos que solo tenemos las historias del "sprint" 1 y luego
vemos las tareas asociadas a cada historia. Algo que puede ser muy particular del equipo es dividir
la puntuación de las tareas entre la historia para que cada tarea, cuando se concluya, aporte a la
conclusión de la historia. Esto es algo muy peculiar del equipo en sí y se puede hacer si se desea.
Luego vemos que la mayoría de los campos vienen del "product backlog". Y los campos que nos
ayudarán con el seguimiento de la conclusión de la historia van a ser los campos del día 1 al día a
10. Luego la persona que actualice el Excel tiene que actualizar con la puntuación de la tarea en el
día que se completó y de esta manera el gráfico de quemado o "burndown chart" se irá
actualizando de manera automática.
Por ejemplo, eliminamos este valor y se actualiza el "burndown chart". Colocamos el valor como
estaba y vuelve y se actualiza. Podemos notar más abajo las filas que dicen Esfuerzo restante y
Esfuerzo ideal. El esfuerzo restante es lo trabajado en el día y representa la sumatoria de los
puntos de todas las tareas que se agotaron o se cumplieron en ese día. Una vez concluidas todas
las historias, el gráfico naturalmente se completa.

Ahora conoceremos la hoja de Review o revisión y Retrospectiva del "sprint". En el "review"

mostramos el demo de producto al usuario y es algo puramente práctico. Lo ideal es interactuar
con el cliente y tomar las notas que sean necesarias.
Luego, en la retrospectiva, podemos documentar esta reunión con una de las técnicas de
retrospectiva para que el equipo indique cómo podemos mejorar. En este caso tenemos las
columnas Empezar a hacer, Dejar de hacer y Continuar haciendo.

Continuaremos estudiando la hoja de impedimentos, que la misma sirve para evitar cometer las
situaciones que representen una degradación en el flujo de trabajo. En esta hoja vamos a registrar
la fecha, descripción del impedimento, estado y cómo se solucionó.

Ya que observamos cada hoja de cálculo, es decir, qué información colocamos y cómo podemos
realizar este seguimiento a través de Excel, podemos subir esta hoja a Google Docs y de esta
manera podría convertirse en una herramienta online de colaboración para todo el equipo una vez
compartes el enlace con todos los usuarios autorizados. Los beneficios son evidentes porque todos
podrán actualizar y ver en tiempo real el progreso del proyecto. También cada integrante podrá
actualizar el Excel en línea y así evitamos tener esa responsabilidad sobre un solo integrante del
equipo.

JIRA
Conociendo las bondades de JIRA a través de un proyecto ágil
En esta ocasión vamos a conocer sobre Jira. Como ven, esta es la página inicial. En principio, muy
agradable a la vista y con varias opciones en el menú que estaremos viendo más adelante. Debes
tomar en cuenta que al activar la versión gratuita de este curso seleccioné la opción en español, lo
cual va a facilitar mucho más la adopción de esta herramienta. Iniciaremos con la creación del
proyecto siguiendo la opción en el menú Proyectos y luego Crear proyecto. Como podemos notar
en esta página, existen varias opciones para tomar como plantilla o modelo de ejemplo de
proyecto dependiendo del negocio en el cual estés involucrado. Por ejemplo, mira este modelo de
Recursos Humanos. Como puedes ver, existe información predeterminada y un flujo
predeterminado para cada área o foco de negocio. Te invito a explorar esas opciones porque
buscan facilitar el ciclo de vida de gestión del proyecto y con tu aporte personalizado, de acuerdo
a las particularidades del negocio, pueden acomodarse mejor a utilizar la herramienta.

Ahora bien, partiendo del tipo de proyecto que vamos a gestionar, tenemos Kanban. Este tipo de
seguimiento usualmente se utiliza cuando tienes casos particulares y usualmente [divorciados] o
excluyentes sobre pendientes en el negocio y que no ameritan crear un proyecto para esto.
También pueden ser actividades del día a día que no están atado a un proyecto en sí.

Scrum, que es el modelo de gestión casi universal o el que es más digerible para alguien que está
iniciando con la gestión de proyectos ágiles, porque tiene ceremonias establecidas muy fáciles de
entender y de reproducir por todo el equipo.

Seguimiento de errores. El seguimiento a errores se refiere, como su nombre lo indica, a ajustes

posimplementación o luego de entregado el proyecto al cliente. En este caso serían adecuaciones
de un grado mínimo en comparación con las historias de usuario que componen el proyecto luego
de haber sido entregado.
Vamos a seleccionar Scrum. Scrum tiende a clasificarse como proyecto de software, como vemos
en la parte superior izquierda, pero esto no debe ser una limitante por industria. En esta plantilla
tenemos el flujo de Scrum, es decir, con las actividades de pendiente, en curso y terminado. Con
Scrum vamos a organizar y priorizar historias. Los tipos de incidencia o elementos que podemos
crear en el proyecto son historias, épicas, errores, tareas y subtareas. En general, nos va a ayudar a
planificar más de un "sprint" en nuestro proyecto para luego a través de gráficos, que se alimenten
en tiempo real con la información que el equipo aporta, podemos conocer la velocidad actual del
equipo e ir ensamblando ciclos incrementales del modo de trabajo.

Daremos clic a utilizar esta plantilla. En la siguiente pantalla tenemos dos opciones, gestionar por
empresa y gestionar por equipo. Vamos a seleccionar gestionar por equipo. Colocamos el nombre
de nuestro proyecto, elegimos el tipo de acceso, seleccionaremos Limitado. El campo Clave es un
código autogenerado por Jira y se utiliza para generar una numeración secuencial para cada
historia y elementos relacionados con el proyecto. Luego presionamos Crear proyecto. Una vez
completado todo, Jira nos lleva a la pantalla del tablero. Aquí vemos que no tenemos ninguna
historia y comenzaremos a alimentar nuestro "backlog".

Vamos a crear varias historias relacionadas al proyecto. Si observamos este botón de Crear, sirve
de utilitario porque está presente como parte del menú y se utiliza para crear historias, épica,
entre otras, dependiendo del valor seleccionado en el campo Tipo de incidencia. Colocamos el
nombre de la historia y presionamos Crear. Algo que puedes notar en un principio es que la
historia no se crea directo en el tablero. Vamos a ir al "backlog". Vemos la historia en el "backlog"
porque posteriormente estaremos realizando la ceremonia de planeación. Continuaremos
creando más historias. De esta manera creamos todas las historias de usuario del proyecto. Luego
realizaremos la planeación y la estimación del esfuerzo de las mismas, así como también la
distribución de las historias por cada "sprint". Por último, vamos a agregar una página web que
funcione como una referencia de nuestro proyecto. La misma la puedes utilizar para buscar
información relacionada al proyecto o que te sirva de guía en el futuro. Hacemos clic en el menú
izquierdo de acceso rápido, presionamos Añadir acceso rápido, luego colocamos la página y listo.
Presionamos Añadir y la misma estará disponible en todo el proyecto.

Creando el panel de seguimiento del proyecto en JIRA

En este capítulo vamos a organizar las historias de nuestro "backlog". Es en la ceremonia de "sprint
planning" donde podemos esclarecer las historias y a su vez puntuarlas o estimarlas. Por ejemplo,
en las historias que tenemos en nuestro "backlog" podemos agregar descripción, comentarios o
colocar la puntuación estimada. A su vez, en la ceremonia de planeación debemos tomar en
cuenta la cantidad de historias y el tiempo que dispone el equipo para este día porque podemos
excedernos del tiempo si el proyecto tiene muchas historias de usuario, o simplemente podemos
trabajar en la estimación de las historias del "sprint" 1 e ir arrastrando las historias al recuadro que
habilita Jira aquí arriba. Por ejemplo, puntuamos a esta historia con 21 puntos, vemos que tiene
21, y luego arrastramos esta historia al "sprint" 1. Esta es la forma más rápida y sencilla. Una vez
tenemos las historias puntuadas y seleccionamos las historias que van a ser trabajadas en el
"sprint" 1, procedemos a presionar Añadir fechas. El nombre del "sprint" se puede quedar como
está. La duración, colocamos dos semanas. Y el objetivo del "sprint", colocamos el objetivo de
nuestro "sprint". Presionamos el botón Actualizar, luego presionamos Iniciar sprint, presionamos
nuevamente Iniciar y Jira nos redirige a la pantalla del tablero. Como pueden observar, tenemos
las historias del "sprint" 1 en la columna de Por hacer.

Algo muy útil que ofrece Jira es una vista previa del comportamiento general del "sprint"
presionando el botón Insights. Luego volvemos al tablero. Cuando regresamos a la página del
"backlog", podemos priorizar las historias con una proyección estimada de los "sprint" que vamos
a trabajar en el futuro. Vale la pena resaltar que esta priorización es una estimación al momento
de realizar la planeación del "sprint" y el equipo debe consensuar y definir cuáles son las historias
o tareas que se deben comprometer para lograr este objetivo, así como también identificar qué
historias deben dividirse y convertirse en épicas. Por ejemplo, vamos a crear dos "sprint" más
presionando el botón Crear sprint. Como pueden ver, se crea el "sprint" 2. Y si presionamos de
nuevo Crear sprint, se va a crear el "sprint" 3. Luego, como "product owner", arrastramos las
historias que entendemos se trabajarán en el "sprint" 2 y en el "sprint" 3. Ahora examinemos los
paneles presionando en el menú superior Paneles y luego Ver todos los paneles. Este es el panel
predeterminado, que es el "default dashboard". Seleccionamos el panel y en este panel podemos
ver mis asignaciones, que son las historias asignadas hacia mí, y el historial de actualizaciones del
proyecto. También, el listado de proyectos disponibles de la empresa y un mensaje de bienvenida
a Jira con vínculos de ayuda. Ahora vamos a proceder a crear un panel presionando Panel y luego
Crear panel. Colocamos los valores de cada campo en Nombre, Descripción. En Lectores
seleccionamos Proyecto y luego seleccionamos el equipo del proyecto. En Editores lo mantenemos
privado y presionamos Guardar. Ahora vamos a añadir los "gadget" que nos interesan.
Presionamos Añadir gadget y se despliega una lista de opciones bastante interesante. De manera
predeterminada "Abrir gadget" permanece abierto una vez se crea un nuevo panel. Recuerda que
lo ideal es seleccionar aquellos indicadores sobre el cual puedas accionar para contribuir en el
proyecto, dado a que este tablero lo estaremos creando para el equipo del proyecto. Es
importante diferenciar qué indicadores le gustaría ver a cada miembro del equipo al momento de
crear ese panel, es decir, al gerente le gustaría ver indicadores de seguimiento, al equipo,
indicadores de sus tareas que están pendientes, y así por el estilo. Esto para evitar una sobrecarga
de información o querer medirlo todo. Vamos a añadir el "gadget" de estado de salud de los
"sprint". Presionamos Añadir y el mismo se despliega, luego seleccionamos el nombre del tablero
y presionamos Guardar. Vemos como se despliega el "gadget". Luego seleccionamos el "gadget"
de Trabajo por hacer en "sprint", de igual manera seleccionamos el tablero, seleccionamos
Mostrar el nombre del tablero, Mostrar el nombre del sprint. Intervalo de actualización puede ser
15 minutos, dependiendo. Presionamos Guardar. Finalmente agregamos el "gadget" de Días
restantes en "sprint". Seleccionamos Mostrar nombre del tablero, Mostrar nombre del "sprint" y
Actualizar cada 15 minutos. Presionamos Guardar. Ahora ordenaremos un poco el panel
arrastrando como se vea visualmente más estético y presionamos Listo. Podemos ver nuestro
panel. A su vez, podemos consultar nuestro panel por el menú Paneles > Indicadores del proyecto
de obra de construcción, el cual acabamos de crear.

Configurando el tablero de trabajo de JIRA

Ahora vamos a realizar modificaciones en el flujo de trabajo. Vamos a Proyectos y seleccionamos
nuestro proyecto, ahora presionamos el botón derecho que está al lado de Terminar el "sprint",
seleccionamos Gestionar el flujo de trabajo. Observamos una nueva pantalla con un flujo sencillo,
este flujo nos muestra que desde cualquier estado se puede hacer una transición a cualquier otro
estado. Vamos a realizar la configuración de que desde To do no pueda pasar a Done sin
previamente pasar por el estado En progreso. Para esto vamos a seleccionar el botón Transición.
Aquí vemos un nuevo cuadro de diálogo y simplemente vamos a seleccionar en el estado de origen
y el estado de destino cómo queremos que sea nuestro flujo. Presionamos el botón Crear. Ahora
vamos a agregar una nueva transición que pase del estado En progreso a estado Done.
Presionamos el botón Crear. Se ve cómo están enlazadas las nuevas transiciones en nuestro flujo.
Procederemos a presionar Actualizar flujo de trabajo. En este cuadro presionamos Guardar.
Regresamos a nuestro tablero y vamos a agregar un estado denominado En espera de tercero.
Este estado va a reflejar aquellos casos en los cuales dependemos de alguien externo al proyecto.
También agregaremos una regla para que se asigne a una persona e inmediatamente pase a este
estado. Luego agregaremos otra regla para que solo dicha persona pueda liberar estos estados.
Presionamos el botón de más en la columna y colocamos el nombre del estado, presionamos la
flechita y vemos como se visualiza el nuevo estado. Ahora vamos a modificar nuevamente el flujo
de trabajo. Para esto, presionamos Gestionar el flujo de trabajo y vemos nuestro estado agregado
en la pantalla. Ahora vamos a agregar nuestra transición para que de En hacer pase a En espera de
un tercero. Presionamos el botón Crear. Se visualiza nuestra transición creada. Ahora
procederemos a crear una regla. Seleccionamos la opción Asignar una incidencia a alguien y
presionamos Seleccionar. Luego observamos la transición que acabamos de crear y seleccionamos
a la persona que va a trabajar estas historias una vez pasen a En espera de un tercero.
Presionamos Añadir. Ahora vamos a añadir una segunda regla y el objetivo de esta es que una
persona solo pueda mover las historias que estén en el estado En espera de tercero.
Seleccionamos la opción Restringir quién puede mover una incidencia, presionamos Seleccionar y
elegimos a la persona. Presionamos Añadir. Vemos como las reglas están creadas en el menú
derecho. Finalmente presionamos Actualizar flujo de trabajo para que los cambios sean
guardados. Presionamos Guardar. Es importante mencionar que esta configuración está
especialmente diseñada para este proyecto, por lo que la empresa tiene la libertad de adecuarlo a
como usualmente sea su día a día.
En lo que resta de este capítulo vamos a explorar un poco la personalización de campos de
acuerdo al tipo de elemento del proyecto, es decir, puedo agregar campos que entiendo que
necesita el proyecto inmediatamente justamente en esta misma pantalla. Vemos que podemos
agregar campos de "story" o historia, de "bug" o defecto, de "task" o tarea, o de "epic" o épica.
Podemos agregar campos asociados a las épicas, a los defectos, historias y tareas. En esta pantalla
también tenemos la opción de campos de descripción y campos de contexto. Para nuestro caso
vamos a agregar un campo tipo numérico que pertenecerá a los campos de contexto. Colocamos
el nombre y una breve descripción del mismo. Presionamos Guardar y listo. Por último, vamos a
probar estos cambios yendo al tablero. Primero vamos a mover una historia y vemos como se
asigna a la persona que indicamos. Ahora vamos a crear una nueva historia y a validar el campo
que acabamos de crear, que está aquí, y presionamos Crear. De esta sencilla manera podemos ir
personalizando de acuerdo a cómo funciona nuestra empresa en Jira.

Configurando reglas automáticas basadas en condiciones o elementos del proyecto

En este capítulo vamos a automatizar una simple tarea. Para esto nos dirigimos en el menú
izquierdo de nuestro proyecto, en Configuración del proyecto, luego seleccionamos
Automatización. En la siguiente pantalla vemos las reglas que ya están habilitadas, las cuales
podemos deshabilitar en cualquier momento presionando el botón o el "check" habilitado o
deshabilitado. En nuestro caso procederemos a crear la nueva regla presionando el botón Crear
regla. Seleccionamos. Se cambió el valor del campo. Este va a ser nuestro desencadenador. Luego
seleccionamos el campo Story point estimate, también el campo Para, marcamos Editar incidencia
y presionamos Guardar. Ahora Jira nos lleva a una pantalla de un nuevo componente, aquí
seleccionamos Nueva acción. En la acción podemos agregar un comentario o enviar un correo
electrónico. Como recomendación en el mundo ágil, debemos conocer a qué se debe este cambio
en la puntuación, ya que eso es lo que estamos monitoreando y conversar con el equipo que
amerita en este caso. Es decir, si debemos crear una nueva historia, si el "sprint" está muy
avanzado y tal vez lo ideal sería planificar para un nuevo "sprint" o, en fin, qué pasó con la historia,
lo ideal es conversar con el equipo. Con la acción lo que buscamos es iniciar un punto de
conversación para buscar el consenso. Para este caso vamos a seleccionar enviar un correo
electrónico y como recomendación particular debemos ser muy prudentes al momento de crear
las reglas para no enviar correos electrónicos de manera muy continua, es decir, vamos a enviar
correos electrónicos para aquellos casos que ameriten una atención explícita. Y, por experiencia, el
cambio de estimación podría significar que la historia no pueda ser completada en este "sprint",
algo que el "Scrum master" debe tener muy pendiente, ya que podría representar un
impedimento para el proyecto. Vamos a seleccionar Enviar correo electrónico. En esta pantalla
podemos colocar el tema o el objetivo del correo y el contenido. Una vez completados los campos
de hasta, copia, el tema, en este ejemplo coloqué la historia, con la nomenclatura de Jira para
colocar el número de la historia, acaba de sufrir un cambio en la estimación. En el contenido
coloqué el mismo texto del encabezado. Finalmente presionamos Guardar. En el nombre de la
regla coloqué "Cambio de estimación" y presionamos activarlo. Con esto se ha activado la regla de
automatización. Podemos validar la regla acabada de crear presionando Automatización o volver a
la lista. Aquí vemos la regla que acabamos de crear.
Integrando JIRA con otras aplicaciones colaborativas
Este capítulo va a ser muy interesante porque Jira hace posible que podamos conectarnos con
otras aplicaciones que utilizamos a diario para el trabajo o para cosas personales. Con esto
buscamos aumentar la productividad, integrándolos con aplicaciones que ya son familiares para
nosotros. Vamos a navegar en el menú Más, luego seleccionamos Aplicaciones y luego
presionamos Buscar aplicaciones nuevas. Vemos una pantalla con la gama de aplicaciones que
tenemos disponibles, también tenemos unos filtros que podemos utilizar para buscar dichas
aplicaciones. Podemos notar que dentro de las aplicaciones disponibles algunas tienen la etiqueta
de Staff pick, que son las recomendadas por el equipo de Atlassian. Dentro de los filtros tenemos
el cuadro de texto donde podemos digitar específicamente el nombre de la aplicación. Luego
tenemos el campo Sort, que sirve para agrupar por las más puntuadas, las que están en tendencia,
el top en ventas y las más nuevas. Luego un "check" de Free. En More filters están las que son
especialmente dedicadas para "cloud", las que tienen soporte del suplidor y las que están en beta.
Luego en Categories o Categorías podemos seleccionar las que están relacionadas a manejo de
proyectos, trazabilidad del tiempo, gráficos o diagramas, tecnología, reportes. También tenemos
otras más. Vamos a presionar el "check" de Free y en Categorías vamos a seleccionar Utilities.
Vamos a seleccionar esta aplicación de QR Code for Jira. Esta aplicación quiero decir que nos va a
generar un código QR por el código de historia en Jira. Para esto simplemente presionamos Get
app y luego presionamos Get it now. La aplicación se está instalando y vemos que con éxito fue
instalada. Iremos a Manage app o Administrar aplicaciones y podemos confirmar que está
instalada. Para probar la aplicación, volvemos al tablero, hacemos doble clic sobre cualquiera de
las historias y nos desplazamos hacia abajo. Seleccionamos Abrir código QR y vemos el código QR
generado por esta historia. Con esto puedes compartir la historia a cualquier persona que tenga
este código QR.

Resumen sobre los beneficios de JIRA para la gestión de proyectos ágiles.

Finalmente, vamos a navegar de manera breve sobre otras opciones útiles que debemos
mencionar en este curso para el manejo de proyectos ágiles. En nuestro proyecto seleccionamos la
opción Configuración de proyectos. Luego en el menú izquierdo seleccionamos Funciones. Si nos
desplazamos un poco hacia abajo, observamos que la opción Informe no está seleccionada, vamos
a proceder a marcarla. Ahora vamos al proyecto y visualizamos la opción de informe habilitada en
nuestro submenú. Presionamos Informe y observamos todos los gráficos de gestión ágil que
podemos habilitar. Vamos a seleccionar Gráfica de trabajo hecho o el "burndown chart". Vemos
como se genera el gráfico. Debido a que iniciamos este "sprint" recientemente, el gráfico no posee
información, pero es sumamente útil para el seguimiento de nuestro proyecto. Usualmente, este
gráfico se irá completando con el día a día. Volvemos hacia Informes y podemos ver, por ejemplo,
que el gráfico de velocidad se completará una vez se concluya un "sprint". Vamos a seleccionar
Diagrama de trabajo pendiente de "sprint". Al igual que el otro, es el gráfico de "burndown chart"
o gráfico de quemado, el cual podemos observar que tienen los días en el eje horizontal y los
puntos en el eje vertical. Ahora vamos a explorar otra opción disponible en el menú que no
habíamos tocado y es la sección de Filtro. Seleccionamos Filtro y seleccionamos Búsqueda
avanzada de incidencias. Aquí vemos una pantalla en el menú izquierdo con filtros
predeterminados como son Mis incidencias, Informadas por mí, Todas las incidencias, Incidencias
abiertas, entre otras. Vamos a seleccionar Todas las incidencias. Aquí aplicamos el filtro de nuestro
proyecto y las historias por hacer. De esta manera podemos ver el resultado del filtro
inmediatamente. A su vez, podemos cambiar la vista a lista, podemos abrir en Microsoft Excel o en
Google Sheets. También podemos compartir o exportar a otro formato. Algo muy interesante es
que si presionamos este menú de los tres puntitos tenemos las opciones de cambiar masivamente,
borrar clasificaciones e importar incidencias. Vamos a seleccionar Cambiar masivamente. Podemos
seleccionar todas las historias y presionar Siguiente. Luego seleccionamos Editar incidencias y
presionamos Siguiente. Podemos cambiar el responsable o cambiar cualquiera de los campos que
están aquí debajo y presionar Siguiente. Finalmente, esta es la pantalla de confirmación.
Seleccionamos Confirmar y se inicia el proceso de edición masiva de todas las historias que
seleccionamos previamente. Vemos como se completa la operación y presionamos el botón de
confirmar. Listo, aquí vemos como se cambiaron masivamente todos los responsables de todas las
historias que seleccionamos. Esta funcionalidad es particularmente útil cuando tenemos muchas
historias en nuestro proyecto.

ASANA
Configurando el enfoque del proyecto en Asana: Portafolio, Proyecto o Tareas
En este capítulo vamos a conocer un poco sobre Asana. Antes de iniciar vamos a realizar un
recorrido general sobre Asana.

Tenemos un menú izquierdo que contiene todas las funcionalidades expuestas para el beneficio de
nuestros proyectos ágiles. Por ejemplo,

- en el menú Inicio, donde observamos las tareas próximas a vencer y un acceso directo a
los proyectos que recientemente hemos trabajado.
- Pasamos a Mis tareas, que en modo de diagrama de Gantt tenemos desglosadas las
asignaciones en las cuales yo soy la responsable.
- Pasamos a Bandeja de entrada, aquí se observan con un mayor nivel de detalle las tareas a
modo de historias relevantes. –
- Continuamos con Informes, que son gráficos que nos muestran el avance de nuestro
proyecto.
- Portafolios, son los portafolios que engloban los proyectos.
- Objetivos, este último podemos utilizarlo para definir la misión del negocio y establecer
los objetivos claros y realizables.
- Luego desplazándonos un poco más abajo en el menú podemos establecer favoritos e
invitar a personas a unirse a nuestro proyecto.
- También si movemos el cursor en la parte superior derecha podemos observar un círculo
naranja con el símbolo de más donde podemos fácilmente agregar elementos al proyecto
como son tareas, crear un nuevo proyecto, mensajes e invitaciones.

Vamos a pasar al menú Portafolios. Vamos a crear un nuevo portafolio presionando el símbolo de
más en Nuevo portafolio, colocamos el nombre del portafolio y luego en el nivel de visibilidad
seleccionamos Privado para miembros del equipo. Presionamos Crear portafolio. Luego de creado
el portafolio tenemos como un menú en modo de pestañas asociado al portafolio donde vemos
Lista, Cronograma, Progreso, Gestión de recursos y Mensajes. Ahora crearemos el proyecto
asociado a este portafolio. Para esto presionamos el símbolo de más, presionamos Proyecto,
seleccionamos Proyecto en blanco, colocamos el nombre, en la privacidad colocamos Privado para
miembros del equipo. En la vista predeterminada podemos seleccionar cualquiera de las que estén
aquí, que son las pestañas que se crean al igual que el portafolio, y luego presionamos Crear
proyecto. En esta pantalla vemos que inicialmente tenemos campos básicos como Fecha y
Responsable y Nombre de la tarea, que equivaldría a la historia de usuario. En este punto
podemos actualizar cada campo y poner las fechas y los responsables. Recordar que las fechas de
entrega siempre van a depender de la estimación que haga el equipo y esto conlleva a ser
conscientes del grado de experiencia que tiene cada miembro del equipo. Un punto a notar es que
presionando el símbolo de más en esta columna puedes agregar columnas personalizadas. Por
ejemplo, agregar la columna de Tipo de iniciativa, luego Selección múltiple, colocamos el nombre
del campo Tipo de iniciativa, luego presionamos Opción y colocamos el nombre de la iniciativa.
Continuamos con la opción 2. Presionamos Agregar una nueva opción para continuar agregando
iniciativas. Con esto creamos todas las iniciativas y procedemos a presionar el botón Crear campo.
Podemos observar el tipo de iniciativa creado como una columna en la lista de historias de usuario
o requerimientos. Continuaremos conociendo en más detalle el proyecto o las opciones y
funcionalidades que nos ofrece Asana con relación al proyecto. Hacemos clic sobre Resumen. Y,
como puedes ver, en Resumen puedes colocar una descripción del negocio o el objetivo en sí que
buscamos con el proyecto. También podemos definir los roles, resumen breve del proyecto,
agregar los logros y agregar los objetivos que respaldan este proyecto. También podemos ver la
fecha de entrega y el estado de nuestro proyecto. Continuando en la pestaña Lista, en este punto
podemos agregar historias. Visualmente, Asana muestra tareas, que en cierto sentido puede
parecerse un poco a los proyectos en cascada de acuerdo a como esquematiza en la pantalla, pero
esto no quiere decir que no podemos adecuar ágil a esta pantalla. Por ejemplo, vamos a agregar
otro nuevo campo de tipo numérico denominado Story points, agregamos el campo Descripción y
colocamos Estimación del esfuerzo a alto nivel que conlleva realizar esta actividad. El formato
permanece numérico, cero decimales, y procedemos a presionar el botón Crear campo.
Continuaremos agregando otro campo de selección múltiple denominado Etiqueta. Con este
campo buscaremos clasificar el nombre de la tarea a modo de épica, historia o tarea. Una vez
agregado los valores, vamos a cambiar los colores para que sean más alusivos a la idea que
buscamos. Por ejemplo, Épica vamos a cambiar a morado, Historia a verde, Tarea a amarillo y
Defecto a rojo. Procedemos a presionar el botón Crear campo. Vemos como el campo Etiqueta
también está habilitado. En esta misma pantalla agregaremos los "sprint". Vamos a colocar en la
sección 1 "Sprint 1". Agregaremos una nueva sección denominada "Sprint 2" y otra sección "Sprint
3". Ahora procederemos a agregar unas cuantas historias para que se vean visualmente cómo van
a quedar dentro de nuestro proyecto. Para esto presionamos el botón Agregar tarea. Vemos como
en la parte inicial podemos tener todas las historias relacionadas al "backlog" y como
posteriormente segregamos por "sprint" todas las historias que deseamos agregar a cada "sprint"
y que forman parte del alcance del proyecto. Podemos continuar agregando historias al "sprint 2"
presionando el botón de más al lado del nombre del "sprint" y seguir agregando las tareas.
Cambiamos los campos de Responsable si así lo amerita, el tipo de iniciativa que acabamos de
crear, la puntuación, basada en la serie Fibonacci, y si es una épica, historia, tarea o defecto. De
esta manera concluimos con la creación de la estructura ágil dentro de la aplicación Asana, que
tiene como objetivo facilitarnos nuestro día a día en el trabajo.

Realizando las actividades básicas del proyecto en Asana

En este capítulo veremos la configuración del tablero en Asana y los gráficos predeterminados que
se habilitan en la aplicación. Pasaremos de la pestaña Lista a Tablero. Aquí podemos ver los
"sprint" por columnas y agregaremos las columnas Kanban Por hacer, En progreso y Realizadas.
También cambiaremos el nombre de esta sección que dice Sin nombre por Backlog, esto para
conocer el listado de historias que posteriormente se estarán planeando en los futuros "sprint".
Presionando Agregar sección agregaremos las columnas por hacer, luego en progreso y finalmente
realizadas. Cada tarea en cada columna se puede mover de una columna a otra sin mayores
contratiempos, como puedes notar. También tenemos la opción de crear tareas o historias debajo
de cada columna. En este punto lo recomendable es colocarla en el "backlog" y que en la
ceremonia de planeación se defina en el "sprint" en el cual se va a trabajar. Si pasamos a la
columna Lista podemos notar las columnas que acabamos de agregar. Cuando pasamos a la
pestaña de cronograma podemos visualizar las fechas de inicio y fin de manera muy ordenada, lo
cual sería útil para quienes trabajan en el proyecto conocer cuáles son las dependencias y cómo se
están interconectadas cada fecha con los posibles entregables. Nos desplazamos un poco hacia la
derecha y vemos las fechas. En la pestaña Calendario, la cual nos muestra un calendario muy
informativo y se observa en relieve aquellas historias que están relacionadas con el proyecto.
Vamos a continuar con el panel. En el panel tenemos cuatro indicadores sobre la salud general del
proyecto, los cuales son Tareas finalizadas, Tareas sin finalizar, Tareas con retraso y Tareas en
total. Estos indicadores podemos cambiar el tipo de gráfico o agregar filtros cuando nos colocamos
sobre el indicador y presionamos el lápiz que se encuentra habilitado. Luego tenemos un
histograma agrupado por las secciones que definimos previamente. Al igual que los indicadores,
podemos configurar el gráfico de acuerdo a como entendemos la información, sería más relevante
para tomar acciones correctivas en nuestro proyecto, o si es para mostrar a los ejecutivos la salud
general del proyecto con números generales que provean una visión de alto nivel sobre el avance.
Adicionalmente, Asana nos facilita un botón de Agregar gráfico. Esto para crear un gráfico desde
inicio a fin si deseamos medir algo que no se encuentra en esta pestaña. La limitante para crear los
gráficos es que solo podemos agregar los campos en el eje de la X y en el eje de la Y solo permite
el número de tareas. Continuamos con la pestaña Mensajes. Aquí podemos crear actualizaciones
informativas sobre el proyecto, las cuales están habilitadas para todo el equipo. Podemos tener
una conversación sobre historias, épicas o tareas en esta pestaña, lo cual representa otra limitante
de Asana porque no te deja interactuar sobre la misma historia o tarea que creamos
anteriormente. Finalmente pasaremos a la pestaña Archivo. Aquí podemos adjuntar documentos
que estarán disponibles para todo el proyecto. De esta manera puedes alimentar el "backlog" on
listado de historias de manera dinámica y con la colaboración directa de la misma fuente que
genera los requerimientos. Posterior a la ceremonia de planeación y desglose del "backlog"
puedes realizar la depuración y estimación de las historias.

Recorriendo los avances del proyecto a través de los reportes de Asana.

En este capítulo lo iniciaremos en la sección Informes, que está ubicada en el menú izquierdo.
Procederemos presionando el botón Explorar gráficos y presionaremos Agregar gráfico
personalizado. Presionamos el botón Crear. Vamos a renombrar nuestro panel, ya que Asana no
nos permite colocarle un nombre al panel al momento de explorar los gráficos en caso de que no
hayamos creado un panel anteriormente. Así tenemos nuestro gráfico. Volvemos a la pestaña
Informe y observamos el panel creado. Ingresamos al panel y luego procederemos a agregar
gráfico. Asana tiene disponibles tres renglones para obtener indicadores del proyecto, que son
Recursos, Estado del trabajo y Progreso. Iniciaremos creando un gráfico de recursos.
Seleccionamos Próximas tareas para esta semana, en los filtros dejamos tarea sin finalizar, en el
estado de la tarea seleccionamos aquellas que están en retraso para conocer qué impedimentos
están ralentizando dicha tarea y que nuestro "Scrum master" pueda resolver ese impedimento.
Finalmente, en la fecha de entrega seleccionamos en los últimos días. Esto porque tenemos
periodos de "sprint" definidos de dos semanas y lo ideal es generar un seguimiento diario sobre
los impedimentos. Procedemos a presionar el botón Crear y de esta manera queda habilitado
nuestro gráfico. Continuaremos creando nuestro segundo gráfico y será en base al estado del
trabajo. Seleccionamos Tareas por campo personalizado. El tipo de gráfico, anillo. En Grupo
seleccionamos Proyecto. Y la medición, por el número de tareas, de esta manera podemos ver el
número de tareas o historias de usuario por cada proyecto que tenemos en Asana. Presionamos el
botón Crear. Vemos como nuestro panel está tomando forma. Continuaremos agregando un
tercer gráfico de la sección Progreso. Vamos a escoger el gráfico con la mayor cantidad de tareas
finalizadas y así a alto nivel podemos utilizar esta información para conocer qué se hace en este
proyecto para que podamos emular ese comportamiento en los demás proyectos. En el tipo de
gráfico seleccionamos Lollipop. Continuando con el campo Incluir tareas, seleccionamos
Portafolios con el portafolio que hemos creado. En el eje de la X dejamos seleccionado Proyecto y
en el eje de la Y permanece el número de tareas. En los filtros subimos el número a dos semanas y
procedemos a presionar el botón Crear. Debido a que no hemos colocado tareas en Done o en
Realizadas, el gráfico se muestra vacío. Al final de concluido nuestro panel podemos invitar a
miembros del equipo para que puedan conocer el progreso del proyecto con esta información
visual que se mantiene actualizada en línea cuando el equipo coloca los avances del proyecto en
Asana presionando el botón Compartir. Con esto concluimos este capítulo.

Azure DevOps Services

Manejando los proyectos a través de los Tableros de Azure
Azure DevOps Services es otra herramienta colaborativa para manejar los proyectos ágiles. La
particularidad que tiene es que es muy especializada para proyectos tecnológicos, lo cual implica
que, aunque tu industria o negocio no esté directamente relacionado con la tecnología, puedas
conocer alguno de los procesos de esta. Vale la pena resaltar que en el momento de realizar este
curso Azure DevOps Services carece de una versión en español.

Por otro lado, si dentro de tu industria vas a manejar proyectos tecnológicos como la
implementación de un nuevo sistema CRM, un ERP o migraciones hacia la nube, muchas empresas
están considerando Azure DevOps Services en la actualidad, ya que es una herramienta en línea
idónea para este tipo de proyectos porque contiene todos los elementos integrados sobre el ciclo
de vida de implementación de una aplicación, que en especial si desconoces de estos procesos
puedes apoyarte de la misma, tanto tú como tu equipo, y dependiendo del nivel de madurez o
experiencia que tengan los colaboradores pueden adoptarla con un mayor grado de velocidad. A
veces, en muchas organizaciones realizar el ensamblaje entre el lenguaje tecnológico y el lenguaje
de negocio puede ser todo un reto y Azure DevOps Services puede convertirse en su aliado para
una transformación digital y para seguir un flujo de trabajo a nivel tecnológico que esté
estandarizado a nivel mundial.

Sobre esta herramienta interactiva para planificar y obtener visibilidad en todo el flujo ágil dentro
de un mundo moderno como es la industria 4.0, la cual busca crear evolución continua del valor
hacia el cliente con un producto interrelacionado con los diferentes procesos que intervienen en la
creación del mismo, podemos comentar sobre los casos de uso más relevantes como son comercio
electrónico, desarrollo de aplicaciones móviles, migración hacia la nube desde .NET, SAP,
Mainframe, SQL o Linux, y aplicaciones críticas del negocio que usualmente mantienen la
operatividad del negocio.

Sobre los casos de uso de industria, puede ayudar a modernizar y a renovar aplicaciones que se
utilizan en los siguientes sectores: gobierno, salud, entretenimiento, energía, manufactura y, por
supuesto, servicios financieros. En lo que resta de este capítulo vamos a navegar brevemente
dentro del menú Azure DevOps Services a través de Organization settings. Observamos que el
menú contiene seis renglones: General, Security o Seguridad, Boards o Tablero, Pipelines, que se
utilizan para segmentar los productos de acuerdo a la prueba a realizar previo a la
implementación, Repos o repositorios de datos para guardar información relevante como
manuales, fuentes de código en caso de ser proyectos de desarrollo de software, y Artifacts, que
son librerías especializadas para el despliegue de aplicaciones de manera integrada y continua. En
lo que resta de este capítulo vamos a concentrarnos en los primeros dos puntos, que estaremos
conociendo a mayor profundidad. Azure DevOps Services

Trabajando en Sprints con Azure

Vamos a iniciar este capítulo creando un nuevo proyecto. Para esto lo hacemos desde la página
principal, donde se habilita un botón New project. Procedemos a presionar el botón New project.
Colocamos el nombre del proyecto en el campo Project name. En el campo Description podemos
colocar una breve descripción ilustrativa. Luego en el campo Visibility tenemos la opción de
público o privado, seleccionamos la opción de privado para luego conceder permisos puntuales a
los miembros del equipo. Si presionamos Advanced vemos que tenemos otro campo, Version
control, que es Git. Esto lo dejamos tal como está. Y Work item process, aquí tenemos las opciones
de Agile, Basic, CMMI y Scrum. Dejamos seleccionado Basic. Ahora pasamos a presionar el botón
Crear. Ahora vemos como el proyecto está creado. Tenemos un submenú y un botón de Private e
Invite. En este caso vamos a pasar a Project settings para realizar la configuración básica de
nuestro proyecto. Vamos a presionar sobre el "link" que dice Basic o Básico. Vemos que tenemos
los elementos básicos de ágil como son la épica, los "issue", que en este caso serían las historias de
usuario, y los "task" o tareas. Los demás están relacionados con proyectos de software. En las
demás pestañas, de Backlog levels, podemos ver como la definición de elementos de proyecto
están agrupadas por los elementos de ágil. Luego en la pestaña de Project podemos ver los
proyectos que utilizan el flujo de Basic. Ahora vamos a pasar a la pestaña de General > Overview.
Aquí vemos los detalles del proyecto. Vamos a desplazarnos un poco más abajo. Aquí podemos
seleccionar cuáles opciones del menú podemos obviar o eliminar para este proyecto, si no se trata
de un proyecto de software. Por ejemplo, podemos eliminar Pipelines, presionamos Remove
pipelines. Test Plans, presionamos el botón Remove test plans. Artifacts, y también presionamos el
botón Artifacts. Ahora vamos a pasar al menú de Boards > Project configuration. En esta sección
podemos crear los "sprint" con fechas estimadas. Por defecto, Azure DevOps crea el primer
"sprint" con las fechas vacías. Vamos a presionar New child y vamos a colocar el nombre del
"sprint", colocamos una fecha estimada de inicio y finalización del "sprint" y presionamos Save and
close. Vamos a crear otro nuevo "sprint" con el nombre de "Sprint 3", colocamos las fechas
estimadas y presionamos Save and close. También, por defecto, Azure DevOps Services estima un
"sprint" de 10 días o dos semanas. Colocamos las fechas de inicio y fin para el "sprint" 1, el creado
por defecto, y presionamos Save and close. Ahora pasaremos al menú Boards > Team
configuration. En esta primera pantalla podemos seleccionar los días laborables del proyecto para
que Azure DevOps Services considere las fechas en todo momento. Pasamos a la pestaña
Templates, la cual se utiliza para colocar valores predeterminados una vez creamos historias,
épicas o tareas. Vamos a crear un nuevo "template" para las historias. Colocamos el nombre de
"Prioridad", seleccionamos el campo Priority o Prioridad y para este seleccionamos un valor 4. Esto
significa que cada vez que se crea una historia el campo Prioridad va a tener un valor de 4.
Presionamos el botón de Save y ahora presionamos el botón de Close. Vemos el campo Prioridad
creado. Con estas configuraciones concluimos la personalización de las tareas administrativas
previas a nuestro proyecto.

Trabajando en Sprints con Zure

Podemos acceder a nuestro proyecto desde la página inicial haciendo clic sobre el mismo. Ahora
vemos que tenemos una página mucho más familiar en cuanto a la gestión de proyectos, con
varias secciones como estadísticas del proyecto, el usuario, los miembros del equipo, y a la
izquierda el menú con las funcionalidades que configuramos, es decir, Boards y Repos. Vamos a
dirigirnos a Boards y luego Boards y vemos un tablero Kanban e iniciaremos a crear nuestras
épicas e historias. Para esto simplemente presionamos New item, agregamos el valor de nuestra
historia. Podemos agregar las épicas seleccionando Epics en el menú superior derecho. Vemos que
cuando está filtrado por épica, la etiqueta cambia a color anaranjado. Colocamos el valor de épica
y presionamos Enter. Volvemos a seleccionar Historias o Issues. Y si hacemos clic derecho o
presionamos el botón Open podemos agregar más valores a nuestra épica o historia con datos
como descripción, agregar una discusión para miembros del equipo, entre otros varios valores
para enriquecer nuestras historias. Podemos ver el gráfico de estado donde se visualiza que la
historia está en To Do. Un historial de cambios. Podemos agregar enlaces o "links", agregar
archivos adjuntos y, una opción interesante en Details o Detalles, podemos relacionar la historia
con otra épica u otra historia. Por ejemplo, podemos seleccionar esta misma historia, seleccionar
el tipo de enlace, en este caso Child o Hijo, y podemos seleccionar la épica que creamos
anteriormente como el padre. Y presionamos OK, ahora presionamos Save and close.
Continuaremos creando las historias, de esta manera se visualiza nuestro "board" con las historias
creadas y si seleccionamos Épicas vemos las épicas creadas en nuestro "board". Si volvemos a
presionar Open a la épica o la historia, también tenemos la opción de Follow. Con esta opción
podemos realizar un seguimiento. A su vez, podemos recibir notificaciones de esta épica. También
podemos modificar para realizar "custom notificaciones", es decir, notificaciones personalizadas,
por ejemplo, cuando cambia el estado, cuando cambia de asignado a cambiado y cuando cambió
de iteración o de "sprint". Para esto presionamos OK. A su vez, si presionamos sobre los tres
puntitos en el menú superior derecho de la épica o historia, podemos ver qué otras acciones
podemos realizar con nuestra historia como son eliminar, crear un "template" para campos
personalizados o campos que tomen valores por defecto cada vez que se cree la épica o la historia,
mover el equipo a un proyecto, cambiar el tipo, entre otras. Podemos observar que tenemos
varias pestañas para seguir configurando nuestro tablero, es decir, podemos seleccionar View as a
backlog o ver como listado y de esta manera tenemos las historias ordenadas como una lista. Del
lado derecho tenemos el recuadro de Planning, donde vemos el "sprint" actual y tenemos la
alternativa de agregar un nuevo "sprint". De esta manera concluimos este capítulo.

Servicios de reporte y autoservicio

En Azure DevOps Services tenemos varias opciones para visualizar reportes. Continuamos en la
pantalla de Boards > Boards para, dentro de la misma, presionar la pestaña Analytics o Analítica, e
inmediatamente podemos notar los KPI de Velocity y Cumulative flow diagram. En Velocity
podemos ver el promedio de velocidad de historias, y cuando presionamos View full report
podemos observar el reporte completo. Vemos que tenemos varios estados como son
completado, planeado, incompleto o completado tarde. Tenemos que el gráfico está agrupado por
un conteo de lo trabajado y también permite filtrar o generar un gráfico por la suma del trabajo. Si
presionamos Velocity by y seleccionamos Sum of Effort, no trajo ningún resultado y volvemos con
el gráfico anterior. Volvemos a la pestaña Analytics. Ahora vamos a explorar el Cumulative flow
diagram, para esto presionamos View full report. Aquí podemos ver el promedio del trabajo en
curso. Exploremos en detalle qué nos muestra este gráfico, el cual se utiliza para identificar los
cuellos de botella en los "sprint" y de esta manera realizar acciones correctivas que ayuden a
mejorar el flujo del proceso. Tenemos la opción de filtrar por la cantidad de días en Rolling period.
Por las columnas Done, Doing y To Do, es decir, realizada, en proceso y por hacer. Aquí
seleccionamos todas y vemos el resultado del gráfico. A su vez, si deseamos que este gráfico se
ancle en el panel del proyecto, se realiza de la siguiente manera. Se presionan los tres puntitos del
lado derecho y presionamos Copy to dashboard. Seleccionamos el "dashboard" o panel. Para esto
seleccionamos el predeterminado, Construcción de un edificio de apartamentos Team - Overview
y presionamos OK. Ahora pasemos a Overview > Summary. Aquí podemos observar que las
estadísticas del proyecto se actualizaron con el número de historias de la última semana. También
podemos agregar una breve descripción del objetivo macro del proyecto presionando Add project
description, agregamos la descripción, seleccionamos el repositorio con el nombre de nuestro
proyecto, seleccionamos Wiki y presionamos Save. Vamos a continuar con Overview > Dashboard.
En el "dashboard" o panel podemos agregar gráficos o estadísticas del proyecto y lo podemos
configurar desde aquí mismo simplemente presionando Add widget. Vemos como una amplia
cantidad de gráficos se habilitan del lado derecho y vamos a seleccionar las historias asignadas
hacia mí. Presionamos Add y se agrega de inmediato. También vamos a agregar el "burndown
chart", presionamos Add. Y podemos agregar otros gráficos que nos ayuden a gestionar nuestro
proyecto. Finalmente, adicionamos Lead time y luego presionamos Done editing. Vemos como el
panel se está alimentando con los gráficos que acabamos de seleccionar. Ahora vamos a la
pestaña Overview > Wiki. En esta página podemos si deseamos crear una página de
documentación del proyecto donde todos los miembros del equipo puedan realizar aportes
informativos que ayuden a comprender el proyecto o que en un futuro sirvan de referencia para la
implementación. Presionamos el botón Create project wiki. En este caso se habilita un editor de
texto, colocamos los valores informativos o la documentación informativa relacionada al proyecto
y luego presionamos Save. De esta manera podemos crear toda la documentación relacionada al
proyecto. Por ejemplo, crear un índice con casos de uso, solicitudes, y queda abierto a necesidad
de cambios por parte de los integrantes del equipo, los cuales pueden aportar información cada
vez que deseen. Con esto terminamos este capítulo y esperamos que Azure DevOps Services haya
sido de su agrado.

CA Agile Central, mejor conocido como Rally

Habilidades Agile en Rally
En este curso conoceremos sobre el Rally, la cual es otra herramienta colaborativa para la
administración y seguimiento de los proyectos ágiles. Vale la pena mencionar que en el momento
de realizar este curso no se cuenta con una versión en español y mostraremos las funcionalidades
importantes en el menú en inglés. En primera instancia tenemos la página inicial con varias vistas
rápidas sobre un proyecto. Por ejemplo, tenemos resumen de interacciones, gráfico de quemado
hacia arriba o hacia abajo, historias listas para aceptar, gráfico de tendencia de defectos,
impedimentos, jerarquía de historia (eso es si las historias tienen hijos o si son padres de otras
historias) gráfico de quemado de la iteración. A su vez, se pueden agregar más gráficos
presionando la tuerquita que está en el lado superior derecho. Rally permite configurar la
estructura de los proyectos en portafolios que se derivan en proyectos. En este curso vamos a
utilizar la configuración por defecto, que es la mencionada. Crearemos nuestro nuevo proyecto
desde el icono superior izquierdo al lado de Rally, donde se pueden ver los espacios de trabajo.
Presionamos las herramientas y luego hacemos clic sobre Projects. En este punto podemos ver los
proyectos creados, el "Sample Project", que es un proyecto de ejemplo que viene con la
configuración de Rally. Luego en Actions seleccionamos New project, se despliega una nueva
pantalla donde procederemos a crear nuestro proyecto. Name (nombre), la descripción, el estado
(abierto), notas (que podemos agregar notas o comentarios) y luego presionamos el botón Save.
Vemos el nuevo proyecto creado. Antes de pasar con la creación de historias quiero comentarles
una funcionalidad en esta misma vista y es la de Fields, o campos, aquí en el lado izquierdo. En
esta pantalla podemos agregar campos personalizados a nuestro proyecto para que se complete al
momento de crear las historias. Procederemos a crear un nuevo campo presionando el botón New
field. Este campo lo denominaremos Ciudad. En el Display name también colocaremos Ciudad. El
tipo, texto. No lo colocaremos como requerido porque entendemos que podría repercutir en los
proyectos anteriores o posteriores. Y luego colocamos que sea visible. Presionamos Save and
close. Volvemos a la pantalla del proyecto que acabamos de crear. En Projects, luego
seleccionamos el nombre del proyecto y en esta pantalla observamos el esqueleto del proyecto, es
decir, si tiene hijos, la cantidad de usuarios, iteraciones o "sprints", entregas o "releases". Esto irá
incrementando cuando avancemos nuestro trabajo. Vamos a la pantalla inicial de Home. Para
visualizar nuestro proyecto recién creado necesitamos realizar una configuración. Ahora
presionamos Menú, se ve el menú del proyecto, seleccionamos Home, luego presionamos el
símbolo de más, en Name colocamos el nombre del proyecto, marcamos el "check" de nuestro
proyecto recién creado y presionamos Save and close. Ahora se habilita una pantalla de diseño con
la vista de los indicadores que deseamos mostrar en nuestro proyecto. Primero nos muestra un
[marco] para configurar la pantalla, es decir, una sola columna, dos columnas y tres columnas.
Vamos a seleccionar dos columnas. Luego presionamos Start adding apps y aquí podemos
seleccionar de los indicadores que vimos al inicio. Seleccionaremos Blocked work o impedimentos
y agregaremos otro gráfico. Podemos agregar Custom board, esta nos muestra el tablero Kanban
tal como se define en la metodología ágil. Por el momento vamos a dejar esta configuración de
esta manera. De esta manera puedes visualizar en el lado superior derecho cómo podemos ver
nuestro proyecto. A su vez, ver el plan, hacer la trazabilidad, ver la calidad, el portafolio y los
reportes. Con esta parte tenemos nuestro proyecto configurado y cada pestaña que se habilita va
a permitir agregar información relacionada al mismo.

Diseñando el plan de iteraciones en Rally

En Rally tenemos varias opciones agregadas para planificar nuestras historias de usuario. Cuando
presionamos Plan en el menú, vemos que tenemos cinco opciones. Backlog, que es el listado de
historias de usuario que son priorizadas por "sprint" o iteraciones. En Rally vamos a utilizar el
término iteraciones o "sprint" de manera indistinta, ya que usualmente son periodos de dos a
cuatro semanas en la metodología ágil. User stories, que son las historias de usuario que se están
trabajando en la actualidad. Timeboxes es el lapso de tiempo que vamos a definir por cada
iteración. Team planning se utiliza para conocer la velocidad de acuerdo a la capacidad de puntos
en las historias que el equipo se comprometió. Work views, que es una funcionalidad que permite
personalizar vistas y relacionar proyectos en una relación de padre e hijo. Iniciaremos desde el
menú Plan > Backlog. Comenzaremos creando nuestra nueva historia presionando el botón Add
new. En Work item tenemos la opción de Defecto, User story y Defect Suite. Seleccionamos User
story. En Project seleccionamos el proyecto que acabamos de crear. En Name, o nombre, es el
nombre de la historia. Plan estimate son la cantidad de puntos con lo cual estaremos valorando
nuestra historia, podemos dejarlo vacío o colocar un valor estimado. El Owner es el asignado.
Luego presionamos el botón Create. También podemos crear historias con más detalles
presionando el botón Create with details que está en la parte derecha. En este punto podemos ver
una amplia variedad de campos a completar como son Descripción, Parent, Tags, Release,
Iteration, Milestones, Archivos adjuntos, Notas, el campo Ciudad, entre otros. Esto es, si tenemos
toda esa información a mano, podemos enriquecer esta información inmediatamente.
Continuaremos agregando historias con el botón Add new. Una vez concluida la creación de todas
las historias, podemos colocar, por ejemplo, historias como impedimentos si presionamos el botón
Blocked sobre la historia, colocamos la razón del impedimento y grabamos. También vemos la
cantidad de puntos que tenemos en este "backlog" y el total de historias creadas. A su vez, si
seleccionamos la historia, tenemos opciones de hacer otras acciones sobre esta historia. Ahora
continuaremos navegando desde el menú Plan > Timeboxes. En este punto vamos a planificar el
tiempo estimado de cada "sprint" y agregaremos un estimado con fechas de inicio y de conclusión
presionando Add new con "details". Para esto presionamos el botón Add new y presionamos
Create with details. Ahora iniciaremos a completar cada uno de los valores. Concluimos creando
nuestro "sprint" 3, colocamos las fechas, el estado y presionamos Create. Cerramos aquí y vemos
que los "sprint" creados en la parte de Timeboxes. Continuaremos navegando desde el menú Plan
> User stories. Aquí podemos ver las historias creadas en el "backlog" y vamos a asignar las
historias a los "sprint" y a los "releases" o entregables. Los pasos son extremadamente sencillos,
solo seleccionamos en la columna Iteración y seleccionamos en el "sprint" donde deseamos
trabajar esa historia. Es interesante comprobar como esta herramienta es ágil, ya que plasma la
funcionalidad de lo que significa ser ágil, es decir, podemos tener varios "sprint" para generar un
entregable o un "sprint" puede convertirse en un entregable. En este punto, el "product owner"
siempre deberá estar vigilando las prioridades del usuario y sugiriendo un cambio de prioridades
de acuerdo a las necesidades del negocio. Ahora vamos a dirigirnos hacia el menú Track > Iteration
status. En esta vista podemos tener datos genéricos con varios indicadores sobre el progreso del
"sprint" en curso. El filtro puede también cambiarse con la iteración. De esta manera.
Continuamos con el menú Track > Team board. Aquí es donde podemos observar visualmente el
tablero Kanban y mover las historias si deseamos. De esta manera. Finalmente, podemos notar
que es Rally tiene varias opciones de rastreo y seguimiento del proyecto, permitiendo varias
facilidades y a partir de esto utilizar la que más nos sea favorable. Con esto extendemos las
alternativas de selección con la que el equipo puede visualizar y realizar su trabajo a través de esta
herramienta colaborativa.
Generando reportes sobre el reporte
En este capítulo vamos a navegar un poco sobre funcionalidades importantes en Rally para la
gestión de los proyectos. Vamos a ir a Home y luego Dashboard. En esta pantalla Rally nos muestra
los indicadores más relevantes para cualquier tipo de proyectos, pero también tenemos la opción
de configurar de acuerdo a nuestra conveniencia. Por ejemplo, presionamos el botón de la
tuerquita, y podemos ver una página con un número dilatado de opciones. Si seleccionamos por
Category, podemos conocer los gráficos relacionados a cada categoría. Por ejemplo,
seleccionamos General. Podemos ver guías en inglés de cómo explotar las funcionalidades de
Rally. Luego seleccionamos Boards y podemos ver los diferentes tableros Kanban que podemos
agregar en nuestro "dashboard". Una vez añadido el gráfico, se ancla en la página de Home o
Dashboard, y vale la pena mencionar que esta página puede ser configurada completamente con
un solo clic. Continuemos desde el menú con la opción Reports y luego Reports. Cuando llegamos
a esta página, también podemos agregar reportes con información extendida. Podemos visualizar
el reporte de velocidad, el "iteration burndown" o el gráfico de quemado hacia arriba, el gráfico de
quemado hacia abajo, el gráfico acumulativo, entre otras. Para utilizar uno de estos gráficos,
simplemente seleccionamos el gráfico que deseamos y podemos ver el gráfico generado. El mismo
no contiene información ahora porque todavía no hemos avanzado en nuestro proyecto. En la
opción Page tools podemos descargar el gráfico en formato PDF o JPG, también enviarlo como
correo electrónico o imprimirlo desde la computadora. Por último, navegaremos sobre el menú
Reports > Custom Reports. Esta opción se utiliza para habilitar KPI o "key performance indicators",
es decir, indicadores claves de desempeño. Por ejemplo, podemos conocer la cantidad de tareas
abiertas agrupadas por tal o cual elemento y filtrarlas por un periodo. Esto es realizable de la
siguiente manera. Presionamos Add new, luego vemos un cuadro de diálogo donde dice "I want to
see..." o qué quiero ver. Puede ser el conteo de ítems que he trabajado, la suma del plan
estimado, la suma de tareas actuales, entre otras. En Broken down by es agrupadas por: las que
están bloqueadas, la fecha de creación, entre otras. Vamos a seleccionar en "I want to see..." el
conteo de ítems que he trabajado y vamos a agrupar por la iteración, luego presionamos el botón
Run. Vemos el modelo de reporte, agrupados por los tres "sprint" que creamos y el conteo de
ítems que tiene cada "sprint". También podemos, mediante la tuerquita, grabar, imprimir o
exportar como un archivo CSV dicho reporte. Add apps,

Wrike
Ideando y configurando el proyecto en Wrike
En este capítulo vamos a explorar Wrike. Tenemos la pantalla inicial, que su acceso directo puede
ser a través del botón de la casa ubicado en la parte superior izquierda. A su vez, tenemos los
espacios para poder crear proyectos de tipo personal, de equipos o proyectos con fases. Luego en
el menú de tres líneas horizontales ubicados en la parte superior izquierda, luego de que creemos
un proyecto, este se irá visualizando en esta parte de manera segregada mediante carpetas o
como lo configuremos inicialmente. En el menú del lado derecho tenemos acceso rápidos a mis
tareas, las tareas creadas por mí y a mis favoritos. Luego tenemos las opciones de calendario,
parte en horas, panel de control, informes, carga de trabajo y flujos. Cada espacio de trabajo va a
depender del nivel de visibilidad que desees configurar para los miembros del equipo. Para
nuestro ejemplo vamos a crear un proyecto por fases, primero presionando sobre el ícono
Proyecto por fases, lo cual nos redirigirá a una nueva vista. Presionamos el botón de más que está
al lado de Proyectos y carpetas, colocamos el nombre del proyecto, la fecha de inicio y fecha de
cierre, dejamos seleccionada la opción Proyecto, en la vista predeterminada seleccionamos Lista y
presionamos el botón Crear. Ahora vamos a crear varias carpetas para segregar los "sprint" y
sobre los "sprint" colocar las historias de usuario. Procederemos a presionar el botón de más al
lado de Proyectos y carpetas, seleccionamos Carpeta y colocamos el nombre del "sprint".
Presionamos el botón Crear. Vemos que el "sprint" se creó como carpeta y procedemos a
seleccionar el nombre del "sprint" para que quede debajo del proyecto que acabamos de
construir. Otra manera de agregar los "sprint" es presionar el botón Añadir y seleccionar Carpeta y
colocar el nombre de "Sprint 2". Presionamos Enter y se visualiza el "sprint" debajo del proyecto.
Agregamos un nuevo "sprint". Ahora pasemos a la pestaña denominada Tabla Scrum. Vemos que
tiene la columna Nuevo, En curso y Completado. También tenemos En espera y Cancelado. Sobre
la columna Nuevo podemos agregar nuevas historias de usuario. En esta vista tenemos la limitante
de que solo tenemos campos informativos para conocer el detalle de la historia. Es por esto que
vamos a pasar a la pestaña denominada Lista. También observamos que la historia acabada de
crear no pertenece a ningún "sprint". Seleccionando la historia que acabamos de crear desde la
pestaña Lista, podemos apreciar que podemos ampliar la información relacionada a la historia
agregando la fecha de inicio y cierre y arrastrarla al "sprint" que deseamos. Seleccionamos
nuevamente la historia y observamos el cuadro del lado derecho, donde podemos ampliar la
información sobre la historia. Podemos establecer las fechas, podemos cambiar el asignado,
agregar archivos adjuntos. En este punto, Wrike tiene opciones de agregar archivos adjuntos
desde varios manejadores de contenido como son Google Drive, Dropbox, Box, OneDrive, entre
otras. También tenemos la opción de agregar una subtarea a la historia. Esta contiene los mismos
campos de la historia y también uno la puede ampliar más adelante. Otra opción que tenemos con
Wrike es compartir la historia o tarea vía correo electrónico a los miembros del equipo. En la vista
del lado izquierdo podemos ordenar las historias por todas las tareas, todas las tareas activas y mis
tareas activas. También podemos ordenar por campo, como prioridad, fecha, fecha de
modificación, fecha de creación, estado e importancia. Si volvemos a seleccionar cualquiera de las
historias, se activa nuevamente el menú del lado derecho y también podemos agregar la historia
como favorito, eliminarla de mis tareas o seguirla. Finalmente, para concluir este capítulo,
pasamos a la pestaña de Tabla y vemos como Wrike ha organizado las historias en un cronograma
de trabajo con campos que son relevantes en la gestión del proyecto.

Creando espacios organizaciones dentro de los espacios de Wrike

En este capítulo veremos cómo organizar los espacios. Si vamos a la página principal a través del
menú de la casa o Home, podemos visualizar los espacios creados. Visualizando los espacios, es
importante estructurar de manera armonizada cómo deseamos que se reflejen nuestros proyectos
y "sprint", porque de esta manera permanecerán durante todo el tiempo que utilicemos Wrike.
Vamos a crear un nuevo espacio presionando el botón de más que se encuentra al lado de
Espacios. Seleccionamos en el menú izquierdo Equipo de marketing y luego seleccionamos Gestión
de eventos. El objetivo de este espacio y de los demás espacios es crear todos los proyectos y
"sprint" relacionados a gestión de eventos en este espacio. De esta manera puedes agregar
nuevos espacios para los proyectos que tienen planeado. Volvemos al menú de Home. Luego,
explorando un poco sobre otras opciones y comparando un poco con otras herramientas, vemos
que las funcionalidades de calendarios, parte en horas, panel de control, informes y carga de
trabajo pertenecen a la versión prémium. Podemos navegar un poco de cada sección para conocer
sobre esta. Pasamos a calendario. Vemos como se muestra el calendario basado en el espacio
anteriormente creado. Volvemos a Home. Vemos la parte en horas. Esto significa que podemos
registrar el tiempo dedicado a una historia de usuario en esta sección. Pasamos a panel de control.
Vemos otro modelo de tablero Kanban. Pasamos a la parte de informes, donde podemos crear
reportes personalizados y así como también podemos ver reportes que trae por defecto la
aplicación. Volvemos hacia Home. Carga de trabajo. En este podemos crear un diagrama de carga
de trabajo para conocer cómo se visualiza la capacidad del equipo dentro de los proyectos. Y,
finalmente, flujo. Este flujo provee un historial de información sobre qué se ha hecho en Wrike, es
como un modo de auditoría con todas las actividades que ha realizado el equipo. También se
puede personalizar con filtros y se puede observar todo el registro de lo que se ha hecho en Wrike.
Volviendo a nuestro proyecto y a uno de los "sprint", notamos que Wrike tiene una opción
interesante de editar de manera masiva las historias de usuario. Para esto, procedemos a navegar
a cualquiera de los "sprint", luego seleccionamos el botón de "checklist" que dice Edición masiva,
luego presionamos Seleccionar todas y ahora se activan unas opciones que tenemos disponible del
lado derecho, donde podemos actualizar el estado, moverla de proyecto, copiarla a otro proyecto,
seguir las historias o eliminarlas. Vamos a cambiar el estado a En curso. Y podemos ver el cambio
que se ha realizado de inmediato. Otra opción interesante que ofrece Wrike es la de poder copiar
un enlace, es decir, selecciono la tarea, presiono el botón de "clip" y puedo copiar el enlace de
esta historia o tarea y enviarla a cualquier miembro del equipo y así puede actualizar o conocer el
estado de esta tarea de manera inmediata, esto sin tener que navegar o buscar el proyecto dentro
de Wrike. Ya concluimos este capítulo navegando al botón de Home o página inicial y veremos que
tenemos una opción colaborativa denominada Bandeja de entrada donde podemos crear
mensajes y recibir mensajes. Las acciones colaborativas en este tipo de aplicaciones son bastante
importantes porque en cierta manera muestran qué tan comprometido el equipo está con el
proyecto y a través de interacciones digitales, en caso de que el equipo esté trabajando de manera
remota, pueden beneficiar a todo el proyecto.

Explorando otras opciones en la versión gratuita de Wrike

Iniciaremos este capítulo mostrando cómo Wrike recomienda organizar o esquematizar nuestras
iniciativas de trabajo. Vemos una estructura jerarquizada donde los espacios de trabajo
corresponden a las iniciativas de negocio, estas a su vez se derivan en proyectos y los proyectos los
podemos organizar en "sprint", que a su vez en Wrike significa que son carpetas. También
recapitulemos que una tarea equivale a una historia de usuario. De esta manera podemos realizar
la equivalencia en Wrike sobre la metodología ágil para manejar nuestros proyectos. Volvemos
hacia Wrike. En la opción del menú con los puntos tenemos una opción denominada Papelera de
reciclaje. Cuando navegamos hacia ella, notamos que se encuentran todos los elementos
eliminados anteriormente. Si habías pensado que se eliminan permanentemente, esta opción
puede ser tu salvación en caso de que hayas eliminado algo por error humano. Para restaurar,
simplemente presionamos la historia o tarea o carpeta y luego se activa un botón en la parte
superior derecha denominado Restaurar. Podemos presionar Restaurar o Borrar. Si presionamos
Restaurar, la historia vuelve a donde estaba originalmente. Y si presionas Borrar, se va a eliminar
permanentemente. Vamos a continuar con una opción superinteresante y que ayuda a mejorar la
productividad cuando integramos nuestro trabajo con otras aplicaciones como Zoom, Slack y
otras. Navegamos desde el botón de ayuda y vemos que existe una acción Aplicaciones e
integraciones. Presionamos sobre esta. Luego seleccionamos Más aplicaciones > Extensiones e
integraciones, y esta nos despliega un menú con las aplicaciones disponibles a integrar. Algunas
pedirán unos pasos extras que deberás completar al realizar la integración, como es la de enlazar
el correo electrónico u otros pasos. Concluiremos este capítulo navegando a la administración de
la cuenta. Para esto, vamos a las iniciales del nombre de la cuenta y presionamos Ajustes. Vemos
que en Perfil se encuentra la información básica con los datos de la cuenta y al final encontrarán
las aplicaciones con la cual está integrada en la sección de aplicaciones autorizadas. En la opción
Preferencias de correo electrónico podemos configurar cómo deseamos recibir las notificaciones
sobre actualizaciones de estado, es decir, marcar o desmarcar cuál opción necesitamos que nos
llegue un correo electrónico. Luego en Temas podemos cambiar el diseño de colores al que más
nos guste o utilizar colores alusivos a nuestra empresa. Luego tenemos la opción de gestión de
cuentas, que incluye un menú de usuarios donde podemos habilitar y agregar usuarios nuevos,
también agregar el rol que corresponda. Finalmente, podemos utilizar las funciones de Wrike para
gestionar el proyecto de manera ágil. Como debilidad, observamos la carencia de opciones de
reportería en la versión gratuita, lo cual puede ser decisiva a la hora de seleccionar la herramienta.
También va a costar un poco de tiempo adaptarnos a cómo configurar el proyecto de manera
inicial para que equivalga al formato ágil. Como siempre, la recomendación es la que mejor se
adapte a las necesidades de tu empresa.

Nutcache
Agregando el proyecto al espacio de trabajo de Nutcache
En esta ocasión vamos a tratar sobre una herramienta llamada Nutcache. En la página inicial, la
cual tiene un diseño sencillo con íconos alusivos a cada funcionalidad, comenzaremos a crear
nuestro proyecto. Desde la opción de acceso rápido tenemos dos renglones de trabajo, uno es
crear proyecto y el otro es crear tareas. Vamos a presionar Agregar proyecto. Este tiene los
siguientes campos a completar. Nombre, que será el nombre de nuestro proyecto. Clientes, se
refiere al público objetivo para el cual va dedicado el proyecto. Tenemos la alternativa de crear
nuevos segmentos de clientes. Modelo, el modelo se refiere a cómo vamos a manejar el tipo de
proyecto. Y tenemos el listado de regular, marketing, Scrum, Kanban o vacío. La diferencia entre
Scrum y Kanban en el tablero son las columnas Por hacer, En proceso y Realizadas. Para este
proyecto seleccionaremos Kanban. La opción de Asignar miembros, que es el equipo de trabajo
que va a ser responsable de ejecutar el proyecto. Luego en la sección del lado derecho tenemos la
información relacionada al manejo del proyecto como son la fecha de inicio y fin y el responsable o
gerente del proyecto, así como el estado, la descripción y la visión. Luego presionamos el botón
Salvar. Una vez creado el proyecto, Nutcache nos redirige a la página inicial del proyecto. También
podemos ubicar los proyectos desde el ícono con el maletín del lado izquierdo y podemos notar
que tenemos seis pestañas asociadas al proyecto. La primera es Visión general, que está
compuesta por indicadores. Lista de tareas, que es la pestaña donde estaremos creando las
historias de usuario pertenecientes al proyecto. Aquí tenemos la opción de lista o tablero.
Miembros, que son los responsables que participan en el proyecto. Gantt, lo cual está disponible
para la versión prémium. Presupuesto, que también está disponible solo para la versión prémium.
Archivos adjuntos, que es donde Nutcache permite que los usuarios agreguen archivos. La
limitante de esta es que solo permite adjuntar archivos desde la PC o la máquina en la cual
estemos trabajando. Notas, como su nombre lo indica, son anotaciones para recordar puntos
importantes. Volvemos a la pestaña de lista y comenzaremos a crear las historias. También
podemos observar que solo tenemos tres columnas por defecto. Vamos a agregar una nueva
columna que represente el "backlog". Para eso, presionamos el botón de más en Status y
colocamos el nombre de "Backlog". Arrastramos esta columna al inicio. Iniciaremos agregando las
tareas presionando el botón de más en Tarea. Agregando las historias, notamos que solo tienen
los campos de descripción, fecha de inicio y responsable. Si presionamos sobre la historia,
podemos observar que se despliega un cuadro con muchos más campos para colocar más
información. Por ejemplo, podemos agregar subtareas, lista de comprobación o "checklist",
cambiar el asignado, cambiar la prioridad, agregar etiquetas. Estas opciones de datas planeadas,
tiempo estimado y tiempo registrado están asociadas a la versión prémium. Además, si vemos en
la pestaña de lista, vemos como todas las historias están organizadas en forma de listado.
Volviendo a la opción Tablero, podemos mover las historias sin mayor complejidad. De esta
manera indicamos a los responsables del proyecto que estamos haciendo el trabajo o ya el trabajo
está realizado en la columna Hecho. Con esto podemos tener un conocimiento general sobre
cómo iniciar nuestro trabajo desde el punto de vista ágil utilizando la herramienta colaborativa
Nutcache.

Visualizando los indicadores de seguimiento en Nutcache

En este capítulo iniciaremos a partir de la pestaña Visión general. Las particularidades que
tenemos en esta página son los indicadores de avance que se actualizan a medida que el equipo
avanza la tarea. Tenemos los gráficos Progreso de tareas, donde se visualiza el porcentaje de
cuántas tareas de la totalidad han sido completadas. Tareas por prioridad, que son aquellas que
colocamos algún nivel de preferencia, es decir, prioridad alta, baja, entre otras. Tareas asignadas,
tareas con tiempo excedido y tiempo total. Algo que Nutcache tiene es que los gráficos que vemos
son los disponibles en la versión gratuita, en la versión prémium existen otras funcionalidades y
otros gráficos para personalizar. Vamos a pasar a la pestaña de lista de tareas para conocer cómo
podemos aplicar algunos filtros. Una base en esta pantalla, tenemos la opción de filtrar por el
tablero o filtrar por la lista. Presionamos el botón Filtro, el cual habilita los campos de filtro. En
este punto podemos realizar un [rejuego] con los campos, como asignado, prioridad, etiqueta y
fecha de vencimiento. Podemos colocar algunos valores y presionamos el botón Aplicar. Vemos los
resultados del filtro. Si queremos, podemos limpiar el filtro y la pantalla vuelve a su estado
original. Otra opción de búsqueda en la misma pestaña es la lupita, la cual es un símbolo muy
conocido para la búsqueda. En este punto simplemente colocamos la palabra clave con la cual
deseamos ubicar la historia. Presionamos Enter y se ven las coincidencias encontradas.
Continuaremos con otra opción bastante atractiva para cualquier herramienta colaborativa y es la
posibilidad de crear reglas automatizadas. Vemos que Nutcache tiene la opción en beta en el
momento de crear el curso y vamos a conocer su funcionamiento. Presionamos el botón de regla,
que es un símbolo de rayo que está aquí, luego se activa este cuadro de diálogo y presionamos
Crear una regla personalizada. Esto nos despliega otro cuadro de diálogo para crear la regla a
partir de que se cumplan ciertas condiciones. Vamos a colocar el nombre de nuestra regla. El
nombre de nuestra regla será "Asignar". Cuando la tarea esté creada, la acción que se va a realizar
es asignar a miembro. Luego se activa el cuadro de miembros y colocamos el usuario. Presionamos
Salvar. Vemos que la regla está activa. Y podemos probar esta regla simplemente agregando una
nueva historia y vemos como se va a asignar al usuario que colocamos. Procedemos a agregar la
historia, presionamos Enter y vemos como se asignó al usuario que indicamos en la regla. Con esto
concluimos la exploración de las facilidades que habilita Nutcache para la gestión de nuestro
proyecto ágil.
Importar proyecto a Nutcache desde otras herramientas
En este capítulo vamos a conocer una facilidad destacada y diferenciadora, entre otras
herramientas de manejo de proyectos ágiles, y puede ser decisiva a la hora de elegir qué
aplicación utilizar. La funcionalidad es importar un proyecto desde Trello a Nutcache. Para esto,
presionamos sobre el nombre de usuario y luego se mostrará un submenú. Luego presionamos
Importar proyectos. En la siguiente página tenemos tres opciones para importar. Desde Asana, lo
cual no está aún disponible por lo menos para la versión gratuita, desde Trello y desde un archivo
CSV. En un futuro también se podrá importar desde este tipo de archivos. Iniciemos presionando
la palabra Importar desde Trello. En esta pantalla se muestran los proyectos que tenemos en
Trello. En caso de que no hayamos realizado el proceso de enlazamiento de la cuenta de Trello con
la opción de Nutcache, aparecerá un cuadro de diálogo para aceptar las condiciones, entre otros
pasos. Continuaremos importando el proyecto. Para esto, seleccionamos el tablero, presionamos
Siguiente, observamos que tenemos la alternativa de mapear nuestros usuarios con los de
Nutcache en caso de encontrar coincidencias. Podemos realizar el mapeo para que las historias de
usuario que vienen desde Trello se asignen automáticamente al usuario indicado de Nutcache,
algo simplemente muy útil. Realizamos el mapeo, presionamos Siguiente. En la siguiente pantalla
nos pregunta qué deseamos importar. En este punto seleccionamos cuáles opciones deseamos
importar. Seleccionamos todas las tareas abiertas y archivadas, importaremos todos los archivos
adjuntos e importaremos todos los comentarios. Y presionamos Importar. Aparece un mensaje
que se enviará una notificación una vez todas las historias estén importadas. Luego de verificar
que llegó el correo, podemos validar cómo se importó el proyecto en Nutcache. Validamos que se
creó el proyecto presionando la flechita. Vemos el proyecto "Backlog de obras de ingeniería", el
cual importamos desde Trello. Podemos cambiar esta vista a una vista en recuadro. Y de esta
manera tenemos el listado de proyectos en los cuales hemos trabajado. Si hacemos clic sobre el
proyecto, también podemos ver las historias que se importaron. En conclusión, vemos lo sencillo
que es importar proyectos hacia Nutcache y lo favorable que es utilizar las funcionalidades que
eliminen un posible retrabajo.

Crear un proyecto ágil en Trello

Introducción
En este curso vamos a conocer cómo Trello puede convertirse en la herramienta ideal para el
manejo de los proyectos ágiles. Veremos cómo Trello facilita la transparencia en cada parte del
ciclo ágil que se traduce en un pequeño intragable. Si estás en un proceso de transformación hacia
el mundo digital o simplemente deseas organizar un proyecto de manera ágil, con Trello podrás
generar el seguimiento que necesitas y convertir tus proyectos en realidad. Te invito a capacitarte
en Trello para que puedas llevar tus proyectos desde inicio a fin con resultados exitosos.
Asimismo, llevando a cabo cada una de las ceremonias Scrum con Trello e identificando de
inmediato los puntos de mejora o de bloqueo que generalmente se presentan en el proyecto y
cómo puedes accionar sobre esto al instante.

Realizar el taller de levantamiento de ideas

Resumen exprés sobre metodología ágil
Existen muchas herramientas que se pueden utilizar para gestionar un proyecto de manera ágil
basado en el marco de trabajo Scrum, el cual es el más digerible y fácil de entender en cualquier
entorno. Es por esto que, previo a conocer las bondades de Trello y cómo esta aplicación gratuita
ha desarrollado funcionalidades que engloban el proceso de Scrum, vamos a conocer un poco de
qué se trata Scrum, su terminología básica y el flujo de trabajo que se sigue cuando se gestionan
proyectos utilizando Scrum.

En el gráfico que vemos a continuación podemos observar el proceso de cómo se resume sin
ningún desperdicio el flujo de trabajo en Scrum, que es un ciclo iterativo que busca generar
pequeños entregables a través de "sprints".

Vamos a definir cada elemento de esta representación visual de Scrum para que en capítulos
posteriores puedas conectar con cada funcionalidad en Trello. Iniciamos con "visión".

- La visión es el objetivo macro o a muy alto nivel sobre el propósito del negocio o del
proyecto. Generalmente, en este punto del proyecto puede considerarse que tiene
muchos elementos de ambigüedad.
- Continuamos con "user stories" o historias de usuario. Son requerimientos iniciales sobre
qué características o funcionalidades deberá cumplir el proyecto. En este punto tenemos
requerimientos a considerar a un mediano nivel de detalle. Recordemos que la
nomenclatura para crear una historia de usuario es "yo, como rol, necesito alguna
funcionalidad para cumplir un fin"
- "Product backlog" o listado de historias de usuario: es la relación total de todos los
requerimientos identificados en un punto con el proyecto. Recordemos que el "backlog"
es un producto vivo que puede incrementarse o disminuirse en el tiempo en base a la
priorización del dueño de negocio o del mercado.
- "Sprint planning": es la planeación del "sprint". Esta es una ceremonia que reúne a todo el
equipo para desmenuzar o desglosar cada una de las historias, agregar más detalle,
generar criterios de aceptación, asignar a los responsables de ejecutar la historia, entre
otras. En esta ceremonia se asigna una puntuación basada en el esfuerzo que conlleva
implementar esta historia. Sobre la estimación del esfuerzo muchas veces se utiliza la
 puntuación basada en la serie Fibonacci, pero también se pueden utilizar otras unidades
de medida
- "Selected product backlog". Luego de puntuadas y aclaradas las dudas en la ceremonia de
la planeación, el próximo paso es agrupar las historias por pequeñas metas que
llamaremos "sprints". En este punto seleccionamos las historias que van a generar el
mínimo producto viable que el cliente acepta como producto y que puede utilizarlo
inmediatamente y partiendo de que es consciente de que no es un producto completo.
- "Sprint backlog": es el listado de historias de usuario que se van a trabajar en el "sprint".
- "Sprint" es el periodo de tiempo definido por el equipo, que puede ser de una y hasta
cuatro semanas, con el cual el equipo se compromete a trabajar las historias de usuario
identificadas en la ceremonia de planeación.
- "Daily Scrum": esta es una ceremonia de alineación del equipo que se efectúa de manera
diaria y que no debe sobrepasar los 15 minutos. En el "daily" o "stand-up meeting" , el
Scrum Master realiza las siguientes preguntas. ¿Qué se hizo ayer?, ¿qué se va a realizar
hoy? y ¿cuáles son los impedimentos?
- "New functionality": es la nueva funcionalidad acabada en el "sprint".
- "Sprint review": es una ceremonia donde se demuestra al cliente lo ejecutado en el
"sprint", es decir, es una demostración en vivo sobre las historias concluidas en el "sprint".
- "Sprint retrospective": es la ceremonia del equipo que permite realizar una introspección y
adaptación sobre las oportunidades de mejora del equipo sobre el "sprint" que acaba de
concluir. Existen varias técnicas de retrospectiva disponibles en línea y que sirven para
generar participación y que cada miembro del equipo genere una apertura para aportar
sus ideas, que buscan siempre mejorar.
- Y finalmente tenemos el equipo, que consiste en el Scrum Master, que es el rol dentro del
equipo que tiene como objetivo remover los impedimentos y asegurar que el equipo
colabore basado en los valores de la metodología ágil. El "product owner", que se encarga
de definir el "product backlog" y priorizar las historias. Y el equipo o "team" es el equipo
ejecutor de las historias de usuario y en este equipo debe participar todo aquel que tenga
un rol en la ejecución o implementación del proyecto.

Organizar el taller de levantamiento de historias de usuario

Iniciemos estableciendo qué es un taller de descubrimiento. Un taller de descubrimiento es
simplemente el punto de partida donde vamos a conocer cuáles son las necesidades de nuestros
usuarios o clientes.

En el taller de elicitación de requerimientos o levantamiento de historias de usuario debemos

establecer un objetivo, involucrar al cliente o usuario final del proyecto. En este taller debemos
identificar a las personas involucradas o al equipo completo que va a implementar el proyecto.
Cuáles son las personas que tienen el poder de tomar una decisión, las personas que tendrán el rol
de consultores en el transcurso de proyecto y aquellos que hay que mantener informados. Por
otro lado, debemos establecer las preguntas ¿qué necesitas?, ¿para qué lo necesitas?, ¿por qué
lo necesitas?, ¿cómo lo has hecho previo al proyecto?, ¿cuándo lo necesitas y dónde lo
necesitas? Más adelante puedes fortalecer el "backlog" realizando entrevistas individuales y un
trabajo de campo u otras técnicas de elicitación de información, dependiendo del proyecto que se
trate para agregar nuevas historias o dar forma a las que ya se levantaron.
Una vez dentro de Trello, nos ubicamos en la pantalla inicial o la página principal a través del ícono
que dice Trello. Luego tenemos tres opciones en el menú izquierdo que son Tableros, Plantillas e
Inicio. Todas se utilizan para ayudarnos con los tableros. Luego podemos observar los espacios de
trabajo que hemos utilizado recientemente y tenemos la opción de crear nuevos tableros. Vamos
a presionar Plantillas y en esta se despliegan todas las opciones de acuerdo al área o la industria
de trabajo. Aquí puedes seleccionar la que más se adecue a tu industria. Ahora vamos a crear
nuestro tablero y lo nombraremos 'Proyecto de despliegue de página web para comercio
electrónico - Taller de descubrimiento' . Podemos seleccionar el espacio de trabajo y la visibilidad.
Luego presionamos Crear. En nuestro taller determinamos que vamos a tener varias áreas y
características o "features" de la empresa que estarán involucradas y estas áreas la vamos a crear
como lista. Simplemente colocamos el nombre de nuestra lista y presionamos Añadir lista.
Finalizamos con la historia de la empresa. Así vemos todas las áreas temáticas que hemos
identificado en nuestro taller de descubrimiento. Luego que hemos determinado las áreas y en el
conversatorio del taller se arrojó la necesidad de cada área y qué se necesita para implementar
cada página al proyecto, de manera sencilla iremos agregando cada historia o épica debajo del
área temática del requerimiento, es decir, podemos presionar Añadir tarjeta y colocamos la
historia. Presionamos Añadir tarjeta. Así podemos ir agregando cada necesidad debajo de cada
área temática.

Continuemos explorando las funcionalidades oportunas de cara al proyecto que estamos

trabajando. Presionemos Mostrar el menú y nos desplazamos un poco hacia abajo y observamos
Power-Ups, luego hacemos clic sobre Añadir Power-Ups. En la siguiente pantalla de búsqueda
aparecen los diferentes "power-up" o potencializadores de Trello. Aquí podemos realizar una
búsqueda en el campo y colocamos "fields", de esta manera aparecen diferentes "power-up" para
personalización de campos. Vamos a utilizar Smart Fields y vamos a seleccionar Añadir, y vemos
que se activa un botón de Smart Fields en el tablero. Cerramos aquí. Vamos a crear un nuevo
"smart field". Presionamos Smart fields, seleccionamos New field, colocamos el nombre 'Estrategia
de negocio', podemos seleccionar un color, que sea de tipo texto y presionamos Crear field. Si
presionamos sobre la tarjeta y seleccionamos Estrategia de negocio, podemos colocar un valor,
'Ventas', y de esta manera se ve este nuevo campo asociado a la estrategia de negocio de ventas
en el área temática de página inicial con la historia o épica que acabamos de crear. De esta manera
puedes continuar agregando campos fundamentales de ágil y de la terminología de tu negocio,
con la salvedad de que no conviertas las historias en un formulario que luego sea muy difícil de
completar para el equipo.

Crear categorías o épicas de las historias de usuarios y desglosar tareas

Iniciaremos conociendo y creando las etiquetas, las cuales podremos reconocer posteriormente en
el proceso de trabajo de nuestro proyecto y en qué nivel de detalle o qué tan compuesta o
atómica esté definida en Trello el enunciado que estemos seleccionando.

En ágil tenemos tres elementos fundamentales y son épica, historia de usuario y tarea, lo cual
estamos asemejando a un árbol genealógico, como podemos ver en la imagen de la derecha.

- Por ejemplo, una épica es un requerimiento o una historia que puede ser divisible en más
de una historia por su grado de complejidad. A medida que avances en el mundo ágil y te
vuelvas más experto, podrás identificar fácilmente una épica debido a que su solución o
 implementación conlleva a otras dependencias o a algo mucho más extenso. En nuestro
ejemplo, los abuelos constituyen la épica de nuestra historia, porque es evidente que la
historia es larga.
- La historia de usuario es el requerimiento o requisito que debe tener una funcionalidad en
específica. En este caso los esposos o la pareja son la historia y, por ejemplo, dentro de
nuestra historia un criterio de aceptación dentro de este gráfico es que deben ser hombre
y mujer. Los criterios de aceptación se utilizan para establecer las pruebas e indicar si la
historia cumple o no cumple el objetivo.
- Finalmente tenemos las tareas. Las tareas son un elemento finito que no se puede dividir
y que son independientes. Para nuestro ejemplo, los niños son nuestra tarea porque son
elementos pequeños con un solo objetivo.

Veremos qué tan fácil es crear las etiquetas en Trello. Solo tenemos que seguir los siguientes
pasos. Seleccionamos cualquiera de nuestras historias haciendo clic. Vemos que existen pocos
campos disponibles para agregar información como son la descripción, comentarios, y podemos
tener una conversación con el miembro del equipo. Una de las ventajas de Trello es que es como
una página en blanco, completamente personalizable y que pone a disposición alternativas
colaborativas que estamos ya familiarizados con otras plataformas. Continuando con los pasos de
agregar las etiquetas, presionamos el botón Mostrar menú, luego hacemos clic en Más,
presionamos Etiqueta, colocamos el nombre de la etiqueta, presionamos Crear una etiqueta y
seleccionamos el color naranja y presionamos Crear. Vamos a crear la etiqueta de la historia.
Colocamos el nombre de la historia, presionamos Crear una nueva historia, seleccionamos el color
verde y presionamos Crear. Finalmente crearemos la etiqueta de tarea. Seleccionamos el color
amarillo y presionamos Crear. Ya están creadas todas nuestras etiquetas y ahora vamos a colocar
etiquetas en cada una de las historias de las áreas temáticas que tenemos identificadas en el taller
de descubrimiento.
Seleccionamos la primera historia. Si leemos el enunciado de la historia, podemos rápidamente
identificar que es una épica. ¿Por qué es una épica? Porque dice "yo, como usuario, necesito el
menú con cuatro secciones principales para mostrar a mis clientes" Inmediatamente, cuando se
menciona "cuatro secciones", yo puedo crear una historia por cada sección, es decir, que esta
historia puede ser divisible en más historias de usuario. Por ende, debemos clasificarla como una
épica. Para clasificarla simplemente presionamos Etiquetas y seleccionamos Épica. Y así de sencillo
podemos identificar que es una épica. Continuaremos clasificando todas nuestras historias en lo
que resta de este curso. De esta manera podemos visualizar cómo nosotros clasificamos nuestras
historias en épica, historias y tareas.

Realizar la planeación de los Sprints

Establecer el alcance y período del Sprint
Vamos a organizar las historias en pequeños entregables que van a aportar el valor que el cliente
necesita a corto plazo, que anteriormente definimos como "sprint". En primera instancia tenemos
que hacer un mapeo o reconocer cuál es el alcance [y] objetivo de nuestro "sprint". Como
podemos ver en el gráfico, tenemos maquetas o bocetos de posibles opciones de página web
destinadas para el comercio electrónico. En el lado izquierdo tenemos una página para escritorio y
en el lado derecho una para móvil. Con estos gráficos también vemos que la misma se dividen en
diferentes diseños. Estos diseños podemos delimitarlos y hacer que los mismos sean nuestros
"sprint" de acuerdo a las áreas temáticas que definimos. Lo que buscamos con esta ilustración es
precisamente identificar cuál sería la prioridad de nuestro "sprint" o cuál sería la prioridad de
nuestro lanzamiento de nuestra página web, que podría ser, por ejemplo, lanzar la página de
ventas.

Vamos a continuar en Trello para fijar las historias que van a preceder unas sobre las otras. Para
esto creamos un nuevo campo en el "smart field" que se denomine 'Prioridad'. Seleccionamos
Smart field, creamos "new field", colocamos el nombre de 'Prioridad' y seleccionamos el verde a
turquesa. Presionamos Crear field. Inmediatamente se ve el campo en las historias. Luego que
agregamos todas las prioridades a cada una de las historias y conociendo un poco más sobre
Trello, podemos agregar este tablero como favorito, ya que contiene el listado global de
requerimientos de nuestro proyecto. Para esto presionamos la estrella que se encuentra en la
parte superior derecha del menú. En esta misma línea podemos compartir el tablero a otras
personas simplemente presionando el botón Invitar. Aquí podemos enviar una invitación por
correo electrónico o crear un enlace y compartirlo nosotros mismos por los medios de
comunicación, ya sea otros medios digitales.

Por último, en este mismo submenú debemos mencionar el espacio de trabajo sobre el cual
estamos gestionando nuestro proyecto. El espacio se utiliza para englobar todos los tableros
referentes a una iniciativa en específica. Podemos cambiar el espacio de trabajo simplemente
haciendo clic en el espacio de trabajo y seleccionando Cambiar espacio de trabajo. Luego podemos
dirigirnos a ver los espacios de trabajo disponibles y desde allí crear uno nuevo. En fin, podemos
crear un espacio de trabajo nuevo presionando el botón Crear y luego Crear espacio de trabajo. Se
colocan los datos que pide el recuadro y se crea un nuevo espacio de trabajo de acuerdo a la
necesidad o iniciativa que estés implementando en ese momento.
Puntuar historias en base a su complejidad y añadir criterios de aceptación
Te voy a mostrar cómo se realiza la técnica de planeación del juego de póker o "poker planning", el
cual busca a través de una técnica de juego un consenso sobre el esfuerzo que representa trabajar
una historia o ética. Usualmente, conocemos la estimación basada en el tamaño de la camiseta o
la estimación basada en los números de la serie de Fibonacci.

En la ceremonia de planeación nos reunimos con todo el equipo que va a trabajar el "sprint" y
empezamos a estimar de acuerdo al grado de complejidad que cada miembro del equipo entiende
conlleva realizar ese esfuerzo. Vale la pena considerar que cuando tenemos equipos con
diferentes grados de experiencia, es decir, una persona recién graduada de la universidad, una
persona júnior o un sénior, muchas veces la puntuación puede diferir entre cada miembro del
equipo. El trabajo del Scrum Master también conlleva a calibrar ese mix de experiencias para que
la información y el traspaso de conocimiento florezca entre cada miembro del equipo. El "poker
planning" se efectúa de la siguiente manera. Establecemos cuál es la medida de estimación que
puede ser con los tamaños de la camiseta, como S para "small" o pequeño, M para mediano, L
para largo y así sucesivamente. O podemos tomar los números de la serie de Fibonacci, que van
desde el 1, 2, 3 hasta 100, como vemos en la siguiente ilustración. Además, existen opciones de
realizar la puntuación en línea a través de una página de Internet. Pero si tienes acceso a cualquier
llamada por videoconferencia o tienes la posibilidad de realizar la planeación en sitio con el
equipo, la mecánica es leer cada historia en conjunto con el "product owner" y realizar preguntas
y aclaraciones sobre cómo se quiere la historia y otros detalles. Basados en la explicación
proporcionada por cada integrante del equipo, pues se puede tener un estimado.
Luego el equipo se prepara para votar. Deben tenerlo bien anotado o disponer de cartas con la
estimación seleccionada y luego, al unísono, cada uno debe mostrar cuál ha sido su votación. En
caso de que existan estimaciones muy dispares, lo ideal es que en la misma reunión quien ofreció
la mayor estimación explique el porqué de esta puntuación y también quien ofreció la menor
puntuación. Seguidamente a la justificación, se repite la votación hasta que la puntuación quede
más o menos equilibrada.

Vamos a pasar a la creación del campo de "story points". Para eso seleccionamos Smart fields,
presionamos New field, colocamos el nombre del campo, dejamos que el tipo de campo sea
numérico, seleccionamos un color, que puede ser rojo, y presionamos Crear field. Ahora vamos a
agregar la estimación a cada historia. Colocamos el valor a cada una de las historias y, ahora que
tenemos puntuadas todas las historias, vamos a agregar la sumatoria de puntos que contiene cada
área temática a través también de "smart field". Presionamos Smart field, luego seleccionamos List
summary, seleccionamos en Story points, Sum, dejamos el color púrpura y procedemos a cerrar.
Vemos como se ve la sumatoria de puntos en cada historia. Con esta información, y en conjunto
con la prioridad, se puede direccionar al "product owner" sobre cuáles son las historias o épicas en
las cuales debemos enfocar el alcance del primer "sprint" y los subsiguientes. Con esta
información que tenemos a simple vista en nuestro tablero, podemos iniciar a delimitar cuáles son
las historias que debemos contemplar en nuestro primer "sprint" y concientizarnos sobre el
esfuerzo que tomaría al equipo ejecutar todas esas historias.

Identificar las historias asociadas al primer sprint

Vamos a crear un nuevo espacio de trabajo. Lo denominaremos 'Página web para el comercio
electrónico' El tipo de espacio de trabajo, seleccionaremos Marketing, y en la descripción
podemos colocar el mismo nombre, presionamos Continuar. Aquí podemos colocar los miembros
del espacio de trabajo o añadirlo más tarde, seleccionamos Más tarde. Vemos nuestro espacio de
trabajo creado. Ahora volvemos a nuestro tablero. Vamos a proceder a cambiar nuestro tablero de
taller de descubrimiento al nuevo espacio creado. Para eso, presionamos el nombre del espacio y
presionamos Cambiar el espacio de trabajo. Seleccionamos el espacio que acabamos de crear y
presionamos Cambiar. Vemos como Trello inmediatamente realiza la actualización. Ahora vamos a
crear un nuevo tablero. Para esto presionamos Crear tablero, en el siguiente recuadro colocamos
el nombre de nuestro tablero, que es igual al nombre del proyecto más "sprint 1", seleccionamos
el espacio de trabajo y la visibilidad la dejamos en Espacio de trabajo. Presionamos Crear. Vemos
nuestro tablero nuevo creado y vacío. Ahora vamos a crear nuestro flujo de trabajo y para esto
crearemos las columnas Por hacer, En proceso y Realizado.

- En la columna Por hacer colocaremos el listado de historias de usuario representativas

para el "sprint" y que el equipo en la ceremonia de planeación identificó, son las historias
que se necesitan hacer para lograr el objetivo del "sprint".
- En la columna En proceso corresponde a las historias de usuario que están en marcha. Y,
por último,
- en la columna Realizado son las historias que cumplen con los criterios de aceptación que
se definieron para dicho requerimiento.

Vamos a navegar a nuestro tablero del "product backlog" o taller de descubrimiento. Este se
puede realizar a través del menú izquierdo o a través del menú donde dice Reciente. Ahora vamos
a mover las historias que están predestinadas para ser trabajadas en el "sprint" 1. Para esto
presionamos el botón con el lápiz en la historia, seleccionamos Mover, seleccionamos el tablero
destino, que corresponde a nuestro tablero del "sprint" 1, seleccionamos la lista Por hacer y
dejamos en la posición 1, luego presionamos Mover. Vemos como el área temática queda vacía y
la historia se transfirió a nuestro "sprint" 1. Vamos a seleccionar otra historia. Ahora volvemos al
tablero del "sprint" 1 y confirmamos que las historias se movieron tal cual.

Continuamos nuestra configuración del "sprint" estableciendo las fechas de compromiso. Para
esto hacemos clic sobre el lápiz, seleccionamos Editar fechas y colocamos las fechas de las dos
semanas que va a conllevar nuestros "sprint". Presionamos Guardar. Trello tiene la opción de
enviar un recordatorio configurable de acuerdo a las alternativas de la lista. Continuaremos
colocando la fecha a las demás historias.

Dentro del mundo ágil, para alcanzar con mucho más claridad en qué consiste la historia debemos
considerar las tareas, que son las actividades limitadas y específicas de un todo. En Trello, las
tareas las podemos representar con un "checklist". Para esto presionamos sobre cualquier
historia, seleccionamos Checklist y procedemos añadir los "checklist". Recordemos que el título
del "checklist" debe ser representativo de acuerdo a la historia de usuario. En estos "checklist"
vemos que podemos asignar a miembros del equipo, asignar fechas específicas para cada
"checklist" y convertir a tarjeta. Vamos a convertir a tarjeta, debido a que esto es una épica y la
convertiremos a una historia de usuario. Podemos notar como se agregó el "checklist" como una
historia por hacer. Vamos a editar esta tarjeta y vamos a colocarla con la nomenclatura de historia
de usuario. Presionamos en el nombre de la historia o el "checklist" y la convertimos a historia con
el formato o nomenclatura de una historia de usuario. Luego para esta historia la podemos
clasificar como anteriormente lo hicimos, con una etiqueta como historia, luego el equipo le
concederá la puntuación que amerite. También podemos notar que podemos adjuntar archivos o
enlaces a la historia haciendo clic sobre Archivo adjunto en la misma. En este punto se visualiza
que tenemos varias alternativas para adjuntar, por ejemplo, desde la computadora, desde Box,
Dropbox, Google Drive, entre otros.

Ejecutar el Sprint
Iniciar el Sprint, personalizar botones y crear reglas para automatizar actividades
En este video vamos a colocar las fechas de compromiso de manera automática cada vez que
añadimos una historia en la columna de En progreso. También podemos hacer ese ejercicio
cuando agregamos historias desde el "product backlog" o taller de descubrimiento. Para realizar
esto, seguimos los siguientes pasos. Presionamos el botón de Automatización, luego presionamos
Reglas. Esto nos dirige a una nueva pantalla. Presionamos Create rule. Notamos que la pantalla
está en inglés, pero podemos continuar realizando la automatización de la regla. Para esto
presionamos Create rule, el botón azul. Luego presionamos Add trigger. Un "trigger" es un
desencadenante de acciones a partir de que se cumpla una condición, y se ejecuta de manera
inmediata. Tenemos varias opciones para nuestro desencadenante como Card move, Card
changes, Dates, Checklist, Card content y Fields. Vamos a seleccionar Card move. En esta
seleccionamos cuándo la tarjeta es añadida a la lista En proceso por "anyone". Presionamos el
botón de más, luego vamos a agregar la acción. En la acción también tenemos varias opciones a
ejecutar. Para nuestro caso seleccionamos Fecha y colocamos la fecha en que finaliza nuestro
"sprint". Presionamos el botón de más y luego presionamos el botón de más también. Vemos
como se va formando la regla. Una traducción a esto sería cuando una tarjeta es añadida a la lista
En proceso por quien sea, la acción es colocar la fecha de compromiso en la fecha que va a
finalizar el "sprint". Luego presionamos Save. Vemos que automáticamente la regla está habilitada
en nuestro tablero. Vamos a proceder a probar la regla. Utilizamos una de las historias que
provinieron de la épica inicial y la vamos a mover a la columna En proceso. Vemos como
automáticamente se colocó la fecha de finalización de nuestro "sprint". Continuando con este
proceso de automatización, vamos a crear un botón que genere un listado de chequeo para tareas
comunes. Para esto presionamos sobre el botón de automatización, luego seleccionamos Botones,
se visualiza una nueva pantalla y sobre esta presionamos Create button, es el botón azul que está
aquí. En la siguiente pantalla colocamos el nombre de la regla en el recuadro que vemos "Button
name", dejamos este "check" marcado, significa que va a estar habilitado por "default" o de
manera predeterminada, presionamos Add action, seleccionamos en esta sección Checklist y
vamos a agregar nuestros "checklist" para nuestras historias. Colocamos el nombre de "checklist"
'Contenido', luego agregamos la lista de chequeo o el contenido al "checklist" de contenido.
Finalmente, agregamos nuestro último elemento a la lista de chequeo, presionamos el botón de
más. Finalmente, vemos la estructura de nuestro botón con el nombre de Verificar contenido. El
"checklist" se llama Contenido, los elementos del "checklist" son revisar formato, texto y
ortografía de cada página, colocar enlaces y colocar botón de realizar pedido. Presionamos Save.
Vemos como queda habilitado el botón en este tablero, ahora procederemos a probar dicho
botón. Seleccionamos una de las historias, agregamos un "checklist" denominado 'Contenido',
presionamos Añadir y luego presionamos el botón que acabamos de crear. Vemos como los
elementos del "checklist" se generaron automáticamente.

Generar acciones basadas en el calendario y las fechas comprometidas en el Sprint

Vamos a conocer qué acciones podemos realizar basados en el calendario de nuestro proyecto.
Por ejemplo, podemos agregar una historia diaria a determinada hora en la columna de Por hacer
para recordarnos hacer el "daily meeting". Para esto vamos a seguir los siguientes pasos.
Presionamos Automatización > Crear regla, luego seleccionamos Calendar, luego presionamos
Create command, este botón azul. En la siguiente pantalla tenemos un botón para añadir un
"trigger" o desencadenador, presionamos sobre el botón. Luego seleccionamos Everyday. Ahora
vemos las opciones que tenemos en Trello sobre cómo podemos configurar nuestra acción de
[área]. Simplemente vamos a agregar una tarjeta, colocamos el nombre de la tarjeta y colocamos
en la lista Por hacer. Presionamos el botón de más. Vemos como se ha creado nuestro siguiente
comando de la siguiente manera. El desencadenador es que cada día se va a ejecutar la siguiente
acción. Presionamos Save. Vemos que el comando está habilitado en este tablero, y presionamos
Cerrar.

Debido a que esta opción o comando solamente lo podremos probar al siguiente día, también
podemos ejecutar la prueba por el botón de automatización para comprobar que se haya creado
satisfactoriamente. Para esto presionamos Automatización > Reglas, vamos a nuestra regla de
calendario y vemos este botón que dice Run now, presionamos este botón y vemos que el
comando se ejecutó satisfactoriamente. Ahora vamos a nuestro tablero y bajamos un poco en la
columna de Por hacer y observamos nuestra tarjeta creada.

Vamos a continuar automatizando nuestro tablero creando una nueva regla. Presionamos
Automatización > Reglas, seleccionamos Due date, presionamos Create command, vamos a
presionar a Trigger y vamos a colocar una regla que sirva de recordatorio dos días antes que la
tarjeta esté próxima a vencer. Para esto hacemos lo siguiente. Seleccionamos dos días antes que la
tarjeta esté próxima a vencer, presionamos el más, luego en este caso vamos a agregar un
contenido a la tarjeta. Colocaremos un comentario y presionaremos Más. Vemos como se creó el
comando. Ahora presionamos Save y esta automatización realizará un recordatorio cuando la
tarea esté próxima a vencer. Con esta demostración concluimos la configuración de las reglas
automáticas tomando en cuenta nuestro calendario y las fechas comprometidas en el "sprint".

Visualizar el cronograma de cada Sprint

Luego de establecidas todas las fechas de nuestras historias para el "sprint" en curso, tenemos una
funcionalidad en la versión prémium de Trello que nos muestra de forma visual cómo cada historia
está entrelazada entre sí y cómo a través del cronograma que facilita Trello podemos ver las
conexiones con nuestro entregable. Para esto procedemos a presionar en el menú del tablero y
luego seleccionamos Cronograma. Una vez ubicados en el cronograma, podemos apreciar el
cronograma filtrado por semana, lo cual podemos cambiar por día, mes, trimestre y año. Si
jugamos un poco con estos filtros, podemos ver cómo se ven las historias a lo largo del año o de la
selección que tengamos. Vemos como las historias se muestran en la fecha que tienen como
compromiso de entregar. Al lado también podemos filtrar por lista, que es la opción
predeterminada. Podemos ver que podemos filtrar por lista, miembro, etiqueta y ninguno. En la
opción Más lista podemos visualizar como se cambia la vista del cronograma sobre las tareas por
hacer, en proceso y realizado basados en el mes. A su vez, podemos seleccionar una de las
historias que están sin programar y arrastrarlas sobre las fechas que tenemos en el cronograma e
inmediatamente Trello va a hacer un cambio en las fechas de compromiso. Vemos como esta
cambió la fecha de vencimiento una vez la arrastramos. Si continuamos filtrando por miembro,
también podemos ver las tareas asignadas por sus miembros. En nuestro caso todavía no hemos
asignado a los responsables de las historias de usuario.
Continuamos con el filtro de etiqueta. En este sentido, podemos ver como las historias están
agrupadas por historias, épicas o los demás colores que nosotros hemos denominado las
etiquetas.

Finalmente, cuando seleccionamos Ninguno, podemos ver las historias como una vista normal de
un calendario, es decir, sin agrupación por miembro, etiquetas, etc. También, al igual que en el
calendario, podemos añadir historias haciendo clic en el botón Añadir tarjeta o lista. Con esta
demostración seguimos sacando provecho a obtener mayor visibilidad para el seguimiento de
nuestros proyectos ágiles utilizando Trello.

Generar tablas o generar información para utilizarlo en Excel

En nuestro tablero, desde la opción Mostrar menú, vamos a conocer cómo exportar la información
del tablero a Excel u otro formato. Para esto presionamos Mostrar menú. En este submenú
podemos acceder a la configuración de etiquetas, colecciones, elementos archivados, configurar
correo electrónico, podemos seguir el tablero, convertir en plantilla, copiar, imprimir y exportar,
así como también podemos copiar el enlace para compartirlo por otros medios de comunicación.
En nuestro caso vamos a presionar Imprimir y exportar. Observamos como se habilita un recuadro
con la función de imprimir y exportar a formatos CSV o JSON. Cuando presionamos Imprimir,
vemos un PDF con el detalle por columnas del tablero. Con esta opción podemos imprimirlo hacia
la impresora o grabarlo como un PDF. Ahora continuemos importándolo a formato CSV.
Presionamos el formato CSV y podemos notar que el archivo se descargó en nuestro explorador.
Ahora vamos a abrir nuestro archivo CSV en Excel y lo vamos a convertir para que sea legible para
cualquier persona. Para esto presionamos en el menú Datos > Obtener datos > Desde un archivo
de texto o CSV, seleccionamos nuestro archivo, esperamos un momento y observamos como
Excel, porque es un archivo CSV, es decir, las columnas están separadas en coma, podemos ver los
datos de nuestro tablero. Ahora presionamos Transformar datos y vemos como la información de
nuestro tablero está en Excel. Con esto podemos realizar o manipular, ya sea en gráficos o en otras
funcionalidades de Excel, la información que tenemos en el tablero. Desde la página anterior, una
vez presionamos Transformar y cargar, se abre el archivo en el Excel que abrimos en blanco.
Ahora, permaneciendo en el mismo submenú, vamos a convertir nuestro tablero en plantilla para
que este sirva de modelo para los demás "sprint". Presionamos Convertir en plantilla y luego
Convertir en plantilla. Vemos que en la parte superior del tablero podemos ver que los miembros
de este espacio de trabajo pueden crear un nuevo tablero a partir de esta plantilla. Esto es útil
cuando tenemos que crear un nuevo "sprint" para continuar nuestro proyecto.

También podemos compartir la plantilla presionando en el botón Compartir plantilla. Vamos a

probar creando un nuevo tablero a partir de la plantilla. Para esto presionamos Crear tablero a
partir de plantilla. Aquí se habilita el recuadro para colocar el nombre del tablero, simplemente
cambiamos a "sprint" 2 y lo dejamos en nuestro proyecto. Podemos conservar las tarjetas, pero no
lo vamos a hacer porque estaremos tomando de las tarjetas de nuestro "product backlog" o de
taller de descubrimiento. Y luego presionamos Crear. Vemos como se crea nuestro nuevo tablero,
el "sprint" 2. Este tablero lo podemos personalizar de acuerdo a las necesidades o historias de
usuario del "sprint" 2.
Conocer las fechas de los entregables mediante el calendario
Tener un calendario personal o de trabajo nos permite organizarnos en el día a día o en el mes y
hasta en un año sobre reuniones, vacaciones o días feriados en nuestro país. Todo esto tiene el
objetivo de planificarnos a corto y a mediano plazo. En Trello, con la peculiaridad del calendario
podemos planificar nuestros "sprint" [vocalmente] con el soporte del calendario. Para esto, en la
opción de tablero seleccionamos Calendario. Inmediatamente vemos un calendario. Sobre las
preferencias del filtro podemos seleccionar día, semana y mes. De manera predeterminada en la
vista tenemos la visualización por mes y, navegando o filtrando en la vista, podemos ver los
objetivos del mes, de la semana o del día. También podemos avanzar o retroceder semanas o
meses posteriores y ver el comportamiento sobre las historias que tenemos asignadas. Trello en
esta misma vista te permite agregar una tarjeta o una lista en el calendario simplemente
presionando el botón Añadir. Vemos que se habilita Lista o Tarjeta. Podemos agregar tarjeta y
agregar el título de la historia de usuario. En la columna de Por hacer podemos colocar fecha de
vencimiento y luego presionamos Añadir tarjeta. Otra forma de agregar una tarjeta es haciendo
doble clic sobre la fecha y también podemos colocar el nombre de la tarjeta en la columna Por
hacer y agregar la fecha de vencimiento y presionamos Añadir tarjeta. Vemos como la tarjeta se
crea inmediatamente en la fecha que colocamos. También podemos añadir una lista. Por ejemplo,
colocar el nombre de dependencias. La misma va a tener el objetivo de colocar aquellas historias
que tienen una dependencia, es decir, dependen de un tercero para que puedan ser trabajadas.
Colocamos la posición y presionamos Añadir lista. Esta se va a reflejar en nuestro tablero. Una
funcionalidad interesante es sincronizar este calendario con el calendario personal. Esta opción no
necesariamente sería con la del calendario personal, ya que podemos importar este archivo e
importarlo en el calendario personal o en el calendario de trabajo y tener alineadas las fechas de
las actividades administrativas del día a día con la del objetivo de nuestro proyecto. Para esto
presionamos Sincronizar con el calendario, luego presionamos Habilitar y copiamos el enlace que
se ha generado. Una vez copiamos este enlace, podemos importar este archivo .ics en nuestro
calendario personal o de trabajo. En conclusión, la vista de calendario es una parte interesante de
Trello que nos ayuda a orientar cada historia con las fechas que establecimos al inicio de nuestro
"sprint".

Seguimiento a través del panel para conocer métricas

En el panel veremos los radiadores de información en forma de gráficos que se cargan mediante
los datos y el trabajo realizado en Trello. Esta funcionalidad es parte de la edición Business.
Procederemos a presionar el tablero en la parte superior derecha, y tenemos la opción Panel,
presionamos Panel. Logramos contemplar cuatro gráficos.

- El primero es Tarjetas por lista, que es un histograma que en el eje vertical contiene la
cantidad de tarjetas o historias de usuario, y en el horizontal las columnas con el estado de
nuestras historias.
- También tenemos el gráfico de Tarjetas por fecha de vencimiento. En él podemos ver, por
ejemplo, la cantidad de historias que están completadas, que vencen pronto o que
carecen de fecha de vencimiento. Esta información es importante para el Scrum Master,
ya que le permite dar un seguimiento especializado en el "sprint" y que todo el trabajo
fluya de manera constante para poder cumplir con las expectativas de nuestro "sprint".
 - Luego seguimos con Tarjetas por miembro, que es otro histograma que en el eje vertical
tiene la cantidad de historias y en el horizontal los miembros o responsables, así como las
historias que no tienen ningún asignado. Aquí podemos ver la cantidad de historias, y vale
la pena mencionar que debemos evitar comparaciones con las asignaciones de historia
porque la estimación de la historia es relativa por la experiencia y otros factores a
considerar por cada colaborador del equipo.
- Seguimos con las tarjetas por etiqueta. En este histograma Trello agrupa, basados en las
etiquetas, la cantidad de historias que posee cada una. Aquí podemos ver la cantidad de
historias épicas y tareas.
- En esta misma línea, Trello permite al administrador agregar otros gráficos. Agregamos
uno de la siguiente manera. Presionamos el botón de más que está ubicado debajo de los
gráficos anteriores, se despliega un recuadro con tres formas que podemos seleccionar,
gráficos de barra, circular o de líneas. Seleccionamos el gráfico circular y presionamos
Siguiente. Seleccionamos Tarjetas por etiquetas, luego presionamos Añadir mosaico.
Vemos el gráfico en nuestra página y podemos eliminar el histograma que muestra la
misma información y así tener varios tipos de gráfico en nuestra página. Lo realizamos
haciendo clic sobre los tres puntos en el histograma por etiquetas, seleccionamos sobre
los tres puntos que están en tarjetas por etiqueta y luego presionamos Eliminar. Trello
tiene un limitantes en esta vista sobre cómo podemos generar más gráficos con otros
datos de nuestro tablero, pero podemos compensar esta carencia con los "power-up" que
otras aplicaciones ofrecen. Con esta explicación terminamos de explorar las ventajas que
nos ofrece el panel.

Explorar el mapa interactivo del proyecto

Para proyectos que estén relacionados con la cadena de suministro o con logística de distribución,
una excelente funcionalidad que nos provee Trello es la del mapa interactivo, que podemos
utilizar para agregar historias de usuario desde una ubicación específica en el planeta. Eso es una
funcionalidad de la edición Business. Procedemos a presionar Tablero en la parte superior
izquierda y luego seleccionamos Mapa. Vemos el mapa y vamos a navegar hacia mi ubicación.
Podemos hacer doble clic sobre el mapa y vemos que se habilita la opción de agregar tarjeta desde
la misma ubicación. Cualquier gerente de proyectos que necesite utilizar ubicaciones geográficas
estaría fascinado con esta funcionalidad, viendo cuando se habilita el recuadro para agregar
información en la tarjeta, solo se requiere el título o la historia. Procedemos a agregar la historia,
luego seleccionamos en la lista de por hacer y, por último, presionamos Añadir. Vemos como se
habilita una ubicación geográfica, la cual es nuestra historia. Si hacemos clic, podemos ver como se
habilita lo que colocamos como historia. También podemos agregar una historia desde el botón
Añadir una tarjeta que está ubicado en la parte superior derecha. Presionamos Añadir tarjeta,
colocamos la historia y en la ubicación podemos escribir el nombre de la ubicación. Seleccionamos
Santiago de los Caballeros, que está ubicado en República Dominicana, en la lista o columna de
por hacer y presionamos Añadir. Vemos como la historia queda incrustada en el mapa con el ícono
de la ubicación en el punto de referencia. Si hacemos clic, también podemos observar la historia
agregada a nuestro mapa. A su vez, si hacemos clic sobre el lápiz, sobre la historia, vemos que la
historia se comporta como si estuviese en nuestro tablero, es decir, que podemos abrir la tarjeta,
editar etiquetas, cambiar el miembro responsable, cambiar portada, mover, copiar, editar fechas o
archivar. De esta manera podemos gestionar nuestro proyecto ágil de una manera visualmente
muy atractiva.

Configurar opciones de visibilidad y permisos en el proyecto

En este capítulo vamos a conocer sobre qué podemos hacer con la configuración de los tableros,
los miembros del equipo y otras opciones. En resumen, veremos qué alcance tienen los miembros
del equipo en cuanto a los tableros que manejan, cómo podemos extender la visibilidad del
tablero al colocarlo como público o restringido solo a los miembros del equipo, entre otras
funcionalidades que brinda la versión Business. Para esto presionamos el botón Trello, sobre
nuestro tablero seleccionamos la opción Configuración y veremos uno a uno cada pestaña de
configuración. Iniciemos por la pestaña de tableros. En esta opción podemos ordenar los tableros
por orden alfabético o descendente, o por el más activo o el menos activo, como podemos ver.
También podemos filtrar los tableros si los tenemos organizados por colecciones. Por ejemplo,
podemos crear una colección para proyectos, mantenimientos, mejoras, anomalías o incidentes.
Para esto solo presionamos sobre el campo Filtrar y presionamos Crear colección. Otra opción que
tenemos en esta pestaña es que podemos filtrar por el campo de búsqueda y colocar el nombre
del tablero en caso de que tengamos varios tableros en nuestro proyecto. Continuando en la tabla
de espacio de trabajo, en esta opción tenemos una búsqueda más avanzada a través del botón
Filtrar. Podemos seleccionar cualquiera de los tableros que tenemos y podemos observar las
historias de usuario que posee dicho tablero. Sin presionamos el botón Marcador, este generará
un enlace sobre este tablero, el cual podemos compartir a través de otros medios de
comunicación o por redes. Continuando en la pestaña Miembros, esta sección tiene la posibilidad
de invitar a otros colaboradores mediante correo electrónico. En la pestaña de Power-Ups
tenemos una relación de los "power-up" habilitados por cada tablero. Luego, continuando con la
pestaña de Exportar, tenemos la alternativa de exportar nuestro tablero en formato CSV o en
formato JSON para aquellas personas que son más técnicas. En definitiva, con esta funcionalidad
podemos migrar nuestro proyecto hacia otra aplicación o hacia Excel. También podemos ver el
historial de exportaciones. Continuamos con la pestaña Configuración. En la pestaña Configuración
podemos configurar la visibilidad de cada una de las opciones de nuestro tablero o espacio de
trabajo, es decir, podemos limitar quiénes pueden crear tableros, eliminar y a su vez podemos
conectar el espacio de trabajo con Slack, lo cual es otra aplicación de mensajería. Finalmente, en la
pestaña de facturación, que pertenece a la edición Business, podemos ver el resumen de las
informaciones importantes relacionadas al pago de la cuenta.

Revisión y retrospectiva de un Sprint

Preparar demo y conocer la velocidad del equipo a partir de las historias completadas
A continuación conoceremos cómo gestionar la ceremonia de revisión a través de Trello, lo cual es
una parte fundamental en el flujo de trabajo de Scrum. La revisión no es más que presentar una
demostración del producto una vez finalizamos un "sprint".

Esta ceremonia es una ceremonia básica en el ciclo de vida del proyecto ágil. Este ritual se debe
efectuar al finalizar el "sprint" y el objetivo es mostrar al "product owner" o dueño del producto o
al cliente cuáles fueron las historias que se completaron y qué tan potable se encuentra el
"sprint" para realizar un despliegue o entrega al cliente, con el paliativo de que es un producto
inconcluso y en continua evolución. Habitualmente, la ceremonia es una demostración en vivo del
producto o una demo. Con este método iniciamos el proceso de familiarización del producto y con
la retroalimentación del cliente, a su vez, podemos canalizar en futuros "sprint" qué mejoras
ameritan, y además estaremos calibrando nuestro listado de historias de usuario con una
apreciación constructiva del propio cliente sobre cómo está quedando el producto. En esta
oportunidad vamos a crear un tablero nuevo denominado Revisiones. Con este tablero lo que
buscamos es documentar todas las retrospectivas de cada "sprint" en un solo tablero.
Procederemos de la siguiente manera. Presionamos Crear un nuevo tablero, colocamos el título,
Visible para el espacio de trabajo, y Crear el tablero. Ahora, basados en una estimación o
proyección de cuántos "sprint" vamos a tener en nuestro proyecto, vamos a agregar una lista por
cada "sprint". Por ejemplo, debajo de cada columna podemos agregar una tarjeta que represente
la demo. En esta tarjeta estaremos guardando, por ejemplo, una presentación en PowerPoint con
el video de la presentación o cualquier otro documento que forme parte de esta demostración.
Luego procedemos a agregar tarjetas o historias debajo de la columna que se esté realizando la
demostración. Por ejemplo, el cliente sugirió en la demo que le gustaría ver una nueva
funcionalidad para tal o cual cosa, eso lo agregamos debajo de la columna indicada. Por ejemplo,
agregamos esta sugerencia, agregamos una nueva más y así sucesivamente podemos ir agregando
todas las sugerencias que se identificaron en la demostración. Posterior a concluir la demo, el
"product owner" o dueño del producto analizará con el equipo para que en un futuro "planning"
se desglose dicha historia y su factibilidad. También se conversará en qué futuro "planning" esta
historia es más conveniente o factible trabajarla. Al igual que en otros tableros, a este tablero le
podemos agregar etiquetas o personalizarlo de acuerdo a como entendamos.

Conversar con el equipo los aprendizajes identificados en el Sprint que acaba de finalizar
Existen varias técnicas que se utilizan para romper el hielo y obtener que el equipo completo
participe en la ceremonia de retrospectiva, que tiene como objetivo principal generar la
transformación intrínseca dentro del equipo para que su desempeño mejora en el siguiente
"sprint". La retrospectiva no es más que generar una inspección abierta dentro del equipo sobre
las oportunidades de mejora encontradas en el "sprint" finalizado. Luego de concluida la demo,
el siguiente paso es la retrospectiva. Con esta buscamos que el mismo equipo realice una
inspección individual y grupal sobre las cosas que pueden mejorar dentro del proceso ágil del
proyecto. En ese sentido, solo el equipo es quien conoce los obstáculos que de alguna manera
impidieron concluir con las historias que quedaron incompletas. Sobre esto, el Scrum Master
tomará nota sobre este conversatorio para realizar los ajustes que sean necesarios para mejorar
este flujo. Así como también a partir de esta información se puede tomar la temperatura del
equipo en el sentido de qué tan acoplados están los colaboradores con sus actividades del día a
día del proyecto.

En el siguiente "slide" quiero mostrar varias técnicas de retrospectiva muy conocidas, que luego
vamos a representar en Trello mediante un tablero. La primera es obtener reacciones dentro del
equipo realizando encuestas. Podemos utilizar encuestas en línea gratis, ya que hay varias
herramientas en Internet para generar una conexión con la audiencia. La siguiente es crear un
tablero Kanban con las columnas Empezar a hacer, Continuar haciendo y Dejar de hacer. Con estas
el mismo equipo, a través de los Post-it o tarjetas en Trello, genera sus observaciones basados en
el "sprint" finalizado. La tercera es la técnica del dado, donde el dado tiene las caras de lo bueno,
lo malo y lo feo. Por ejemplo, si estuviésemos todos en una misma sala, el moderador de la
ceremonia o alguien del equipo lanza el dado y cualquier colaborador toma la iniciativa para
conversar sobre qué cara quedó hacia arriba luego de lanzado el dado.

En esta oportunidad vamos a crear un tablero denominado 'Retrospectivas'. Procedemos a

presionar el botón Crear, luego Crear tablero, colocamos el nombre en el espacio de trabajo de
nuestro proyecto, la visibilidad sobre el espacio de trabajo y presionamos el botón Crear. Ahora
crearemos las columnas Empezar a hacer, Continuar haciendo y Dejar de hacer. Con esto
permitimos que cualquier miembro del equipo añada tarjetas cuando estemos celebrando la
ceremonia de retrospectiva. Procederemos a agregar las tarjetas. Es importante mencionar que en
esta ceremonia debemos conversar con los miembros del equipo de modo muy abierto y con el
objetivo de mejorar para que al final de la reunión el equipo quede con el compromiso de mejorar
aquellos puntos que se trataron en la reunión. Otra forma de enriquecer nuestro tablero es
agregando pegatinas. Las mismas se utilizan para agregar reacciones. Para esto presionamos el
botón Mostrar menú, presionamos Pegatinas y procedemos agregar la pegatina en la tarjeta que
entendamos.

Continuar con el siguiente Sprint

Una vez hemos concluido con todas las ceremonias del "sprint" y generado el entregable
correspondiente, es momento de reiniciar nuevamente nuestro ciclo ágil con una nueva meta o
alcance definido para nuestro producto.
 Recordemos que el "product owner" es quien selecciona y prioriza las historias del próximo
entregable a partir del "product backlog" o listado de historias de usuario. Sobre esta selección se
origina el nuevo "sprint" o las historias propias de ese "sprint". El próximo paso es iniciar la
ceremonia de planeación, donde discutiremos el "sprint backlog" y puntuaremos aquellas historias
que no estén puntuadas para luego iniciar con la ejecución del "sprint", llevando a cabo todos los
días las reuniones diarias de 15 minutos para que, una vez finalizado el "sprint", ejecutemos la
ceremonia de revisión y retrospectiva. Continuaremos con la creación de nuestro nuevo tablero
para el próximo "sprint". Dependiendo de dónde nos encontremos en Trello, ya sea en un tablero
o en la página inicial, podemos crear el nuevo tablero, es decir, podemos crear un nuevo tablero a
partir de presionar Crear un nuevo tablero desde aquí o presionar el botón Crear tablero desde el
botón Crear. Pero, para evitar retrabajo, vamos a proceder a crear nuestro nuevo tablero a partir
de una plantilla, es decir, presionamos el botón Plantilla y se van a heredar las columnas de En
proceso, Tareas por hacer y Hechas. Colocamos el nombre de nuestro próximo "sprint" y dejamos
Espacio de trabajo con el nombre de nuestro espacio de trabajo, con la visibilidad de espacio de
trabajo y procedemos a crear nuestro próximo "sprint" a partir de la plantilla. Presionamos Crear.
Como podemos ver, heredamos las historias de un "sprint" anterior, lo cual pudiésemos haber
eliminado si hubiésemos desmarcado el "check" de heredar historias. Simplemente en este caso
tenemos que depurar las historias de usuario que no corresponden al "sprint". Y si algunas de
estas provienen del "sprint" anterior, se utilizarán en este "sprint". Es decir, podemos archivar esta
tarjeta y de esta manera quedará eliminada de este nuevo "sprint". Las demás pueden continuar
en el proceso de trabajo del "sprint" actual si quedaron como deuda técnica del "sprint" anterior.
Con esto hacemos un reinicio del ciclo utilizando Trello.