Principios del Manifiesto Ágil para Equipos Eficientes

Clase 4 de 17 • Curso de Gestión de Equipos Ágiles

Clase anteriorSiguiente clase

Sandra Sierra

student•

Caso práctico:

Accionables:

Definir tamaño del sprint (+corto si hay +incertidumbre)
Escribir HU y priorizarlas con el cliente
Presentar al final de cada sprint el valor / incremento funcional
Involucrar al cliente en las etapas del proyecto
Ceremonias y espacios para mejorar la comunicación
Excelencia técnica para lograr un mejor producto

LEONARDO DELGADO

student•

Hola Sandra, a la última situación le agregaría también la X en el principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Muy buen análisis,

Juan Fernando Utria Guisado

company_admin•

Hola Sandra, a la parte de ceremonias y espacio, ya que la ruta tomada no ha sido efectiva, yo presentaría un cambio de canal de comunicación ya que el actual no ha dado resultados.

Lisset Alexandra Neyra Romero

student•

Resumen de la Clase Principios • Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. o ¿Qué es lo valioso para el cliente? • Principio 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. • Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. • Principio 4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. • Principio 5: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. o Cuando las personas están motivadas es entre el 15% y 20% más productivos. • Principio 6: El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. • Principio 7: el software funcionando es la medida principal de progreso. • Principio 8: Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. • Principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. • Principio 10: la simplicidad, o arte de maximizar la cantidad de trabajo no realizado es esencial. • Principio 11: las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. • Principios 12: a intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Patricio Sánchez Fernández

student•

Gran resumen, Lisset. Felicitaciones.

José Javier López López

student•

El equipo no vive los valores y principios ágiles y en específico:

_Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción. _

Entrega de Producto Frecuentemente

El cliente está muy molesto porque no le aceptan cambios en el alcance.

Satisfacción del Cliente con entrega continua y temprana de valor
Aceptamos que los requisitos cambien

Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.

Comunicación cara a cara
Los responsables de negocio y desarrolladores trabajan juntos de manera cotidiana

_Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias. _

Ritmo sostenible
El software funcionando es la principal medida de progreso
La simplicidad

El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.

La atención continua a la excelencia técnica

Marcelo Taco

student•

Como líder de un equipo, ¿cuánta tolerancia posee para las equivocaciones? Por ejemplo: si un miembro del equipo desea realizar una tarea de una forma que usted sabe que es errónea, ¿lo dejaría aprender de la experiencia? Reláteme alguna experiencia.

Andrés Felipe Salcedo Sepúlveda

teacher•

Hay una técnica en Management 3.0 que se llama delegation póker. Consiste en determinar 7 niveles de empoderamiento por cada tarea. De esta forma se determina el riesgo y que nivel de tolerancia se puede tener al error en cada actividad.

Si el riesgo es bajo, se asume el error en favor del aprendizaje. De igual forma, creo que siempre se puede opinar y sugerir (esto promueve el debate y la interacción), que es diferente a decirle a otros lo que tienen que hacer (esto promueve la opresión).

Platzi Team

student•

No se hace participe al cliente. No se hacen revisiones periódicas de avance. comunicación impersonal. No se permite el cambio en el transcurso del desarrollo.

Andrés Felipe Salcedo Sepúlveda

teacher•

Bien Rodolfo, añadiría también que el equipo no tiene un ritmo de trabajo sostenible.

Luis Camilo Fernandez Gomez

student•

https://docs.google.com/document/d/1NW-gi7UGrUzZp0akQJoT-pkMEYIk2iZiUwEgEl4R9Kk/edit?usp=sharing

Ejercicio realizado

Edwar Y. Castillo B.

student•

Cristian Giovani Carbajal Herrera

student•

En este caso, el equipo no está aplicando varios principios ágiles clave:

Principio 1, 2 y 3: No entregan software funcional frecuentemente y no aceptan cambios tardíos. Se recomienda implementar sprints cortos con entregas parciales y aceptar cambios priorizados.
Principio 4 y 6: La comunicación con el cliente es lenta y por correo. Deben establecer reuniones frecuentes cara a cara o por videollamada para resolver dudas rápido.
Principio 7: El avance debe medirse con software funcionando, no con tareas internas.
Principio 8: Jornadas de 10 horas no son sostenibles. Es mejor mantener un ritmo constante que permita calidad y motivación.
Principio 9: No deben eliminar casos de prueba, ya que compromete la calidad. La excelencia técnica debe ser prioridad.
Principio 12: Deben hacer retrospectivas periódicas para mejorar sus procesos.

Aplicando estos cambios, el equipo podría ser más ágil, entregar valor antes y recuperar la confianza del cliente.

Lady Diana Camelo Ramirez

student•

Comparto el ejercicio practico:

Magno Alarcón

student•

Profesor, de acuerdo con el principio 2, aceptamos que los requisitos cambien, pero digamos ya se acordó una fecha de entrega del producto y el cliente necesita hacer cambios urgentes, como se negocia esto?, lo aceptamos pero le decimos que atrasará la entrega del producto?

Andrés Felipe Salcedo Sepúlveda

teacher•

Hola Magno, uno de los aspectos clave de la agilidad es que el cliente hace parte del equipo. Los proyectos tradicionales fracasaban desde la década de los 90 según The CHAOS Report de Standish group, por falta de involucramiento del cliente, las prácticas ágiles emergen como una respuesta esto. Si el cliente no hace parte del equipo, no se está haciendo algo muy diferente a como se gestionaban proyectos en los 90.

En este caso, el cliente al hacer parte del equipo debe entender que toda decisión tiene un impacto, todo cambio es aceptado en agilidad pero reconociendo y aceptando desde todas las partes el impacto que tiene el cambio (en lo positivo, como en lo negativo)

Ana Maria Rojas Alcaraz

student•

Acciones a tomar:

Definir un sprint, tener claros los objetivos para comenzarlo
Definir historias de usuario para garantizar entregas frecuentes de valor
Hacer partícipe al cliente del desarrollo de software o producto
Realizar dailys
Capacitar mejor a los desarrolladores en su conocimiento técnico
Al final de cada sprint realizar un review

Paola Andrea Gómez Ariza

student•

Se tienes los siguientes criterio de la problemática:

3 años lleva un producto que no se ha podido entregar

Cliente insatisfecho

Baja o nula comunicación y adecuada frente a los desarrolladores y el negocio (cliente)

Porcentaje de avance no esperado y no hay estructura de un plan de trabajo.

Se debe partir de un cambio:

coordinar una sesión con el equipo y el negocio para llegar a los diferentes acuerdos, aceptar los cambios de los requisitos

Llegar a un acuerdo en consultar con el cliente que espera como primera entrega y que es lo que realmente se va comprometer a entregar para no generar altas expectativa.

Generar sprints de trabajo de cada 15 días y dar seguimiento oportuno utilizando dailys de cómo va con el desarrollo y qué tipo de stopper están incurriendo por las demoras.

la comunicación se debe trabajar por ambos canales, correo electrónico para tener evidencias y sesiones de trabajo para que la justificación sea aún más clara de lo que se requiere en el producto.

Motivar al equipo y tener buen acercamiento.

Pactar con el cliente fechas de entregas significativas para que esté conforme con el trabajo y la planeación que se está ejecutando

Mantener la agilidad y la excelencia del cumplimento

Recordar al equipo que las tareas al ejecutar deben ser autogestionadas

Reflexionar con el equipo en que podemos mejorar y optimizar el tiempo de actividades llevando un Project con fechas definitivas para proceder a un buen seguimiento estructurad.

Diana Paola Muñoz Prada

student•

Buenas tardes compañeros, a continuación mi solución al caso propuesto:

Como se evidencia en la imagen, el equipo actual en mi opinión no está cumpliendo ninguno de los 12 principios de Agilidad, por eso ahora que se puede hacer para que esto cambie, relaciono algunos accionables a tener en cuenta:

Contratar a una persona especializada en metodologías agiles (Scrum Master)
Identificar quién es el Product Owner, el equipo de desarrollo y el usuario final.
Identificar claramente cuál es la necesidad qué tiene el usuario final.
Realizar una lista ordenada de lo que se requiere para obtener el producto final.
Priorizar las actividades para generar valor en menor tiempo.
Identificar cuáles son las estimaciones en cuento a recursos y tiempos para desarrollar el producto. (Tener en cuenta impedimentos)
Listar los cambios que se tengan durante el desarrollo por parte del usuario final.
Agendar reuniones diarias con todo el equipo, para conocer los avances que se tienen y los impedimentos para continuar el desarrollo.
En caso de tener dudas sobre el desarrollo del producto, agendar reuniones con el usuario final para refinar las actividades a realizar.
Agendar reuniones periódicas para mostrar el avance que se tiene en el desarrollo del producto.

Atenta a sus comentarios, gracias!

Patricio Sánchez Fernández

student•

Excelente.

Leonardo Ippolito

student•

Caso Practico:

Estamos frente a un equipo que durante 3 años ha desarrollado un producto que no ha salido a producción.

--> Evidentemente debemos fraccionar en pequeños entregables y alcanzables.

El cliente está muy molesto porque no le aceptan cambios en el alcance.

--> En cada entregable tendrá un alcance , y en cada sprint nuevo podemos ir realizando cambios, mejoras, evolucionando en el valor de cada entregable y aceptando así simplemente los distintos nuevos alcances que surjan por las razones que sean, cambio en el negocio, expectativas del clientes,etc.

Los desarrolladores culpan del retraso al usuario, ya que tarda semanas en responder por correo las dudas que tienen sobre el producto.

--> Aquí tanto el equipo de desarrollo, pruebas y el equipo cliente/Negocio deben trabajar siempre en conjunto. Diariamente un tipo de comunicación cara a cara, codo a codo.

Como el porcentaje de avance no es el esperado, la gerencia ha exigido a los desarrolladores trabajar jornadas de 10 horas diarias.

--> En la medida que los entregables se puedan ver se palpara como progreso, es lo más motivante, es palpable el crecimiento, las mejoras propuestas por los equipos serán auto gestionables en futuras etapas, ir así hacia la simplicidad, la apertura de nuevas ideas, modificaciones.

El equipo ha decidido eliminar algunos casos de prueba para recortar la brecha de tiempo en el plan de trabajo.

--> En la atención continua de un proceso ágil genera un desarrollo sostenible, un ritmo constante desde la simplicidad.

Carlos Antonio Bin

company_admin•

El principio 11, es esencial para un adecuado funcionamiento de equipos, dado que la intervención de lideres, jefes, gerentes.... minimiza su autogestión, por ende, es sumamente importante dejar, sin descuidar el crecimiento y organizacion propia de los equipos.

Laura Anguiano

student•

¿Cómo poder trabajar con un cliente que no sigue estos principios? Tu equipo y tú liderando el equipo pueden hacer gran parte, pero ¿qué pasa cuando tu cliente no está entrenando en agilidad? ¿Qué puedes hacer?

Andrés Felipe Salcedo Sepúlveda

teacher•

El cliente no tiene porque estar entrenado en Agilidad, al final se trata es de hacerle parte del proceso de creación del producto pidiendole que aporte lo que ya como cliente por naturaleza tiene, que es su feedback producto de la interacción con el producto. Él no tiene que hacer algo diferente a compartir sus sensaciones y opiniones.

Atenas Barrios Pacheco

student•

Principios del Manifiesto Ágil que no se están aplicando:

Entrega continua de software funcional: El producto no ha salido a producción en 3 años.
Colaboración con el cliente sobre negociación contractual: No se aceptan cambios del cliente.
Respuesta ante el cambio más que seguir un plan: Rechazan ajustes en el alcance.
Comunicación cara a cara: Se depende de correos con largas demoras para una respuesta.
Sostenibilidad del desarrollo: Jornadas de 10 horas no son sostenibles.
Excelencia técnica y buen diseño: Se eliminan casos de prueba, comprometiendo calidad.

Acciones para ser más ágiles:

Implementar entregas incrementales y frecuentes.
Involucrar activamente al cliente en revisiones y decisiones.
Usar reuniones breves y frecuentes para resolver dudas rápido.
Promover una cultura de mejora continua en vez de castigar con más horas.
Asegurar la calidad manteniendo los casos de prueba.

Paula Elizabeth Llumiquinga Guevara

student•

Problemas:

No se toma en cuenta la satisfacción del cliente, ni las modificaciones.
El cliente comenta falta de iteraciones en el producto. Se mantiene unilateral la perspectiva y se omite la visión del usuario al que está destinado el producto.
Tiempo largo de entregas sin estructura.
Se omite tanto el trabajo colaborativo constante como la eficiencia de la comunicación.
Debido a las fallas de comunicación, el largo tiempo de desarrollo y la falta de información no hay un equipo motivado.
Al no tener suficiente información el equipo no puede auto-organizarse y tener libertad creativa.

Soluciones:

Definir cual es la necesidad específica del cliente y que considera que sería valioso (¿Cuál es la visión del producto?, ¿Cuáles son las necesidades latentes que no expresa?) para el producto entregable.
Reorganizar la información sobre las necesidades del cliente y los hitos alcanzables dentro del desarrollo del producto, dejando de lado las suposiciones e iniciando un mejor contacto con el cliente.
Reorganización y establecimientos de sprints. Dentro de estos sprints se debe priorizar las modificaciones esenciales (de fondo) y dejar las modificaciones de forma para la finalización del proyecto.
Realizar una sesión rápida de revisión, sea presencial o por videochat, con la finalidad de obtener más información sobre el requerimiento del cliente, cuales son los hitos ya alcanzados hasta el momento y establecer un backlog optimizado.Del mismo modo establecer periodos de revisión con el cliente para poder comprender las necesidades y las iteraciones necesarias.
Al explorar mejor las necesidades del usuario y la visión que tiene del producto, se puede lograr que los desarrolladores se vinculen de manera más directa, además al resolver dudas puede aumentar el entendimiento del proyecto y permitir la motivación a alcanzar logros, ya que si no se comprende la finalidad de un proyecto difícilmente el equipo conectara con el trabajo y querrá alcanzar los objetivos.
Es necesario establecer las iteraciones que se deseen sobre el producto realizado, o iniciar un nuevo proyecto con mayor claridad en los objetivos, necesidades y tiempos de entrega, con la finalidad de que el equipo pueda organizar backlog, trabajar bajo sprints claros y optimizar las entregas.

Leonel Oswaldo Cabrera Alvarado

student•

Hola, después de revisar el texto del caso y los principios vinculados al manifiesto ágil, considero los siguientes puntos para buscar revertir la situación y lograr un mejor equipo:

1. Se tendría que trabajar con el cliente para entender claramente lo que requiere, involucrándolo como parte del equipo de definición, lo que nos lleva a definir un alcance más claro

2. Generar una planeación acorde al nuevo alcance y dividirlo en iteraciones cortas con objetivos claros para lograr alcanzarlos en ese tiempo.

3. Generar revisiones con el cliente de los avances y validar posibles ajustes en la planeación para lograr incrementar el valor de las entregas de cada iteración, buscando generar un reléase con mayor valor posterior a dos o tres iteraciones cortas.

4. Integrar al equipo en sesiones cara a cara para lograr que entiendan muy bien el alcance, el objetivo y el por que su trabajo es importante en cada iteración. Hacerlos responsables de lo que tiene que generar cada uno.

5. Considerar que las pruebas son parte importante para lograr una entrega de calidad y con valor al cliente, por lo que hay que integrar al equipo de pruebas en todo momento y lograr trabajo en paralelo para sumar el valor y lograr los objetivos.

Quedo al pendiente de la retro.

Erick Arellano

student•

No hay interacciones entre el equipo de trabajo y el cliente.

No se está colaborando con el cliente para cambios del proyecto sobre la marcha

Plan

Realizar historias de usuario con las necesidades del cliente retomando los casos eliminados.
Pactar un compromiso con cliente para realizar una reunión semanal mínimamente para revisión de los avances de las historias de usuario.
Realizar un spring con las historias de usuario en su spring backlog.
Revisar las historias de usuario ya en el definition of done con el cliente en la reunión semanal para dar el visto bueno o si tiene alguna necesidad diferente retomar esta.