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.
  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.
  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.
  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.
  5. Un Scrum Master trabajar 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.
  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.
  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.
  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.
  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.
  10. Un Scrum Master que le dice al Product Owner y al equipo de desarrollo que no usa Scrum sino la agilidad, por esa razón los “Daily Scrum” se harán esporádicamente cuando sean necesarios y solamente si el equipo lo decide porque ellos son auto organizados.
  11.  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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.