Traducción al castellano del post “50 Best Scrum Practices for Dream Team” de Kevin Wood

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum (50 Best Scrum Practices for Dream Team) y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

Batman y Robin

Scrum es uno de los frameworks más populares para implementar Agile. De hecho, muchas personas creen que Scrum y Agile son la misma cosa, aunque definitivamente no lo son. Agile es un grupo de metodologías de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agile pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.

Equipo

  • Los miembros del equipo trabajan en roles multifuncionales
  • El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
  • Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
  • Los miembros del equipo piden ayuda proactivamente
  • Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna

Scrum Master (SM)

  • El SM facilita la autoorganización del equipo
  • El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de scrum)
  • El SM protege al equipo de distracciones externas e internas
  • El SM permite una estrecha cooperación en todos los roles
  • El SM interactúa con la alta dirección

Propietario del Producto (PP)

  • El PP interactúa con el equipo y todas las partes interesadas (Stakeholders) para crear el
    backlog
    o la Pila de Producto
  • El PP escribe historias de usuario y criterios de aceptación
  • El PP prioriza la Pila de Producto y decide sobre las fechas de lanzamiento de las diferentes versiones
  • El PP acepta o rechaza historias de usuario
  • El PP cancela el sprint si piensa que el objetivo del sprint ya no tiene sentido

Definición de Hecho o Definition of Done (DoD)

  • Cada historia de usuario cumple los criterios del DoD
  • Todos los miembros del equipo y el PP conocen de memoria el DoD y lo respetan

Estimación

  • El PP obtiene estimaciones a partir del equipo
  • Sólo estima el equipo
  • Cada miembro del equipo participa en la estimación
  • El equipo estima usando la técnica del Planning póker

Reunión de planificación Sprint

  • Todos los miembros del equipo participan
  • El PP presenta las historias de usuario priorizadas al equipo
  • Todas las historias del sprint están estimadas
  • La reunión da como resultado un plan de sprint

Sprint

  • El equipo entrega algo después de cada sprint
  • El equipo sigue las prioridades marcadas por el PP
  • El equipo alerta al PP cuando tienen problemas
  • El equipo trata los problemas cuando ocurren (no más tarde)
  • La longitud de Sprint no cambia después de cada sprint
  • Las historias que se han empezado terminan dentro del mismo sprint

Pila de Sprint (PS)

  • La PS está visible y es de fácil acceso para el equipo
  • La PS se actualiza todos los días
  • Las estimaciones de las tareas se actualizan todos los días
  • Los miembros del equipo actualizan la PS por ellos mismos
  • Las historias están claramente mapeadas

Scrum Diario (SD)

  • El SD tiene ocurre a la misma hora y lugar todos los días
  • El SD comienza y termina puntualmente
  • Todos los miembros del equipo están involucrados
  • El PP participa en la reunión por lo menos unas pocas veces por semana
  • El equipo revisa el gráfico de burndown y toma medidas si van retrasados
  • El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después

Revisión de Sprint

  • La demo formal se realiza después de cada sprint
  • Sólo las historias aceptadas por PP se demuestran
  • Todos los interesados se han invitado para la demo con antelación
  • Se anima a las partes interesadas a dar su opinión durante la demo

Retrospectiva

  • La Retrospectiva tiene lugar después de cada sprint
  • Todos los miembros del equipo y el PP comparten el feedback
  • El equipo analiza los datos y decide que acciones emprender
  • Las acciones se priorizan e implementan en los próximos sprints

Sobre el autor

Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Esperamos que os sea de utilidad y vuestros comentarios

Post escrito conjuntamente por Gertrudis López y Alexander Menzinsky

Anuncios

Jugando Cynefin Lego Game en el Road to BAOS 2017

davSiguiendo con los workshops organizados en la Comunidad Madriagil en el Road to BAOS 2017 por João Barreiro y Unai Roldán, el sábado pasado compartimos una maravillosa experiencia que consistió en un taller donde jugamos al Cynefin Lego Game de Andrea Tomasini,  que permite experimentar cuatro de los cinco dominios del marco de trabajo Cynefin de David Snowden.

Cynefin* se utiliza en el marco de las metodologías ágiles para darles una base científica. Surge de investigaciones en los ámbitos de la teoría de sistemas,Modelo Cynefin la teoría de la complejidad, la teoría de la red y teorías de aprendizaje y es muy útil para entender y explicar porqué distintos enfoques de trabajo y de hacer las cosas funcionan bien en un entorno y en otro no. Cynefin compara cinco dominios de distinta complejidad: Obvio, Complicado, Complejo, Caótico y Desorden y define sus características principales, lo que nos da una guía para identificarlos en nuestros entornos de trabajo y de esta manera tomar decisiones e implementar acciones de una manera más informada con el objeto de mejorar la forma de trabajar y tratar de reducir su nivel de complejidad en la medida de lo posible.

Primera ronda del juego

El objetivo de la primera ronda fue trabajar con el cuadrante de lo Obvio, donde las relaciones causa efecto son obvias y la manera de hacer las cosas es conocida por todos, muchas veces rutinaria y no requiere pensar mucho antes de comenzar a trabajar, por lo que existen mejores practicas o se pueden identificar fácilmente. Es el entorno que más se corresponde con el área de operaciones.

Nuestra tarea fue coger las piezas, separarlas por colores y hacer un grupo especial para las piezas raras (ruedas, engranajes, etc.). A continuación pueden observar el resultado:

resultado de la primera ronda

foto iratxe

grupo cpn piezas separadas

Una vez hecha la tarea reflexionamos sobre las buenas prácticas que habíamos aplicado, que fueron: ponernos de acuerdo para ver como íbamos a trabajar, dividiendo el trabajo de cada miembro del equipo por tonos de piezas y colaborar con los otros miembros pasando piezas del tono que estaba trabajando.

Segunda ronda del juego

El objetivo de la segunda ronda del juego fue trabajar con el cuadrante de lo Complicado, donde las relaciones causa-efecto no son obvias, pueden haber muchas buenas practicas para resolver un mismo problema, se necesitan expertos que orienten hacia cuál es la mejor y se necesita pensar antes de comenzar a trabajar.

La tarea fue, después de juntar las piezas que habíamos separado por colores, construir una torre lo más alta posible, siguiendo un patrón de colores y donde las piezas de arriba no fueran más grandes que las piezas de abajo. A continuación pueden observar el resultado de cada equipo:

Resultado de la segunda rondaTorre del grupo de IratxeResultado de la segunda ronda 2

Una vez hecha la tarea reflexionamos sobre las buenas prácticas que habíamos aplicado. Lo primero es que tuvimos un tiempo para pensar y para planificar cómo íbamos a hacer el trabajo y nos coordinamos e interactuamos mucho más que en la primera ronda.

Tercera ronda del juego

El objetivo de la tercera ronda del juego fue trabajar con el cuadrante de lo Complejo, donde las relaciones causa-efecto existen pero para entenderlas hay que mirar al pasado, no hay buenas prácticas identificadas y hay que probar soluciones para ver si funcionan o no. Para trabajar en este cuadrante hace falta mucha creatividad, innovación e intercambio de ideas.

La tarea fue, después de desmontar la torre de la ronda anterior, construir un animal siguiendo un patrón de colores, cada miembro del equipo sólo podía tocar un color y no podíamos hablar entre nosotros. A continuación pueden observar el resultado de varios equipos:

Resultado de la ronda 3 1                      Serpiente construida en la tercera ronda para trabajar lo Complejo

Resultado de la segunda ronda 3                       Elefante construido en la tercera ronda para trabajar lo Complejo

dav
Otra serpiente construida en la tercera ronda para trabajar lo Complejo

Aquí nos dimos cuenta que era necesario comunicarnos de alguna forma, y como no podíamos hablar en dos equipos nos comunicamos a través de notas escritas y otro grupo se comunicó a través de señas. Al encontrar la manera de comunicarnos pudimos ponernos de acuerdo en el animal a construir, qué color y en qué partes del animal iba a trabajar cada uno.

Cuarta ronda del juego

El objetivo de la cuarta ronda del juego fue trabajar con el cuadrante de lo Caótico, donde no tienes tiempo de pensar, haces algo y lo pruebas para ver si funciona y se reduce el nivel de caos existente para tratar de llevarlo a una situación de complejidad.

La tarea fue, después de desmontar el animal de la ronda anterior, construir un vehículo, sin hablar entre nosotros, siguiendo un patrón de colores, donde cada color podía ser tocado por una sola persona y cuando Unai tocara a alguien del equipo se lo llevaba a otro equipo. A continuación pueden observar el resultado de varios equipos:

Resultado de la ronda 4 2

Resultado de la ronda 4 1jpeg

Vehículo del grupo de Iratxe

Aquí el caos se producía cuando alguien del equipo se iba a otro equipo y llegaba alguien nuevo. Había que tratar de solucionar esa situación de alguna manera para que el nuevo miembro se incorporara al equipo y entendiera que es lo que se estaba haciendo y la forma en la que podía participar. Lo hacíamos por señas y cuando no veíamos la forma de participar en un nuevo equipo, lo mejor que podíamos hacer era no hacer nada para no entorpecer el trabajo de los demás.

En la parte final del taller compartimos opiniones y entre otras llegamos a concluir lo siguiente:

  • A nivel metodológico tenemos que detectar en que cuadrante estamos y con base en esto pensar como actuar
  • La ayuda para tratar de reducir la complejidad está en las buenas prácticas
  • Con el tiempo, nuestros productos cambian de un cuadrante a otro
  • Scrum es un marco de trabajo para construir productos complejos de una manera sencilla
  • Cynefin se ha visto que funciona mejor cuando el equipo habla directamente con el cliente e intercambian ideas y opciones de como reducir la complejidad
  • Hay que buscar que, culturalmente, los equipos se sientan cómodos en entornos complejos
  • Si cortamos los hilos de feedback y no conocemos los resultados de las acciones que acometemos, hay problemas.
  • En sistemas complejos a veces hay intereses ocultos que no sabemos que existen y que pueden ser la causa de muchas situaciones inexplicables.

Muchas Gracias a Unai y a João por organizar y conducir el taller y a todos los que participamos. Fue una mañana llena de aprendizajes y diversión.

Saludos Cordiales y espero que el post os sea de utilidad así como espero vuestros comentarios

Gertrudis

*: Otros posts interesantes sobre Cynefin
http://www.javiergarzas.com/2016/07/entendiendo-modelo-cynefin.html
http://www.martinalaimo.com/es/blog/cynefin

Mapa mental del post: “7 SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND” de Luis Gonçalves

Estoy preparando una formación para Scrum Masters y uno de los puntos que me parece fundamental tratar es el de los antipatrones que se presentan frecuentemente en las organizaciones y en las implementaciones de Scrum con respecto a este rol.

Pienso que es importantísimo tratar este tema en las formaciones y reuniones de Scrum Masters para abordarlo tanto de manera preventiva como también post-mortem, es decir, una vez que se ha presentado alguno de los antipatrones, para poder ser capaces de prevenir su aparición siendo conscientes de su existencia y de sus características y en el caso de detectar su presencia poder tomar las acciones necesarias para corregir dicha situación.

Para tratar el tema me gusta un post de Luis Gonçalves: “7 SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND”, que me parece supercompleto y práctico, ya que habla de los principales antipatrones que se dan en las organizaciones con respecto al rol del Scrum Master, debido principalmente al desconocimiento por parte de la organización de la importancia de este rol en las implementaciones de Scrum y también al desconocimiento y/o falta de puesta en práctica del enfoque de “Servant Leader” (Líder al servicio del equipo de desarrollo, del Product Owner y de la organización) por parte de los mismos Scrum Masters.

Aunque el título hace referencia a siete antipatrones, en la última actualización del post, Luis identifica y describe ocho antipatrones asociados al rol de Scrum Master:

  1. “Scrum Master” en vez de “Jefe de Proyecto”
  2. Mezcla de roles “Scrum Master” y “Product Owner”
  3. Falta de enfoque
  4. Scrum Masters que no hacen coaching a la organización
  5. Scrum Master sólo como secretaria
  6. Scrum Masters que no hacen coaching al Product Owner
  7. Scrum Master no reconocido por la gerencia
  8. Cambiar frecuentemente quien ejerce el rol de Scrum Master

Para entender en profundidad cada antipatrón y tener una base de discusión sobre el tema, he elaborado un mapa mental en la herramienta colaborativa Mindmeister que los resume y que permite ver de una manera esquemática cada antipatrón y sus elementos: cuando se puede presentar, los problemas que puede ocasionar y posibles soluciones. Haciendo click aquí o sobre la imagen podéis acceder al mapa en el Mindmeister y ver el detalle de cada uno de los antipatrones.

Imagen del Mapa mental de antipatrones del Scrum Master

Imagen del mapa mental en castellano del post “SCRUMMASTER ANTIPATTERNS THAT EVERY SCRUMMASTER MUST UNDERSTAND” de Luis Gonçalves

Comparto el mapa mental en el blog porque pienso que os puede ser de utilidad y servir como base para formaciones, retrospectivas e intercambio de ideas sobre el tema con el objeto de generar discusiones, reflexiones sobre si se está dando algún antipatrón, posibles formas de resolverlos y el descubrimiento de otros antipatrones no incluidos aquí.

Espero vuestros comentarios

Saludos Cordiales,

Gertrudis López

 

Comentarios sobre el keynote de Corinna Baldauf sobre Retrospectivas en la CAS 2015

Nada más apropiado para comenzar este blog que hablar de lo mejor de la CAS 2015, la Conferencia Agile Spain que se celebró en Madrid los días 3 y 4 de diciembre de 2015.

cas2015 imagen
Poster de la CAS 2015

Quiero compartir con vosotros lo mejor de las conferencias a las que asistí, para que los que no tuvieron la oportunidad puedan enterarse de que se habló y para los que asistieron puedan compartir sus experiencias y sus aprendizajes.

Lo mejor de la CAS 2015, reseña del keynote de Corinna Baldauf sobre retrospectivas.

Pues voy a comenzar por el final y voy a reseñar el último Keynote de la CAS 2015, de Corinna Baldauf* sobre Retrospectivas. En próximas entradas reseñaré las otras conferencias a las que asistí.

baldauf-corinna
Corinna Baldauf, autora de la herramienta Retr-O-mat, para ayudar a crear retrospectivas novedosas e inspiradoras

Primero que todo, me pareció genial cerrar el evento con este Keynote, donde se hizo la retrospectiva de la CAS 2015. De verdad que fue muy valioso el poder tener unos momentos de reflexión sobre todo lo aprendido a lo largo de la conferencia y lo más importante, concretar qué es lo que íbamos a hacer cada uno después de la CAS 2015 con lo que habíamos aprendido y como implementarlo y divulgarlo.

Hicimos una actividad interactiva donde teníamos que compartir con nuestro compañero de al lado cuál fue la experiencia más impresionante que habíamos tenido en la CAS 2015. Lo interesante de esta actividad es que las respuestas no se circunscribieron únicamente a las charlas como tal, sino a los eventos informales surgidos a raíz de la CAS 2015, por ejemplo, una cena entre amigos que hace tiempo no se habían visto en donde compartieron experiencias e historias sobre Agile y otros temas. Otra experiencia impresionante que surgió fue el sitio donde se hizo la CAS 2015, el Círculo de Bellas Artes de Madrid, lo hermoso de sus espacios y sobre todo su espectacular azotea. Con respecto a las actividades de la CAS propiamente dichas, la experiencia más impresionante que comentamos fue el taller práctico de Design Thinking.

 

 

azotea-del-circulo-de-bellas-artes_vistas 8
Vista desde la azotea del Círculo de Bellas Artes de Madrid
circulo de bellas artes interior 5
Escaleras del Círculo de Bellas Artes de Madrid

Luego hicimos otra actividad en grupo donde cada miembro debía responder a la siguiente pregunta: ¿Qué he aprendido de la CAS y qué quiero probar en el trabajo?

Surgieron muchas ideas, entre ellas:

  • Llevar Agile más allá de proyectos concretos, es decir, llevar Agile a la organización como tal.
  • Seguir trabajando con el Design Thinking
  • Incorporar dinámicas y juegos en las reuniones de planificación de sprints y en las retrospectivas
  • Propiciar y organizar actividades de aprendizaje en el marco del equipo de trabajo
  • Implementar formas de compartir temas y/o lecciones aprendidas sobre temas de interés para todos los miembros del equipo
  • Hacer posters de los temas y lecciones aprendidas en la CAS para pegarlos en nuestros lugares de trabajo para que todos nuestros compañeros pudieran enterarse de los temas tratados
  • Tener una reunión con nuestros jefes para ver formas de implementar Agile en el trabajo diario
  • Y yo propuse el comenzar a hacer este blog sobre Agile, para compartir lo aprendido y lo que voy aprendiendo, así que aquí estoy, implementado mi propuesta.

A continuación os comento los puntos que más me impactaron de lo que dijo Corinna en este Keynote:

  1. Si quieres adoptar alguna practica ágil en tus proyectos, adopta las retrospectivas
  2. Nuevas preguntas hacen aflorar nuevas respuestas, por esto es que siempre busca nuevas preguntas. Las nuevas preguntas permiten que los participantes adopten nuevas perspectivas, tengan nuevas ideas y formas nuevas de solucionar los problemas detectados
  3. Las cinco fases de una retrospectiva:
    1. Set the stage (Armar el escenario)
    2. Gather data (Recolectar datos)
    3. Generate insight (Indagar y descubrir el meollo de la necesidad o del problema)
    4. Decide what to do (Decidir qué hacer)
    5. Close the retrospectiva (Cerrar la retrospectiva)
  4. Hacer las retrospectivas SMART:
           Specific (Especificas)
           Measurable (Medibles)
           Attainable (Alcanzable)
           Relevant (Pertinente)
           Timely (oportuno)
  5. La interactividad en las retrospectivas es fundamental
  6. Hacer la retrospectiva de la CAS 2015 al pensar y responder las preguntas:
    – ¿Cuál fue la experiencia más impresionante que habíamos tenido en la CAS? y compartirla con la persona que estaba sentada a nuestro lado
    – ¿Qué he aprendido en la CAS y qué quiero probar en el trabajo?
  7. Libro recomendado:
    Agile Retrospectives: Making Good Teams Great. Autoras: Diana Larsen y Esther Derby
  8. Como conclusión general:
    1. Comenzar con retrospectivas
    2. Aprender a hacerlas bien
    3. Seguir adelante con las retrospectivas
    4. El resto vendrá por sí mismo

Podéis ver el vídeo de la conferencia de Corinna en la CAS 2015 pulsando aquí.

*: Corinna Baldauf es la creadora de una herramienta para ayudar a crear retrospectivas novedosas e inspiradoras llamada Retr-O-Mat, disponible en español en el sitio http://plans-for-retrospectives.com/index_es.html?id=42-33-68-29-53 (abre en ventana nueva) (traducido por Thomas Wallet y Pedro Serrano). Retr-O-mat propone distintas dinámicas de grupo para llevarlas a cabo en cada uno de los cinco pasos de las retrospectivas mencionados anteriormente.