Está en la página 1de 219

A Sandra, porque sin ella este libro no

hubiera sido posible, al menos, en un


tiempo razonable. Y aunque suene
bien, no es una frase hecha, de hecho,
sin su ayuda, habría tardado más
tiempo en terminarlo que lo que tardó
Bilbo en terminar el suyo.
Peopleware y Equipos Ágiles
Con prácticas de Management 3.0
Andrés Alarcón, Juan Salvador Aleixandre Talens, Olga Alonso Santamaría,
Juan Carlos Álvarez Martín, Javier Álvarez Moreno, Ana Aranda, Camilo
Araújo Figueiredo, Jesús Ávila, María Cruz Bacete Castellanos, Toni Bailón
Pérez, Patxi Ballesteros Fernández, Fernando Barrio
Bonilla, Francisco Javier Becerra Fernández, Ana
Belmonte, Carlos Benítez Monje, Pablo José Bermejo de
Miguel, Ludo Bermejo, Arturo Bermúdez Bonilla, Ryan
Berrio Cardona, Juan Jesús Blanco Bautista, Pedro Luis
Blanco del Campo, Ignacio Blanco Rodríguez, José Ramón
Bobes Bascarán, Manel Bonilla, José Brieba Sánchez, José
Luis Calatayud Machi, Antonio Calero, Pedro Antonio
Campos López, Jacinto Canales, Manuel Caño Gómez,
María Ángeles Carbonel, Bernat Carbonell, Eduardo
Cardells Fuertes, Fernando Cárdenas Fernández, José
Carrillo Izquierdo, Manuel Castro Paliza, Borja Chamorro
Marín, Mario Chamorro, Ángel Ciau, Oscar Ciudad
Ceprián, Roberto Clemente Arnanz, Andrés Córdoba
González, Iván Corps, Luis María Croce Mallagray, Abel Cuenca, Nuria
Cuervo Santamaría, Antonio de Ancos Cid, Santiago de Blas Hidalgo, Víctor
de la Rosa Guerrero, Cristina De León Martínez, José Ignacio de Uribe Ladrón
de Cegama, Joan Díaz Capell, Luis Miguel Díaz Díaz, Javier Díaz, Jesús
Escribano Llorente, Oscar J. Esteban, Javier Estellés, Esther Estévez Contreras,
Ricardo Estévez, Aldo Marcelo Fabián Dulce, Izem Fariña Roger, Eduardo
Fernández Oliver, Miguel Ángel Fernández Ruiz, Chema Fernández Varela,
Juan Manuel Ferrer Forteza, Eva Fonseca López, Marcos Gabarda Inat, Álvaro
Gala Martínez, Jesús Galindo Alfonso, José Luis Gamallo García, Pablo
García Bastante, Jorge García Calleja, Endika García Gayoso, Daniel García
Jones, Santiago García Nieto, Marcos García Pascual, Rodrigo García Peláez,
Santiago García Sánchez, Benjamín Garrido, Juan Carlos Gil Montoro, José
Manuel Gómez Villanueva, Juan Mauricio Goncalves Gouveia, Javier
González Criado, Ulises Javier González Díaz, Rodrigo Gracia Peña,
Francisco Griñán Moreno, Xisco Guaita, Fred Guerreiro, Gema Gutiérrez, John
Jairo Gutiérrez Narváez, Javier Gutiérrez Rodríguez, Carlos Gutiérrez
Saldaña, Carlos Hermida Hermida, Javier Hernández Aldea, Paloma
Hernando Morón, Eduardo Herranz Sánchez, Enric Hospital Juncà, Manel
Hurtado Fernández, José Manuel Iniesta Chamorro, José Jiménez Fernández-
Mazarambroz, Javier Jiménez, Joseba Jiménez Rivas, Fernando Jiménez
Rivera, Antonio Lalaguna, Joaquín Lasheras Velasco, Fernando Lázaro,
Diego Lema, César Liébana Carrasco, Ángel J. López Aceituno, Jesús López de
la Cruz, Tomás López Rodríguez, Javier Losa, Jesús Lozano Robles, Ángel
Luis Lozano Sánchez, Juan Malpica Romo, Marcos López Álvarez, Manuel
Marqués Reija, Diego Marrero Fernández, Alberto Martínez Ballesteros,
Gabriel Martínez Martínez, Juan Martínez Neira, José Enrique Mateo Seguí,
Armando Miranda Villasana, Sonia Montagud, Alfonso Monteagudo, Jair
Montealegre Zorro, Natalia Montoto Ballesteros, Miguel José Monzó Montes,
Iván Mora Pérez, Tomás Moreno Bernal, Fernando Mugarra, Pau Mugarra
Llopis, Jordi Mulet i Albiach, David Muñoz Ortega, Chema Navarro Gómez,
Gabriel Naveiro Elissondo, Pedro Olivares Sánchez, Valerio Oropeza García,
Nacho Ortega, Jorge Oteo García, Luis Otero Gil, Ana Palomo Cabrales,
Fernando Paz, Juan Carlos Peláez López, Raúl Peláez MrAddon, Julio César
Pérez Arques, Isidro M. Pérez Tohux, Manuel Pijierro Sa, Gonzalo Plaza,
Joaquín Precioso Sánchez, Maribel Puebla Contreras, Alberto Puig Rodríguez,
Iñigo Querejeta, Arsenio Quijano Larrosa, Javier Quirós, Alberto Rodríguez
Bernárdez, Purificación Rodríguez Blanco, José Rodríguez, Moisés
Rodríguez, Juan Manuel Rodríguez Pérez y Azahara Fernández Guizán,
Diego J. Romero López, Juan Miguel Romero Rodríguez, Francisco Jesús Rubio
Reales, Miguel Jesús Ruiz Santaella, Judit Sáez Martínez, Ángel San José
Lázaro, Leonardo José Sánchez Niño, Daniel Sánchez Rama, Javier Sánchez
Riquelme, Ignacio Santabárbara Ruiz, German Sanz, Álvaro Saugar, Jorge
Sobrado, Vicent Soria Durá, Manuel Suárez Prieto, José Antonio Suárez
Rodríguez, Emiliano Sutil García, Alberto Tablado Linares, Carlos Tirado
García, Alberto Toribio Sáez, Jorge Tutor, Ximena Valente, Albert Valiente
López, Luz Vallejo Quintela, Juan José Vallina Castro, Sergio Vasco
Hernández, Javier Villamonte Pereira, José Villaverde Carrera, Fiorella Elizabet
Yanac Monzen, Josep Yepes, Èric David Zapater Montorio
De la edición: 233gradosdeTI

MARCAS COMERCIALES: las marcas de los productos citados en el


contenido de este libro (sean o no marcas registradas) pertenecen a sus
respectivos propietarios. los datos y los ejemplos utilizados son ficticios salvo
que se indique lo contrario.

Se ha puesto el máximo empeño en ofrecer al lector una información completa


y precisa.

Sin embargo, 233gradosdeTI no asume ninguna responsabilidad derivada de


su uso, ni tampoco por cualquier violación de patentes ni otros derechos de
terceras partes que pudieran ocurrir. Esta publicación tiene como objeto
proporcionar unos conocimientos precisos y acreditados sobre el tema tratado.
Su venta no supone para el editor ninguna forma de asistencia legal,
administrativa ni de ningún otro tipo. En caso de precisarse asesoría legal u
otra forma de ayuda experta, deben buscarse los servicios de un profesional
competente.

Reservados todos los derechos de publicación en cualquier idioma. Según lo


dispuesto en el Código Penal vigente ninguna parte de este libro puede ser
reproducida, grabada en sistema de almacenamiento o transmitida en forma
alguna ni por cualquier procedimiento, ya sea electrónico, mecánico,
reprográfico, magnético o cualquier otro, sin autorización previa y por escrito
de 233gradosdeTI: su contenido está protegido por la Ley vigente que establece
penas de prisión y/o multas a quienes intencionadamente reprodujeren o
plagiaren, en todo o en parte, una obra literaria, artística o científica.

ISBN 978-84-697-7450-2

Versión: 1.0
Sobre el Autor, JAVIER GARZÁS PARRA
• javier.garzas@urjc.es
• twitter: @jgarzas
• web: www.javiergarzas.com, blog en el que
escribo desde hace más de 10 años
• LinkedIn: es.linkedin.com/in/jgarzas

Cursé estudios postdoctorales y fui investigador


invitado en la Universidad Carnegie Mellon
(Pittsburgh, EE. UU). Doctor (Ph.D.) (cum laude por
unanimidad) e Ingeniero en Informática (premio extraordinario).

He sido programador, jefe de proyectos, consultor, director de informática


(CIO), diseñador de muchos UMLs, etc., he pasado por casi todas las
dedicaciones del desarrollo software.

Pionero en España en agilidad, mi primer proyecto ágil en empresa fue en


2001.

Desde hace años, me dedico a ayudar a organizaciones, a que hagan mejor


software, productos del conocimiento o intelectuales (en tiempo, con
productividad, agilidad, calidad y felicidad).

Hasta la fecha, a lo largo de mi carrera profesional he trabajado para, o en, más


de 90 empresas (en España, Colombia, Chile, Venezuela y EEUU) entre las
que están algunas como: INDITEX, GMV – Control de Satélites, FERROVIAL,
WOLTERS KLUWER, REPSOL, TELEFÓNICA MÓVILES, BANCO
SANTANDER, INDRA, RENFE, DIRECCIÓN GENERAL DE TRÁFICO
(DGT), MINISTERIO DE ADMINISTRACIONES PÚBLICAS (MAP),
SISTEMAS TÉCNICOS DE LOTERÍAS (STL), AENOR, SIEMENS,
INFORMÁTICA DE LA COMUNIDAD DE MADRID (ICM), EL MUNDO, etc.

Además, soy profesor de la Universidad Rey Juan Carlos.

En lo que refiere a certificaciones, muchas, algunas de ellas: Certified


Management 3.0 Practitioner (y co-owner de la propia Management 3.0),
Scrum Master certificado por Jeff Sutherland (co-creador de Scrum),
Advanced Agile certificado por Alistair Cockburn (uno de los padres de la
agilidad), Certificado DAD (Disciplined Agile delivery) por Scott Ambler
(creador del modelo), etc.
1. Prefacio ................................................................................................... 25

2. Peopleware ............................................................................................... 33
2.1 El Lado Oscuro: Taylorismo e industrialización .............................. 35
2.2 Equipos y personas: la esencia de la agilidad ................................ 39
2.3 Management 3.0................................................................................. 46
2.4 Tribus ............................................................................................... 48
2.4.1 Nivel 1 ..................................................................................................................... 51
2.4.2 Nivel 2 ..................................................................................................................... 51
2.4.3 Nivel 3 ..................................................................................................................... 52
2.4.4 Nivel 4 (Equipo Ágil) ............................................................................................. 52
2.4.5 Nivel 5 (Equipo Ágil) ............................................................................................. 53
2.4.6 O te adaptas a la cultura de la tribu o la tribu te expulsa ...................................... 54
2.5 Equipos “Good to Great” ...................................................................... 55
2.5.1 Liderazgo nivel 5: ambición y humildad .............................................................. 55
2.5.2 Primero “quién” y luego “qué” ............................................................................... 56
2.5.3 Enfrentarse con la dura realidad ........................................................................... 56
2.5.4 Una clara estrategia................................................................................................ 56
2.5.5 Cultura de disciplina (sin burocracia ni exceso de reglas) ................................... 57
2.5.6 Aceleradores tecnológicos ........................................................................................ 57
2.5.7 Constancia .............................................................................................................. 57
2.6 A un equipo deberías verlo como un sistema complejo ................... 58
2.7 Último consejo antes de seguir: Cuidate del Cobra Kai .................. 60

3. Motivado ................................................................................................. 65
3.1 Teoría X e Y .......................................................................................... 68

21
3.1.1 La Teoría X .............................................................................................................. 68
3.1.2 La motivación, los deseos y la pirámide de Maslow ............................................... 69
3.1.3 Pasarlo bien en el trabajo... ¿es malo? ..................................................................... 69
3.1.4 Una necesidad satisfecha ya no motiva ................................................................ 71
3.1.5 Los gestores pueden satisfacer necesidades sociales o egoístas... indirectamente 73
3.1.6 Teoría Y ................................................................................................................... 74
3.2 La motivación intrínseca ...................................................................77
3.3 Las recompensas pueden desmotivar .................................................. 78
3.4 Reglas para el buen uso de recompensas .............................................81
3.5 Práctica de Management 3.0: Kudo Box ............................................ 82
3.5.1 Pero cuidado con los kudos ..................................................................................... 84
3.6 ¿Qué motiva intrínsecamente?........................................................ 86
3.6.1 Adquirir conocimiento y/o la curiosidad .............................................................. 88
3.6.2 Honra, honor y lealtad ............................................................................................ 88
3.6.3 Libertad, independencia, autonomía ......................................................................89
3.6.4 Poder y/o estatus ......................................................................................................89
3.6.5 Relaciones ................................................................................................................ 90
3.6.6 Orden ........................................................................................................................ 90
3.6.7 Objetivo y propósito .................................................................................................. 91
3.7 Práctica: calendarios Niko-Niko ..................................................... 93
3.8 Práctica: celebra éxitos y la Spaghetti Dinner ................................... 97

4. Auto-Organizado .................................................................................. 101


4.1 Modelos de liderazgo y auto-organización ...................................... 104
4.1.1 El control y mando ............................................................................................... 104
4.1.2 Líder sirviente, el anfitrión y el invitado ............................................................ 105
4.1.3 La escalera del liderazgo ........................................................................................ 109
4.1.4 Autonomía del equipo y alineamiento por la dirección ........................................ 111
4.1.5 Los estilos de liderazgo de Goleman ..................................................................... 112
4.1.6 Holocracia .............................................................................................................. 114
4.2 ¿Debería haber managers? Todos deberíamos ser Managers ......... 116
4.3 Práctica de Management 3.0: Tableros de delegación ...................... 119
4.4 ¿Reglas? ¿Normas? ........................................................................ 122
4.4.1 Principio de subsidiariedad .................................................................................. 126

22
4.4.2 ¿Reglas para que todos trabajemos igual?............................................................ 127
4.5 Seguridad, la cultura del error como base de la innovación ........ 127
4.5.1 Evita la cultura de búsqueda de culpables ........................................................... 128
4.5.2 La innovación se alimenta de equivocaciones ..................................................... 129
4.5.3 Anzeneering ..........................................................................................................131
4.5.4 La seguridad psicológica ...................................................................................... 133

5. Multifuncional .................................................................................... 137


5.1 El problema de los silos ..................................................................... 137
5.2 El equipo multifuncional ................................................................. 140
5.3 T-Skills, no todo el mundo sabe hacer de todo ................................. 142
5.4 Matrices de multifuncionalidad .................................................. 143
5.5 De silos a multifuncionales pasando por Tuckman........................ 144
5.6 Cambia la orientación a proyectos por equipos ............................. 146
5.7 El equipo ágil es estable ................................................................. 148
5.8 La separación física entre los miembros de un equipo impacta ...... 152
5.9 Identidad, sentimiento de equipo ..................................................... 154
5.9.1 Nombres ................................................................................................................. 155
5.9.2 La prueba de la camiseta ....................................................................................... 155
5.10 Práctica de Management 3.0: Exposición del trabajo ................... 156

6. Productivo ............................................................................................. 161


6.1 Medir horas es peligroso, erróneo y obsoleto ...................................... 161
6.1.1 “Crunch mode” vs “Sustainable pace” .................................................................. 164
6.1.2 Gestión por fuerza bruta ....................................................................................... 165
6.1.3 Slack: quemar al equipo no se traduce en mayores resultados .......................... 167
6.1.4 No puedes medir la productividad de un programador (aplicable a trabajador del
conocimiento) ......................................................................................................................... 169
6.2 La velocidad del equipo... Algo más preciso que contar horas ...... 171
6.3 Desperdicios que frenan la velocidad del equipo ........................... 173
6.3.1 El desperdicio del tamaño ..................................................................................... 174
6.3.2 El desperdicio de la interrupción .......................................................................... 177
6.3.3 El desperdicio del cambio de contexto.................................................................... 184
6.3.4 Práctica: El Swarming ......................................................................................... 186

23
6.3.5 Práctica: Time Boxing ...........................................................................................188
6.3.6 Práctica: Pomodoro ................................................................................................. 190
6.3.7 El desperdicio de los malos entornos físicos ......................................................... 192
6.4 Pero... Nunca olvides que lo más importante es el valor ............... 193

7. Mejora (Kaizen) ................................................................................... 197


7.1 Cultura de reflexión y retrospectiva ..................................................198
7.2 Visualiza el cambio ....................................................................... 201
7.3 Práctica de Management 3.0: Celebration Grid: Visualiza +
Experimenta + reflexiona ........................................................................... 203
7.4 Lean Change .................................................................................. 204
7.5 Lean Coffee .................................................................................... 206

8. Bibliografía .......................................................................................... 212

24
1. Prefacio

La puerta del oficial de comunicaciones se abrió lentamente, al otro lado se


veían unas manos mecanografiando muy rápidamente, con claros síntomas
de nerviosismo. En el papel, que rápidamente iba saliendo del teletipo, podía
leerse lo siguiente: “naciones luchan contra terror desconocido. Las armas
más mortíferas de la ciencia listas para combatir terror innombrable”. Casi en
el mismo instante, al otro lado de la ventana, un coche recorría la avenida a
gran velocidad, sobre su techo varios megáfonos repetían: “permanezcan en
sus casas, repito, permanezcan en sus casas”. Los megáfonos de las estaciones
y centros públicos se unían, repetían el mismo mensaje, añadiendo: “la
seguridad de la ciudad depende de su cooperación con las autoridades
militares”.

A pocos kilómetros de allí, en el desierto, un puñado de heroicos militares y


agentes de policía hacían frente, disparando, ridículamente, dando una
extraña imagen de impotencia e insignificancia, a algo difícil de describir...
un grupo de hormigas gigantes, monstruos fruto del descontrol que había
hecho la humanidad en el uso de la radioactividad, ¡no había palabras para
describirlas!

Escribí lo anterior mientras veía “Them!”, una película serie B de 1954, un


clásico del terror y la ciencia ficción. Esas hormigas terroríficas, como se
organizaban, me recodaban algo, y no me refiero a algo horrible o de terror (o
sí, pero en este caso no me refiero a eso).

Un equipo potente, uno “con mucho peopleware”, un equipo ágil, trabaja de


manera parecida a como se organiza una colonia de hormigas: sin grandes
jerarquías, sin total centralización de la toma de decisiones en un único

25
individuo, pequeño grupo o jefe de proyectos, no existen departamentos de
hormigas especializados, etc.

En términos generales, podríamos cambiar hormigas por abejas, por los pájaros
que forman una bandada, un banco de peces o incluso las neuronas que
forman un cerebro.

Hay un tipo de manera de organizarse que viene “de serie” en “el ADN” de
muchos seres vivos y que es mucho más antigua, y diferente, que aquella
que, no hace tantos años, los humanos inventamos para organizar muchas
empresas, aquella que el hombre inventó para organizarse cuando llegó la
época de la industrialización y que hemos heredado, generación tras
generación, hasta nuestros días. Pero hoy la mayoría no trabajamos en el
sector industrial, no participamos en la creación de productos
industrializados... aun así muchos siguen organizándose de “aquella
manera”.

La clave, la pieza fundamental de un equipo ágil, y de la agilidad en general,


está precisamente ahí... en tener equipo, esa palabra tan poco comprendida
como frívolamente usada. Una hormiga individual puede ser brillante, pero la
colonia, el colectivo, es capaz de hacer cosas increíbles. Una sola neurona puede
ser algo fascinante, pero todas juntas... crean un Steve Jobs.

Frente a la gestión centralizada en un solo individuo, o un pequeño grupo,


cada hormiga decide y participa en qué hacer, qué decisión tomar, tienen
autonomía, auto-organización (como le llamamos en agilidad), liderazgo
rotativo y temporal, según las circunstancias, una parte esencial de cualquier
equipo ágil. No hay una hormiga, abeja, neurona, etc., que fije un plan
detallado para el resto... todas van “creando el plan”, decidiendo, con
autonomía, según sean las circunstancias y la realidad que se van
encontrando.

26
Y aunque cada hormiga tenga su especialización puede cambiar de tarea si el
colectivo lo necesita. Una hormiga dedicada a labores domésticas saldrá a
buscar comida si el colectivo lo necesita, algo que suena mucho a ese concepto
tan de equipos ágiles como es la multi-funcionalidad.

Quizá, en el fondo, los grandes valores y principios de lo que llamamos


peopleware, o equipos ágiles, la naturaleza ya nos los enseñó a los seres vivos
que trabajamos en grupos. Aunque muchos colectivos y organizaciones de
humanos parecen haberlo olvidado. He aquí un humilde texto que pretende
que, al menos tú y yo, recordemos, y aprendamos, que hay maneras más
naturales, peopleware y ágiles, de organizarnos.

¡Necesitamos más peopleware!


Hace un tiempo lancé una propuesta desde mi blog (javiergarzas.com): que
sinceramente se respondiera a una serie de preguntas relativas a competencias
sobre gestión de equipos. En aquella encuesta participaron 453 personas, un
número razonable para hacerse una idea.

La encuesta proponía una serie de cuestiones, de las que te dejo con un par de
datos: solo un 16% había leído el Mythical Man-Month de Brooks (libro del
año 75 inspirador de un montón de ideas que usamos hoy cuando hablamos
de equipos ágiles) y sólo un 19% habían leído “algo” sobre peopleware.

Otra razón más. Había que hacer algo, así que espero poder contribuir a la
comunidad y poder ayudarla con este libro.

27
Sobre la selección de temas
De cada uno de los temas que trata este libro puede haber decenas de libros
especializados. Eso sin entrar en otros tantos temas bajo el paraguas
peopleware que yo no he contemplado.

Así que, lo primero que quiero decirte es que confíes en mí... si estás aquí ya
no te queda otra.

La selección de los temas que he incluido en el libro, y los que no, la he basado
en mi experiencia, en lo que yo uso frecuentemente, lo que veo, lo que más
deben potenciar los equipos, lo que más están mejorando las organizaciones
que están en una transformación ágil, lo que más vas a usar y más te vas a
encontrar.

El libro está dividido en 6 grandes áreas, en la primera te presentaré el


concepto de peopleware y equipos ágiles, el resto corresponden con los
principales atributos de un equipo ágil: está “motivado”, “auto-organizado”, es
“multi-funcional”, “productivo” (entendiendo bien la productividad) y
“mejora” (o Kaizen) continuamente.

Y, como en otras ocasiones, en otros de mis libros y guías, me he puesto el


objetivo de que te sea lo más fácil, ameno y rápido de leer. De nada vale escribir
algo si nadie lo va a leer. Y de ahí que, entre otros, limitase el número de
páginas a, aproximadamente, 200, lo cual, además, me forzó a seleccionar
muy cuidadosamente los contenidos a incluir.

Libros relacionados
Si no estás familiarizado con Scrum, o con la agilidad en general, te
recomiendo leer antes estos libros:

28
• Gestión de proyectos ágil…. y las experiencias de más de 12 años de
proyectos ágiles. Garzás Parra, Javier. ISBN: 978-84-616-9017-6.
Edita 233 Grados de Ti.

• Cómo sobrevivir…A la planificación de un proyecto ágil. Garzás


Parra, Javier. ISBN: 978-84-616-5733-9. Edita 233 Grados de Ti.

Estos libros podrás encontrarlos en:

• http://233gradosdeti.com/publicaciones-233/

Webs y redes sociales relacionados


Este mundo se mueve tan rápido que lo escrito pronto queda anticuado, por
eso, si quieres mantenerte al día en estos temas te recomiendo seguir:

• www.javiergarzas.com

• www.233gradosdeTI.com

• www.facebook.com/javiergarzas.blog

• Youtube: el de Javier Garzás y el de 233 Grados de TI

• Slideshare Javier Garzás

29
31
2. Peopleware

"Al final, la verdadera fuerza del espartano es el guerrero que está a su lado. Así que dale respeto y honor.”

-- Fragmento de la película 300

El que lanzó el tema del peopleware a la popularidad fue el famoso libro


ochentero (¿hay algo que no se inventara en los 80?) Peopleware: Productive
Projects and Teams (DeMarco & Lister, 1987), que popularizó estudios que
hablaban sobre la importancia del papel humano en el desarrollo software y
sus especiales particularidades. Mucho de ello fue casi olvidado durante
mucho tiempo, posteriormente fue rescatado y remasterizado, por la corriente
ágil actual. Hoy en día aquellas ideas, y todas las que han evolucionado y
derivado desde entonces, se usan en muchas otras actividades intelectuales,
trabajos en grupo, más allá del puro desarrollo software.

Aquel libro del 87 de DeMarco y Lister, es el más famoso. Si bien, el tema


venía aún de más atrás: el término peopleware (software, hardware… y
peopleware) fue usado por primera vez en 1977 por Peter G. Neumann en su
libro “Peopleware in Systems” (del que hoy, desgraciadamente, es casi
imposible hacerse con un ejemplar).

Lo que el término venía a decirnos es que entre las claves que determinan el
éxito o fracaso de una actividad, como es el caso del desarrollo software, sin
duda, la más determinante es “las personas”.

En mayor o menor medida, prácticamente todo aquel que ha estudiado el éxito


o fracaso de un proyecto software ha destacado el papel clave que las personas,
y por extensión el equipo, juegan.

33
Como decía (Glass, 2002), “no hay que olvidar que las personas son las que
hacen el software”, hoy podríamos extender esa frase a que son las personas las
que crean servicios, crean ideas, productos del conocimiento, etc. Las
herramientas ayudan, las técnicas también, los procesos, etc., pero sobre todo
esto están las personas.

Mucho se ha hablado de este tema. Por ejemplo, como señaló Davis en su genial
libro 201 Principles of Software Development (Davis, 1995), “las personas son
la clave del éxito”, hablando sobre qué marca la diferencia en un proyecto.

Y Cockburn, “el equipo humano es el componente no lineal de primer orden en


el desarrollo software” (Cockburn, 2000).

También McConnell, que comentó que “las personas son las que tienen más
potencial para recortar el tiempo de un proyecto” y que quienes han trabajado
en software “han observado las enormes diferencias que hay en los resultados
que se producen entre desarrolladores medios, mediocres y geniales”
(McConnell, 1996).

Más, aunque en lo nuestro siempre hay que tomar las estadísticas con
cuidado, después de analizar 69 proyectos (Boehm, 1981) comprobó que los
mejores equipos de desarrolladores eran hasta 4 veces más productivos que los
peores. En la NASA (Vallet & McGarry, 1989), observaron diferencias de
hasta 3 a 1 en productividad entre sus diferentes proyectos. E incluso mucho
antes, en el 74, había ya estudios (Weinberg & Schulman, 1974) que habían
observado diferencias de 2,6 a 1 en productividad en equipos a la hora de
realizar las mismas tareas de desarrollo.

Como has podido ir viendo, hay un montón de mensajes desde diferentes sitios
resaltando la importancia de las personas y equipos, por encima de otros, como
procesos, documentos, estructuras y jerarquías inadecuadas, etc.

34
Y, en todo caso, independientemente de los números, referencias y estudios...
¿es que no lo sabias ya?... claro que sí, ¿cuántas veces has vivido la experiencia
de que han sido personas las que salvan y marcan la diferencia en proyectos
y organizaciones (y no procesos, métodos, documentos, etc.)?

Todas esas ideas, con su gran profundidad, son el peopleware. Lo que hoy
también conocemos como equipos ágiles, actualizando esas importantes ideas
de hace años a los tiempos que corren.

No hay una única definición de peopleware o de equipos ágiles, si muchas


corrientes que apuntan hacia la misma dirección, y eso, en sí, le da más
riqueza a la idea.

De entre todas esas corrientes e ideas, aparte de las que ya he mencionado, voy
a comentar algunas de las más importantes, comenzado por la propia idea de
Agilidad, pasando por la de Management 3.0, la de Tribus, etc., para que
entendiendo todas, desde varios ángulos, esquematices en tu mente esa idea
de... peopleware.

Pero antes, para que te quede más claro aún, quiero presentarte al lado opuesto
del peopleware, al “Lado Oscuro”, la visión más tradicional y alejada de lo que
buscamos, tan presente en nuestros días y que se camufla fácilmente...

2.1 EL LADO OSCURO: TAYLORISMO E INDUSTRIALIZACIÓN

Aunque para algunos esto esté muy claro, no siempre ha sido así, ni es así, en
todos los sitios. De hecho, he conocido (y conozco) demasiadas organizaciones
en las que no pensaban (piensan) exactamente de esta forma, en las que la
gerencia veía que los desarrolladores, o los trabajadores del conocimiento, no
eran lo más determinante, eran “piezas intercambiables... meros recursos”
(¿humanos?), y, de hecho, así, literalmente, me lo dijo una vez una directiva.

35
Quizá el Taylorismo te suene de algo, resumiendo al máximo, en 1911
Frederick Taylor (1856 – 1915) publicó su histórico libro, aquel llamado The
Principles of Scientific Management. Y fue ahí donde empezó todo, el Lado
Oscuro para nosotros, ahí él propuso la gestión (el management) como algo
“revolucionario” que resolvería las limitaciones de productividad de las
organizaciones de la era industrial.

Taylor fue pionero en la idea de dividir una organización entre personas que
piensan (ejecutivos, managers, diseñadores, etc.) y personas que hacen
(constructores), idea que puedes leer por ahí en inglés como thinkers vs doers
(los que piensan frente a los que hacen), legitimando así la profesión del
“manager” como thinking principals of the non-thinking human resources
(los directores de los recursos humanos no pensantes).

Taylor también introdujo la idea de división funcional, la especialización en


el trabajo y la jerarquía, managers pensantes en la parte alta y trabajadores
que ejecutan sin la responsabilidad de pensar en la baja (recuerda esto cuando
avances en el libro y tratemos cosas como la multifuncionalidad y la auto-
organización).

Su modelo de organización se usó ampliamente en fábricas después de su


muerte, en 1915, llegando, posteriormente, su uso hasta organizaciones ya no
industriales, de servicios, etc.

Concretamente, la división en thinkers vs doers generó las conocidas como 3


grandes brechas del Taylorismo:

• La social: debido a las jerarquías…un grupo arriba, otro abajo.

• La funcional: división funcional, especialización en equipos,


departamentos o incluso empresas, que provoca necesidad de

36
jerarquías, problemas de comunicación e interfaces entre esos
llamados silos.

• La de tiempos y planificaciones: la división entre los que piensan y


los que hacen lleva a la necesidad de planificaciones, coordinaciones
y gestiones temporales, tiempos para pensar y, posteriormente,
tiempos para hacer lo pensado, lo que daría origen a técnicas como los
Gantt (Gantt, el que los creó, fue alumno de Taylor).

Hay mucho escrito sobre lo inhumano, poco científico, etc., de la llamada


“gestión científica” de Taylor y muchas frases “populares” de Taylor, que hoy
seguro te van a parecer horribles, como aquella de “en el pasado el hombre fue
primero; en el futuro el sistema debe ser primero”.

El caso es que mucho del management tradicional, el de mayor uso, como lo


conocemos hoy, se educó en aquellas bases y no es muy diferente de lo que
Taylor propuso hace más de un siglo.

En el mundo del software no solo heredamos modelos de gestión como los de


Taylor y los diagramas Gantt, sino que quizás por lo reciente de la profesión,
por la “crisis de identidad” que la acompañó durante años (no saber qué
profesión éramos y tomar referentes erróneos), etc., gran parte del sector
pretendió imitar la manera de trabajar industrial... y el Taylorismo llegó a
tomarse como referente y patrón a imitar.

Y de ahí vienen ideas como la separación entre diseño (los que piensan o
thinkers) y programación (los que hacen o doers), el ciclo de vida en cascada,
su gestión con Gantts, la especialización en departamentos frente a la
multifuncionalidad (que empezaremos a ver en la pág.135), hasta la idea de
proyecto, etc.

37
Esto llevó a un modelo de trabajo en el que la parte más esencial, la humana,
se pretendía relegar a un segundo plano, por detrás de procesos y modelos de
trabajo.

Los problemas y costes que hemos arrastrado durante años por intentar
implantar esa visión en profesiones puramente intelectuales, del conocimiento
(recordemos, no industriales), han sido altísimos.

Enumerarlos todos sería largo, pero véase como ejemplo la “lista de errores
clásicos” del desarrollo software, un famoso compendio que recopiló hace años
(McConnell, 1996), donde se describen los principales y típicos problemas que
se suelen encontrar a la hora de gestionar software.

La lista original contiene 36 errores típicos, pero para no extenderme te dejo


aquí los 10 primeros que derivan de una mala gestión del equipo. Seguro que
más de uno (y de cinco) te van a sonar:

1. Descuidar la motivación del equipo.

2. Tener en el equipo personal poco preparado.

3. No encargarse de los problemas en el equipo.

4. Demasiados héroes.

5. Añadir gente a un proyecto con retraso (lo que provoca que se retrase
más).

6. Oficinas ruidosas.

7. Fricción entre desarrolladores y clientes.

38
8. Fijar expectativas para el proyecto que no son realistas.

9. Falta de apoyo de la dirección.

10. Falta de involucración por parte de los stakeholders del proyecto.

La gente que participa en una creación intelectual como es el software, un


plan de marketing u otros productos del conocimiento, no son como los obreros
en una cadena de montaje, cuyo trabajo tiene un alto componente físico y no
tanto intelectual.

2.2 EQUIPOS Y PERSONAS: LA ESENCIA DE LA AGILIDAD

Podríamos decir que la palabra agilidad, aplicada al software (que es donde se


origina), como tal, aparece en 2001, cuando 17 representantes de frameworks
de desarrollo software (Scrum, Extreme Programming, DSDM, etc.) que
presentaban una alternativa a la visión tradicional, de inspiración en el
Taylorismo, se juntaron y escribieron un conjunto de valores y principios
comunes que suponían una réplica a los enfoques tradicionales.

La réplica iba frente a los procesos de desarrollo software, que llamamos


“tradicionales” o “pesados”, que se basan mucho en la documentación, en la
predictibilidad, en buscar planes inamovibles, etc. Aquellos que representan la
translación de ideas industriales, o de arquitectura tradicional, al mundo del
software.

39
40
Hasta esa época, lo más típico era pretender ver el desarrollo software como una
cadena de montaje de un producto en una fábrica: con fases separadas que se
realizan una única vez (toma de requisitos del cliente, diseño, desarrollo,
testing), roles especializados, silos, etc.

Pero el desarrollo software por naturaleza (extensible a muchos trabajos del


conocimiento) no es así. Es una actividad creativa, que normalmente se
realiza en equipo, donde la motivación, las habilidades personales y las
relaciones entre las personas importan mucho en el resultado final, y en el
que la comunicación entre personas es vital (demasiado vital como para
entregarla 100% a un documento).

Y, por si fuera poco, el mundo de los productos del conocimiento está muy
sujeto a cambios, porque avanza muy rápido, porque los usuarios muchas
veces no tienen claro lo que quieren e incluso porque el equipo tampoco tiene
claro al principio cuál es la mejor forma de hacer lo que necesita el cliente y
puede que tenga que hacer varias pruebas hasta encontrar la mejor solución.

Para manifestar lo poco apropiado de los modelos de trabajo tradicionales,


aquellas 17 personas escribieron el Manifiesto Ágil, formado por 4 valores y
12 principios que tratan sobre la profesionalidad, la excelencia técnica, la
mejora continua, etc.

41
42
El Manifiesto Ágil es una especie de paraguas, bajo el cual hay un montón de
frameworks más detallados como Scrum, XP, etc.

43
Además, los 4 valores del manifiesto, se acompañan de 12 principios:

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega


temprana y continua de software con valor.

• Aceptamos que los requisitos cambien, incluso en etapas tardías del


desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.

• Entregamos software funcional frecuentemente, entre dos semanas y


dos meses, con preferencia al periodo de tiempo más corto posible.

• Los responsables de negocio y los desarrolladores trabajamos juntos de


forma cotidiana durante todo el proyecto.

• Los proyectos se desarrollan en torno a individuos motivados. Hay


que darles el entorno y el apoyo que necesitan, y confiarles la
ejecución del trabajo.

• El método más eficiente y efectivo de comunicar información al


equipo de desarrollo y entre sus miembros es la conversación cara a
cara.

• El software funcionando es la medida principal de progreso.

• Los procesos ágiles promueven el desarrollo sostenible. Los promotores,


desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.

44
• La atención continua a la excelencia técnica y al buen diseño mejora
la agilidad.

• La simplicidad, o el arte de maximizar la cantidad de trabajo no


realizado, es esencial.

• Las mejores arquitecturas, requisitos y diseños emergen de equipos


auto-organizados.

• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo


para, a continuación, ajustar y perfeccionar su comportamiento en
consecuencia.

Independientemente de los diferentes frameworks ágiles, ya puedes


interiorizar cómo los valores y los principios del manifiesto resaltan a las
personas, la comunicación cara a cara, la colaboración entre diferentes áreas y
especialidades, etc.

Ha pasado ya mucho tiempo desde que se escribiera el Manifiesto Ágil y, en la


actualidad, muchos han propuesto su actualización. Algunos sustituyen en
el mismo manifiesto la palabra software por “soluciones”, para hacer extensible
su aplicación a otras áreas más allá del desarrollo software.

Dentro de estas propuestas de actualización hay algunas interesantes, como el


Modern Agile de Joshua Kerievsky, que sintetiza la agilidad en 4 principios:

• Haz que la gente sea impresionante.

• Haz de la seguridad (psicológica) un prerrequisito.

• Experimenta y aprende rápidamente.

45
• Ofrece valor continuamente.

De nuevo, los dos primeros principios del Modern Agile hablan de personas.

Una propuesta más, la de Alistair Cockburn, uno de los firmantes del


manifiesto original, que propone “el corazón de la agilidad” para resumir las
bases: colaborar, reflexionar, entregar y mejorar. Nuevamente, resalta la
importancia de las personas en las bases de la agilidad.

Iremos viendo cómo trabajar muchas de las bases anteriores en los siguientes
capítulos, antes vamos con más ideas, corrientes y conceptos tras todo esto que
llamamos peopleware...

2.3 MANAGEMENT 3.0

Lo que más te puedes encontrar si sales ahí fuera es una lucha entre varios
mundos, varias visiones de cómo gestionar organizaciones y equipos, el
mundo del pasado que está muy presente, que cuenta con años de tradición,
que está asentado en múltiples organizaciones, que fue originado en la época
industrial y, por otro lado, la lucha, casi del tipo a la de los “rebeldes” contra el
imperio, de un nuevo (lo de nuevo entre comillas) modo de ver y hacer las
cosas, más acorde a un modelo de organización que trabaja con “ideas”, más
que con “hierro”.

No soy muy amigo de las etiquetas, tan de moda últimamente, de ponerle a


todo “1.0”, “2.0” o “3.0”, pero Jürgen Appelo las utiliza bastante bien para
contar esta lucha entre la visión clásica de gestionar, que llama 1.0 y la
visión del futuro-presente, que llama 3.0 (Appelo, 2016), bastante útil para
entender la situación actual

46
Aún hoy, la práctica más común es que las organizaciones gestionen, o lo
intenten, a sus trabajadores como máquinas. Esto es algo que caracteriza al
Management 1.0: supervisión, control de horarios, sistemas de fichar, miedo,
horas, salir el último de la oficina como prueba de valentía, etc. También es
típico aquí el gestionar al personal mediante la competitividad entre los
miembros (frente a la visión de que el éxito es del equipo y la visión
compartida).

Afortunadamente, hay ya organizaciones que han aprendido que hay otra


manera de hacerlo mejor. Por ahora, hablamos aquí de las organizaciones
Management 2.0, donde se sabe que “las personas son el activo más valioso” y
que los directivos deberían ser “servidores” que gestionan que la gente pueda
desarrollar su mayor potencial.

Interesante, pero, lamentablemente, las estructuras de empresas que


empezaron gestionándose en Management 1.0 durante muchos, muchos años,
no son nada fáciles de cambiar, y aunque empiezan a ver la importancia de
los equipos, y por eso están en Management 2.0, aún se estructuran haciendo
uso de esos departamentos especializados, grandes jerarquías, etc. Por lo cual,
por mucho interés que tengan los nuevos directivos de cambiar la manera de
gestionar, el entorno y la estructura... se lo hace casi que imposible.

Yo, que suelo colaborar con muchas empresas, te puedo asegurar que la
mayoría de las medianas y grandes están entre el Management 1.0 o el
Management 2.0. Muchas de ellas ya han visto la necesidad de hacer un
cambio, más acorde a los tiempos que corren. Pero están, y seguirán estando
durante muchos años, en Management 2.0, porque la estructura, entorno,
jerarquías, costumbres, con las que se han gestionado durante años, no son
nada fáciles de cambiar. Y muchas, por desgracia, van a necesitar hasta un
cambio generacional para poder hacerlo.

47
Dicho lo anterior, el Management 3.0 se cuenta muy rápido (si bien aplicarlo e
interiorizarlo te puede llevar años): la visión orientada a personas y equipos
en una estructura organizativa pensada para ello.

Más allá de las definiciones anteriores, el Management 3.0, como disciplina,


aglutina un conjunto de ideas y “prácticas” para potenciar a las personas y
los equipos. A lo largo del libro, te iré dejando algunas de ellas, las que
considero más importantes y que suelo ver, y usar, con mayor frecuencia.

2.4 TRIBUS

Otra manera de aproximarnos a lo que vamos a entender por peopleware,


equipos ágiles, es la idea del Tribal Leadership (Logan, King, & Fischer-
Wright , 2008) que es un bestseller, en el que cuentan los autores que los
responsables y líderes empresariales deberían conocer los grupos que hay
dentro de sus empresas, cómo esos grupos se comunican, qué cultura tienen y
cómo son, y sobre todo, ser conscientes de la importancia que esto tiene para
entender cómo opera la empresa y hasta dónde puede llegar. Para explicarlo
mejor a dichos grupos les llamaron “tribus”.

Una tribu se compone de entre 20 y 150 personas, cuando una tribu tiene más
de 150 miembros ella misma suele dividirse, por si te suena, este es el número
de Dunbar, que dice que “no se puede mantener relación social con un grupo
de más de 150 personas” (número que toma también Spotify para sus
famosas tribus ágiles).

Una gran empresa puede contener muchas tribus, en competencia y/o


cooperación y, una pequeña empresa puede contener solo una. Establecernos en
tribus está dentro de nuestro ADN y estas han ayudado al hombre a sobrevivir
desde la última edad de hielo.

48
Cada una tiene una cultura dominante y un líder, y eso hace diferentes a
unas tribus de otras.

Los autores clasifican en una escala de uno a cinco las diferentes culturas en
las que puede estar una tribu, donde el nivel 1 es la menos deseable y la cinco
la más potente y, normalmente, para evolucionar hasta un nivel hay que
pasar antes por las previos. Y cada nivel lo identifican con una frase que
representa el sentimiento y cultura en dicho nivel.

49
50
El nivel 1 es una tribu más primitiva, el 4 y el 5 son más evolucionados. Para
nosotros, estos dos últimos identificarían a un equipo ágil.

Conocer en qué tribu estás y trabajar para evolucionar a una tribu de un nivel
superior es lo que viene a llamarse tribal leadership (liderazgo tribal), que,
además, tiene algunos fans notables, incluyendo al co-fundador de Zappos,
al de Linkedin, etc. Hasta el famoso y deseado escalado ágil de Spotify hizo
uso del término Tribu.

Entender el liderazgo tribal tiene su interés y te ayudará a entender muchos


comportamientos en el día a día de una organización. Incluyendo por qué se
ha establecido cierta manera de trabajar y por qué se rechaza otra (ágil).

2.4.1 NIVEL 1

Afortunadamente, la mayoría de los profesionales no hemos visto ni vivido


nunca esta primera etapa tribal, cuya mentalidad es… de “pandillas
callejeras”. La frase con la que se identifica es la de, literalmente, “la vida es
una mierda”. Las personas en este nivel son hostiles, desesperadas, violentas y
se unen para salir adelante en un mundo violento e injusto. Las
organizaciones, por lo general, no contratan individuos que suelen moverse
en tribus de nivel 1 y, si lo hacen, los expulsan rápido. Así que vamos con la
dos…

2.4.2 NIVEL 2

Según los autores del libro, el 25% de las tribus en los lugares de trabajo están
en este nivel. Y la frase que la identifica es la de “mi vida es una mierda”. La
gente en este nivel se resigna y se cruza de brazos, es apática y está
desmotivada.

51
Este nivel es bastante común, es típico de gente desmotivada, que lleva años
haciendo lo mismo en el mismo sitio, sin ningún incentivo. Trabajan porque
no hay otra salida, pero no les gusta su trabajo.

2.4.3 NIVEL 3

El que, según el libro, domina en el 49% de las tribus. La frase que lo


identifica es “yo soy genial” o, más concretamente, “yo soy genial y tú no.”
Normalmente, suele darse en colectivos de médicos, abogados, comerciales,
consultores, etc.

En esta fase el conocimiento es poder. Las personas son competitivas de


manera individual. El estado de ánimo es de “guerreros solitarios”. Yo le
llamo, y es la foto que pongo cuando lo cuento, cultura a lo “Lobo de Wall
Street”. Búsqueda adictiva del éxito de manera individual pasando por
encima de otros.

De hecho, es muy común que en las compañías caracterizadas por tribus en


nivel 3, el éxito se mida de forma individual: ventas, objetivos comerciales, etc.

También existe en estas tribus un sentimiento de deshumanización. Vales


algo como persona mientras estás en la tribu y alguien puede aprovecharse de
ti, luego no eres nada. Si te vas de la empresa, te das de baja, te echan, etc.,
todo el mundo se olvida de ti… ¿te suena? ¿lo has vivido?… yo sí.

2.4.4 NIVEL 4 (EQUIPO ÁGIL)

Estado muy potente para una tribu y al que pocos pueden llegar. La frase que
caracteriza a este tipo de tribus es la de “somos geniales”, “somos geniales
como grupo” (es más cercana a ese sentimiento existente en los equipos
deportivos). Y hay un abismo entre el “yo soy genial” (nivel 3) y “somos

52
geniales” (nivel 4), los autores no lo mencionan como tal, pero nosotros, a este
nivel, le podríamos llamar “ágil”.

Este tipo de tribus suele tener una tribu o grupo adversario con el que rivaliza
y compite, y ahí realmente el “somos geniales” podría extenderse a “…y ellos
no”. Y de ahí una regla para esta cuarto nivel: cuanto mayor sea el enemigo...
más poderosa será la tribu.

Cuando los grupos llegan a este punto, ellos se ven a sí mismos como una
tribu con un propósito común. Se comprometen con los valores fundamentales
compartidos por el grupo y no tolerarán individuos que vengan con la visión
del nivel 3.

Una organización, equipo, tribu, etc., de alto rendimiento, peopleware, debe


estar como poco en el nivel 4 y en intervalos en el 5 (que veremos ahora). No se
me ocurre cómo aquello que identificamos con una cultura ágil… puede
ocurrir en una tribu con un nivel menor al 4.

2.4.5 NIVEL 5 (EQUIPO ÁGIL)

La frase que la identifica es “la vida es genial”. Potencial altísimo, ese


sentimiento de que el grupo va a hacer historia, y no para vencer a un
competidor… sino porque su trabajo tendrá impacto global. Quieren cambiar el
mundo.

Los equipos en la nivel 5 han producido innovaciones milagrosas. Este nivel


es de liderazgo puro, visión e inspiración.

Después de un tiempo en este nivel estos equipos vuelven al nivel 4 para


reagruparse antes de volver al 5.

53
2.4.6 O TE ADAPTAS A LA CULTURA DE LA TRIBU O LA TRIBU TE
EXPULSA

Peter Drucker decía que "la cultura se come a la estrategia para desayunar". Si
una tribu está en, por ejemplo, el nivel 4, la de “somos en grupo los mejores”, es
porque la mayoría de miembros están en dicho nivel, y si viene un nuevo
miembro hablando el lenguaje de la 3, “yo soy el mejor”, la tribu rechazará a
esa persona.

Así funcionan las tribus… o nos moldean a su cultura o, si rechazamos su


cultura, nos aíslan. ¿No has sentido esto en alguna empresa en la que has
trabajado y de la que te has ido porque no encajabas? …yo sí (y me fui).

La mayoría de las empresas, medianas o grandes, tienen tribus que son


mezcla de los niveles 2 y 3, rondan la línea divisoria entre “mi vida es una
mierda” y “yo soy genial”, con algunas tribus menores en el nivel 4, la de
“somos geniales”. Y esto, en ocasiones, genera auténticas batallas.

Muchas empresas, que desconocen todo esto, intentan implantar una nueva
cultura, no saben cómo llamarle, pero intuyen que para seguir siendo
competitivos necesitan más tribus de nivel 4, incluso en ocasiones no saben
ni que hay tribus. Pero van a ciegas, dan charlas de cambio, le mandan a todo
el mundo el libro ese de Quién se ha llevado mi queso, les dan cursos, llaman
a consultores que vienen con un montón de PowerPoints de gestión del
cambio, pero…

La forma de mover toda una tribu al siguiente nivel es mover la masa crítica
de gente a la siguiente etapa. Este proceso consiste en mover a mucha gente
hacia delante de forma individual, facilitando el utilizar un lenguaje
diferente y cambiar, en consecuencia, un comportamiento diferente.

54
En una tribu en nivel 3 debería haber cada vez más gente de nivel 4 para que
exista el cambio.

Muy pocas personas tienen la capacidad de cambiar el escenario dominante de


una tribu. Esas personas son “líderes tribales”. El trabajo de un líder tribal es
acelerar el viaje de cada persona entre un nivel y otro, de manera que se forme
una nueva masa crítica y que, cuando eso suceda, la tribu se vea a sí misma
como una tribu. Esto es liderazgo tribal, en pocas palabras, se centra en dos
cosas: cambiar el lenguaje que la gente usa y los tipos de relaciones que se
forman en la tribu.

2.5 EQUIPOS “GOOD TO GREAT”

Vamos con otra aproximación más. El Good to Great (Collins, 2001) es un


“clásico”, venerado por muchos, y que trata sobre qué se repite en aquellas
empresas que pasan de estar en la media, a convertirse en grandes empresas
(no en tamaño sino en excelencia, liderazgo, etc.).

Pero, además de esas pautas, lo que hace este libro especial es la investigación
previa que se hizo para encontrar esas buenas prácticas. Estamos hablando de
un libro que es el resultado de una investigación de cinco años de trabajo.
Veamos qué tiene que decirnos sobre peopleware. Te voy a dejar a continuación
las 7 pautas que se repetían en las empresas estudiadas (los datos, empresas,
etc., los puedes ver en el libro).

2.5.1 LIDERAZGO NIVEL 5: AMBICIÓN Y HUMILDAD

Las empresas que salen de la media tienen líderes con ambición… y


humildad, líderes que dejan el ego en pro de los objetivos del grupo, que
piensan en “nosotros”, no en “yo” (lo cual me recuerda al liderazgo tribal y a
las tribus nivel 4 y 5 frente al nivel 3).

55
2.5.2 PRIMERO “QUIÉN” Y LUEGO “QUÉ”

Para la mayoría de las empresas, “qué hacer” a menudo se considera más


importante que “quién lo hace”. Es muy común que las grandes empresas
traten a los empleados como piezas, “recursos” las llaman algunos. Y este
segundo patrón habla de, primero, rodearse de la gente adecuada y, luego,
poner los objetivos, y no al revés.

Contratar a las personas adecuadas lleva por el camino del éxito, contratar a la
gente equivocada… lleva por el mal camino.

2.5.3 ENFRENTARSE CON LA DURA REALIDAD

Que es la capacidad de hacer frente a la realidad, conocerla, no esquivarla, no


vivir en cosas irreales.

2.5.4 UNA CLARA ESTRATEGIA

Que se puede sintetizar en ver si la empresa o grupo tiene interiorizada la


respuesta a estas tres preguntas:

• ¿En qué podemos ser los mejores del mundo?

• ¿Qué impulsa nuestro motor económico?

• ¿Dónde está nuestra pasión?

Y, resueltas estas preguntas, se convierten en un concepto único, claro y


simple.

56
2.5.5 CULTURA DE DISCIPLINA (SIN BUROCRACIA NI EXCESO DE
REGLAS)

Cuando las organizaciones empiezan a crecer, la reacción más común es


poner la empresa bajo control mediante la creación de burocracia, jerarquías,
procesos, contratando gente que los haga cumplir, etc. Y eso hace perder el
espíritu inicial, la innovación, la flexibilidad.

En las empresas que se salen de la media Collins encontró un patrón que les
permitió, ya con éxito, mantener esa energía intacta y a la vez crecer: libertad
para la gente, que implica y denota confianza, y que conlleva que cada
persona tenga una gran responsabilidad.

Y de ahí que la gente de esos equipos era de confianza y responsable. Por esto,
el concepto de disciplina aquí tiene que ver más bien con “auto-disciplina”. La
clave, de nuevo, es tener gente buena, la burocracia es… para los no tan
buenos. Hablaremos de esto en varias ocasiones, más adelante.

2.5.6 ACELERADORES TECNOLÓGICOS

Las grandes empresas se dieron cuenta de que no toda la tecnología es útil y


que es más una ayuda que un motor esencial. La tecnología debe estar
siempre dirigida por la estrategia. La tecnología puede acelerar, no impulsar.
Es una ayuda, pero por sí sola… no te convierte en grande (¿te recuerda a
“personas e interacciones sobre procesos y herramientas”?).

2.5.7 CONSTANCIA

Las cosas, el éxito, no ocurren de la noche a la mañana. Paciencia y


constancia. Hay que hacer “girar la rueda” de manera constante, hasta que
coge inercia y, de repente… el motor arranca.

57
2.6 A UN EQUIPO DEBERÍAS VERLO COMO UN SISTEMA COMPLEJO

Una aproximación al peopleware más, esta vez desde los sistemas complejos. Si
de verdad estás muy metido en temas ágiles, y has llegado realmente a
profundizar en el tema, en algún momento te habrás topado con la teoría de
los sistemas complejos.

El modelo Cynefin ya lo dejaba claro, no es lo mismo “simple” (fácil de


entender), que “complicado” (se puede comprender, aunque sea muy difícil) y
que “complejo” (la predicción es difícil, se aprende probando).

Y, para lo nuestro, gran cantidad de expertos ya dijeron en su día que un


equipo software (extensible a equipo que crea conocimiento) es un sistema
adaptativo complejo, como Jim Highsmith (firmante del Manifiesto Ágil), en
su libro Adaptative Software Development (Highsmith, 1999) o Ken Schwaber
(firmante del Manifiesto Ágil y co-autor de Scrum), en su libro Agile
Software Development with SCRUM (Schwaber, 2001).

La teoría de la complejidad es una teoría científica desde hace, relativamente,


poco tiempo. Importantes autores como Appelo e incluso destacados científicos,
como Stephen Hawking, han hablado de que la complejidad es una de las
ideas más importantes del siglo XXI.

Los equipos software, los de creación de productos del conocimiento y hasta los
“proyectos” software son sistemas adaptativos complejos.

Un sistema complejo se compone de agentes (elementos, partes)


interconectados, que interactúan unos con otros, que juntos forman un todo
y que constantemente se están organizando. Por ejemplo, agentes de un
sistema complejo pueden ser cada uno de los peces que forman un gran banco
de peces, los virus, cada una de las neuronas que forman el cerebro, cada uno

58
de los ñus que forman la manada, cada uno de los zombis que forman una
horda zombi, las hormigas con las que comenzamos el libro o cada una de las
personas de un equipo o proyecto.

En un equipo o proyecto… solo las personas son agentes, en el sentido de


agentes de un sistema complejo, porque son los únicos que pueden auto-
organizarse, interconectarse, interactuar, etc. Los Gantt, requisitos, tableros
ágiles, pósits, herramientas como Jira, o Trello, y otros tantos, no son agentes
del sistema complejo.

En cualquier sistema adaptativo complejo, desde una bandada de pájaros a un


equipo de personas, los agentes interactúan, cada uno tiene su propia
motivación, se adaptan, compiten y colaboran por un objetivo.

Además, si te fijas, en los sistemas complejos que hay en la naturaleza, los de


toda la vida, como en un enjambre, el control está muy distribuido, más que
centralizado, no hay un virus jefe, por ejemplo, y si hay una abeja reina esta
delega bastante en lo que hacen cada una de las abejas obreras (recuerda esto
cuando, más adelante, pág.99, hablemos de auto-organización).

¿Qué hubiese sido de los directores de las grandes películas de terror serie B sin
los sistemas adaptativos complejos? ¿Cómo hubiesen quedado películas como
Pirañas (1978), Enjambre (1977), La noche de los muertos vivientes (1968)
o La humanidad en peligro (Them!) (1954) y sus hormigas mutantes?

Además, en un sistema adaptativo complejo, cada miembro, o agente, del


grupo tiene su propia visión del mundo, que es una visión parcial, por lo que
para obtener una visión más amplia hace falta unir las visiones, la
información, de muchos agentes (¿te suena esto a técnicas como el plannning
pocker?)

59
La idea de “complejidad” choca mucho con la idea de “predictibilidad” (el
cascada en sí, asume la predictibilidad). De hecho, una de las claves de un
sistema complejo es que no suele funcionar con soluciones simplistas (las que
a continuación vamos a llamar “Cobra Kai”) o muy pensadas para la certeza,
como los cascada, Gantts, jerarquías de trabajo simplistas, pensar que
documentando se solucionan las incertidumbres y complejidades, etc.

La complejidad lleva consigo la incertidumbre. Y si tratas con un sistema


complejo lo peor que puedes hacer es tratarlo como un sistema complicado
(ejemplo típico de aplicación de técnicas de ingeniería clásica, arquitectura,
etc., a equipos y proyectos software). Y por ello...

2.7 ÚLTIMO CONSEJO ANTES DE SEGUIR: CUIDATE DEL COBRA KAI

El miedo no existe en este dojo, ¿verdad? ¡NO, SENSEI!

El dolor no existe en este dojo, ¿verdad? ¡NO, SENSEI!

La derrota no existe en este dojo, ¿verdad? ¡NO, SENSEI!

-- John Kreese, en un fragmento de la película Karate Kid

Cobra Kai, por si te falla la memoria (o no sé qué hacías en los 80), era el dojo
de kárate en la película Karate Kid, cuyas técnicas de “gestión” se
caracterizaban por usar prácticas brutales, violentas, poco éticas (hoy le
llamarían bullying) y estrategias simplistas que terminaban con malos
resultados.

Cuenta la leyenda que en tiempos de la colonización británica, en India se


disparó el número de cobras venenosas, llegando a ser una importante
amenaza. Para controlar la plaga, a los políticos (y estos no eran españoles)
no se les ocurrió otra que dar una recompensa económica por cobra muerta.

60
Al principio la cosa fue bien, pero cómo no… sé que tú también lo has pensado
ya… a alguien se le ocurrió criar cobras venenosas, para así no salir a
cazarlas y además aumentar el número de ejemplares a canjear por la
prometida recompensa. Y la best practice de criar cobras se extendió, creando
un negocio bien lucrativo, criar cobras y luego cobrar la recompensa de su
“captura”.

Pero bueno, llegado el momento, los políticos se dieron cuenta del engaño y
quitaron la recompensa por cobra capturada. Entonces el negocio de criar
cobras dejó de ser rentable, por lo que aquellos que las estaban criando dejaron
de hacerlo, dejando en libertad las cobras que tenían en posesión… lo que
incrementó aún más la plaga de cobras.

La anterior historia es un ejemplo de lo que técnica, y finamente (porque se


me ocurren otros muchos nombres que darle), se llama “reduccionismo”:
solución fácil a un problema complejo que, típicamente, acaba empeorando el
problema que pretendía solucionar.

Como el de las cobras, hay un montón de casos similares, por ejemplo, uno
muy citado es el de la “ley seca”, lo de ilegalizar el alcohol, que derivó en un
gran mercado negro, crimen organizado y la aparición de gánsteres como Al
Capone.

Obviamente, cómo no, la aplicación del reduccionismo y sus efectos ha crecido


en nuestro mundo más que la población de cobras, ideas simplistas que se
venden bien a gente poco conocedora de la profundidad de los temas. Ese
reduccionismo que hay quien llama “populismo tecnológico”.

Se me ocurren tantos reduccionismos en gestión de equipos, que no sé por


dónde empezar: valorar a la gente por las horas que echa (en vez de lo que
aporta), o medir el avance del trabajo por tiempo transcurrido (en vez de por

61
trabajo completado), la mayoría de documentos que se escriben para creer que
así se tiene el control, poner un sistema de fichar, etc., muchos de ellos los
iremos tratando más delante.

¡Ah! y como lo de llamar a todo esto solución “Cobra” era un poco soso, y
además se deja fuera otras conductas como las prácticas abusivas, decidí
llamarles… “Cobra Kai”, nombre que mola más, es más mnemotécnico, y nos
trae buenos recuerdos de la infancia.

Cuídate de las soluciones Cobra Kai, yo te contaré algunas, pero desde ahora
mantente siempre alerta.

62
63
3. Motivado

-Aquí es donde empecé [comenta Apollo Creed en el ruinoso gimnasio de Los Ángeles donde él empezó su
carrera].

–Ese es tu problema Rocky. Yeah. ¿Ves esa mirada en sus ojos [refiriéndose a la de un montón de chavales
entrenando a tope para poder llegar a algo en el boxeo] ¿Rocky? Cuando luchamos, yo entrené duro, pero
yo no tenía esa mirada. Tú la tenías y me ganaste.

Tengo que conseguir esa mirada de nuevo en ti, Rocky.

La mirada del tigre, tío. La mirada del tigre. Vamos.

-- Fragmento de la película Rocky III

Aunque no sabemos medir la productividad (como te contaré más adelante,


allá por la pág.169), entendemos que un equipo “feliz” es más productivo, o
que con la felicidad, motivación, es más fácil retener talento o atraerlo, o
generar buenas ideas para el negocio y, quizá por ello, está de moda medir y
“gestionar” la felicidad.

Aunque hay muchas razones para perseguir la felicidad en el trabajo,


extensible a la vida fuera de él, según (Leber, 2014) las personas más felices
son aproximadamente un 12% más productivas, yo creo que se quedaron
cortos con el 12%... muy cortos. En trabajos de carácter intelectual, esto tiene
bastante lógica, aunque solemos darle muy poca importancia.

La “mirada del tigre” es esa que tienen aquellos que se comen los proyectos,
libros, etc., no falla, esos se salen con la suya.

65
Y dista mucho de la mirada de la “cebra vieja”, mucho más típica de
encontrar, sin duda, y por desgracia, que la del tigre. La de la cebra vieja, es
la de “todo me molesta”, “si esto no va a funcionar”, “si esto no vale para
nada”, “si no tengo tiempo”, “si es que…”, “si es que siempre lo hemos hecho
así, para qué cambiar”, etc.

No falla, no he visto jamás a una persona o equipo triunfar, o estar por encima
de la media, con la mirada de una cebra vieja, sin motivación. Lo más que
esperan es pasear tranquilamente por el Serengueti, dejando el tiempo pasar y
pasar, sin preocupaciones, sin retos.

66
67
3.1 TEORÍA X E Y

Han pasado un montón de años desde que McGregor publicó el popular


artículo “The Human Side of Enterprise” (McGregor, 1957). El tema que
trata el artículo es antiguo y altamente interesante en lo que se refiere a
motivación, auto-organización, llámalo equipos ágiles o peopleware. A mí me
lo contaron en la universidad, pero hasta hace unos años no logré verle el
sentido y aplicación.

McGregor hablaba de dos maneras de ver la motivación, las llamadas “Teoría


X” y “Teoría Y”. Vamos a ello...

3.1.1 LA TEORÍA X

La Teoría X, por desgracia, te va a sonar. Habla de aquellas organizaciones


que piensan que sin la intervención activa de la gerencia (el management),
las personas serían pasivas, incluso resistentes, a la hora de trabajar. Y por
ello, la gestión debe basarse en persuadir, recompensar, castigar, controlar, etc.

Según esta teoría, el hombre corriente, por naturaleza, trabaja lo mínimo, le


falta ambición, no le gusta la responsabilidad y prefiere ser dirigido (te puede
sonar a las tribus nivel 2, que vimos en “Tribus”, pág.48).

Comenta McGregor que no está claro el origen de los anteriores pensamientos,


pero, como luego voy a ir contando, se sabe que NO tienen un origen en la
naturaleza innata de las personas y que viene más de la organización y
gestión industrial (otra vez los problemas de la herencia de la
industrialización).

68
3.1.2 LA MOTIVACIÓN, LOS DESEOS Y LA PIRÁMIDE DE MASLOW

McGregor tira de las ideas de su amigo Maslow (que te debe sonar de la


famosa pirámide de Maslow) para empezar a rebatir la Teoría X y habla de que
el hombre siempre desea algo, tan pronto como una de sus necesidades está
satisfecha, otra aparece en su lugar. Este proceso es interminable, desde el
nacimiento hasta la muerte.

Y las necesidades del hombre están organizadas en una serie de niveles,


formando una pirámide (la pirámide de Maslow), representando una
jerarquía de importancia, en la que en el nivel más bajo están las necesidades
fisiológicas como alimentación, seguridad, descansar, etc.

Cuando las necesidades básicas están satisfechas por el hombre, y ya no tiene


miedo de su bienestar físico, sus necesidades sociales se convierten en
importantes motivadores de su comportamiento: pertenecer a un grupo, ser
aceptado por sus semejantes, dar y recibir amistad y amor, realización, etc.

Muchos managers olvidan satisfacer o, mejor dicho, poner las bases para que
se pueda lograr satisfacer las necesidades sociales. Incluso llegan a ver mal
que se satisfagan necesidades sociales en el trabajo.

3.1.3 PASARLO BIEN EN EL TRABAJO... ¿ES MALO?

No sé si has hecho el siguiente experimento alguna vez… haz o vuelve a hacer


lo siguiente: ves preguntando por ahí a amigos, compañeros, al primero que te
encuentres, aquello de “¿qué tal la semana?” o “¿cómo ha ido el trabajo?”.

Cuenta cuántos te dicen algo diferente a.. “uf, menuda semana”,


“sobreviviendo”, “currando, es lo que hay, no queda otra”. Cuenta cuántos te
dicen algo del tipo a “esta semana me lo he pasado genial”, “no veas que bien
lo hemos pasado en el trabajo” o similares.

69
Si te pasa como a mí, y la cuenta te sale que prácticamente el 100% de las
respuestas son del tipo “uf, menuda semana”, a mí se me ocurren dos cosas.
Una, que vaya pena de sitios en los que trabajamos. ¿Vas a trabajar así hasta
los 70 (o más), casi 12 meses cada año? ¿has hecho la cuenta de cuantos días
de tu vida vas a pasar en malos trabajos?

Y dos, que creo que hay un porcentaje de gente, menor, lo reconozco, que,
aunque no lo haya pasado mal en el trabajo, socialmente, por instinto (a mí
me pasa) no puede decir otra cosa que no sea que “esta semana ha sido lo peor”,
decir que “estos días lo he pasado genial” suena raro, suena a que entonces no
has trabajado. Por defecto decimos que lo pasamos mal en el trabajo, decir que
lo pasas bien... suena raro.

No te puedo regalar una fórmula mágica para cambiar el pensamiento


anterior. Pero sí sé lo que yo quiero hacer, cosa que por cierto ya empecé a hacer
hace unos años, pero que quiero hacer con más fuerza: quiero que la mayoría
de mis días de trabajo y de la gente que trabaje conmigo sean tan duros (en
esfuerzo por lograr nuestros objetivos) como divertidos.

70
“En algún lugar profundo de nuestra memoria ancestral se esconde la idea de que el trabajo
se supone que es molesto (oneroso). Si te gusta hacer algo, eso no es realmente trabajo. Si te
gusta lo suficiente, probablemente sea pecado. Por cierto, no deberías cobrar por ello. Lo que
realmente deberías hacer es encontrar otra cosa en la que trabajar, algo que parezca un
trabajo. Entonces puedes ser un aburrido, un cansado y generalmente un miserable como
todos los demás.

Si eres un gerente, esta memoria ancestral te pedirá que te asegures de que tu gente nunca
se divierta en el trabajo. Cualquier evidencia de placer o alegría en el lugar de trabajo es un
signo seguro de que algún manager no está haciendo su trabajo. El trabajo no está siendo
realizado con el máximo de eficiencia por parte de los trabajadores, sino no deberían tener
buenos momentos.

Por supuesto, nadie dice abiertamente que el trabajo no debe ser divertido, pero la idea está
ahí, grabada a fuego en nuestro subconsciente cultural. Resulta que en la timidez nos
sentimos culpables si alguna vez nos pillan riendo haciendo una tarea. Ello resulta en la
aceptación del código de vestimenta, del código anti-palomitas de maíz, y en la actitud del
ceño fruncido, que distingue a los llamados profesionales de las personas que están
disfrutando de sí mismos.”

-- Peopleware, año… 1987.

3.1.4 UNA NECESIDAD SATISFECHA YA NO MOTIVA

McGregor pone el ejemplo de respirar aire, a menos que se te prive de ello,


respirar (aun estando en la base de las necesidades de las personas, en la base
de la pirámide de Maslow) ya no tiene un efecto motivador.

71
Así, cuando las necesidades fisiológicas están razonablemente satisfechas,
las necesidades en el siguiente nivel superior comienzan a dominar el
comportamiento del hombre, para motivarlo, o frustrarlo por no lograrlas.

Por encima de las necesidades sociales, aún están las llamadas necesidades
egoístas, que son de dos tipos:

• Autoestima, necesidades de confianza en sí mismo.

• Reputación, estatus, reconocimiento, etc.

A diferencia de las necesidades más básicas, las egoístas nunca se resuelven.


Se logra una y aparece otra. Hay una búsqueda interminable de las mismas.
Pero recuerda, esta búsqueda interminable no aparece hasta que las
necesidades físicas y sociales han sido satisfechas.

Una organización gestionada al modo industrial, con grandes jerarquías,


con una separación entre los que “piensan” y los que “hacen” (típica en
modelos cascada, industriales, arquitectura, etc.), da pocas oportunidades a
los que allí trabajan de satisfacer las necesidades egoístas y sociales.

Las carencias en necesidades fisiológicas, y los efectos que ello tiene en el


comportamiento, son notablemente más visibles que las carencias en
necesidades de niveles superiores. Pero, igualmente, si alguien tiene
necesidades de realización, sociales, reconocimiento, etc., frustradas… ello
también tendrá consecuencias en su comportamiento.

Comportamientos como la pasividad, hostilidad, o la negativa a aceptar la


responsabilidad no están en la “naturaleza humana”, son síntomas de la
privación de poder lograr necesidades sociales y egoístas.

72
Pero recuerda: un nivel de necesidades satisfecho ya no motiva, y sin embargo
la gerencia a menudo se pregunta “¿por qué la gente no está más motivada? si
pagamos buenos salarios, proveemos buenas condiciones de trabajo, etc.”. Y lo
que pasa es que una vez satisfechas esas necesidades fisiológicas y de
seguridad (con sueldos, espacios, etc.) la motivación se ha desplazado hacia lo
social y tal vez hacia necesidades egoístas. Y aparecerá la desmotivación a
menos que haya oportunidades en el trabajo para satisfacer estos niveles más
altos de motivación.

Pero si la gerencia sigue centrando su atención en las necesidades


fisiológicas… no cambiará nada.

3.1.5 LOS GESTORES PUEDEN SATISFACER NECESIDADES


SOCIALES O EGOÍSTAS... INDIRECTAMENTE

Los medios para satisfacer necesidades fisiológicas y de seguridad pueden ser


proporcionados por la dirección, de hecho (salvo en contrataciones
infrahumanas) un contrato decente en sí mismo es un medio para ello:
salario, condiciones de trabajo y beneficios sociales. Pero no funcionan, en
absoluto, a la hora de motivar en el nivel social o egoísta.

Y, además, la gerencia no puede directamente proporcionar a una persona


autoestima, o el respeto de sus compañeros, o la auto-realización. Sólo puede
crear las condiciones que le alienten y le permitan buscar tales satisfacciones
a él mismo… o puede frustrarlo al no crear esas condiciones.

Lo que le pasa a mucha gente hoy es que trabaja en organizaciones Teoría X,


modelo industrial, y tiene que buscar la satisfacción de sus necesidades
sociales o egoístas fuera del trabajo, lo cual nos lleva a organizaciones con
tribus nivel 2.

73
Curiosamente, la gerencia, al hacer posible la satisfacción de las necesidades
de nivel más bajo se ve privada a sí misma de la capacidad de motivar de la
misma manera, usando los mismos elementos, porque ahora la motivación ha
subido un escalón.

3.1.6 TEORÍA Y

Bueno, después de todo este rollo aparece como alternativa la “Teoría Y”, que
dice:

• Que la gerencia es responsable de satisfacer las necesidades


económicas, materiales, etc. (el nivel básico).

• Que la gente no es por naturaleza pasiva. Si lo son es por sus


experiencias en la organización.

• La tarea esencial de la dirección es organizar las condiciones y


métodos para que la gente pueda lograr sus propios objetivos de
motivación sociales o egoístas.

Y todo esto no rebaja el papel de la gerencia, al revés, lo sofistica. La Teoría X


confía exclusivamente en el control externo del comportamiento humano,
mientras que la Teoría Y depende en gran medida del autocontrol y la
autodirección.

¿Ideas que encajan con la teoría Y? Seguro que muchas… te irán sonando a
“ equipos ágiles”:

• Descentralizar y delegar, poder auto-organizarse, asumir


responsabilidad, etc., lo cual ayuda a satisfacer las necesidades

74
egoístas. Las organizaciones más planas fuerzan a esto, a que cada
uno se auto-gestione.

• La aceptación de responsabilidad por parte de todos.

• Participación y gestión consultiva. Tener voz en las decisiones que


nos afectan, lo cual ayuda a las necesidades sociales y egoístas.

• Evaluaciones del rendimiento, no en modo Teoría X, sino dejando que


las personas tengan responsabilidad en la planificación y evaluación
de su propio rendimiento.

75
76
3.2 LA MOTIVACIÓN INTRÍNSECA

A parte de las experiencias propias de cada uno, se han realizado muchas


investigaciones sobre qué motiva a un equipo.

Por ejemplo, una de las más famosas es la de un profesor de psicología de la


Universidad de Wisconsin, Harry F. Harlow, que, en la década de 1940,
estableció uno de los primeros laboratorios del mundo para estudiar el
comportamiento de los primates (lo cual, desgraciadamente, le hizo famoso…
por los éticamente cuestionables experimentos que realizó con los monos).

En lo que aquí nos interesa, Harlow ideó un sencillo rompecabezas mecánico


que consistía en abrir una tapa y para ello los monos tenían que extraer un
pasador vertical, quitar un gancho y levantar la tapa.

Los científicos colocaron los rompecabezas en las jaulas de los monos para
observar cómo reaccionaban. Y, casi de inmediato, algo extraño sucedió.
Espontáneamente, sin estímulo o insistencia exterior, los monos comenzaron
a jugar con los rompecabezas e incluso disfrutaban con ello. En poco tiempo,
comenzaron a averiguar cómo funcionaba el artilugio. Y nadie los había
recompensado con comida, afecto o aplausos.

Hasta entonces, los científicos sabían que había dos maneras de provocar el
comportamiento. La primera, el impulso biológico: los seres humanos y otros
animales comen para saciar su hambre, beben para saciar su sed, etc. Pero este
no era el caso. La segunda y única otra manera conocida de incitar un
comportamiento eran los premios y castigos.

Para responder a la pregunta, Harlow ideó una nueva teoría, una tercera vía:
“el cumplimiento de la misión”, que proporciona recompensa intrínseca. Los

77
monos resuelven los rompecabezas simplemente porque… les resultaba
gratificante. La alegría de superar la tarea era su propia recompensa.

La idea era radical, pero lo que pasó después aumentó la confusión y


controversia. Harlow pensó que lo que él llamó “motivación intrínseca”,
seguramente, estaría subordinada a las otras dos vías de incitar para hacer
algo. Y, siendo así, los monos recompensados con comida a la hora de resolver
los rompecabezas... realizarían la tarea aún mejor.

Sin embargo, cuando Harlow probó este enfoque, los monos en realidad
cometieron más errores y resolvieron los rompecabezas con menos frecuencia.
La introducción de recompensas alteró el rendimiento negativamente.

Según lo anterior, la tercera manera de motivar, la intrínseca, era tan o más


fuerte que las otras.

La noción de esta tercera vía apenas se estudió hasta que otro científico,
Edward Deci, retomó las investigaciones de Harlow.

3.3 LAS RECOMPENSAS PUEDEN DESMOTIVAR

“Tenemos empleos que odiamos para comprar cosas que no necesitamos.”

-- Fragmento de El Club de la Lucha

En 1969, Edward Deci, estudiante de psicología de la Universidad Carnegie


Mellon, buscando tema de tesis, se sintió intrigado por la “motivación” y
empezó a estudiar las estrategias Harlow.

Deci eligió para su experimento el cubo de Soma, un rompecabezas geométrico,


con siete piezas distintas formadas con cubos que hay que unir para

78
conseguir un cubo mayor, y que permite ensamblar las piezas en millones de
combinaciones posibles, creando múltiples formas.

En su experimento, Deci dividió los participantes, estudiantes universitarios,


en un grupo experimental (Grupo A) y un grupo control (Grupo B). Cada
participante entró en una habitación y se sentó en una mesa sobre la cual
estaban las siete piezas del cubo de Soma y dibujos de tres configuraciones del
rompecabezas.

Hubo tres sesiones. En la primera sesión, los miembros de ambos grupos


tuvieron que ensamblar las piezas para replicar las imágenes. En la segunda
sesión, hicieron lo mismo con dibujos diferentes, pero esta vez Deci dijo al
Grupo A que les pagaría por cada construcción con éxito, el grupo B, por su
parte, quedó sin recompensa.

En la primera sesión, como es lógico, no hubo mucha diferencia entre lo que


los participantes del grupo A y B hicieron. En la segunda sesión, el grupo al
que se le pagaba aumentó el interés y superó al no remunerado.

Sin embargo, en la tercera sesión Deci dijo a los participantes del Grupo A que
ya no había suficiente dinero para pagarles y que esta tercera sesión sería no
remunerada. Y los sujetos del grupo A, que previamente habían sido pagados,
respondieron de manera diferente. Ahora pasaron significativamente menos
tiempo jugando con los rompecabezas, menos que en la primera, cuando no se
les pagaba.

“Cuando el dinero se utiliza como recompensa externa los sujetos pierden el


interés intrínseco de la actividad”, escribió Deci. Las recompensas pueden
ofrecer un breve refuerzo, como la sacudida de la cafeína que te mantiene
durante unas horas más. Pero el efecto desaparece, y peor aún, puede reducir a
largo plazo la motivación de una persona para continuar el proyecto.

79
Deci señaló que los seres humanos tienen una “tendencia inherente a buscar
la novedad y los desafíos, para extender y ejercer sus capacidades, para
explorar y aprender”. “Pero esta tercera vía es más frágil que las otras dos y
necesita el entorno adecuado para sobrevivir”.

Otras investigaciones, como Punished by Rewards (Kohn, 1999), han


revelado algo tan de sentido común como que los incentivos externos
(típicamente el dinero), como forma de recompensa, funcionan al revés de
cómo se esperan, matan la motivación intrínseca de las personas (el
comportamiento que sale desde el interior de una persona por iniciativa
propia).

En inglés, a esto se le llama overjustification effect, es decir, en lugar de hacer


las cosas por el propio placer de hacerlas, se hacen con el objetivo de conseguir la
recompensa.

Como estamos viendo, las recompensas tienen sus cosas buenas y sus cosas
malas, como la de trabajar solo con el objetivo de obtener cada vez una
recompensa. Y por eso son unas de las herramientas más complicadas y
menos comprendidas en la gestión.

Y las recompensas pueden transformar una tarea interesante en algo


monótono. Y disminuir la motivación intrínseca, mermando el rendimiento.

Sino... ¿cómo se explica que proyectos de software libre, proyectos colaborativos,


proyectos sin remuneración, escribir frecuentemente en un blog, etc., superen
a proyectos de presupuestos millonarios?

Si quieres profundizar en el tema, te recomiendo que leas a (Pink, 2011),


merece la pena.

80
3.4 REGLAS PARA EL BUEN USO DE RECOMPENSAS

El tema de recompensar no es algo trivial, es algo potente, pero requiere


profundizar sobre ello. Aquí te dejo 6 buenas prácticas para recompensar a los
miembros de los equipos, para interiorizarlas (Appelo, 2016):

1- No prometas todas las recompensas por adelantado. Recompensa en


momentos inesperados.

2- Las pequeñas recompensas son más efectivas para fomentar las


ganas de trabajar y pueden darse de manera más frecuente.

3- Recompensa de forma continua, no solo una vez. No busques una


recompensa puntual.… cada día puede ser un buen día para celebrar
algo.

4- Recompensa en público, no en privado. El objetivo de dar recompensas


es reconocer buenas prácticas y que la gente disfrute de su trabajo y
de manera pública puede funcionar mejor que de manera privada.

5- Recompensa el comportamiento, no el resultado. Recompensa la buena


conducta, si solo te centras en los resultados… puedes generar una
cultura peligrosa.

6- Fomenta que haya recompensas entre compañeros, no sólo para los


subordinados.

Seguir estas reglas, a la hora de recompensar, da la oportunidad de aumentar


el rendimiento de las personas y el disfrute en el trabajo, fomentando la
motivación intrínseca. Y una manera de potenciar las recompensas es con los
Kudos...

81
3.5 PRÁCTICA DE MANAGEMENT 3.0: KUDO BOX

“Cinco manos, casi congeladas, sujetaron el mástil desplegando la bandera al aire, y lo plantaron, como
los primeros en llegar al polo sur geográfico”, escribió Amundsen. Aquello tenía que realizarse entre
todos. “Todos los que habían arriesgado sus vidas en el esfuerzo y habían permanecidos juntos”.

-- Amundsen, en la conquista del polo Sur

Los Kudos, o la Kudo Box, son un método para dar un reconocimiento a


alguien, normalmente por escrito y de manera pública, lo que potencia la
motivación intrínseca, siendo una práctica sencilla y eficaz, que cumple con
las 6 reglas para dar recompensas.

Este método consiste en instalar una caja (hay quien usa la pared para pegar
los Kudos, en vez de la caja), la Kudo Box, que permite a los miembros del
grupo dejar en la misma una pequeña recompensa, bien sean pequeños
obsequios, notas de agradecimiento o de reconocimiento del esfuerzo y el
trabajo, etc.

82
El nombre de este método viene de Paul Klipo, el ex presidente de Lunar Lógica
Polska en Polonia. En ella, sus empleados podían dar a sus compañeros un
regalo por valor de 20€. Lo llamaron Kudos y consistía en una caja en la que
podían dejar esa recompensa cuando alguien en la compañía sentía que otro
merecía una recompensa.

De esta manera, los Kudos son recompensas públicas (una de las 6 reglas que
vimos). Todos los miembros del equipo participan en esta iniciativa. Todo esto
resulta en un potente sistema de recompensas de bajo coste.

Un sistema similar, llamado Love Machine (hacer a los empleados felices), fue
implantado por Philip Rosedale, ex director ejecutivo de Linen Lab. Este
sistema permitía a los miembros del grupo enviar notas de agradecimiento a
sus compañeros, de forma muy similar al sistema Kudo Box.

Hay otros nombres para este sistema como HERO awards en Zappos y que
funciona de manera similar a los anteriores.

No importa el nombre, todos ellos son sistemas que permiten a la gente darse
entre ellos pequeños obsequios inesperados de agradecimiento por un trabajo y
además también permite a la persona apreciar el cumplido, y eso, también
tiene valor.

83
3.5.1 PERO CUIDADO CON LOS KUDOS

Si nunca nadie te recompensa, te felicita por algo o te da un Kudo, no habrá


una acción motivadora. Sin embargo, después de incorporar esta práctica,
desmotiva mucho que recompensen, feliciten o den a otro un Kudo y a ti no,
por un trabajo que, por ejemplo, hicisteis ambos o que nació de una idea tuya.

Antes del uso de los Kudos, en esa situación, no había una herramienta
pensada para motivar… pero ahora hay un arma que puede usarse,
inconsciente o conscientemente, para desmotivar.

84
Y si el receptor del Kudo no reconoce a su vez que realmente es de él, pero
también es en parte tuyo, no solo hay un efecto desmotivador… sino que
además aparecen resquemores.

Siempre es mejor dar Kudos por exceso que por defecto, pero también darlos a
gente que no hizo nada… vuelve a minar la moral de los que si hacen. ¡Qué
complicada una cosa tan aparentemente simple!

Hasta el punto de que, en ambientes hostiles, como el que vivió Mr. Nobody,
había quien daba Kudos a unos para explícitamente “castigar” a otros, a los
que no los recibían y habían participado en el éxito. No hacer uso de ellos no
era lo mejor, pero el mal uso de los mismos creó una situación peor que la de no
tenerlos.

Mr. Nobody me contó que incluso en su organización, después de que


algunos se sintieran heridos por no recibir Kudos de trabajos exitosos en los
que habían participado de alguna manera, quizá tiempo atrás, quizá en su
concepción inicial, hubo quien dio un “salto armamentístico” superior y creó
el “Auto-Kudo”. “Como no me dieron un Kudo por un trabajo del que yo fui
parte, se lo dieron a otro y el felicitado tampoco se acuerda de reconocer mi
participación, me doy yo, explícitamente y en voz alta, un Auto-Kudo”.

Y puestos a inventar, después de lo anterior, como a alguien no se le iba a


ocurrir un “arma de destrucción masiva”, una “Estrella de la Muerte”… el
Anti-Kudo, una manera de explícitamente señalar a alguien por algo que otro
considera que no fue una buena acción.

Ojo, no trivialices ni subestimes el poder de ciertas ideas aparentemente


sencillas y de imagen feliz, los cambios son complicados y hay que saber
mucho, conocer la cultura de un lugar, trabajarla previamente, antes de poner
ideas alegremente en circulación.

85
3.6 ¿QUÉ MOTIVA INTRÍNSECAMENTE?

Harry F. Harlow comprobó que la motivación intrínseca, la que sale de dentro,


frente a la externa, como pagar a alguien por algo, es una de las maneras más
eficaces de que una persona esté motivada.

Pero ¿qué motiva intrínsecamente a alguien? Hay un montón de autores que


han elaborado listas sobre lo que motiva intrínsecamente. Quizás los más
destacados sean (Deci & Ryan, 2002) y (Reiss, 2000). También (Appelo,
2016) elaboró una lista de motivadores intrínsecos (bajo el Management 3.0
la puedes encontrar como la práctica de Moving Motivators).

En muchas ocasiones hago con los equipos un taller de “qué nos motiva a
cada uno”. Si creemos firmemente que la motivación es importante... ¿no
merece la pena poner en común qué nos motiva a cada uno? Así evitamos dar
por hechas generalidades, o que los managers asuman que al equipo le motiva
lo mismo que a ellos.

Para el taller de motivación he probado diferentes dinámicas y con diferentes


listas de factores de motivación, con la idea de que cada uno seleccione los
factores que más le motivan, y los que menos, para una posterior puesta en
común.

A continuación, te voy a dejar los 7 factores que yo uso. Si haces este taller,
obviamente, puedes poner o quitar, pero después de muchas pruebas a mí estos
me van muy bien. He evitado listas muy largas porque nos perdíamos en
debates “etimológicos”, de hecho, la siguiente simplifica aún más los Moving
Motivators de Management 3.0, agrupando muchos de los factores de dicha
lista (para aligerar el taller y evitar debates de si esta palabra, este motivador,
es similar a este otro y “no sé cuál escoger”).

86
87
3.6.1 ADQUIRIR CONOCIMIENTO Y/O LA CURIOSIDAD

El aprender motiva a la gente y la gente con conocimiento atrae. Ayudar a las


personas a aumentar su conocimiento es para algunos un factor de
motivación.

La curiosidad, conocer cosas nuevas, buscar y absorber información… motiva.

Puedes hacer uso de la curiosidad para motivar, despertando la curiosidad


hacia ti, o hacia tu proyecto o empresa. De hecho, Seth Godin elaboró una teoría
llamada el “principio contrario” (Godin, 2009) y que junto con otras
investigaciones, como por ejemplo la de (Pink, 2012), afirman que ser
diferente a los demás despierta la curiosidad, lo que aumenta el interés hacia
ti, o hacia tu proyecto o tu empresa.

Si quieres que la gente se interese en una idea, que le motive, tiene que ser lo
suficientemente diferente como para hacerse notar. De esta manera, la gente se
verá intrigada por la idea, despertará su curiosidad.

Ejemplo práctico: el nombre que le dimos a 233 Grados de TI, ¿un nombre que
empieza por número? ¿qué significa 233 Grados de TI?, siempre hay alguien
que lo pregunta.

3.6.2 HONRA, HONOR Y LEALTAD

Entornos de honradez, de respeto moral y de la dignidad. Las acciones y los


entornos honorables motivan y generan una gran confianza. La confianza
es clave para mantener una buena relación con los clientes, proveedores,
compañeros, etc.

88
El honor atrae a cierta gente y crea lealtad. Como dice (Cialdini, 2006), la
gente por lo general se siente obligada a devolver favores, regalos,
invitaciones… ya que es lo más honorable.

Muchas empresas utilizan este factor para motivar a la gente a comprar. Y lo


hacen, por ejemplo, regalando cosas (libros, webinars, etc.), y luego ofrecer
servicios adicionales de pago basándose en la idea de que la mayoría de la
gente tiene la necesidad de “pagar los favores”.

3.6.3 LIBERTAD, INDEPENDENCIA, AUTONOMÍA

Hay a quien le motiva la libertad, tomar sus propias decisiones, que le dejen a
su aire, que elija su horario, etc. Gran cantidad de empresas de hoy en día, que
generalmente no son aquellas bajo el patrón Troglodita Management, hacen
uso de este factor de motivación, con horarios abiertos, zonas de relax a las que
puedes ir cuando quieras, etc.

Claro que en el mundo del Troglodita Management hay varios ejemplos de


cómo destruir este factor de motivación, véanse los sistemas de fichar… que sí,
que aún existen.

3.6.4 PODER Y/O ESTATUS

Hay gente a la que le motiva el poder. Cargos, títulos, puestos, etc., son típicas
representaciones de poder e influencia que motivan a muchos.

Un ejemplo práctico de motivación por poder se da cuando, frente a la figura de


un único jefe de proyectos que toma todas las decisiones, se delega poder de
decisión a los miembros del equipo.

También hay a quien le motiva el estatus. Elevar su condición social, con


títulos, premios, certificaciones, referencias, acreditaciones, etc.

89
Una manera de motivar en este sentido es usar símbolos o etiquetas que
representan el estatus, como se hace en la “gamificación”, otorgar premios
públicamente, etiquetar a alguien como senior o similares.

En algunos lugares, por el cambio a equipos ágiles, se reducen las jerarquías,


este es un punto a tratar, ya que al reducirse las opciones de aumentar poder y
estatus vía ascenso en la jerarquía hay quien ve mermado este factor de
motivación como opción de futuro.

3.6.5 RELACIONES

El establecer relaciones motiva, abrirnos como personas, darnos a conocer,


conocer la vida personal más allá de la profesional, etc., ayuda creando mayor
confianza, dando lugar a una mejor relación.

Las personas se sienten más conectadas cuando tienen un acercamiento más


personal entre ellas. Muchos nos relacionamos mejor cuando nos abrimos a los
demás.

Muchas empresas de hoy en día hacen uso de este factor, planificando


actividades que mejoren las relaciones, after works, salidas, comidas, etc.

En este sentido podríamos citar aquí al llamado “principio de asociación”.


Según (Cialdini, 2006), las personas están ansiosas de asociarse a los éxitos
de otros. Cuando las personas se sienten conectados con los logros de los
demás, aunque sea de una manera superficial, piensan que su imagen
pública se fortalece y se sienten más aceptados por el grupo.

3.6.6 ORDEN

Aquí hablamos de predictibilidad, de la necesidad de la gente de tener un


camino claro.

90
Esto es un problema porque vivimos en un mundo adaptativo complejo en el
que ningún camino es seguro. Nada es predecible. Y, desafortunadamente, el
mensaje de que los cambios no tienen un camino predecible no le gusta a todo
el mundo.

A quien le motiva este punto del “orden” suele buscar simplicidad, claridad y
una ruta clara.

3.6.7 OBJETIVO Y PROPÓSITO

Tener un gran objetivo, luchar por una causa, un objetivo noble… motiva.
Ejemplo: “Cambiar el mundo del software, erradicando las viejas y anticuadas
prácticas de gestión que aún nos asolan”. Trabajar por una potente visión nos
motiva a muchos.

Misión es lo que quieres para ti, y la visión es lo que quieres para los demás,
lo que quieres que ocurra más allá de los muros de tu equipo u organización
(Mejide, 2014).

Y a toda visión le corresponde una causa. Si quieres conseguir algo para los
demás, normalmente deberás conseguir vencer a aquello que les impide
conseguirlo por sí mismos. Porque si no, no te necesitarán para alcanzarlo. Si
te necesitan, es porque hay un impedimento. Hay un enemigo contra el que
luchar. Puede ser un enemigo enorme, como “cambiar las prácticas herencia de
la industrialización en el mundo del software”.

Está bien que nunca alcances tu objetivo. No te desesperes si eso ocurre, porque
los grandes objetivos son como el horizonte: por mucho que camines siempre se
alejan. Pero para eso sirven, precisamente... para caminar.

Ejemplo, en Visual MS, una muy interesante empresa de Vigo, ganadora del
Best Workplace 2017 por la Great Place To Work, tienen una visión, un

91
objetivo realmente emotivo y potente: “lograr que la empresa supere los 100
años de existencia”.

Piensa que las empresas y los proyectos no unen a los equipos… los juntan.
Los reúnen bajo un mismo techo (y a veces ni eso), bajo un mismo nombre de
empresa (el cual muchas veces a pocos les importa). Lo que une mucho a los
miembros de un equipo son las causas y luchar por ellas, si estas existen.

De todos mis trabajos, proyectos y dedicaciones, solo puedo recordar verdaderas


situaciones de unión con los miembros del equipo cuando hubo alguna causa
común por la que luchar.

Una cosa que es típica en un gran equipo es la búsqueda de un objetivo


común, compartido, un objetivo de equipo. Pero, ojo, los equipos no alcanzan
objetivos, son las personas de los equipos las que logran objetivos, si hay un
objetivo de equipo fuerte es porque hay una suma de objetivos personales
fuerte.

La mayor parte del trabajo es realizado por personas individualmente, aun


así, los equipos son importantes, no solo por la colaboración a la hora de
terminar cosas, sinergias, etc., sino también porque sirven como un
“dispositivo” para alinear objetivos.

En la gestión tradicional aquí es donde puede aparecer el error… a algunos


gerentes les resulta incómodo hacer algo por lograr que los trabajadores, cada
miembro del equipo, persiga los objetivos corporativos y los haga suyos… “los
profesionales deben aceptar los objetivos, para eso se les paga”. Y creer que los
trabajadores aceptarán automáticamente los objetivos de la organización es un
signo de ingenuidad gerencial. El mecanismo por el cual los individuos se
involucran en los objetivos de la organización es complejo.

92
Piensa que, quizás como manager, probablemente, hayas aceptado el objetivo
corporativo de terminar un proyecto en fecha y presupuesto, y lo hayas
interiorizado. Pero… ¿esa interiorización del objetivo es solo profesional o hay
algo personal? ¿puede que cumplir el objetivo te lleve a una mayor presencia en
la empresa? ¿más autoridad? ¿cumplimiento de objetivos económicos? Puede
que el objetivo corporativo haya coincidido con uno personal.

En los rangos superiores de una organización, típicamente, está muy


trabajado el que cada gerente tenga un fuerte incentivo personal para aceptar
los objetivos corporativos. Pero… ¿se trabaja lo mismo en la parte inferior? Allí
donde se realiza el trabajo real falla ese engranaje de alinear objetivos, allí
muchos piden “profesionalismo”.

Como líder trabaja activamente el alineamiento de objetivos, objetivos


personales y esa suma que forma el objetivo del equipo.

3.7 PRÁCTICA: CALENDARIOS NIKO-NIKO

Hay equipos que utilizan (nosotros lo hacemos desde hace años) el llamado
calendario Niko-Niko (en japonés sonreír), también conocido como calendario
de la felicidad o índice de la felicidad.

Hay empresas que van más allá y consideran el índice de la felicidad como
un parámetro más importante que los financieros (Kniberg, 2010).

93
Hay muchas maneras de hacerlo, nosotros ponemos en un calendario una
“carita” al final del día indicando cuál ha sido nuestro estado de ánimo. Las
caras pueden ser felices, indiferentes o tristes. Para que sea más visual, se
suele asociar un color distinto a cada carita, como el verde para feliz y rojo
para triste.

A la hora de rellenarlo, aparte de problemas relacionados con el trabajo,


nosotros también consideramos problemas ajenos que pueden causar estar poco
motivado ese día.

Cuando una cara sale azul o roja, en ese momento comentamos la situación.
Si no hay confianza y transparencia este método no vale para nada,
ahórratelo. Si alguien piensa que por poner una cara roja el resto lo va a mirar

94
mal, algún jefe le va a echar la bronca, etc., mejor utiliza el papel del
calendario para subir la altura del monitor.

Para que este método funcione, además de la confianza, el siguiente gran reto
es la constancia. Sé que, para muchas otras organizaciones, el principal reto
no es “pegar” los calendarios en la pared… es lograr que poner en ellos el estado
de ánimo sea un hábito y que no quede en una moda pasajera, de un mes. Mi
consejo para lograrlo es que: (a) todo el mundo crea en ello, (b) que los
primeros meses alguien se centre en recordar su uso y (c) hacer uso del papel
de toda la vida, pegándolos en un sitio que sea imposible no verlos.

Es una técnica tan simple como útil, que usan muchas organizaciones y de
la que puedes sacar variantes para eventos esporádicos o iniciativas, como, por
ejemplo, el Happiness Index (índice de la felicidad), que se usa para ver cómo
de satisfactoria está siendo una actividad, una iniciativa de cambio, etc. En
este caso cada uno puede votar de manera anónima, poniendo un “puntito”, en
cómo se ha sentido durante un periodo de tiempo (p. ej. en el último Sprint).

95
96
3.8 PRÁCTICA: CELEBRA ÉXITOS Y LA SPAGHETTI DINNER

Un manager debería “propiciar” (ojo con lo de propiciar) ocasiones en las que


fácilmente, y de manera frecuente, un equipo logre éxitos de manera
conjunta. Es decir, que el mánager no solo tendría que quedarse esperando a
ver si el éxito llega, en proyectos grandes quizá con demasiada poca
frecuencia, sino que, pro-activamente, debiera propiciar que lo más pronto, y
frecuentemente posible, ocurrieran situaciones de éxito en grupo.

Y debiera ponerle imaginación para ello, aunque sea generando situaciones


que, sin el ingenio del manager, podrían no haber ocurrido. Creando pequeñas
y frecuentes situaciones de éxito, que pueden venir de pequeñas tareas,
simulaciones, actividades, etc., cualquier cosa que se le ocurra para lograr un
resultado, exitoso, del trabajo en equipo.

Con el añadido, ojo, de que ese éxito debiera resultar del trabajo del grupo, y no
tanto de la gestión que pudiera hacer el manager. Él genera la situación, pero
la auto-organización del equipo lleva a la resolución exitosa.

La idea de esta antigua práctica viene a perseguir aquello de que “el éxito suele
llamar al éxito”, pretende que las estrategias de trabajo en grupo que han
logrado ese pequeño éxito se armonicen, éxito tras éxito, que la auto-
organización (de la que hablaremos en el siguiente capítulo) se vaya
engrasando.

Y para fomentar esta práctica, e incentivar la imaginación de los managers


(poco imaginativos), existe la Spaghetti Dinner (DeMarco & Lister, 1985),
cena de espaguetis, por si hacía falta traducción. Y que nosotros, te hablo de
233 Grados de TI, usamos frecuentemente, desde hace tiempo, pero llamándola
“233 Calorías” (aludiendo a que es una comida nada light).

97
La práctica de la Spaghetti Dinner consiste en propiciar una reunión
gastronómica con el equipo, pero no a la tradicional usanza, en la que,
típicamente, el manager elige el sitio para comer y, si te descuidas, hasta
puede elegir el menú. No, así no, así suena muy a comida Comand and
Control, no… lo que aquí se busca es potenciar la auto-organización.

En la Spaghetti Dinner el manager dice “el qué”, que hay que preparar una
comida o cena, y el equipo resuelve “el cómo”, cómo la hará y hacerla (sí,
implica cocinar en grupo). Esto puede ir desde decidir qué cenar, pasar por el
supermercado, cocinar y terminar recogiendo la mesa.

Antiguamente, había quien a la hora de realizar un proceso de selección


incluía una comida o una cena, entonces… ¿qué mejor y más ágil que un
Spaghetti Dinner? Si quieres saber si alguien va a encajar en el equipo,
organiza una y que colabore desde el supermercado hasta el postre. Te va a
resultar más informativo que un absurdo psicotécnico.

98
99
4. Auto-Organizado

Un virus está vivo. Tiene inteligencia. Eso no es inusual. Lo que es tan inusual aquí, con este virus, es
que los anfitriones infectados parecen estar comunicándose. Tiene alguna clase de mente colmena y está
conectando a todos los anfitriones.

-- Fragmento de la serie Stranger Things (2ª temporada)

La auto-organización es el proceso por el cual una estructura o patrón aparece


en un sistema sin una autoridad central o elemento externo que lo imponga
de manera planificada (Appelo, 2010).

La auto-organización es algo de lo más normal, es el comportamiento por


defecto en un sistema formado por átomos, virus, peces, pájaros, en la selva... y
en equipos software o similares.

Lo que limita la auto-organización es el entorno y las restricciones que le fija.


En la selva está limitada por restricciones como la que impone, por ejemplo, la
orografía.

Cuanto más complejo es un sistema (y un equipo software, o similar, lo es)


menos podemos controlarlo al detalle. Imagina controlar al detalle todo el
tráfico de un país o una ciudad... imposible. Para ello, la solución es delegar el
control, para poder controlar la complejidad del sistema.

Por ejemplo, los controladores de tráfico aéreo delegan control en los pilotos.
Las autoridades de tráfico fijan los límites y las restricciones en el código de
circulación, delegando el control en los automovilistas. Los mánager ponen
las restricciones y delegan control en los equipos.

101
Aquí aparece el concepto del manager como “jardinero”, que pone toda su
ayuda y soporte para que crezcan las plantas, las riega, compra la tierra, etc.,
pero las que finalmente crecen, y saben cómo hacerlo... son las propias
plantas.

Un equipo auto-organizado es un equipo dirigido y organizado por sus


propios miembros, para alcanzar los objetivos especificados por la gerencia,
dentro de las limitaciones de su entorno (Appleton, 2009):

• La gerencia puede dar forma y empujar al equipo y sus miembros,


pero la dirección no dicta los detalles de cuál es la solución ni el
proceso de cómo crearla.

• El equipo es responsable no solo de dirigir y organizarse para


alcanzar sus objetivos, sino también de controlarse y adaptarse para
corregir y mejorar su propio desempeño. Esto significa que el equipo
puede cambiar la forma en que se dirige y organiza, con el fin de
responder a las limitaciones de su entorno, lo que también implica
que…

• No existe un único “líder” del equipo durante la vida útil del equipo o
proyecto. El líder no es una asignación estática, sino más bien un
papel dinámico.

• Así que la persona que dirige el equipo en un momento dado puede


cambiar, dependiendo de la actividad o problema que se aborde en un
contexto o situación particular.

Un “equipo ágil” es (o se supone que debe ser) un equipo auto-organizado, que


se guía por los valores y principios ágiles (los del Manifiesto Ágil), por las

102
restricciones que pone la gerencia y que pone su mejor “cómo” para
implementar las soluciones que se le requieren.

“Yo, como mánager, no lidero el cambio, lo lideráis vosotros, el equipo, yo estoy


para proporcionar lo que necesitéis y que esto no se salga de unos límites”

Un gran ejemplo de líder que sí que entendía la auto-organización, lo viví


en una organización con la que colaboraba ayudándoles en su
transformación ágil. El directivo que desde dentro lideraba el cambio, en
una de las múltiples reuniones con los equipos para incorporar mejoras les
dijo: “Mi papel como líder del cambio ya ha terminado, ahora sois vosotros
los que lo lideráis y yo estoy para proporcionaros todo lo que necesitéis”

En un equipo ágil auto-organizado, los miembros deciden colectivamente y


hacen lo necesario con el fin de cumplir con los compromisos, valores y
objetivos.

Así, un equipo ágil auto-organizado es:

• Autónomo: No existe un único centro de toma de decisiones o de


autoridad. El control se distribuye conjuntamente por todo el equipo.

• Adaptable: El equipo se ajusta dinámicamente según sea necesario,


con el fin de resolver sus propios problemas y mejorar su propio
desempeño.

• Responsable: El equipo comparte colectivamente la responsabilidad de


los resultados.

103
4.1 MODELOS DE LIDERAZGO Y AUTO-ORGANIZACIÓN

Dicho lo anterior, te puedo asegurar por experiencia que la auto-organización


es de lo más difícil de entender, difícil de hacer crecer, pero, a la vez, es la clave
diferenciadora entre equipos buenos y equipos excelentes.

Una buena manera de que entiendas la idea de auto-organización es verla


desde varios enfoques. Veamos con más detalle diferentes filosofías de
liderazgo en equipos, comenzando por la menos auto-organizada y alejada de
la idea de auto-organización.

4.1.1 EL CONTROL Y MANDO

La tipología de equipo “control y mando”, desgraciadamente, es la más


ampliamente usada (es lo que más me encuentro). La idea es tener un grupo
de gestores que dan directrices a un grupo de trabajadores.

Los gestores piensan qué hacer y cómo (típicamente en reglas y metodologías)


y se lo transmiten al equipo, todo ello en un modelo jerarquizado. Una
estructura de trabajo muy en línea con la Teoría X, la típica del Taylorismo
(como vimos en la sección “Teoría X e Y”, pág.68).

Este tipo de gestión es otra herencia más de querer encajar el desarrollo


software o la creación de productos del conocimiento, en los modelos de gestión
herencia de la industrialización, como la construcción de casas, carreteras,
etc. De hecho, esto es un “invento” reciente, si lo comparamos con la auto-
organización (que viene de serie en la naturaleza).

Y viene muy de la mano del ciclo de vida en cascada. Por ejemplo, aquella
única fase de diseño en la que un grupo piensa y detalla el trabajo que hará
posteriormente otro grupo, los programadores, constructores, creadores, etc. Los

104
problemas de esta manera de gestionar se han tratado en numerosas
ocasiones.

Un primer problema de este modelo es que asume dar grandes directrices al


mismo tiempo a un gran número de personas y que todas las ejecuten. Pero la
creación de soluciones intelectuales requiere mucho más de “micro gestión”,
puede haber “órdenes” generales de alto nivel (las restricciones) pero tiene que
haber gestión también a nivel operativo, piensa que lo raro es que dos personas
hagan exactamente lo mismo.

Otro gran problema es que anula que el equipo sea parte de la gestión. En este
modelo el conocimiento necesario para tomar decisiones estratégicas está casi
exclusivamente en la gerencia, pero en disciplinas como el software, y
similares, la mayoría de las veces el que tiene más conocimiento (o
conocimiento útil al que sacar partido) es aquel que está “en el frente”. Por
ello, el conocimiento y la toma de decisiones debe fluir de arriba abajo y de
abajo arriba, no solo de arriba hacia abajo.

De ahí, que frente a este antiguo modelo surgieron otros, los que podemos
llamar “modelos de gestión ágiles”...

4.1.2 LÍDER SIRVIENTE, EL ANFITRIÓN Y EL INVITADO

“La auto-organización no puede ser una buena práctica, es la práctica por defecto de cualquier sistema,
incluyendo a los equipos”

-- Jurgen Appelo

El término “Líder Sirviente” (Servant Leader) se comenzó a usar para definir


el modelo de liderazgo de los roles clave en agilidad (Scrum Master, Product
Owner, etc.), con la idea de que la gerencia debía “servir” al equipo, estar a su

105
disposición para facilitar su trabajo. Esto le da la vuelta a la típica pirámide de
jerarquía, poniendo al gestor abajo y al equipo arriba.

Para algunas situaciones la metáfora del líder sirviente puede ser muy útil,
pero en ocasiones corremos el riesgo de que el equipo evite cualquier
responsabilidad de liderar, dejando toda la gestión al líder sirviente.

Para mejorar esta metáfora, apareció la del “Líder Anfitrión” (Host Leader).
Esta nueva metáfora o modelo de liderazgo surgió en 2014, a raíz de un libro
de liderazgo (no ágil, de liderazgo general) llamado Host – Six New Roles of
Engagement (McKergow & Bailey, 2014). Aquí los roles de gestión se ven
como un “anfitrión” (en vez de un sirviente) de una fiesta. Los anfitriones se
encargan de abrir la puerta, recibir a los invitados, crear un buen entorno, ser
parte del evento colaborando, decidir quién entra, etc.

los anfitriones tienen ciertos derechos: decidir quién viene a la fiesta, y quién
no, e incluso establecer una serie de normas y límites, asegurarse de que la
gente los cumpla y si no tomar acciones en consecuencia... como echar a
alguien de la fiesta por faltar el respeto a otra persona (ejemplo de acción de
mando y control, justificada por ser una actitud tóxica y que daña al resto
del equipo). Además, confían en que los invitados participarán y colaborarán
en el evento.

Pienso que la metáfora del anfitrión es mucho más rica que la del sirviente
más clara y sencilla de transmitir, ya que hay una mezcla de ayudar al
equipo, de demandar ciertas normas de civismo, de esperar la colaboración en
el equipo, y de autoridad en casos tóxicos que puedan dañar al resto.

En un curso que impartió Alistair Cockburn (uno de los firmantes del


Manifiesto Ágil) en Madrid, que organizamos desde 233 Grados de TI,
descubrí otra nueva metáfora para todo esto del liderazgo ágil y la auto-

106
organización, como extensión a la del líder anfitrión: el “Líder Invitado”
(Guest Leadership). En este caso hablamos de esa situación que ocurre cuando
un invitado nota que hay que hacer algo, participar, ayudar, etc., y
voluntariamente, sale de él, y se encarga de ello, en lugar de esperar a que el
anfitrión aparezca... en el equipo todos podemos ser líderes invitados cuando
la ocasión lo requiera.

107
108
4.1.3 LA ESCALERA DEL LIDERAZGO

La escalera del liderazgo es un modelo de David Marquet (Marquet, 2012)


para evaluar el tipo de liderazgo y auto-organización, que nos va a servir
(para mí ha sido muy útil) para reforzar la idea de auto-organización.

“Cuando le damos autoridad a las personas, creamos líderes”, comenta


Marquet, y propone un modelo de evaluación del liderazgo, así como una
“escalera”, tanto en el modelo de liderar como en el de tomar la iniciativa por
parte del equipo, basado en 7 niveles.

Lo interesante de este modelo es que define diferentes niveles, tanto para el


equipo como para el gestor, y los deja bastante claros con las frases que
propone para identificarlos. El nivel más bajo de la escalera es el menos auto-
organizado.

109
110
4.1.4 AUTONOMÍA DEL EQUIPO Y ALINEAMIENTO POR LA
DIRECCIÓN

Otra aproximación más. Henrik Kniberg, compartiendo el modelo de Spotify


(Kniberg, 2016), proponía una matriz, de dos dimensiones, interesante para
complementar ideas sobre auto-organización en el equipo y el papel del líder,
para situar qué tipo de liderazgo nos representa.

La matriz cruza el grado de autonomía del equipo (en qué grado decide el
cómo resolver las cosas) y el grado en el que la dirección deja claros los
objetivos (en qué grado queda claro qué hay que resolver).

Interesante en este caso destacar que cuando nos referimos a auto-


organización no solo hablamos de la autonomía del equipo, sino también de

111
alineamiento de objetivos por parte de la gerencia. El modelo incluso propone
que un buen alineamiento debe componerse de:

• Un propósito compartido... ¿por qué estamos trabajando en X? ¿por qué


le preocupa a la organización?

• Transparencia.

• Ciclos de realimentación, para reforzar de manera frecuente el


alineamiento, dentro del equipo y entre varios equipos.

• Dejar claras las prioridades.

• Aprendizaje organizacional, que las buenas y malas prácticas se


compartan entre equipos (aquí puedes hacer uso de las técnicas que te
comentaré en el capítulo Mejora (Kaizen) pág. 195).

4.1.5 LOS ESTILOS DE LIDERAZGO DE GOLEMAN

De entre decenas que habrá, junto con los anteriores, este es otro modelo que yo
suelo usar en talleres con equipos.

El famoso Daniel Goleman realizó un estudio de tres años sobre el estilo de


liderazgo de 3.000 gerentes, su objetivo era descubrir conductas de liderazgo
(de paso la investigación descubrió que el estilo de liderazgo influía de media
en el 30% de la rentabilidad de las compañías). Y tras aquel estudio identificó
seis estilos de liderazgo (Goleman, 2000):

• El líder que marca el ritmo. Si este estilo se resumiera en una frase,


sería "Hazlo como yo ". Este estilo funciona mejor cuando el equipo ya
está motivado y capacitado, y el líder necesita resultados rápidos. Si

112
se usa demasiado, sin embargo, este estilo puede abrumar e impedir la
innovación.

• El líder autoritario. Si este estilo se resumiera en una frase, sería "Ven


conmigo". No es la mejor opción cuando el líder está trabajando con
un equipo de expertos que saben más que él.

• El líder afiliativo. "La gente es lo primero". El estilo de afiliación


funciona mejor en momentos de estrés, cuando los compañeros de
equipo necesitan reconstruir la confianza. Este estilo no debe usarse
de forma exclusiva, ya que puede fomentar un rendimiento mediocre
y una falta de dirección.

• El líder coach. "Prueba esto". Es menos eficaz cuando los compañeros


de equipo son desafiantes y no están dispuestos a cambiar o aprender,
o si el líder carece de competencia.

• El líder coercitivo. Exige cumplimiento inmediato... "Haz lo que digo".


El estilo coercitivo es más eficaz en tiempos de crisis, durante una
emergencia. Sin embargo, debe evitarse en casi todos los demás casos,
ya que puede dañar la motivación y la innovación.

• El líder democrático. En este caso construye consenso a través de la


participación. "¿Qué opinas?" sería la frase que lo define. El estilo
democrático es más efectivo cuando el líder necesita que el equipo
admita o tome posesión de una decisión. No es la mejor opción en una
situación de emergencia, cuando el tiempo es esencial.

Una cosa interesante de la investigación de Goleman es que los mejores líderes


no usan de un solo estilo de liderazgo... pueden usar estilos diferentes en

113
situaciones diferentes o combinarlos juntos. Cuantos más estilos exhiba un
líder, mejor.

Cómo los uso yo…

Con los equipos suelo organizar periódicamente un taller de liderazgo y una de las
dinámicas que suelo utilizar es la escalera de Marquet, la matriz de Kniberg y el modelo de
Goleman.

Imprimo los anteriores dibujos, los pegamos en la pared y el grupo (equipo y managers) va
poniendo pósits en los escalones y lugares en los que identifica que estamos, en la sección
de la matriz en la que estamos y los estilos de liderazgo de Goleman que son más típicos.

Periódicamente revisamos si hemos subido, o bajado, escalones, o si hemos cambiado de


casilla en la matriz o si hemos incorporado, o reducido, estilos de liderazgo.

4.1.6 HOLOCRACIA

La “Holocracia”, el nombre viene de holoarquía (Koestler, 1967), propone un


modelo de gestión basado en unidades autónomas y auto-organizadas, sin
jefes o managers, pero dependiendo de una totalidad mayor de la que forman
parte. Sería el nivel máximo de auto-organización (ojo, que no
necesariamente es el que tú tienes que usar).

¿Y qué implica una Holocracia? Estas son algunas de las más típicas
características (Robertson, 2015):

114
• No más roles laborales (adiós especialización y cargos en tarjetas). En
la mayoría de las empresas cada persona tiene un único rol, en una
Holocracia las personas tienen múltiples roles, son más
multifuncionales, esto aumenta la libertad y la expresión del talento
creativo. También significa que la empresa puede aprovechar esas
habilidades de una manera que no podía hacer antes.

• Autoridad más distribuida y más delegación, con apenas roles de


gestión o jefatura. Así la capacidad de tomar decisiones está más
distribuida y menos centralizada en pocas personas. Las jerarquías
son mucho más planas o no existen.

El término se puso de moda desde que Zappos, una empresa de ropa propiedad
de Amazon, anunciase un cambio en su forma de organización (Groth,
2013), rompiendo las jerarquías típicas por una Holocracia, ellos trabajan sin
jefes.

Esencialmente, es una nueva forma de dirigir una organización que reduce


las jerarquías, potencia la autonomía y la auto-organización. Para las
pequeñas empresas u organizaciones que han nacido hace pocos años, la
Holocracia les (nos) viene de serie, es casi una manera obligada de trabajar
para sobrevivir, pero cuando el tema se menciona en empresas medianas o
grandes que trabajan de manera más tradicional… la cosa suena, o se
escucha, de otra manera.

Por mucho que, por ahí unas empresas, por cierto, nada cercanas a nuestro
entorno, como Zappos, Medium, Spotify, etc., cuenten en inglés lo bien que
les va trabajando así, aunque lo cuente el Economist (The Economist, 2014),
aunque lo cuente quien quieras… en muchos entornos dar tal salto es casi
imposible.

115
Aun así, yo he trabajado con varias organizaciones en España que se
estructuran en una Holocracia, pero ciertamente son pocas las que hay.

No obstante, llegar hasta tal punto no es algo obligatorio para poder ser
considerada una organización ágil, siempre puedes usar esquemas de auto-
organización más moderados. La técnica de los tableros de delegación, que
veremos más adelante, está pensada para este tipo de escenarios.

Si quieres saber más sobre este tema, échale un vistazo a la


llamada Holocracy Constitution v4.0 (HolocrazyOne., 2013).

4.2 ¿DEBERÍA HABER MANAGERS? TODOS DEBERÍAMOS SER


MANAGERS

“No tomes el control y atraigas seguidores. Da el control y crea líderes”

-- David Marquet

En línea con lo anterior, con tanta auto-organización... ¿necesitamos


managers, gerentes, etc.? ¿Son realmente necesarios?

Hay un popular artículo en la Harvard Business Review (Hamel, 2011), que


argumenta que “son demasiadas las horas desperdiciadas por los jefes,
dedicados solo a supervisar el trabajo de otros”. También complementa lo
anterior diciendo que “no es problema de los jefes, es problema del modelo de
gestión”. Y añade que “tener muchos jefes hace lentas a las organizaciones”,
que “los jefes más poderosos además son los más alejados de la realidad”, sin
olvidar “los costes que conlleva tener jefes”.

Recuerdo que en una de las empresas “grandes” en las que trabajé, en el


departamento había más jefes que “indios” (como nos auto-llamábamos
nosotros). Entre las situaciones extrañas que aquello generaba, siempre

116
recordaré el “informe de seguimiento de los viernes”, que implicaba que tanto
mis compañeros como yo mismo, perdiéramos todos los viernes 5 horas (toda
la mañana) en exponer en un horrible Word lo que habíamos hecho durante la
semana, para enviárselo al “jefe” que, a su vez, se lo enviaba a su “jefe”, que,
además, no tenía ni idea de lo que poníamos y apenas lo leía (o lo leía
poniendo caras, como si lo entendiera). En aquel equipo estábamos 5 personas,
por 5 horas cada viernes, 25 horas a la semana dedicadas al dichoso informe,
100 horas al mes…

Como comenta (Appelo, 2016), el caso de “no jefes” es similar al de “no tester”.
Una cosa es “la dedicación exclusiva a ser tester” y otra “la dedicación al
testing”. Podemos discutir si debería haber o no personas dedicadas
exclusivamente al testing… si bien todos coincidimos en que si se debe dedicar
tiempo al testing. De igual forma, una cosa es “la dedicación a la gestión” y
otra cosa es tener “un gestor exclusivamente dedicado a la gestión”.

Queramos o no, dedicación a la gestión tiene que haber: hay que fijar los
objetivos del equipo, preocuparse de si hay que incorporar más gente a los
equipos, hablar con los usuarios, de que la gente cobre, de que se pague, de
comprar los pósits para los tableros Scrum, etc.

Disponer de una persona exclusivamente dedicada al testing, o de una persona


exclusivamente dedicada a la gestión, dependerá de las circunstancias. Pero
en la mayoría de los casos se hace necesario que esa persona esté ahí, para
quitar tareas de gestión a los equipos, para contar con alguien experto en ese
tipo de tareas de gestión. Y que exista el manager no tiene por qué invalidar el
concepto de auto-organización.

Los mismísimos Takeuchi y Nonaka en el mítico The New New Product


Development Game (Takeuchi & Nonaka, 1986), artículo que dio origen y

117
nombre a Scrum, escribían: “Un control sutil también es coherente con el
carácter de auto-organización de los equipos”.

De manera similar, comentaba Mike Cohn que el trabajo de un equipo ágil es


auto-organizarse en torno a los desafíos, y dentro de los límites y
limitaciones, que fija la gerencia. Mientras que el trabajo de gestión existe, y
debiera centrase en eliminar obstáculos, que no ponerlos y hacer lento al
proceso (Cohn, 2010; Fast Company, 2005).

Jim Highsmith comentaba que la auto-organización es diferente a la


anarquía, y que la auto-organización implica algún tipo de liderazgo
(Highsmith, 2009)

Y Esther Derby que la auto-organización no significa que no existan


“managers”, el grado de “jefes” depende del momento, por ello es casi mejor
utilizar el término “auto-organizándose” en lugar de “auto-organizado”,
enfatizando así que es un proceso continuo (Derby, 2011).

Lo que sí que estoy observando cada vez más es que las organizaciones que
pueden permitírselo, y que no han caído en convertirse en un dinosaurio
difícil de mover, están cada vez más yendo a estructuras más planas. Sin
eliminar roles de gestión, pero reduciendo jerarquías.

Y te puedo asegurar que el cambio hace feliz a mucha gente, empezando por
los managers. He tenido un montón de experiencias en este sentido, pero
recuerdo que en una de las últimas “transformaciones ágiles” uno de los
managers me dijo: “Qué feliz soy ahora, he pasado de estar desde el viernes al
sábado al medio día, cada semana, planificando al detalle el trabajo que el
equipo haría la semana siguiente... a ¡disfrutar de la auto-organización!.

118
El Efecto Espectador

Cuando, inocentemente, hace años en 233 Grados de TI empezamos con la auto-


organización nos afectó mucho el error de entender que ello implicaba que no hubiera
responsables de nada (porque lo éramos todos de todo).

¿Qué pasó? Que, por ejemplo, había que contestar un correo de soporte, a un usuario y todo el
mundo pensaba que alguien ya lo haría… pero nadie lo hacía.

Y a más gente en el equipo más afectaba este problema. De hecho, en psicología tiene un
nombre: el efecto espectador, que viene a decir que, por ejemplo, si un grupo presencia un
accidente, cuanto mayor es el grupo espectador menos, o más lento, se socorre a los heridos
(“ya lo hará otro”).

Aprendimos rápido de aquello: que las tareas las pueda hacer cualquiera no quiere decir que
no tengan un responsable, para que persiga que se hagan.

Fijamos responsables por áreas, que rotaban por meses, teniendo claro que una cosa es ser
responsable, cuyo objetivo es perseguir que algo se haga y otra hacerlo.

4.3 PRÁCTICA DE MANAGEMENT 3.0: TABLEROS DE DELEGACIÓN

La delegación no es una cosa binaria, hay niveles. El arte está en encontrar el


equilibrio adecuado. Hay cosas que si se delegan a equipos con poca
experiencia acaban en el caos. Y hay cosas en las que los jefes no querrán
perder el control, en otras se puede ser más flexible, etc., por eso es útil usar
diferentes niveles de delegación.

119
Una herramienta bastante útil son los “tableros y niveles de delegación”,
donde se enumera en filas una serie de áreas clave (cosas sobre las que hay
que decidir y que van más allá de tareas individuales o pequeñas) y en
columnas se ponen los siete niveles de delegación que ahora veremos,
definiendo para cada área de decisión qué tipo de delegación le corresponde:

• Tell (Di): Como responsable, tú tomas una decisión y no tienes que


dar explicaciones, solo se la transmites al equipo.

• Sell (Vende): Como responsable, tú tomas una decisión por los demás,
pero, posteriormente, intentarás convencerlos de que es la decisión
correcta, tratas de vendérsela.

• Consult (Consulta): Como responsable, tú tomas la decisión final, si


bien preguntas primero, antes de tomarla y respetas las opiniones del
equipo.

• Agree (Acuerdo): Hay una discusión entre todos los involucrados


hasta alcanzar un consenso sobre la decisión final.

• Advise (Aconseja): El equipo toma la decisión final, si bien el grupo


antes te pide consejo como responsable, pero la decisión final es del
grupo.

• Inquire (Pregunta): El equipo toma la decisión, si bien,


posteriormente, la justifica, informa o te la explica como responsable.

• Delegate (Delega): El equipo toma la decisión final, Se delega la


decisión en el equipo y no te tiene que dar detalles como responsable.

120
El modelo es simétrico, el nivel 7 es como el 1, pero en un caso decide el grupo
y en el otro el responsable.

Hay muchas maneras de montar un tablero de delegación, depende mucho del


tipo de organización. Te voy a contar un ejemplo.

A continuación, tienes una imagen de uno de nuestros primeros tableros (de


233 Grados de TI). Como se puede ver, en la primera fila, ponemos los 7
niveles de delegación y en la primera columna ponemos aquellas cosas que
vamos a delegar.

Como no tenemos un responsable como tal, un jefe de proyecto ni una figura


similar, lo que hacemos es que en cada una de las cosas a delegar asignamos
un responsable.

121
Te cuento las filas más relevantes de nuestro tablero. Respecto a las decisiones
económicas, todos hemos delegado la responsabilidad a Wonder Woman (para
no poner nombres usamos un superhéroe asociado a cada persona). Siguiendo
el orden del tablero la siguiente fila es la decisión de quien va a los proyectos,
en este caso el responsable es el Capitán América, y como está en la columna
Agree el responsable (Capitán América) debate con todos los involucrados (el
resto del equipo) y el grupo debe llegar a un consenso para decidir.

Para el caso del Marketing, el equipo delega la responsabilidad o las decisiones


en este caso, en Batman, Charles Xavier y en el Capitán América, esto quiere
decir, que el resto del equipo se olvida de las decisiones de esta tarea.

En cuanto a los días libres, al ser un equipo auto-organizado, cada uno nos
ocupamos de elegir los nuestros, por eso pone cada uno el suyo, no obstante, se
encuentra en la columna Agree, porque, a pesar de ello, el resto del equipo tiene
que estar de acuerdo.

4.4 ¿REGLAS? ¿NORMAS?

“Si quieres que la gente piense dale propósitos no instrucciones.”

-- David Marquet

En el libro Good to Great (Collins, 2001) comenta que muchas empresas creen
que con el papeleo y la burocracia serán capaces de alinear a los no alineados.
Pero la burocracia es para “gente que no es buena” y que la burocracia es
síntoma de que la empresa no es excelente.

La burocracia mata el espíritu emprendedor de las empresas y hace que los


mejores las abandonen.

122
Incompetencia y burocracia forman un círculo vicioso que puede acabar con
una empresa.

Según Collins, apoyado en varios casos de estudio, “las empresas exitosas


tienden a eliminar burocracia y jerarquías, sustituyéndolas por cultura de
auto-disciplina y espíritu emprendedor”.

Las empresas que combinan auto-disciplina, sin burocracia, con sentido y


responsabilidad empresarial son las que alcanzan resultados excelentes.

Disciplina es respeto a los valores, cumplimiento de lo acordado,


responsabilidad, etc. Auto-disciplina es además convencimiento de las
personas, del grupo, de cumplir con esa responsabilidad sin necesidad de
“policías” de las reglas, controles, fichajes, etc.

Ya decía Stacey que una buena y fiable manera de poner al borde del colapso
a una organización es que la gente hiciera exactamente lo que las reglas,
normas, procedimientos, metodologías, workflows, etc., dicen que se haga, al
pie de la letra y nada más (Stacey, 2000).

Y yo acabo de ver en esa pared, otra vez, (que no es la primera ni el primer


sitio) un pedazo de A3 impreso a todo color con una cantidad de cajas y
flechas que no imaginas… definiendo el macro proceso y no sé cuántas
reglas.

Por alguna razón, en la que tampoco viene al caso profundizar, hay sitios
muy fans de las reglas, de tenerlo todo por escrito, normalizado, detallado,
especificado, documentado, todo. Montones de hojas que casi nadie lee, que son
complejas de actualizar, muchas veces obsoletas y que en ocasiones solo valen
para eximir culpas o cargarlas a otro…“es que es lo que viene en el
procedimiento”.

123
Si te pasas con las reglas, normas y procedimientos matas la innovación y la
capacidad de pensar…y ya si quieres matarla más... implanta una “policía”
del procedimiento, que persiga a quien no los cumpla.

Para innovar hay que pensar, pensar en cosas que no se han pensado antes y
eso es incompatible con seguir al pie de la letra un procedimiento que lleva ahí
de toda la vida. Será eso por lo que se dice que la “creatividad va de la mano
con no hacer lo que hace todo el mundo”.

124
125
Cuantas más reglas pones más haces que la gente haga sólo lo que dicen las
reglas, la improvisación se reduce. Y la responsabilidad de crear respuesta a
nuevas situaciones recae en agentes externos, los metodólogos, muchas veces
ajenos a la realidad, que tienen que crear nuevas reglas, siempre tiempo
después, siempre después de una improvisación.

Mermar la capacidad de improvisación y respuesta de todo el grupo a los


problemas inesperados… es un problema.

Las reglas y metodologías pormenorizadas vienen a decir cómo alguien ha


pensado que otros deben trabajar, con independencia de quien esté haciendo
una tarea y lo listo, o no tanto, que sea. A gente menos capaz quizás tenga
sentido establecer más reglas. En trabajos de alto componente intelectual,
como el nuestro… ¿tiene tanto sentido pensar por otros cómo deben hacer las
cosas hasta el detalle? Muchas reglas provocan que se eluda la responsabilidad
de pensar y mandan el mensaje de que no eres lo suficientemente listo.

4.4.1 PRINCIPIO DE SUBSIDIARIEDAD

En Management 3.0 le llaman el “principio de subsidiariedad”, que dice que


las reglas son responsabilidad de cada equipo, de fijarlas o de no tenerlas, a
menos que el equipo no haga bien su trabajo, en cuyo caso recae sobre el
siguiente nivel jerárquico decidir si aplica reglas y cuáles.

Lo anterior, entre otros, viene a decir que no hagamos procedimientos, reglas y


metodologías de todo y por defecto. Crea procedimientos y metodologías solo
para aquello que se ha demostrado que no funciona... si es que no hay unas
reglas pre-establecidas y escritas.

126
4.4.2 ¿REGLAS PARA QUE TODOS TRABAJEMOS IGUAL?

Un clásico en la defensa de las metodologías pormenorizadas, de documentar


y de tener muchas reglas es aquello de que “así todos trabajarán igual” y eso
hará que las cosas se hagan más rápido, con menos errores y que se reutilicen
buenas prácticas, escritas, que otros podrán usar.

Hasta cierto punto gran parte de lo anterior, repetir buenas prácticas, puede ser
una buena estrategia… pero escribir reglas y metodologías no es la única ni la
mejor manera de lograrlo.

Escribir reglas y metodologías provoca rigidez, difícil adaptación, y por


definición es algo escrito en el pasado, que hay que mantener, que solo unos
pocos actualizan.

En agilidad, y en la época pre-ágil, ya aparecieron muchas maneras de


distribuir buenas prácticas, buscar uniformidad, sin necesidad de escribir y
detallar: dojos, katas, pair programming, pair review, mob programming,
comunidades de conocimiento, retrospectivas en grupo, etc. No dejes que los
anteriores no existan… por tener un documento de reglas.

4.5 SEGURIDAD, LA CULTURA DEL ERROR COMO BASE DE LA


INNOVACIÓN

“El 7 de mayo de 1937 la ciudad de Nueva York presenció la más sensacional caza de un hombre jamás
conocida en esta metrópoli. Al cabo de muchas semanas de persecución, “Dos Pistolas” Crowley -el asesino,
el pistolero que no bebía ni fumaba- se vio sorprendido, atrapado en el apartamento de su novia, en la
Avenida West End.

Ciento cincuenta agentes de policía pusieron sitio a su escondite del último piso.

Cuando Crowley fue finalmente capturado, el jefe de Policía Mulrooney declaró que el famoso delincuente

127
era uno de los criminales más peligrosos de la historia de Nueva York. “Es capaz de matar -dijo- por
cualquier motivo.”

Pero, ¿qué pensaba “Dos Pistolas” Crowley de sí mismo? Lo sabemos, porque mientras la policía hacía
fuego graneado contra su departamento, escribió una carta dirigida: “A quien corresponda”. Y al escribir,
la sangre que manaba de sus heridas dejó un rastro escarlata en el papel. En esa carta expresó Crowley:
“Tengo bajo la ropa un corazón fatigado, un corazón bueno: un corazón que a nadie haría daño”.

Crowley fue condenado a la silla eléctrica. Cuando llegó a la cámara fatal en Sing Sing no declaró, por
cierto: “Esto es lo que me pasa por asesino”. No. Dijo: “Esto es lo que me pasa por defenderme”. La moraleja
de este relato es: “Dos Pistolas” Crowley no se echaba la culpa de nada.

--

“He pasado los mejores años de la vida dando a los demás placeres ligeros, ayudándoles a pasar buenos
ratos, y todo lo que recibo son insultos, la existencia de un hombre perseguido.”

Quien así habla es Al Capone. Sí, el mismo que fue Enemigo Público Número Uno, el más siniestro de
los jefes de bandas criminales de Chicago.

Los anteriores son un extracto de un capítulo del genial libro de Dale Carnegie
(te recomiendo mucho que lo leas, hazme caso), el Cómo ganar amigos e
influir sobre las personas (Carnegie, 1936).

Como comentaba Carnegie, si ni Al Capone, ni “Dos Pistolas” Crowley, ni los


hombres y mujeres despiadados se culpan por nada… “¿qué diremos de las
personas con quienes usted, lector, o yo, estamos en contacto?”.

4.5.1 EVITA LA CULTURA DE BÚSQUEDA DE CULPABLES

La falta de culpabilidad no es solo condición de los grandes criminales, es


algo innato a la condición humana, algo que puedes encontrar en el día a día,

128
contra lo que, por mucho que regañes y muestres pruebas al otro de su error…
es difícil luchar o cambiar.

Incluso cuando he visto la inexistencia de control de versiones, viendo el


mayor copy-paste de código de mi vida, viendo dar plazos que eran imposibles,
en ningún caso, nadie sintió que había hecho algo mal… siempre “había una
buena razón para ello”… siempre.

Es cuestión de la condición humana. Seguro que nos pasa o ha pasado a


todos. Estoy completamente seguro de que me habrá pasado a mí.

Es por ello, que por muy claro que tengamos que alguien la ha liado, que no
tenía ni idea de lo que hizo en un proyecto, ni idea de la repercusión de
aquella absurda decisión, por más que se lo digas… rara vez reconocerá el
error, por mucho que te empeñes en demostrar su culpa.

Así que, como decía Lincoln, “no los censuréis; son tal como seríamos
nosotros en circunstancias similares”. Criticar, sabiendo que el criticado no
aceptará la culpa, calmará tus sentimientos, pero hará al culpado justificar
sus actos y que, probablemente, te censure a ti y te tome aversión. Las
personas no somos lógicas, somos impulsivas y tenemos orgullo.

4.5.2 LA INNOVACIÓN SE ALIMENTA DE EQUIVOCACIONES

“La verdadera medida del éxito es el número de experimentos que pueden hacerse en 24 horas”

--Thomas A. Edison

Es más, si quieres innovación y auto-organización tendrás que tolerar el


error, en este caso controlado, incluso crear la cultura del error, a eso le
llamamos dar seguridad al equipo.

129
Si estás todos los días, durante muchos días, haciendo el mismo régimen de
adelgazamiento y no bajas de peso… no esperes un milagro, cambia, ¡busca
otro método! Si estas estudiando de una determinada manera y suspendes
todo… no esperes un milagro, cambia, busca otro método.

Parece lógico ¿no? Pues no, no lo es, sino no habría tanta gente obstinada en
intentar no cambiar, y de repetir y repetir ciertas maneras de hacer,
esperando… que caiga el milagro, la divinidad, la lotería.

Probar nuevas cosas produce éxitos y fracasos, hasta el punto de que algunos
hablan de que "sólo aprendemos del fracaso" y hasta recomiendan cosas como
“falla lo más frecuentemente posible pero no repitas dos veces el mismo error”
(Fast Company, 2005)

Al parecer, el fracaso y el éxito son necesarios para el aprendizaje. Aprendemos


más cuando no podemos predecir si lo que vamos a intentar tendrá un buen o
mal resultado. No aprendemos nada cuando repetimos lo mismo una y otra
vez… cuando todo lo que hacemos es repetir las prácticas establecidas, es difícil
saber si podríamos hacer algo mejor.

Del mismo modo, si todo lo que hacemos es cometer los mismos errores,
entonces tampoco estamos aprendiendo mucho. El aprendizaje óptimo ocurre
en algún lugar intermedio.

Minimizar los fracasos reduciría el aprendizaje. Por supuesto, maximizar el


fracaso tampoco tendría sentido. Lo que debemos maximizar es la
comprensión de nuestros problemas, esto sucede experimentando éxitos y
fracasos. Por lo tanto, debemos celebrar el aprendizaje, no los éxitos o fracasos.

130
4.5.3 ANZENEERING

“No esperes resultados diferentes si siempre haces lo mismo”

-- A. Einstein.

Para experimentar... no se debe tener miedo al fracaso.

Si quieres un equipo potente, más allá de cosas que ya sabemos, como el


tamaño, la multifuncionalidad, entorno, auto-organización, etc., tienes que
conseguir que la gente se sienta segura, así no tendrá miedo de tomar riesgos,
experimentar, equivocarse y lograrás así sacar todo su potencial.

Esto, obviamente, es una idea bastante antigua, que supongo tendrá muchos
nombres, uno de ellos es Anzeneering, que, salvo error mío, viene de Joshua
Kerievsky. Es la unión de Anzen, que significa “seguridad” en japonés, y
Engineering.

En este mismo sentido, en el de la importancia de la seguridad, hay un dato


interesante a destacar. En 2012, Google creó una iniciativa llamada “Proyecto
Aristóteles”, para estudiar los cientos de equipos en Google y averiguar por qué
algunos funcionaban muy bien y otros no.

Los investigadores del proyecto revisaron medio siglo de estudios académicos


sobre cómo funcionaban los equipos. Y sobre la base de estos estudios,
examinaron los equipos de Google, viendo cosas como… ¿Con qué frecuencia
los compañeros socializan fuera de la oficina? ¿Mismas aficiones? ¿Estudios
similares?, etc.

Pero, después de mirar 180 equipos, era imposible encontrar un patrón.


Algunos equipos eficaces, por ejemplo, se componían de amigos y otros por
personas que apenas se conocían.

131
Hasta que empezaron a investigar “la cultura del grupo”. La cultura, son las
tradiciones, normas de comportamiento y reglas no escritas que rigen cómo
funciona el grupo.

Google había identificado docenas de comportamientos en la “cultura” que


parecían importantes, pero a veces las normas de un equipo eficaz
contrastaban con las de otro igualmente exitoso.

Después de darle muchas vueltas, llegaron a la conclusión de que, finalmente,


lo que distinguía a los “buenos” equipos era cómo los compañeros se trataban
entre sí. Unas normas adecuadas, podían aumentar la inteligencia colectiva,
mientras que normas equivocadas podrían hundirlo, aunque los miembros
fueran individualmente brillantes.

Aunque había heterogeneidad de comportamientos, había dos que todos los


buenos equipos compartían:

• Los miembros hablaban en la misma proporción, un fenómeno que los


investigadores denominan “igualdad en la distribución de los turnos
de conversación”. Al final del día, todo el mundo había hablado más o
menos la misma cantidad.

• Todos tenían alta “sensibilidad social’”, tenían intuición para


detectar cómo los demás se sentían, en función de su tono de voz,
expresiones y otros gestos no verbales.

En psicología, a rasgos como “los turnos de conversación” y “sensibilidad


social” se les conoce como “seguridad psicológica”. Un sentimiento de
confianza en el que el equipo no va a avergonzar, rechazar o castigar a
alguien por hablar, que se caracteriza por la confianza interpersonal y el

132
respeto mutuo y en el que las personas se sientan cómodas siendo ellos
mismos.

Según los datos de Google la seguridad psicológica, más que cualquier otra
cosa, era fundamental para hacer un buen trabajo en equipo. Para darlo todo
en un equipo hay que sentirse “psicológicamente seguro”, saber que podemos
ser lo suficientemente libres para compartir cosas que nos asustan o no
gustan, sin temor a recriminaciones.

4.5.4 LA SEGURIDAD PSICOLÓGICA

Edgar Schein, en su popular Organizational Culture and Leadership


(Schein, 1985), de manera similar, también hablaba de la “seguridad
psicológica” y su papel en el cambio. Para empezar, contaba que la “ansiedad
de sobrevivir” potencia el cambio y la “ansiedad de aprender” lo frena.

Según Schein, el verdadero cambio no empieza a suceder hasta que el


individuo u organización está experimentando alguna amenaza real, lo que
él llama la ansiedad por sobrevivir, la “ansiedad de supervivencia”, que viene
alimentada del miedo a la pérdida del poder, de que la competencia nos
expulse, miedo de perder nuestro trabajo, cargo, etc.

Últimamente, por ejemplo, me encuentro muchas organizaciones entrando en


ansiedad de supervivencia, cuando ven que los cambios tecnológicos, la
llegada de organizaciones más ágiles a su sector, el incremento de la
velocidad en su negocio, la mayor dependencia de la tecnología, ha hecho que
nuevos competidores sean una verdadera amenaza.

Pero, por otro lado, un cambio conlleva aprender algo nuevo, experimentar,
adentrarse en algo desconocido, salir de la zona de confort, etc., lo que

133
también produce otro tipo de ansiedad, la que Schein llama “ansiedad de
aprender”, la cual produce resistencia al cambio.

Para reducir la ansiedad de aprendizaje, Schein introduce un tercer elemento,


la llamada “seguridad psicológica”, que es necesario aumentar para frenar al
máximo la resistencia al cambio. ¿Y cómo se aumenta la seguridad
psicológica”? Pues, como puede parecer obvio, con formación, comunicación,
sentido de equipo, visión clara, un líder apropiado, etc.

134
135
5. Multifuncional

"Necesitas un Foreman, un Bill Gates, una miss Daisy, dos catetos, un Walt Whitman...”

-- Fragmento de la película “Ocean's Eleven”

Un equipo multifuncional es aquel equipo que posee todas las competencias


necesarias para lograr completar el trabajo, sin depender (o dependiendo
mínimamente) de otros equipos, áreas, o roles fuera del mismo.

No significa que todo el mundo dentro del equipo sepa hacer de todo, significa
que:

• El equipo en su conjunto es autosuficiente y tiene el conocimiento y


habilidades necesarias para construir el producto que le toca (sin
depender de otros equipos o departamentos)

• La especialidad de cada miembro puede ser complementada por algún


otro miembro del equipo y que cada persona conozca algo más que su
propia especialidad (las llamadas competencias en T de las que te
hablaré luego).

5.1 EL PROBLEMA DE LOS SILOS

La visión más clásica de una empresa, algo que ha sido muy típico en
desarrollo, es estructurarse por departamentos (en vez de por equipos)
especializados, lo que se conoce como “silos”.

137
138
Los típicos, de manera general, son: negocio, desarrollo, testing y operaciones.
Había también quien hacía silos por partes del producto, el departamento de
back-end, el de front-end, etc.

Incluso en algunos sitios la cosa es más crítica: en vez de departamentos


especializados ¡hay empresas! (por cuestiones de externalización).

Hay algunas características, a la vez que problemas, muy típicos de la


estructura por silos:

• Para completar la creación de algo es necesario contar y coordinar


personas de todos esos departamentos (o empresas), lo que implica
lentitud, pedir “recursos” de un responsable al otro, pausas, alinear
diferentes planificaciones, cuellos de botella, etc.

• Cada silo puede haber terminado con éxito su parte... pero el todo, la
entrega, puede haber sido un fracaso.

• Las “interfaces” entre silos suelen ser documentación, que se asume


como contrato entre las partes y que suele llevar a frenar el cambio y
la adaptación (“lo pone en el papel, es lo que tú dijiste”).

• Cada departamento suele tener su propio modelo de trabajo, que si un


CMMI en desarrollo, un ITIL en operaciones, un comité de cambios en
medio, un pull de recursos, hay que entrar en la cola para testing,
una PMO para coordinarlo todo…

• De la separación en silos vienen, por ejemplo, los históricos


desencuentros entre desarrollo software, testing y operaciones: “que si
testing es quien pone palos en las ruedas de desarrollo”, “que si

139
desarrollo intenta saltarse el trabajo de testing”, “que si a mí en local
me funciona”, etc. Lo típico.

5.2 EL EQUIPO MULTIFUNCIONAL

La visión ágil se basa en equipos multifuncionales (dos palabras importantes


aquí: equipo y multifuncional), es decir, equipos autónomos, capaces ellos
solos de tomar una necesidad de negocio (p. ej. una historia de usuario) y
dejarla lista en producción o pre-producción.

Es como darle la vuelta a la estructura de silos, haciendo equipos que estén


formados por personas de cada uno de los silos. Así el equipo tiene todas las
competencias sin depender de estructuras externas.

¿Qué ventaja tiene pasar a equipos multifuncionales?:

• Elimina multitud de “desperdicios” (en terminología Lean), es decir,


elimina cosas que no aportan valor.

• Potencia la comunicación rápida y eficiente, cara a cara, entre


personas, al eliminar las barreras entre departamentos y los más que
típicos procesos documentales.

• Eliminar tiempos muertos (“déjame una persona de testing para el


día X”) y evitar que desarrollo, testing, etc., se realice en cascada, es
decir, que las pruebas sean al final del proyecto, cuando casi no
queda tiempo y cuando ya la mayoría de lo que testing detecta “es
demasiado tarde para ser solucionado, o no llegamos a la fecha de
proyecto”.

140
• Simplifica el modelo y aplana jerarquías. En una estructura de
equipos multifuncionales ya no es necesaria tanta estructura de
gestión.

• Visión más clara de en qué estado están las cosas, ahora puedes
medirte por trabajo completado, real, que aporta valor, (p. ej. en cada
Sprint) por el equipo. En una estructura por silos, el seguimiento, la
mayoría de las veces, se hace por horas, sin tener eso reflejo real de en
qué estado están las cosas (esto te lo amplío en la sección “La
velocidad del equipo... Algo más preciso que contar horas”, pág.171).

Y, sobre todo, aunque parezca una obviedad... es la base para empezar a tener
equipos.

Soy consciente de que hay empresas tradicionales que cuando escuchan cosas
como que: testing (u operaciones) puede ser mucho más eficientes trabajando
juntos, dentro del equipo de desarrollo, y no fuera, tiemblan los cimientos de
su edificio, el día se hace noche, aparece un ojo de fuego en la torre de Barad-
dûr, etc. Pero qué queréis que os diga, yo cada vez lo veo y experimento más y
los resultados hablan por sí solos.

No obstante, hacer que testing trabaje dentro del equipo de desarrollo no


implica necesariamente eliminar el departamento de testing (que es una
opción), no… lo que implica es que ahora testing es transversal, u
horizontal, dando servicios con personas ubicadas en cada uno de los equipos
de desarrollo. Y esta es una buena estrategia que yo he visto en muchos sitios,
y que tiene la ventaja de “alinear” prácticas en todos los equipos.

141
5.3 T-SKILLS, NO TODO EL MUNDO SABE HACER DE TODO

Muchos equipos ágiles con los que empiezo a trabajar malinterpretan el


concepto de equipo multifuncional, pensando que multifuncional, o equipo
ágil en general, es aquel en el que todo el mundo sabe hacer y hace de todo. Es
una opción, pero si fuera condición obligatoria... pocos equipos ágiles íbamos a
ver en este mundo.

Equipo multifuncional no significa que todo el mundo tiene que saber hacer
de todo (Kniberg, 2010), mala y común interpretación, multifuncional
significa:

• Que el equipo en su conjunto, posee todas las competencias necesarias


para lograr completar el trabajo él solito, sin depender (o dependiendo
mínimamente) de otros equipos, áreas, departamentos o roles fuera
del mismo.

• Además, cada miembro del equipo está capacitado y dispuesto para


poder hacer algo más que aquello en lo que está especializado y no
hay una única persona con conocimiento exclusivo sobre algo (para
evitar “Rambos solitarios”), lo que se conoce como T-Skills
(competencias en forma de T).

Lo de competencias en forma de T viene de que debes (o se espera) tener una


fuerte competencia y preparación en lo tuyo, en tu especialidad, y esto sería el
palo vertical de la T, pero que, además, debes conocer otras áreas, aquellas que
no son tu especialidad pero que son necesarias en el trabajo del equipo, esto
sería el palo horizontal de la T.

142
5.4 MATRICES DE MULTIFUNCIONALIDAD

Como complemento a la visión de las competencias en T, la “Matriz de


Multifuncionalidad” (Kniberg, 2009) te puede ser útil, yo la uso mucho,
sobre todo antes de que un equipo grande se divida para entrar en el camino
de la multifuncionalidad, nos da una foto muy buena de por dónde pueden
venir los problemas.

La técnica se basa en escribir en las columnas de una tabla las principales


competencias necesarias para construir el producto. Y en las filas de esa
misma tabla los nombres de las personas del equipo. Puntúa dentro de la tabla
el grado de habilidad de cada persona respecto a cada competencia.

Pon un “asterisco” allá donde la persona es experta (el palo vertical de la T).
Pon un “punto” donde la persona no es experta, pero podría desenvolverse y
ayudar con dicha competencia (el palo horizontal de la T). Deja en blanco
competencias que una persona desconozca por completo (o se niegue a hacer).

143
Cada columna debería tener como mínimo un asterisco, acompañado de, al
menos, un punto u otro asterisco.

5.5 DE SILOS A MULTIFUNCIONALES PASANDO POR TUCKMAN

El que para mí fue el peor entorno en el que he trabajado, fue una empresa que
desarrollaba software en la que día sí y día no había bronca. Bronca
propiciada, tolerada o fomentada por los máximos responsables; quizá alguien
pensó que los entornos de disputa hacen a la gente más competitiva y así más
productiva. Un caso más del Troglodita Management.

Pues para mi sorpresa, algún tiempo después de aquello, que además he visto
otras tantas decenas de veces, descubrí que el tema parece ser tan común que
hay hasta una teoría que lo trata, la de Tuckman. De la que se deriva que

144
muchos equipos nunca llegan a ser productivos porque se atascan en un ciclo
“formación del equipo – confrontación”. Donde la gente se va, la echan, llegan
los nuevos y vuelta a empezar.

Desarrollado en 1965, el “Modelo de Tuckman” es popular en el mundo de la


formación de equipos en general y, lógicamente, también se ha hecho uso y
aplicación del mismo en el mundo de la agilidad.

Dicho modelo cuenta que los grupos no empiezan totalmente formados,


cohesionados, a la primera, sin más, y que los equipos necesitan tiempo para
crecer, necesitan tiempo para ser productivos y que lo hacen a través de etapas.
De hecho, lo popular del modelo de Tuckman son precisamente esas etapas de
“madurez”.

Tuckman decía que había cuatro fases básicas (a las que posteriormente
añadió una quinta) en la evolución y madurez de un equipo: “formación”,
“confrontación”, “normalización” y, por fin, llega la fase de “rendimiento”.
Vamos a ellas con un poco más de detalle:

1. Formación. Es la etapa inicial del equipo, durante la cual todo el


mundo se preocupa, principalmente, por buscar cuál es su lugar en el
equipo.

2. Confrontación. Superada la anterior, en esta etapa pueden aparecer


las confrontaciones, disputas sobre cómo deben hacerse las cosas, etc.

3. Normalización. Los miembros del equipo establecen sus reglas de


juego, se aclara quién hace qué, cómo, etc.

4. Rendimiento. Etapa final, se consolidan las relaciones entre los


miembros del equipo y las sinergias. Etapa de mayor rendimiento.

145
En 1977, Tuckman añadió una quinta etapa, cuya traducción vendría a ser
algo así como “finalización”, que consiste en que se completa la tarea y
desaparece el equipo.

El valor de este modelo es que nos ayuda a entender que los equipos
evolucionan, no se forman instantáneamente, hay fases que superar.

5.6 CAMBIA LA ORIENTACIÓN A PROYECTOS POR EQUIPOS

Hay una enorme diferencia entre estructurarse, gestionarse, organizarse, o


como lo quieras llamar, enfocado a proyectos (modelo de trabajo clásico en
industria, arquitectura, etc., y, en general, de aquellas profesiones que crean
productos físicos) o enfocado a equipos. Que no es lo mismo, ni mucho menos.

Como primera reflexión, he de decir que si tienes dudas sobre si tu equipo o


empresa tiene una visión de proyectos o de equipos, puedes empezar por
contestar a una pregunta… ¿Llegan proyectos y se montan equipos para
desarrollarlos o tenéis equipos estables desde hace tiempo que hacen
determinado tipo de proyectos (o tareas, que lo de proyecto aquí empieza a no
ser tan destacado)? Que no es ni de lejos lo mismo.

“Estructurarse por proyectos”, es estructurarse por método de estimación (más


lícito o no, más elaborado o más a ojo), una fecha inicio, una fecha fin y un
presupuesto a cumplir. Estimación predictiva, proyección al futuro, plan en
base a los requisitos del proyecto.

“Estructurarse por equipos” implica estimación basada en el pasado, en la


capacidad de trabajo efectiva que tiene el equipo por unidad de tiempo
(iteración o sprint), estimación empírica, lo que se llama velocidad (todo esto
lo trataré en el cápitulo Productivo, pág.159). Conociendo la velocidad de un
equipo se hacen previsiones, estimaciones, para terminar tareas. Y para esto

146
debe haber, obviamente, equipos (estables) que lleven trabajando un tiempo y
se conozca su velocidad.

Estar estructurado por proyecto pone como premisa principal cumplir la fecha
de entrega, sea como sea, aunque tenga que quitar fases, saltarme el testing,
o lo que sea.

Estructurarse por equipo implica trabajar por todos los medios en aumentar la
productividad del equipo, lo que implica un entorno físico adecuado, trabajar
en evitar las interrupciones, equipos pequeños, etc., y, sobre todo, motivación y
talento. Las tentaciones de saltarse etapas imprescindibles, como el testing,
para entregar antes, son mucho menores porque esos saltos de tareas
necesarias lastrarán la velocidad del equipo en las siguientes iteraciones o
Sprints (deuda técnica), y, cómo se hace uso de la velocidad… esos bajones de
productividad se verán muy claramente.

Estructurarse por proyecto implica, por lo general, montar un equipo para ese
proyecto y luego desmontar ese equipo.

Estructurarse por equipo pone la premisa del equipo estable (vamos, que no
rote constantemente la gente como buena práctica, como veremos más
adelante.

Estructurarse por proyecto implica, muchas veces, que una persona está en
varios, o muchos, proyectos y, en ocasiones, por ello, en muchos equipos.

Estructurarse por equipos implica que el equipo es estable y hace tareas de


varios proyectos, si es necesario, o de uno único, o de ningún proyecto (ya que
el concepto proyecto apenas aplica).

Estar estructurado por proyecto se manifiesta en un montón de detalles más…


Por ejemplo, existen “nombres de proyectos”, nombres que acabado el proyecto

147
mueren, en vez de “nombres de equipos” que, en algunos casos… llegan a
convertirse en míticos y no tienen fecha de caducidad (lo veremos en la
pág.155).

5.7 EL EQUIPO ÁGIL ES ESTABLE

Quien dice que no pasa nada por mover gente de un equipo a otro (o de un
proyecto a otro), suele caer en la idea de confundir “personas” con “recursos
humanos”. Un “recurso” es sólo “dinero” y horas, pero una “persona” es,
además, relaciones con otras, conocimiento, motivación, desmotivación,
experiencia, etc. Por eso, mejor piensa en “personas” y no en “recursos
humanos”.

Si solo ves “recursos humanos” pues, probablemente, y teóricamente, te cuadre


lo de cambiar “recursos” de un equipo a otro, por motivos de facturación, crisis,
apagar fuegos, etc. Pero si piensas que en los proyectos hay “personas”,
empezarás a ver que las siguientes, y casi centenarias, ideas, tienen más
sentido del que pensabas:

• Ley de Brooks. O aquello de que “añadir gente a un proyecto software


con retraso hace que se retrase más”, ya que añadir más personas
incrementa los canales de comunicación, tiene el coste de la fase de
aprendizaje, etc.

• El Modelo de Tuckman. Un equipo necesita un tiempo para ser


eficiente, que no es automático.

Cuando uno olvida cosas como las anteriores, normalmente, ve con buenos
ojos la multitarea, es decir, tener a personas distribuidas en varios equipos y
en varios proyectos, con muchas cosas a la vez, olvidando que trabajar en más
de una tarea genera pérdidas de tiempo y disminuye la productividad, por

148
cuestiones del cambio de contexto (puedes ampliar esto en la sección “El
desperdicio del cambio de contexto”, pág.184).

Por lo tanto, la próxima vez que alguien te plantee esto, es que ni te lo pienses:
“los equipos deben ser estables”.

Los miembros de los equipos estables se conocen, conocen su estilo de trabajo,


se forman juntos. Por ello ten en cuenta que, sin equipos estables, raro es que
conozcas la capacidad de trabajo del equipo, llámalo velocidad (más de ello en
la sección de ”La velocidad del equipo... Algo más preciso que contar horas”,
pág.171).

Hay una excepción a esta regla, y es cuando algún miembro de un equipo se


va a otro durante un tiempo para aprender y ofrecer buenas prácticas.

Luego está el caso de la rotación de personas y su sustitución. De media todo el


que ha estudiado el tema habla que, si una persona se va y viene otra, la
nueva incorporación no es productiva hasta que pasan los tres primeros meses
de trabajo (DeMarco & Lister, 1985). Tres meses de trabajo perdidos.

Si, de nuevo, quieres ver sólo el tema económico, calcula cuánto te cuesta de
media una persona al mes y multiplica por tres. Supón que una persona te
cuesta al mes 3.000 € (todos los gastos incluidos), pues si se va pierdes 9.000
€. Y si se te van dos al año 18.000 €. Y si se te van tres al año 27.000 €. ¿Lo
pillas?

¿De verdad no te merece la pena invertir, no sé, 10.000 € al año en “felicidad”?


¿En que la gente no esté deseando irse y echando currículums en LinkedIn a
escondidas?

149
Y eso sin contar que mientras están, antes de irse, lo de estar quemado se
cepilla literalmente la productividad. Recuerda aquello de un equipo “feliz” es
más productivo y por ello está de moda medir la felicidad.

Y la lista de costes podría continuar, porque en un entorno de mucha rotación


(y te lo digo por experiencia porque he trabajado en entornos así) se crea una
cultura de “hay que irse”. Si muchos se van “será por algo”. Por lo que tu
empresa puede convertirse en un sitio de paso para todo el mundo y cambiar
eso cuesta, mucho.

150
151
5.8 LA SEPARACIÓN FÍSICA ENTRE LOS MIEMBROS DE UN EQUIPO
IMPACTA

La distancia en el desarrollo software, y prácticamente en cualquier trabajo


del conocimiento, ha tenido de siempre un enorme impacto en los equipos: la
distancia importa.

A más distancia más problemas suele haber y por ello más atentos debemos
estar a la hora de cuidar la comunicación. Y no estoy hablando de
separaciones de miles de kilómetros, incluso el que miembros del equipo estén
en plantas diferentes del edificio influye en que los equipos lleguen a ser
verdaderamente multifuncionales, ya que muchas veces lo de tener que
moverse por el edificio hace que se reduzca la comunicación.

Y la comunicación, como facilitarla y hacerla lo más eficiente posible, es otra


de esas cosas (al igual que les pasa a los entornos físicos, las interrupciones,
etc.) que impacta mucho y se cuida poco. Fíjate que (Perry, 2002) y sus
colegas hicieron hace ya sus años un estudio en el que observaron que los
desarrolladores pasan más de la mitad de su tiempo en actividades que
incluyen “algún tipo de interacción con otras personas”.

Hay una popular gráfica de (Cockburn, 2001) que muestra los efectos de la
distancia en referencia a los medios de comunicación usados: lo más eficiente
es estar todos físicamente frente a una pizarra. De hecho, Cockburn sugiere
que “el equipo debe estar sentado con una separación no superior a la longitud
de un autobús escolar”.

152
Otra popular curva sobre el tema es la Curva de Allen, de 1977, que muestra
que cuando las personas se separan a una distancia mayor a 10 metros la
probabilidad de que se comuniquen al menos una vez a la semana cae al 10%.

Aunque la gráfica es antigua, y en aquellos tiempos no había la tecnología


de ahora, Allen comentaba que “en los últimos años la tecnología no ha podido
hacer que esto mejorase mucho más”.

Y es lo que también argumenta uno de los patrones Scrum, el Collocated


Team (Sutherland & Coplien , 2015), que habla de como si los miembros del
equipo están separados físicamente las cosas pueden funcionar de manera
menos efectiva.

153
Dicho esto, y ya siendo conscientes y sabiendo que sí, que la distancia
importa, que tiene impacto, lo ideal… que el equipo esté junto, lo más próximo
que puedas, y que, si no puede ser, al menos, seas consciente del impacto que
tiene la distancia en la comunicación y que por ello pongas especial atención
en cómo mejorarla y fomentarla.

5.9 IDENTIDAD, SENTIMIENTO DE EQUIPO

Un fuerte sentimiento de pertenencia a un grupo, equipo, empresa o


comunidad suele ir acompañado de sentirse parte de sus símbolos, aquellos
que los identifican, esos nombres, colores, logos, mascotas, etc., que
identifican al grupo.

Piensa en un equipo de fútbol sin escudo, sin colores, sin himno…. ¿qué sería?
Dígase de paso que cada vez estoy más convencido de que un buen equipo está
más cercano al concepto “equipo de fútbol” (equipo pequeño, multifuncional,
con objetivo claro, poca jerarquía, etc.) que al concepto “ejército” (equipo
grande, jerarquizado, orientado a hacer en vez de pensar, etc.).

Esto de la identidad de grupo, se lo llevan tomando muy en serio los políticos,


las religiones, los clubes deportivos, militares, etc., desde que el mundo existe
y, de formar “pasión por los colores”, los anteriores saben.

En culturas tecnológicas más avanzadas esta historia también se la saben


desde hace tiempo. Populares ejemplos son los equipos que montaba Steve Jobs,
usando los símbolos piratas, para hacer a su equipo exclusivo y diferenciado
del resto, para que sus miembros sintieran que eran especiales y diferentes al
resto.

Tener símbolos, logos, eslóganes, crea sentimiento de grupo y de pertenencia


al mismo.

154
Claro, que crear una identidad lleva tiempo, trabajo y hasta necesita de suerte.
Poner personas juntas bajo un mismo techo no crea una cultura. Pero hay algo
típico en todos aquellos equipos que sí han creado una cultura: tienen sus
símbolos. Lo raro es lo contrario, un equipo potente… sin símbolos.

5.9.1 NOMBRES

Pregunta a los equipos de tu empresa, al tuyo, por sus nombres de equipo, si


no tienen, mala cosa; si tienen los nombres de los clientes para los que
trabajan, mala cosa; si tienen los nombres de los productos o tecnologías con
los que trabajan, mala cosa.

Salvo que los clientes o tecnologías con las que trabajan produzcan gran
orgullo a los miembros del equipo, esos nombres dicen poco de identidades y de
valores.

Y qué queréis que os diga, yo lo que más me encuentro después de pasar por
más de 80 empresas… es eso, equipos sin identidad, sin nombres y lo peor,
gestores sin conciencia de lo que ello implica.

5.9.2 LA PRUEBA DE LA CAMISETA

“Un equipo tiene de verdad identidad cuando está deseoso de vestir con los
símbolos de ese equipo, es lo que se llama el test camiseta” (Appelo, 2010), y
que le sucede, como te comentaba, a todo “grupo” que provoca fuertes
sentimientos de pertenencia: equipos de fútbol, religiones, partidos políticos,
etc.

Un equipo pasa el test de la camiseta cuando viste orgullosamente una


camiseta con el símbolo que representa a su empresa o equipo. Claro, que, para
ello, antes tiene que haber símbolo y camiseta.

155
5.10 PRÁCTICA DE MANAGEMENT 3.0: EXPOSICIÓN DEL TRABAJO

En relación con lo anterior, hay una práctica en Management 3.0 llamada


Work Expo, y que es algo así como montar una exposición de nuestro trabajo
que vale para visualizar recuerdos, valores, éxitos, fracasos, recuerdos de “te
acuerdas de aquel día en el que…”, o de “te acuerdas de aquel que…”, esas
cosas.

Vamos que lo que busca es crear un recordatorio visual de los valores de su


equipo… por qué batallas ha pasado, uf, de lo que ha disfrutado. Puede parecer
una obviedad, pero si no te preocupas por ello, aunque se tengan esos recuerdos,
acaban desapareciendo, se olvidan, mueren…

Esto del Work Expo, o “Tótem” que le llaman algunos, se lo monta cada
equipo, cada grupo, la idea es esa, mostrar recuerdos, mostrar valores. Desde
arte friki, a fotos, capturas de pantalla, correos electrónicos o Kudos, todo vale.
Un montón de trastos para alguien que acaba de llegar, pero un montón de
historias a recordar para los “propietarios”.

Propón una lista de preguntas para empezar a construir el Tótem del equipo:

• ¿Qué nos hace especiales? ¿Cuáles son nuestros valores?

• ¿Qué historias queremos recordar?

• ¿Qué imágenes representan a nuestro equipo?

• ¿Qué trabajos, o resultados, queremos exponer?

• ¿Qué éxitos y fracasos queremos recordar?

156
Dicho lo anterior, toca pasar a la práctica, y sacarle alguna foto a uno de los
Tótems que nosotros hicimos en 233…

157
159
6. Productivo

“El almuerzo es para desocupados.”

-- Gordon Gekko, fragmento de la película “Wall Street”

6.1 MEDIR HORAS ES PELIGROSO, ERRÓNEO Y OBSOLETO

Durante toda mi vida profesional aquello de “a ver quién trabaja (o está en la


oficina) más horas” me ha perseguido y en la mayoría de las ocasiones… me
ha pillado.

Cuando me dedicaba solo y exclusivamente a programar recuerdo haber


“programado” hasta tal hora que a ratos lo hacía durmiendo, dando cabezadas
(no te cuento lo que pudo salir de allí).

Una vez tuve un jefe que nos enviaba adrede correos a altas horas de la noche
(nunca supimos si tenía programados los envíos) para, a la mañana
siguiente, regañar públicamente a quienes no lo habían leído, aquellos que no
lo habían hecho estaban (estábamos) “poco comprometidos con la empresa”.

Alguna vez te habré contado de aquel sitio en el que, si te ibas a tu hora, al


levantarte y coger el abrigo, el jefe te decía: “Oye ¿tienes frío? Si eso ponemos
la calefacción.“

161
“Mi padre, Burt Scott, que trabajó para Henry Ford durante muchos años, me contó una
historia acerca de aquel encuentro. En la planta de Ford situada en River Rouge tenían
problemas técnicos con un nuevo generador de gran tamaño.

Los ingenieros eléctricos de la factoría eran incapaces de encontrar dónde se hallaba el


problema, por lo que Henry Ford solicitó la ayuda de Setinmetz. Cuando el “pequeño
gigante” [nota, sufría de enanismo] llegó a la fábrica, se negó a recibir cualquier tipo de
ayuda, sólo solicitó una libreta, un lapicero y un camastro.

Durante dos interminables días, y noches, Steinmetz se dedicó a escuchar el sonido del
generador y a realizar incontables cálculos. Entonces, pidió una escalera, cinta métrica y
una tiza. Subió con esfuerzo a lo alto del generador y midió con sumo cuidado, colocando
una precisa marca de tiza en una parte de la enorme máquina.

Hecho esto, descendió por la escalera y comentó a los escépticos presentes que era necesario
desmontar una placa del lateral del generador y eliminar 16 vueltas de la bobina a partir
del punto en que había realizado la marca de tiza.

Los ingenieros introdujeron más tarde las correcciones sugeridas por Steinmetz y el
generador comenzó a partir de entonces a funcionar perfectamente.

Al poco tiempo le llegó a Ford una factura por 10.000 dólares firmada por Steinmetz desde
General Electric. Ford devolvió la factura, agradeciendo el buen trabajo realizado por
Steinmetz, pero solicitando respetuosamente una factura detallada. Steinmetz respondió
enviando de nuevo la factura a Ford con el siguiente detalle:

Marca de tiza en el generador: 1 dólar [trabajo físico].

Saber dónde hacer la marca: 9.999 dólares [idea y conocimiento, nota de jgarzas]

Total a pagar: 10.000 dólares”

162
En la era del conocimiento, seguir valorando el trabajo de un profesional en
función de las horas que pasa sentado en la oficina, es otra de esas malas
prácticas que nos ha tocado, y tocará, vivir durante muchos años, demasiados.
Otra herencia envenenada que nos deja la era industrial.

En los trabajos industriales, en los trabajos de obrero, en las cadenas de


montaje, en las construcciones de carreteras, puentes, etc., es hasta cierto
punto lógico pensar que a “más horas de trabajo más avance del proyecto”. Pero
en los trabajos del conocimiento (como, por ejemplo, es el desarrollo software)
¿de verdad crees que horas equivale a trabajo terminado y/o de valor para los
usuarios y clientes?

Llevo muchos años viendo y sufriendo esta extraña manera de valorar el


trabajo basado en el conocimiento, sólo por horas “silla”.

Ya desde mis primeros años, cuando trabajaba para una consultora grande en
modo body shopping, si había algo que te hacían aprender rápido era que el
mejor, el “más comprometido”, era el que salía más tarde.

Daba igual que estuvieras 12 horas pensando en cómo organizar la fiesta del
próximo fin de semana, lo importante no era tanto tu mente… era tu cuerpo
sentado en una silla.

Aun hoy, incluso sigo viendo muchos lugares que continúan esa idea
instalando sistemas de fichar que cuentan las horas desde que entras hasta
que sales (aunque mucha gente pase la mitad de esas horas charlando frente
a la máquina de café que hay dentro de la oficina). Como si por tener a
alguien más horas dentro de una oficina fuese a tener más ideas.

163
En los trabajos del conocimiento una buena idea que se explica en 5 min.
puede ahorrar a una empresa, o a un equipo, meses o años, 5 min. pueden
hacer ganar muchos proyectos.

El verdadero motor de un equipo ágil no viene de supervisar las horas que


trabaja... viene de una cultura que motive desde dentro a las personas, de unos
valores y unos objetivos claros.

6.1.1 “CRUNCH MODE” VS “SUSTAINABLE PACE”

“Los actuales horarios obligatorios son de 9 a.m. a 10 p.m. - siete días a la semana - con el sábado por la
tarde libre de vez en cuando por buena conducta (salida en esos casos a las 6:30 pm). Una semana
laboral de ochenta y cinco horas. Se ignoraron las quejas de que estos horarios, combinados con la fatiga
existente en el equipo, se traducirían en un mayor número de errores cometidos y una mayor cantidad
de energía desperdiciada.

El estrés está pasando factura. Después de un cierto número de horas dedicadas a trabajar los ojos
comienzan a sufrir; después de un cierto número de semanas la fatiga se comienza a acumular de
manera exponencial. Hay una razón por la que hay dos días libres en un fin de semana, cosas malas le
suceden a la salud física, emocional y mental si estos días libres se eliminan”.

El anterior es un extracto del post escrito en noviembre del 2004 por la pareja
de un empleado de Electronic Arts, detallando las condiciones de trabajo
extremas allí impuestas (Livejournal, 2004)

Por si no lo conocías, lo cual no dejaría de ser una suerte para ti, el Crunch
Mode, es el término utilizado para describir trabajos extremos en el ámbito de
la tecnología, extremo se refiere a tiempo dedicado, obviamente.

Típicamente, los que se enorgullecen, o avergüenzan, del Crunch Mode hablan


de 50, 60, 70 e, incluso, como en el caso de Electronic Arts, a veces... 80 horas
a la semana durante meses.

164
En el otro extremo, prácticas ágiles como “Ritmo Sostenible” (Sustainable
Pace), una antigua y popular práctica de XP (eXtreme Programming), que
defiende que los equipos deben trabajar duro… pero a un ritmo que sea
sostenible y que se pueda mantener indefinidamente en el tiempo.

La idea del Ritmo Sostenible es mantener a la gente fresca, para que así
puedan ser más creativos a medio y largo plazo, durante años.

Tras ideas como la del “Ritmo Sostenible” está la razonable afirmación de que
aumentar el número de horas de trabajo, no aumenta linealmente la
productividad. Horas trabajadas es diferente a cosas terminadas y a valor
aportado.

Además, pasado un punto de inflexión, los equipos tienden a ser más


destructivos que productivos. Cuando se usa a largo plazo, el modo Crunch
frena la productividad y genera muchos errores en comparación con el Ritmo
Sostenible.

6.1.2 GESTIÓN POR FUERZA BRUTA

Cuando hace ya unos años trabajaba para una empresa grande, siempre
recuerdo, y así lo solemos recordar cuando nos juntamos algunos que en
aquel tiempo allí trabajamos, que imperaba la gestión por fuerza bruta y
terror.

Todos teníamos, sin exagerar, miedo (que va más allá de respeto) a nuestro
jefe, que, a su vez, tenía terror al suyo (terror hasta el punto de que yo una vez
lo vi temblar mientras hablaba con él por teléfono).

Las cosas se hacían bajo la llamada gestión por miedo: si algo salía mal
sabías que o te caía una bronca de mucho cuidado y/o intentaban dejarte en

165
ridículo delante de cuanta más gente mejor y/o te amenazaban con echarte
(fácil en nuestro caso porque todos éramos externos en modo body shopping).

Otra “buena práctica” de gestión complementaria que allí solía usarse era la
de la fuerza bruta. La idea era que todo saldría mejor si, además de tener
asustado a aquel que tenía que hacer el trabajo, se usaba la fuerza bruta.

La fuerza bruta se manifestaba de diferentes formas. En “tiempo”, por


ejemplo… si no funciona hay que echar más horas, días, noches, etc., si algo
no sale es “porque no le has echado horas suficientes” (y no porqué la deuda
técnica fuera brutal). En “personas”, si la versión no es estable, es que hacen
falta 20 personas más probando… “más gente”, “es porque pocos la han
probado” (y no por el churro código que había detrás, que parecía programado
con los codos en vez de con los dedos, pero eso nadie lo miraba).

Curiosamente, la gestión por fuerza bruta creaba además una extraña cultura
bárbara, vikinga, en la que los más valorados eran los que echaban más horas
y se iban más tarde (aunque en realidad estuviera viendo el Marca todo el
día), el que llegaba primero (aunque dejase la chaqueta bien visible en la silla
para que la viera el jefe al llegar y mientras se fuera a tomar cafés) o el que
contesta más mails a horas raras, tipo las 4:00 a.m. (aunque realmente los
escribiera el día anterior y los dejaba listos en borrador, para darle a enviar o
programarlos).

Muchos en aquellos momentos de inocencia creímos que si empresas y


directivos tan importantes gestionaban así… esa debía ser la manera de
gestionar que debíamos aprender y replicar en futuras tribus y poblados que
pudiéramos gestionar.

166
Afortunadamente, algunos nos dimos cuenta que eso era un error, que más
allá de la brujería (fuerza bruta) había ciencia (ingeniería del software) y
abandonamos la cultura bárbara (otros aún no se han dado cuenta).

Y nos dimos cuenta de que la culpa de que el software tuviera incidencias no


era de echar pocas horas, era de que el testing era prehistórico, que los
problemas en el desarrollo no eran “por gente poco comprometida que no
enviaba correos a las 5:00 a.m.”… era culpa de gente que no había visto un
libro de desarrollo software en su vida, o era de que no había control de
versiones.

6.1.3 SLACK: QUEMAR AL EQUIPO NO SE TRADUCE EN MAYORES


RESULTADOS

La traducción de Slack sería algo así como “tolerancia”, “distensión”, en


nuestro caso, “no apretar tanto a la gente”, etc.

En 2001, el popular Tom DeMarco, publicó Slack: Getting Past Burnout,


Busywork, and the Myth of Total Efficiency (DeMarco T. , 2011)de
traducción difícil, pero que sería algo así como: “No fuerces tanto a la gente:
pasa del trabajo que aporta poco valor, quema a la gente, y el mito de la
eficiencia total”.

En el libro DeMarco vuelve a recalcar el hecho de que eso de que un equipo esté
muy ocupado y sobresaturado… no se traduce en mayor efectividad y
beneficios.

En un destacado y elaborado artículo publicado por (Robinson, 2008), hasta


idolatrado en ciertos ámbitos, expone y detalla el problema y carencia de
sentido del modelo Crunch Mode en tecnología.

167
Según comenta Robinson, más de un siglo de estudios, en varios sectores,
muestran que la productividad cae inmediatamente al iniciar las horas
extraordinarias y sigue bajando hasta que, en aproximadamente ocho
semanas de 60 horas, el trabajo total realizado es el mismo que lo que se
habría hecho en ocho semanas de 40 horas. Trabajar más de 21 horas
continuadas, comenta, es equivalente a estar ebrio.

Según lo anterior elaboró sus 6 Leyes:

• Lección 1: La productividad varía a lo largo de la jornada de trabajo,


la mayor productividad ocurre a las cuatro / seis primeras horas.
Después de muchas horas, la productividad se aproxima a cero;
eventualmente se convierte en negativa.

• Lección 2: La productividad es difícil de cuantificar para los


trabajadores del conocimiento.

• Lección 3: 5 jornadas a la semana de 8 horas maximizan la


producción a largo plazo en todas las industrias en las que esto se ha
estudiado en el último siglo. ¿Qué nos hace pensar que en tecnología
estamos exentos a esta regla?

• Lección 4: Con 60 horas por semana, la pérdida de productividad


causada por trabajar más horas supera las horas extras trabajadas en
un par de meses.

• Lección 5: El trabajo continuo reduce la función cognitiva un 25%


por cada 24 horas. Múltiples noches de trabajo consecutivas tienen un
efecto acumulativo grave.

168
• Lección 6: Las tasas de error suben con el número de horas trabajadas
y sobre todo con la pérdida de sueño. Con el tiempo la catástrofe ocurre
¿Es un riesgo que realmente puedes darte el lujo de tomar?

Al final, parece que no iba tan desencaminado Kent Beck cuando añadió a su
eXtreme Programming el Ritmo Sostenible.

6.1.4 NO PUEDES MEDIR LA PRODUCTIVIDAD DE UN


PROGRAMADOR (APLICABLE A TRABAJADOR DEL
CONOCIMIENTO)

“Puedo decirle a un obrero que a las 7am sea productivo. Pero ¿puedo decírselo a un ingeniero?”

-- Akio Morita (fundador de Sony)

Este mensaje se ha tratado y estudiado en numerosas ocasiones, a lo largo de


la historia de la informática, pero parece no haber calado lo suficiente en
ciertas empresas y gestores. No puedes medir la productividad de un
programador, por ahora… no sabemos cómo hacerlo.

Comenzando por lo básico, productividad es la relación entre la entrada a una


actividad y su salida. Si en mi exprimidor de frutas meto 5 manzanas y
saca 5 litros de zumo su productividad es 5 litros por cada 5 manzanas. Si
otro exprimidor saca 10 litros por cada 5 manzanas, será el doble de productivo
que el anterior.

Por tanto, para medir la productividad tienes que medir la “salida” de una
actividad. Para medir la productividad de una actividad intelectual,
pongamos por caso el desarrollo software, tienes que medir la salida del
desarrollo de software, pero… no podemos medir la salida de un desarrollo (o
aún no sabemos cómo).

169
Aún hoy hay quien se empeña en medir la productividad, la “salida”, con
líneas de código, que para actividades que no son el desarrollo de software,
sería similar a contar las páginas o párrafos que tiene el informe que ha hecho
una persona. Decenas de expertos han tratado lo erróneo de esta suposición
(Fowler, 2003).

Para un mismo requisito, historia o tarea, Kenobi puede implementarla en 100


líneas de código y Anakin en 1000. Aparentemente, Anakin sería más
productivo… pero no necesariamente. De hecho, puede haber creado 900 líneas
de código innecesarias, incluso con código duplicado, que luego nos tocará
mantener, a más líneas de código innecesarias más costes innecesarios.

Es como si en el caso del exprimidor, tuviésemos los 10 litros de zumo hechos


por Anakin, pero una gran parte de esos litros está en mal estado, pero no
sabemos exactamente cuántos. Si, efectivamente, son 10 litros de Anakin
frente a 5 de Kenobi… pero parte de los 10 litros de Anakin están
envenenados.

Tampoco podemos asumir, aunque suene raro, el efecto contrario: a menos


líneas de código más productividad. Ya que puede que entonces Kenobi se
haya dejado por el camino los mínimos de un buen diseño, unos mínimos
para la mantenibilidad futura, etc.

Y si, además, el testing lo hace otra persona, no Anakin... meteríamos otra


variable, lo bien que ha comprobado el tester lo bien hecho que estaba el
desarrollo de Anakin. Y si encima contamos con que el número de pruebas
necesarias para estar seguros 100% “tiende a infinito”, y al final solo hacemos
un muestreo, muestreo que depende del “olfato del tester”.

170
¿Y las actividades no directamente relacionadas con desarrollo? ¿Y si Kenobi
no hizo más porque le encargaron solucionar un error en algo que otra
persona implementó hace tiempo? ¿Cómo metemos esto en el modelo?

Los “peros” en este punto son muchos como para poder acabar con un modelo
preciso de cálculo de productividad, lo que hace que, erróneamente... muchos
gestores lo simplifiquen a medir horas (otro Cobra Kai, ver pág.60)

Si premio la productividad medida en líneas de código puedo estar cavando, y


pagando, mi propia tumba.

Y conocer exactamente cuantas líneas de código deberían ser las idealmente


necesarias para programar una necesidad de negocio es, por ahora, algo
imposible de calcular.

Pero que matemáticamente no podamos calcular la productividad... no quiere


decir que no exista, porque muchas veces sí intuimos que Kenobi es más
productivo que Anakin. A este efecto, sensación, intuición, muchas veces le
llamamos con frases como que “es mejor programador”, “es el que más sabe”,
“es el más rápido programando y además lo hace bien”, tenemos la sensación,
pero no podemos ponerle un número.

6.2 LA VELOCIDAD DEL EQUIPO... ALGO MÁS PRECISO QUE


CONTAR HORAS

Resumidamente, la velocidad es el trabajo, que suponemos (ya hablaremos de


por qué he utilizado la palabra suponemos) que aporta valor (es decir, lo pidió
un Product Owner), terminado (superó el Definition of Done) por todo el
equipo (multifuncional) al final de un trozo de tiempo, típicamente el Sprint.

171
Normalmente, en muchos equipos que usan Scrum, la velocidad se calcula
sumando el número de puntos historia, que se estimaron para cada historia de
usuario que finalmente se terminó al finalizar el Sprint (si estos conceptos se
te escapan, puedes leer más de esto en Guía de Superviviencia Agil..
estimación con puntos historia que escribimos hace unos años (Garzás &
Navarro, 2015) y en el libro Cómo Sobrevivir…a la planificación de un
proyecto ágil (Garzás, 2013)

Si el equipo completó 3 historias en el Sprint, cada una estimada con 5


puntos historia, entonces su velocidad en ese Sprint fue 15.

Esta aproximación es un cambio sustancial frente a medir productividad en


horas trabajadas (ya ni te cuento en líneas de código programadas):

• Primero, porque la historia de usuario es un trabajo de equipo, ya no


intentamos medir productividad por persona, que vimos que era
imposible, sino que lo hacemos por parte de todo el equipo
multifuncional.

• Segundo, porque deja en un papel muy secundario el concepto de la


hora, que deja de ser lo único y más importante, ahora,
independientemente de las horas dedicadas, y de cuándo se trabajó (si
fue por la tarde, por las noches o solo los fines de semana), medimos el
trabajo completado.

Si eres un manager, si cambias de una gestión por horas a una por


velocidad… vas a ver que no tiene comparación, y al primero que le va a
encantar va a ser a ti, que vas dejar de ser el “policía” de la hora, y te lo digo
por experiencia, porque que he vivido muchos cambios de hora a velocidad.

172
Además, ahora tenemos como equipo ágil una potente herramienta para ir
mejorando, Sprint a Sprint: la velocidad. Medir la velocidad nos vale para
mejorar, reflexionar, buscar qué desperdicios la frenan...

6.3 DESPERDICIOS QUE FRENAN LA VELOCIDAD DEL EQUIPO

La velocidad, entendida como la suma de los ítems (o la suma de los puntos


historia de cada uno de esos ítems) que se terminan en un trozo de tiempo
(típicamente un Sprint) y que había pedido el Product Owner (ojo, recalco lo
de “había pedido el Product Owner”, no conteo de tareas técnicas), se ve
condicionada especialmente por lo que solemos llamar... el desperdicio.

El desperdicio (también conocido como Waste en inglés) fue una de las


principales aportaciones de Taiichi Ohno (1912 – 1990), el artífice del Lean,
quien introdujo el principio fundamental de que las mejoras y la manera de
trabajar debían eliminar desperdicios: todo aquello innecesario, todo de lo que
se puede prescindir, todo aquello que no aporta valor, todo lo que frena tu
objetivo final (felicidad, rentabilidad, liderazgo del sector, etc.).

Aplicado a tecnología, en el libro, Lean Software Development (Poppendieck &


Poppendieck , 2003) se incluyen entre los siete principios del Lean Software…
eliminar desperdicios.

Desperdicios típicos son las interrupciones, los cambios de contexto (tener un


montón de tareas abiertas e ir saltando de una a otra), la baja calidad
software, los documentos que nadie leerá jamás, las especificaciones de cosas
que nadie jamás implementará, las especificaciones de casos de prueba que
nunca nadie ejecutará, las reuniones eternas sobre temas en los que nunca
nadie se pondrá a trabajar, las funcionalidades programadas en una
aplicación que ningún usuario utilizará, etc.

173
Si analizas tu entorno de trabajo, el equipo en el que estás, deberías echarle un
vistazo a si hay mucho desperdicio. La cultura de búsqueda y eliminación de
desperdicios debería ser para siempre, Kaizen, como te contaré en un próximo
capítulo.

No obstante, te voy a dejar algunos desperdicios clásicos que aplican a la parte


humana, a los equipos (por no irme del tema no entraré en otros como pueden
ser técnicos o de malos procesos).

6.3.1 EL DESPERDICIO DEL TAMAÑO

Aún hay quien, erróneamente, piensa que un equipo… cuanto más grande
mejor, que aumentar el número de personas de un equipo es la única manera,
la manera más racional y eficiente, de generar más y recortar tiempo.

Escribiendo estas líneas no dejo de recordar aquel equipo de desarrollo en el


que trabajé hace años, que cuando yo llegué era ya de 20 personas, y al que,
por los constantes fracasos e imposibilidad de cumplir fechas y mínimos de
calidad… los responsables de la empresa le añadían cada vez más y más
personas. Obteniendo cada vez peores y peores resultados y con un gasto
económico mayor. Quizás lo peor fue que nunca lograron entender por qué
esto sucedía.

Un señor llamado Lawrence Putnam, tremendamente desconocido para la


mayoría de los responsables de proyectos, pero cuyos trabajos han sido
tremendamente determinantes para entender la gestión de proyectos en el
software, elaboró hace unos años una investigación tan importante como
fascinante. Tal fue su influencia, que inspiró el por qué muchos frameworks
ágiles recomiendan trabajar con equipos pequeños (aproximadamente 7
personas, esto me lo contó el propio Jeff Sutherland, uno de los padres de
Scrum, en un workshop en Estocolmo).

174
Putnam revisó 500 proyectos software, los cuales estaban en el rango de entre
35.000 y 95.000 líneas de código. Y clasificó todos esos proyectos en cinco
grupos, en función del tamaño de sus equipos, los que tenían equipos de entre
1,5 - 3 personas, de 3 - 5, de 5 – 7, de 9 - 11 y de 15 - 20.

Los resultados de Putnam evidenciaron algo que mucha gente


sospechaba: cuando el tamaño del equipo crecía, más allá de un número de
personas, el esfuerzo, lógicamente aumentaba al haber más gente, pero el
tiempo de proyecto no se reducía. Equipos más allá del rango de entre 5 y 7
personas aumentaban en esfuerzo… pero también el calendario.

Cuando el tamaño del equipo se incrementaba del rango 1,5 – 3 al de 3 – 5 el


calendario, el tiempo, se acortaba y el esfuerzo se incrementaba. Cuando el
tamaño pasaba de 3-5 a 5-7 ocurría lo mismo. Pero cuando se pasaba de 5-7 a
9-11 tanto el esfuerzo como el calendario se incrementaban. En el rango 15 –
20 la situación era peor.

Los equipos con un número mayor a 7 personas se veían constantemente


penalizados por:

• La coordinación mayor que requerían esos equipos grandes, por las


mayores y más numerosas actividades de gestión.

• El incremento de las rutas de comunicación entre sus miembros, lo


cual crea más errores. A más personas, más líneas de comunicación
aparecen.

Quizás a alguien se le estarán pasando por la cabeza en estos momentos


preguntas del tipo a “bueno, ¿y cómo aplica todo esto a empresas con 200
personas?”, pues, según todo lo anterior, si quieren lograr la máxima
eficiencia deberían reestructurarse en muchos equipos de 7 personas (aquí

175
entraríamos en otra área que se nos iría del tema del libro... escalar –o des-
escalar- agilidad).

En este sentido, en 1975, Brooks escribió y popularizó, aquello que “añadir


gente a un proyecto software con retraso… hace que se retrase más”, asunto
que posteriormente se ha conocido como la Ley de Brooks (Brooks, 1975).

Aunque Brooks reconoció explícitamente que la “Ley” es una “simplificación


bárbara”, que hay que matizar según el caso, destacó dos factores por los que
la introducción de los recién llegados frena a los presentes:

• El tiempo que se necesita para que aprendan lo suficiente como


para ser productivos, que, además, requerirá durante ese periodo
de las personas que ya estaban, que han de enseñar a los nuevos.

• El aumento de las vías de comunicación, lo que implica, entre


otros, más gasto en coordinación del trabajo, gestión, etc.

Muchos habréis sufrido la Ley de Brooks, siempre que sale el tema cuento
aquel proyecto, aquel en el que me tocó lidiar con que el cliente, por los
continuos retrasos, se empeñaba en pagar e incorporar a nuestro equipo grupos
de 10 becarios: “Pero si os pago yo gente… ¿cómo me podéis decir que eso no
acelerará la entrega? “. Pobre hombre (y me refiero a este quien aquí escribe).

No obstante, y aunque nuestro subconsciente, experiencia y batallas, nos


dicen que esto de “añadir gente a un proyecto software con retraso hace que se
retrase más” es cierto, la cosa no es tan trivial. Y a día de hoy, casi 50 años
más tarde, la pregunta de cómo y cuándo introducir nuevas personas, o
equipos, sigue sin estar clara.

176
¿Retrasa siempre añadir gente? Depende del momento. Por ejemplo, algunos
antiguos trabajos de la NASA (Landis, y otros, 1992) recomiendan
comenzar con un número pequeño de personas de alto nivel e ir aumentando
el número.

No tenemos fórmulas mágicas, pero si sabemos que el tamaño es peligroso y


que lo mejor es tender siempre al menor número de personas.

6.3.2 EL DESPERDICIO DE LA INTERRUPCIÓN

Hace ya años, en el 85, DeMarco y Lister, crearon los Coding War Games
(DeMarco & Lister, 1985), una competición que premiaba la velocidad y
calidad del desarrollo software y en la que participaron 166 desarrolladores de
35 organizaciones diferentes.

Entre otras, la competición se usó como un experimento para estudiar hasta


qué punto el entorno físico influyó en la obtención de resultados.

Los organizadores de la competición pidieron a los participantes que les


proporcionaran información sobre las características de su entorno físico de
trabajo, concluyendo el estudio en que los mejores desarrolladores software
fueron los que además disponían de espacios físicos de trabajo, con menos
interrupciones, llamadas de teléfono, mayor privacidad, etc. Hasta tal punto
que los desarrolladores que ocuparon el 25% de las mejores posiciones, y que
disponían de los mejores entornos físicos, obtuvieron una productividad 2,6
veces superior a aquellos que ocuparon el 25% de peores posiciones.

La frecuencia en que se olvida la influencia del entorno físico en la


productividad se ha convertido en uno de los principales problemas de
productividad en las organizaciones de desarrollo software.

177
¿Pasas días y días trabajando con la sensación de no terminar nada? Si
algún día trabajas desde casa, en el avión, en un hotel… ¿tienes la sensación
de que ese día es 100 veces más productivo que cualquier otro trabajando en la
oficina?

Si te pasa lo anterior, probablemente, trabajas en un entorno propenso a la


interrupción, que impide la concentración. Y en trabajos intelectuales, como
programar, escribir artículos, post, diseñar, etc., las interrupciones son un
mal demasiado frecuente que afecta enormemente a la productividad.

En 2010, se publicó otro trabajo muy interesante sobre el tema, (Parnin &
Rugaber, 2010) donde se describe un análisis que hicieron con 86
programadores, de los que grabaron 10.000 sesiones trabajando con Eclipse y
Visual Studio, más una encuesta a otros 414 programadores. Algunas de las
conclusiones fueron:

• Lo normal es que a un programador le lleve de 10 a 15 minutos


retomar el nivel de concentración después de haber sido interrumpido.
Así que, con cuatro interrupciones, cuatro “perdona que te moleste,
pero…”, cuatro llamadas al móvil, se pierde una hora de trabajo.

• Solo el 10% de las sesiones de programación, una vez interrumpidas,


reanudaron su actividad en menos de un 1 minuto.

El problema es que hay entornos, empresas, oficinas, etc., en las que lo de


interrumpir es más la norma que la excepción. Si hiciésemos un cálculo de las
horas que se pierden al día, semana, año, etc., por las interrupciones… más de
uno se tomaría muy en serio este tema.

178
Estrategias para Controlar las Interrupciones

Te voy a contar lo que yo he visto, usado y probado para controlar las interrupciones:

Fija horas de no interrupción, por ejemplo, de 9:00 a 12:00.

Habilita espacios para hablar separados de los espacios para pensar.

Si quieres algo de alguien, salvo que sea cuestión de vida o muerte, pídeselo por chat, Slack
o similar, pero…

Deshabilita las notificaciones automáticas del chat, correos, Slack…, para ver esas
notificaciones cuando quieras… no cuando quieran ellas.

Usar carteles, que puedes poner en tu mesa, indicando que estás concentrado y no quieres
que te molesten.

179
180
6.3.2.1 Un espacio para hablar y otro, separado, para pensar

Recuerdo que en una de las empresas de desarrollo en las que trabajé, los
puestos de trabajo, las mesas de todos, estaban dispuestas en dos grandes
filas, dejando un pasillo en el centro.

Desconozco cuál fue el origen, pero un día en aquel pasillo aparecieron dos
balones, uno de fútbol y otro de rugby. Y ello degeneró en la costumbre de que
cuando alguien pasaba le daba una patada a uno de los balones, y si
coincidía con alguien más … pues hasta se organizaba una
“pachanga” (dícese de partido de futbol informal) en el pasillo.

Había responsables de la empresa que veían aquello Cool, molaba, porque era
un “rollo” tipo Google. Servía para relajar, quitar estrés, daba imagen
moderna, etc.

Pero no sé si aquellos responsables llegaron alguna vez a ser conscientes de


que aquello también servía para romper la concentración de 30 personas, que
acababan siendo el público de las “pachangas”. Y supongo que tampoco eran
conscientes de que interrumpir a quien programa, o al que realiza cualquier
actividad intelectual, hace que su productividad disminuya.

Si como vimos, se habla de que se pierden una media de 15 min de trabajo de


una persona concentrada cuando es interrumpida (Parnin & Rugaber, 2010),
dos “pachangas” por día, 2 * 15 min = 30 min, por 30 personas, 900 min de
trabajo perdidos por día, que son 15 horas al día, 75 horas a la semana, casi el
trabajo de dos personas totalmente perdido a la semana.

Me encantan las oficinas con juegos y salas de recreación, modernas, etc.


Pero, por favor, separar las salas de recreo de los lugares de concentración.

181
Partiendo de la premisa, que comentamos antes, de que interrumpir a quien
programa hace que su productividad caiga, la oficina en la que trabaje un
grupo de desarrolladores (o cualquier grupo de profesionales que realicen
tareas que requieran concentración) debiera ayudar a eso, a evitar las
interrupciones y la falta de concentración.

Hace tiempo nosotros, en nuestro entorno de trabajo, nos pusimos la norma de que
cuando alguien quiere algo de otro, se lo escribe por chat, en vez de gritárselo y hacer
que el resto de la gente gire la cabeza y empiece a opinar sin necesidad. También al
pedirnos las cosas por chat, el que responde no tiene por qué contestar
inmediatamente, interrumpiendo aquello en lo que estaba.

No hay una forma perfecta de organizar el entorno de trabajo, y al final lo


que más influye es la cultura de la organización, y que el equipo sea
consciente del impacto de las interrupciones.

No deja de ser una lástima pasar por empresas y empresas, y escuchar aquello
de “mañana trabajaré desde casa (o en la biblioteca) porque tengo que
terminar tal cosa, y si me quedo aquí en la oficina no la voy a terminar”.

6.3.2.2 Trabajar con música hace que seas menos productivo

En los 60, investigadores de la Universidad de Cornell realizaron una serie de


experimentos sobre los efectos de programar mientras se escucha música.
Dividieron un grupo de estudiantes de informática en dos grupos, en uno

182
aquellos a los que les gustaba estudiar con música de fondo y otro con
aquellos a los que no.

Colocaron a cada grupo en una habitación separada. Una habitación en


silencio para el grupo al que le gustaba trabajar sin música y una habitación
equipada con auriculares para el otro grupo.

A todos los participantes se les entregó un problema de programación en


Fortran, para trabajar en él a partir de ciertas especificaciones.

Los participantes en las dos habitaciones realizaron el ejercicio prácticamente


con misma velocidad y precisión.

La parte del cerebro que se requiere para la aritmética y la lógica no se ve


influenciada por escuchar música. Pero hay una parte del cerebro que sí que
escucha la música.

La especificación requería una transformación de números. Por ejemplo, los


participantes tuvieron que cambiar cada número dos dígitos a la izquierda y
luego dividir por 100 y así sucesivamente, una docena de operaciones en total.

Aunque la especificación no lo decía, el resultado final de todas las


operaciones era que cada número de salida era igual a su número de entrada.
Algunas personas se dieron cuenta de ello y otras no. La gran mayoría de
aquellos que lo descubrieron estaban en la habitación en silencio.

Muchas de las tareas diarias realizadas por los profesionales requieren del
lado izquierdo del cerebro, y la música no interfiere ahí, ya que es el lado
derecho del cerebro el que procesa la música.

Pero los trabajos intelectuales, de concentración, etc., como la programación o


similares, no solo necesitan del lado izquierdo del cerebro, aquella parte

183
encargada de la lógica, también requieren del ingenio y las sensaciones, que
se procesan en el lado derecho.

Esos descubrimientos ocasionales, esos “¡ahora caigo!”, “se me acaba de


ocurrir”, etc., que pueden ahorrar meses o años de trabajo, la creatividad,
implica al hemisferio cerebral derecho. Pero si el lado derecho del cerebro está
escuchando a todo volumen La Mataré de Loquillo, Baba O’Riley de los Who
o Thunderstruck de AC/DC, por poner sólo algunos casuales ejemplos, se pierde
la oportunidad del salto creativo.

6.3.3 EL DESPERDICIO DEL CAMBIO DE CONTEXTO

Un libro con datos bastante interesantes sobre gestión de proyectos y el


comportamiento humano es el de Gerald Weinberg, Quality Software
Management (Weinberg, 2011), famoso, principalmente, por un estudio que
exponía el desperdicio de tiempo que conllevaba tener a las personas en más de
un proyecto.

Concretamente, Weinberg lo sintetizaba en esta tabla:

184
Según el cálculo de Weinberg, añadir un solo proyecto más, adicional a aquel
en que estamos trabajando, genera pérdidas de un 20% del tiempo. Agregar
un tercer proyecto, crea pérdidas de casi la mitad del tiempo.

Estas pérdidas de tiempo vienen del cambio de tareas, de “trasladar los


pensamientos” de un proyecto a otro distinto. El efecto que se produce es muy
similar a las interrupciones, aquello que ya comentamos.

Tener abiertas demasiadas cosas a la vez, reduce la efectividad por los cambios
de contexto, cosas que se empiezan y no se terminan, se empiezan otras,
vuelta a la primera, vuelta a pensar en qué estado quedó, etc.

Por razones como estas, las de evitar el cambio de contexto al que lleva tener
muchas tareas abiertas a la vez y, el desperdicio que ello conlleva, la práctica
Lean de Kanban limita explícitamente, con un número, el máximo de tareas

185
que pueden estar abiertas (lo que se conoce como “limitar el WIP o Work In
Process).

Limitar el WIP es una técnica para controlar el cambio de contexto, otra, que
puede usarse independientemente o de manera complementaria, es el
Swarming.

6.3.4 PRÁCTICA: EL SWARMING

Aunque la idea del Swarming (cuya traducción sería algo así como
“enjambre”), una práctica también conocida como “flujo continuo de una sola
pieza” (One-Piece Continuous Flow), es muy antigua (se olvida o desconoce
en demasiadas ocasiones). Si sigues Scrum desde hace tiempo, y lo haces
bien, consciente, o inconscientemente, debieras haber aplicado el Swarming.

La idea es dedicar y concentrar todos los esfuerzos (del equipo o gran parte del
mismo) a terminar el ítem (típicamente una Historia de Usuario) de mayor
valor (típicamente el primero en el Backlog).

Todo lo necesario para completar lo más pronto ese ítem se hace tan en paralelo
como sea posible. Esto tiene varias implicaciones:

• Cada miembro del equipo se centra en un solo ítem o historia de


usuario y todo el mundo debe ayudar, en lo posible, a que se termine
la historia de mayor prioridad. El Swarming lleva a potenciar la
multifuncionalidad del equipo.

• El tiempo entre el momento en que el equipo comienza a trabajar en


un ítem y este se termina (Definition of Done superado) es lo más
corto posible.

186
La idea del Swarming es trabajar todos juntos para cerrar algo… más que
trabajar cada uno en sus tareas (Sprint backlog) y que los ítems (Product
Backlog) que aportan valor no se cierren hasta el final.

Esto es tan importante que hasta los Dailys debieran orientarse en línea con el
Swarming: “qué hemos hecho, y qué vamos a hacer, para, como equipo,
terminar ese ítem lo más pronto posible”.

Knibeg en 2007 creó un patrón de trabajo derivado del Swarming, el Rey –


Sirviente (Kniberg, 2007), que, simplificadamente, consiste en lo siguiente:

• Cualquiera que esté trabajando en la historia (ítem) de mayor


prioridad es Rey.

• Todos los demás miembros del equipo son sirvientes.

• Si quieres ser uno de los Reyes tienes que ayudar con la historia de
máxima prioridad.

• Cuando un Rey necesita ayuda, los siervos ofrecen inmediatamente


sus servicios.

• Un Siervo no puede interrumpir a un Rey.

• Tan pronto como la historia de máxima prioridad está terminada,


cualquiera que trabaje en la siguiente historia es ahora Rey.

187
6.3.5 PRÁCTICA: TIME BOXING

Desde que conocí la técnica de Time Boxing me ha parecido de lo más efectiva,


a la vez que simple, obvia, y curiosamente desconocida, en lo que a técnicas de
gestión del tiempo se refiere.

El Time Boxing (cuya traducción vendría a ser “cajas de tiempo”, que como
ves queda un poco raro, por lo que usaré las palabras en inglés), se basa en que
todo “tiempo” en un equipo debe tener un máximo, conocido por todas las
personas del equipo.

Es decir, toda reunión o evento debe tener un máximo temporal, conocido antes
de empezar. Y llegado ese tiempo máximo la reunión se termina. Los Daily
Meeting, por ejemplo, son 15 min., y llegados los 15 min… se acabó la
reunión.

Si utilizas Scrum, quizás inconscientemente, usas el Time Boxing, los


Sprints y cualquier evento son Time Boxing, ya que tienen un tope temporal
que no ha de superarse.

No obstante, esta técnica se utilizaba en software mucho antes de llegar


Scrum a nuestras vidas. Uno de los primeros modelos ágiles, DSDM
(Dynamic Systems Develpment Method), ya hacía uso de ella. McConnell en
su Rapid Development (McConnell, 1996) ya la recomendaba como una de las
“buenas prácticas”. Y eXtreme Programming igualmente la contempla.

Al principio, sobre todo si vienes y vives en un entorno de reuniones


interminables, de esas en las que la gente pasa más de media reunión
pensando “en sus cosas”, puede que te cueste implantar la cultura del Time
Boxing, pero se puede, te lo digo por experiencia.

188
189
Yo he probado de todo para controlar el Time Box, en una ocasión incluso (y la
idea la tomamos de Atlassian) usamos un pollo de goma, que emite un sonido
estridente al apretarlo, para que el facilitador de la reunión controlara los
tiempos. Sé imaginativo y divertido.

6.3.6 PRÁCTICA: POMODORO

Cuenta la leyenda que cuando el italiano Francesco Cirillo comenzó sus


estudios universitarios buscó desesperadamente una técnica de concentración
que le ayudase a ser más productivo… y la encontró. Y la inspiración para
encontrarla vino de esos típicos “pomodoros”, tomate en italiano, que hay en
muchas cocinas y que se usan para medir el tiempo que se cocinan los
alimentos.

Esta técnica consiste en poner el reloj del pomodoro a cero y ponerse a trabajar
en una tarea ininterrumpidamente, hasta que transcurran 25 minutos,
intervalo de tiempo al que llamamos pomodoro. Terminado este tiempo
corresponden 5 min. de descanso. Terminado el descanso, comienza otro
pomodoro, y después otro descanso de 5 min. Así sucesivamente, hasta el
cuarto pomodoro, al que le corresponde una pausa de 15 min., transcurridos
los cuales comienza otra vez la serie.

Personalmente, llevo utilizando dicha técnica desde hace ya bastante tiempo.


Te resumo más específicamente cómo yo la uso.

Dedicar un pomodoro a una tarea no significa que tengas que terminar la


tarea en un único pomodoro. Hay tareas que requieren, obviamente, mucho
más de 25 min. Pero, eso sí, y esto es lo verdaderamente importante, dedicar
un pomodoro a una tarea significa estar esos 25 min. solo y exclusivamente
dedicado a esa tarea. Y a nada más. Nada. Ni correo, ni twitter, ni llamadas.

190
A nada. Durante su duración apágalo todo. Aquí debes ser muy auto-
disciplinado.

Obvio decir, que, por desgracia, el número de pomodoros por día varía mucho.
Hay días con muchos, en los que terminas sintiéndote muy realizado, y hay
días de reuniones, llamadas, viajes, etc., en los que no hay pomodoros. Pero los
días que si puedas utilizarlos... utilízalos, porque vas a notar la diferencia y
el incremento de productividad.

Te dejo 3 características que, para mí, hacen tan importante trabajar por
pomodoros:

1. Te crea un hábito, una métrica de productividad. Antes de conocer


esta técnica, mantenía una lista de tareas a las que asignaba un
tiempo variable. Por ejemplo, empezaba la tarea 1 y decidía dedicarle
50 min, luego a la 2, 30 min. Pero mantener tiempos fijos me ha
ayudado a lograr un mayor hábito y a disponer de una métrica,
piensas en términos como… “¿cuántos pomodoros dura esto?”

2. Realización y consciencia del trabajo realizado. Te hace ir más rápido,


ya que eres realmente consciente del tiempo que le dedicas a cada
cosa, y empiezas a pensar cosas como… “a esta tarea no debo dedicarle
más de 2 pomodoros”, “ya llevo 3 pomodoros con esto… tengo que
terminar ya”, etc.

3. Te ordena el día y te baja a la realidad… a la realidad de lo productivo


que realmente has sido. Sí, puedes estar cansado al final del día, con
sensación de haber estado muy liado, pero… ¿cuántos pomodoros has
hecho? Muchas veces se nos pasa el día (mes, año, etc.) liados en
tareas no productivas y no somos conscientes de ello.

191
6.3.7 EL DESPERDICIO DE LOS MALOS ENTORNOS FÍSICOS

Oye, en serio, que si no es porque me puse a preparar una ponencia y porque


pensé en darle un toque más personal hablando de mi experiencia,
ampliándola con fotos, sino es por ello… no me habría dado cuenta de los
sótanos en los que he trabajado, programado, disfrutado, etc., a lo largo de mi
carrera profesional.

Pero, es más, ya dando la charla, según los enumeraba… ¡no me sentía solo! Y
veía entre los asistentes esas caras de “y yo también”. Caras que corroboré
cuando después de la charla pude hablar con muchos de ellos que me decían…
“Javier cómo me he visto identificado, ¡yo también he programado en un
montón de sótanos!”

De aquella charla, recuperé de las profundidades del disco duro la foto del
sótano de un periódico para el que trabajé, aquel en el que había que sentarse
con “el plumas” del frío que hacía, las fotos del sótano de un antigua estación
de otra organización para la que trabajé, que solía inundarse si llovía mucho
(nunca nos tocó ver “en directo” ninguna inundación allí trabajando, pero
dedujimos que así pasaba al llegar algún lunes y ver tierra mojada y
cucarachas muertas en el suelo), las de un sótano almacén de otra empresa
para la que trabajé, cuyos baños, para más emoción, se inundaban de vez en
cuando, etc.

Qué recuerdos… los sótanos, sí.

Pero que no te quede una mala sensación, que no, en serio, seguro también
has disfrutado de algún sótano y de lo que un sótano une a la gente, team
building de sótano que le llaman algunos, el compañerismo que genera (va
en serio), las buenas historias que da para contar luego, para poner fotos de
sótanos en un PowerPoint.

192
6.4 PERO... NUNCA OLVIDES QUE LO MÁS IMPORTANTE ES EL
VALOR

Habiendo citado la velocidad, como una herramienta útil para gestionar la


productividad del equipo, debo advertirte de que tengas cuidado con sólo
guiarte por la velocidad y olvidar el valor que tiene aquello que hace el equipo.
Puedo tener buenas velocidades y crear productos que no aporten valor.

El valor, sin tener una definición exacta, es, como decía (Jeffries, 2015), “lo
que tú quieres”, más concretamente, lo que esperan los usuarios potenciales
del producto que estás creando.

El valor es negocio. Si la velocidad es más responsabilidad del equipo técnico,


el valor es más del Product Owner.

El movimiento del #noestimates alerta de ello... ojo con las estimaciones, en


Puntos Historia, por ejemplo, que lo determinante es el Valor.

Utiliza los Puntos Historia... pero no olvides el Valor.

193
195
7. Mejora (Kaizen)

“El pasado puede doler, pero, tal como yo lo veo, puedes o huir de él o aprender”.

-- Rafiki, fragmento de la película “El Rey León”

“Nunca dejes que nadie te diga que no puedes hacer algo”.

-- Fragmento de la película “En busca de la felicidad”

La palabra Kaizen vendría a significar “mejora continua”. Proviene de las


palabras japonesas 改(“kai”) que significa “cambio” y 善 (“zen”) que
significa “bueno”.

Realmente, Kaizen es una filosofía que nace en Japón enfocada en que las
mejoras hay que hacerlas constantemente, no cuando detectamos un error o
un problema… ¡no!... las mejoras hay que estar haciéndolas siempre. Además,
siempre hay espacio para mejorar. Y la mejora es responsabilidad de todos, no
de un pequeño grupo.

El término Kaizen es creación de Masaaki Imai, en el libro Kaizen: The Key to


Japan’s Competitive Success (Masaaki, 1988). Desde entonces, esta filosofía se
ha hecho bastante popular.

Normalmente, es típico encontrar el pensamiento de que “si funciona no lo


toques”, pero la filosofía Kaizen nos recuerda que, aunque funcione...
podemos hacerlo mejor y si no lo mejoramos alguien lo hará y nos sacará del
mercado.

197
Una de las principales ideas de Kaizen es involucrar a todo el mundo, desde el
súper jefe hasta el becario. Todos están invitados, motivados, etc., para lanzar
sugerencias de mejora regularmente. Y siempre, de manera continua.

En la mayoría de los casos no se trata de ideas que supongan grandes


cambios, se basa en hacer pequeños cambios de forma constante.

Trabaja con la idea de que toda persona y sus ideas son un activo para la
empresa, en crear un entorno en el que se fomente el respeto mutuo y la
comunicación abierta. Las mejoras solo se pueden propiciar cuando la gente
está dispuesta a expresar sugerencias. Blame has no place in Kaizen (la culpa
no tiene cabida en Kaizen, en línea con lo que vimos en “Seguridad, la
cultura del error como base de la innovación”, pág.127).

En este capítulo voy a compartir contigo ideas y estrategias para ayudarte a


interiorizar el Kaizen en tu equipo, con el objetivo de la mejora y la evolución
constante del equipo ágil. De hecho, esta parte me parece clave si quieres poner
en práctica todo lo que te he contado antes, en los capítulos previos.

7.1 CULTURA DE REFLEXIÓN Y RETROSPECTIVA

— ¿En qué me equivoco? Pienso como muchos otros directores.

—¡Justamente!

—¿Qué quiere usted decir? —empiezo a sentirme incómodo y ofendido.

—Alex, si es usted «como muchos otros» —dice recalcando mis propias palabras— es que ha aceptado un
montón de cosas sin preguntarse si son correctas o no. Luego, realmente, usted no está́ usando la cabeza,
sino la rutina.

-- La Meta (Goldratt, 2010).

198
En tu empresa o equipo… ¿se reflexiona colectivamente sobre la experiencia
aprendida? Si es así… ¿esas reflexiones colectivas son constructivas o
simplemente son una reunión para desahogarse y luego quedan en nada?

Desde hace años, estas reuniones de reflexión, generalmente en el mundo ágil,


se han popularizado bajo el nombre de retrospectivas. Las retrospectivas
recuerdan a las antiguas reuniones de “lecciones aprendidas” y a los “post-
mortem”, pero con algunas diferencias.

Norm Kerth fue quien publicó el primer libro sobre retrospectivas, Project
Retrospectives: A Hand- book for Team Reviews (Kerth, 2001), donde se
describe a las retrospectivas como una reunión ritual de una comunidad al
final del proyecto, para revisar eventos y aprender de la experiencia. Nadie
conoce la historia completa, cada persona tiene un pedazo de la historia, por
ello el ritual de la retrospectiva es narrar colectivamente la historia y de ello
obtener sabiduría.

También en su libro Norm Kerth marca las diferencias que hay entre una
retrospectiva y una reunión de “Post Mortem” o de “lecciones aprendidas”: las
retrospectivas deben ser positivas y actuar como un catalizador para el cambio,
y no solo ser un analizador de problemas.

Este no es un libro sobre retrospectivas, hay muchos especializados en el tema,


pero sí que quiero dejarte alguna técnica para que comiences a trabajar la
reflexión.

Un libro destacado en lo que refiere a retrospectivas es el de Patrick Kua, The


Retrospective Handbook: A guide for agile teams (Kua, 2013). Kua creó una
útil y popular técnica para estructurar de manera más eficiente tus reuniones
de retrospectiva. A la técnica la llamó “estrella de mar”. Yo la uso mucho, pero
la suelo llamar “estrella de la muerte”. Se basa en usar un diagrama con

199
forma de estrella de mar que permite crear cinco áreas de cosas a tratar,
evitando así centrarse solo en lo bueno y lo malo.

Las cinco cosas a tratar son las siguientes:

• Continuar haciéndolo. Cosas buenas que han funcionado. Momento


para pensar en lo que perderíamos de no hacer una práctica en
particular.

• Menos de. Prácticas que no están ayudando tanto como se esperaba, o


que simplemente no son útiles en las circunstancias actuales.

• Más de. Prácticas que se desean probar más o que no se están


necesariamente aprovechando al máximo.

200
• Dejar de hacerlo. Obviamente para cosas que no son útiles o no
agregan valor.

• Comenzar a hacerlo. Sugerir cosas nuevas a probar.

Hay un montón de técnicas más para hacer retrospectivas en las que no voy a
entrar para no salirnos del tema principal del libro. Te recomiendo, por ejemplo,
leer el libro: Agile Retrospectives: Making Good Teams Great (Derby, Larsen,
& Schwaber , 2006) o la web de funretrospectives.com. Y, de hecho, es muy útil
que vayas probando, cambiando periódicamente de técnica de retrospectiva.

Profundiza y tómate en serio este tema para hacer evolucionar a tus equipos.
Sin ir más lejos en nuestro grupo de trabajo, tuvimos una época de
retrospectivas “de aquella manera” (ya sabes, en casa de herrero cuchillo de
palo), es decir, hacíamos retrospectivas cuando nos acordábamos, sin
conclusiones, sin estructura, sin guardar un mínimo de lo comentado, etc.
Tómatelo en serio, verás que sacas mucho valor.

7.2 VISUALIZA EL CAMBIO

Lo tengo comprobado, de los objetivos que me propongo para el próximo año, los
que realmente me tomo en serio son los que tengo escritos en un pósit que hay
pegado en la pared, frente a mi mesa de trabajo. Esos objetivos los veo todos los
días, son importantes y no se me van a olvidar.

Cuando alguien me pide consejo sobre cuál es el mejor soporte en el que tener
un tablero ágil siempre le digo que lo mejor es que estén… en la pared.

A este respecto, desde hace años yo tenía mi propia intuición, no sabía cómo
explicarla o argumentarla, era mi experiencia: prefiero ver un tablero (Scrum o
Kanban) en la pared antes que verlo en una herramienta, y si un libro es

201
realmente importante lo prefiero en papel, etc. Fue cuando di con el artículo
Why the Brain Prefers Paper (Jabr, 2013), cuando dije… ¡por fin! al final no
va a ser solo intuición, cabezonería o la edad. No va a ser solo cosa mía, va a
ser verdad que por mucho que nos empeñemos, leer en soporte físico, tipo
tablero o papel, no es lo mismo que leer en una pantalla.

Más allá de la base científica, de por qué el cerebro prefiere el papel a la


pantalla, en el caso concreto de la gestión de la mejora, tener las tareas,
objetivos, etc., en la pared, frente a una herramienta hace que:

• Las cosas importantes se vean nada más entrar a la oficina.

• Las vean otros roles que normalmente no van a entrar en las


herramientas software de gestión de proyectos, como comerciales,
gerentes, etc. Esto hace que el resto de personas vea qué hacemos, en
qué andamos.

• Permite que todos, todo el equipo, veamos lo mismo, discutamos sobre


lo mismo, de pie, que estemos alrededor de las tareas cuando hay que
tomar decisiones.

• Permite que, fácilmente, todo el equipo pueda hacer modificaciones, en


el mismo momento, rápida y visiblemente, frente a que pueda
hacerlas solo aquel que tiene el ratón.

Y esto no quita que periódicamente, cada cierto tiempo, alguien tome registro
de todo ello y pase la información que hay en la pared a la herramienta.

Sé que hay veces que es imposible, por distribución física de los equipos, pero
siempre que puedas, visualiza al máximo las cosas importantes de un equipo.

202
7.3 PRÁCTICA DE MANAGEMENT 3.0: CELEBRATION GRID:
VISUALIZA + EXPERIMENTA + REFLEXIONA

Juntando todo lo anterior, hay una técnica de Management 3.0 bastante útil:
Celebration Grids o Tableros de Celebración . Son una forma visual de
presentar – recordar - reflexionar sobre el resultado de un experimento, de
probar algo, y de si ese experimento tuvo éxito o no.

Los tableros tienen 3 columnas, una de “errores”, otra de “experimentos” (cosas


que estamos probando y sobre las que aún no tenemos una conclusión final)
y una tercera de “buenas prácticas”, aquellas que nos suelen funcionar. Cada
columna se divide en dos partes, una para cosas que han sido un “éxito” y otra
para cosas que han “fallado”.

Lo de tener una sección de “fallos” en la columna de “buenas prácticas” se


utiliza para representar casos anecdóticos, aquellos en los que una buena
práctica no siempre ha resultado como se esperaba. De manera similar, tener
una sección de “éxito” en la columna de “errores” nos viene bien para reflejar

203
prácticas que típicamente fallan pero que en algunas contadas ocasiones han
funcionado.

Los tableros de celebración nos ayudan a recordar buenas prácticas y a


aprender de los errores, evitando que se olviden, y nos animan a que
experimentemos y probemos nuevas prácticas.

7.4 LEAN CHANGE

El libro Lean Change Management de (Little, 2014), nos traslada la idea de


usar Canvas (cuya traducción vendría a ser lienzo, tablero) para organizar el
cambio en un equipo u organización.

Lean Change nos habla de varios Canvas, como el de mejoras, que funciona
bien cuando la incertidumbre es bastante baja y el del plan de gestión del
cambio, un plan de una página, más útil cuando la incertidumbre es alta,
cuando no se puede saber exactamente el camino exacto que seguirá la mejora
(que es lo típico).

Yo suelo usar mucho, en las llamadas transformaciones ágiles en las que he


participado, el Canvas del plan de gestión del cambio, y por ello te voy a hablar
un poco más de él.

El Canvas con el plan del cambio, típicamente, tiene una sección para el
“problema que se pretende resolver” (el objetivo), otra para “las opciones” que se
disponen en este momento para resolverlo, los “riesgos”, “obstáculos”
(impedimentos), las “acciones” (sección que viene a ser un Kanban de tres
columnas, ToDo – Doing - Done), “Métricas”, para ver el progreso y, por último,
“ideas” y feedback.

204
Hasta aquí la “versión oficial” del Lean Change… a partir de este momento,
ya sabes, experimenta y adapta. Yo he hecho uso en numerosas ocasiones del
Lean Change a la hora de organizar, y arrancar, la mejora de un equipo, con
las adaptaciones que se vieron necesarias.

Utilizar las ideas Lean y ágiles (las del Lean Change y todas las demás) en
el propio proceso de cambio y mejora continua es una idea altamente
recomendable. Es como he conseguido que muchas organizaciones
tradicionales arranquen y continúen el cambio.

Mi consejo es que formes un “grupo del cambio”, con roles claves de todas las
partes involucradas, incluyendo representantes de cada uno de los equipos
involucrados en la mejora.

205
Y que una vez que el “grupo del cambio” ha realizado el Canvas del plan de
gestión del cambio, fijéis “Sprints del Cambio” (por ejemplo, cada 2 semanas).
Estos Sprints tienen su propio tablero, con sus ítems del cambio a resolver
durante el Sprint del cambio, su Planning, su Review y su Retrospectiva.

7.5 LEAN COFFEE

Un Lean Coffee es una reunión estructurada, pero sin agenda, similar a una
unconference o a un open. Los participantes se reúnen y construyen la
agenda democráticamente al comienzo de la reunión.

En la gestión del cambio es muy útil porque da voz a todo el mundo, no sólo
de arriba hacia abajo.

206
207
208
209
Esta es la estructura que se utiliza normalmente en las reuniones de Lean
Coffee:

• El facilitador indica la temática de la reunión.

• El facilitador crea una un tablero con 3 columnas: por discutir,


discutiendo y discutido.

• Se facilitan pósits a los participantes y éstos apuntan en ellos ideas


sobre las que se les gustaría que se debatiera. Como en todo (Time
Boxing), es aconsejable limitar el tiempo en esta parte, por ejemplo, a 5
minutos. Los pósits serán el Backlog de la reunión.

• Una vez escritas las ideas para el debate, se pegan en un lugar visible,
por ejemplo, en la pared. Ahí se eliminan ideas duplicadas y se juntan
aquellas que sean similares.

• Se leen los pósits en voz alta. En el caso de que haya dudas aquel que
escribió el pósits puede hacer una breve explicación.

• Ahora se vota. Cada participante dispone de dos votos, se pueden usar


pegatinas, o marcar los pósits con un rotulador. Cada participante
puede poner sus votos en los pósits que quiera.

• El tema más votado pasa a la columna de discutiendo, el resto de


pósits se deja en la columna por discutir, ordenados según el número
de votos.

• Cada idea se discute durante un período de tiempo establecido,


normalmente 5 minutos. Una vez concluidos se puede votar para

210
continuar dos minutos más con esa idea, típicamente utilizando la
regla del pulgar: Pulgar arriba significa sí, a medias neutral y hacia
abajo no.

211
8. Bibliografía

Appelo, J. (2010). Management 3.0: Leading agile developers, developing agile


leaders (1ª ed.). US.: Addison-Wesley Educational Publishers Inc.

Appelo, J. (2016). Managing for happiness: Games, tools, and practices to


motivate any team. New Jersey: John Wiley & Sons, Inc.

Appleton, B. (2009). Agile self-organizing teams. Obtenido de Brad


Appleton's ACME Blog: http://bit.ly/2ud8NoN

Boehm, B. W. (1981). Software engineering economics. Englewood Cliffs,


N.J: Prentice Hall.

Brooks, F. (1975). The mythical man month (1ª ed.). Boston: Addison
Wesley.

Carnegie, D. (1936). Cómo ganar amigos e influir sobre las personas. Simon
& Schuster, Inc.

Cialdini, R. (2006). Influence: The psychology of persuasion. Harper


Business.

Cockburn, A. (2000). Characterizing people as non-linear, first-order


components in software development. 4th International Multi-
Conference on Systems, Cybernetics and Informatics. Orlando,
Florida.

Cockburn, A. (2001). ASD book extract: "Communicating, cooperating


teams". Obtenido de Alistair Cockburn: http://bit.ly/1pvAU7z

212
Cohn, M. (2010). The role of leaders on a self-organizing team. Obtenido de
Mountain Goat Software: http://bit.ly/2gXAWs1

Collins, J. (2001). Good to great: Why some companies make the leap... and
others don't (1ª ed.). Nueva York: HarperCollins Publishers.

Davis, A. M. (1995). 201 principles of software development. McGraw-Hill


Inc.,US.

Deci, E., & Ryan, M. (2002). The handbook of self-determination research.


Rochester: University of Rochester Press. Obtenido de
http://bit.ly/2udncB4

DeMarco, T. (2011). Slack: Getting past burnout, busywork, and the myth of
total efficiency (1ª ed.). Nueva York: Broadway Books.

DeMarco, T., & Lister, T. (1985). Programmer performance and the effects of
the workplace. Proceeding ICSE '85 Proceedings of the 8th
international conference on Software engineering. Los Alamitos,
CA.: IEEE Computer Society Press.

DeMarco, T., & Lister, T. (1987). Peopleware: Productive projects and teams.
Dorset House Publishing Co Inc.,U.S.

Derby, E. (2011). Misconceptions about self-organizing teams. Obtenido de


Esther Derby Associates, Inc: http://bit.ly/1LvGXm5

Derby, E., Larsen, D., & Schwaber , K. (2006). Agile retrospectives: Making
good teams great (pragmatic programmers) (1ª ed.). Raleigh,
Carolina del Norte, US.: Pragmatic Bookshelf.

213
Fast Company. (2005). Celebrate Failure. Obtenido de Fast Company
Magazine: http://bit.ly/2tJ2Lta

Fowler, M. (2003). Cannot measure productivity. Obtenido de Martin Fowler:


http://bit.ly/2gMLA8c

Garzás, J. (2013). Como sobrevivir...a la planificación de un proyecto ágil (3ª


ed.). Madrid: 233 Grados de TI.

Garzás, J., & Navarro, N. (2015). Guía de supervivencia ágil...estimación con


puntos historia (1ª ed.). Madrid: 233 Grados de TI.

Glass, L. (2002). Facts and fallacies of software engineering. Addison-


Wesley Professional; 1 edition.

Godin, S. (2009). Purple cow, new edition: Transform your business by


being remarkable. Portfolio.

Goldratt, E. M. (2010). La meta:un proceso de mejora continua (1ª ed.).


Ediciones Díaz de Santos, S.A.

Goleman, D. (2000). Leadership that gets results. Obtenido de Harvard


Business Review: http://bit.ly/11loSrr

Groth, A. (2013). Zappos is going holacratic: No job titles, no managers, no


hierarchy. Obtenido de Quartz Media: http://bit.ly/2ttmK3b

Hamel, G. (2011). First, let’s fire all the managers. Obtenido de Harvard
Business Review: http://bit.ly/18gWmdU

Highsmith, J. (1999). Adaptive software development: A collaborative approach


to managing complex systems. New York: Dorset House Publishing
Co. .

214
Highsmith, J. (2009). Agile project management (2ª ed.). Boston: Addison
Wesley.

HolocrazyOne. (2013). Holacracy constitution (v4.0). Obtenido de


Holacracy: http://bit.ly/2vmDxCc

Jabr, F. (2013). Why the brain prefers paper. Obtenido de Scientific


American: http://bit.ly/2nPv3SJ

Jeffries, R. (2015). The nature of software development: Keep it simple, make


it valuable, build it piece by piece (1ª ed.). Raleigh , Carolina del
Norte, US.: Pragmatic Bookshelf.

Kerth, N. (2001). Project retrospectives: A handbook for team reviews. Nueva


York: Dorset House Publishing Co., Inc.

Kniberg, H. (2007). Scrum and XP from the trenches (1ª ed.). Morrisville,
Carolina del Norte, US.: Lulu.com.

Kniberg, H. (2009). Is your team cross-functional enough? . Obtenido de


Crisp's Blog: http://bit.ly/1HXmTwN

Kniberg, H. (2010). What is crips? Obtenido de Crisp's Blog:


http://bit.ly/2uLUNnc

Kniberg, H. (2016). Alignment at scale or how to not become totally unagile


when you have lots of teams. Obtenido de Crisp's Blog:
http://bit.ly/2C9VG9J

Koestler, A. (1967). The ghost in the machine (1ª ed.). Hutchinson (UK)
Macmillan (US).

Kohn, A. (1999). Punished by rewards (2ª ed.). Boston: Houghton Mifflin.

215
Kua, P. (2013). The retrospective handbook: A guide for agile teams.
CreateSpace Independent Publishing Platform.

Landis, L., Waligora, S., McGarry, F., Stark, M., Johnson, K., & Cover, D.
(1992). Recommended approach to software development. National
Aeronautics and Space Administration (NASA).

Leber, J. (2014). Happy workers are more productive: science proves it.
Obtenido de Fast Company: http://bit.ly/2mN1JO2

Little, J. (2014). Lean change managment: Innovative practices for


managing organizational change (1ª ed.). Happy Melly Express.

Livejournal. (2004). The human story. Obtenido de Livejournal:


http://bit.ly/1kE5ZG5

Logan, D., King, J., & Fischer-Wright , H. (2008). Tribal Leadership:


Leveraging natural groups to build a thriving organization. Harper
Collins Publishers.

Marquet, D. (2012). Turn the ship around!: How to create leadership at every
level. Austin, TX.: Greenleaf Book Group LLC.

Masaaki, I. (1988). Kaizen: The key to japan's competitive success. Nueva


York: McGraw-Hill Higher Education.

McConnell, S. (1996). Rapid development: Taming wild software schedules


(1ª ed.). Microsoft Press.

McGregor, D. (1957). The human side of enterprise. Adventure in Thought


and Action, Proceedings of the Fifth Anniversary Convocation of the

216
School of Industrial Management. 2, págs. 6-15. Cambridge:
Massachusetts Institute of Technology.

McKergow, M., & Bailey, H. (2014). Host: Six new roles of engagement.
Solutions Books.

Mejide, R. (2014). Urbrands (1ª ed.). Madrid: Espasa Libros S.L.U. .

Parnin, C., & Rugaber, S. (2010). Resumption strategies for interrupted


programming tasks. Software Quality Journal, 19(1), 5-34.

Perry, D. E. (2002). People, organizations, and process improvement. IEEE


Software, 11(4), 36-45.

Pink, D. (2011). Drive: The surprising truth about what motivates us.
Riverhead Books.

Pink, D. (2012). To sell is human: The surprising truth about moving others.
Nueva York: Riverhead Books.

Poppendieck, M., & Poppendieck , T. (2003). Lean software development: An


agile toolkit (1ª ed.). Boston: Addison Wesley.

Reiss, S. (2000). Who am I?: The 16 basic desires that motivate our behaviour
and define our personality. Nueva York: Tarcher Inc.

Robertson, B. (2015). Holacracy and the search for agile organization.


Obtenido de Mountain Goat Software: http://bit.ly/2vm86aZ

Robinson, E. (2008). Why Crunch Mode Doesn't Work: 6 Lessons. Obtenido


de Engines of mischief: http://bit.ly/2vM7JGV

217
Schein, E. (1985). Organizational culture and leadership (1ª ed.). Jossey-
Bass Publishers.

Schwaber, K. (2001). Agile software development with SCRUM (1ª ed.). US:
Pearson Education.

Stacey, R. (2000). Complexity and management: Fad or radical challenge to


systems thinking? (complexity inorganisations). Abingdon, UK.:
Routledge.

Sutherland, J., & Coplien , J. (2015). Collocated Team. Obtenido de Published


Patterns: http://bit.ly/2uEX4Og

Takeuchi, H., & Nonaka, I. (1986). The new new product development game.
Obtenido de Harvard Business Review: http://bit.ly/1HiSiWj

The Economist. (2014). The holes in holacracy. Obtenido de The Economist:


http://econ.st/2thXCIB

Vallet, J., & McGarry, F. (1989). A summary of software measurement


experiences in the software engineering laboratory. Journal of
Systems and Software, 9(2), 137-148.

Weinberg, G. (2011). Quality software management: Systems thinking


(Vol. 1). Nueva York: Dorset House Publishing Co., Inc.

Weinberg, G., & Schulman, E. (1974). Goals and performance in computer


programming. Human Factors: The Journal of the Human Factors
and Ergonomics Society, 16(1), 70-77.

218
219