Mi mundo habla en "proyectos" pero yo quiero ser "ágil"

Está claro, al igual que el idioma técnico más usado es el inglés, el “idioma” más usado en el mundo técnico es el “proyectos”. Y creo que hoy ya deberías tener claro que ese no es un buen “idioma”, no me voy a repetir sobre los problemas de la herencia de los proyectos al mundo software, técnico, y por extensión, a todo aquel que trabaja con “productos” de carácter “intelectual”.
Si aún aún no tienes claro el problema de los proyectos… ya te dije que no me voy a repetir, ya le he dedicado mucho, pero te dejo cosas que deberías leer y un vídeo que deberías ver:

• 6 peligros de pensar en proyectos
• Gestión orientada a proyectos vs orientada a equipos (llámala ágil)
• En vez de “un Scrum por proyecto” mejor un “Scrum por equipo”
• Más allá del concepto “proyecto” en tecnología #noprojects #beyondproject

 

Al igual que los que tenemos inglés de guerrilla (Consejos, aventuras y desventuras de un informático con el inglés e “inglés de guerrilla”), que escuchamos inglés y nuestro cerebro traduce lo mejor que puede a español, también tú, si tu mundo habla en idioma “proyectos” deberías traducirlo internamente al idioma “equipos – productos – agilidad”.
La excusa de es que “mi cliente habla en proyectos”, y por eso me resigno a trabajar mal, es tan mala como la de “no sé inglés”, y por eso «no voy a leer nada en inglés»… el problema va a ser tuyo, no de los que inventaron en inglés ni de los que trabajan en idioma proyectos.
Está claro que si tus clientes hablan en “proyectos” no vas a ser un nativo “ágil”, pero eso no implica que no puedas buscarte las mañas. Vamos con dos situaciones típicas de negocios cuyos clientes sólo quieren oír la palabra «proyectos» y algunas razones que no impiden trabajar internamente de manera ágil.

PARENTAL ADVISORY: EXPLICIT CONTENT

Ninguno de los siguientes supuestos es el ideal, ni el objetivo en tu vida, pero… la vida es así. Mientras consigues moverte a una situación ideal, que tu cliente piense de otra manera, aquí te dejo algunas cosas que puedes pensar para trabajar de manera ágil en un mundo de proyectos.
Y también te digo una cosa… si realmente trabajar de manera ágil, y llegases al punto en el que las ventajas de ello son muy claras, quizá ahí no te sea tan difícil hacerle ver a tu cliente que hay otras maneras de trabajar.

Tu cliente te pasa una especificación de requisitos detallada, con todos los requisitos y cerrada, y no quiere verte hasta dentro de meses cuándo espera que llegues con todo el desarrollo listo

No estás, dentro de lo malo, en la peor situación (ver siguiente caso, que no te de ni requisitos) ¿Qué puedes hacer? Nada, absolutamente nada, ni los requisitos cerrados ni las fechas cerradas, te impide trabajar en iteraciones cortas, o usando un ciclo de vida ágil.
Partiendo de la mala situación de requisitos cerrados, nada impide que los ordenes por prioridad, hagas una especie de Backlog, y vayas haciendo incrementos en Sprints de pocas semanas con equipos pequeños, multifuncionales y autor-organizados.
Así ganas un montón de ventajas, antes de meterte en un cascada. Vas eliminando la incertidumbre de hacer una gran entrega al final, vas viendo si es realista la fecha de entrega y si hubiese algún problema con la fecha, al menos, entregas algo que funciona, aunque pueda faltarle algo de funcionalidad (situación mucho mejor que meterte en la incertidumbre de un cascada).

Tu cliente te pasa algo muy general de lo que quiere, ni llamarle requisitos, y no quiere verte hasta dentro de meses cuándo espera que llegues con todo el desarrollo listo

Caso similar al anterior, con más razones para usar un ciclo de vida ágil… ya que te va a tocar a ti sacar los «requisitos». De nuevo, nada, absolutamente nada, te impide «de puertas» adentro trabajar usando un ciclo de vida ágil.
Vas a tener que crear, o inventar, tú los requisitos, ya incluso llamémosles historias de usuario, hacerte un Backlog y trabajar por incrementos en Sprints de semanas. Beneficios, los mismos que en el caso anterior pero ampliados: vas viendo la evolución, eliminas la incertidumbre de la entrega final, sabes desde casi el principio con qué vas a llegar al la futura fecha de entrega, siempre tienes algo listo, etc.