Los "ScrumButs"

En las formaciones vemos que Scrum es un marco de trabajo, y por lo tanto tiene flexibilidad. Dos equipos distintos podrían estar haciendo cosas diferentes y eso no impediría que ambos estuvieran haciendo Scrum de forma correcta.
Sin embargo, algunos tienden a malinterpretar esa flexibilidad para hacer cualquier cosa, yendo incluso en contra de los principios ágiles. Que el marco sea flexible, no significa que lo podamos romper y rehacer a nuestro antojo, y encima tengamos el morro de seguir llamándolo scrum.
Y esto me recuerda a lo que una vez me dijo una mánager: " Scrum es lo que yo diga ". (Con la de gente válida que hay en el paro, aún me pregunto como algunos siguen en su puesto...)

Por eso, en este post vamos a hablar de los " ScrumButs ", que son aquellos que aseguran que hacen Scrum pero en realidad no lo están haciendo bien y por tanto están perdiendo el potencial que Scrum puede darles (en inglés, "I do Scrum but..." de ahí el nombre).

Para arrancar, veamos estos 100 Scrumbuts :
Hacemos Scrum pero...

1. No me siento seguro.
2. Nuestro equipo no es cross-funcional.
3. ¿Podemos extender la duración del Sprint?
4. A menudo nos saltamos la Retro.
5. Creo que sí porque, eso justo es lo que hace Jira, ¿no?
6. Sólo los Stakeholders internos asisten al Review.
7. Seguimos intentando seguir un RoadMap .
8. Nuestro equipo no está preparado para auto-organizarse.
9. Sólo nuestro PO habla con los Stakeholders.
10. Tenemos que hacer un parche (hotfix) ya.
11. El PO nos dice qué hacer en el Sprint Planning.
12. Hagamos un [Design Sprint, Sprint 0, Architecure Runway, Pre-Sprint, Discovery Sprint, Recovery Sprint, Planning Sprint].
13. No necesitamos hacer Daily Scrum.
14. ¿Y cómo encaja aquí el Project Manager?
15. Management habla de Agile pero actúa como Waterfall.
16. Fallar no es una opción.
17. El mercado es demasiado dinámico como para planificar.
18. Saltémonos estos puntos del DoD (Definition of Done) por ahora.
19. Si el equipo no entrega lo que se comprometió tienen que echar horas extras.
20. Deberíamos planear una reunión para discutir...
21. ¿Cuántas horas son un Story Point?
22. El PO se apropia del Sprint Backlog.
23. El Sprint Review no es más que una Demo.
24. No le digas al cliente...
25. Odiamos los eventos de Scrum.
26. Management no lo es.
27. Nuestro Daily dura a veces 40 minutos.
28. El contrato dice que...
29. Preferimos hacer el Daily cualquier otro día.
30. Nuestro Burn Down Chart sólo baja los viernes.
31. No tenemos una definición que todos conozcamos de lo que significa "Terminado".
32. ¿Cursos? ¿Formación? Eso en tu tiempo libre.
33. No gastamos tiempo en refinar el Product Backlog.
34. Como X no ha llegado aún, no podemos hacer [pon aquí cualquier evento de Scrum].
35. El incremento... no me parece nada.
36. No hacemos visible nuestro trabajo.
37. Todos hablamos de las pruebas automáticas, pero nunca lo aplicamos realmente. Tampoco hacemos pruebas manuales porque deberían estar automatizadas.
38. Nuestro equipo trabaja en múltiples productos a la vez.
39. Que esté terminado para mañana.
40. ¡Management quiere implantar SAFe!
41. Nuestro equipo está formado por 18 personas.
42. ¿Más de un desarrollador en la misma historia? Eso es ineficiente.
43. Nuestro PO es un comité.
44. Hacemos grooming .
45. Yo soy Diseñador/Desarrollador/QA/etc...
46. ¡Management nos dice que tenemos que aumentar nuestra velocidad!
47. Tenemos una " ReviewSpective "
48. Es que Jira se ha caído.
49. Empecemos con un Sprint 0.
50. Scrum no es Agile.
51. Nuestro Burn Down Chart se parece más a un Burn UP Chart.
52. Aún planeamos los próximos 6 Sprints.
53. ¿No recibiste el memorando/ la circular/ las instrucciones?
54. Nuestro cliente demandó un gran diseño completo de antemano.
55. Tú dime qué hago.
56. Tenemos que usar Jira.
57. Nuestros Sprints parece marchas fúnebres.
58. Nuestras estimaciones son " Deadlines ".
59. ¿Definition of Done? Si esto se hace sólo en 15 minutos...
60. No tenemos incremento de producto al final del Sprint.
61. Tenemos seis Sprint Goals para este Sprint.
62. El Daily es un reporte de estado al Scrum Master.
63. El equipo no está al tanto de las promesas que Management está haciendo a los Stakeholders.
64. Consideramos una maqueta como un Incremento.
65. Nuestros Stakeholders están demasiado ocupados para unirse a los Sprint Reviews.
66. Nuestro producto es "oscuro y está lleno de terrores".
67. Una User Story es un PBI (Product Backlog Item), ¿no?
68. Nuestro Scrum Master apesta.
69. Nuestro Sprint Backlog está fijo.
70. La mayoría de nosotros nunca se ha leído la guía de Scrum.
71. No tengo ni idea de en qué está trabajando mi compañero.
72. Todos los PBI tienen que estar terminados al final del Sprint.
73. Nuestro Sprint Goal es aumentar la velocidad.
74. Podemos posponer el próximo Sprint, ¿verdad?
75. Lo pronosticado es nuestro Sprint Goal.
76. Management prefieren un Agile Coach a un Scrum Master.
77. No tenemos tiempo para resolver deuda técnica ni refactorizar.
78. El Product Owner (o el Scrum Master) asigna todas las tareas.
79. ¿Dónde y cuándo es el Daily esta vez?
80. Sólo el Product Owner puede acceder al Product Backlog.
81. No llevamos los planes de mejora de la última Retro al Sprint Planning.
82. Scrum tan sólo es una excusa para no llegar a las fechas límite.
83. La velocidad del equipo no está aumentando, por lo que no están mejorando.
84. Scrum está anticuado.
85. No tenemos el entorno ni el soporte que necesitamos.
86. No hemos integrado nada en años.
87. Nuestro Scrum Master es también el Product Owner.
88. Nuestra organización es demasiado grande para Scrum.
89. Nos llaman "cerdos".
90. Nos llaman "recursos".
91. Nuestro Product Owner está ausente todo el tiempo.
92. Nuestro Daily Scrum se ha convertido en un Weekly Scrum.
93. Parece que no podemos estar en desacuerdo y comprometernos.
94. No se confía en nuestro equipo para hacer el trabajo.
95. El Scrum Master sólo facilita los eventos.
96. Tengo quejas durante días.
97. QA lo hace un equipo separado en un edificio diferente.
98. Seguimos sin saber explicarlo a Management.
99. No estamos abrazando sus valores.
100. ¿Por qué seguimos necesitando un Scrum Master?

Si te sientes identificado en alguno/s de los puntos y pensabas que eso era lo correcto... igual te vendría bien asistir a una de mis sesiones de formación ;-)

Pronto haremos una revisión de los principales Scrumbuts en los distintos niveles de la organización. Permanece atento porque será para reír, por no llorar, porque por desgracia los Scrumbuts están por todos lados.

¿Te has tenido que pelear con alguno de estos 100 Scrumbuts? ¿Cómo has hecho para solucionarlo? ¡Deja tu comentario!





Fuente: https://medium.com/serious-scrum/100-scrumbuts-value-down-the-drain-3e470d9e3623