- Tags:: #📚Books , #✒️SummarizedBooks , [[Scrum]], [[My engineering management principles, values, and practices]] - Author:: [[Jeff Sutherland]], [[J. J. Sutherland]] - Liked:: #2/5 - Link:: [Scrum de Sutherland, Jeff / Sutherland, J. J. 978-84-08-24662-6](https://www.todostuslibros.com/libros/scrum_978-84-08-24662-6) - Source date:: [[2014-08-24]] - Read date:: [[2022-08-06]] - Cover:: ![[cover_scrum.png|100]] ## Why did I want to read it? Lo que encontré "by chance" en una librería y, a pesar de certificarme hace siglos como Scrum Master y Scrum Developer (que en qué estaría yo pensando también), quería ver qué decía "el original". ## What did I get out of it? >Desde el primer día me pareció un misterio por qué la gente insiste en trabajar de formas que sabemos que son ineficaces y un desperdicio de dinero, además de deshumanizadoras y deprimentes (p. 47) En general nada sorprendente respecto de lo que ya conocía (pero hay que leer las fuentes originales siempre, porque los conceptos se van desvirtuando y te llevas sorpresones). ### Intro to Scrum **La esencia:** >Básicamente, el Scrum se basa en una idea sencilla: cada vez que iniciamos un proyecto, ¿por qué no comprobamos cómo va cada cierto tiempo, vemos si lo que estamos haciendo apunta en la buena dirección y si es lo que la gente realmente quiere? ¿Y por qué no comprobar si existen maneras de mejorar lo que estamos haciendo (...) Esto es lo que se denomina un **ciclo de «inspección y adaptación»** (p. 24). Me gusta especialmente que haya un momento periódico y diferenciado para la inspección y adaptación. No he conseguido entender todavía que propone [[Kanban]] (e.g., si lo que propone es inspección y adaptación periódica). Me gusta esta simplicidad y que a pesar de ello haya gente que piense que CUALQUIER proceso está de más (su alternativa suele ser el caos) [[Process allergy]]. Fíjate lo que dice aquí el amigo: >En un mundo teóricamente perfecto, no habría procesos (...). **Los «procesos» que la gente utiliza son un derroche y ahí se incluye el Scrum.** Pero no vivimos en un mundo perfecto, y los malos procesos están tan enraizados en nuestro pensamiento que, como alternativa, necesitamos el proceso más liviano posible con el mayor impacto en nuestro trabajo (...). Mi intención ha sido que el proceso en sí constituya un marco lo menos perturbador posible y no obstante mantenga a la gente centrada. **Lo que realmente queremos en nuestro trabajo es un «fluir» sin esfuerzo** (p. 140) ^dc5626 Y el término viene de esto del rugby. Ya sabéis, los señores cis-hetero que se dedican al management no saben salir de las analogías del deporte y la guerra ([[✍️ Sin machirulos hay paraiso. Una charla heterofriendly sobre management]]): ![[Pasted image 20220815082454.png]] Scrum bebe del [[Toyota Production System]]... que a su vez viene de los americanos-os-saludamos-con-alegría! >Dado que el Scrum procede de técnicas utilizadas en la fabricación japonesa, no está de más saber dónde las aprendieron **los japoneses. Irónicamente, muchas las aprendieron de un estadounidense: [[W. Edwards Deming]]**. Deming trabajó para el general Douglas MacArthur durante la ocupación americana de Japón tras la segunda guerra mundial. El enfoque de MacArthur respecto a la reconstrucción de la economía consistía en despedir a la mayoría de los altos directivos de las empress japoneses, ascender a los jefes de línea y traerse a expertos en operaciones empresariales, como Deming, de Estados Unidos. La influencia de Deming en la fabricación japonesa fue espectacular. Formó a cientos de ingenieros en lo que se denomina «**control estadístico de procesos**». (p. 54) ### Big in Japan Inspiración de las artes marciales, el Shu Ha Ri (p. 58) - Shu: conoces las reglas y las repites como un paso de baile - Ha: como dominas las reglas, te puedes permitir meter alguna innovación - Ri: puedes pasar de las reglas y ser creativo porque has interiorizado los principios. Vamos, que **para saltarte las reglas, primero las tienes que dominar.** Esto, normalmente, la gente se lo pasa por el forro ([[✍️ Refusing to stand on the shoulders of giants]]). Por otro lado, destaca el contraste aquí con [[📖 Extreme Programming Explained]], diciéndote que o aplicas todo o no estás verdaderamente haciendo XP: >...en el Scrum existen algunas normas, y lo bueno sería aprenderlas y trascenderlas (p. 277). Los desperdicios de [[Taiichi Ohno]] de [[Toyota Production System]] (p. 116):  ^213fec - Muri: desperdicio de la irracionalidad. - Mura: de la incoherencia. - Muda: de los resultados >Estas ideas se corresponden en gran medida con el ciclo de Deming (...) **Planificar, Hacer, Comprobar Actuar.** Planificar evita el Muri. Hacer evita el Mura. Comprobar evita el Muda. Actuar implica la voluntad, la motivación y la determinación de hacer todo eso (p. 116) Aquí además el autor añade el desperdicio emocional, el que causan los gilipollas (un tipo distinto de gilipollas que el de [[📖 Build. An Unorthodox Guide to Making Things Worth Making#Chapter 2 3 Assholes]]): >...cuando una empresa tiene un **gilipollas al que le gusta marear y poner nerviosa a la gente.** Estos gilipollas a menudo justifican su conducta afirmando que ellos simplemente procuran que la gente trabaje mejor. Pero lo único que hacen es tratar de manera autoindulgente los aspectos negativos de su personalidad, y nada es más perjudicial para la capacidad de despuntar de un equipo. **No sea un gilipollas** y no permita, favorezca ni acepte esa conducta en otros (p. 140). ### El equipo: generalistas, transparencia y conexión >Cambie el rendimiento del equipo. Esto tiene mucho más. impacto -en varios órdenes de magnitud- que el rendifmiento individual (p. 95) >Puedo duplicar la productividad de un equipo en un mes, pero ¿la de un individuo? Eso podría llevar un año (p. 196). ¿Cómo? Pues, que fluya la comunicación. [[Jim Coplien]], en los Bell Labs de AT&T estudió a través de múltiples proyectos software el impacto de la comunicación en el delivery del equipo: >Lo que hizo fue mapear todos los flujos de comunicación dentro del equipo: quién hablaba con quién, dónde estaba fluyendo la información y dónde no. Este tipo de mapa es una herramienta clásica que puede utilizarse tanto para detectar embotellamientos com acaparadores de información. **Cuanto mayor es la saturación de comunicación -cuantas más personas saben más cosas-más rápido es el equipo** (p. 105). Y ojo, para [[Data team roles]], [[Generalist vs specialist]]: > El mayor impedimento para la saturación de comunicación es la especialización (p. 105). También otra más para [[The thinker - doer model]]: > Atomizar a la gente en compartimentos estancos solo sirve para que todos vayan más desplacio. Aparte de eso, alimenta la sospecha y la desconfianza. **No hace más que dividir una empresa entre los jefazos que lo saben todo y los peones que se limitan a ejecutar partes de un plan misterioso que ellos no son capaces de comprender.** Sandeces. Si no puedes confiar en la gente a la que has contratado para embarcarse en lo que estás haciendo, estás contratando a la gente equivocada y has establecido un sistema defectuoso de por sí (p. 196). Citando el mítico [[📖 Delivering happinness: ¿cómo hacer felices a tus empleados y duplicar tus beneficios?]] de [[Zappos]]: >Su investigación muestra que cuanto más conectadas están las personas con otras personas en el trabajo, más felices son y, aparentemente, también más productivas e innovadoras (p. 199). ### Ojo a la complacencia >Debido a que en este punto es donde las formas del Scrum pueden derrumbarse, las «burbujas de felicidad» son una de mis principales preocupaciones (p. 206). [[No nos decimos lo suficiente lo buenos que somos]]: >Cuando yo era piloto de combate solíamos decir que después de 3.000 horas en la cabina tienes que dejarlo, porque te vuelves complaciente y so puede representarte la muerte. Si bien un equipo complaciente puede que resulte menos arriesgado para la empresa, **pone en riesgo el rendimiento continuo del equipo.** Esta actitud complaciente a menudo se pone de relieve en comentarios como el siguiente: «Nos merecemos darnos un descanso; nos lo hemos ganado». **O los miembros individuales de un equipo valoran su espíritu de equipo y su felicidad tan alto que no quieren ponerla en peligro. O temen el cambio en sí, en el pensamiento de que si lo que hacen está funcionando, ¿por qué cambiarlo?** (p. 206). De aquí viene una de las ventajas de ir midiendo la velocidad del equipo. Además, necesitas un Sabio-Loco: >El Sabio-Loco es la persona que formula preguntas incómodas o saca a la luz verdades igualmente incómodas. no siempre es fácil contar con estos trabajadores, dado que pueden ser considerados conflictivos o ajenos al equipo, pero es necesario cultivarlos y utilizarlos (p. 208) ### Multitasking no y feedback loops más rápido Basado en [Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking | PLOS ONE](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0054402): >Parece que las personas con mayor tendencia a la multitarea y más proclives a usar el teléfono móvil mientras conducen son las que tienen una visión más sobrevalorada de sus capacidades. El principal autor del studio, David Sanbonmatsu, decia en el blog de la NPR, Shots, en enero de 2013: «Las personas no abordan varias tareas a la vez porque sean buenas en eso. Lo hacen porque son más distraídas. Les resulta dificil inhibir el impulso de hacer otra actividad». En otras palabras, las personas que practican la multitarea son las que no pueden concentrarse. No lo pueden evitar. (p. 118) [[Gerald Weinberg]] en [[Quality Software Management]]: ![[Pasted image 20220813155544.png]] Lo suyo es: ![[Pasted image 20220813155642.png]](p. 122) >Si algo está a medio hacer al final del sprint, estaremos peor que si aún no hubiéramos empezado a hacerlo (...) Habría sido mejor crear algo más pequeño, algo que realmente funcionara (p. 126). >Cualquier equipo debería saber exactamente cuánto trabajo es capaz de dejar hecho en cada sprint (p. 184). John Boyd, el "Mad Major" fue un piloto de combate que luego le dio por estudiar ingeniería y descubrió que: > El que es capaz de manejar la tasa de cambio más rápido es el que sobrevive (p. 230). Y eso lo haces entrando más veces en el bucle OODA del enemigo: Observar, Orientarse, Decidir y Actuar. ### Como decía un ex-CTO mío: "a un equipo lo que le pone contento es tener éxitos compartidos", y viceversa. Basándose en [The benefits of frequent positive affect: does happiness lead to success? - PubMed](https://pubmed.ncbi.nlm.nih.gov/16351326/), que nos concentremos en hacer el equipo feliz. La felicidad es causa del éxito. Éste tiene que ser el tema en una "Retro", siempre pensando en pequeños pasos continuos ([[kaizen]]): >Funciona así: al final de cada sprint cada persona del equipo responde a una reducida serie de preguntas: >1. En una escala del 1 al 5, ¿qué piensa de su papel en la empresa? >2. En la misma escala, ¿qué piensa de la empresa en general? >3. ¿Por qué piensa así? >4. **¿Qué podria hacerle más feliz para el próximo sprint?** > >(...) > Éste es el punto crucial. El equipo escoge una mejora y la convierte en la cosa más importante que hay que hacer en el próximo sprint, con unos test de aceptación (p. 192). ### Producto ![[Pasted image 20220814174355.png]] > El Responsable de Producto se encarga de traducir la productividad del equipo en valor (p. 224). Pero esto es como too much, no? Es otra vez [[The thinker - doer model]]: > Sin acceso a él, el equipo no sabrá qué hacer o en qué orden hacerlo (p. 225). Una buena historia de usuario, por [[Bill Wake]], es INVEST (p. 176): - Independent. - Negotiable: "hasta que esté realizada del todo, debe poder reescribirse". - Valuable. - Estimable. - Small. - Testable. ### Curiosidades Politiqueo a tope. Lo peor. >A raíz del ataque, la Comisión del 11 de Septiembre procedió a un análisis detallado para descubrir qué había fallado. Los analistas, afirmó la Comisión, no podían acceder a la propia información que se suponía debían analizar. "La mala calidad de los sistemas de información del FBI –dice el informe– hacía que el acceso dependiera en gran parte de las relaciones personales de cada analista con los individuos de las unidades o brigadas operativas en las que se encontraba la información". (p. 15) Recuerdos de [[Brené Brown]] en [[📖 Daring Greatly]]: >El reconocimiento pertenece al hombre que está en la arena, con el rostro desfigurado por el polvo. (p. 33) En cuanto a "trabajar demasiado duro hace que se trabaje más" (p. 132), es un poco decepcionante que aquí no hay referencia a estudio que lo mantenga. Solo la experiencia de [[Scott Maxwell]], fundador de capital riesgo OpenView Venture Partners, sobre los equipos que habían implementado Scrum. Y de hecho, hay un poquito de pseudo-ciencia, con una gráfica por ahí, "Casa Inventadellas": ![[Pasted image 20220815085300.png|400]] Detrás de esta gráfica no hay dato real. Se la dibuja Scott a Jefff en una pizarra... Pero aquí aparece representada así, sin pinta de que sea una aproximación a ojímetro y es un poco [[📖 Bullshit. Contra la charlatanería]].