Gran parte de la historia inicial del Scrum se escribió en el Blog Scrum de Jeff Sutherland hace casi 20 años. Todavía puede consultarse en jeffsutherland.org/scrum pero hay que llevarlo a scruminc.com para que no se pierda la historia.
Hoy en día, muchos profesionales no comprenden los orígenes de Agile, que comenzaron con los patrones organizativos y Scrum. Los patrones y el trabajo de Scrum se compartieron con Kent Beck para poner en marcha eXtreme Programming y en la reunión del Manifiesto Ágil participaron los fundadores de XP y Scrum junto con un grupo de consultores y líderes de opinión. No había otros marcos ampliamente desplegados en ese momento, con la posible excepción de DSDM en Europa, que hoy en día ha sido sustituido en gran medida por Scrum.
Esta entrada de blog de 2003 fue citada por Jim Coplien en su presentación de 2008 sobre la historia de Scrum como patrones organizativosque también merece la pena leer.
Blog Scrum de Jeff Sutherland: 11 de marzo de 2003
He aquí algunos comentarios sobre los requisitos necesarios para un Scrum motivados por los mensajes publicados en la lista scrumdevelopment@yahoogroups.com. Aquí hablo de empresas de productos. Existen paralelismos para el desarrollo interno de SI.
Los Scrum con los que trabajo se ocupan de los cambios en los requisitos durante la iteración del sprint. El jefe de producto (como Product Owner) forma parte del Scrum por este motivo. El Scrum de desarrollo no define los requisitos iniciales a menos que sea un Scrum de marketing de producto.
Siempre empezamos un desarrollo Scrum con algo de código en funcionamiento. Así pues, un Scrum se diseña para mejorar un código base. La especificación funcional proporcionada por marketing debe basarse en prototipos en funcionamiento mostrados a clientes o clientes potenciales que estén de acuerdo en que eso es lo que quieren para la próxima versión. Puede ser un sprint o varios para llegar al lanzamiento.
Mis clientes actuales son médicos y no tienen tiempo para reunirse en los Scrum diarios, así que los médicos que comercializan productos tienen que ser sus sustitutos. Los médicos me han enseñado que un producto NO SE UTILIZARÁ, a menos que se adapte cuidadosamente a su flujo de trabajo, sea extremadamente receptivo y pueda personalizarse rápidamente siempre que tenga deficiencias. Dado que el fracaso es inmediato porque el médico se niega a utilizar el producto, éste debe ser casi perfecto a la primera y solucionarse en el plazo de un mes, o fracasarás y tendrás que buscar otro cliente.
Esta férrea disciplina exigida por el entorno médico me ha hecho darme cuenta de que todos los proyectos deben llevarse a cabo con esta disciplina. Si no es así, el fracaso puede llevar más tiempo, pero al final el sistema no se vende bien ni se utiliza bien. Así que creo que mis comentarios son pertinentes en otros entornos. No ganarás a lo grande si no haces esto.
Además, si el marketing del producto no tiene claras las necesidades del cliente (o del mercado), tampoco las tendrá la alta dirección. Si la alta dirección no respalda un producto, las prioridades se confundirán. Esto restará atención y recursos al Scrum y reducirá la probabilidad de éxito.
Si el marketing de producto no puede funcionar, tiene que hacerlo desarrollo. No lo harán tan bien y no deben tratarlo como cortar código. Deben salir de la oficina, hacer estudios de mercado y entrar en las oficinas de los clientes o llevarles a ellos. Deben prestar apoyo a las ventas y estar allí cuando el cliente compra o no compra y entender por qué sí o por qué no. Deben abandonar su trabajo de desarrollo el tiempo suficiente para definir los casos de uso, conseguir una interfaz de usuario que guste a los clientes y aclarar el flujo de trabajo y la lógica empresarial del cliente. Una vez hecho esto, pueden pensar en codificar el producto.
En un proyecto nuevo sin código existente, he visto a un Scrum de desarrollo trabajar en un prototipo durante una semana y definirlo como su código base.
La tarea consiste entonces en perfeccionar la base de código para satisfacer mejor las necesidades del cliente. Si eso no está claro, los programadores no deberían escribir ni una línea de código. Cada línea de código cuesta dinero escribirla y más dinero mantenerla. Es mejor que los programadores naveguen que escribir código que no se va a necesitar. Si escriben código que al final no se utiliza, la empresa pagará por ese código durante toda la vida del sistema, que suele ser más larga que la vida profesional del desarrollador. Si los desarrolladores se dedicaran a navegar en lugar de escribir código inútil, se divertirían, y la empresa tendría un sistema menos caro y menos quebraderos de cabeza que mantener.
Cuando la necesidad del cliente está clara, se escriben las líneas de código mínimas para satisfacer la necesidad definida. Esta es la forma de trabajar de XP (que era la práctica del equipo original de Scrum) y debería ser la forma de trabajar de Scrum.
Dicho esto, el marketing de productos debe gestionarse como un Scrum de Product Owners (ahora llamado Metascrum). Una vez dirigí un equipo de alta dirección (CEO, EVP, SVPs y directores de marketing de producto) como un Scrum de marketing de producto. Con una comida a la semana, en seis meses hicieron más cambios e innovaciones de producto que en los cinco años anteriores. Este Scrum también ayudó a crear empresas de Internet de éxito como Lycos y Altavista, empresa líder en búsquedas antes de que existiera Google.
Spanish 
English 
French