Tú no quieres Agilidad, quieres proyectos predictivos cortitos

Cómo lo lees, no mires hacia otro lado, no mires a ver si alguien te está mirando señalándote con el dedo acusador: Tú no quieres la Agilidad, quieres proyectos predictivos cortitos y lo sabes

Después de varias conversaciones con equipos de desarrollo de software que trabajaban para clientes que querían agilidad a toda costa, había un denominador común en sus quejas.

Todos los clientes lanzaban sus necesitamos scrum, scrum master, equipos autoorganizados, equipos autogestionados, etc., es más lo exigían no sólo de palabra, sino en sus RFP, en sus pliegos, en sus propuestas de oferta, pero… ¿qué pasa luego en la realidad?

Pues que estos mismos clientes, piden en una iteración (en un sprint) que se les entregue el diseño gráfico de la aplicación y, una vez aprobado, en el siguiente sprint se comience a desarrollar. También piden que todas las personas del equipo imputen las horas que trabajan cada día y a qué tarea lo hacen, piden que haya un documento escrito con todo lo que implementa en la aplicación, piden cerrar el alcance antes de comenzar con los sprint, piden un precio cerrado dentro de un alcance y en un tiempo fijo, piden cosas que tienen sentido en los modelos predictivos, pero no en los ágiles.

Y lo hacen, porque realmente no entienden que ser ágil, igual que lean, etc. necesita una serie de compromisos por ambas partes, proveedor y cliente, y necesita de un cambio de mentalidad, de un cambio cultural, para dejar de hacer las cosas tal como las hacíamos para hacerlas de otra forma.

Si no vas a cambiar, querido cliente, tu forma de hacer las cosas, tu cultura de hacer las cosas, la organización de tu empresa en cuanto a presupuestación, entrega de fondos, cooperación, colaboración,… no tiene mucho sentido que te sigas empeñado en tener la Agilidad, mejor dedícate a realizar proyectos predictivos de otra forma, proyectos predictivos cortitos.

En estas conversaciones, la gente exponía que lo que de verdad querían sus clientes eran entregas más frecuentes, poder probar las cosas cuanto antes y que se definieran por escrito los requisitos. Pues ya está, la solución son proyectos predictivos cortitos, proyectos predictivos que duren 1 mes, 2 meses a lo sumo, no más, proyectos en los que se puedan hacer demos frecuentes sin esperar al final del proyecto.

¿Que entonces no estarás siendo ágil? No en cuanto al Manifiesto Ágil, pero no importa, lo que tienes que hacer es mejorar lo que estabas haciendo hasta el momento y empeñarte en realizar la “agilidad” sin el cambio cultural y demás tampoco te va a reportar sus beneficios.

Párate a pensar y no pierdas más el tiempo.

Si conoces los proyectos predictivos, si sabes lo que pedir, lo que esperar, lo que ofertar, conviértelos en un caso de éxito limitando su tamaño, haciéndolos breves, aprendiendo tras su implantación las lecciones aprendidas que hay detrás de ellos y tomando decisiones para mejorar, para MEJORAR, porque no te olvides de esto lo importante es MEJORAR ni utilizar esta técnica u otra, MEJORAR, hacerlo cada vez mejor.

La cuestión es no comparar la agilidad con los proyectos predictivos que fallan, sino la agilidad con los proyectos predictivos. Los fallos hay que corregirlos, pero si cometes fallos en proyectos predictivos los cometerás también en los ágiles y no por el framework, metodología o como quieras llamarlo simplemente porque alguien que es el cliente, que no entiende el espíritu de lo que va a usar, ni se ha preocupado en saber cómo se obtienen sus beneficios te va a decir que ¡esto lo quiero y ya! y alguien de tu empresa dirá la famosa frase de “El cliente siempre tienen la razón”.

Así que no te calientes proyectos predictivos cortitos. Ni más ni menos ya lo dice el Chaos report cuanto más pequeño el proyecto menor probabilidad de fallo, independientemente del marco de desarrollo aplicado.

Be short my friend!