viernes, noviembre 17, 2017

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

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 la verdad cuando lo comenzamos a leerlo, todos creemos que vamos a terminar diciendo "sí, si es Scrum, es la bala de plata que siempre habías buscado y que va a solucionar todos tus problemas" y el texto termina muy clara y contundentemente "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes."

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