Salvar al soldado ágil

Hoy he podido comprobar como hasta el más convencido de los agilistas cede a las presiones de la gerencia porque es a lo que estamos acostumbrados y no se nos ocurre defender nuestra profesionalidad con argumentos sino con excusas. Como el agraviado es un buen amigo, daré su nombre. 😉 (Vaya uno a tener amigos para esto)

dijo hoy por twitter lo siguiente:

semuratAug 03, 10:47am via HootSuite

@semurat odio a los listos q teniendo una aplic completa y COMPLEJA de 2 años te pidan que hagas un modulo igual, pero “sencillo” en 15 días

Después de varias “puyitas” (por mi parte) creo que lo clavó al decirle que:

ialcazarAug 03, 12:30pm via HootSuite

@semurat Si el tiempo y el precio son cerrados, cláramente el alcance será variable, es decir no entregaras todas las funcionalidades

ialcazarAug 03, 12:31pm via HootSuite

@semurat o bien, como tienes que entregar todas las funcionalidades (alcance y precio cerrado) el tiempo será variable, es decir, retrasos

ialcazarAug 03, 12:34pm via HootSuite

@semurat o bien entregas a tiempo, lo q quería el cliente (en principio) pero lleno de fallos ya que “no dió tiempo a hacerlo mejor”. Ánimo!

En definitiva, Jorge podría haber explicado esto mismo a sus jefes. ¿De qué habría servido? A largo plazo estaría sentando las bases de la credibilidad de Jorge como profesional. A corto plazo estaría dando la oportunidad (convendría explicitarla, por si acaso) de que la gerencia priorizara los objetivos, dando la oportunidad a Jorge de entregar lo que más valor ofrezca a sus jefes, lo que podría llevar a una mayor credibilidad como profesional. En ambos casos, no hay nada que perder y sí mucho que ganar. 🙂

Si a alguien le interesa la opinión autorizada de UncleBob al respecto de estas situaciones, justamente refiere una muy, muy parecida en su charla “Clean Code I”. La podéis descargar desde el BitTorrent de la NDC2010 (Conferencia que se celebró recientemente en Noruega).

Por favor, si alguna vez véis a algún compañero en esta situación, recordadle que tiene más opciones que “aceptar lo inevitable”. Ayudad a salvar al soldado ágil.

  • Pingback: Tweets that mention Se hace camino al andar… » Blog Archive » Salvar al soldado ágil -- Topsy.com()

  • reemplazable

    En mi empresa simplemente te hubieran llamado romántico y te hubieran dicho que te dejes de tonterías y te pongas a trabajar. Y que ya te dirán ellos cuando parar. 😀

  • Vaya la que le habéis dado al pobre @semurat, con el marrón que tiene… Ánimo @semurat
    En mi experiencia lo más típico es que esto acabe en retraso épico del proyecto. ¡ Y es que la realidad muerde, y mucho, aunque nos empeñemos en lo contrario ! Veo dos escenarios típicos para el proyecto de @semurat:
    a) El equipo y el gerente se dan cuenta de que el proyecto se va a retrasar y simplemente no se lo dice al cliente hasta el final del proyecto. Si el proyecto es importante para el cliente, este tragará ya que no puede dar marcha atrás y abortar tan tarde, con lo que el proyecto se retrasa y punto, seguramente se eche más madera para que se retrase menos, pero todos sabemos que esto es ineficaz, sobre todo al final del proyecto.
    b) El proyecto se entrega a tiempo, con calidad pésima. Se pone en producción pero se tarda bastante tiempo en arreglar los suficientes bugs como para que la aplicación sea útil al cliente. En realidad esto es un retraso encubierto, ya que se tarda más de lo pactado en tener una aplicación funcional y usable, pero oficialmente el proyecto “está entregado en fecha”. Si la fase de arreglo de bugs se presupuesta a parte como una fase de “mantenimiento”, la empresa va a ganar un dinero extra sobre el presupuesto inicial del proyecto, lo suficiente como para compensar el retraso real del proyecto.
    En ambos casos el cliente se queda muy descontento. Lo malo es que puede ser que considere estos escenarios como inevitables, y se los esté esperando desde el principio.
    Pregunta: ¿el comercial que vendió el proyecto se lleva comisión por volumen de la venta o sólo por el beneficio del proyecto? En el primer caso, el comercial va a decir cualquier barbaridad para vender, ya que una falta de beneficios del proyecto no le afecta.

  • Juan Quijano

    Dios, que teniendo un marrón como el que tenía, que además lleguen los “listillos” dandole consejos de como tratar con tu gerente desde un punto de vista “Agile”…

    ¿O no te has dado cuenta del tufo prepotente y paternalista de tu post?

  • Bueno, bueno…ser protagonista de una entrada del blog de jmbeas…qué gran honor para un pequeño saltamontes como yo, aunque haya sido para darme un repaso 😉

    La verdad es que a veces soy muy llorón y caigo en el desánimo de luchar contra los elementos. En este caso además aparecen dos factores que no ayudan a que intente sobreponerme:

    Había empezado a escribir una respuesta muuuuy larga, pero creo que no os debo castigar con ello. Sólo decir que la empresa sigue un camino y yo otro. Intentar ser ágil en una empresa en que se menosprecia ese término hasta que hay un proyecto que se quiere ganar y piden Scrum, y te piden a ti que documentes algo que simplemente lo quieren porque lo piden no por convencimiento y aguantando risitas y mofas de ignorantes que son comerciales y porque se han “bajado” un libro de Scrum piensan que ya saben y te van a dar consejos a ti…lo siento, el trabajo es dia a dia y no solo por tener etiquetas demuestras nada.

    Hay más detalles por detrás que no voy a narrar porque no es el sitio ni debo hacer público.

    Agradezco a @ialcazar devolverme a la realidad y demostrarme que sea lo que sea algo se va a resquebrajar: o tiene retrasos o tiene fallos…casi prefiero lo primero.

    ¿Por qué prefiero los retrasos? Porque yo ya aviso de los problemas antes de que lleguen, porque si hay fallos en lo entregado mi credibilidad como desarrollador queda en entredicho. Porque los tiempos no los he marcado yo ni se me ha preguntado, y porque “alguien” ha cedido a una exigencia del cliente que no es viable en plazos.

    Y visto cómo están las cosas ya he resuelto el tema del alcance: se va a desarrollar lo que más valor da al cliente obviando partes de la aplicación original que no aportan valor al objetivo de este módulo “reducido”.

    Gracias a los dos por “leerme la cartilla” para sacar adelante esto.

  • dario

    la metodología agil es una moda, como tantas modas ha habido en los últimos 30 o 40 años. es una vuelta de tuerca mas a intentar mejorar el proceso de desarrollo, que como siempre a veces se puede aplicar y otras veces no.

  • jmbeas

    Queridísimo Jorge, ya sabes que si me he atrevido a nombrarte y ponerte “en la picota” es por el afecto y el respeto que te tengo. Si no le puedo decir lo que pienso, abiertamente, con transparencia, a un agilista convencido, ¿a quién se lo voy a decir si no?

    Bueno, al tema. Este artículo en realidad es una glosa de lo que nos ocurre (nos viene ocurriendo y, desgraciadamente, nos seguirá ocurriendo) día a día en nuestro sector. No es algo extraordinario. Recientemente ha habido un artículo que ha batido record de comentarios en JavaHispano y tampoco han faltado en la lista de Agile-Spain. La mayoría se queja de lo mismo: “la dura realidad”. Creo que fue el TíoAlfredo el que dijo lo siguiente:

    decimos cosas como “necesitamos que scrum funcione en el mundo real y bla,bla” cuando en realidad lo que necesitamos es cambiar ese mundo, que será real, pero es un completo despropósito.

    Por eso mismo, porque no es algo raro, pero sí es algo que nos hace infelices y estar a disgusto en nuestro trabajo, por lo que tenemos la obligación de hacer algo. Y si pudieramos decir “es que no se puede hacer nada”, pues vale, me callo.

    El agilismo puede ser una moda si la veis como metodología, pero si os fijáis en los principios veréis que es un cambio de mentalidad. Es algo mucho más profundo que un simple cambio en los procesos. Y justamente el agilismo nos da herramientas como las que comento en este artículo para ayudarnos a combatir la inconsciencia, desconocimiento o lo que sea del resto de nuestros compañeros del sector (me refiero también a los comerciales, a los gerentes, etc, no sólo a los programadores y técnicos en general). ¡Usémoslas (si tenemos el coraje necesario, claro, que es uno de los valores de XP)!