Blog Post
Los "ScrumButs" II
Antonio Jesús Ruiz Córdoba • 9 de octubre de 2019
No lo llames Scrum, porque eso que haces no es Scrum.
Después de oír entre risas, porque es mejor reír que llorar, cómo uno de los asistentes a uno de mis cursos me contaba las ideas de su jefe para implantar Scrum, supe que mi siguiente entrada en el blog tenía que ser una continuación de los Scrumbuts.
Al jefe de esta persona, le había llegado algo de "Scrum" a los oídos y le dijo al equipo lo que se espera de un buen entorno Agile: "Los sprints los haremos unos de 3 días, otros de una semana, según nos vaya conveniendo", "las estimaciones en horas, por supuesto", "¿el scrum master? cualquiera" "tampoco hay que ser tan puristas con Scrum"... Esta persona es un ejemplo obvio de Scrumbut.
Los Scrumbuts son los motivos por los que los equipos no pueden obtener todas las ventajas de Scrum para resolver sus problemas y conseguir todos los beneficios del desarrollo de producto al usar Scrum.
En la última entrada del blog vimos cien ejemplos de Scrumbuts. Aquí veremos algunos repetidos. ¿Aún no lo has visto? Te dejo el enlace https://www.antoniojesusruiz.es/los-scrumbuts
Veamos ahora más frases que nos van a dar las primeras señales de alarma de estar ante un Scrumbut. Las vamos a separar en categorías:
- Scrum General:
- " Scrum es sólo para los desarrolladores, no para los miembros de Management ".
- " Agile nos dice que es 'Individuos e interacciones sobre procesos y herramientas', pero Scrum es un proceso, ¿no? ".
- Prácticas Waterfall:
- " El cliente necesita un gran diseño completo de antemano ".
- " Vamos a hacer primero una maqueta que sólo involucrará a los diseñadores ".
- " Las stories deberían tener diseños técnicos y funcionales ".
- " Ya hemos planeado los próximos 6 sprints ".
- " Nuestro backlog es un documento de requerimientos ".
- " ¿Story Points? ¿Sprints? ¿Backlog? Nuestros clientes no lo entenderán. Nosotros sólo hacemos contratos con alcance/ horas/t iempo fijo ".
- " Yo soy [Product Owner/Project Manager/Agile Coach/Scrum Master/Business Developer/Account Manager/Portfolio Manager/Team Manager] "(selecciona todos lo que apliquen).
- " Hagamos un [Design Sprint, Sprint 0, Architecture Runaway, Pre-Sprint, Discovery Sprint, Planning Sprint] ".
- No multi-disciplinar:
- " El equipo de desarrollo lo componen sólo desarrolladores software ".
- " Nuestro equipo de [QA/Diseño/UX/Arquitectura/IT]... " (o el departamento que quieras añadir).
- " Yo soy un [diseñador/desarrollador] por lo tanto, yo sólo [diseño/desarrollo] ".
- " [Luis] trabajará sólo en la Story [X], porque él sólo se basta" .
- " ¿Dos desarrolladores en la misma tarea/story? Eso es muy ineficiente ".
- Nuestro mánager no... (falta de auto-organización):
- " Aún no podemos confiar en el equipo para que se auto-organicen ".
- " No involucramos al equipo al hacer la oferta inicial a nuestros clientes ".
- " Ya le hemos dicho al cliente que... ".
- " El Product Manager es el Product Owner... también lo es el cliente... y cualquiera de sus interesados... Realmente, cualquiera que contacte con Management tendrá prioridad ".
- " Cuando el Product Owner rechazó [X], el cliente le dijo a Management que le dijera al Product Owner que... ".
- " [María] es la Product Owner, pero necesita la aprobación de los mánager antes de poder... ".
- " [Management y/o Product Owner] ponemos peticiones urgentes en el Sprint Backlog ".
- " El equipo de desarrollo no debería interactuar con el [cliente/usuario/interesado], sólo el Scrum Master o el Product Owner ".
- " Le pediremos al equipo que haga... ".
- " Management le pide al equipo B que haga cualquier cosa que funcione para el equipo A ".
- " Priorizamos nuestro trabajo según los interesados que contactan a Management estén más enfadados/molestos/frustados ".
- " Estimar con el equipo es ineficiente ".
- La rutina:
- " Sólo hacemos Daily Scrum ".
- " Los eventos de Scrum se hacen demasiado largos... ".
- " El Sprint no puede comenzar porque la Story [X] no está clara del todo ".
- " Este Sprint durará algo más, porque [Y] no se ha finalizado ".
- " Nuestros Sprints son de 6 semanas ".
- " El Sprint no puede comenzar porque aún quedan elementos del Sprint anterior por terminar ".
- " El equipo no ha entregado lo que se comprometió, así que tendrá que echar horas extras ".
- " El Sprint Review no puede comenzar, porque el equipo aún no ha finalizado ".
- " Las sesiones de coaching/training deberían hacerse durante los eventos de Scrum... o bien haciendo 'pizza sessions' después del trabajo ".
- " Usa el tiempo de las retrospectivas para finalizar tareas ".
- " ¡La estimación es demasiado alta! Ya habíais hecho algo similar, ¿no?. Va a ser sólo un copy-paste ".
- " Necesito [más información] antes de [empezar] ".
- " Como [una persona] no ha llegado, no tiene sentido que tengamos [cualquiera de los eventos de Scrum] ".
- " Deberíamos tener una reunión sobre... ".
- Las métricas:
- " La velocidad del equipo no está aumentando, por tanto el equipo no está mejorando ".
- " Añadiremos más capacidad al equipo para aumentar la velocidad y así cumplir con la demanda del cliente ".
- " No podemos esperar a las estimaciones del equipo, porque el cliente quiere las estimaciones hoy ".
- " Las estimaciones son las fechas límite de entrega ".
- " Las estimaciones las hace sólo el [Solutions Architect/Business Anaylist/Senior Developer] ".
- " No tenemos tiempo para hacer estimaciones ".
- " Nuestro burn-down chart se parece más a un burn-up chart ".
- " Nuestro burn-down sólo baja los viernes ".
- " Usamos 'compromisos' en lugar de 'pronósticos' ".
- " Un Story Point es una hora, ¿verdad? ".
- " ¿Cuántas horas son un Story Point? "
- Resistencia al cambio:
- " Siempre hemos hecho [X] así... ".
- " No deberíamos intentar cambiar [nuestra forma de trabajar] por ahora "
- " Sólo haré [tareas] que hayan sido definidas en [la herramienta X] y cumplan con [formato Y] ".
- " Yo soy [senior], así que no voy a hacer [tareas mundanas] ".
- " No podemos empezar (a trabajar en una story / un sprint) porque no tenemos todos los detalles ".
- Herramientas:
- " No necesitamos un Scrum Board físico porque usamos Jira ".
- " Usamos Jira, por lo tanto somos Agile ".
- " Todos los equipos tienen la obligación de usar Jira ".
- " Jira " (Sí, merece su propio ScrumBut).
- " Podemos usar Skype así que no hay necesidad de estar juntos ".
- " El cliente crea una petición en la herramienta [A], con enlaces a la herramienta [B] que incluye adjuntos de la herramienta [C] los cuales [copiamos/sincronizamos] a la herramienta [D] donde la refinamos antes de que lo muevan a la herramienta de los equipos Scrum [E] y los desarrolladores entonces crean las tareas en la herramienta [F] además de mantener el seguimiento de esas tareas en la pared de los post-it "
- Prácticas:
- " Todos hablamos sobre las pruebas automatizadas pero nunca las aplicamos realmente. Tampoco hacemos pruebas manuales porque deberían estar automatizadas ".
- " ¿Cuál de los catorce Sprint Goals debemos hacer primero? ".
- " Esto son sólo 15 minutos de trabajo, no hace falta que tenga todo el DoD, ¿verdad? ".
- " ¿Cursos?¿Formación? Sólo en tu tiempo libre ".
- " No hacemos documentación porque así lo dice el Agile Manifesto ".
- " No tenemos tiempo para trabajar en la deuda técnica ".
- Spikes, Stories y Definition of Done:
- " Una Story es lo mismo que un PBI, ¿no? ".
- " [Luis] añadió el criterio: 'Las ventas aumenten en un [añade un porcentaje aleatorio]' ".
- " [Carmen] añadió: 'etc.' ".
- " [Carlos] añadió: 'Ver el powerpoint adjunto' ".
- " [Ana] añadió el criterio: '¡Tiene que estar en producción hoy!' ".
- " [Juan] añadió como DoD: 'Que le guste al [Product Owner/usuario]' ".
- " [Laura] añadió como DoD: 'Que no haya bugs/defectos' ".
- " [Santi] creó una Story: 'Como Product Owner quiero un botón verde para comprar de forma que aumenten las ventas' ".
- " [Silvia] creó una Story: 'Como departamento de marketing queremos que el SEO aumente nuestra exposición' ".
- " [Alex] creó una Story: 'Como departamento de marketing necesitamos el envío masivo de correos esta tarde' ".
- " [Alicia] añadió un bug: 'El sistema no tiene [una característica nunca antes mencionada] que debería haber estado sin necesidad de haberlo dicho antes como parte parte de [X]. Por favor, ¡tenedlo listo para [mañana]!' ".
- " [Rafa] añadió una Story: 'Oh, sólo una cosa más...' ".
Échale un vistazo al siguiente vídeo que resume bastante bien la vida de un Scrum Master rodeado de ScrumButs:
Otras entradas del blog:
En mi experiencia, me he encontrado con muchos casos donde gente muy diversa reniega de Scrum afirmando, con excusas y ejemplos muy diversos que Scrum no funciona. Y esto lo hacen a todos los niveles, desde alta dirección, management, desarrolladores e incluso, algunos "Scrum Master". "Scrum está bien en la teoría, pero en la práctica no funciona", "es que nuestro caso es especial y Scrum no encaja en lo que hacemos", "Scrum tiene demasiadas reuniones que nos hacen perder el tiempo", "Scrum no sirve porque no se mira la calidad", "que sí, que en nuestra empresa hay un Scrum Master certificado y lo hemos probado en un proyecto tal cual viene en la guía y no hemos terminado en tiempo todos los requisitos que se nos pedían"... Casualmente, todos tienen algo en común: Interpretaciones o implementaciones incorrectas. Esto hace que el marco de trabajo Agile más común a nivel mundial, no sólo no dé ninguna ventaja, sino que acaba resultando contraproducente. ¿Quieres que veamos algunos de estos casos? Proyectos cerrados : Excusa : "Es que yo quiero xxxx para dentro de 30 meses y con un presupuesto cerrado de $$$ y con Scrum no puedo tenerlo" Explicación : Este punto parte de una base errónea que además es muy popular: "En Scrum está prohibido tener proyectos cerrados". No. En ningún sitio pone que esté prohibido tener proyectos cerrados y se puede trabajar perfectamente con Scrum un proyecto cerrado. ¿Pero, si la ventaja de Scrum es la adaptabilidad, para qué serviría en un caso como este? Pues justo para eso, para la adaptabilidad. La gran ventaja de Agile en general y Scrum en particular es que nos va a mostrar los problemas con muchísima antelación para que nosotros seamos capaces de adaptarnos, de forma que si vemos que no llegamos podemos aumentar el equipo (o reducirlo), adquirir nuevas herramientas que faciliten el desarrollo o cualquier punto que veamos que puede reconducir el problema. Si nos resultase imposible haciendo cambios de forma interna, tendremos que renegociar algo (alcance, coste y/o tiempo). Renegociar con mucha antelación da opción a que las condiciones puedan cambiar, mientras que si retrasamos dicha negociación hará que se complique o que las nuevas condiciones sean problemáticas para todas las partes. Si es imposible renegociar, posiblemente sea mejor cancelar un proyecto en el mes cinco que en el mes 29, que es lo que pasaría en caso de usar Waterfall (tendríamos muchos más gastos para llegar al mismo punto: No se puede hacer) Problema : Aquí el problema no es Scrum. Es el hecho de aceptar proyectos completamente cerrados en entornos complicados o complejos. Auto-engaño : "Es que mis clientes así lo exigen". MENTIRA (salvo que trabajes con la Administración Pública). ¿De verdad crees que RENFE exigió tener la mayor vergüenza de la ingeniería de software de la historia de España, en forma de una web donde los usuarios que querían hacer una compra sólo conseguían insatisfacción máxima? ¿No crees que si le hubieran dicho "Ey, renegociamos algo porque esto no tiene toda la calidad esperada" no hubieran preferido entregar con calidad un mes después o haber invertido un 5% más pero que los usuarios finales estuvieran contentos? Y si nos vamos al ejemplo inicial: ¿De verdad crees que, en un mundo como el actual donde cada poco tiempo sale algo totalmente novedoso, tu cliente quiere dentro de 30 meses algo que era útil hace 30 meses pero que en el momento de la entrega está obsoleto? ¿Y si durante ese tiempo sus necesidades han cambiado qué hacemos? ¿Le damos algo que ni quiere ni necesita sólo porque el proyecto era cerrado? ¿De verdad crees que ese cliente va a repetir con nosotros? Solución : Es tan sencillo como hablar con tus clientes y mostrarles, pero de verdad, que tu objetivo es su satisfacción y que para facilitar adaptarnos a sus necesidades y evitar casos "web de Renfe" debemos conocer qué podemos negociar en caso de ser necesario (aunque reflejemos qué, cuándo y con qué coste de forma inicial). ¿Quieres que veamos más ejemplos? Sigue atento a esta página donde actualizaremos con más detalles o únete a la Newsletter donde las próximas entregas irán dedicadas a desmitificar bulos sobre Scrum y Agile.
Hace unas semanas una chica me preguntó por la certificación de Agile Coach que ofrece el PMI (Project Management Institue). Mi respuesta no podía ser otra que, aunque el saber no ocupa lugar y mientras más te formes mejor, yo no me centraría en esa certificación y el motivo que le di era muy sencillo: Si a mí me pide una empresa que les ayude a contratar a un Agile Coach y hay varios candidatos que me demuestran similares conocimientos y experiencia, yo no sólo no valoro como algo positivo tener certificaciones del PMI, sino que incluso prefiero a alguien que no tenga ninguna al que sólo tenga de esta institución. ¿Por qué? La mayor empresa en el mundo en las certificaciones de Project Management lleva desde 1969 defendiendo un punto de vista predictivo y una forma de trabajo en cascada que no encaja con la filosofía Agile. No está mal en entornos muy simples, pero en cuanto el entorno se complica un poco esta forma de trabajo en cascada ha demostrado una y otra vez su ineficacia, de ahí que naciera hace más de 20 años Agile y su manifesto, para hacer las cosas de una forma distinta. Cuando vieron que perdían el monopolio de las certificaciones en gestión de proyectos por una forma más óptima de trabajar se unieron al carro haciendo su propia certificación en Agile, defendiendo que Agile era perfectamente encajable en la gestión de proyectos tradicionales haciendo algo así como la imagen de este post (imagen de monolit-it.pl/2018/02/Water-Scrum-Fall ). Es decir, que cogen una gestión de proyectos en cascada y, dentro de la fase de desarrollo, es donde se hace un trabajo en iteraciones como si trabajar así ya te hiciera Agile. Algo similar (con otra imagen) es algo que publicó por X (twitter) la cuenta @PMIMadridSpain (si lo quieres, tengo el enlace aunque acabaron borrando el contenido por la burrada tan gorda que defendían, prometo que era mucho peor que lo de la imagen). Aunque podría llegar a entender que trabajes así si es tu primer día en una transformación Agile (y no estás siguiendo mis consejos), debes saber que haciendo esa mezcla, vas a tener las desventajas de los dos mundos (cascada y Agile) y sin ninguna ventaja reseñable ni a corto ni a largo plazo. Así que es muy difícil tomarse en serio a quien claramente demuestra su incompetencia (por desconocimiento, por mantener el status quo...) y nos enseña como caso ideal lo que claramente es una crónica de una muerte anunciada y motivo por el que Agile nunca funcionará en tu organización. Y de repente, para empezar el año, noticia bomba: El Project Management Institute y la Agile Alliance han anunciado el día 3 que se asocian: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ Esta noticia ha dejado perplejo a todo el mundo dentro de la Agilidad. ¿Cómo es posible que dos formas tan antagónicas de entender la gestión de proyectos se unan? De una parte una organización sin ánimo de lucro que busca promover y compartir la filosofía Agile y por otra una gran empresa que busca mantener su hegemonía como único referente en la gestión de proyectos. Pues para entenderlo basta con leer la letra pequeña: "As part of this process, Teresa Foster, Managing Director of Agile Alliance, and her team will transfer to PMI" Esto es como cuando una gran empresa energética recibe una ayuda del gobierno que nadie entiende y que perjudica al resto de ciudadanos, y luego vemos que los ministros que la aprobaron, casualmente pasan a la empresa como asesores... pues algo parecido. Por un lado, la Agile Alliance será subvencionada por la mayor empresa en el mundo de certificaciones de Project Management, y el PMI, que ya vendía certificaciones Agile, ahora dirá que su contenido es bueno porque viene avalado por la Agile Alliance por lo que venderá más; y todo ello mezclado con esas "puertas giratorias" donde los que aprueban la colaboración se llevarán "su comisión". Así que, al final, es el dinero el que nos ha llevado a esto. ¿Mi opinión? Yo me mantengo receloso de esta colaboración. El cambio que tendría que dar el PMI para moverse en la mentalidad Agile tendría que ser tan grande que, casi casi habría que refundarlo. También creo que sus certificaciones de Project Manager van a seguir defendiendo esa forma de trabajo predictivo que funciona, sí, pero sólo en entornos muy simples. Hoy en día, hay muchas empresas certificadoras sobre Agile en general (y Scrum en particular) que, con mayor o menor prestigio hacen una defensa de esta forma de trabajar mucho más óptima (y coherente), por lo que yo no me iría a obtener una validación profesional justo a las antípodas de esta forma de trabajar. Si quieres validar tu carrera como Project Manager tradicional, ve al PMI. Si lo que quieres es validar tu evolución en Agile (y Scrum), que es lo que ahora más demanda el mercado, mi primera opción sería el PSM I de scrum.org (que puedes conseguir con mis cursos de Scrum ), siendo igual de válidas para la mayoría de las ofertas de trabajo hacerlo con EuropeanScrum o CertJoin (ambas también se pueden conseguir con mis formaciones ) o incluso Scrum Manager, Scrum Alliance y otras certificadoras. ¿Quién sabe? Igual, como he visto bromear en algún foro sobre este tema, dentro de poco nos encontramos con que el PMI ha abierto la certificación de "Agile Project Manager" o alguna aberración similar. Habrá que estar atento. ¿Y tú qué opinas sobre esto?
Deja de ser un buen Scrum Master para ser un gran Scrum Master
Necesitamos menos "managers" y potenciar el "self-managment"