prohibido
Todo el mundo habla de los beneficios de SCRUM pero yo te voy a contar sus 5 principales “fallos” por los que no se implantará en tu Empresa. Como lo lees, no se va a implantar en tu empresa.
La gestión de proyectos ágil está de moda ya lo vimos en nuestra encuesta ¿somos ágiles o predictivos? pero como todas las modas tiene algunos puntos débiles que algunos no ven.
Esta ceguera hace que se tiren de cabeza a abrazar la nueva metodología (la buena nueva, la que toque en ese momento) porque por sí sola resolverá todos los problemas, nada más lejos de la realidad.
Ten en cuenta estos 5 puntos de SCRUM que pueden hacer peligrar su integración en tu empresa:
El Product Manager debe tener claro cual es el objetivo del producto hacia donde debe ir el proyecto, cosa distinta es que los requisitos finales estén por ver pero debe tener claro adonde quiere llegar.
Con esa idea en mente, con esa guía, debe ir alimentando el Backlog (la pila de producto) con las siguientes historias a desarrollar. Debe completarlas con el nivel de detalle suficiente y debe priorizarlas para que el equipo pueda ir seleccionándolas en cada iteración.
Esta labor es del cliente, del Product Owner y si no la hace, SCRUM no funciona. Demasiadas veces he asistido a clientes que te dicen: “yo te he dicho lo que quiero, eso ya lo gestionas tú” desentendiéndose de esa labor necesaria por su parte.
Tenlo en cuenta cuando implantes SCRUM en tu empresa.
Mucha gente asocia instantáneamente que el Scrum Master es un Director de proyecto, un project manager, un jefe de proyecto,… la idea no es esa. Como vamos a ver en el siguiente punto el equipo Scrum es autogestionado, vamos que se gestionan ellos solos.
¿Entonces el papel del Scrum Master?
El papel del Scrum master es un papel de apoyo, algunos lo traducen como facilitador. Suele ser una persona con experiencia en el uso de Scrum y ayuda a aplicarlo de la forma adecuada. También se encarga de algunas relaciones con el Product Owner y de gestionar los impedimientos.
Da consejos pero no ordena.
Este fallo es el que mata a todo el mundo. Si el equipo SCRUM es autogestionado eso significa que no hay un rol que lo dirija sino que el propio equipo al completo se gestiona. Por tanto abstente de poner al mando a alguién porque entonces perderás la agilidad.
Si no hay autogestión, SCRUM no funciona ya que tendríamos una réplica de un sistema predictivo en lugar de un sistema ágil.
El backlog debe tener una dimensión determinada y no convertirse en una lista infinita de requerimientos que al final se gestione como un proyecto predictivo con construcción de prototipos.
La idea de SCRUM es que haya una cierta incertidumbre por lo que no podemos saber todo a priori. Habrá cosas que averiguaremos por el camino y, por ello, hay que ir poco a poco, no todo de golpe. Esto nos permitirá adaptarnos a esas situaciones que desconocemos y que sin duda se presentarán y además nos habilitarán a dar la mejor solución posible.
Esto no quita que puedas tener otras listas independientes del Backlog para ir agregando lo que se te vaya ocurriendo para evaluarlo en un momento posterior pero el backlog déjalo flaco.
Muchos clientes piensan que la agilidad es poco más que hacer las cosas sobre la marcha como las vas pensando y ya está. Por eso, ven ahorros al eliminar todos los procesos que hay que hacer en los modelos predictivos y que no son necesarios con la agilidad.
Pero en agilidad también hay que planificar.
La planificación en scrum, claro está, es una planificación ágil y por tanto hay que comprenderla dentro de su propio objetivo y dentro de su forma de realizarse.
Por ejemplo, en el Sprint 0 (aunque a algunos puristas no les gusta llamarlo así porque no hay ninguna entrega de componente del producto a desarrollar) se planifica y se acuerdan aspectos del producto como estándares a usar, nomenclaturas a emplear, etc.
Por otro lado, cuando se estiman los elementos del Backlog se genera un Plan de Entregas que se irá ajustando tras cada Sprint.
Como ves algo de planificación hay pero planificación ágil.
¿Te has encontrado con algún otro problema al implantar Scrum en tu empresa? ¡Compártelo con nosotros!
Este año ha sido complicado. En el sentido de que ha sido un año duro.…
Y el año se acaba. Después de tantos días juntos en este blog hoy llegamos…
Las compañías energéticas están en el ojo del huracán con los precios que estamos sufriendo…
Sin duda hay una creencia muy extendida que piensa que las cosas se consiguen porque…
El Haiku de hoy de Taylor Swift me encanta. Resume perfectamente lo que no debes…
Las ideas innovadoras siempre son interesantes para que nos puedan inspirar. Si además ayudan a…
View Comments
Hombre a parte de lo de "spring" que entiendo que querías poner sprint hay muchos factores que determinan si Scrum es implantable o no, por ello las empresas que realmente tienen varias tipologías de proyecto saben la importancia de tener una PMO (oficina de proyectos) que regula la metodología a implantar en los proyectos y la evolución - velocidad de desarrollo. Recordad que Scrum se centra en el ROI (retorno de la inversión).
Factores como el tamaño de los equipos, si son cross functional, la madurez de la organización, la tipología de la empresa (funcional, matricial,orientada a proyectos...) marcan si se puede optar no por scrum sino por metodologías ágiles o no.
En el punto que discrepo es en el 5, si hay una reunión llamada sprint planning creo que está claro que se planifica. En el punto 3 lo de que el equipo toma decisiones, relativamente, la última palabra es del product owner si tiene afectación hacia afuera. Y en el punto 1 yo iría un paso más allá, a parte de saber del producto debe conocer la metodología y hacer cálculos como ROI, TIR, VAN,... ya que es uno de los fundamentos de su estrategia de priorización del backlog, hay otras no malinterpretéis, pero el ROI pesa mucho.
La "Primavera" la sangre altera gracias por el aviso Miguel.
Estamos de acuerdo en que lo ideal es tener una PMO que tenga los medios necesarios para poder seleccionar la mejor metodología/modelo/mejores prácticas para cada proyecto, porque coincido contigo en que la naturaleza del proyecto es lo realmente determinante.
También estoy de acuerdo en que pueden existir muchos motivos por los que finalmente no funcione SCRUM en una empresa, por ejemplo se me ocurre que alguien quiera boicotear el proceso porque se opone a los cambios, sin importar si este es a mejor o a peor.
Por eso, mi perspectiva es la de pensar problemas en empresas que inician su implantación sin tener una experiencia previa o importante en SCRUM y como se pueden malinterpretar ciertos roles y ciertas prácticas pensando que son como en otras metodologías o porque es lo que "yo creía que" "yo pensaba que".
Gracias de nuevo por el aporte Miguel vamos a tener que crear otro artículo con errores en la implantación de SCRUM para que todo el mundo los pueda tener presentes al realizar la suya propia.
Excelente artículo
Me parece un poco negativo el tono del artículo... y yo veo que se habla más bien de "riesgos" del Scrum en lugar de "fallos".
Scrum es una herramienta muy potente pero que requiere mucho esfuerzo y capacidad de los equipos y la organización que lo aplican.
Si los equipos o la organización no llegan al nivel mínimo, Scrum se puede convertir en un problema en lugar de una ventaja de cara a lo que es sacar un proyecto adelante... aunque incluso en ese caso servirá como herramienta de diagnosis que permitirá sacar a la luz la carencias de los equipos y de la organización.
Todo depende de lo fuerte que se quiera apostar...
Realmente Sergio lo de "debilidades" de Scrum está dicho con ironía es más bien problemas de las empresas que no saben adaptarse a lo que significa SCRUM.
SCRUM exige un cambio en muchos aspectos y muchas empresas lo toman como la última panacea técnica y de ahí el error o uno de ellos.
Interesante artículo, espero aún estén respondiendo consultas. Y que pasa en aquellas empresas donde se requiere saber el presupuesto de un proyecto a fin de aprobar su ejecución. ¿Cómo responde SCRUM en ese escenario? ¿Con qué nivel de certeza? Ojo que algunas organizaciones requieren tener el número cerrado para presentar los proyectos a evaluación del directorio y socios.
Todo depende del tipo de requisitos que necesite el proyecto Marco.
Si tienes claro que se va a hacer, que requisitos exactos vas a hacer no tiene mucho sentido utilizar Scrum, cualquier método predictivo te valdría y además contarías con una estimación bastante precisa desde el principio.
Scrum entra en acción cuando sabes qué quieres (el objetiv) pero no sabes cómo lo quieres (debes descubrirlo iteración tras iteración). En este escenario el presupuesto va más orientado a cerrar un número de horas que se dedicaran a ese descubrimiento y a los requisitos que se puedan implementar durante ese tiempo pero no cuales serán los requisitos concretos.
Es un cambio de pensamiento y de cultura.
Espero haberte aclarado la cuestión.