Una de las grandes confusiones con Scrum es querer utilizarlo para hacer Proyectos. Esta confusión es crítica, porque la diferencia entre proyecto y producto es clave para entender cómo Scrum te ayuda a resolver problemas en entornos complejos. De esta confusión, nace el gran problema de Scrum en las empresas, el marco más utilizado y quizás peor entendido. Estudiamos cómo Scrum nos ayuda.
Las empresas se organizan por proyectos
Hace unas semanas, charlaba con el Director General de una startup que quería un cambio de rumbo en cultura y organización. Este Director General tenía una opinión interesante sobre las empresas que os quiero compartir. Según él, hemos creado empresas con departamentos (silos) cerrados donde cada área es responsable de una serie de trabajos. Los proyectos sirven para unir las diferentes áreas que, normalmente, no colaboran.
Si lo pensamos, los proyectos son lo único que une a personas de diferentes departamentos. Y esto se nota mucho en grandes empresas, donde los departamentos se diferencian de muchas maneras: objetivos diferentes, documentos diferentes, bonus diferentes, trato con cliente diferentes e incluso ubicación física.
El éxito de un proyecto
No tengo nada en contra de los proyectos. En entornos complicados, son útiles porque podemos prever todo aquello que vamos a construir, en qué orden, con qué personas y en qué tiempo. Tener claro todos esos datos resulta muy tentador y útil en negocios complicados. Sin embargo, cuando saltamos al mundo de lo complejo, empezamos a ver que algo falla.
En el mundo complejo, no podemos saber todo lo que va a ocurrir, por lo que casi todos nuestros planes se acaban “cayendo”, después de haber invertido mucho tiempo en ellos. Es más, podemos ser capaces de hacer un proyecto sin pasarnos de alcance, coste y tiempo y, aún así, fracasar por construir un producto incorrecto.
El gran problema de los proyectos es que ponen el foco en la entrega, no en el impacto de la misma. Según el Project Management Institute (PMI), la labor de un Jefe de Proyectos es asegurar que el plan ocurre y que no nos salimos de los parámetros previstos.
La certificación que valía para todo
El mundo de las certificaciones es bastante peculiar: hay una gran parte de negocio y venta de “papeles” a cualquier precio y, por otra parte, es una forma de generar conocimiento y aprendizaje. En su día, analizamos en este blog la utilidad de certificarnos en Scrum.
Varias organizaciones que han “inventando su propio Scrum” hablan de cómo gestionar proyectos utilizando este marco. Si encuentras un curso, formación, certificación o infografía que hable de “Gestión de Proyectos con Scrum”, es muy probable que esté transmitiendo información incorrecta. ¡Desecha esa fuente!
Scrum 2020: Producto, producto, producto
Comentaba Jerónimo Palacios en su newsletter, que la nueva Guía Scrum se orientaba muy claramente a producto. Un producto define su éxito por la entrega de valor. El concepto de valor es amplio, a veces es dinero directo, otras veces recorte de gastos o de tiempo, otras, en la satisfacción de los usuarios… Debe haber una métrica que el propio Scrum Team trate de mejorar en iteraciones inferiores a 30 días. ¡Bienvenidos a Scrum!
Un producto trata de resolver un problema, una necesidad, y no se centra tanto en la fecha, aunque tampoco es cuestión de obviar que existen. Por ejemplo, en el mundo de los seguros, es relevante el mes de mayo y junio, porque muchas personas se compran un coche en esos meses y los seguros tienen que ofrecer alternativas para captar clientes.
Cumplir una fecha no garantiza un éxito y cuando trabajamos en “modo producto” tenemos claro que es así. Por eso, es vital que identifiquemos muy bien a nuestros usuarios, la manera en la que gastaremos el dinero, qué métricas nos alertarán de que vamos mal y, por ello, tenemos que adaptarnos.
¿Por qué hacemos este producto?
Uno de los grandes cambios de la nueva Scrum Guide es el Product Goal, que trata de responder a una pregunta clave: ¿Por qué hacemos este producto? Esta pregunta, en empresas grandes, suele percibirse como dañina. En estas empresas, hay mucho dinero y se destina a diferentes iniciativas, por tanto, no hay que justificar el producto. Sin embargo, ¿cómo sabemos que construimos el producto adecuado?
El gran cambio de Scrum es ese, no se trata de llevar a cabo el plan maestro que definimos cada año con el presupuesto, se trata de entregar valor con el dinero que queremos invertir. Maximizar valor consiste en eso, aprovechar los recursos económicos disponibles para generar un producto que aporte.
Y tú, ¿haces proyectos con Scrum?
Excelente artículo, me gustó mucho la claridad y muy bien aterrizados los conceptos.La diferencia de PMI con Scrum, gracias Profesor Javier.
Gracias a ti 🙂
Gracias Javier por el artículo. Muy claro e ilustrativo
Gracias x compartir
Sumamente esclarecedor tu artículo, Javier. De hecho, a mi me representa algo así como “haber visto la luz”. Vengo del mundo de la gestión de proyectos y por mucho tiempo estaba usando Scurm para gestionar ágilmente proyectos pero siempre sentía algo, una vocecita, que me decía “como que hay algo que no encaja”. Pero ahora, a partir de tu artículo, he visto la luz. Gracias por tu esclarecedor artículo y manos a la obra para mi para hacer cambios en mis diferentes conceptos, materiales y cursos. Saludos a la distancia.vrv
Muchas gracias. El equipo de mamá te agradece el comentario 😊 el propósito del blog era despertar consciencia
Pues por mi parte, lo ha hecho. Y de una manera contundente.
Tengo mucho trabajo que hacer frente a este cambio de paradigma, pero contento (y tranquilo de hacerlo).
Saludos,
vrv
Como siempre cada tema es muy enriquecedor y aporta muchísimo porque está basado en su vasta experiencia muchas gracias por compartir sus conocimientos.
Me gustaría hacerle una consulta, Cuál es su recomendación si un equipo Scrum es asignado a desarrollar un «producto» que realmente es un proyecto debido a que es un tema regulatorio dónde los requerimientos y fecha de entrega ya están definiendo ?
Pues diría dos cosas: hacer Kanban (no garantiza que llegues pero al menos maximiza la cantidad de alcance en tiempo que tengas). Y el segundo consejo es rezar…
Muchas gracias por compartir conocimiento.
Actualmente, revisando el PMBOK séptima edición, se puede encontrar que usan el término de Sprint para el desarrollo de proyectos, y que tienen definido los Ciclos de Vida Predictivo o Tradicional , y Ciclo de Vida Ágil o Iterativo, lo cual definitivamente tu artículo me ayuda mucho, para entender que puedo tener proyectos que incluyen Productos como parte de su ejecución en los entregarles.
También se detalla los Proyectos de Ciclo de Vida Mixtos.
Muchas gracias por la excelente explicación.
Javier, gracias por el artículo, muy claro y lleno de aportes para la ejecución scrum!
No estoy haciendo nada, ni pienso hacer, porque no desarrollo productos (Software) gerencio proyectos de infraestructura. pero Javier te felicito por la claridad de conceptos, para aquellos colegas que piensan que los ciclos de vida tradicionales o en cascada ya no se usan, y a ahora es cuando, ya que la agilidad en estos proyectos no es acorde con la evangelización del PMI. es con BIM, Lean Construction, Last Planner Systems y IPD. Saludos y te sigo en la red. Saludos cordiales.
Bernardo García
Gracias 😊