Si quieres conocer realmente el corazón del marco de trabajo Scrum, debes leer el paper de Hirotaka Takeuchi and Ikujiro Nonaka que le dio origen a principios de los 80. Aunque, si no lo has leído, aquí te comparto mi resumen.
Control por misión (Built-in Instability): la alta dirección crea un elemento de tensión en el equipo al darle gran libertad para llevar a cabo un proyecto de importancia estratégica para la empresa y al mismo tiempo establecer requisitos muy desafiantes. Es decir: dar gran libertad y objetivos muy exigentes. Dar libertad con exigencia. Algo que los autores llamaron 'Built-in Instability' y que prefiero, por simplicidad, llamar "control por misión".
Equipos autoorganizados: es un equipo que exhibe tres condiciones: autonomía, autotrascendencia y fertilización cruzada. En el día a día, la alta dirección rara vez interviene; el equipo es libre de establecer su propia dirección. En cierto modo, la alta dirección actúa como capitalista de riesgo. O como dijo un ejecutivo: “Abrimos nuestro bolso pero mantenemos la boca cerrada”.
Fases de desarrollo superpuestas: es la integración de diferentes profesionales de una cadena de valor para lograr objetivos comunes, en vez del trabajo aislado y en secuencia. Aquí se introduce la idea del rugby, las fases se superponen considerablemente, lo que permite que el grupo absorba la vibración o “ruido” generado a lo largo del proceso de desarrollo trabajando como bloque unido. Un equipo trata de recorrer la distancia como una unidad, pasándose el balón de un lado a otro, en equipo.
Control sutil: se busca seleccionar a las personas adecuadas, crear un entorno de trabajo abierto, alentar a los ingenieros a salir al campo y escuchar lo que los clientes y stakeholders tienen que decir, establecer un sistema de evaluación y recompensa basado en el desempeño del equipo, manejar las diferencias de ritmo a lo largo del proceso de desarrollo y tolerar y anticipar los errores. La gerencia establece suficientes puntos de control para evitar que la inestabilidad, la ambigüedad y la tensión se conviertan en caos; y al mismo tiempo, la gerencia evita el tipo de control rígido que perjudica la creatividad y la espontaneidad fomentando el ‘autocontrol’.
Aprendizaje múltiple (Multilearning): hay que dedicar tiempo al aprendizaje individual constante, fomentando la iniciativa y el aprendizaje práctico por parte de los empleados y ayudando a mantenerlos al día con los últimos avances. Además incluye el aprendizaje en otras áreas de la experticia de cada profesional.
Aprendizaje Organizacional: los autores proponen la 'transferencia organizacional del aprendizaje' que incluye el impulso para acumular conocimiento a través de niveles y funciones distintas en el ecosistema de la organización; y el impulso por parte de los miembros del equipo para transferir su aprendizaje a otros fuera del grupo. El conocimiento también se transmite en la organización al convertir las actividades del proyecto en una práctica estándar. Es decir que se busca en estos dos últimos puntos el aprendizaje multi-nivel, multi-funcional y transversal en la organización, algo que podemos llamar aprendizaje organizacional.
Si buscamos seguir estas claves en el desarrollo de software o en nuestra organización, nos estaremos acercando a este Scrum pragmático. El framework, en el fondo termina implementando estas ideas, aunque fue años más tarde cuando fue creado por Ken Schwaber y Jeff Sutherland, quienes le dan forma y lo popularizan, basados en la idea de estos autores, en sus propias experiencias y en los numerosos experimentos del incipiente framework hechos por Jeff. Pero esa es otra historia.
Referencias:
https://hbr.org/1986/01/the-new-new-product-development-game (A version of this article appeared in the January 1986 issue of Harvard Business Review)
https://agileexperience.es/2021/01/31/origenes-de-scrum-the-new-new-product-development-game/
https://www.institutoagile.com/post/el-t%C3%A9rmino-scrum-aplicado-al-desarrollo-de-proyectos
No hay comentarios:
Publicar un comentario