Archivos de Categoría: Blog

¿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.

Tom DeMarco y Timothy Lister en su libro Peopleware consideraban que hay dos teorías fundamentales de gestión que son aplicables a la gestión de proyectos. Una, la primera de ellas y quizás la más primitiva, considera que el valor o riqueza existente en la Tierra es una cantidad limitada. Según esta teoría, cuanto más se trabaja para extraerla, más riqueza se obtendrá (y menos quedará para los demás).

Inconscientemente, es la teoría que aplican muchos managers cuando deciden usar las horas extra, los fines de semana trabajados o la penalización si los trabajadores se marchan a su hora. Están dividiendo el número de tareas realizadas a la semana entre 40 horas y no entre las 60 realmente trabajadas. Así creen aumentar ellos la, mal llamada aquí productividad, un pequeño fraude en las cuentas que tanto cuesta a los trabajadores.

Según esta manera de pensar, la tarea del gestor es la de extraer el máximo de trabajo (el trabajo de los colaboradores) usando la menor cantidad posible de recursos (el número y sueldo de esos colaboradores). A partir de ahí el cálculo es sencillo, para maximizar la “productividad” se deberá aumentar el número de horas empleadas y pagar poco por ellas o no contratar muchos técnicos.

Es el cálculo básico que realizan los managers que, como comenta Javier Garzás en su blog, pretenden aumentar la productividad añadiendo 10 becarios de golpe a un proyecto. Imaginen el impacto de eso en un proyecto en un proyecto normal: Hay que parar de trabajar para enseñar a esos nuevos compañeros, buscar algo que hacer para cada uno de ellos, revisar lo que hayan hecho, atender sus preguntas, etc. En lugar de avanzar solo se va a conseguir retroceder durante mucho tiempo.

En la Mecánica Clásica, el trabajo empleado para mover un objeto es el resultado de multiplicar la fuerza empleada por el desplazamiento conseguido. Cuanto más lejos se haya conseguido desplazarlo, más trabajo se ha hecho. Si ponemos a diez personas a mover una gran piedra y esta no se ha movido un milímetro, según la Física, el trabajo realizado es cero. Sucede lo mismo con esta mal entendida productividad.

Si en 40 horas apenas se es capaz de entregar un mínimo de tareas hechas es que algo está fallando en los métodos productivos. Si hay que emplear 60 horas a la semana para conseguir obtener algunas tareas más, eso no es productividad real, en un engaño en los cálculos. Se aumenta un poco la productividad a coste de disparar la fuerza empleada. Y esto sin tener en cuenta el cansancio y la falta de motivación producidos por no tener suficiente tiempo de descanso. Solo se estará consiguiendo reducir el desplazamiento conseguido para la siguiente semana.

Los que aplican estas soluciones para intentar aumentar el trabajo conseguido solo se están fijando en una parte de la ecuación. Miran la fuerza, el número de horas que se trabaja, pero se olvidan de la otra parte, lo que se consigue con esa fuerza, el desplazamiento obtenido ¿De qué vale aumentar solo la fuerza si puede que incluso se esté perjudicando con ello los resultados?

Ya lo dice el ingeniero español José María Acosta en su libro sobre el uso eficaz del tiempo: “Trabajar más horas o más deprisa no es la solución”. Pasar más horas en la oficina tampoco lo es.

¿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.

¿Cuántos proyectos conoce que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿No? Esto pasa en casi todos los sectores, no solo en la industria del software, pero probablemente esta industria tiene una tasa de proyectos fracasados más alta que otras. Puede verse esto tras cada uno de los estudios del informe CHAOS del Standish Group que, siendo aún muy discutibles, pueden dar una aproximación del estado de la industria.

Las estimaciones de tiempo y coste de un proyecto se salen de toda escala y se incumplen habitualmente los relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tienen todas las personas no deprimidas. Debido a él, se cae, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómeno, el de la falacia de la planificación, es debido a que los seres humanos tienden a subestimar cuanto nos va a llevar terminar una tarea. Se es demasiado optimista y siempre se piensa que se va a tardar mucho menos de lo que finalmente va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio a los estudiantes de una universidad. En él preguntaron a 87 estudiantes cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto. solo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55,5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness). Es el efecto que nos dice que por muy bien que se planifique el proyecto será difícil planificar los imprevistos porque son eso, imprevistos, y no se conocen de antemano. Se planifica todo lo relacionado con las especificaciones del proyecto, pero nos olvidamos de calcular los imprevistos. En nuestra mente, no tenemos en cuenta las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera.

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: “Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter”.

Y si esto ocurre y el proyecto se alarga más de lo previsto, probablemente se caiga todavía en más costes de lo que supone terminar más tarde. Como no se llega a la fecha del fin del proyecto la presión llevará a meter a más gente dentro del proyecto para intentar terminar a tiempo. Lo que se conseguirá es tener que contabilizar gastos extra directos como el salario de estas nuevas personas, pero también indirectos de los cuáles no siempre se es consciente.

Al incluir más personas se olvida que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores a los que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya decía Brooks en los años 70: “Añadir más gente a un proyecto retrasado, hará que se retrase aún más”.

Pero la presión por terminar a tiempo aún hará incurrir en más costes en el proyecto. Las prisas terminarán haciendo bajar la calidad del producto que se produce. Aparecerán más errores que también necesitarán tiempo para ser corregidos, o se saltarían las pruebas para asegurar la calidad del proyecto con lo que saldrá a la venta con defectos. Errores que harán perder la confianza y credibilidad del cliente. Y por supuesto, queremos que este cliente nos contrate de nuevo ¿No?

Vimos la semana pasada un poco de historia sobre Extreme Programming y su creador, Kent Beck. Veamos ahora los valores y fundamentos detrás de XP y que hacen que este funcione:

Simplicidad: Se trata de usar la solución que funcione que sea la más simple posible. Aprovechar el concepto de la Navaja de Ockham o seguir el principio KISS (Keep It Simple, Stupid) para desechar ideas demasiado complejas y no hacer over-engineering.

Para ello se tomarán pequeños pasos hasta el objetivo y se iterará hasta conseguirlo. Se adaptará por el camino a lo que se haya aprendido en lugar de pensar una solución compleja al inicio y desarrollarla al pie de la letra.

Comunicación: Kent Beck se dio cuenta de que muchos de los problemas en los equipos de trabajo se debían a que no había una correcta comunicación entre sus miembros. Para ello propone:

1. Que todos los miembros del equipo de trabajo se comuniquen cara a cara de forma diaria (similar a las reuniones diarias de Scrum)
2. Que todo el mundo trabaje en todas las partes del proyecto, desde la toma de requisitos hasta la codificación.
3. Que se cree un sentimiento de pertenencia al equipo y de cooperación entre todos los integrantes.

Coraje: Se trata de crear un ambiente en el que no haya miedo a ser castigado o criticado por cometer un error o por ir retrasado en su tarea. Un ambiente en el que cada persona se sienta libre de decir cuál es realmente el estado en el que está la tarea en la que está trabajando.

Se quiere conseguir la valentía suficiente para que se tomen decisiones libremente porque se busca lo mejor para el proyecto. Se trata de evitar, por ejemplo, que se documenten páginas y páginas de lo que realmente son excusas. Cuando se escribe mucha documentación en realidad se quiere decir “Se me dijo así por lo que yo diseñé/implementé esto”. De esta forma se quiere que nadie pueda poner un “pero” a la decisión que se ha tomado.

Feedback: En XP se da por sentando, que no se puede implementar la opción correcta a la primera. Se debe iterar y volver a mejorar la opción tomada o desarrollar una diferente. Para conseguir esto se necesita obtener retroalimentación de lo que sucedió en la iteración anterior para poder mejorar.

Se generará tanto feedback como se pueda manejar y tan rápido como sea posible. Se irá más despacio si el equipo no puede adaptarse a tanto feedback recibido.

El feedback puede venir en muchas formas posibles, por ejemplo, en resultados de los test ¿Funcionaron? ¿Qué falló? Opiniones de los clientes que ya están usando la aplicación, o funcionalidades introducidas en la aplicación ¿Recibieron muchos clics? ¿Las completaron? ¿Han preguntado por ellas?

Respeto: Es el valor que resume los otros cuatro y sin el que los demás no funcionarán. Si no hay respeto entre los miembros del equipo y éstos no respetan al proyecto y sus compañeros difícilmente se obtendrá un feedback correcto. No tendrán el coraje suficiente para tomar las mejores y más simples decisiones y fallará la comunicación. Nadie, en un equipo de trabajo que usa XP, es más importante que nadie. Ni lo es el jefe del proyecto sobre el resto de miembros ni lo es el ingeniero software sénior con muchos años de experiencia en el trabajo.