Explorando los horizontes de Scrum: Ampliar las posibilidades de las industrias reguladas
El extraordinario viaje del comandante Jon Haase aparece en El cuaderno de campo Scrum
En Scrum Inc., los límites de Scrum y los principios ágiles se extienden mucho más allá de las TI y el desarrollo de software. En este extracto de "El libro de campo Scrum: Mayor rendimiento, mejores resultados. A partir de ahora.El autor, JJ Sutherland, en colaboración con el Dr. Jeff Sutherland, cocreador de Scrum, aborda el escepticismo que suele surgir al considerar la adopción de Scrum y Agile en entornos complejos y regulados, como los sectores gubernamental y militar.
Lo hemos oído una y otra vez. "Aquí no puede funcionar" viene de muchos sectores estructurados y jerárquicos. Sin embargo, a través de la experiencia del comandante de la Marina estadounidense Jon Haase, descubriremos a continuación cómo Scrum desafía estas suposiciones y demuestra su eficacia y efectividad incluso en los entornos más exigentes y de mayor riesgo.
"Aquí no puede funcionar" - Un extracto de El cuaderno de campo Scrum
El siguiente extracto pertenece a The Scrum Fieldbook: Rendimiento más rápido, mejores resultados. Starting Now. por JJ Sutherland, Director General de Scrum Inc.
Hay un estribillo común que oigo de los escépticos del Scrum: no puede funcionar aquí. Lo que hacemos es demasiado complejo. Demasiado impredecible. Demasiado difícil para un sistema que da autonomía a los equipos. Por alguna razón que no alcanzo a comprender, creen que la gestión de proyectos tradicional puede gestionar su proyecto especial, pero lo creen fervientemente. O dicen que puede estar bien para el software, pero en su dominio supercomplejo que es mucho más difícil que el software simplemente no se puede aplicar.
Doy clases abiertas al público con bastante frecuencia. Y lo increíble es la enorme variedad de personas que acuden. Hay desde banqueros, fabricantes, editores y fabricantes de productos biofarmacéuticos hasta investigadores, proveedores de servicios, educadores y trabajadores sin ánimo de lucro. Los estudiantes casi siempre representan una asombrosa diversidad de sectores, conocimientos y funciones.
Pero si usted es uno de esos escépticos, quiero compartir con usted la experiencia de una persona que ha implementado Scrum en un dominio que muy probablemente tiene más en juego, se mueve más rápido, y con mucho menos margen de error que lo que usted está tratando de lograr. Probablemente.
El comandante de la Marina estadounidense Jon Haase me llamó hace un par de años. Hacía poco que había asumido el mando de la unidad EODMU2 (Explosive Ordnance Disposal Mobile Unit 2). Quería implantar el Scrum en su unidad y me llamó para pedirme consejo. Quería ir más rápido, con mayor calidad en uno de los entornos más exigentes del planeta.
Explosive Ordnance Disposal son los más pequeños de las Fuerzas Especiales de EE.UU.. Un par de miles de personas. Pero tienen que ser capaces de desplegarse con cualquiera de las otras unidades en cualquier lugar del planeta y en cualquier entorno. Se ocupan de las bombas. Se encargan de destruir, inutilizar, todo lo que pueda explotar. Desde minas y proyectiles hasta artefactos explosivos improvisados como el
bombas de carretera que se hicieron tristemente famosas en lugares como Irak. Funcionan en tierra y bajo el agua. E incluso pueden hacer seguras las armas más mortíferas del mundo, las cargadas con cargas nucleares, químicas o biológicas. También hacen otras cosas, pero sólo lo que está clasificado.
Y Jon decidió dirigir su mando, uno de los más exigentes del ejército, con Scrum. Dada la naturaleza de su trabajo, las entrevistas con alguien como Jon son poco frecuentes. Aun así, le envié una lista de 12 preguntas sobre el Scrum y su trabajo. Se mostró dispuesto a responder a nueve de ellas por correo electrónico. No quiero poner palabras en su boca, así que compartiré con vosotros el correo electrónico que recibí de él.
Su respuesta comienza con este descargo de responsabilidad: Las opiniones expresadas son las del autor y no representan necesariamente las opiniones del Mando de Combate Expedicionario de la Armada, el Departamento de la Armada, el Departamento de Defensa o el Gobierno de los Estados Unidos.
P - ¿Cuándo oyó hablar por primera vez de Scrum?
La primera vez que oí hablar del Scrum fue cuando me preparaba para mi gira de mando. Me puse en contacto con mentores y elaboré una lista de lecturas que abarcaba muchos temas, desde el liderazgo y la gestión hasta la comunicación y la inteligencia emocional. Fue a través de este proceso que encontré Scrum. Cuando lo vi, me comprometí a aprender más leyendo "Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo". Esto fue hace aproximadamente 2 años y comenzó mi viaje de aprendizaje sobre la Agilidad y el marco Scrum.
P - ¿En qué se inspiró para implantar Scrum en EOD?
En lugar de tomar decisiones, siempre que sea posible intentamos hacer experimentos. Estos experimentos tienen algunas condiciones necesarias para llevarse a cabo. La primera es que el coste debe ser bajo y el riesgo muy bajo. Estos experimentos también deben ser temporales por naturaleza y reversibles si el
experimento resulta infructuoso. Por último, debe haber alguna métrica que podamos controlar para ver si el experimento tuvo el resultado previsto.
La implantación del Scrum cumplía todos estos requisitos.
No costó dinero poner en marcha el experimento, la implantación del Scrum entrañaba poco riesgo, era temporal y podía revertirse fácilmente si no tenía éxito, y contaba con métricas como la velocidad para evaluar su eficacia. Al medir la productividad de una semana a otra, se puede hacer un seguimiento de la productividad semanal, lo que se conoce como velocidad del equipo.
P - ¿Cómo se estructuró? ¿Cómo se organizó?
Estructuramos nuestra implementación del Scrum para que fuera coherente con las funciones, actividades y artefactos del marco Scrum. El Scrum Master era el Oficial Ejecutivo, el Product Owner era el Oficial de Mando, y el Equipo Scrum era el resto de puestos clave del personal. La composición del grupo cambió con el tiempo a medida que íbamos perfeccionando nuestra comprensión de los productos y servicios que apoyaba cada miembro del mando.
P - ¿Cuál fue el impacto inmediato?
Team Velocity empezó con cuatro puntos al día y fue creciendo hasta alcanzar los 50 puntos diarios. El impacto inmediato fue la mejora de las comunicaciones, la priorización y la realización de tareas.
P - ¿Cuáles fueron los elementos que más impacto tuvieron? ¿Por qué?
Los elementos que más repercusión tuvieron fueron la definición de los objetivos y el orden del día de todas las actividades. Aunque muchas de las actividades reflejaban acciones habituales de la vida militar, carecían de la claridad de objetivos y agenda que obtuvieron con nuestra aplicación Scrum.
El timeboxing también se convirtió en una parte esencial de nuestra vida cotidiana.
La razón por la que el Timeboxing y la comprensión de los objetivos de cada evento se volvieron tan vitales para nosotros es que podíamos medir nuestra eficacia en función de unos objetivos comunes, entendidos y meditados.
objetivos cada vez que se reunía el equipo. Esto nos permitió estar más centrados y este enfoque nos permitió lograr un trabajo más significativo.
P - ¿Puede darnos un ejemplo de algo que haya podido hacer con Scrum y que antes no pudiera?
Como líder, estoy mucho más atento a los efectos que mis acciones tienen en el equipo. Al realizar Retrospectivas rigurosas, sé cómo repercuten mis acciones en la felicidad del equipo.
Por ejemplo, presioné al equipo durante un Sprint para lograr un objetivo específico que estaba fuera de línea con algunas de nuestras prioridades de cara a ese Sprint. En la retrospectiva, pedí al equipo su opinión y obtuve comentarios sinceros sobre cómo mis acciones habían provocado un fuerte descenso de la felicidad del equipo. Sin Scrum, el equipo nunca habría tenido un mecanismo para transmitirme esa información, y yo nunca habría conocido los resultados de mis acciones.
P - ¿Qué fue difícil? ¿Ha tenido que modificar algo?
Fue difícil convencer al equipo de que necesitábamos realizar todos los eventos en el Sprint. Aunque había una amplia aceptación de la Scrum diaria, la gente sentía que estábamos gastando mucho tiempo en reuniones haciendo Backlog Refinement y Retrospectivas, lo que no siempre era apreciado. Poco a poco, a medida que el equipo comenzó a comprender el impacto de cosas como tener un backlog limpio y listo o solicitar la felicidad del equipo y sugerencias de mejora continua en las Retrospectivas, el equipo ganó más aprobación y aceptación de estos eventos.
P - Repasa tu Sprint... ¿cómo y dónde hiciste cada prueba?
El Sprint comienza el lunes por la mañana, cuando nos reunimos con todos nuestros pelotones en nuestra reunión semanal de sincronización. Esto nos permite solicitar la opinión de todos los equipos que operan en el mando.
A partir de ahí, pasamos a la Planificación del Sprint, donde podemos tomar las aportaciones que acabamos de recibir e incorporarlas a nuestro plan del Sprint. Cuando el plan del Sprint está completo, pasamos al Diario Scrum y discutimos cómo comenzaremos nuestro trabajo. Todo esto se hace en nuestra sala de conferencias.
A continuación, celebramos el Scrum diario en la misma sala de conferencias utilizando nuestro tablón de equipo, que está a disposición de todos los miembros del mando. El miércoles por la tarde nos reunimos para llevar a cabo el Backlog Refinement delante de nuestro tablero de equipo. Este proceso consiste en debatir y priorizar el trabajo pendiente. El viernes tenemos una reunión con todos nuestros marineros para presentarles el trabajo que hemos realizado. Esta es nuestra Revisión del Sprint. El viernes por la tarde reuniremos al Equipo para nuestra Retrospectiva frente al tablero del equipo.
P - ¿Durará después de su marcha?
El futuro es imposible de saber, pero el trabajo de base está hecho, y la infraestructura existe para que Scrum sobreviva a mi mandato.
Ahora, piense en lo que acaba de leer. Elimine las menciones ocasionales al rango y a los marineros y céntrese en los puntos clave. Esto no es un ejemplo militar, es un ejemplo de Scrum trabajando en un entorno complejo, difícil e impredecible.
El comandante Haase y su equipo siempre estuvieron altamente cualificados y motivados. Como Fuerzas Especiales son lo mejor de lo mejor casi por defecto. Sin embargo, tras implantar Scrum, Haase y su equipo vieron cómo la productividad mejoraba de cuatro a 50 puntos al día en 18 meses. Eso supone un aumento del 1250%.
Y aunque el trabajo que realizan puede ser de alta tecnología, esta no es la historia de una startup de software, ni siquiera de un equipo que está creando un producto. En cierto modo, se trata de una empresa de servicios altamente especializada, peligrosa y letal. Desde que trabajo con Jon, por mis clases ha pasado un flujo constante de gente de la Navy Special Warfare. Y estas son personas que,
Por encima de todo, centrarse en los resultados. Hay tolerancia cero para todo lo que no les haga más rápidos y eficaces.
Como antiguo periodista, sé que el escepticismo puede ser saludable. Pero debe equilibrarse con la aceptación de pruebas. Si no, el escepticismo puede ser contraproducente, incluso destructivo. Sobre todo cuando el escepticismo no es más que un disfraz del simple miedo al cambio.
Desafiar las probabilidades en las industrias reguladas
La historia del Comandante Haase es un testimonio de la adaptabilidad y eficacia del Scrum y las metodologías ágiles en sectores regulados. No se trata sólo del desarrollo de software o de startups; se trata de transformar fundamentalmente la forma de trabajar de los equipos, incluso en los entornos más complejos y exigentes. Los resultados son innegables: un aumento del 1250% de la productividad en 18 meses. Cuando el escepticismo se enfrenta a la realidad de un cambio positivo, se nos recuerda que cuestionar es saludable, pero adoptar una transformación basada en pruebas puede conducir a un éxito sin precedentes. Así pues, dejemos que este relato de la Scrum en acción en el más difícil de los entornos nos inspire a creer en su potencial, incluso frente a los escépticos del "aquí no puede funcionar".
Spanish 
English 
French