domingo, 9 de septiembre de 2018
lunes, 20 de agosto de 2018
Como ser un Scrum Master Extraordinario
Diez consejos que siempre necesitarás aplicar para ser extraordinario
1. Nunca comprometa al equipo con nada sin consultarlos primero
Como Scrum Master, no tiene la autoridad para aceptar solicitudes de cambio (sin importar cuán pequeñas) en nombre del equipo. Incluso si está absolutamente seguro de que el equipo puede cumplir una solicitud, diga: "Necesito consultar esto por parte del equipo antes de poder decir que sí".
Y, desde luego, no comprometa al equipo con los plazos, entregables ni nada más sin antes hablar con los miembros del equipo. Puede que no necesites hablar con todo el equipo: muchos equipos permitirán que algunos o todos los miembros digan: "Sí, podemos hacer eso" sin una reunión de equipo completo. Pero sigue siendo su decisión, no tuya.
2. Recuerda que estás ahí para ayudar al equipo a lucir bien
Ser un Scrum Master no se trata de hacerte quedar bien. Te ves bien cuando el equipo se ve bien. Y se ven bien cuando hacen un gran trabajo.
Sabes que estás haciendo bien tu trabajo cuando los que están fuera del equipo comienzan a preguntarse si te necesitaban. Sí, puede ser aterrador si su jefe se pregunta si es necesario. Pero un buen jefe sabrá que tu habilidad y experiencia te hacen parecer innecesario cuando de hecho eres indispensable.
Confíe en su gerente para comprender la diferencia entre parecer innecesario y no ser necesario.
3. No derrotar al equipo con un libro de reglas ágiles
Ni Scrum ni Agile vienen con un libro de reglas (aunque algunos han intentado crear uno).
Si su producto tiene usuarios, considere escribir historias de usuarios. Pero las historias no son obligatorias para ser ágiles. Si alguien necesita saber cuándo entregará: estimar. Si no, tal vez no. Si crees que una revisión al final del sprint es demasiado tarde para recibir comentarios, haz una revisión individual a medida que se crea cada característica.
Ser ágil se trata de honrar los principios y valores que crean agilidad. Si te mantienes fiel a esos, no te puedes desviar demasiado, sin importar lo que te puedan decir algunos.
4. Nada es permanente así que experimente con su proceso
Parte de honrar los principios de la agilidad es experimentar con su proceso. Anime al equipo a probar cosas nuevas.
¿A su equipo le encantan los sprints de dos semanas y cree que funcionan perfectamente? Estupendo. Ahora pídales que prueben una carrera de una semana o tres semanas y observen los resultados. Los experimentos pueden no ser siempre populares, pero son la mejor manera de garantizar que continúe descubriendo nuevas y mejores formas de trabajar.
5. Asegúrate de que los miembros del equipo y los interesados se vean como compañeros
Los miembros del equipo y las partes interesadas del lado del negocio aportan una perspectiva importante a una iniciativa de desarrollo de productos. Como tal, cada uno necesita ser valorado por igual.
Cuando una de las partes ve al otro como algo tolerable, la organización como un todo sufre. Los equipos de desarrollo deben comprender la perspectiva única presentada por los interesados. Y las partes interesadas deben respetar al equipo de desarrollo, incluida la escucha cuando los desarrolladores dicen que un plazo es imposible.
6. Proteja al equipo, incluso en más formas de las que puede pensar
Quizás el consejo ágil que se da con más frecuencia es que un Scrum Master necesita proteger al equipo de un propietario de producto o partes interesadas excesivamente exigentes. Y ese es un buen consejo. A veces, los propietarios de los productos simplemente piden demasiado con demasiada frecuencia y con demasiada agresividad. Esto obliga a los equipos a cortar esquinas, generalmente esquinas de calidad, que vuelven a rondar el proyecto.
Y entonces un buen Scrum Master protege al equipo contra esto.
Pero lo que no escuchas tan a menudo es que un buen Scrum Master también debería proteger al equipo contra la complacencia. Los buenos equipos ágiles buscan constantemente mejorar. Otros equipos se conforman, tal vez inconscientemente, en pensar que han mejorado lo suficiente. Y es probable que sean dramáticamente más rápidos y mejores que antes de haber oído hablar de ágil. Pero incluso los grandes equipos a menudo pueden mejorar mucho.
Los Great Scrum Masters protegen a los equipos de la sensación de que no les queda nada por aprender.
7. Desterrar el fracaso de su vocabulario
De vez en cuando, voy a visitar a un equipo que se refiere a un sprint como un "sprint fallido". Por lo general, esto significa que el equipo no entregó todo lo que planeaban. Apenas considero una falla, especialmente si el equipo terminó la mayoría de los elementos planificados o si manejaron hábilmente una emergencia.
Cuando un jugador de baloncesto tira el balón hacia la canasta y anota, se llama gol de campo. Cuando el jugador falla, se llama intento de gol de campo . No es un fracaso . Un intento .
Good Scrum Masters ayuda a los equipos a ajustar su forma de pensar para que reconozcan los sprints y las características que no alcanzan las expectativas como intentos en lugar de fracasos.
8. Elogie a menudo pero siempre atentamente
El otro día le dije a mi hija adolescente que estaba orgulloso de ella. Su rostro se iluminó. Eso no debería haberme sorprendido. ¿A quién no le gustaría que le digan que alguien está orgulloso de ellos?
Pero la forma en que reaccionó me hizo darme cuenta de que no debía contarle esto con la suficiente frecuencia. Pensé que era equivalente a que le dijera algo obvio, como: "Eres alta". Pero supe que no era así.
Nunca ofrezcas elogios falsos. Nadie quiere escuchar eso. Pero cuando los miembros de su equipo hacen un buen trabajo, hágales saber. Lo más probable es que no lo escuchen con la suficiente frecuencia.
9. Aliente al equipo a hacerse cargo de su trabajo
Un equipo que es nuevo en Agile confiará en su Scrum Master o coach de manera significativa. El equipo puede no saber cómo mantener reuniones de scrum diarias en quince minutos. O pueden no entender la importancia de superponer el trabajo o de ser un equipo multifuncional.
Lo mismo puede decirse de un equipo deportivo inexperto. El entrenador de los niños pequeños que aprenden a jugar fútbol (soccer) necesita enseñarles todo. Cuando mis hijas tenían 6 años, su entrenador corría a lo largo de todo el juego gritando: "¡Patea y corre!". Si no lo hacía, los jugadores jóvenes se olvidarían. Incluso con él gritando, de vez en cuando algún niño simplemente se sentaba en la hierba y miraba.
Compare el entrenador de los niños con el entrenador de un equipo de la Copa del Mundo. En un equipo de la Copa del mundo, los jugadores han aprendido qué hacer. Si el entrenador llega tarde a la práctica, los jugadores sabrán qué ejercicios o ejercicios para comenzar el día. El entrenador de la Copa Mundial no necesita recordarles a los jugadores que pateen y corran. Pero el equipo de la Copa Mundial nunca te diría que no necesitan un entrenador en absoluto.
No importa qué tan bueno sea un equipo ágil, todavía creo que se benefician de tener un Scrum Master o entrenador. Pero los buenos equipos ágiles asumen algunas de las tareas de entrenamiento más sencillas como parte de sus propios viajes para dominar las habilidades necesarias en el desarrollo de productos.
10. Cállate y escucha
Algunos de los mejores entrenadores o mentores que hará es permanecer en silencio y dejar que el equipo descubra la respuesta.
Esto puede ser difícil. Cuando ve que su equipo lucha por descubrir qué hacer, es natural querer intervenir y ofrecer consejos. Pero si resuelve problemas o incluso ofrece sugerencias con demasiada facilidad, los miembros del equipo aprenden a esperar que resuelva todos los problemas para ellos.
No quiero insinuar que nunca puedas ofrecer sugerencias. Eres una persona inteligente. Si no, no estarías en el rol en el que estás. Pero parte de ser un gran Scrum Master es ayudar a los equipos a aprender cómo resolver problemas por sí mismos. Si resuelves todos los problemas que enfrentan los miembros del equipo, no tienen la oportunidad de aprender cómo hacerlo ellos mismos.
¿Qué falta en esta lista?
Estoy seguro de que me faltan algunas perlas de sabiduría. ¿Cuál es el mejor consejo de una frase que has recibido o dado como Scrum Master? Por favor comparte tus pensamientos en los comentarios a continuación.
fuente : https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need
1. Nunca comprometa al equipo con nada sin consultarlos primero
Como Scrum Master, no tiene la autoridad para aceptar solicitudes de cambio (sin importar cuán pequeñas) en nombre del equipo. Incluso si está absolutamente seguro de que el equipo puede cumplir una solicitud, diga: "Necesito consultar esto por parte del equipo antes de poder decir que sí".
Y, desde luego, no comprometa al equipo con los plazos, entregables ni nada más sin antes hablar con los miembros del equipo. Puede que no necesites hablar con todo el equipo: muchos equipos permitirán que algunos o todos los miembros digan: "Sí, podemos hacer eso" sin una reunión de equipo completo. Pero sigue siendo su decisión, no tuya.
2. Recuerda que estás ahí para ayudar al equipo a lucir bien
Ser un Scrum Master no se trata de hacerte quedar bien. Te ves bien cuando el equipo se ve bien. Y se ven bien cuando hacen un gran trabajo.
Sabes que estás haciendo bien tu trabajo cuando los que están fuera del equipo comienzan a preguntarse si te necesitaban. Sí, puede ser aterrador si su jefe se pregunta si es necesario. Pero un buen jefe sabrá que tu habilidad y experiencia te hacen parecer innecesario cuando de hecho eres indispensable.
Confíe en su gerente para comprender la diferencia entre parecer innecesario y no ser necesario.
3. No derrotar al equipo con un libro de reglas ágiles
Ni Scrum ni Agile vienen con un libro de reglas (aunque algunos han intentado crear uno).
Si su producto tiene usuarios, considere escribir historias de usuarios. Pero las historias no son obligatorias para ser ágiles. Si alguien necesita saber cuándo entregará: estimar. Si no, tal vez no. Si crees que una revisión al final del sprint es demasiado tarde para recibir comentarios, haz una revisión individual a medida que se crea cada característica.Ser ágil se trata de honrar los principios y valores que crean agilidad. Si te mantienes fiel a esos, no te puedes desviar demasiado, sin importar lo que te puedan decir algunos.
4. Nada es permanente así que experimente con su proceso
Parte de honrar los principios de la agilidad es experimentar con su proceso. Anime al equipo a probar cosas nuevas.
¿A su equipo le encantan los sprints de dos semanas y cree que funcionan perfectamente? Estupendo. Ahora pídales que prueben una carrera de una semana o tres semanas y observen los resultados. Los experimentos pueden no ser siempre populares, pero son la mejor manera de garantizar que continúe descubriendo nuevas y mejores formas de trabajar.
5. Asegúrate de que los miembros del equipo y los interesados se vean como compañeros
Los miembros del equipo y las partes interesadas del lado del negocio aportan una perspectiva importante a una iniciativa de desarrollo de productos. Como tal, cada uno necesita ser valorado por igual.
Cuando una de las partes ve al otro como algo tolerable, la organización como un todo sufre. Los equipos de desarrollo deben comprender la perspectiva única presentada por los interesados. Y las partes interesadas deben respetar al equipo de desarrollo, incluida la escucha cuando los desarrolladores dicen que un plazo es imposible.
6. Proteja al equipo, incluso en más formas de las que puede pensar
Quizás el consejo ágil que se da con más frecuencia es que un Scrum Master necesita proteger al equipo de un propietario de producto o partes interesadas excesivamente exigentes. Y ese es un buen consejo. A veces, los propietarios de los productos simplemente piden demasiado con demasiada frecuencia y con demasiada agresividad. Esto obliga a los equipos a cortar esquinas, generalmente esquinas de calidad, que vuelven a rondar el proyecto.
Y entonces un buen Scrum Master protege al equipo contra esto.
Pero lo que no escuchas tan a menudo es que un buen Scrum Master también debería proteger al equipo contra la complacencia. Los buenos equipos ágiles buscan constantemente mejorar. Otros equipos se conforman, tal vez inconscientemente, en pensar que han mejorado lo suficiente. Y es probable que sean dramáticamente más rápidos y mejores que antes de haber oído hablar de ágil. Pero incluso los grandes equipos a menudo pueden mejorar mucho.
Los Great Scrum Masters protegen a los equipos de la sensación de que no les queda nada por aprender.
7. Desterrar el fracaso de su vocabulario
De vez en cuando, voy a visitar a un equipo que se refiere a un sprint como un "sprint fallido". Por lo general, esto significa que el equipo no entregó todo lo que planeaban. Apenas considero una falla, especialmente si el equipo terminó la mayoría de los elementos planificados o si manejaron hábilmente una emergencia.
Cuando un jugador de baloncesto tira el balón hacia la canasta y anota, se llama gol de campo. Cuando el jugador falla, se llama intento de gol de campo . No es un fracaso . Un intento .
Good Scrum Masters ayuda a los equipos a ajustar su forma de pensar para que reconozcan los sprints y las características que no alcanzan las expectativas como intentos en lugar de fracasos.
8. Elogie a menudo pero siempre atentamente
El otro día le dije a mi hija adolescente que estaba orgulloso de ella. Su rostro se iluminó. Eso no debería haberme sorprendido. ¿A quién no le gustaría que le digan que alguien está orgulloso de ellos?
Pero la forma en que reaccionó me hizo darme cuenta de que no debía contarle esto con la suficiente frecuencia. Pensé que era equivalente a que le dijera algo obvio, como: "Eres alta". Pero supe que no era así.
Nunca ofrezcas elogios falsos. Nadie quiere escuchar eso. Pero cuando los miembros de su equipo hacen un buen trabajo, hágales saber. Lo más probable es que no lo escuchen con la suficiente frecuencia.
9. Aliente al equipo a hacerse cargo de su trabajo
Un equipo que es nuevo en Agile confiará en su Scrum Master o coach de manera significativa. El equipo puede no saber cómo mantener reuniones de scrum diarias en quince minutos. O pueden no entender la importancia de superponer el trabajo o de ser un equipo multifuncional.
Lo mismo puede decirse de un equipo deportivo inexperto. El entrenador de los niños pequeños que aprenden a jugar fútbol (soccer) necesita enseñarles todo. Cuando mis hijas tenían 6 años, su entrenador corría a lo largo de todo el juego gritando: "¡Patea y corre!". Si no lo hacía, los jugadores jóvenes se olvidarían. Incluso con él gritando, de vez en cuando algún niño simplemente se sentaba en la hierba y miraba.
Compare el entrenador de los niños con el entrenador de un equipo de la Copa del Mundo. En un equipo de la Copa del mundo, los jugadores han aprendido qué hacer. Si el entrenador llega tarde a la práctica, los jugadores sabrán qué ejercicios o ejercicios para comenzar el día. El entrenador de la Copa Mundial no necesita recordarles a los jugadores que pateen y corran. Pero el equipo de la Copa Mundial nunca te diría que no necesitan un entrenador en absoluto.
No importa qué tan bueno sea un equipo ágil, todavía creo que se benefician de tener un Scrum Master o entrenador. Pero los buenos equipos ágiles asumen algunas de las tareas de entrenamiento más sencillas como parte de sus propios viajes para dominar las habilidades necesarias en el desarrollo de productos.
10. Cállate y escucha
Algunos de los mejores entrenadores o mentores que hará es permanecer en silencio y dejar que el equipo descubra la respuesta.
Esto puede ser difícil. Cuando ve que su equipo lucha por descubrir qué hacer, es natural querer intervenir y ofrecer consejos. Pero si resuelve problemas o incluso ofrece sugerencias con demasiada facilidad, los miembros del equipo aprenden a esperar que resuelva todos los problemas para ellos.
No quiero insinuar que nunca puedas ofrecer sugerencias. Eres una persona inteligente. Si no, no estarías en el rol en el que estás. Pero parte de ser un gran Scrum Master es ayudar a los equipos a aprender cómo resolver problemas por sí mismos. Si resuelves todos los problemas que enfrentan los miembros del equipo, no tienen la oportunidad de aprender cómo hacerlo ellos mismos.
¿Qué falta en esta lista?
Estoy seguro de que me faltan algunas perlas de sabiduría. ¿Cuál es el mejor consejo de una frase que has recibido o dado como Scrum Master? Por favor comparte tus pensamientos en los comentarios a continuación.
fuente : https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need
domingo, 12 de agosto de 2018
Una vista de la herramienta Team Canvas
Canvas es una herramienta estratégica facil de usar que ayuda a los miembros del equipo a iniciar proyectos y alinearse en una visión común. Según nuestra experiencia con startups y grupos creativos, está hecho para iniciar proyectos colectivos sin problemas, permitir que las personas conozcan entre sí y acumular el impulso suficiente para ponerse en marcha. mas información de ella en http://theteamcanvas.com/use/
viernes, 27 de julio de 2018
En scrum lecciones aprendidas se trabajan en la reunion de retrospectiva
En el proceso retrospectiva del Sprint , el Scrum Master y Scrum Team se reúnen para analizar las lecciones aprendidas durante todo el Sprint. Esta información está documentada como lecciones aprendidas, que pueden aplicarse a futuros Sprints. Como resultado de esta discusión, puede haber Mejoras Accionables Acordadas o Recomendaciones del Cuerpo de Orientación de Scrum Actualizadas. Las mejoras aprobadas acordadas son las principales salida de este proceso. Son la lista de elementos procesables que el equipo ha creado para abordar problemas y mejorar procesos con el fin de mejorar su rendimiento en futuros Sprints. Una vez que las Mejoras Accionables Acordadas hayan sido elaboradas y refinadas, el Equipo de Scrum puede considerar elementos de acción para implementar las mejoras. El Retrospect Sprint Log es un registro de las opiniones, discusiones y elementos procesables planteados en una reunión de Retrospect Sprint. El Scrum Master podría facilitar la creación de este registro con las aportaciones de los miembros del Scrum Core Team. La recopilación de todos los registros de Sprint retrospectivos se convierte en el diario del proyecto y detalla los éxitos, problemas, problemas y resoluciones del proyecto. Los registros son documentos públicos disponibles para cualquier persona en la organización.Seguir los tres procesos de la fase de Revisión y Retrospect ayuda a los involucrados en un proyecto de Scrum a revisar los entregables e identificar los impedimentos para neutralizar en el futuro. Recuerde que los procesos no necesitan realizarse de forma secuencial o por separado. Se pueden ajustar para complementar los requisitos específicos de cada proyecto. Sin embargo, antes de abandonar la fase de Revisión y Retrospectiva, es imprescindible analizar el proyecto y determinar qué funcionó y qué no funcionó.
Los principales objetivos de la reunión son identificar tres cosas específicas:
Cosas que el equipo necesita seguir haciendo: mejores prácticas
Cosas que el equipo necesita comenzar a hacer: mejoras de procesos
Cosas que el equipo necesita dejar de hacer: problemas de proceso y cuellos de botella
Estas áreas se discuten y se crea una lista de Mejoras procesables acordadas.
Otras herramientas utilizadas en el Proceso de Retrospect Sprint son:
Lancha rápida
Métricas y técnicas de medición
Las salidas de Retrospect Sprint son:
Mejoras accionables acordadas
Elementos de acción asignados y fechas de vencimiento
Artículos no funcionales propuestos para cartera de productos priorizada
Registros de la Retrospectiva del Sprint o Log (s)
Lecciones aprendidas del equipo Scrum
Recomendaciones actualizadas de Scrum Guidance Body
¿Cómo se relaciona la reunión de Retrospect Sprint con el aspecto 'inspeccionar y adaptar' de Scrum?
La reunión de Retrospect Sprint es un elemento importante del marco de Scrum "inspeccionar-adaptar" y es el paso final en un Sprint. Todos los miembros del equipo de Scrum asisten a la reunión, que es facilitada o moderada por Scrum Master. Se recomienda, pero no es obligatorio para el propietario del producto. Un miembro del equipo actúa como el escriba y documenta las discusiones y los elementos para la acción futura. Es esencial realizar esta reunión en un ambiente abierto y relajado para alentar la participación plena de todos los miembros del equipo. Las discusiones en la Retrospect Sprint Meeting abarcan tanto lo que salió mal como lo que salió bien.
fuente : https://www.linkedin.com/pulse/scrumstudy-sprint-retrospective-meeting-jeetendra-roy-smc-ssgb-mba/
La Era de Agile Uno de los 10 mejores libros del 2018 Segun Amazon
Un viaje al futuro de muchas empresas nos presente este libro, Adoptar agile permite a un equipo, una unidad o una empresa adaptar y actualizar ágilmente los productos y servicios para satisfacer la cambiante tecnología y las necesidades de los clientes. Y el proceso es aplicable en cualquier parte: las empresas no necesitan nacer ágiles, comienza la transición y cosechando resultados extraordinarios.
Entrenamiento en gestion agil de proyectos con Scrumstudy. Como incorporando prácticas más ágiles en su organización y ejemplos inspiradores de acciones ágiles y consejos claros y prácticos. Info Whatsapp 57 3206953696 #scrum #agilent
jueves, 19 de julio de 2018
Convergencia de Scrum y DevOps - The Convergence of Scrum and DevOps
Vale la pena mirar el documento The Convergence of Scrum and DevOps , Dave West CEO Scrum.org, Jayne Groll CEO DevOps Institute, como integrar Scrum y Devops , los equipos entregan software en funcionamiento continuamente y donde el trabajo fluye sin interrupciones entre todas las partes
interesadas en tiempo real. Agregue a eso donde el valor es claramente entendido, medido e informado. Y muchas ideas y conceptos de Scrum.org super valiosos #scrum #devops #software #ceos #agilent Fuentes usadas en los entrenamientos de Gestion agil de proyectos con Scrumstudy.
lunes, 16 de julio de 2018
El Equipo acepta mayor responsabilidad y ofrecer mayor valor
¿Aceptar una mayor responsabilidad significa entregar un mayor valor? Scrum cree que los empleados son motivados por sí mismos y buscan aceptar una mayor responsabilidad. Entonces, entregan mucho más valor cuando se autoorganizan. El estilo de liderazgo preferido en Scrum es "liderazgo de servicio", que enfatiza el logro de resultados centrándose en las necesidades del equipo de Scrum.
Beneficios de la autoorganización
La autoorganización como principio esencial en Scrum conduce a lo siguiente:
- Compromiso del equipo y propiedad compartida
- Motivación, que conduce a un nivel de rendimiento mejorado del equipo
- Entorno innovador y creativo propicio para el crecimiento
La autoorganización no significa que los miembros del equipo puedan actuar de la manera que deseen. Simplemente significa que una vez que se define la Visión del producto en el proceso Create Project Vision, se identifica al propietario del producto, Scrum Master y Scrum Team. Y el propio Scrum Core Team trabaja en estrecha colaboración con los Stakeholder (s) relevantes para refinar mejor los requisitos a medida que pasan por el proceso Develop Epic (s) y Create User Stories. La experiencia del equipo se usa para evaluar los insumos necesarios para ejecutar el trabajo planificado del proyecto. Este juicio y experiencia se aplican a todos los aspectos técnicos y de gestión del proyecto durante el proceso Crear entregas.
Aunque la priorización se lleva a cabo principalmente por el propietario del producto que representa la voz del cliente, el equipo de Scrum autoorganizado participa en el desglose de tareas y la estimación durante los procesos de creación de tareas y estimación de tareas. Durante estos procesos, cada miembro del equipo es responsable de determinar qué trabajo va a hacer. Suring la ejecución de un Sprint, si los miembros del equipo necesitan ayuda para completar sus tareas, Scrum aborda esto a través de la interacción regular obligatoria con las Daily Standup Meetings. El propio Scrum Team interactúa con otros equipos a través de Scrum of Scrums Meetings y puede buscar orientación adicional según lo requiera el Scrum Guidance Body.
Finalmente, Scrum Team y Scrum Master trabajan estrechamente para demostrar el incremento del producto creado durante el Sprint en el proceso Demostrar y Validar Sprint, donde se aceptan entregables debidamente completados. Dado que los entregables son potencialmente enviados, (y el inventario priorizado del producto tiene prioridad según las historias de los usuarios en el orden de valor creado por ellos), el propietario del producto y el cliente pueden visualizar y articular claramente el valor que se crea después de cada Sprint; y los equipos Scrum a su vez tienen la satisfacción de ver que el cliente y otras partes interesadas aceptan su arduo trabajo.
fuente : http://blog.scrumstudy.com/accepting-greater-responsibility-and-delivering-greater-value/
Suscribirse a:
Entradas (Atom)