Pages Menu
Categories Menu

Posted by on Mar 26, 2019 in General | 2 comments

Yo no sé cuál es la mejor manera (¿Ágil?) de trabajar

Yo no sé cuál es la mejor manera (¿Ágil?) de trabajar

Mira, aviso, me aviso a mí mismo, este va a ser el post que he escrito con estilo mas viejuno de la historia de este blog, después de escribirlo, y re-leerlo, me reafirmo en que está lleno de frases que me recuerdan a mi abuela, he estado tentado hasta de no publicarlo, pero aquí está y ahí va, para empezar fuerte, la primera…

Ya llevo muchos años en esto y he visto de todo (no todo, pero si mucho y de todo). Toma ya.

Llevo desde el 2000 ayudando a gente a trabajar mejor. Hice más UMLs que un tonto, hice Gantts, mucho diseño OO (hasta una Tesis del tema), especifiqué requisitos, etc., aprendí de todo ello lo malo que tenía hacerlo.

Mi primer contacto con eXtreme Programing (el mítico framework Ágil) fue en 2001.

He trabajado en EEUU, en Chile, en Venezuela, en Colombia y en España.

Debo haber pasado, trabajado en, o para más de, 100 empresas, deben haber asistido a cursos, clases mías, etc., más de 1000 personas (tengo guardados los datos de todos y cada uno de los cursos, charlas y eventos en que he participado) y ello me ha llevado a escuchar multitud de historias y problemáticas.

Y, después de todo eso, sólo te puedo decir una cosa… no sé cuál es la mejor manera de hacer las cosas. Conozco multitud de cosas que han funcionado en un sitio y en otro no y un número aún superior de cosas que tienen, hoy, poca probabilidad de funcionar.

Pero no conozco la mejor, infalible y única manera de hacerlo lo mejor posible. Conozco muchas probables, ninguna segura 100%.

Bueno, concretamente, hasta ahora, si que sólo conozco una manera que sí funciona casi siempre, pero la dejo para el final.

Qué una práctica te funcione depende de miles de variables que hacen que cada caso sea único

No conozco la mejor e infalible mejor manera de hacer las cosas porque hay tanta multitud de variables que hace que lo que funciona en un sitio no lo haga en otro.

Porque que una buena práctica, ágil o lo que sea, funcione depende…

  • Depende de la época, quién sabe qué negocios y tecnologías habrá en 10 años, quizá lo de hoy no sirve en unos años no valga, coge un DeLorean y vete a contarle a un programador de tarjetas perforadas el DevOps, Agilidad, entrega continua, verás como en esos tiempos no se miraba tan mal el Cascada.
  • Depende de lo que rodea a tu equipo, esos clientes, ese negocio que está ahí fuera (no es lo mismo vender apps, que trabajar para agencias gubernamentales, o hacer body shopping, etc.) y que, muchas veces, difícilmente vas a poder cambiar.
  • Depende de tu producto, de su tecnología, del grado de Legacy y Walking Deads que tenga, etc., sólo aquí tenemos combinaciones que prácticamente son infinitas.
  • Depende de tu equipo, depende de su madurez, de sus conocimientos, pero es que hasta…
  • Depende de la edad de tu equipo (edad mental si quieres vale, si no quieres que use edad), pero hay equipos a los que hay empujarlos y otros a los que hay que frenarlos, hay equipos que quieren salir pronto por la tarde, y para ello llegar muy tempranito a trabajar, y hay equipos que quieren llegar tarde aunque tengan que salir más tarde.
  • Depende, incluso, del efecto novedad, las ganas que se le pone a probar algo nuevo muchas veces no son las ganas por mejorar lo de siempre.
  • Depende de haber probado una práctica que ahora dices que no mola pero que te llevó a descubrir la que ahora usas y que parece que mola más.
  • Depende de lo que vamos aprendiendo como comunidad y te va llegando
  • Depende hasta del país, de la cultura, etc.

Por ello creo que toda práctica que recomendamos debería ir acompañada de las palabras «en mi experiencia» y la palabra «probabilidad». Ejemplo, «en mi experiencia el ciclo de vida iterativo e incremental ágil tiene alta probabilidad de funcionar muy bien».

Es un poco absurdo hablar así, pero implícitamente cada vez que digamos, digo, «esta es la mejor manera de hacer x» deberíamos estar entendiendo lo anterior. Por mucho que en el pasado defendiéramos con gran vehemencia tal práctica o la que defendamos ahora.

Recuerda que probablemente Scrum en unos años este cuestionado aunque hoy lo defendamos a muerte.

La única cosa que seguro, hoy, me funciona

He visto gente que le funcionan los Puntos Historia, otros no, a unos les funcionan con tiempo, a otros con complejidad, a unos les funciona Scrum, a otros no, a unos el Testing Unitario, a otros mejor los de integración, a unos Gherkin, otros no, unos Kanban, etc.

E, incluso, lo que hoy parece que funciona mañana quedará como una mala práctica del pasado al descubrir otra mejor.

Pero con tanta variabilidad lo único que he visto que funciona es:

  • Probar, probar y probar.
  • Probando con lo que parece que tiene más probabilidad de funcionar y evitar probar con lo que tiene menos probabilidad de hacerlo

Y para ello, ya que las cosas a probar son infinitas y el número de pruebas es limitado, necesitas conocer el máximo de «herramientas» y el máximo de experiencias ajenas con ellas.

Si conozco 27 destornilladores diferentes, en vez de uno, que además he probado previamente, cuando vea tu tornillo único en el mundo te podré ofrecer las herramientas con más probabilidad de éxito.

Quizá la mejor no está en mi caja de herramientas, pero podré acertar más si tengo 27 que si tengo 2.

De hecho, probar y buscar destornilladores es la esencia de este blog, porque al forzarme a escribir todos los días me fuerzo a reflexionar sobre cosas que han pasado y a descubrir cosas nuevas.

El Lado Oscuro

Dicho lo anterior, el Lado Oscuro está ahí fuera, siempre.

El Lado Oscuro está, entre otros, en que todos, yo también, estamos pre-programados para lo contrario, para buscar que alguien nos diga la verdad absoluta y así no tener que pensar mucho nosotros, ni tener que esforzarnos en probar, probar, cambiar, cambiar.

Estamos pre-programados para buscar tener algo o alguien a quien echar la culpa de nuestros males.

Estamos pre-programados para no ver con buenos ojos el error y probar conlleva equivocarse para mejorar (si somos ágiles deberíamos respetar el error e, incluso, alabarlo).

Estamos pre-programados para buscar zonas de confort permanentemente.

Consejo final…

Por eso a tu Agile Coach, y a vosotros mismos, lo que le tienes que pedir es que conozca muchas herramientas, que tenga muchas experiencias con ellas y que te fuerce constantemente a probar cosas y a cambiar. Que te saque, salir, constantemente de la zona de confort.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

2 Comments

  1. Muy cierto estimado, no creo que haya una receta universal, todo depende de muchas variables para obtener el valor esperado. Muy buen artículo.Gracias por compartir tus conocimientos
    Saludos

  2. Hola Javier, te agradezco este post, a veces me siento muy confundido e incomprendido. Llevo en esto de la ingeniería (de sistemas con software) más de 20 años. He usado y uso cascada, V, scrum, Kanban y casVScramban. No soy ni talibán ni abanderado de ninguna de ellas. Desde mi experiencia, lo único que asegura algo el éxito es tener grandes profesionales, comprometidos con el proyecto, que les guste su trabajo, emocionalmente preparados para encontrarse con bloques de hormigón y mucha, muchísima experiencia para elegir la mejor metodología para cada caso. ¿El casVScramban? pos vale, si funciona.

    Por cierto no utilizo post-its 😉

    un saludo

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This