Agile Project Management

Si quieres construir un equipo sólido deberás ser tolerante con los fallos, con las peculiaridades de cada uno y animarlos a que prueben e intenten cosas. Deben saber que pueden hacerlo de forma tranquila, que no les va a pasar nada si algo sale mal, que están respaldados por todo el equipo.

Existe una especie de cultura en muchas empresas, a veces en la sociedad en general, en la que, cuando algo pasa, y se comete un error, todo el mundo busca un culpable. Se le busca, señala y encuentra para luego decidir que él o ella son los culpables de todo lo sucedido. A partir de ahí siempre quedará una mancha en la confianza en esa persona que la estigmatizará por mucho tiempo.

Esto crea un sistema en el que todo el mundo está más preocupado de no tener que tomar decisiones importantes, y no tan importantes, a menos que se lo ordene alguien y lo ponga además por escrito. Se escriben documentos y emails a todo el que pueda pintar algo en la decisión para que estén al tanto y manifiesten su visto bueno, pero estos no quieren comprometerse tampoco. Como resultado de todo esto, no se toman decisiones, nada se mueve, nada avanza y los departamentos legales o los consultores de seguridad, protección de datos o auditores en la empresa tienen un montón de consultas en sus despachos.

A esto en inglés se le llama la cultura del CYA (cover your ass). Si se usa una mano para cubrirse las espaldas, solo queda una disponible para trabajar. El equipo estará más ocupado buscando confirmación de los superiores, escribiendo documentos y correos con justificaciones, que en pensar la mejor forma de hacer el trabajo.

No se trata de que todo se tome a la ligera, siempre hay que adoptar alguna precaución, pero debemos admitir que, a pesar de eso, los problemas ocurren, los errores se cometen. Si cuando esto sucede, comenzamos a preguntar y preguntar sobre quién decidió esto, quién lo hizo o por qué, y así seguimos hasta sacar los colores a alguien, vamos a causar más problemas que beneficios. Nadie hará ni propondrá nada, solo se hará lo que el jefe haya indicado expresamente, pero ¿para qué hay un equipo entonces si cada pequeña acción la decide elgerente?

Si algo pasa, no hay problema, los errores se comenten todos los días. Todo el mundo se equivoca. Sí, tú también te equivocas. Por acción o por omisión ¿seguro que no cometes ningún error? Ya te aseguro que alguno cometes, si no fuera así, tu equipo o tu empresa serían líderes mundiales o irían camino de ello. Seguramente no es el caso.

Ayudará mucho si, cuando surge un problema, comienzas diciendo «Me equivoqué, es culpa mía ¿Me echan una mano?». Si eres el responsable del equipo, animarás a otros a que lo digan cuando ellos hayan metido la pata (y evitará que el problema se agrave porque lo están escondiendo). Crearás un clima de confianza y naturalidad que se notará en la productividad y el rendimiento, pero no solo eso, estarán más dispuestos a hacer un esfuerzo, ayudarte a solucionar el problema y sacarte del apuro.

La Prisa, la exigente viejecita que domina nuestras vidas, no solo nos hace escoger las tareas más fáciles para acabar pronto, también nos presiona para que le demos algo rápido, lo que sea, incluso si no está bien terminado. No tiene tiempo que perder, quiere algo y lo quiere ya.

Los nervios por perder nuestro cargo o nuestro empleo acuden a la Prisa para que presione al equipo. Quiere que le entreguemos nuestro trabajo cuanto antes. Ya habrá tiempo para florituras después, no puede esperar más. Si no está bien probado o terminado, ya lo haremos después; con suerte no pasará nada cuando alguien esté usando nuestro producto. Si esto sucede, le pondremos un parche rápido y ganaremos algo más de plazo para una futura corrección. Qué lejano parece siempre el futuro, pero solo está a un segundo de distancia.

Después de entregado, respiramos aliviados. ¡Hemos sobrevivido! Han surgido algunos problemas en la reunión de demo, pero en los próximos sprints le dedicaremos tiempo a corregirlo.

Pronto nos damos cuenta de que la corrección de esas incidencias nos consume más recursos de los previstos. Además, no paran de aparecer nuevas: a las de la semana anterior se suman las de sprints previos.

Cuando decidas ignorar un aviso o esconder problemas debajo de la alfombra, ten por seguro que volverán a aparecer. Y lo harán exigiendo al menos tres veces el tiempo que en su momento habría sido necesario: primero necesitará volver a reconocer el problema, después recabar datos y ponerte en la situación necesaria para corregirlo, y por último, tendrás que solucionar todos los problemas que el error haya generado en el tiempo en que estuvo en producción. Todo esto tener en cuenta que puede que tengas que aplacar la ira del cliente, devolver dinero o responder las quejas de los usuarios.

Pero la Prisa no permite que te olvides de ella. Sigue demandando cosas nuevas, aunque apenas has podido hacer algo; los últimos sprints los has estado dedicando a corregir problemas anteriores. «Bueno, entregaremos lo que tenemos hasta ahora, aunque no esté bien, pero saldremos así del paso», pareces pensar. En algún momento, no sabes cómo, saldrás de este círculo vicioso.

Entregas algo, lo que sea, esté como esté. Una solución rápida para escapar y volver a coger resuello. Crees con esto, encontrar algo de paz, pero así no aplacas a clientes y usuarios. Solo creas una situación que se asemeja al famoso meme del dibujo de un caballo que, con las prisas por terminar, acaba siendo garabateado. Empiezas a ir rápido, pero acabas yendo cada vez más despacio. En cada recodo del camino coges una nueva piedra que echas a tus alforjas. Llega un momento en el que apenas puedes avanzar más.

No sucede solo cuando estás preocupado por tu puesto de trabajo o por contentar a un cliente que se puede marchar. A la Prisa, también recurren el Orgullo y la Vanidad. Queremos mostrar lo rápidos y ágiles que somos con nuestro reluciente Scrum; comenzamos a medir la velocidad y a mostrar a todos los Stakeholders todo lo que hemos podido acabar esta semana.

Cuatro funcionalidades nuevas esta semana, seis la próxima, y ocho la siguiente. Insistimos al equipo para que termine ya esto que están haciendo, no importa cómo. Tenemos que entregar más cosas. «¿Cómo podemos enseñar en la reunión de demo solo dos funcionalidades nuevas?», pareces pensar. Pronto tendremos que parar para corregir problemas mal resueltos en sprints anteriores. A menos que sigamos con esta carrera de la rata, y para continuar con este ritmo, continuemos entregando trabajo aún a medio cocer.

Cuando la velocidad y las reuniones de demo de Powerpoints comienzan a importar más que la calidad y el trabajo bien hecho, es cuando comenzamos a caer en un Scrum que hace más daño que bien. Un Scrum hueco, que solo es una cáscara que esconde un producto defectuoso y un estrés que perjudica al equipo de trabajo. No nos pagan por trabajar rápido. Nos pagan por un producto o servicio útiles que resuelve los problemas del cliente.

Algunos, cansados de estos Scrum flácidos, se han orientado hacia el movimiento Software Craftmanship[1]. Sobre esta tendencia, el conocido Uncle Bob, indica lo siguiente en uno de sus artículos (solo por mencionar algunos puntos).

• Estamos cansados de escribir mierda.
• No vamos a crear un desastre solo para cumplir un calendario.
• No aceptamos esa estúpida idea de ya «limpiaremos» las cosas luego.
• No aceptamos la opción de hacer las cosas mal.
• No permitiremos a nadie que nos fuerce a hacer cosas de forma poco profesional.
• Cumpliremos los calendarios porque sabemos que la única manera de ir rápido es hacerlo bien.
• Si algo merece la pena hacerse, merece que se haga bien.
• El paso lento y constante gana las carreras.

[1] Martin, R. Software Craftsmanship: What it’s all about [en línea]. The clean coder. Disponible en http://thecleancoder.blogspot.com/2011/01/software-craftsmanship-what-it-all.html.

Sucede con frecuencia. Nos dejamos llevar por la ceguera de las cifras y los presupuestos de nuestro proyecto. Vamos mal (siempre vamos mal) y queremos recortar esa sangría de horas que le estamos dedicando a la construcción de nuestro producto. El cliente nos pide cambios y mejoras, pero no podemos dedicarle un minuto más: «Nos vamos a salir del presupuesto, no me van a pagar el bono este año y no conseguiré que me den proyectos más grandes».

Es aquí cuando pensamos que lo que nos falta es ponernos firmes con el cliente y decirle muy claro que tenemos que dejar el proyecto tal y como está. «Después de todo, el contrato dice que hay que hacer un control de stock y un inventario de artículos, y eso es lo que hemos hecho», piensas. «Si aún es lento o quedan cosas que arreglar, tendrá que contratarnos de nuevo. Que busque presupuesto, y nos llame, que le pasaremos una estimación conveniente».

Ponte por un momento en los zapatos del cliente. Ha invertido una importante suma de dinero en el proyecto, y después de meses de trabajo, aún no tiene nada que le funcione. Te ha contratado a ti y a tus compañeros para que le aporten una solución a su problema, y lo único que tiene desde hace semanas son disputas sobre esta o aquella línea del contrato.

Puede que te vuelva a contratar para que termines el trabajo, pero mucho me temo que lo hará a regañadientes, y no por voluntad propia. Habrás ganado esta batalla y salvarás temporalmente el proyecto, pero este cliente no contará contigo para proyectos futuros. Tampoco hablará bien de tu empresa a sus colegas. La visión de túnel y el cortoplacismo te impiden ver más allá de los próximos meses o el presupuesto de este año, pero ¿qué vas a hacer cuándo termines ese trabajo y no suene el teléfono?

Intenta asegurarte de que resuelves el problema del cliente. Para eso te paga, para que pienses en cómo mejorar sus procesos, no para que luches por tu presupuesto o dediques tu tiempo a interpretar el contrato de la forma que te es más propicia. Colabora con él e intenta entender dónde puedes aportar más valor. Probablemente estará encantado de quitar otras cosas de la lista si puedes ayudarlo con su principal dificultad.

Entrega también tu trabajo poco a poco y ponlo a funcionar. Deja que lo usen. Los usuarios pronto verán qué les es útil y qué no. Todas esas funcionalidades que pintaban bien sobre el papel, quedarán pronto olvidadas cuando puedas resolverles sus principales inconvenientes. Las negociaciones son mucho más sencillas si la otra parte sale claramente beneficiada.

Pronto vendría el rey a hacer una visita a su provincia. Sería el primer destino en su gira por los departamentos del sur. Era todo un honor y no quería fallar. Él era el gobernador y representante del rey en esas tierras; tenía que llevar el traje más imponente del lugar. Solo estaría un día, por lo que no podía fallar en su elección. Debía impresionarlo en la recepción en su honor si quería contar con alguna posibilidad de llegar a ministro de Gracia y Justicia.

Pidió consejo a sus tres mejores amigos, los que más entendían de moda y los que más elegantes iban a sus fiestas. Todos querían tomar las decisiones más importantes sobre el modelo a llevar. Deseaban impresionar con sus conocimientos sobre moda y estilo al gobernador y ser responsables del impresionante aspecto del máximo jerarca en la provincia. Se reunían cada día para presentarle las mejores telas y broches y comprobar qué tal le quedaban los últimos bordados.

Tantas personas opinando volvían loco al modisto. Un mañana pensaban que el fajín debía ser rojo, otra que azul para destacar sus ojos y una tercera que verde como el color de la bandera local. Nunca se ponían de acuerdo. Apoyar la idea del otro consejero suponía darle todo el crédito a él.

Cuando por fin tomaban una decisión por mayoría, pero uno de ellos quedaba disconforme, días más tarde volvía a la carga y convencía a los otros dos, que terminaban aceptando para no enfadarlo.

Después de meses de trabajo, el gobernador comenzó a quejarse amargamente de lo que se llevaba hecho: No podía ni verlo. Habían apostado ahora por el traje de color verde, pero ya no estaba tan seguro. ¿Y si al rey le gustase más el azul? Desde luego, era un traje impresionante también, pero ¿no habría alguna manera de combinar los dos trajes y así no correr el riesgo de fallar?

La mujer del gobernador, preocupada por la indecisión de su marido, decidió acudir una mañana al lugar de las pruebas. Nada más llegar anunciaba: «Pero ¡Qué bonito está! ¿No podrían hacerme a mí uno igual?». Ante esto, el gobernador coge nuevos ánimos y dice: «¿A que está bonito? ¿Te gusta? ¡Lo he elegido yo en homenaje a los colores de la bandera!». Sin embargo, sugiere otros cambios al pantalón para dejarlo, ahora sí, perfecto. Tampoco le gusta la tela de la chaqueta. Hay que cambiarla, esa tela no es la más apropiada para la visita en verano del rey.

El tiempo se acerca y nada está terminado. Se ha hecho, rehecho y vuelto a hacer con las decisiones del principio. No queda más tiempo para valorar más alternativas. El gobernador disgustado con las prisas del sastre elige un broche cualquiera: «Por esto me gusta hacer las cosas con tiempo». No está contento y no sabe si acertará. Admite en secreto a sus amigos que el traje azul le gustaba más.

Pero ya no quedan más hojas en el calendario; mañana es el gran día. «Si tan solo pudiese contar con un par de horas más», se decía. Las costureras tuvieron que trabajar toda la noche para tenerlo preparado para la mañana siguiente. Si con las prisas se han equivocado en alguna medida o patrón, el gobernador tendrá que acudir a la recepción con un par de agujas sujetando alguna pieza.

Llegó el día del besamanos del rey. Todos los cargos importantes de la provincia estaban allí presentes, esperando para hacer una reverencia al rey. Mientras pasaban frente a él haciendo la genuflexión, les dedicaba una amplia sonrisa a las mujeres y una cálida palmada en el hombro a los hombres. Cuando llegó el turno de nuestro gobernador, le susurró «¡Qué guapo está usted hoy! Me recuerda usted a la Hacquetia epipactis de mi tierra»

«¿Habéis visto lo que me ha dicho el rey? Solo me lo ha dicho a mí. No se lo he oído decir a nadie más», comentaba el gobernador a todo el que lo quería escuchar en la fiesta que siguió a la recepción. Pensaba ahora convertir a la planta esa en símbolo de la región y hacerse un sello con su estampa. Podrían también encargar nueva mantelería para el palacio de la gobernación con bordados en color verde. Él siempre supo que, estudiándolo bien y trabajándolo mucho, sería capaz de hacer la mejor elección: «Todo el esfuerzo hecho y las ocupaciones que he tenido que dejar de lado han merecido la pena».

En muchas de las situaciones de la vida, no tienes ni idea de qué es mejor o que no. Estúdialas brevemente, toma una decisión que crees más acertada y apuesta por ella. Lo demás son opiniones que pueden venirse abajo cuando el traje lo vea el rey o el producto esté en las estanterías de las tiendas. Si, usando los recursos y pruebas suficientes, siempre pudiésemos saber qué va a tener éxito y qué no, no habría productos fallidos en los mercados. Todos serían la próxima revolución en su sector.

No te dejes llevar por la parálisis por análisis o el miedo a perder lo que ganarías con las opciones B, C o D. Procura tener en cuenta también los errores que puedes cometer debido a los cambios constantes en los criterios de elección o todo lo que dejas de ganar mientras inviertes tiempo y dinero valorando terceras y cuartas opciones.

No es bueno tampoco tener más de un Product Owner para nuestro proyecto. Ni los tribunales, ni las democracias son buenas para la toma de decisiones. Elige a alguien sensato y con conocimiento del mercado como Dueño del Producto y confía en que sabrá resolver cuándo no conviene meter más recursos en decisiones que son insondables.

Es difícil, pero puede ocurrir si no se hacen las cosas bien. Sucede sobre todo cuando hay tensión en el proyecto; no se está contento con lo que el equipo de trabajo entrega, por lo que se deciden poner unos sprints en marcha. Poco a poco se van entregando cosas, pero la presión no disminuye, aún no es suficiente. Todo el equipo está alerta y preocupado por lo que se pueda pensar de él y su productividad

La Cultura de la Prisa comienza a tomar el control y es una anciana exigente. Lleva desde tiempos inmemoriales exigiendo más y más tributos, no importa la calidad que tengan, solo quiere que se le entregue algo rápido para dejar de gritar. Pero las tareas resueltas deprisa y corriendo que se le entregan solo le crean más apetito. Están huecas y no le sacian su voracidad.

Creemos cumplir con nuestro trabajo sirviendo más tareas cada vez más deprisa, pero cuando alguien las comprueba, vemos que aún tienen detalles por pulir o fallan algunas cosas. Esto genera una sensación de urgencia aún mayor por ver resultados, ansiedad que tratamos de aplacar dándonos más prisa todavía.

Sin calma para hacer las tareas, volvemos a cometer más errores que nos llevan de nuevo a la casilla de salida. No hemos avanzado nada, y para colmo, en el próximo sprint no podremos trabajar en lo que prometimos hacer: tendremos que dedicarlo a arreglar lo que aún no funciona bien.

Durante unas semanas estaremos sumando puntos. Añadimos las cosas más fáciles de hacer, aquellas que podemos entregar rápido o están mejor definidas, pero evitamos terminar lo importante. Lo dejamos para el siguiente sprint o para el otro, nunca hay tiempo para lo trascendente: la Prisa nos agobia con su insistencia.

Es un círculo vicioso del que no podremos salir si no nos paramos con determinación y le plantamos cara a esta condena que, en parte, nos hemos autoimpuesto: No vamos a entregar nada hasta que no haya revisado cada funcionalidad y cumpla con mis estándares de calidad. Si no lo hacemos así, lo entregado hoy para aplacar a esta anciana, estará detrayendo nuestras fuerzas para hacerlo mañana. Tendremos que pararnos frecuentemente a corregir lo hecho. Poco a poco iremos cada vez más despacio hasta llegar a una situación de bloqueo de la que es difícil encontrar salida.

Se trata de una suma de varios de los aspectos del Principio de Laborit: Solucionamos antes lo urgente que lo importante, elegimos hacer antes lo rápido que aquello a lo que nos lleva más tiempo o preferimos hacer lo más sencillo antes que lo difícil.

Pasan los sprints y no acometemos los problemas graves o los asuntos significativos. Sprint tras sprint queremos sumar nuevos puntos para contentar a la Prisa: Corremos el riesgo de estar limitándonos a correr en una rueda de hámster.

A lo largo de estos que años que llevo dedicándome a la Agilidad, varias personas me han preguntado si Agile o Scrum son solo una moda. La mayoría lo hacían preocupados por la respuesta. Otros no lo preguntaban, directamente lo afirmaban. En general, a quién lleva unos meses dedicados a sacar una certificación, o leyendo y estudiando sobre todo esto, les horroriza pensar que no sea más que un nuevo revuelo. Una de esas rebeliones con más alboroto que consistencia. Querían saber si todo ese tiempo invertido en dar lustre a su currículum, o a poner en práctica todo lo que habían leído, les iba a servir para algo.

La respuesta corta a si la Agilidad, Scrum o Kanban son una moda, al menos «mi respuesta corta», es que sí, son una moda ya desde hace unos años. Se han convertido en el nuevo mainstream y no hay jefe de proyectos o técnico que se precie, especialmente en la industria del software, que no diga que es ágil.

La respuesta larga, que continúa a la frase de que la Agilidad es una moda, es que de esta moda quedarán las bases para lo nuevo que vendrá. En una década, quizás dos, una nueva metodología se impondrá que nos convencerá a todos de que esta sí es la nueva panacea. Será escalable y medible, flexible para los técnicos, pero de apariencia seria para los managers. Solucionará algunos de los problemas que tenemos ahora y mejorará además otros aspectos. Pero también estoy convencido de que buena parte de los principios y valores de la Agilidad seguirán siendo válidos, se llame como se llame el nuevo proceso.

Puede que ya no sigamos metodologías algo estrictas como Scrum o que dejemos de hacer reuniones de retrospectiva y gráficas burn-down. Después de todo, la vida se nos va en reuniones, pero es difícil que dejemos de reunirnos a primera hora y contarnos en qué estamos trabajando para luego salir disparados a continuar con lo que estábamos haciendo. Veo difícil también que dejemos de tener sprints, o como los llamemos en el futuro. Ponernos una meta corta con una lista de elementos clara y avanzar poco a poco hasta dejarla cerrada es un elemento básico de casi cualquier técnica de productividad.

Sí, es una moda, pero es lo mejor que sabemos hacer ahora. Aprenderemos cosas nuevas, mejoraremos las anteriores o las ampliaremos, pero hay fundamentos dentro de la agilidad que difícilmente dejarán de ser importantes ¿Cree que alguno de estos valores dejará de ser importante en los proyectos que tendrá en el futuro?

• La gente de negocio y los técnicos deben trabajar juntos de forma diaria durante todo el proyecto.
• Construya proyectos alrededor de gente motivada. Deles el entorno, soporte y confianza que necesiten.
• Se promueve el desarrollo sostenido. Sponsors, técnicos y usuarios deberían ser capaces de mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad.
•  La simplicidad es esencial.

Hay otros principios similares a estos. No creo que dejen de ser relevantes por mucho que cambien las cosas, pero si alguien define otros nuevos, bienvenidos sean si aportan mejoras.

Nadie sigue ahora la moda en el vestir de los 60, 70 u 80, pero muchos de los fundamentos de esas modas pervivieron: Los tejidos, el colorido o la ligereza en las ropas evitaban los corsés o los trajes imposibles de principios de siglo. Si excluimos las mayores extravagancias, mucho de lo que vestimos ahora hereda de aquellos años. Seguramente suceda algo similar con la Agilidad; que se adapte y cambie con los tiempos. Nada es eterno.

En alguna ocasión nos encontraremos con el experto en un campo que se resiste a cambiar y aprender lo nuevo que está llegando. Te dirá que es una moda, que ya pasará, que lo que él conoce no va a desaparecer nunca. «Es imprescindible ¡Ha sido así toda la vida!». Claro, lo ha sido toda «su» vida profesional, pero ahora que ya suma veinte años en el negocio las cosas comienzan a cambiar. Tendrá que salir de su zona de confort y dedicar parte de su tiempo libre a leer, estudiar y ponerse al día. Aprenderá nuevas formas de hacer las cosas que posiblemente pongan en entredicho la manera en la que siempre ha hecho su trabajo.

Esto no pasa solo ahora que tenemos ordenadores, móviles y robots que nos limpian la casa. Ha pasado siempre. Cuando el invento revolucionario de la época era el ferrocarril y éste comenzaba a llegar cada vez más lejos y más rápido, había gente que decía: «Los trenes van demasiado rápido, no es natural, como mucho, hay que ir como los caballos.» Había quién pedía incluso limitar la velocidad del ferrocarril a treinta kilómetros por hora. Una vez superada ampliamente esa barrera, se oían voces que proponían limitarlos a setenta «Porque los pulmones humanos no lo resistirían.»

Las primeras personas que se subían a un tren que podía alcanzar los cien kilómetros por hora, lo hacían con miedo. ¿Qué les podría pasar a esa velocidad? ¿Por qué podía pasarles algo a cien y no a noventa y siete o a ciento tres? Simplemente porque cien era una cifra redonda, una barrera imaginaria de tres dígitos que, por alguna razón, parecían relacionar con un límite físico humano.

Sitúese ahora en un futuro más o menos cercano en el que un ciudadano cualquiera se va a subir por primera vez a un taxi autónomo sin conductor. Para cuando esto comience a ser habitual, el número de accidentes, heridos o fallecidos por automóvil se habrá reducido drásticamente. Los sensores de cercanía, velocidad y la inteligencia colectiva de la nube o el Internet de las Cosas harán virtualmente imposible que podamos tener un accidente. Sin embargo, habrá mucho miedo. Habrán leído en las noticias que cerca de Islamabad uno de estos taxis cayó por un precipicio ¿Qué pensarás cuando te llegue una situación como esta? ¿Serás de los que participe activamente en esa revolución o de los que querrá que la prohíban?

Cambios y más cambios llegarán de forma continua y más rápida cada vez. Procure permanecer abierto a ellos para poder reaccionar y adaptarse a la nueva situación. Nuevos métodos y procesos van a aparecer, pero también a desaparecer; intente aprender y mejorar con todos ellos. Quedarse solo con lo que le explicó alguno de sus primeros profesores no le va a ayudar gran cosa en un mundo cambiante.

Hoy, durante casi todo el día, mi libro Gestión práctica de proyectos con Scrum ha estado alcanzando el puesto de bestseller en la categoría de Información, Internet y Medios digitales en español de Amazon.com.

Participó en la promoción Kindle Flash por la que fue enviado en una newsletter a todos los usuarios en español de Amazon.com. Participaba en la selección de hoy junto a libros como Lean Startup de Eric Ries o Límites Cara a Cara de Henry Cloud (todo un honor).

Aquí tienen algunas capturas de pantalla del día de hoy:

Como veremos más adelante en algún post posterior, el efecto Dunning-Kruger es aquel que hace que las personas con menos habilidades o inteligencia se sientan más competentes que el resto de sus colegas. Su falta de conocimientos hace que desconozcan lo que les falta para dominar la materia y se creen en control absoluto de la situación.

Algo así sucede cuando en una entrevista de selección se pregunta a alguien bueno “¿Sabes Java? (ponga aquí la tecnología o la técnica relevante para tu equipo)”. El entrevistado piensa en todo lo que ha leído y lo que le falta por aprender y nos dice: “Bueno… un poco”. Tiene noción de todos los libros que hay en el mercado sobre esto y de las que solo ha leído unos pocos o se compara con sus compañeros más sénior y piensa “Aún me queda mucho”.

Si pregunta a alguien no tan bueno, pero muy seguro de sí mismo puede que nos diga “Sí, soy muy bueno en eso”. Es posible que lo diga porque no tiene idea de todo lo que se ha escrito sobre la materia, ni se haya preocupado por averiguarlo. Nunca ha leído un blog ni ninguno de los libros de cabecera sobre Java y cree que, con los dos o tres años trabajando con esa tecnología, ya sabe todo lo que se necesita.

Le interesa trabajar con el primero de los entrevistados de este ejemplo. La humildad, cuando proviene de saber lo difícil que es hacer las cosas bien, es un atributo muy valioso. Aun cuando haga las cosas aceptablemente bien, siempre le quedará algún libro por leer o alguna charla a la que asistir con la que mejoraría terriblemente. Y esto es algo que saben los profesionales competentes.

En cambio, no se beneficiará tanto de trabajar con candidatos que no tengan dudas, o que crean saberlo todo en su campo. Huya del exceso de seguridad, desconfíe de aquel al que no le quede algo por aprender. Nunca hay decisiones acertadas al 100%, siempre habrá una contrapartida que pagar y usted quiere consigo a aquellos que valorarán los pros y los contras de cada decisión.

Incluso, si el candidato es novato o no muy experto, será bueno que sea capaz de saber ver que aún tiene mucho que mejorar. Admitirá los errores y tratará de corregirse y optimizar. A otros, el efecto Dunning-Kruger (lo veremos más adelante) no les permitirá ver en qué son malos. Pueden tender incluso a enfadarse o ignorar las correcciones que se les indican. Simplemente no entienden que puede haber mejores formas de hacer las cosas.

Estos días he recibido, de parte de Eugenio Tuya, un estupendo ejemplar del libro sobre Gestión de proyectos de Gregory M. Horine. Todo un clásico de los Manuales Imprescindibles de Anaya.

Será uno de mis próximos libros a leer, pero no he podido aguantar en hojear ya alguno de sus contenidos. Para muestra, dos estupendo extractos:

• En la sección «¿Qué es exactamente un proyecto de éxito?» se puede leer como uno de los factores principales «(…) Mantenimiento de relaciones positivas:  Se ha logrado satisfacer todas las necesidades del proyecto con una orientación hacia el personal y no se ha precisado sacrificar las necesidades individuales de los miembros del equipo o los vendedores. Los que han participado en un proyecto finalizado con éxito deberían estar entusiasmados al ver que el proyecto está completo, y con ganas de repetir la experiencia«.
• En la sección «Diez principios clave para un equipo de alto rendimiento» tiene un apartado que dice así: «Relaciones públicas: Haga como si usted fuese el encargado de relaciones públicas de cada uno de los miembros de su equipo. Además de ofrecer respuestas oportunas y apreciación por cada uno de ellos personalmente, asegúrese de que la ‘gente adecuada’ (…) conozca el excelente trabajo que están llevando a cabo a lo largo de todo el proyecto.«

No es un libro sobre Agilidad o Management 3.0, pero me alegra mucho ver que hay cosas que se comparten entre todos los entusiastas de la gestión.

Ya he mencionado alguna vez en este blog al estadístico norteamericano Edwards Deming cuyo nombre está asociado al espectacular desarrollo de Japón después de la Segunda Guerra Mundial. A él se asocian también conceptos como el de Calidad Total o el que luego dio lugar a la palabra japonesa Kaizen o mejora continua. Por algo los japoneses llaman a Deming «el padre de la tercera revolución industrial».

También se ha hablado varias veces en este libro sobre lo importante que es la calidad cuando ofrecemos un servicio o creamos un producto. Pero de acuerdo con Deming, la calidad no es una meta fija que alcanzamos y en la que nos podemos dormir en los laureles. La calidad total siempre está un poco más lejos de lo que podemos llegar esta semana.

Pero ¿Cómo podemos establecer un plan sistemático para mejorar la calidad? Deming nos habla del ciclo PDCA (Plan, Do, Check, Act o Planificar, Hacer, Comprobar y Actuar) para conseguirlo:

• Plan: Detectar una oportunidad de mejora y crear un plan para conseguirla.
• Do: Probar ese plan con un test a pequeña escala cuyos resultados podamos medir con fiabilidad.
• Check: Comprobar esos resultados y aprender de ellos.
• Act: A la vista de los resultados, si el test funcionó implementar el plan a una escala mayor. Tanto si funcionó como si no lo hizo, volver al paso 1: Planificar.

Imagina que eres el responsable de un servicio de HelpDesk de IT. Desde todos los departamentos de la empresa te llegan, a través de una página web, solicitudes de todo tipo: No me funciona el ratón, no puedo cambiar mi clave, necesito un portátil nuevo o la página web para reservar salas de reuniones está caída.

La principal queja que usted recibe de los usuarios es que los técnicos cierran los tickets con las solicitudes demasiado pronto. Si una página no funciona, el técnico la comprueba, ve que a él si le conecta y decide cerrar el ticket como solucionado. Ha pensado que el usuario no ha sabido escribir bien la dirección de la página o que fue un problema puntual y que ya está resuelto. No se ha parado a pensar si el usuario se está intentando conectar desde otra red o la clave de la Wi-Fi de su edificio ha sido cambiada y por tanto sigue sin poder conectarse.

Decides poner un plan en marcha para mejorar esto. Crearás una checklist como la mostrada a continuación para que cada técnico la complete antes de marcar un ticket como resuelto. Será una checklist a usar solo por los técnicos que dan soporte a las incidencias en las aplicaciones web. Los que dan mantenimiento al hardware o instalan software estarán fuera de momento. La checklist propuesta sería una como la que sigue:

1. ¿Funciona la página web desde el ordenador del técnico?
2. ¿El usuario puede acceder a Google.com?
3. ¿El usuario puede acceder a otras aplicaciones internas?
4. ¿El usuario ha escrito bien la dirección de la página?
5. ¿Está accediendo el usuario desde la Wi-Fi del edificio o lo hace desde su casa?

Como verás es una lista breve, no queremos que los técnicos pasen mucho tiempo contestando preguntas.

Pasarás ahora a crear un test para comprobar si usar esta checklist da resultados. Si la valoración de los usuarios a los tickets resueltos mejora en un 20% definitivamente vas a dejar esta checklist implantada para siempre.

Dejarás pasar un mes para luego examinar las estadísticas de los técnicos que resuelven incidencias en las páginas web. Compruebas que en ese tiempo la puntuación dada a los tickets resueltos ha mejorado ampliamente esa cifra. No solo eso, el número de tickets reabiertos por los usuarios ha bajado también en un porcentaje significativo.

Es momento de actuar. Decides mejorar un poco esta checklist con una comprobación más e idear otro test para la sección que resuelve incidencias de hardware. Esta checklist no es tan sencilla y tendrás que planearla bien. Es momento de volver a planificar e iterar en este ciclo PDCA.

No intentes volver del revés todo el servicio ni cambiar de la noche a la mañana todo tu producto para mejorar. Como dicen los ingleses «Don’t boil the ocean» (no hiervas todo el océano si solo necesitas hacerte un té). Puede volver loco a todo el equipo o a los usuarios que usan tu producto. Las mejoras tienen un coste de implementación y puede que sus beneficios no superen ese coste (o que perjudiquen más que beneficiar).

A veces nos equivocamos y decidimos atacar un problema que no existe mediante un recurso que impresionará a los demás. Quizás decidimos aplicar la norma de cero defectos o calidad 100 %, cuando en el equipo no se están haciendo copias de seguridad con la suficiente fiabilidad o cada vez que una nueva versión sale al mercado se sufre demasiado. Resuelve los asuntos básicos e importantes primero. Le permitirán coger velocidad después. Cuando haya conseguido atajar los asuntos más relevantes y el equipo haya cogido resuello, es tiempo de pasar al siguiente nivel y avanzar un poco más.

Presta también atención en las mejoras en la prevención del fuego y no en la lucha contra el fuego. Analiza la causa de los principales problemas que estás teniendo, aquellos que están causando el mayor número de incidencias o que están impidiendo que el servicio funcione de forma suave y tranquila.

«Pre-ocupándote» antes de ocuparte en la extinción, conseguirás reducir el número de fuegos abiertos en el futuro. Si procuras ser constante en estos planes de mejora continua y trata de poner en marcha un plan sencillo en cada sprint o cada mes, en poco tiempo habrás atajado la fuente de numerosos problemas. Ante los problemas habrás sido proactivo en lugar de reactivo.

Cuando hablamos de gestión solemos hablar de «Gestión de proyectos» o de jefes de proyectos, pero cuando estamos gestionando un proyecto no prestamos atención solo a su presupuesto, al tiempo y el alcance del mismo. Lo que realmente queremos conseguir con ese proyecto, dentro de su presupuesto y tiempo establecidos, esproducir un producto que se venda bien y al que le respalde una imagen de buena calidad (después de vender este producto idearemos otro para el que no querremos que le arrastre la mala imagen del anterior).

Idealmente también nos gustaría disfrutar del tiempo en el que lo estamos desarrollando. Ni a nosotros, ni a los miembros del equipo que tengan la suerte de trabajar con nosotros les complacería tener que trabajar en un lugar donde las situaciones de estrés, el mal ambiente o las horas extra nos devoran desde dentro.

El proyecto con el que la empresa de Steve Jobs ideó el iPhone fue un auténtico fracaso, si solo al presupuesto nos referimos. Se terminó gastando en la investigación y desarrollo del nuevo iPhone alrededor de 150 millones de dólares, mucho más de lo presupuestado para ese fin. De hecho, durante el tiempo en el que se estaba concibiendo, se produjo mucha fricción en Apple. Los mejores ingenieros fueron destinados a ese proyecto dejando huérfanos los planes de muchos jefes de proyectos en la casa. Sin embargo, el proyecto terminó generando unos ingresos de 500 mil millones para la compañía de Steve Jobs. Todo un éxito como producto a pesar de que el proyecto fuese un fracaso.

Yo mismo he participado en proyectos que se terminaron a tiempo y dentro del presupuesto, pero que el cliente nunca llegó a utilizar. Se utilizaron tecnologías sencillas y seguras para las que había un amplio margen para hacerlo bien y rápido, pero para cuando vio la luz ya habían sido ampliamente mejoradas por otras. El director del proyecto en el cliente decidió iniciar un nuevo proyecto (con otro proveedor) al poco de que finalizáramos con el anterior.

También he participado en proyectos en los que nos comimos rápidamente el presupuesto y sobrepasamos el tiempo fijado para que comenzase a ser usado por los usuarios. Las buenas ideas usadas en él y lo contentos que estaban los clientes con el resultado final y cómo se había desarrollado todo, hicieron que nos contratasen siempre a nosotros de modo preferente. Perdimos dinero en ese primer proyecto, pero nos hizo ganar buena fama en el resto de la industria donde se ofertaba nuestro producto.

En este libro intento prestar atención no solo al proyecto, sino al producto que se está construyendo en ese proyecto, al equipo que lo está haciendo y, por qué no, a tu propia tranquilidad mientras lo haces. De seguro no querrás un proyecto que te quite el sueño a ti ni a tus compañeros de trabajo.

No está de moda usar la palabra proyectos cuando en realidad lo que queremos es un producto de éxito. Tampoco está en boga emplear a equipos de usar y tirar, configurados explícitamente para los seis meses de un proyecto, cuándo queremos equipos muy cohesionados y de alta productividad ¿Debería decir, por tanto, gestión de productos o gestión de equipos en lugar de gestión de proyectos?

Bueno, un nombre había que darle a esto que hacemos. A pesar de llamarlo proyecto, no se olvide de todos los aspectos que intervienen en un proyecto de éxito: el producto y el equipo.

En inglés existe una frase hecha que dice «Good, fast or cheap, choose two». Nos viene a decir que no podemos tener los tres atributos en un producto o servicio. Si es bueno y rápido no será barato. Si es barato y rápido no será bueno. Si es bueno y barato será un servicio lento o tendremos el producto dentro de mucho tiempo.

Es una frase equivalente a nuestro «Bueno, bonito y barato» que nos venden en los mercados y que siempre damos como imposible. Pensamos que nos están timando, que un producto así no existe.

Esto pensamos también cuando somos nosotros los manufacturadores de ese servicio que queremos vender. Si invertimos en calidad y hacemos un producto bueno, será caro en el mercado y nos costará venderlo. Si lo hacemos rápido y económico no será gran cosa y se convertirá en un producto mediocre más en las estanterías de los minoristas o en el catálogo de nuestros comerciales.

Sin embargo, Tom DeMarco y Tim Lister nos cuentan en su libro Peopleware que esa frase no es verdad. Cuando midieron la productividad de los programadores de cientos de empresas de Estados Unidos, la calidad era recompensada con creces.

Según su estudio, los técnicos que realizaban los proyectos en una décima parte del tiempo que los demás también cometían diez veces menos errores que los más errores cometían. Es decir, que no necesitaban invertir más tiempo para cometer menos errores. Simplemente lo hacían bien a la primera. Tenían en sus empresas una cultura de la calidad que les hacía prestar atención a lo que hacían, intentando entregarlo bien al primer o segundo intento.

Hacer el trabajo para después corregir errores hace que todo sea mucho más lento. Cuando semanas después de terminar el producto aparece el primer problema tienen que desmontarlo todo, revisar e intentar hacer memoria de por qué estaba hecho así.

Jeff Sutherland en su libro Scrum cuenta que miembros del equipo de desarrollo de Palm, los contructores de las primeras PDAs, le contaron que decidieron medir cuando costaba corregir cada error que encontraban. Revisando estas mediciones se dieron cuenta de que, si un error se corregía el mismo día que se produjo, se solucionaba en una media de una hora. En cambio, si el problema era archivado y se corregía tres semanas después, el tiempo medio empleado para arreglar el error era de 24 horas ¡24 veces más!

No entreguemos nuestro trabajo a las primeras de cambio. No nos dejemos llevar por la presión y entreguemos lo primero que nos pareció bien. Tardaremos mucho menos si revisamos concienzudamente nuestro trabajo, empleando el tiempo y la paciencia suficiente que da el saber que, adelantar un minuto ahora, hará que nos retrasemos mucho más después.

Deming lo explica así con su ciclo de Reacción en Cadena de la Calidad:

1. Aumentamos la calidad.
2. Se reducen los costes porque hay menos errores, menos tiempo en corregirlos y rehaciendo el trabajo, menos tiempo resolviendo quejas y pagando reclamaciones, etc.
3. Aumenta la productividad (empleamos menos recursos para hacer los mismo).
4. Ganamos más mercado por tener mejor calidad y costes más bajos.
5. Seguimos en el negocio.
6. Creamos más empleo.

Y ahora que ha terminado con los seis puntos, vuelva al punto número uno y continúe mejorando (recuerde la mejora continua). Merecerá la pena porque podrá elegir los tres atributos: Bueno, rápido y barato.

Para estas fechas estaba prevista la salida a la venta de mi tercer libro, pero he decidido posponerlo a la espera de que se confirmen algunas novedades en su publicación. Les mantendré informados mediante este blog, LinkedIn o Twitter.

Mientras tanto les dejo con el índice provisional que tendría:

NO HAY PRÁCTICA SIN TEORÍA

1. A qué llamamos Agilidad
2. Scrum
3. Lean
4. Extreme Programming

NI TEORÍA SIN PRÁCTICA

1. Hablando con el cliente
2. Leyendo el futuro
3. Cómo ser ágiles en todo tipo de proyectos

GESTIÓN DE EQUIPOS DE TRABAJO

1. Las dos teorías de la gestión
2. Coding wars
3. El portfolio
4. Permítase trabajar con gente que dude
5. El efecto Pigmalión
6. No deshaga los buenos equipos
7. Todo el mundo tiene derecho a equivocarse
8. Trabajando con incompetentes
9. Trabajando con genios
10. Principio de Hanlon
11. La increíble historia del robo de un banco y los equipos de trabajo

SUELO FÉRTIL

1. Ley de Parkinson
2. Ley de Carlson
3. Nada peor que la multitarea
4. Y si de interrupciones hablamos
5. Ofrezca un trato justo

LA “LÓGICA” DEL COMPORTAMIENTO HUMANO

1. Síndrome del estudiante
2. Añadir gente a un proyecto retrasado hace que se retrase aún más
3. Principio de Hawthorne
4. Psicología de la persuasión
5. La firma de abogados y las máquinas de escribir
6. Deje que le atrape el efecto Zeigarnik

QUIÉN ES EL DUEÑO DE TODO ESTO

1. Agilidad para el dueño
2. Deje madurar las peticiones
3. Pero ¡Qué estamos haciendo!
4. Parálisis por análisis
5. Agilidad o contorsionismo
6. Efecto IKEA

LOS ERRORES MÁS HABITUALES

1. Pasarnos de ágiles
2. Dejar que el miedo campe a sus anchas
3. Pruebas insuficientes
4. Lo que hay que entregar está grabado a fuego hasta el día del juicio final
5. ¿Está enseñando su trabajo?
6. Diseñar todo el proyecto desde el inicio
7. Nos pasamos el día reunidos
8. El jefe de proyecto reparte las tareas
9. Apretar demasiado en el objetivo del sprint
10. Dependemos demasiado de héroes
11. Interrupciones urgentes que no nos dejan avanzar
12. Asumir que ya lo sabemos todo
13. Demos que no están listas
14. La Pila del Producto no está lista
15. Hacemos demos huecas
16. Temor a las demos

VENTAJAS DE SER ÁGIL

1. Divide y vencerás
2. Saber cada dos semanas lo que piensa el cliente
3. Que comience ya a usar su producto
4. Medir la productividad individual
5. Llegar tan lejos y tan rápido como un ciclista
6. ¿A quién le gustan las sorpresas?

ES LA CALIDAD, ESTÚPIDO

1. El verdadero precio de la calidad
2. El coste de hacer las cosas mal

HABILIDADES ÁGILES

1. Vísteme despacio que tengo prisa
2. Levante la cabeza y mire alrededor
3. Empiece por lo más fácil
4. Todo el mundo comete errores (excepto yo, claro)

Este es un extracto de mi nuevo libro «Dibujando la revolución ágil» en el capítulo sobre gestión de equipos de trabajo. Espero que le guste:

Alguien contó a McArthur Wheeler[1], un pequeño delincuente de la zona de Pittsburgh (USA) que, si se ponía zumo de limón sobre la cara, este actuaría como tinta invisible y no podría ser grabado por las cámaras de seguridad de los bancos.

McArthur, que a pesar de todo no era tan confiado, quiso probar esto por su cuenta y se intentó hacer una foto a sí mismo con una Polaroid para probar este efecto. Se cree que, con los ojos terriblemente irritados por el zumo de limón, no pudo hacer bien la foto y el encuadre salió desviado. Probablemente fotografió el techo de su salón.

Animado por un descubrimiento que le permitiría dirigirse tranquilamente a un banco sin despertar sospechas y atracarlo sin que nadie le grabase, entró a plena luz del día y untado en limón en dos bancos de Pittsburgh. Allí todas las cámaras lo grabaron nítidamente apuntando con su arma al cajero.

Con lo que no contaba el señor Wheeler es que su imagen saldría esa misma noche en los noticieros de las 11. Tan solo una hora después, sobre las 12:10, Wheeler fue detenido por la policía. Además, su casi metro setenta de altura y más de 120 kilos de peso lo hicieron fácilmente reconocible por los vecinos de Pittsburgh que indicaron a los detectives por dónde solía andar.

Al parecer, en el momento de la detención, Wheeler no salía de su asombro por haber sido detenido tan pronto y solo atinó a decir “¡Pero si me había puesto el zumo!” ¿Qué había llevado a este buen señor a creerse más listo que nadie y descubrir el secreto de la invisibilidad y el atraco perfecto? David Dunning, un profesor de psicología en la Universidad de Cornell, leyó esta noticia en el Almanaque Mundial de 1996 y se hizo preguntas similares.

Dunning pensó que, si Wheeler era tan tonto como para atracar bancos con zumo de limón, quizás ni el mismo se diera cuenta de su propia incompetencia, lo que le habría llevado a atreverse a hacer algo así.

Junto a uno de sus estudiantes, Justin Kruger, Dunning quiso saber si era posible medir si somos conscientes o no de nuestros propios límites y se animaron a hacer un estudio para intentar averiguarlo. Si fuéramos conscientes de hasta dónde llega nuestro conocimiento podríamos pensar “¡Eh! Espera un minuto, la decisión que acabo de tomar no tiene mucho sentido, mejor busco a alguien que me aconseje”. Pero ¿Y si no lo somos y nuestro propio desconocimiento nos hace pensar que lo sabemos todo?

Dunning y Kruger[2] tomaron como sujetos del estudio a diversas clases de psicología en su universidad a cuyos estudiantes les pasaron unos tests de lógica, gramática o sentido del humor. Una vez hechos estos tests, se le preguntó a cada estudiante en qué posición creían que habían quedado con respecto a sus compañeros.

Lo que pudieron comprobar en esos tests no le sorprenderá mucho después de lo aquí comentado: Los estudiantes que peor nota sacaron en los tests, creían estar entre los que mejores resultados habían obtenido. Sin embargo, aquellos para los que se probó que eran más competentes, creían estar engrosando las filas de los de peor resultado.

Esto dio lugar a lo que se conoce como el Efecto Dunning-Kruger: Las personas más incompetentes sobrevaloran su propia capacidad, pero además tampoco son capaces de reconocer la capacidad de los otros.

Tenga en cuenta este efecto cuando observe la dinámica con la que se desenvuelve cada día el equipo con el que trabaja. No permita que el desconocimiento de algunos miembros del equipo de trabajo les haga aventurarse demasiado a decisiones arriesgadas que no están bien valoradas. Escuche a aquellos más reflexivos y que admiten dudas, seguramente son capaces de intuir delante de ellos un abismo que no pueden rellenar ahora por esa inexperiencia o impericia. Procure evitar que la arrogancia que provoca el desconocimiento, y que convierte a algunos en líderes de equipo, lleve a todos por mal camino.

Téngalo presente también para sí mismo. Aunque hubiese sido usted uno de aquellos estudiantes que mejor puntuación sacaron en los tests de este estudio, siempre habrá un área de conocimiento, tecnología o campo para el que sea solo un novato. No permita que desconocer todos los factores y parámetros que deban influir en la toma de una decisión le lleve a equivocarse. Coméntela con todo el equipo y aquellas personas que considere que tienen buen criterio. Puede que le sorprenda (o incluso le alarme) la cantidad de cosas que usted no tuvo en cuenta.

Si quiere saber más sobre cómo la Agilidad puede ayudarle a su productividad y la de su equipo, no dude en comprar Dibujando la revolución ágil: Ahora a un precio especial.

Dibujando la revolución ágil en Amazon España

Dibujando la revolución ágil en Amazon.com

Dibujando la revolución ágil en Amazon México

Referencias:

[1] The Anosognosic’s Dilemma: Something’s Wrong but You’ll Never Know What It Is por Errol Morris en el New York Times

[2] Dunning-Kruger effect en la Wikipedia

¿Sabe qué tiene que ver una psicóloga de la era soviética o un atracador de bancos con cómo se gestionan los proyectos de la forma más eficaz? ¿Y con unos abogados que no quieren abandonar las máquinas de escribir? Son casos como esos los que explican por qué funciona la Agilidad o por qué otros proyectos no salen adelante fácilmente.

Ya está en preventa mi nuevo libro Dibujando la revolución ágil. Aquí podrá encontrar una explicación entretenida a todos los principios económicos o sociales que están detrás de las metodologías ágiles y que se explican en este libro de la forma más amena que me ha sido posible.

El libro se complementa con anécdotas e historias reales obtenidas de la experiencia en decenas de proyectos grandes y pequeños para explicar, de forma entretenida, justo lo qué vas a necesitar para entender esta filosofía y los mecanismos humanos que la hacen funcionar. El libro trata de ser entretenido evitando términos y palabrejas extrañas disponibles solo para entendidos.

No encontrará en este libro un aburrido listado de reuniones y roles de Scrum o de prácticas de Lean. No es un libro tampoco solo para informáticos y gente de IT. Cada capítulo está orientado hacia cualquier tipo de proyectos y productos, no solo a profesionales del software.

Mi anterior libro Gestión práctica de proyectos con Scrum llegó a alcanzar el puesto número 1 en ventas de ebooks de todo Amazon España. Estuvo también en numerosas ocasiones en el Top 100 compartiendo listado con Arturo Pérez Reverte o Almudena Grandes. Aún así a mucha gente se le hizo corto el libro. Este nuevo documento pretende ampliar el anterior y ser un digno sucesor del primero.

Aquí tiene algunos ejemplos de los capítulos y secciones que podrá encontrar en él:

• La increíble historia del robo de un banco y los equipos de trabajo
• Deje que le atrape el efecto Zeigarnik
• Agilidad o contorsionismo
• Efecto IKEA
• Ofrezca un trato justo
• Nada peor que la multitarea
• El coste de hacer las cosas mal
• El verdadero precio de la calidad

Si quiere saber más sobre cómo la Agilidad puede ayudarle a su productividad y la de su equipo, no dude en comprar Dibujando la revolución ágil: Ahora a un precio especial.

Dibujando la revolución ágil en Amazon España

Dibujando la revolución ágil en Amazon.com

Dibujando la revolución ágil en Amazon México

Este efecto, que recibe su nombre por el rey de Chipre que en la mitología griega se enamoró de la estatua que él mismo había creado, describe el resultado que tienen unas expectativas sobrevaloradas sobre el objeto de las mismas.

Rosenthal y Jacobson realizaron en los años sesenta un estudio con los niños de primero a sexto de primaria de una escuela de primaria de California. Se les dijo a los profesores de esos niños que la prueba que estaban haciendo a sus alumnos era indicativa del potencial de la capacidad intelectual de los niños. Los que mejores resultados obtuviesen en esos test mostrarían supuestamente importantes avances a lo largo del siguiente curso escolar. En realidad, era una prueba falsa que solo medía algunas aptitudes no verbales, nada que ver con el cociente intelectual.

La mayor dedicación y el aumento de las expectativas de los profesores sobre los alumnos que ellos consideraban superdotados hizo que estos avanzasen intelectualmente más que el resto. Tan solo ocho meses después de la prueba el grupo que obtuvo mejores resultados, especialmente aquellos que estaban en los primeros cursos, mejoraron su puntuación en los test de inteligencia. Había una asociación entre el rendimiento de los alumnos y las expectativas del profesor.

Sucede lo mismo cuando se gestionan equipos de trabajo. A veces nos formamos ideas preconcebidas, reales o no, sobre un compañero de trabajo. Quizás influidos por un comentario positivo de otro jefe de proyectos. Quizás por la buena imagen que ha dado su currículum, quién sabe por qué, pero el hecho es que se tienen buenas expectativas sobre su comportamiento. Se le dedica más atención, se aprecian más sus ideas y se acogen mejor sus inquietudes. Este compañero se sentirá más valorado y probablemente trabajará más y mejor.

¿Y al revés? El efecto contrario también funciona. Si a un niño le dices desde pequeño “¡Qué malo eres! ¡Qué mal te portas!”. Lo hará así toda su vida porque es lo que se espera de él. Él es malo e inquieto y así lo sentirá. Los psicólogos están llenos de adultos que acuden con sentimientos de culpa porque sienten que son “malos”.

También nos formamos imágenes negativas de compañeros con los que se ha trabajado anteriormente y no salió bien o quizás porque provienen de un proyecto que resultó un sonoro fracaso. Las expectativas serán bajas con respecto a ellos. Tenderemos a hacer menos caso de sus opiniones y revisando su trabajo seremos más escépticos o críticos con lo entregado. Bajará su moral y sus ganas de aportar ¿Por qué lo iban a hacer? No se les hace caso y se sienten decepcionados. Recuerde que si se les trata como si fuesen unos profesionales chapuceros esto se convertirá en una profecía autocumplida. Además de lo mal que los haremos sentir.

¿No se puede cambiar esto y tratar a todos sin hacer prejuicios, esperando lo mejor de ellos? Es el mejor equipo que tenemos y si los tratamos con buen ánimo probablemente también ellos hagan su mejor trabajo.

Agradezca el esfuerzo, felicite cuando algo haya salido bien, no se guarde los comentarios positivos, hágalos sentir partícipes de los éxitos. Evite también hacer hincapié en los errores, céntrese en las posibilidades de mejora, no busque culpables y los tendrá a su lado cuando el error sea suyo.

Haga esto con moderación y sin aspavientos, si no es realmente sincero no servirá de nada, solo generará rechazo. Repítalo de forma constante y manténgalo también, si puede, en las crisis más fuertes, cuando todo parece que se va a ir al traste. Es ahí cuando realmente va a consolidar el crédito ganado o perderlo de golpe si no ha podido mantener la coherencia.

¿Le ha gustado este post? Podrá ver más contenidos como este en mi nuevo libro: Dibujando la revolución ágil. Esté atento a este blog. Pronto anunciaré la preventa del libro a un precio especial durante las primeras cuatro semanas.