“Si no puedes nombrar al menos 5 cosas que no te gusten de las herramientas que usas: o estás en la luna de miel, o eres irracional”

- Jesse Noller, Python Committer

El pasado lunes Leo Soto nos representó en el evento más importante de agilidad (en Chile) organizado por ChileAgil con una charla que preparmos ambos[1] y cuyo mensaje es reflexionar acerca del daño que hace el fanatismo, la evangelización, la moda, o los ghettos cuando usamos metodologías ágiles.

Agradecemos al equipo organizador del evento por darnos el espacio y aceptar escucharnos hablar de las cosas que Odiamos de la agilidad en un evento que hace oda a la ágilidad.

[1] La charla estaba preparada para ser un diálogo entre Leo y yo, pero tuve a un accidente de tránsito mientras me dirigía al evento, así es que todo el mérito a Leo por haber improvisado mi parte.

Lo que sigue es la traducción del post http://blog.brodzinski.com/2010/08/suck-as-project-manager.html (Para que lo usen o lo muestren a los managers de proyectos a los que les dan deseos de agarrar por el cuello a veces, ¿o debo decir siempre?).

—

Recientemente, respondí una serie de preguntas acerca de los managers de proyectos en una organización que conozco. Una de las preguntas fue acerca de la poca importancia que cumple el role de los managers de proyectos allí. Luego de pensarlo se me ocurrió que son “Guardianes de los procedimientos”.

Lo veo bastante a menudo – Las personas que se preocupan más de hacer el trabajo según los procedimientos que de hacerlo bien hecho. Si la persona que te viene a la mente es un PM, quien ve el proyecto como una combinación de presupuestos y cartas gantts en vez de personas entonces ya saben a que personalidad me refiero.

La verdad cualquier procedimiento, no solo los relacionados a gerencia de proyectos sino también a desarrollo de software, requieren un esfuerzo significativo. Se necesita una política que asegure una práctica de cumplirlos hasta que la gente se acostumbre. Y si la gente no le ve valor a un procedimiento en específico no lo van a usar nunca. Esta es la razón básica por la que medir el tiempo en desarrollo de software siempre requiere algún tipo de política hasta conseguir que los desarrolladores lo hagan.

Mientras más procedimientos, más tiempo gastado en mantenerlos y menos tiempo gastado en hacer el trabajo real. Ustedes saben, aquel trabajo que realmente importa y que impulsa el proyecto hacia adelante.

Esto es algo que siempre me ha fascinado – ¿Como esos guardianes de los procedimientos encuentran tiempo para preocuparse por cada detalle del template del documento? – ¿Que ven en gastar 1 hora discutiendo un cambio de 5 horas en la estimación de la gantt en una sala con 12 personas más?. Y solo porque este cambio va a hacer que el proyecto se salga del presupuesto. ¿Por qué pelear acerca del calendario inicial es tan importante, a pesar que el alcance del proyecto cambió de manera significativa en el entretiempo?. Y tres veces.

Entonces sí, si lo que tú quieres realmente es joder como manager de proyectos, esta es definitivamente la forma de hacerlo. Debes comenzar a pensar rápidamente acerca de nuevos bellos procedimientos que hagan la vida de los demás más miserables. Después de todo, esa es la forma en que tu vas a demostrar tu poder.

—

Revisión: Leo Soto.

Cada vez que leo un nuevo artículo sobre «Agilidad» (o intento, pues hace tiempo que no termino ninguno), solo encuentro más y más tecnicismos.

Esta de moda ser ágiles, y han aparecido un puñado de vendedores de agilidad que intentan ganar dinero tratando de convertirte a la religión ágil con libros, cursos, certificaciones, lo que sea sin importar condiciones o entornos, todos podemos ser ágiles, ¡vamos mierda que se puede!

Y sí, por supuesto que incluso nosotros hemos usado en más de una ocasión alguno de los términos para también «ponernos en onda» y porque bueno a veces los clientes nos preguntan sobre ellos, ¿que remedio?.

Entonces, tú lento que me escuchas, o mejor que me lees: NO intentes ser ágil, se productivo, genera valor. Haz las cosas guiado por el sentido común, no porque lo leíste en un artículo, usa tus instintos y los medios con los que cuentas y solo se productivo; ¿Como?, como seas capaz de serlo y el medio te lo permita.

Aquí van algunos consejos de alguien que cada vez entiende menos de agilidad y más de productividad y que ha ganado fama por ser lo último:

1. Usa al máximo al menos 6 horas del día y no más de 8 sin distracción (descansando lógicamente, recuerda, sentido común[1]), para las demás cosas que no generan productividad (como ver un video en youtube o leer blogs) hay tiempo.
2. Toma una tarea a la vez y termínala sin interrupciones, si es muy grande sepárala en pequeñas tareas.
3. Escribe pruebas de conceptos antes de empezar con las cosas que no tienes idea de como hacerlas (no las hagas, estudia y prueba cosas).
4. Si tu tarea involucra escribir programas con interfaces visuales haz prototipos gráficos de lo que debes hacer y pregunta al cliente si están bien, no te preocupes por la lógica antes de la gráfica, es más fácil programar la lógica cuando te guía una interfaz.
5. Si tienes dudas de como hacer algo no asumas la solución, pregunta sobre el tema, llama al cliente, coméntalo con tus colegas.
6. Trata de no depender de factores externos para desarrollar la solución, con tu laptop debe bastar (puede tomar tiempo hacerlo, pero lo vas a recuperar en el camino).
7. Si algo es muy difícil de hacer no  lo hagas sin antes comentarlo con el cliente, él quiere una solución, pero no tiene que ser esa, pueden negociar otra que que le permita tener lista la funcionalidad en menor tiempo.
8. Intenta plantearte los casos de bordes, si no usas TDD (tecnicismo, ja) no significa que no puedas ser productivo, escribe los test en un archivo de texto, y antes de entregar pruébalo todo de nuevo.

Usa el sentido común para ser productivo y no ágil. Eso te va dar más valor.

[1] Nosotros tenemos una mesa de ping-pong en la oficina, y se puede usar libremente (ehh, o sea como dictaría el sentido común, pocas veces en el día.)