February 19, 2018

Patrones Anti Scrum del Scrum Master

AntiScrum

  1. Un Scrum Master que le dice al equipo de desarrollo y al Product Owner que según alguna experiencia cada miembro del equipo de desarrollo solo puede desarrollar como máximo hasta una capacidad de X puntos de historia por Sprint, este tipo de Scrum Master también aclara que intentar que el equipo haga más puntos de historia implicaría presionar al equipo de desarrollo y crear un mal clima de trabajo. En Scrum lo que importa es la entrega de valor y el impacto en los clientes. La velocidad en puntos de historia no representa una métrica que refleje la entrega de valor. La velocidad en puntos de historia no representa una predicción del futuro y menos la capacidad del equipo de lo que puede entregar en cada Sprint.
  2. Un Scrum Master que dirige la reunión y le pregunta a cada miembro del equipo de desarrollo las tres preguntas como son, que hizo ayer, que va a hacer el día de hoy y que impedimentos tiene. En esta reunión el Scrum Master enfatiza a ese desarrollador que tiene que cumplir con las tareas que se ha comprometido. Los valores de Scrum fomentan un entorno cultural que fomenta el empoderamiento y la creatividad. El Scrum Master no es el policía de Scrum.
  3. Un Scrum Master que divide a un equipo de desarrollo al etiquetarlos con roles, por ejemplo, menciona a los “Programadores” que deben terminar su código para que puedan pasarlo a “QA” que está esperando algo que probar y que mientras eso no suceda la persona de “QA” se encuentra con tiempos muertos porque no tiene nada que hacer. El Scrum Master fomenta la colaboración y ayuda a que se pueda formar un equipo multifuncional que complemente sus competencias y mejorar continuamente sus capacidades de entrega de producto con valor.
  4. Un Scrum Master que protege al equipo de desarrollo estableciendo que como están sumamente ocupados no hay tiempo para interrumpirlos y por ello el Product Owner necesita hacer el refinamiento con el Scrum Master y evitar el contacto directo con el equipo de desarrollo porque ello podría impactar a los tiempos. La colaboración y cocreación son importantes para mejorar y fomentar la transparencia, el equipo de desarrollo tiene que aportar y participar del refinamiento.
  5. Un Scrum Master que trabaja con el equipo de Scrum el “Sprint Retrospective” con dinámicas que ayuden a fortalecer el buen ambiente de trabajo, ignorando las mejoras a los criterios de terminado, prácticas y herramientas ágiles y el proceso de Scrum. La agilidad se trata de mejorar la capacidad de respuesta al cambio a través de la entrega de producto innovador, la excelencia técnica es importante para ello así como una cultura ágil que provea confianza.
  6. Un Scrum Master que enfatiza al Product Owner y al equipo de desarrollo que si el equipo ha venido produciendo X puntos de historia de velocidad entonces no pueden hacer más puntos de historia o en última instancia podrían aumentar ligeramente los puntos de historia, pero en ningún caso se debe presionar al equipo porque podrían sentirse mal. En un entorno empírico se planifica para lo impredecible. Las velocidad no es una métrica que mide la productividad del equipo.
  7. Un Scrum Master de antemano establece un proceso de control de cambios que implica evitar que se incluya el “feedback” del Product Owner, este proceso va a establecer que se encuentra dentro del alcance del Sprint y que se encuentra fuera del alcance. Con este proceso se busca evitar que el Product Owner o alguien del equipo de desarrollo incluyan la información producto de las revisiones y refinamiento continuo. El empirismo se basa en aceptar los cambios y no en tratar de controlarlos o limitarlos.
  8. Un Scrum Master que establece con claridad que es responsabilidad del Product Owner ingresar todas las historias de usuario y criterios de aceptación en la herramienta, también que el Product Owner tiene que dar todo el detalle necesario porque el equipo de desarrollo solo hará aquello que el Product Owner les dice que haga, además si el Product Owner omite algo será de responsabilidad única y exclusiva del Product Owner y que en ese escenario el equipo de desarrollo no lo va a desarrollar porque como el equipo de desarrollo ha estimado a su máxima capacidad cualquier cosa que salga definidamente no será incluido.  Por ello el Product Owner es el único responsable de lo que se debe construir. La responsabilidad del Product Owner es maximizar la entrega de valor.
  9. Un Scrum Master que le dice al Product Owner que la única reunión donde se va a inspeccionar el incremento de producto es en el “Sprint Review” por ello debe tener paciencia y esperar a esa reunión. Antes de esa reunión el equipo de desarrollo no puede entregar nada para inspeccionar ni dar “feedback” porque tiene que terminarse el tiempo del Sprint según lo establece Scrum. La inspección y adaptación es continua durante el Sprint y no solamente al final del Sprint Review.
  10.  Un Scrum Master que le dice al equipo de desarrollo y al Product Owner que no se puede encontrar alternativas para mejorar, solo hay una alternativa que es primero desarrollar el código y luego hacer las pruebas. Scrum no dice cómo hacerlo y es la única alternativa, cualquier otra alternativa lleva riesgos que no se pueden asumir porque el Sprint es corto.
  11. Un Scrum Master que mapea los puntos de historia a horas. Es decir, el equipo hace la estimación en horas. Con esta técnica cumple con lo que dice Scrum de usar puntos de historia y también con el Jefe de Proyectos que le pide un plan detallado en horas.
  12. Un Scrum Master que le dice al equipo de desarrollo que Scrum es una metodología para gestionar proyectos y que está metodología se basa en que todos terminen las tareas a las que se han comprometido.
  13. Un Scrum Master que le dice al equipo que la estrategia es hacer un Sprint de desarrollo con pruebas iniciales y luego un Sprint de Testing para asegurar la calidad del producto.
  14. El Scrum Master asigna las tareas al equipo de desarrollo y le dice con precisión que hacer porque de esta manera se asegura que cometan menos errores. El Scrum Master toma las decisiones de quien hace que tarea en el equipo de desarrollo según su especialidad.
  15. Un Scrum Master que fomenta el uso del Sprint Cero para reducir el riesgo en la estimación y para que el equipo de desarrollo tenga tiempo para prepararse antes de iniciar el desarrollo en el Sprint 1.
  16. Un Scrum Master que requiere trabajar con dos tipos de Product Owners, un Product Owner técnico para que entienda técnicamente al equipo de desarrollo y un Product Owner de negocio para que defina los criterios de aceptación de cada Product Backlog Item.