Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, metodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos y productos a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
lunes, noviembre 27, 2017
viernes, noviembre 17, 2017
La razón del cambio - Tweet
#DeColección
— Jorge Hernán Abad L. (@jorge_abad) November 17, 2017
“We generally change ourselves for one of two reasons: inspiration or desperation.”
― Jim Rohn
martes, noviembre 07, 2017
Leído y Recomendado: Revisión a la Guía de Scrum 2017
Hola a todos
Les comparto esta interesante reseña sobre la actualización a la Guía de Scrum, publicada hoy el 7 de noviembre de 2017 elaborada por Lucho Salazar en su famoso blog Gazafatonario IT:
Este es el link de webinar de los autores: Scrum Guide Revision Webinar
Este es el link de las diapositivas de los autores: View or Download the Scrum Guide Revision Slides
Link de artículo original: http://www.gazafatonarioit.com/2017/11/revision-la-guia-de-scrum-2017_7.html
Cambios
entre las Guías Scrum de 2016 y 2017
1. Adicionada
sección sobre los Usos de Scrum:
2. Modificada la redacción en la sección El
Scrum Master para proporcionar una mayor claridad al rol. El texto ahora dice:
3. Adicionado a la
sección El Scrum Master al Servicio del Dueño de Producto
4. Actualizado el
primer párrafo de la sección Scrum Diario para que se lea:
5. Actualizada la sección Scrum Diario para proporcionar claridad sobre los
objetivos del Scrum Diario incluyendo este texto:
6. Adicionada
claridad sobre los bloques de tiempo (time-boxes)
7. Adicionado a la
sección Lista de Pendientes del Sprint (Sprint Backlog):
Adicionada claridad a la sección Incremento:
Descarga
la guía actualizada en Español:
Puedes hacerlo directamente de:
http://www.scrumguides.org/download.html
Les comparto esta interesante reseña sobre la actualización a la Guía de Scrum, publicada hoy el 7 de noviembre de 2017 elaborada por Lucho Salazar en su famoso blog Gazafatonario IT:
Este es el link de webinar de los autores: Scrum Guide Revision Webinar
Este es el link de las diapositivas de los autores: View or Download the Scrum Guide Revision Slides
Link de artículo original: http://www.gazafatonarioit.com/2017/11/revision-la-guia-de-scrum-2017_7.html
Revisión a la Guía de Scrum 2017
Cambios
entre las Guías Scrum de 2016 y 2017
1. Adicionada
sección sobre los Usos de Scrum:
Scrum fue
desarrollado inicialmente para gestionar y desarrollar productos. Desde
principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para:
1.
Investigar
e identificar mercados viables, tecnologías y capacidades de productos;
2.
Desarrollar
productos y mejoras;
3.
Liberar
productos y mejoras tantas veces como sea posible durante el día;
4.
Desarrollar
y mantener ambientes en la Nube (en línea, seguros, bajo demanda) y otros
entornos operacionales para el uso de productos; y
5.
Mantener
y renovar productos.
Scrum se ha usado
para desarrollar software, hardware, software embebido, redes de funciones
interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para
gestionar la operación de organizaciones y casi todo lo que usamos en nuestra
vida diaria, como individuo y como sociedad.
Dado que la complejidad de la tecnología,
el mercado y del entorno y sus interacciones aumentan rápidamente, la utilidad
de Scrum para tratar con la complejidad está a prueba diariamente.
Scrum demostró ser especialmente efectivo
en la transferencia iterativa e incremental de conocimiento. Scrum se usa ahora
ampliamente para productos, servicios y gestión de la organización matriz.
La esencia de Scrum es un pequeño equipo de
personas. El equipo individual es altamente flexible y adaptativo. Estas
fortalezas continúan operando en un equipo, en varios, en muchos y en redes de
equipos que desarrollan, liberan, operan y mantienen el trabajo y los productos
de trabajo de miles de personas. Ellos colaboran e interoperan a través de
arquitecturas de desarrollo sofisticadas y ambientes finales de liberación.
Cuando las palabras “desarrollar” y “desarrollo”
se usan en la Guía de Scrum, se refieren a trabajo complejo, tales como estos
identificados anteriormente.
2. Modificada la redacción en la sección El
Scrum Master para proporcionar una mayor claridad al rol. El texto ahora dice:
El Scrum Master
es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Los
Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas,
reglas y valores de Scrum.
El Scrum Master
es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las
personas externas al Equipo Scrum a entender qué interacciones con el Equipo
Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar
estas interacciones para maximizar el valor creado por el Equipo Scrum.
3. Adicionado a la
sección El Scrum Master al Servicio del Dueño de Producto
Asegurar que los objetivos,
el alcance y el dominio del producto sean entendidos por todos en el equipo
Scrum de la mejor manera posible
4. Actualizado el
primer párrafo de la sección Scrum Diario para que se lea:
El Scrum Diario
es una reunión con un bloque de tiempo de 15 minutos para el Equipo de
Desarrollo. El Scrum Diario se lleva a cabo cada día del sprint. En él, el
Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. Esto
optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo
avanzado desde el último Scrum Diario y haciendo una proyección del trabajo del
Sprint a realizar a continuación. El Scrum Diario se realiza a la misma hora y
en el mismo lugar todos los días para reducir la complejidad.
5. Actualizada la sección Scrum Diario para proporcionar claridad sobre los
objetivos del Scrum Diario incluyendo este texto:
El Equipo de
Desarrollo es el encargado de establecer la estructura de la reunión y esta se
puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta
de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más
en discusiones. Aquí hay un ejemplo de lo que podría usarse:
·
¿Qué
hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
·
¿Qué
haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
·
¿Veo
algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo
del Sprint?
6. Adicionada
claridad sobre los bloques de tiempo (time-boxes)
Usando las palabras “a lo sumo” para
eliminar cualquier pregunta relacionada con que los Eventos tengan que ser de
cierta duración y, en cambio, esos son los tiempos máximos asignados.
7. Adicionado a la
sección Lista de Pendientes del Sprint (Sprint Backlog):
Para asegurar el
mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una
mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente
anterior.
Adicionada claridad a la sección Incremento:
Un incremento es
un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al
final del Sprint. El incremento es un paso hacia una visión o meta.
Descarga
la guía actualizada en Español:
Puedes hacerlo directamente de:http://www.scrumguides.org/download.html
viernes, noviembre 03, 2017
Un Horrendo y Horroroso Scrum
Hola a todos
Reciente pasamos el Hallowen y quisiera compartir algo que me asusta de muchas implementaciones y adopciones de Scrum.
Comencemos
Durante mucho tiempo en mis entrenamientos de Fundamentos de Scrum comparto el siguiente texto de Tobias Mayer (https://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/) con los asistentes:
"Imaginen si nuestros días en el trabajo estuviesen llenos de sonrisas y sentimientos de compañerismo y llenos de emoción. Imaginen un espacio de trabajo que se remontan a patios de la infancia, donde la invención y la innovación eran una parte natural de cada interacción. Imaginen que es responsable de su propio entorno, su propio ritmo y su propia carga de trabajo. E imaginen entregar con frecuencia un trabajo de calidad con a unos clientes encantados y relajados. Se puede convertir esa imaginación en realidad. Existe un mecanismo simple y bien entendido para ir desde donde estás ahora a donde le gustaría estar, y no, ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." Tobias Mayer
Y somos nosotros y no el framework los encargados de cambiar nuestra forma de trabajo, el framework ayuda, pero podemos aún teniendo Scrum como forma de trabajo situaciones que dan espanto:
- Product Owners o Scrum Masters que son los jefes de los equipos y los presionan y exprimen y los tratan como "recursos"
- Scrum Master que solo se preocupan de agendar reuniones y no se ocupan de la mejora continua de su equipo, ni de su PO
- Equipos en los que no se entienden (para ser sincero, realmente no son equipos)
- Equipos con deuda técnica creciente y sin herramientas adecuadas
- Equipos que no tienen buenas herramientas y no están orientados a la excelencia técnica
- Equipos con muchos sprints encima y sin salir a producción
- Equipos sin retrospectivas
- Equipos con dailys de seguimiento estricto y no de sincronización
- Equipos Scrum donde se gestionan las horas y las estimaciones y en los que "toca reponer el tiempo si se falla una estimación"
- Equipos Scrum trabajando bajo un contrato de alcance fijo, tiempo fijo y costo fijo (todo fijo)
- Metricas de cascada aplicadas a proyectos ágiles
- Product Backlog al cual se le hacen frecuentes controles de cambio
- Planning asignadas previamente por el PO (y posiblemente un líder técnico) y no estimadas por el equipo
- y muchas más
Lo anterior muy coincidente con la frase de Ken Schawber
“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura.(1) ” Ken Schawber
Da pavor ver estas situaciones, y es nuestra labor como Scrum Masters como Agile Coaches trabajar con la organización y los equipos para generar entornos de trabajo diferentes, y cierro como dice Tobias "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes."
Bienvenido el feedback, los comentarios y las historias de terror.
Saludos Ágiles
Jorge Abad
Notas
1. Creo que Ken hubiera querido terminar esta frase con una palabra más contundente
Suscribirse a:
Entradas (Atom)