Book review (2/2): Extreme Programming Explained (Second Edition) de Kent Beck y Cynthia Andres
🎵 Vamos, Kent, sal a bailar, que tú lo haces fenomenal...
Segunda parte y final del resumen del “Extreme Programming Explained”. Un poco más y acabo copiando y pegando el libro entero. El menú del día es:
Kent Beck 🤜🤛 Frederick Taylor.
¿Hay un problema de incentivos en XP?
El mercado global del trabajador de software.
Despedida y cierre.
Kent Beck 🤜🤛 Frederick Taylor
Uno de los side (¿no tan side en realidad?) topics que trata Kent Beck hacia el final del libro es cómo la herencia que traemos de la "organización científica" del trabajo del Taylorismo, es la responsable de mucha malfunción al construir software. Hacer software no es un proceso industrial, el Taylorismo parte de unas premisas que no aplican aquí.
Las cosas salen de acuerdo con el plan
Aquí, todo el capítulo 8, "Estimation" del Rapid Development es espectacular:
The basic software-estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clear focus. Because the picture of the software you're trying to build is fuzzy, the estimate of the time and effort need to build it is fuzzy too. (p. 165)
La micro-optimización lleva a macro-optimización
En software, micro-optimizar no suele ser suficiente: mantener una visión de sistema, holística, nos puede desbloquear mejoras mucho más dramáticas. Por no hablar de que hacer cambios a nivel de sistema es mucho menos traumático que en un proceso físico (de esto ya hablamos en el post anterior).
La gente es intercambiable y necesitan decirles qué hacer.
No hay mucho que comentar en esto, ¿no?
Una estructura social que… no pega.
Separa planificación de ejecución
Crea un departamento de calidad separado.
No one wants to think of himself as a cog. (p. 136)
Taylor assumed that workers would 'soldier' whenever possible (…) Sends the message that engineering and quality are separate, parallel activities. (p. 132)
La alternativa a esto (especialmente a esta estratificación social) e inspiración de XP, es esa referencia que seguro que has leído por múltiples otras vías, que es el Toyota Production System, donde, entre otras cosas, todo el mundo es responsable de la calidad.
¿Hay un problema de incentivos en XP?
Cuando uno oye frases del tipo "todo el mundo es responsable de la calidad", asiente con la cabeza. Pues sí, ¿quién va a decir que no? Pero pasa un poco lo que se comenta en un artículo que cito muchísimas veces, “How to read self-help”:
But this is a hallmark of wisdom: it’s trivial to read but nearly impossible to put into practice (…) we need lots of examples to drive this wisdom home. We should be more forgiving of self-help (the genre) and more forgiving of ourselves. Putting wisdom into practice takes requires reading, reflection, and practice."
Es decir, ¿cómo se gestiona esto en la práctica? ¿Cuál es el incentivo para que se honre este ideal? Este es el punto que me parece más crítico de XP: una de las cosas más importantes a tener en cuenta para que tengamos o no éxito con él. Me surgen muchas preguntas:
¿Para tener éxito con XP es condición necesaria y suficiente que inherentemente la gente que forma parte de tu empresa tenga una motivación intrínseca por hacer un buen trabajo, y por entender que es un esfuerzo colectivo?
El objetivo es de equipo, pero, si todos somos responsables, ¿cómo evaluamos el rendimiento de un trabajador?
¿Cómo somos responsables todos de la calidad y, al mismo tiempo, lo hacemos de una forma eficiente (esto es, no estamos todos a absolutamente todo)?
…
El propio capítulo sobre el Toyota Production System que incluye este libro nos resuelve un poco la primera cuestión (quizá también la tercera). Tenemos que cambiar de un modelo "push" de trabajo (que haya mucho trabajo work in progress, es decir, muchas "partes" entre cada paso de la cadena de montaje de manera que cada paso de la cadena pueda trabajar independientemente y no tenga que esperar nunca al paso anterior), a un modelo "pull":
Workers are accountable for the quality of their work because the parts they create are immediately put to use by the next step in the line. (p. 136)
If you use a part immediately, you get the value of the part itself as well as information about whether the upstream machine is working correctly (…) leads to pressure to keep all the machines in a line working smoothly and also provides the information necessary to keep the machines working smoothly. (p. 136)
Que vamos a tener problemas con la evaluación de los miembros de un equipo XP también lo prevé Kent Beck. Él mismo nos dice:
…most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help other if he will be evaluated on individual performance? (p. 82)
Esto, por tanto, puede guiar malamente las decisiones de los developers, como por ejemplo a la hora de decidir si invertir tiempo en mejorar el diseño del software (que es crucial pero no visible) vs. añadir una feature más (que es algo mucho más vistoso). Incluso puede haber impacto en el throughput de toda la organización:
The Theory of Constraints shares with other theories of organizational change the assumption that the whole organization is focused on overall throughput, not on micro-optimization. If everyone is trying to make sure his function is not seen as the constraint, no change will happen (…). The reward system and culture need to align with overall throughput instead of individual productivity for the change to stick. (p. 99)
Sometimes XP can facilitate shifting the constraint out of software development completely (…) The programmers may learn to go fast enough that product marketing can't specify features fast enough. (p. 89)
Beck nos anticipa dos posibles soluciones a este problema de evaluación: evaluación por equipo o evaluación individual pero con distinto criterio al típico.
Evaluación por equipo
The need for altruistic behavior, however, moves some teams to give raises to the team as a whole instead of to individuals. (p. 82)
Este modelo es el que me resulta más coherente, con diferencia, con la naturaleza de XP (equipo, auto-organización...), pero no termina de solucionar qué ocurre cuando hay miembros del equipo que no encajan. ¿Entiendo que la autonomía de los equipos permitiría que éstos mismos tomaran cartas en el asunto (p. ej., sugiriendo planes de rendimiento, transferencia a otros equipos...)? ¿Cómo nos aseguramos de que los equipos no se conviertan, por otro lado, en ghettos? Y aún así, ¿cómo evitas la competición entre equipos? ¿Se trata de dar un paso aún mayor, de más alto nivel, y asegurarte que tienes una cultura de empresa en la que todo el mundo entendería que la competición individual no tiene lugar? ¿Volvemos a dejar las cosas un poco en manos de la motivación intrínseca del trabajador?
Mientras escribía este post (it’s been 84 years…), aparecía esta noticia un poco controvertida, sobre como Typeform introdujo un sistema monetario interno para agradecer a tus compañeros su colaboración. Meanwhile, at Mercadona Tech:
Evaluación individual, pero ojito
La alternativa es seguir con las evaluaciones individuales hasta ahora, pero puesto que XP es transparente, un manager tiene mejor información para decidir. Eso sí, teniendo en cuenta que la vara de medir sea:
In XP, valuable employees: act respectful, play well with others, take initiative, deliver on their commitments (p. 82)
Entiendo que cómo alinear los valores de todas las personas en tu organización da para un libro aparte, pero me deja el tema mucho más abierto de lo que me gustaría, para lo crítico que creo que es. Con todo, al final siempre veo una reducción, un leitmotiv en software management que, por un lado es esperanzador (en tanto que es accionable y sencillo de entender), pero al mismo tiempo solo te deja un grado de libertad/acción: necesitas un recruiting exquisito (con la actitud del candidato) para encontrar a esa gente que entiende o puede llegar a interiorizar que:
Without a change of heart, all the practices and principles in the world will produce only small, short-term gains. You and the rest of the team [business, product...] share a fate. Act like it and you may come to believe it (…) We, in software, have the opportunity to create new social structures in which technical excellence is joined with business vision to create new products and services of unique value. (p. 154)
Tools and techniques change often, but they don't change a lot. People, however, change slowly but deeply. The challenge of XP is to encourage deep change, to renew individual values and mutual relationships to give software a seat at the table for the next fifty years." (p. 155)
Así lo contaba Fernando Díaz, el CTO de Mercadona Tech, el año pasado (su poquito de stalking cuando vas a entrar a trabajar en un sitio es importante):
El mercado global del software
En este capítulo Beck utiliza el offshoring un poco como excusa (un caso de estudio en el que sería complicado aplicar XP) para hacer una reflexión muy interesante, especialmente en el contexto que nos encontramos ahora.
Arrancamos fuertecito. Ojo a esto, que es 2005:
I don't like the political and racial overtones of the word 'offshore': high-paid white people taking advantage of low-paid dark people and then complaining about 'them' taking 'our' jobs (p. 149).
Para Kent Beck, la globalización en el contexto de la industria del software no es un juego de suma cero, y uno de los principios de XP, el de mutual benefit ("every activity should benefit all concerned") es perfectamente posible con el offshoring.
If the software industry learns to create more value at lower cost, the increase in demand will more than make up for the temporary loss of jobs in any one location. (p. 150)
Pero eso sí, todo el mundo tiene que ponerse las pilas. Todos tenemos algo que ofrecer, pero... hay que ofrecerlo:
In high-cost-base areas, improved efficiency, integrity and accountability are imperative for survival. The days of one hundred expensive contractors without accountability working on one project are numbered. The same project will be done with ten efficient and accountable programmers or it will go elsewhere (…). High-cost-base teams need to focus on high-leverage projects, where the strength of direct communication is most valuable".
To compete, low-cost-base teams need to increase the value they create too. Just because you can afford to throw lots of bodies at a problem doesn't mean that is the most profitable way to solve it.
Conclusión
Hay ciertos libros que uno sufre mucho para resumirlos, porque hay poca paja que recortar (Bauman, no se me ocurre resumir ningún libro tuyo más). Más que resúmenes, son retrabajos, re-organizaciones con el objetivo de asimilarlos mejor. Éste es claramente uno: no le sobra nada, y me explota la cabeza lo bueno que es Kent Beck anticipándose a las cuestiones que como lector vas a ir teniendo, y, especialmente, lo adelantado que iba Beck en algunas cuestiones (y lo que se moja).
En cuanto a XP, es la primera vez que estoy en una organización que lo usa (vs. procesos "Scrum-like"), con lo que solo tengo las impresiones que me causa lo que he leído. Recuerdo que cuando solo lo conocía superficialmente, o hacía prácticas esporádicas (algún pair programming tonto por ahí), me generaba bastante rechazo. Ahora que creo que lo entiendo mejor, mi sensación es que es un sistema muy coherente, que suena muy bien y que si se hace bien, tiene pinta de permitir niveles de rendimiento que serían difíciles de otra manera. PERO, sí que creo que es difícil hacerlo bien. Es decir, un equipo haciendo XP “a medio gas”, puede ser mucho más mediocre que un equipo sin XP. Es una apuesta valiente, pero que con un compromiso fuerte, tiene pinta de que marque muchísimo la diferencia.