Sé que soy políticamente incorrecto, pero cada vez estoy más convencido de que muchos seudo-gurús son a las empresas, lo que los telepredicadores a la sociedad. Estas charlas que acabo de cruzarme ahora son sólo una muestra, y además de lo más digna, que las hay mucho más cutres.
Es posible que esté equivocado, y seguro que ellos y su público están convencidos, pero aunque así fuera, estamos en un planeta algo loco, en el que tiene el mismo precio dos días de charla (1.500$) de obviedades de agilidad, trabajo de equipos auto-organizados, bla bla, rodeada de puesta en escena, que la vida de unos 25-30 niños. (39€ cada niño).
Hacer de una empresa un campo de scrum implica a toda la organización, no sólo a los programadores, o a la gestión de proyectos. Las organizaciones son realidades sistémicas, interrelacionadas.
Olvidemos, o desaprendamos (y si no lo conoces, mejor que mejor) eso de que scrum funciona con tres roles: propietario de producto, scrum master y equipo.
El grado de éxito de la implantación ágil en la empresa no depende tanto de implantar unos roles, sino de asignar con solvencia las responsabilidades necesarias en la organización para que se desarrolle la agilidad; y las que se deben cubrir de forma coordinada y alineada con la visión de la organización pertenecen a tres categorías clave:
Gracias a la comunidad ágil de Chile, por el recibimiento y la invitación a participar y compartir en chileagil.cl
Con todo el interés para colaborar en el desarrollo de una comunidad profesional ágil, en la medida y dedicación que me resulte posible nos leemos también por allá. Empezamos ya mismo dando vueltas a cómo suelen considerar las empresas a los programadores .
Si resides en Chile y te interesan la aplicación de metodologías ágiles en empresas o proyectos de software:
A las empresas no las valoramos por su realidad, sino por la percepción que de esa realidad tenemos. La clave no es por tanto que sean buenas, sino que se perciban como buenas; hecho que hace de las certificaciones de calidad herramientas de marketing, antes que de mejora; y como el hábito no hace al monje, quienes usan ISO, CMMI... sólo por la apariencia, no los los llevan como hábitos sino como disfraces.
Como la agilidad empieza a ser conocida, y reconocida, están empezando a surgir disfrazados de ágiles; aunque en este caso no se trata de farsantes, sino de ingenuos. No se disfrazan para engañar, sino por creer que las prácticas de backlogs, reuniones guays, burndowns, kanban, etc... tejen un hábito milagroso que transforma en ágil a la empresa que lo adopta.
Claro que es normal concluir que la agilidad es un conjunto de prácticas, cuando la información y formación ágil se ofrece con una distorsión de foco que consume todo o casi todo el esfuerso en las prácticas y las formas: en lo fácil; y pasa de puntillas sobre el fondo: lo difícil.
Me he encontrado esta recopilación de pizarras, juegos, gráficos y otros ejempos de artefactos para gestión visual ágil, realizada por Peter Janssens y Patrick Debois.
Es curiosa la idea que de apalancamiento y trabajo negativo expone Andrew s. Grove en High output management:
Los directivos realizan (o deberían realizar) trabajos de apalancamiento elevado, llamando apalancamiento a la medida de las consecuencias de productividad para la organización. El rendimiento de un directivo se relaciona con la actividad directiva a través de la siguiente ecuación:
Rendimiento directivo = Rendimiento de la organización = L1 x A1 + L2 x A2 +...
Esta ecuación nos dice que para cada actividad que un directivo lleva a cabo (A1, A2, etc.) el rendimiento de la organización debería incrementarse en algún grado. Por tanto, la extension en que se haya incrementado dicho rendimiento viene determinada por el apalancamiento de esa actividad: L1, L2, etc
Un tipo de actividades de elevado apalancamiento son las que afectan a muchas personas, como por ejemplo cada vez que un directivo imparte a un grupo su conocimiento, habilidades o valores.
Aprovechando que me voy a acercar por Santiago de Chile, si te apetece y podemos coincidir, tomamos un café. En serio, como andaré de domingo a miércoles (24 a 27) y supongo que habrá huecos entre la charla que tengo el martes y un par o tres de entrevistas, si se tercia, será un gusto compartir café y un rato de conversación.
Si a alguno os interesa, avisadme (jpalacio--a--navegapolis.net) y el domingo en cuanto tenga la agenda vemos si podemos coincidir.
Cambiar la burocracia material de documentación y procesos evitables, por la "burocracia ágil" es un riesgo de jefes (gestores, "scrumes-gestores", team leaders, product managers...) que, o ya padecían, o han adquirido con la agilidad una reunionitis aguda, que puede acabar siendo crónica.
Hace pocos días, en un correo me comentaba Julio que la implantación de scrum había dado un especial "gustillo" a su jefe por las reuniones, que empezaba a preocupar y cansar a muchos, y cuestionaba, con mucho tino, la existencia de una "burocracia ágil".
Las reuniones tienen algo de puesta en escena, y también de laboratorio de dinámica de grupos, por lo que algunos gestores con necesidades especiales de atención o de reconocimiento o afianzamiento, o socialización, etc. (vamos, ¿¡quién de nosotros está libre de algo de esto!?) encuentran (o encontramos) en ellas el suministro fácil de una dosis con la creencia ilusa de que están realizando su trabajo con especial competencia.
Las reuniones son un recurso muy caro, y por eso pueden ser el mayor agujero de ineficiencia en empresas de gestión paradójica, en las que siempre está ocupada la sala de juntas con reuniones interminables, mientras el responsable de recursos humanos, apunta a los que sobrepasan los 20 minutos de la pausa del café.
No sé si sería útil un "taximetro" en la sala, como el Meeting Miser de PayScale; pero quitando las reuniones "institucionales" un consejo es cambiar el "chip": abandonar la mesa y las sillas, por charlas de pie, con un objetivo claro, junto a una pizarra, y un límite de tiempo de 20 minutos.
Las empresas que desarrollan texto, las "texto-factory", deben ser muy cuidadodas en la contratación de personal, porque las diferencias de productividad y calidad entre los mediocres y los mejores es muy grande; siendo, generalmente, los mecanógrafos los más productivos, seguidos de traductores, notarios, novelistas y por último los poetas.
Pero aunque esto es lo habitual, tampoco hay que actuar con prejuicios, porque siempre hay excepciones, además de que dentro de cada categoría también hay diferencias muy grandes; y así, por ejemplo, entre los novelistas, los hay tan buenos como Corín Tellado, que con una obra de más de 4.000 libros, deja muy atrás a mediocres como Cela o tantos otros.
Estas empresas necesitan modelos de ingeniería con procesos que midan objetiva y cuantitativamente la eficiencia con alguna de las métricas que ha desarrollado la "Ingeniería del Texto", como puede ser el número de líneas (LOC LOT) por hora, o por día; y la calidad, a través de la densidad de erratas y faltas de ortografía.
Empleando Wikirank, se puede comprobar que Scrum despierta de 3 y 10 veces más interés que otros modelos y prácticas de desarrollo de software (Extreme Programming, Lean Software Development, DSDM, FDD, RUP, CMMI, ISO 15504...)
Extreme Programming, FDD, Lean Software Development... tienen conocimiento tan útil o más que Scrum en lo que a agilidad se refiere, pero... el márketing es perverso.
Se trata de la "cuarta ley del Marketing" (1). La ley de la percepción: "Lo que importa no es el producto sino su percepción".
La programación es, las más de las veces, un trabajo creativo que casi siempre se realiza con presión. ¿Son compatibles presión y creatividad?. ¿Somos capaces de realizar un trabajo creativo cuando nos sentimos presionados?.
El sentido común nos apresura a responder que no, que hay que trabajar de forma relajada... pero éste tampoco es un buen consejo: la ley de Parkinson tiene bien merecido el calificativo de "ley", porque siempre "el trabajo tiende a expandirse hasta llenar todo el tiempo disponible".
Parece que hay que considerar más factores, y este artículo (1) apunta otro que tiene pinta también determinante: el entorno de trabajo. Hay entornos "buenos" y "malos".
En el podcast 45 de Java Hispano , Jorge Rubira charla con tres buenos conocedores de la agilidad: José Manuel Beas , Xavier Quesada y Xavi Albaladejo sobre los principios y el porqué del desarrollo ágil: en qué consiste, las ventajas de involucrar al cliente, trabajar en iteraciones cortas, evitar las barreras de comunicación de los procedimientos documentados, trabajar en equipos reducidos, con líneas de integración continua, refactorización y deuda técnica, etc.
Añado "Confessions of a Serial Product Owner" a la lista de libros: una guía breve para propietarios de producto, escrita por Anna Forss que combina el conocimiento e interés por dos áreas de prácticas de gestión que a muchos puristas espantaría: Microsoft Project y agilidad.