¿Que es ser ágil y que es ser maduro?

china-contortionist

Hace ya mucho tiempo que desarrolladores, testers, project leader, capacitadores, pensadores, hasta el SEI y en general todos los actores de la industria del software, venimos enfrascándonos en discusiones casi mortales por defender alguno de los extremos de la dicotomía «ágiles vs. maduros» o «ñoño vs. trajes». Estas charlas se suceden todo el tiempo y en todo lugar, en las cafeterías de las empresas, en las oficinas, en las horas de almuerzo, en los blogs, revistas, todo el mundo habla de lo mismo.

Que es ser ágil y que es ser maduro? ¿Puedo ser como el señor de la foto? y si implemento SCRUM soy más ágil o simplemente me habilita a autodenominarme como tal? ¿Una empresa que implementa CMMI level 5, está condenada a tardar 1.000 años en proveer un producto costosísimo a un cliente agotado?

Así planteada la discusión entre dos extremos, uno blanco y el otro negros, casi nadie distingue la infinidad y continuidad de la escala de grises intermedios y se toman posiciones más rápido que en la bolsa de valores, a favor de una u otra fase, según las preferencias de la tribu a la que se pertenece, y es cierto que ningún hobbista (termino utilizado por Bill G. y que refleja como pienso sobre los apasionados del soft) puede alucinarse con CMMI, es casi como ver un adolecente ultraconservador, ni puede a un MBA simpatizarle la idea de una metodología «liviana», con poca o ninguna «evidencia» de «control». Así que existe un perfil de los «ágiles» y los «maduros» que, sin perjuicio de sus justificaciones, parece hacer de sus ideales algo irreconciliable, pero que sin embargo forman las dos caras de una misma moneda porque ambos se centran en los aspectos administrativos que rodean a la escritura de código, a mi entender, el verdadero proceso de convertir capital y trabajo en software de valor para el cliente.

La discusión entre si ser agiles o formales es una de las más estériles en las que he participado por lo siguiente:

  • Sus promesas son marketineras y contradictorias: basta solo con ver los charts que muestran tanto los ágiles como los formales para darse cuenta que los dos prometen lo mismo, mayor productividad/calidad y menores costos/defectos/rework. Es claro, al menos uno está mintiendo.
  • Esto es quizás producto de la ausencia de verdaderos científicos (actuales) del desarrollo de software. Faltan personas que experimenten realmente con desarrolladores, al mejor estilo tayloriano, para determinar a ciencia cierta cuales son las mejores formas de desarrollar. Si hoy existiese un Taylor del software yo no tendría dudas como: ¿como deben distribuirse los escritorios?, ¿donde deben estar los pizarrones?, ¿cuantos mails por hora puede recibir un desarrollador antes de perder totalmente la concentración?, ¿cuantas claves distinta puede manejar?, ¿como lo afectan las políticas de paga/performance?, ¿cuantas tools, tareas, meetings puede manejar simultáneamente?, etc., etc. 
  • La adhesión de una empresa a alguna de estas alternativas se debe más a la tendencia (quien hace más ruido), moda, afinidad cultural con alguna de las corrientes, necesidad de certificarse y cualquier otra, más que por cuestiones de fondo y esto en gran mediada se debe a la falta de credibilidad sobre las promesas realizadas por ambas, en el caso de los agiles porque no presentan números y en el caso de los formales porque los números presentados parecen estar peleados con la realidad.

Por esto es que existen 2 perfiles de empresas que se deciden por lo ingenieril y 2 perfiles que se deciden por lo ágil. En el primer caso estos son, la pyme que quiere (o a la que le exigen) certificarse para quizás exportar y la empresa de trayectoria reconocida que quiere certificarse. Muchas de las pymes han logrado darle la fama a CMMI de certificación comprable y han popularizado los cursos intensivos, de entre treinta minutos y una hora, «Lo que te van a preguntar en el Assessment». Muchas de las compañías reconocidas, en cambio, han sido las que le han dado la fama de lenta, pesada y burocrática aun cuando ellas ya eran compañías lentas, pesadas y burocráticas mucho antes de certificarse. Por el otro lado, los que se deciden por alguna metodología ágil, son pymes desordenadas que pretenden justificar su desorden aduciendo ser agiles y las empresas (o equipos) que desean realmente ordenarse.

Parece cierto que las empresas tienen un «perfil» que muchas veces las condicionan en sus elecciones respecto de la metodología a utilizar, como es claro que existen para ambos bandos, apóstoles y verdades a medias. Pero una verdad que no se lee muy seguido, ya que no se encuentra en ninguno de los dos extremos, es que ni CMMI, ni SCRUM, ni RUP, ni XP son la solución. Y es justamente por lo antes dicho, muchas de las grandes empresas que hoy implementan CMMI ya eran muy burocráticas antes de lograr la certificación y muchas empresas que implementan alguna metodología de las llamadas ágiles ya contaban con una cultura de trabajo dinámica y veloz antes de «ordenarse». Por esto es que cuando se hablamos de la pesadez y lentitud del CMMI, en gran parte estamos hablando en realidad de la lentitud y pesadez de las empresas que lo implementan y no tanto del modelo en si. De igual manera, cuando hablamos de lo ágil que es SCRUM, seguramente nos estamos refiriendo a los atributos de dinámica, practicidad y velocidad en el desarrollo de software que poseen las empresas que lo incorporan a sus prácticas operativas y no tanto de si la manera en que gestiona los requerimientos es o no una maravilla.

Resumiendo, las discusiones sobre las metodologías, no dejan ver, a mí entender, problemas ambientales, administrativos y operativos de los que depende en mayor medida el éxito de los proyectos. Según mi experiencia, lo que más condiciona la productividad del staff, como así también la calidad, el tiempo de entrega y el costo de los productos de trabajo de una consultora de software, es la «CULTURA organizacional». Es como  se acostumbra a pensar y actuar en esa empresa, sus herramientas, el ambiente (hasta la iluminación, ventilación, disposición de los escritorios, edad promedio de la gente, oficinas con música o sin música, con o sin acceso a internet, messenger, carteles en las paredes o sin carteles, de camisa y corbata o de bermudas, con oficinas dispersas por muchos pisos o planas, etc.), sus políticas no escritas con respecto a los proyectos, con respecto a los clientes, con respecto a los compañeros, sus criterios de selección de personal, sus niveles jerárquicos, el nivel de rotación, la estabilidad de los equipos de proyectos, etc.

No son pocas las empresas que implementando a conciencia todas las recomendaciones de los institutos de calidad internacionales, y obteniendo sus certificados correspondientes, fallan en lograr valor real para sus clientes. También es sabido que muchísimas empresas fallan en este objetivo independientemente de haber implementado alguna metodología ágil. En otras palabras, esto no asegura nada.  Solo la experiencia, la experimentación, la intransigencia en nuestra voluntad de mejora y nuestra gente pueden lograr los milagros que muchas empresas necesitan. Cada empresa debe ser o al menos poseer un laboratorio y la masa critica para crear sus propio sistema, refinar su cultura y por qué no importarla (no solo traer un CEO de una empresa que admiramos) y mejorar todo todo el tiempo.

Lucas Ontivero

Sin categoría

12 thoughts on “¿Que es ser ágil y que es ser maduro?

  1. Lucas, me sorprende que no lo veas claro después de tus palabras, tu mismos lo dices, la diferencia está en las personas, punto clave que las metodologías clásicas obvian de manera sistemática. Ese es su pecado, poner el peso en las herramientas y la documentación en lugar de en como interactuan las personas (http://geeks.ms/blogs/rcorral/archive/2007/09/03/personas-o-bits.aspx).

    Hay un tema que marca una diferencia radical, los equipos que hacen metodologías ágiles presenta un grado de satisfación mucho mayor que los equipos que usan metodologías clásicas, no es un dato científico sino un dato basado en mi experiencia. Esto facilita enormemente que no se abandone la metodología, error en que se cae a menudo desde fases tempranas. Y el Taylor de las metodologías que si que existe y se llama Steve McConnell ya lo dijo hace tiempo: «Nada afecta más a la productividad en un proyecto de software que la motivación y satisfación de los desarrolladores».

    Ninguna metodología garantiza nada, desde luego, pero lo que está sobradamente demostrado es que un volumen razonable de metodología, y sobre todo de buenas prácticas, garantiza mejores resultados. Lo único que no sirve es no hacer nada.

    A la hora de implementar una metodología hay una cuestión de economia y de riesgo que es vital. Es mucho más económico y sobre todo gradual implantar una metología ágil que implantar una metodología clásica tipo CMMI o RUP. Las metodologías ágiles se centran en el equipo, sin embargo CMMI afecta a toda la organización. Es un salto en que nos podemos caer de maduros (http://geeks.ms/blogs/rcorral/archive/2006/09/15/_BF00_Nos-podemos-caer-de-maduros_3F00_.aspx).

    Otro de los temas clave es que es mucho más facil encontrar un sponsor (http://geeks.ms/blogs/rcorral/archive/2006/10/09/Implantar-mejoras-en-la-gesti_F300_n-de-tus-desarrollos.aspx) para una metodología ágil (necesitas alguien a nivel de jefe de proyecto) que para implantar CMMI o RUP (necesitas alguien a nivel de CTO o CEO).

    Es posible comerse una ballena a pequeños bocados, pero no es tan ‘facil’ comersela de uno solo.

    Creo que las ventajas de las metodologías ágiles es que parten de principios que son familiares a los desarrolladores que son los más afectados para bien o para mal por la implantación de una metodología (http://geeks.ms/blogs/rcorral/archive/2006/10/20/La-declaraci_F300_n-de-interdependencia.aspx).

  2. Hola Rodrigo, ante todo gracias por comentar tan bien esta entrada.

    Lo que veo, y que tal vez no logre explicar suficientemente bien, es que las discusiones sobre las metodologías son una cuestión de fetichismo, la fascinación que muchos sufren ante las promesa que les hacen las metodologías es muy fuerte y en algunos casos termina cegándolos. Me seria igualmente imposible convencerte a vos de utilizar CMMI como al director de mi empresa convencerlo de utilizar SCRUM.

    La metodología por si sola no determina ni el éxito ni el fracaso de una empresa ni proyecto. Y entiendo muy bien que la gente es la clave, pero la gente va y viene y lo que queda es lo inmaterial, lo cultural, la inercia de una forma de trabajo heredada que ha ido evolucionando y aceitándose con el tiempo. ¿Seria posible que existieran empresas que no utilizaran CMMI, ni RUP, ni SCRUM, ni XP, ni ninguna de las metodologías con «nombre propio»? Claro!. ¿Y tendrían éxito en sus proyectos? algunas si y otras no. Yo viví estas situaciones en empresas a las que les iba bien, muy bien y en otras a las que les iba regular. Una de ellas es Gameloft que es el nro. 1 del mundo en juegos para celulares. Desde el primer día pude ver que la cosa era muy distinta a todo lo que conocía y más allá de las cosas a mejorar, funcionaba muy bien.

    En cuanto a lo de que «los equipos que hacen metodologías ágiles presenta un grado de satisfacción mucho mayor que los equipos que usan metodologías clásicas, no es un dato científico sino un dato basado en mi experiencia.», este es el problema, yo también escribo esto basado en mi experiencia pero todos vemos el mundo desde nuestra ventana y eso crea nuestra versión de la realidad, ¿quien puede darme los resultados de esa estadística? Si esa estadística existiese realmente, este post no hubiese merecido tu comentario.

    Pero me estoy yendo de mi punto porque más allá de comentar lo que es sabido, metodología!= éxito, a lo que quería arribar es que cada empresa es única y que cada una debe estar en condiciones (tener gente capaz) de crear sus propios mecanismos de trabajo e irlos estudiando y mejorando, y que solo con una mentalidad de intransigencia total contra la mediocridad en todas las tareas y a todos los niveles se pueden incrementar las chancees de éxito. Si como un paso importante hacia este objetivo se quiere implementar alguna metodología conocida, bienvenida sea, pero no es necesaria.

  3. Comparto contigo que lo importante son las buenas prácticas por enciman de las metodologías, pero una manera de que las buenas práctica perduren a los cambios que sufren los equipos es usar una metodología. Sino las buenas prácticas desaparencen, se olvidan, bajo presión.

    Decir que mi apreciación sobre la satisfación de los equipo, aunque es subjetiva, es completamente valida. Veo muchos equipos de desarrollo y hablo con muchísimos desarrolladores a lo largo del año. Ojo, ninguna metodología es un bala de plata, ni para todos los entornos aplica la misma metodología. Yo no tengo nada contra CMMI, pero si tengo mucho contra las pésimas implementaciones de CMMI que se ven habitualmente.

    Es más facil equivocarse con CMMI, por su propia naturaleza burocrática y pesada que con Scrum. En metodologías hay que aprovecharse de que poco es mucho. Ha poco bien mejor que mucho mal. Lo que se puede obtener con un poco de metodología es mucho y sin correr el riesgo de aplastar a tu equipo de desarrollo.

  4. lo dicho .. es muy importante elegir adecuadamente la metodología de trabajo, pero es más importante aún utilizarla correctamente !!!

    Saludos y lindo tema para hablar 😀

  5. Comparo las metodologías con los patrones de diseño, al final nos ofrecen una serie de pautas que intentan mejorar el desarrollo, quizás no habría que comparar CMMI, Scrum, XP y otras, al final cada una tiene sus reglas y seguro que todas han sido utilizadas con efectividad en muchas empresas.

    Pienso que muchas veces no es cuestión de elegir la mejor, si no la más adecuada, según el tipo de empresa y negocio en el que nos movemos, cuando comencé a trabajar con Scrum me di cuenta que algunas de las ideas de la metodología las había utilizado durante años, y algunas de ellas como integrar al cliente dentro del proyecto de desarrollo habían logrado el éxito de varios proyectos en los que trabaje, me di cuenta en seguida de que esta metodología era mucho más cercana a mi forma de trabajar y logramos implantarla con facilidad y algo mucho más importante, sin mucha burocracia.

    ¿ Cuántos de nosotros a utilizado un patrón de diseño sin conocerlo ?

    ¿ Por que utilizar una u otra, y no lo mejor cada una ?
    Veo estas discusiones muchas veces con los lenguajes, que si es mejor .net, Java, Delphi,… después de varios años he visto programas en muchos lenguajes, la mayoría un autentico desastre, los menos, mejor desarrollados, pero después de analizarlos te das cuenta que la diferencia está en las personas que los han desarrollado y no en las tecnologías que han utilizado.

    Las metodologías bien aplicadas nos permiten ser más efectivos en nuestro trabajo, y medir como realizamos nuestro trabajo, algo cada vez más importante para cuantificar los costes y valorar aquellos factores en los que dedicamos más tiempo, al igual que los patrones de diseño, las metodologías han sido pensadas y probadas por muchos para ayudar a que el desarrollo de aplicaciones sea más efectivo. Decir cuál es la mejor dependerá de las personas que las manejen y su forma de trabajar.

  6. Juan, completamente de acuerdo con tu punto de vista.
    Solo una cosa, creo que usar CMMI en la mayoría de los casos es como usar asm para hacer programas de gestión.

    Un saludo!!!

  7. Tanto Rodrigo como Juan están diciendo lo mismo, con mucho criterio estan poniendo énfasis en la gente y ven a las metodologías como lo que son en realidad, sistemas de buenas prácticas ya probadas que resumen las experiencias exitosas de otros que ya pasaron por lo mismo, una especie de memoria o conciencia administrativa. Y de seguro que esto es así. Pero yo no creo en eso de que la elección de la metodología se algo importante, más bien veo como muy acertado lo que dice Juan en esas dos preguntas que hace, y especialmente en esa «¿ Cuántos de nosotros a utilizado un patrón de diseño sin conocerlo ?». Ese es el punto, al igual que la comparación con lo lenguaje, la calidad de nuestro prducto no depende del lenguaje en absoluto. Estoy muy de acuerdo, ahora en cuanto a la gente, yo sé que es determinante pero existe un componente cultural muy importante que para mi se llama «intransigencia» en cuanto a hacer las cosas bien siempre a toda costa e irlas mejorando. Sin este «estado mental» trasminado hasta en las paredes de la organización todo falla, hasta la implementación de una metodologia. Por supuesto, existen un millón de factores más pero con esas dos cosas, la elección de una metodología «masiva» no me parece determinante más bien entiendo que cada empresa debe ser capaz de crear su propio esquema de trabajo basado en su s propias convicciones e idiosincracia administrativas y operativas algo con el espíritu de «¿ Por que utilizar una u otra, y no lo mejor cada una ?» pero sin tanta amorfidad alienígena.

  8. Lucas, muy interesante el post y los comentarios.

    Solo me gustaria hacer 2 acotaciones al respecto:
    1) Muchas veces las empresas terminan eligiendo una metodología «madura», como por ejemplo CMM o CMMI, por la necesidad de contar con una acreditacion / certificacion emitida por un ente externo, que permita a un eventual cliente determinar rapidamente la capacidad del proceso de desarrollo utilizado. Es decir, no solo importa lo bueno que uno sea desarrollando software, sino tambien la posibilidad con la que se cuente en cada caso de demostrar que tan bien hacemos las cosas y en ese punto las metodologias formales suelen brindar mecanismos de certificacion ampliamente aceptados.

    A modo de ejemplo, se me ocurre el caso de las certificaciones de calidad utilizadas en otras industrias como las ISO, etc.

    2) Otra cosa, las metodologías maduras generalmente no llegan a un nivel de detalle de las practicas y sub-practicas tal que nos fuerze a realizar las tareas de una determinada forma que pueda ser contraria a nuestras costumbres. Concretamente, nosotros trabajamos en nuestra empresa con un proceso CMM2 Compliance y muchas de las exigencias del modelo están expresadas en terminos de «QUE» y no «COMO». Por ejemplo, en el area de planificacion, se nos exige implementar de forma consistente 2 tecnicas de estimacion, pero no se determina cuales.

    Espero que aporte a la discusion.

    Saludos.-

  9. Pablo, estoy totalmente de acuerdo en los dos puntos. Siempre tengo problemas sacar la idea central de las cosas pero acá voy: No interesa tanto la metodología sino que lo realmente importante es el COMO se hacen esos QUEs que hay que hacer y eso es lo que le da una cierta identidad a la empresa en cuanto a que le da la nota de desempeño.
    A mi me resulta evidente que lo que realmente es ágil es la organización con independencia de la metodologia que utilice.
    Como todo desarrollador he pataleado y lo sigo haciendo cada vez que intentan «formalizar» alguna de mis tareas, pero hasta el dia de hoy no he visto que los QUEs me hayan perjudicado en mi desempeño sino los COMOs, los CON QUE, los EN DONDE, los CUANDOs, etc.
    El otro problema que veo siempre es que es muy dificil discutir desde las experiencias no compartidas. Existen muchas más opiniones basadas en «algo que leí», «lo que opina fulano de tal (que es muy groso)» o «lo que todos piensan».

    Saludos.-

  10. Muy interesante este post y los comentarios realizados. Creo que hay muchas verdades de todo esto y son el alimento de muchas discusiones que, Lucas, creo has dado en los perfiles exactos.

    Yo opino igual que Pablo con respecto a las dos causas que provocan que las empresas terminen eligiendo certificaciones más formales.

    Actualmente creo que lo que nos sucede es que somos muy inmaduros en todo, y por ende no podemos pretender trabajar de forma madura sin cambiar cuestiones de fondo. Tales como:

    1) Generalmente, pretendemos gerenciar la super empresa con el personal de una empresa recontra pequeña.
    2) Las políticas y definiciones de COMO hacer las cosas las tomamos, en mandos gerenciales, sin consultar a los que realmente las hacen (hasta quizás subestimando).
    3) Como es tan pesado, hacer estas definiciones, hacemos una única definición general, y pretendemos gestionar todo tipo de proyecto de la misma manera.
    4) Como no podemos invertir tanto en este tema, usamos herramientas de Oficina para llevar la documentación (lo cual no sirve).
    5) Las mejores prácticas se las dejamos tomar a personal sin experiencia (para MOTIVARLOS: muchas veces así se crean a los monstruos no ?)

    Podríamos seguir enumerando muchas cosas más, pero creo que esta última pregunta, nunca pasa por la cabeza y creo que es la que primera nos deberíamos hacer:

    EL CLIENTE QUIERE PAGAR POR ESTO ?

    En definitiva, yo no creo que ninguna de estas metodologías que venimos hablando defina el éxito o fracazo de una organización, primero creo debemos cambiar el concepto de organización y realmente hacer las cosas acorde a la organización que queremos con los costos que ésta implica.

    Muy interesante el post saludos a todos.

  11. ElIteya, gracias por comentar en mi blog. He leido muy bien (y muchas veces) los punto que enumeras y he podido sacar muchas conclusiones como que estás hablando de los problemas propios de una pequeña empresa y que sus manager (al menos los que administran los dessarrollos) son técnicos convertidos en administradores (por lo del micro-management y la otorgación de libertades para motivar, cosas que no susceden en las grandes) pero lo que no entendí es la pregunta (EL CLIENTE QUIERE PAGAR POR ESTO ?). No obstante, te voy a decir que creo que es lo que el cliente paga: «el cliente paga por software que funciona y resuelve el problema para el que fue solicitado». Ahora, indirectamante paga por todas las tareas que se requieren para cumplir con eso. Muchas veces nos da vueltas por la cabeza esa misma pregunta (exactamente esa, con las mismas palabras) cuando estamos haciendo algo a lo que no le vemos la utilidad o que simplemente no nos gusta pero la respuesta es siempre ‘SI’, el cliente paga por eso, por el tiempo que rrhh se la pasa enviando email, por los zapatos del jefe, por el tiempo que perdemos hablando de java y c# (cafes de por medio), etc.
    No hace falta tornutarse con la idea de que «no estamos haciendole rendir al máximo el dinero al cliente!!». Solo hay que pensar en el costo a largo plazo de lo que le estamos brindando.

    Saludos.

Responder a lontivero Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *