Serie 100 Cortos ágiles

1. La agilidad no es moverse más rápido. Ser ágil es moverse en la dirección correcta creando el camino correcto

2. La agilidad no es una meta. Ser ágil es un camino de transformación y mejora continua

3. La agilidad no es Scrum o Kanban. Ser ágil es una mentalidad que valora las personas, el cambio, la entrega de valor y la mejora continua.

4. El cambio exponencial que impulsa el desarrollo tecnológico exige de organizaciones ágiles enfocadas en valores y principios que impactan positivamente al cliente.

5. Las organizaciones ágiles emplean equipos pequeños y autónomos, dan importancia a sus interacciones y a la mejora continua de su desempeño.

6. Las organizaciones ágiles utilizan ciclos cortos de trabajo que facilitan la entrega frecuente de productos, incrementa la interacción con el cliente y el aprendizaje conjunto.

7. Las organizaciones ágiles incrementan la transparencia. Hacer visible el trabajo de todos mejora la comunicación y el aprendizaje, y reduce la complejidad.

8. La agilidad no son sólo mejores resultados. Ser ágil es reflexionar frecuente y profundamente sobre los procesos y cómo mejorarlos continuamente.

9. La agilidad no va de aplicar mejores prácticas. Ser ágil implica evolucionar productos, procesos y equipos a través de la experimentación.

10. Las organizaciones ágiles valoran el trabajo colaborativo sobre el desempeño individual, reconociendo la Sinergia que genera el trabajo en equipo.

11. Scrum, más allá de sus prácticas, se basa en el Empirismo: la experimentación, observación, aprender del error y la validación de lo que funciona en nuestros entornos particulares.

12. La TRANSPARENCIA, primer pilar de Scrum, exige la visibilidad, un lenguaje común y que todos en el equipo, e involucrados, sean coautores de las soluciones.

13. La INSPECCIÓN, segundo pilar de Scrum, invita a una evaluación constante del avance del producto, la eliminación del desperdicio y de los impedimentos. Utiliza las dailies, el sprint planning, la review y la retrospectiva.

14. La ADAPTACIÓN, tercer pilar de Scrum, hace de la mejora continua una práctica habitual del equipo, con acciones que mejoran sus procesos, la calidad de sus productos y servicios, y las interacciones entre las personas.

15. Valores Scrum: COMPROMISO de cada miembro del equipo de hacer el máximo esfuerzo para cumplir la meta del Sprint. Se refiere a dedicación no a resultados. Los equipos maduros logran ser predecibles.

16. Ser ágil es comprometerse con los objetivos del equipo, con la calidad, con aprender, con ser mejores profesionales, con la transparencia, con ser proactivos, con la entrega de frecuente de valor y con la mejora continua.

17. Valores Scrum FOCO en lo importante y prioritario para cumplir la meta del sprint, que bien definida, equivale al desarrollo y validación del sprint backlog, evitando la multitarea y las tareas extras, manteniendo el trabajo simple y de calidad.

18. Valor Scrum APERTURA y franqueza en cada miembro del equipo, manteniendo una actitud abierta y proactiva para mejorar sus capacidades y competencias profesionales y personales.

19. Valor Scrum RESPETO al conocimiento, las habilidades y la experiencia profesional de cada persona involucrada con el producto, respetando su rol y participación.

20. Valor Scrum CORAJE para hacer lo correcto, resolver impedimentos, sacar a la luz los problemas, reconocer los errores y las oportunidades que permiten mejorar el producto o servicio.

21. Design Thinking (DT) significa forma en que piensan los diseñadores. Es un método para generar ideas innovadoras que centra su eficacia en entender y dar solución a las necesidades reales de los usuarios. (Más información y lista de técnicas y herramientas en https://www.designthinking.es).

22. DT pone en valor generar empatía para entender los problemas, necesidades y deseos de los usuarios implicados en la solución que estamos buscando.

23. DT valora la colaboración y el trabajo en equipo, y la generación de prototipos que validen las propuestas antes de asumirse como correctas, propiciando la identificación y solución de fallos antes de implantar la solución.

24. DT promueve lo lúdico y el disfrute para llegar a un estado mental en el que demos rienda suelta a nuestro potencial. Utiliza técnicas con un gran contenido visual, que estimulan nuestra mente analítica y creativa, dando como resultado soluciones innovadoras y factibles.

25. DT es un proceso iterativo, primero se recolecta mucha información y se genera gran cantidad de contenido, que se irá afinando hasta desembocar en una solución que cumpla con los objetivos del equipo.

26. DT, en su fase de Empatía, busca comprender las necesidades de los usuarios implicados en la solución que estemos desarrollando, y también de su entorno, siendo capaces de ponernos en la piel de dichas personas para generar soluciones consecuentes con sus realidades.

27. DT, en su fase de Definición, identifica problemas o retos cuyas soluciones serán clave para la obtención de un resultado innovador. Utiliza, de la información recopilada, la que aporta valor y nos lleve al alcance de nuevas perspectivas. No definas posibles soluciones, eso lo hacemos en la siguiente fase.

28. DT, en su fase de Ideación, busca la generación de un sinfín de opciones, con actividades que favorecen el pensamiento expansivo y eliminando los juicios de valor, analizando incluso las ideas más estrambóticas que podrían ser parte de soluciones visionarias. Utiliza Divergencia y luego Convergencia.

29. DT, en su fase de Prototipado, propone construir prototipos para hacer las ideas palpables y permitir la validación de las posibles soluciones, poniendo de manifiesto elementos que debemos mejorar, corregir, refinar o cambiar antes de llegar al resultado final.

30. DT, en su fase de Testeo, prueba los prototipos con los usuarios implicados a fin de identificar mejoras significativas, fallos a resolver y posibles carencias. El proceso vuelve a iterar hacia las fases anteriores hasta convertir la idea en la solución buscada.

31. La agilidad tiene su origen en los años 90, con la crisis de la entrega tardía del software. Líderes del sector generan en 2001 un manifiesto de desarrollo de productos que propone nuevas formas más eficientes de pensar, desarrollar y tomar decisiones.

32. Para la agilidad el Desarrollo de productos está basado 1ro. en la confianza, 2do. en valores y principios, y 3ro. en marcos de trabajo afines a esta filosofía. En este orden.

33. Desarrollo de Productos ágiles cuya capacidad adaptativa dan al cliente la ventaja competitiva de responder rápidamente a los cambios de su entorno.

34. Desarrollo de productos ágiles con entregas tempranas y continuas de producto funcionando, entre 1 y 4 semanas, dentro de un proceso iterativo e incremental.

35. La agilidad lleva al equipo a la Entrega frecuente de incrementos de productos de valor para el cliente, lo que le permite retornos de inversión más tempranos que con desarrollos tradicionales.

36. La agilidad se preocupa de que el equipo tenga individuos motivados, donde el cliente es parte del equipo, y junto al equipo de desarrollo, trabajan para entregar productos de valor.

37. El equipo ágil está conformado por profesionales multidisciplinares y autónomos, donde prevalece la transparencia y un ambiente de confianza.

38. El equipo ágil valora la calidad, por lo que trabaja con diseños y arquitecturas que aseguran la excelencia técnica del producto.

39. El equipo ágil mantiene un enfoque de desarrollo basado en la simplicidad, en lo que da valor, minimizando el retrabajo y las tareas innecesarias.

40. Los equipos ágiles reflexionan frecuentemente, en cada iteración, para mejorar la forma en que trabajan, haciendo de la mejora continua parte de la cultura y disciplina del equipo.

41. Kanban es un método para definir, gestionar y mejorar servicios y productos, cuyo objetivo es ayudar a que una organización adopte, poco a poco, una cultura de mejora continua y respeto por las personas.

42. Kanban utiliza un método de gestión visual del trabajo que busca entregar valor al cliente mediante equipos enfocados en hacer eficiente el flujo de trabajo, utilizando principios Lean, que propone un pensamiento simple y ajustado, reduciendo los desperdicios y centrándose en lo esencial.

43. En Kanban el equipo diseña el flujo identificando los estados por los que pasa el trabajo, y elabora un Tablero, físico o digital, donde hacer visible cada paso de las tareas que realiza.

44. Una de las principales ventajas que nos permiten los tableros Kanban es hacer visible el estado del trabajo y a la vez detectar cuellos de botella en el flujo para que el equipo los resuelva rápidamente.

45. Practica de Visualización: El equipo toma del backlog una tarea pendiente, la coloca en la primera columna del tablero y a medida que la va ejecutando la va pasando por las columnas del tablero hasta llegar a la última. Todos en el equipo ven donde está el trabajo.

46. Practica WIP: En Kanban el equipo da preferencia a terminar tareas en curso antes de iniciar tareas nuevas, razón por la que el equipo limita su trabajo en curso. ¡Stop starting, start finishing! (Deja de empezar y empieza a terminar).

47. Eficiencia del flujo: en Kanban el equipo analiza el flujo y observa donde se pudieran estar quedando atascadas las tareas, a fin de resolver estos cuellos de botella, haciendo eficiente y fluido el flujo de trabajo.

48. En Kanban, el Gestor de la demanda, o Product owner, prioriza el trabajo del equipo con frecuencia a fin de garantizar que siempre se trabaja con aquello que la organización más necesita en ese momento, aquello que le da más valor.

49. Métricas Kanban: el equipo busca conocer su tiempo de entrega o Lead Time, que va desde que se solicita un trabajo hasta que se entrega, a fin de mejorarlo, realizar estimaciones y tener medias para ser predecible.

50. Métricas Kanban: Delivery Rate (Tasa de entrega) Número de elementos finalizados por unidad de tiempo. Analizar esta métrica, junto con el WIP (Trabajo en curso) permite al equipo conocer su capacidad, ser eficiente y cumplir sus compromisos.

51. Las políticas explícitas en Kanban facilitan la alineación y sincronización del equipo, objetivos y acuerdos comunes, normas claras, y foco en la entrega eficiente de valor.

52. En Kanban los ciclos de feedback disciplinan al equipo para que periódicamente aprovisionen y prioricen su trabajo, revisen las entregas, y reflexionen sobre sus políticas, WiP, métricas y oportunidades de mejora.

53. Kanban inicia con la fase de preparación, para comprender la demanda, los flujos de trabajo actuales e identificar posibles clases de servicio. Se obtienen indicadores del servicio actual y se evalúa el nivel de agilidad del equipo.

54. En la fase de formación se imparten talleres para que los equipos se familiaricen con el método Kanban, sus principios y prácticas, y se, realizan dinámicas que simulen la operativa de trabajo. Es común que un coach acompañe a los equipos en su proceso de aprendizaje.

55. Partiendo del conocimiento adquirido en la preparación y formación, en la fase de lanzamiento, se diseña e implementa el modelo de trabajo ágil basado en Kanban, se configura y visualiza el flujo de trabajo, se hacen explicitas las políticas, se limita el WIP, se acuerdan los ciclos de feedback, y se mide y gestiona el flujo.

56. Una fase que se da en paralelo a la ejecución de un servicio o desarrollo de productos en Kanban es mejorar y evolucionar continuamente el flujo y el equipo de trabajo.

57. Un equipo Kanban tiene como objetivo conseguir la mejora evolutiva a través de los ciclos de feedback y sus métricas de ejecución y gestión, actuando sobre la base de lo aprendido de forma colaborativa.

58. Scrum o Kanban: Ambos marcos son ágiles, comparten valores, principios e incluso prácticas. Scrum es más apropiado cuando la demanda y la entrega puede realizarse por Sprints. Scrum brinda mayor estructura y prácticas ágiles a los equipos que se inician en Agilidad.

59. Scrum o Kanban: Cuando la demanda no es planificable por sprint, bien sea por que no hay suficiente demanda para sprints continuos, o por la naturaleza de las entregas y disponibilidad de las personas involucradas, los equipos ágiles pueden implementar Kanban, recordando que Kanban es mucho más que el uso de tableros visuales.

60. Scrumban: las prácticas Scrum y Kanban pueden combinarse para facilitar un marco que combina roles, artefactos y eventos de ambos métodos de trabajo, donde lo importante es conseguir un enfoque basado en los valores y principios de la agilidad, poniendo foco en las personas, en el concepto de equipo, en la entrega continua de valor y en una cultura de calidad y mejora continua.

61. Métricas, indicadores, y/o KPIs, son mediciones que facilitan a los equipos ágiles conocer el estado de salud de sus proyectos, productos y equipos ágiles. Si no mides, no sabrás cómo estás y si estás mejorando o no.

62. Las métricas ágiles nos ayudan a evaluar la calidad de un producto, a optimizar procesos y a realizar un seguimiento del rendimiento y nivel de madurez de un equipo.

63. El propósito de las métricas es apoyar la mejora continua de los equipos y sus productos, en ningún caso, deben ser utilizadas como un arma para atacar y hacer sentir mal a los equipos, quienes podrían desarrollar una relación de rechazo con las métricas.

64. Compartir y usar métricas ágiles sólidas y transparentes puede ayudar al equipo a compartir una visión común, reducir la confusión y conocer sobre el verdadero progreso del trabajo del equipo.

65. En agile medimos el trabajo completado, el que da valor a la organización, el que cumple la definición de hecho del equipo. Cuando se trata de desarrollo de software, es software funcionando.

66. Los productos y proyectos ágiles son complejos, cambiantes y con una alta incertidumbre; medirlos con métricas tradicionales, como trabajo planificado vs completado, o coste del trabajo realizado, lejos de ayudar, amplifican la presión y el estrés en el equipo.

67. En Agile, han surgido nuevas maneras de medir el progreso, que ayudan a comprender y mejorar el flujo de trabajo, descubrir cuellos de botella y mejorar la eficiencia del equipo, para favorecer entregas al cliente de mayor valor y con más frecuencia.

68. Para mejorar o reducir los tiempos de entrega al cliente, los equipos ágiles necesitan conocer cuánto tiempo tardan sus elementos de trabajo, para recorrer todo el proceso, o una parte de él.

69. Agile, toma de la filosofía Lean, dos métricas que miden el Tiempo de entrega (Lead time) y el Tiempo del ciclo (Cycle time). El Lead time mide el tiempo que tarda un requisito desde que el cliente lo solicita al equipo de trabajo, hasta que lo valida y acepta para colocarlo al servicio de los usuarios.

70. El Cycle time mide cuánto tiempo tarda el trabajo en un estado, como por ejemplo "En pruebas" o en un ciclo en particular, como por ejemplo desde que el equipo inicia el desarrollo hasta que el trabajo se entrega para revisión y pruebas por parte del usuario.

71. En Scrum, medimos la velocidad de entrega del equipo, es decir, el número de puntos de historia completados al final del sprint.

72. Luego de los primeros sprints, el equipo logra estabilizar su velocidad, lo que representa su capacidad de entrega.

73. En Scrum, buscamos que el equipo sea predecible, estabilice su velocidad de entrega y planifique conforme a su velocidad.

74. En Scrum, la predictibilidad se calcula dividiendo el número de puntos completados entre el número de puntos planificados al inicio del sprint. Un equipo ágil busca una predictibilidad cercana al 100%.

75. Otro dato que monitorean los equipos Scrum, es el número de puntos de historia añadidos al sprint en curso. Aunque no es una buena práctica, en ocasiones, los equipos deben aceptar trabajo no planificado.

76. El trabajo urgente o no planificado, debe ser gestionado por el equipo, a fin de reservarle capacidad, analizarlo para reducirlo, y priorizarlo con el PO.

77. Los equipos ágiles, miden la frecuencia de las entregas, con la intención de reducir el tiempo entre una entrega y la siguiente.

78. Los equipos ágiles, miden el número de tareas en progreso o Work In Progress, para conocer el número óptimo que promueve su productividad, evitando el multitasking. Con este valor limitan el WiP.

79. El Burndown Chart muestra la cantidad de trabajo que se ha completado en un sprint, y el trabajo total restante. Permite mantener al equipo al tanto del avance del sprint y predecir la probabilidad de completar su trabajo en el tiempo disponible. 

80. El Velocity Chart muestra la cantidad de trabajo que planifica y completa un equipo en cada sprint. Este valor debería volverse más preciso y confiable con el tiempo, a medida que el equipo mejore la estimación y solución de sus problemas.

81. Obeya room o Sala Obeya, en japonés "habitación grande" o "habitación de guerra", es un método para la gestión visual de proyectos proveniente de la cultura Lean y utilizada en 1990 por Toyota.

82. La sala Obeya es un espacio físico o digital que recopila y presenta información clave sobre los resultados, avances y gestión del proyecto/producto, tanto a nivel operativo como de gestión.

83. La sala Obeya al reunir información útil y elementos visuales en un solo lugar aporta eficiencia y enfoque a los equipos, fomentando un entorno de colaboración y comunicación significativa, evitando correos, informes y reuniones innecesarias.

84. Las salas Obeya se basan en principios como la visibilidad, la transparencia, la mejora continua y el trabajo en equipo. Utilizan cuadros de mando o dashboard con la calidad del dato y usabilidad para facilitar la comunicación, colaboración y toma oportuna de decisiones.

85. La sala Obeya incluye mediciones útiles a la mejora del desempeño de los equipos tales como: predictibilidad, velocidad, tiempo entre entregas, valor entregado, entre otros. Las consultas pueden filtrarse en un periodo específico e incluir gráficos que muestren la evolución de métricas en el tiempo que facilitan el análisis comparativo y las proyecciones.

86. La sala Obeya puede diseñarse utilizando el ciclo Deming (PDCA), mostrando los objetivos a alcanzar (Plan), el plan actual que el equipo ejecuta día a día (Do), las métricas de negocio y del equipo (Check) y las acciones de mejora continua (Act).

87. Para hacer un uso eficiente de la sala Obeya, además de un buen diseño y calidad del dato, los equipos acuerdan normas para hacer eficiente su flujo de trabajo, eliminar desperdicios y cuellos de botella, resolver impedimentos, y tener reuniones efectivas.

88.Entre los desafíos de implementar con éxito salas Obeya se encuentran: mantener un ambiente de confianza que favorezca la transparencia, entornos de aprendizaje que valoren los datos, promoción de la autonomía y autogestión del equipo de trabajo.

89. La sala Obeya incluye mediciones del nivel de madurez del equipo en la aplicación de prácticas ágiles y entrega de valor para promover la reflexión y la mejora continua de su desempeño.

90. Las salas Obeya, son un espacio de reflexión en equipo y aprendizaje, no un espacio de seguimiento y control de tareas.

91. Management 1.0 Liderazgo basado en jerarquía, monitorizar, reparar y reemplazar sus partes. El 2.0 reconoce que las personas son lo más valioso y que merecen un liderazgo servicial.
92. Management 3.0 es un movimiento de innovación y gestión donde el liderazgo es una responsabilidad grupal y el éxito de la organizacion se consigue manteniendo la felicidad de los trabajadores como una prioridad.
93. Management 3.0 examina cómo analizar los sistemas adaptativos complejos para encontrar las soluciones correctas para un mejor liderazgo, para ello cuenta con Martie, el monstruo de la gestión, que guía 6 principios.
94. Martie 1. Energizar personas: las personas son la parte más importante de una organización y los managers deben hacer todo lo posible para mantener a las personas activas, creativas y motivadas.
95. Martie 2. Empoderar a los equipos: los equipos pueden autoorganizarse, y esto requiere empoderamiento, autorización y confianza desde el management.
96. Martie 3. Alinear restricciones: la autoorganización puede conducir a cualquier cosa, y por tanto, es necesario proteger a las personas y a los recursos compartidos, y brindar a las personas un propósito claro y unos objetivos definidos.
97. Martie 4. Desarrollar competencias: los equipos no pueden lograr sus objetivos si sus miembros no tienen las capacidades para ello, por tanto, los managers deben contribuir al desarrollo de sus competencias.
98. Martie 5, Aumentar la estructura: muchos equipos operan dentro del contexto de una organización compleja. Por ello es importante considerar estructuras que mejoren la comunicación.
99. Martie 6. Mejorar todo: las personas, los equipos y las organizaciones necesitan mejorar continuamente para posponer el fallo tanto como sea posible.
100. La Agilidad incorpora conceptos y estrategias maduras como Lean y Kanban, así como propuestas novedosas como DevOps y el Management 3.0.

Completando el reto de 100 mensajes cortos ágiles, y que de mejor manera que con Management 3.0.

¡¡¡Aprende y celebra conmigo!!!

#Reto100CortosAgile, #Agilidad, #Kanban, #Scrum, #EquiposAgiles, #ProductosAgiles, #ScrumMaster, #Métricas, #SalaObeya, #Management3.0

Linkedin 100 Cortos Agile (10/10)

Divide con coherencia y Vencerás con éxito!

Sabemos que tener una gran meta que requiere de tiempo, recursos y esfuerzos, puede ser algo complejo de abordar y muy abrumador, especialmente cuando existe incertidumbre.

La estrategia “Divide y Vencerás” es utilizada por la mayoría de las metodologías y marcos de trabajo, y en agilidad nos facilita el Descubrir, Aprender y Adaptar el Producto y método de trabajo del equipo, utilizando un modelo de desarrollo iterativo e incremental, con eventos basados en la mejora continua.

Saber Dividir es parte esencial del éxito. Es por ello que en Scrum dividimos el desarrollo en iteraciones o sprints de 1 a 4 semanas y el producto backlog en historias de usuario con pequeñas funcionalidades que deben construirse y validarse en un sprint.

Cada sprint y cada historia de usuario debe disponer de un objetivo y meta coherente con la del producto general. El producto backlog suele surgir de un mapa de historias (user story mapping) que a partir de los objetivos del producto, identifica las actividades, épicas e historias de usuario (HU). 

Algunos equipos se preguntan cómo dividir las HU para que sean pequeñas y quepan en un sprint, recordando que una HU debe convertirse en una pieza del producto funcionando, demostrable y validable por un usuario. Para ello, disponemos de diferentes técnicas, según: Pasos del flujo de trabajo, Reglas de negocio, Flujo feliz / infeliz, Opciones de entrada, Tipos de entrada, Casos de prueba, Roles, entre otros. (Leer más en: 10 estrategias útiles para descomponer historias de usuario grandes). 

Otra forma que he experimentado, es describir una funcionalidad (HU grande) cuyos criterios de aceptación se corresponde con diferentes HU.

¿Qué estrategias te han funcionado para dividir y estimar HU?

#Agilidad, #Scrum, #ScrumMaster, #ProductBacklog, #HistoriasUsuario, #USM

Guia del Scrum Master: Ejecución (Sprint 1 y sucesivos)

 

La ejecución de un proyecto o producto ágil basado en Scrum comienza con el Sprint 1. Cada equipo acuerda la duración de los sprints, que suelen ser de 1, 2, 3 o 4 semanas, y una vez fijada la duración, debe ser la misma en todos los sprints. En cada sprint se dan 5 eventos: Refinamiento, Planificación de sprint, Reuniones diarias (dailies), Revisión y Retrospectiva (¿Es verdad que en Scrum hay demasiadas reuniones?: Los eventos en Scrum).

Disponer de una lista de actividades y verificaciones guía al Scrum master (SM) en la gestión exitosa del proceso Scrum, y como toda guía ágil, debe ser constantemente inspeccionada y adaptada a las particularidades del equipo, producto y organización donde se aplica (más sobre el SM en Lecciones Aprendidas con SCRUM. El Scrum Master (2)).

Guía básica para la ejecución de los eventos de cada sprint:

#	General
1	El SM realiza con anticipación las convocatorias a cada evento del sprint, incluyendo en cada caso: Propósito, Agenda, Fecha, hora y duración, Lugar o enlace digital	☐
2	En la reunión el SM facilita las conversaciones dentro del equipo y modera la sesión para que siga la agenda, cumpla su propósito y se realice en el tiempo acordado. Cómo tener sesiones de trabajo productivas en Scrum	☐
3	Ayuda que el equipo disponga de una Sala Obeya para la gestión eficiente de su proyecto o producto La Sala Obeya: Gestión visual y colaborativa de proyectos	☐
	Refinamiento
4	El Product Owner (PO) prioriza el Product Backlog y documenta las historias de usuario más próximas a realizarse en la herramienta y formato acordados. Se recomienda tener refinadas las historias para los próximos 2 sprints	☐
5	El equipo de desarrollo analiza las historias prioritarias y toma nota de las dudas	☐
	Planificación de sprint
6	El SM verifica que se dispone de backlog priorizado y refinado para la planificación del sprint	☐
7	En la reunión el SM verifica con el PO la prioridad de las historias, valida si el equipo de desarrollo tiene cualquier duda y solicita que estimen las historias que podrían acometerse en el sprint	☐
8	El equipo, guiado por el PO, acuerda la meta del sprint y conforma el Sprint backlog con las historias que permiten cumplir la meta y cumplen la definición de Ready. El Sprint Goal: La meta del Sprint. Historias de Usuario: DoR y DoD clave para la eficiencia y productividad del Equipo	☐
9	El equipo de desarrollo verifica que el alcance del sprint es el adecuado de acuerdo con su capacidad, teniendo en cuenta velocidad y disponibilidad	☐
	Reuniones diarias (Dailies)
10	El equipo debe tener actualizado el estado de las historias y tareas en las que trabaja	☐
11	Compartir el tablero del sprint activo y hacer un recorrido del trabajo en curso de derecha a izquierda, dando prioridad al cierre del trabajo en curso más próximo a completarse	☐
12	El SM toma nota de los impedimentos y dificultades del equipo de desarrollo para gestionar su solución	☐
13	Verificar el trabajo en progreso que se encuentra en el sprint activo, asegurándose de que las personas del equipo no tienen más de 2/3 tareas asignadas (Work In Progress-WIP). Cómo hacer dailies productivas en 15 minutos	☐
	Revisión y Retrospectiva de sprint
14	El equipo prepara la demo para la revisión del sprint y durante la revisión se documentan los acuerdos referidos a cada historia de usuario trabajada durante el sprint. El PO valida las historias que pasan a Done. Definition-of-Done: Clave de la Calidad del Producto. ¿Qué es una review?	☐
15	El SM prepara la retrospectiva llevando un registro de las acciones de mejora acordadas en la retrospectiva anterior para verificar su estado e impacto en el sprint. El valor de las retrospectivas potentes. Hagamos Retrospectivas potentes	☐

¿Qué agregarías a esta lista?

¡Gracias por leerme!

Saludos, María Esther

Ig @Soy.agile.coach

Guia del Scrum Master: Preparación (Sprint 0)

Con el propósito de facilitar una herramienta que guie al Scrum Master (SM) a realizar con éxito su rol en proyectos y equipos ágiles que implementan Scrum, he pensado que podría ser de utilidad disponer de una lista de actividades y verificaciones que deben realizarse en cada una de las fases y eventos Scrum, así como en otros aspectos relacionados con el liderazgo y el análisis de métricas, entre otros temas. 

Utilizo un formato tipo CheckList con una breve descripción de cada actividad y enlaces web que profundizan su contenido. He considerado desarrollar 3 puntos: 1. Preparación (Sprint 0), 2. Ejecución (Planificación, Dailies, Refinamiento, Revisión y Retrospectiva), 3. Liderazgo y Agente de cambio (Apoyo al PO, Desarrollo del equipo, Liderazgo servicial, análisis de métricas). Con estos artículos en particular, quiero recopilar feedback sobre su necesidad y utilidad, y de ser positivo este experimento, evolucionar la iniciativa hacia un e-book. Así que, si apoyas esta idea, por favor recomienda y comparte estos artículos, y si quieres amplia tu opinión en los comentarios. Este es el primer artículo sobre Preparación (Sprint 0).

#	Actividad	Status
1	Junto con el Product Owner (PO), identifica que técnicas y dinámicas realizar, así como las personas clave que deben asistir, y preparen la agenda del Sprint 0. How to plan an inception (or similar workshops)?	☐
2	Siguiendo la agenda, y de acuerdo con la disponibilidad de los participantes, envía las convocatorias a las reuniones indicando: requisitos, objetivos y puntos a tratar en cada reunión.	☐
3	Asegura que durante las sesiones de sprint 0 se crea el Mapa de Historias de Usuario. ¿Cómo hacer un User Story Mapping?	☐
4	Si se trata del desarrollo o evolución de un producto o proyecto pueden necesitar la elaboración de un Plan de entregas. SCRUM: Release Planning y Scrum	☐
5	En caso de que sea la primera vez que el PO trabaja con Historias de Usuario, realiza un taller de escritura de Historia de Usuarios. SCRUM: Cómo escribir historias de usuarios sin morir en el intento	☐
6	Al disponer de las primeras historias descrita, coordina una sección de refinamiento con el equipo de desarrollo y el PO. Experiencia: Cómo hacemos las reuniones de refinamiento (Grooming)	☐
7	Facilita que el equipo Scrum acuerde la Definición de Hecho (DoD) y la Definición de Preparado (DoR).  Definiciones ante de empezar el primer Sprint (DOR y DOD)	☐
8	Apoya al PO en la creación del Product Backlog y del Plan de entregas. Por ejemplo, en Jira:  Historias, epics e iniciativas, Aprende a utilizar versiones en Jira Software	☐
9	Convoca la Planificación del Sprint 1 y las Dailies del equipo de desarrollo	☐
10	Recuerda moderar las reuniones para que se realicen en el tiempo agendado y siguiendo lo especificado en la convocatoria. 10 pautas para organizar reuniones de trabajo efectivas	☐

#Agile, #Scrum, @ScrumMaster, #Sprint0, #Inception, #Experimento

Gracias
Saludos
María Esther Remedios
Ig @Soy.Agile.Coach

Agile 2: Continuando con los Valores

En la web de Agile 2 se lee: "Valoramos todas estas cosas y nos esforzamos por equilibrarlas o combinarlas para cada situación", lo que evidencia una diferencia con el Agile manifesto del 2001, donde se disponen los valores en dos columnas y se declara "... hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda".

La evolución de Agile reconoce lo complejas que son las organizaciones, por lo que en sus valores y principios priman los términos depende y reflexionar sobre el contexto y las necesidades particulares de cada organización y equipo, y para que en cada caso, los responsables incorporen las estrategias y prácticas más convenientes.

Valor 1: Consideración y Prescripción.

Este valor establece que en ocasiones se debe considerar la situación y el contexto, y luego de analizarlo y comprenderlo, actuar en consecuencia. Podríamos utilizar el ciclo de mejora continua PDCA, donde se Planifican acciones, se Ejecutan (Do), luego se Chequea el impacto en los procesos y resultados, y finalmente, se Actúa para estandarizar o adecuar prácticas. Si se decide utilizar un método prescriptivo, como un marco ágil de trabajo Scrum, las personas y equipos se forman en sus técnicas y herramientas, y las siguen sin cambios. En la filosofía Shu-Ha-Ri, a esta primera etapa se le conoce como Shu, y en la medida en que sus prácticas son comprendidas, podrían ser adaptadas (Ha) y posteriormente incluso, crear nuevas prácticas (Ri).

Poner en equilibrio prácticas de Consideración o de Prescripción, según lo demanden las circunstancias.

Valor 2: Resultados y productos (Outcomes and outputs).

Este valor, en mi opinión, mereció un artículo aparte que puedes leer aquí.

Los Resultados requieren Productos, y ambos importan, tomando en cuenta que son los Resultados los que dan valor a la organización.

Valor 3: Individuos y Equipos

Este valor destaca que los individuos y sus diferencias son igual de importantes que el equipo, y que las personas no son el equipo al que pertenecen. Cada miembro del equipo tiene objetivos e intereses personales, asimismo el equipo, como una unidad que busca lograr con éxito el desarrollo y evolución de un producto o servicio.

Los intereses del equipo y los intereses individuales deben estar en equilibrio, colocando especial énfasis en tener personas motivadas.

Valor 4: Comprensión Empresarial y Comprensión Técnica

El éxito del producto involucra una profunda comprensión holística de la información empresarial y de la técnica.El personal de tecnología debe interesarse por los aspectos funcionales y comerciales de la solución, así como el personal de negocio por las cuestiones tecnológicas.

Equilibrar ambas perspectivas funcional y técnica en todos los miembros del equipo, genera mayor colaboración y soluciones más efectivas e innovadoras.

Valor 5: Empoderamiento individual y buen Liderazgo

Las personas valoran y necesitan tener capacidad de acción, poder decidir cómo realizar su propio trabajo, darle la oportunidad de innovar, expresar nuevas ideas y arriesgarse a probar esas ideas. Promover en cada individuo un Liderazgo personal. Los equipos y unidades organizativas necesitan Líderes que guíen y empoderen a los que lideran, evaluando la madurez de cada persona y determinando el tipo de soporte y de formación que necesitan para su crecimiento.

Equilibrar el empoderamiento individual con un buen liderazgo para lograr un mejor desempeño.

Valor 6: Adaptabilidad y Planificación

En los entornos y productos complejos se producen frecuentes cambios que exigen capacidad de adaptabilidad. Por otra parte, la planificación es importante porque los planes establecen la mejor dirección de la acción y alinean a las personas y equipos sobre una ruta común.

Equilibrar adaptabilidad y planificación significa elaborar planes flexibles que se adaptan con rapidez a los cambios que se vayan produciendo.

¡Gracias por leerme y compartir!

Si quieres que profundice en alguno de estos temas, solicitalo en los comentarios (^.^)

Saludos,

María Esther Remedios

IG: @Soy.Agile.Coach

Agile 2: Valor 2: Resultados y productos (Outcomes and outputs)

 

Entendamos primero la diferencia entre resultados (outcomes) y productos (outputs).

Los resultados son lo que la empresa quiere o necesita lograr y los productos son las acciones o elementos que contribuyen a lograr dichos resultados.

En la primera iteración de Agile, se da mucha relevancia a los Equipos y al Producto.

En Agile 2 se destaca que los Resultados requieren Productos, y ambos importan; pero los Resultados son lo que más importa.

Por ejemplo, un outcome o resultado organizacional podría ser "un incremento en las ventas" y el output o producto un sistema de pedidos en línea.

Hablar de Valor en Agile se refiere a los outcomes o resultados, y puede diferir entre lo que valora una empresa, un cliente y un usuario. Una empresa puede valorar la retención del cliente, el cliente tener mayor autonomía operacional y el usuario una menor tasa de incidencias que resolver, resultados que se buscan obtener evolucionando uno o más outputs o productos.

Luego, para avanzar hacia el logro de resultados organizacionales, debemos comprender las necesidades de sus clientes, sus dolencias, limitaciones y prioridades, y con este conocimiento desarrollar productos que logran cambios positivos.

Cabe destacar, que es más fácil medir productos que resultados, ya que estos últimos dependen en gran medida, de la satisfacción de las personas. En todo caso, se deben medir productos y resultados, a fin de evitar el conocido efecto sandía: indicadores exitosos en las actividades/productos y rojos en los resultados/satisfacción de clientes.

Imagen tomada de: https://www.bmc.com/blogs/outcomes-vs-outputs/

Agile 2 propone entonces, realizar más reflexiones y dedicar mayores esfuerzos en entregas de valor que generen resultados felices.

Gracias por compartir y comentar!!!
Saludos, Ma.Esther
Ig @Soy.Agile.Coach

Agile 2: Valor 1: Consideración y Prescripción

 

En la web de Agile 2 se lee: "Valoramos todas estas cosas y nos esforzamos por equilibrarlas o combinarlas para cada situación", lo que evidencia una diferencia con el Agile manifesto del 2001, donde se disponen los valores en dos columnas y se declara "... hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda".

La evolución de Agile reconoce lo complejas que son las organizaciones, por lo que en sus valores y principios priman los términos depende y reflexionar sobre el contexto y las necesidades particulares de cada organización y equipo, y para que en cada caso, los responsables incorporen las estrategias y prácticas más convenientes.

El primer valor se resume en: Consideración y Prescripción.

Este valor establece que en ocasiones se debe considerar la situación y el contexto, y luego de analizarlo y comprenderlo, actuar en consecuencia. Podríamos utilizar el ciclo de mejora continua PDCA, donde se Planifican acciones, se Ejecutan (Do), luego se Chequea el impacto en los procesos y resultados, y finalmente, se Actúa para estandarizar o adecuar prácticas.

Si se decide utilizar un método prescriptivo, como un marco ágil de trabajo Scrum, las personas y equipos se forman en sus técnicas y herramientas, y las siguen sin cambios. En la filosofía Shu-Ha-Ri, a esta primera etapa se le conoce como Shu, y en la medida en que sus prácticas son comprendidas, podrían ser adaptadas (Ha) y posteriormente incluso, crear nuevas prácticas (Ri).

En próximos artículos conversaremos sobre otros valores del Agile 2.

Gracias por compartir y comentar!!!

Saludos, Ma.Esther
Ig @Soy.Agile.Coach