Octubre y noviembre han sido dos meses ajetreados. A los habituales proyectos de formación y consultoría se han unido dos eventos interesantes: El Agile Open Spain 2010 y el Amsterdam Scrum Gathering.
Del Agile OPen Spain 2010 tenéis un par de fotos aquí. Me volví con una sensación agridulce, la verdad. Por una parte, es patente como ha subido el nivel del evento, con mucha más gente dispuesta a aportar experiencia real y con preocupaciones más relacionadas con la implementación y práctica de metodologías Ágiles que con descubrir de qué tratan. Bien por la comunidad Ágil española. Pero por otra se pudo respirar muy evidentemente algo que ya se intuye por los espacios virtuales: se están creando dos corrientes de pensamiento, y una de ellas está de alguna forma enfrentada a la otra.
Concretamente, existe un nucleo duro de “Anarco-sindicalistas del teclado” 
que han creado un espacio extremista en el que “lo único” importante es la programación, el código bonito, TDD, disfrutar programando, la excelencia técnica y las camisetas con chistes en binario. Que no es que no sea importantísimo. Pero no es “LO” importante, en plan “todo lo demás es malignmo y debe ser descartado de la faz de la tierra”. Para ellos, “Scrum es cosa de gerentes” y los procesos son algo a ser destruido junto con la documentación, las herramientas, los contratos y los planes. Es decir, realizan una lectura extrema del manifiesto Ágil y se olvidan de la parte de “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda“.
Son gente que dice cosas como “no se puede programar sin TDD” (aunque productos como Linux o Apache se hayan hecho sin TDD), “no se puede ser Ágil si no haces programación orientada a objeto” (aunque haya gente haciendo Agilidad en Cobol o, ya puestos, en Marketing o en equipos que hacen televisión) o “no se puede hacer Scrum sin técnicas de programación Ágil”. Que no es que “La excelencia técnia no mejore la agilidad”, por citar un principio Ágil, pero en ninguna fuente autorizada sobre el universo Ágil se citan estas técnicas como condición “sine qua non” o “necesaria y suficiente” para ser Ágil.
De hecho el manifiesto cita cuatro valores, ninguno de los cuales se refiere directamente a la ingeniería, y 12 principios, de los cuales solo uno cita una “mejora” de la Agilidad mediante la aplicación de la excelencia técnica.
Insisto: me paso la vida evangelizando sobre cosas como la automatización de tests, la propiedad colectiva de código, los estándares de programación, la integración continua e incluso los repositorios de código y el control de versiones. Creo que en pleno siglo XXI un equipo que busca la mejora continua acabará tarde o temprano enfrentado al estado del arte. Pero si de buenas a primeras te atrincheras en un elitismo taliban y, además, condenas cualquier cosa que huela a proceso u organización, luego no te quejes de lo dificil que es que te dejen ser Ágil en la empresa. Porque para empezar, no has entendido nada.
El problema es que muchas masas oprimidas en las trincheras de la programación se están arremolinando en torno al ideal libertario de los verdes pastos de la comuna digital y se están creyendo cosas como “si el código está bien hecho, lo demás no importa”. Hartos de entornos viciados, compañeros tóxicos y jefes incompetentes, creen que la salida es echarse al monte compilador a cuestas y entonar cánticos de integración continua y refactorización en torno a la hoguera comunitaria del subversion.
Bueno. Tiempo al tiempo. 
El otro grupo (en el que me auto-alineo, claro), discute frecuentemente sobre aspectos culturales de la Agilidad, el comportamiento de las personas, la frontera entre disciplina y auto-organización, los procesos que no se anteponen a los individuos, la mínima documentación que debe existir con cada incremento de código funcionando, negociar y colaborar con el cliente, crear equipos de alto rendimiento, las retrospectivas, los planes de mejora, la adaptación al cambio, el concepto de valor, el diseño emergente, la definición de set mínimo de funcionalidades con valor de mercado, el coaching de equipos, personas, gerentes y clientes, los contratos que reflejan nuestra forma de trabajar, la gestión de proyectos, los sistemas complejos… Y no condenamos las prácticas de ingeniería ($deity nos libre). De hecho las recomendamos. Y sin embargo existe un cierto interés en hacernos aparecer como “el enemigo”. Dejo a criterio del lector el decidir por qué, que bastante me estoy mojando ya con este rant.
He estado también como decía en el Amsterdam Scrum Gathering, del que tenéis varias fotillos aquí. Será porque “Scrum es cosa de gerentes”, pero ni aquí ni en la Lean Kanban Europe pude respirar este mismo clima de “talibanismo técnico” que me pareció respirar en la #aos2010.
Tuve la oportunidad de hacer una lightning-talk o “charla relámpago”, de la que pude grabar este video (la presentación está aquí):
Sustainable Pace: The Boxer, The Aikidoka and the Katana Suburi from Proyectalis on Vimeo.
También pude hacer un Ideacamp sobre Scrumban parecido al que hice en a Agile Open Spain. Gustó tanto que varias personas me pidieron que hiciera un “whitepaper” sobre esta aproximación, pero como eso es muy aburrido en su lugar he hecho esta presentación que espero que pueda ayudar a los que intentan compaginar Scrum con un entorno de alta incertidumbre en el que, en el día a día, siguen surgiendo muchas otras cosas que también deben ser atendidas:
La experiencia del Lean Kanban Europe y la del Scrum Gathering han sido tan buenas que me he decidido a abrir un blog en inglés dedicado específicamente a la Agilidad. Seguiremos informando
Actualización: borraré inmisericordemente cualquier comentario en la línea de “para ti las prácticas de ingeniería no son importantes / son secundarias / son optativas”, ya que no es eso lo que he dicho como cualquier lector con dos dedos de frente podrá interpretar
Hola Ángel,
Muy buen post, aunque me ha costado seguirlo. Un rant considerable, una charla sobre aikido, boxeo, motivación, aprendizaje y disciplina y unas transaparencias de scrumban. Bien para entrenar cambio de contexto mental. La charla sobre scrumban es muuuy interesante.
Sinceramente, yo no conozco quienes son esos dos grupos. No pude ir al AOS ni participo tanto en la comunidad para saberlo. Tampoco sé realmente cuales son, para ti, las fuentes autorizadas para el Universo Ágil. También intuyo a partir de esa afirmación, que habrá muchas fuentes no autorizadas. Personalmente me gusta escuchar opiniones de gente que haya implementado con y sin éxito todo tipo de prácticas ágiles y no ágiles, y en base a esa experiencia ya considero a esas personas autorizadas al menos a opinar sobre esos temas, que no a dogmatizar. Otra cosa serían los que hablen sin ningún tipo de experiencia, ¿no?
Respecto a la excelencia técnica. Mi opinión personal es que es algo fundamental, pero sin entrar nunca en prácticas concretas. Tanto me da si se consigue la excelencia técnica con TDD o sin TDD, con programación en parejas o sin programación en parejas, con tests o … mmm bueno sin tests mejor no, en COBOL o en Java.
Pero creo que estás hablando de software, ¿no? Me es muy complicado realmente el imaginar a una organización que busque realmente el éxito, sin buscar simultáneamente la excelencia técnica. Por más que pienso no se me ocurren ejemplos. Pienso en las grandes compañías internacionales y todas destacan *también* por sus equipos de ingeniería. Ya sean los Microsoft, Oracle, Yahoo, Google, Amazon, o los Netflix, Linkedin, Twitter (ejem), Facebook,… no sé, en serio, no se me ocurren. En todas esas organizaciones podemos encontrar equipos técnicos excelentes, unos muy ágiles y otros no tanto, pero sí que hay un enorme énfasis en la importancia técnica.
Del mismo modo, yo creo que únicamente con la excelencia técnica no es suficiente. Sí se necesitan procesos, y sí se necesita excelencia también en la aplicación esos procesos. Pero repito, mi opinión personal es que la excelencia técnica es algo necesario. Algunos de los mensajes entre líneas que se parecen extraer de tus párrafos (lo siento si lo he malinterpretado, pero yo creo que no llega con ese “recomendar”) serían inimaginables en otros sectores como el de la ingeniería industrial, la fabricación, la construcción, y en general cualquier tipo de ingeniería. No me puedo imaginar a todos esos sectores que a menudo utilizamos como ejemplos sin buscar una excelencia técnica. No me puedo imaginar a Toyota (y quien dice Toyota dice Ferrari o dice Seat) por ejemplo dedicándose simplemente “a recomendar” prácticas de ingeniería. Sí que me los imagino sin embargo buscando las mejores prácticas de ingeniería para ser más eficientes y producir producto de la mayor calidad posible al menor precio. Aunque siempre habrá fábricas como Tata que valoren la producción de volumen al menor coste posible frente a la ingeniería. La cuestión es si ese es el modelo que queremos divulgar.
Un saludo.
PS. Me ha quedado tan largo que igual aprovecho este comentario para un post. Espero que no te importe.
Ángel, me considero parte de los “anarco-sindicalista del teclado” (hasta mola el nombre
) como llamas al grupo preocupado sobretodo por el código y el software bien hecho.
En mi opinión te equivocas en algunas de las cosas que dices, no son como las has puesto, o al menos yo no las veo así. Nadie dice que sin TDD no se pueda hacer buen software (pocos de los que estabamos allí hacen TDD el 100% del tiempo, simplemente algunos decían que era la mejor forma que conocen de hacer buen software) ni mucho menos que sin orientación a objetos sea imposible hacer buen software. Esto último lo discutí hace poco en la lista de correo (que no se si te refieres a ello), y fue una frase que dije que NADIE de los que me respondió se paró a leer. Mi frase fue algo así como “Hacer Scrum sin leerse los principios ágiles es como programar en Java sin conocer orientación a objetos, que lo puedes hacer, pero así saldrá el resultado…”. Por esta frase (no se si son palabras exactas, pero era la idea), me empezaron a contestar que se puede hacer buen software sin orientación a objetos y bla bla bla… Por supuesto que se puede hacer software sin orientación a objetos, y se ha hecho durante años. Por favor no pongamos palabras en bocas que no lo han dicho…
Sobre los procesos. Recuerdo una conversación con Enrique Comba (otro talibán del código), donde decía que lo que hay que hacer es conocer cuantos más procesos mejor y hacer el nuestro. Y estoy completamente de acuerdo, no significa no tener un proceso, pero tiene que ser adaptado a nuestras necesidades. No siempre se puede/quiere hacer Scrum o Kanban o X, dependerá del grupo, de la empresa y del proyecto. Y vuelvo a decir, eso no significa que se esté contra todo proceso.
Sobre grupos, contratos, etc… Te vuelvo a remitir a Enrique, 2 de sus charlas fueron sobre cosas que dicen que no interesan. En la primera (la de Inception) dijo cómo era a relación con sus clientes, como trabajaban juntos, como se conocían, etc… La segunda fue “Y tú cómo les cobras a tus clientes?” dónde explicaba la manera en la que ellos hacen los contratos y cobran.
Y bueno, al final de que trata todo nuestro sector, de hacer software no? Pues habrá que preocuparse del software, de cómo hacerlo bien. No significa olvidarse que se está dentro de una empresa con sus clientes y colaborando con gente, pero creo que el foco hay que ponerlo en el propio software.
No sé que Agile Spain viviste tú, pero yo no ví esa corriente para nada, y creo que tu forma de presentar a las partes es muy sesgada (algo comprensible cuando te posicionas dentro de una de ellas, por otra parte).
Creo que para hablar de un grupo como anarco-sindicalistas del teclado, espacio extremista, lectura extrema del manifiesto ágil, elitismo talibán, condenar cualquier cosa que huela a proceso u organización, hacernos parecer como “el enemigo”, deberías ser mucho más explícito de a quién y a qué cosas te estás refiriendo. No sé si te refieres en ese grupo a la gente que hablaba del Software Craftsmanship y de ser profesional, por alguna de las cosas que mencionas, me gustaría que lo aclarases.
Como dices, es un rant sí, pero no creo que te hayas mojado para nada.
Un par de cuestiones de fondo en relación a este post de Ángel Medinilla y sobre la cuestión de los extremismos.
La verdad es que esto parece un ejemplo claro de lo que algunos llaman “teoría del péndulo” después de muchos tiempo trabajando con principios clásicos “hiperordenados” e “hiperregulados”, eso desencadena un movimiento de reacción que desemboca en planteamientos totalmente contrarios: “desarrollo libre de proceso” y “anarquía”. Está claro que los extremos no son buenos, pero quiero llamar la atención sobre el hecho de que este fenómeno es consecuencia de una excesiva presión en un sentido que genera una respuesta en el sentido totalmente contrario. Se necesitará tiempo para que el péndulo “alcance equilibrio”.
Por otro lado un factor que, en mi opinión agrava las cosas, es que a veces da la sensación que los profesionales de este sector tendemos a pensar de forma “binaria” más allá de nuestro trabajo delante de la computadora
calificándolo todo en extremos: Este tío es Dios, este tío es un #%#%@, esta tecnología mola, esta tecnología es una p… m…. Creo que somos uno de los colectivos profesionales con más tendencia a los extremismos que uno puede encontrar.
Esta bien eso de dividir en dos bandos a la gente y auto-posicionarse en el bando de “los buenos”, sin duda es una visión muy poco parcial del asunto.
También esta muy bien encargarte de poner en boca de otros (entre comillas lo pones) palabras e ideas y definir el pensamiento del grupo “malo” tratando de ridiculizarlo y llevándolo a un extremo absurdo.
Esta bien hacer todas estas cosas y llamar talibanes al resto, tiene narices la cosa.
Algunos consideramos que para “hacer mejor software” que es de lo va el manifiesto ágil, es necesario usar practicas que sirvan para hacer mejor software. Sin duda una posición realmente radical.
Yo tampoco estoy de acuerdo en muchas cosas y paso a rebatir
> Son gente que dice cosas como “no se puede programar sin TDD” (aunque productos como Linux o Apache se hayan hecho sin TDD)
Hombre… y mis padres hacían Asturias-Madrid por la nacional. ¡Pues claro! Pero yo cojo la autopista y ¡tan ricamente oigan! ¿Que tendrá que ver la velocidad con el tocino? Eran otros tiempos. Igual que los sistemas en COBOL. Eran otros tiempos. Que el mantenimiento no arrastre lo nuevo por favor
Es lógico que en ningún momento en el manifiesto ágil se hable de tdd ni de nada por el estilo porque no son el método definitivo. El día de mañana aparecerá otra cosa y habrá que cambiarse. Esa es la idea de la excelencia técnica. El no quedarse nunca estático, siempre ir por donde más rápido se va independientemente de por donde voy más cómodo o por que camino estoy más acostumbrado a ir. Si no me merece la pena aprender cosas nuevas a lo mejor soy yo la pieza que hay que reemplazar y tampoco se va a acabar el mundo.
El caso es el de siempre. Veo normal que exista ese “talibanismo” porque en mi opinión el management tampoco entiende el agilismo pero el que sigue mandando es el management así que ya sabemos la visión que se impone
Claro que se demoniza al manager. En mi opinión en caso de problemas cuanta más resposabilidad tengo más porcentaje de culpa es mío y la situación de ahora, permíteme que te diga es un auténtico desastre si miramos el conjunto del desarrollo del software en España 
Gracias por los comentarios
@martin en lo referente a fuentes autorizadas me refiero a gente como Kent Beck, Martin Fowler, Alistair Cockburn, Jeff Sutherland, Ken Schwabber… No digo que no haya mindundis como yo que tengan cosas interesantes que aportar, pero no se me ocurre dictaminar de forma categórica que “No se puede hacer Agile si no se hace lo que yo hago”. Tampoco he podido encontrar ninguna de estas fuentes “autorizadas” (me empiezo a arrepentir de haber usado el término) que den soporte a esta postura. Por lo demás, estamos esencialmente de acuerdo, puesto que yo soy el primero que intento convencer a todo el mundo de que las prácticas técnicas son importantes y beneficiosas… Pero ¿si no las haces no eres Ágil? Eso es extremismo o, en el mejor de los casos, proselitismo.
@jjballano: “Nadie dice que sin TDD no se pueda hacer buen softwar”. Exáctamente esto me lo han dicho a mi a la cara. Y lo mismoc on las contestaciones sobre que no se puedehacer software si no es orientado aobjetos. A esa gente me refiero, no a Enrique ni a tí (lo siento, porque te molaba el término de Anarco-sindicalista del teclado
)
@alberto me refiero exácta y únicamente a la gente que ha dicho las cosas que menciono (todas las que están entre comillas con literales). Que se mojen ellos y defiendan esta postura, ¿no?
@vellebue totalmente de acuerdo en lo del péndulo y lo de los extremismos (yo mismo puedo ser muy extremista a veces
).
@Alfredo, tal como digo no pongo palabras en boca de nadie. Todo lo que está entre comillas está extraido de conversaciones reales. Si no fuiste tú quien las dijiste, ¡Enhorabuena! Probablemente el post no vaya contigo.
@Rafa estoy de acuerdo en lo importante de evolucionar hacia la excelencia técnia, pero “Veo normal que exista ese “talibanismo”” o “claro que se demoniza al manager” (al manager, a todos los manager??)… Pues en fin.
Triste el hecho de que podamos llegar a ponernos en dos bandos, la verdad. No estuve en el AOS, y no sé si existía esa percepción, ¿quizás no era un “bando” y solo dos o tres personas?
Por otro lado, creo que afrontes como afrontes el agilismo, la parte de gestión y la excelencia técnica son necesarias. Ambas. Así que supongo que estaría más en el lado de Angel, que entiendo que no niega para nada la parte de hacer buen software en su visión más técnica.
Si estás en una organización grande, la parte de gestión, y sobre todo, el enfoque CULTURAL del agilismo probablemente tome mucho más peso al inicio, pues debes cambiar muchas mentalidades. Si por el contrario eres un pequeño equipo, concentrado y todos con la misma idea en la cabeza de agilismo, no te das cuenta y te parece que te centras solo en la parte técnica, pero sin darte cuenta ya te gestionas de una manera determinada -ágil-.
Es absurdo ver esta película sin una de las dos partes. Si la organización no te deja gestionar de manera ágil un proyecto, te centrarás en hacer un sw. de la manera que quieras, pues podrás controlar como lo desarrollas. Pero si de verdad quieres ser ágil, un día querras cambiar la organización y “convertirla”.
Y al reves pasa lo mismo. Con el tiempo te das cuenta que no podrás adaptarte al cambio, si tu software no es lo sufientemente bueno, si no lo tienes controlado y seguro.
Por último, @Rafa, el management no entiende el agilismo por que no lo conoce. Por que mucha gente no quiere que le cambien sus maneras de hacer las cosas, y no se para a estudiarlo. Miedo al cambio, que se suele decir. Pero la reacción no puede ser un talibanismo anti-manager, si no involucrarlos! En algunos sitios, lo vamos consiguiendo
Sin estar en el AOS, yo tengo una sensación parecida a la de Ángel simplemente leyendo la lista de agile-spain.
Cuando me inicié en el mundo ágil, mi percepción iniciar fue que eso era una cosa inventada por los desarrolladores para recuperar su poder y “hacer lo que les dé la gana”.
Creo que aun queda algo de eso… especialmente entre los defensores de “la artesanía del software”.
De nuevo, que nadie se lleve a malentendidos… escribir buen software es importante. Pero no lo es menos escribir el software que el cliente necesita.
Y también entiendo que defender la artesanía no va en contra de defender la gestión. Es sólo que hemos creado tantas vistas parciales (manifiesto ágil, XP, artesanía) que es normal que haya quien sólo vea los árboles, pero no el bosque.
Yo tampoco estuve en el AOS, y tengo la sensación de Angel, que conste que soy 100% desarrollador. Pero esa ola de “sin estas practicas no haces bien la cosas” se está imponiendo en muchos sitios, y no parece correcta. En primer lugar porque en mi opinión TDD no es aplicable a todos los casos (y darme todos los palos que queráis), es lo mismo que la moda de testear absolutamente todo (me he visto en un proyecto donde los tests eran mucho más complejos que el propio código a testear, de hecho había un buen desarrollador dedicado solo a los tests de integración y medio-desarrollador a añadir funcionalidades. Con tanta complejidad, hacemos tests para los tests? porque los tests tenían más bugs que el código) . Por otro lado, los mejores artesanos que conozco no usan TDD y sin embargo su código produce una admiración y envidia tremenda.
He usado TDD desde hace 5 años, de forma intermitente, en este momento no lo hago. La cuestión a la que quiero llegar, es que para mi no es indicador de que seas mejor o peor el que hagas TDD o no, es una practica más, estoy de acuerdo que asociada a esta practica vienen otras muy buenas como desacoplamiento, pero hay muchas gente que las sigue sin TDD de por medio.
@joserra como no podía ser de otra forma, lo has entendido perfectamente. No se trata de negar lo técnico: ambas partes son esenciales. Pero hay gente que hipertofia la importancia de lo técnico y, además, niega la importancia de todo el resto de cuerpo de conocimiento de Agile (“Scrum es un proceso / los procesos son para gerentes / yo no necesito un proceso”). Puede que el bando lo conformen dos o tres personas, pero arremolinan una nube de simpatizantes que se están llevando una idea equivocada de lo que significa el agilismo y, lo que es aun peor, están evangelizando un Agilismo erroneo y descafeinado que nos da una mala prensa.
@Abel, si ya somos por lo menos dos los que tenemos esa impresión… Es que hay que hablar del tema. Creo que hay talibanes entre los partidarios de la artesanía del software, pero también creo que “ni son todos los que están, ni están todos los que son”. El concepto de artesanía del software es muy bueno toda vez que no niegue ni demonice el resto.
@Felix, como suelo citar “una vez es mala suerte, dos coincidencia… Tres es un patrón”.
. Somos muchos los que tenemos esta impresión, y qe conste que tengo a gente mandándome correos electrónicos que no quiere comentar porque no quiere que se les eche encima el “sindicato” 
. Efectivamente, dentro de que creo que técnicas como TDD son buenas técnicas, decir que si no la usas eres un programador del siglo pasado es un poco sesgado. Eso sí: si no usas control de versiones, eres un programador del siglo pasado, que conste… 
@angel jajajaja exacto, el problema es que ya habrá algunos que dirán: si no usas git, eres del siglo pasado. xDDD
Buenas!
Ángel, tienes razón, hay/había/se están creando dos grupos claramente diferenciados por gestión y técnica. A mi parecer una pena tremenda. Nunca me han gustado los extremos y parece ser que no sabemos otra cosa que converger hacía ellos. Obviamente la gente que me conoce sabe en cuál de los dos grupos me sitúo, en el técnico, en el killer del teclado
(no te gusta este más @jjballano?). Pero no porque no valore la parte de gestión o la crea innecesaria sino todo lo contrario pero no es mi skill o mi pérfil o mi interés profesional o como os apetezca decirlo. Cada uno sabe hacer lo que sabe hacer y es bueno en algo, ahí esta la gracia de todo esto ¿no? Esto va de personas que hacen software, personas que se complementan, personas que tienen un mismo objetivo por si a alguien se le olvida y es cubrir una necesidad con un producto (ya sea una necesidad propia o de un cliente). Y, creo que, todos deberíamos remar en el mismo sentido.
¿Los bandos son inevitables? Posiblemente si pero eso no significa que tengan que ser bandos radicales enfrentados. No me gusta la palabra talibán, se ha terminado usando en cualquier ámbito cuando representa algo muy muy concreto y relacionado a personas de una mentalidad muy cerrada. No es término agradable en el cuál me guste verme englobado. No me ha gustado percibir, a partir de tú post, que gente que comparte mi mentalidad seamos talibanes, creo que todo lo exageramos. Seguro que has escuchado palabras como las que dices, yo también, no lo voy a negar. En la combinación de ingredientes esta la receta perfecta o más ideal. Que un Agile Open se acaba dividiendo en dos, gestión y técnico, genial, ¿que hay de malo en ello? Sin TDD se puede hacer software, si, y buen software también. Si te empeñas en hacer un truño de software te va a dar lo mismo uses TDD o la panacea.
Ojalá nos mirásemos más los unos a los otros y no a nuestro propio ombligo, seguro las cosas irían mejor. Desde luego a veces se consigue pinchando con un post o en un hilo de la lista
Un saludo!
El post claro que va conmigo ángel, va conmigo y con muchos que pensamos que las practicas técnicas son las que más ayudan a progresar a un equipo, aunque como dices tu no negamos en absoluto la importancia de las practicas de gestión, simplemente las consideramos subordinadas a las practicas técnicas, tu puedes tener una visión contraria y considerar la técnica subordinada a la gestión, y partiendo de esta premisa podríamos discutir e incluso en algunos puntos estar de acuerdo, pero tu no juegas limpio, has cogido 3 frases sueltas que has oído en el open y las has utilizado para definir, más bien tergiversar, las opiniones de todo un colectivo de gente. Todavía no he visto ningún post de nadie criticando a los “talibanes del post-it” o a “los anarco-sindicalistas del burndown”.
En resumen, me parece un post desafortunado y totalmente fuera de lugar, cosas así son las que no nos hacen falta en esta comunidad si queremos, y espero que sea el objetivo de todos, mejorar la forma en la que desarrollamos software.
@Kinisoftware, tu postura no te alinea con los talibanes. El post describe otra cosa. Toda vez que dices cosas como “Sin TDD se puede hacer software, si, y buen software también” o que si se divide el Open en trakcs técnicos y de gestión no pasa nada, entonces fenomenal, paz brother
. Como decía, el post describe otra cosa.
@Alfredo no creo que escuches a nadie decir “si no tienes post-its y burn-down, no eres Ágil”, “lo que más ayuda a un equipo son los post-its y los burn-downs”, “la automatización de tests queda subordinada a los post-its y los burn-downs” o “no se puede hacer buen software sin burn-downs”. Sin embargo lo contrario sí se da. Eso es lo desafortunado y me da la razón en lo referente a los extremismos. Lo de “fuera de lugar”, como se da la circunstancia de que este lugar es mío, pues que quieres que te diga…
Hola,
Para que nadie piense que Angel es un mentiroso, yo estaba presente cuando alguien dijo la frase de “Sin TDD no se puede ser ágil”…y sí, no hubo manera de que cambiese su forma de ver las cosas.
No hace falta haber acudido a AOS para ver que sí que hay varios puntos de vista, posiciones, bandos, tendencias o como le queráis llamar. Es difícil es una comunidad tan grande no discrepar.
Al mí al menos sí me da la sensación que hay cierto sector que propone que la parte técnica y las buenas prácticas ingenería son lo único que importa y que todo lo que suene a procesos, documentación, empresa, gerente o similar da repelus y no es ágil!
Sí que percibo que del manifiesto ágil cada uno ve lo que quiere ver y hay una parte que se deja de lago…cuando claramente se dice que ámbos lados son importantes.
De todas maneras, como dice Ángel, claro que la ingenería del software es muy importante; yo siempre las recomiendo y las empleo en mis desarrollos, pero una cosa es que considere que es la forma mas óptima de conseguir mi fin y otra es que considere que si voy por otro camino ya no estoy siendo ágil.
Un saludo,
En serio, ¿donde están los que dicen que la parte técnica es lo único que importa?. Porque cualquiera que lea este post pensará que son una manada enfurecida y por aquí no hemos visto ni uno… ni yo mismo que soy lo más parecido a un taliban que ha pasado por aquí mantiene esa posición.
Lo que si decimos muchos es que scrum sin practicas técnicas no sirve de mucho, y para que nadie me diga que no tengo fuentes autorizadas: http://martinfowler.com/bliki/FlaccidScrum.html
El tío bob decía que scrum es una practica del día a día, mientras que XP es una práctica del minuto a minuto. Muchos pensamos que sin cambiar la forma en la que hacemos las cosas minuto a minuto no es posible operar un verdadero cambio, yo al menos no me conformo con menos.
Personalmente he visto varias veces “scrums flacidos” en vivo y en directo, todavía no he visto ningún proyecto fracasar por exceso de celo en las buenas practicas de ingeniería, será por eso que mi visión es que el problema real es justo el contrario al que estáis señalando en este post.
¿Seré un extremista?
Ángel, si hay 2 bandos, en uno en el que estás tú y en otro está el tío que te dijo esas frases en el Open, dónde estamos los demás? Los que nos preocupamos sobretodo por el código pero no pensamos lo mismo que esa/s persona/s que te dijeron eso? Quizás deberías decir que hay 4 grupos, los más preocupados por el código, los más preocupados por la gestión y los talibanes de ambos bandos. Lo que no me parece bien es que nombres a los razonables de un bando y a los talibanes del otro. Pero no, mejor ponemos el extremo de uno y mi respuesta razonable así quien lo lea se alineará mucho más con mi idea, que es la más razonable.
Ah y sí, yo he leído a gente decir que con equipos malos pero con Scrum son ágiles y hacen bien las cosas… Como te digo, talibanes hay en todos los sitios, lo importante es ver si son mayoría o no. Es fácil saber que en este caso (como en el que nombras) son 4 locos que dicen esas estupideces.
@angel @joserra …
Me alegra profundamente cuando leo vuestros post en el que el management son personas comprensivas, en serio. Me hace ver que a lo mejor lo que he vivido hasta ahora no es normal y el “no me compliques la vida” que he sufrido toda mi vida es una excepción. El que las únicas personas que quieren mejorar algo en el proceso de desarrollo son los que están más abajo y aún no están quemados. ¿De verdad no os parecen habituales los piques entre dirección e ingeniería? No sabeis cuanto me alegro de oir esto.
@ibon
Pues yo creo que lo que pasa es que hay mucha gente que ni pincha ni corta en otra parte que no sea ingeniería así que de lo que se preocupan por motivos púramente prácticos es de esa parte. ¿A cuantos de vosotros que seais solamente programadores os dejan meter mano en procesos no ingenieriles? De hecho ¿a cuantos os dejan meter mano en procesos ingenieriles y nunca habéis tenido que hacer alguna guerrilla? Hay que sudar sangre y tener mucha suerte para que algo cambie (aunque sea para mejor, eso da igual). De hecho creo que más de lo segundo que de lo primero.
@kinisoftware
¿Por que hay un problema entre que se dividan entre gestión y área técnica? Supongo que eso pasa porque las empresas son así ;). Si las empresas son así esos bandos son inevitables. Si no los queremos hay que hacer desaparecer esa separación en la empresa lo cual me parece una tarea hercúlea.
—
Conozco a muy poca gente que diga que la documentación no es necesaria si eres ágil. Evidentemente alguno hay pero también conozco a alguno que dice que el Sporting de Gijón tiene equipo para ir a champions. De hecho creo que conozco al mismo número de un grupo que de otro. Personalmente no creo que sea un número significativo para ser representativo de nada
Si alguien dice lo de sin tdd no eres ágil le contestais: nah tio , sin BDD no eres ágil pero mañana sin HDD no eres ágil y pasado sin JDD no eres ágil y después… a lo mejor sin lo que no eres ágil es sin mejora continua. ¡Cuidado! eso no quiere decir que haya que conformarse con el “como también se puede hacer buen software con tarjetas perforadas nos quedamos así” sino todo lo contrario. Ya que ahora haces soft con tarjetas perforadas vete siempre avanzando hacia el siguiente método que vas a ser más productivo a la larga.
El caso es que me parece que se comete mas el segundo error que el primero. Por eso es normal que personas con cierto perfil “excesivamente inquieto” acaben más quemadas y los más “inmovilistas” esten tranquilos. Por eso me parece normal que cierto tipo de gente tenga fricciones con management. No se, es que leyendo ciertos post parece que sea muy fácil hacer que una organización grande de personas funcione a nivel social y a mi me parece imposible. El status quo es sin ágil así que me parece normal que la gente que quiere mejora continua este puteada que quereis que os diga…
Además leyendo vuestros post me parece que es hasta fácil escribir buen software en una servilleta de papel si hacemos Scrum. No se… si os dan a elegir entre TDD y sin tests ¿cuantos elegiríais sin tests?
@Alfredo como te dice Ibon, esa gente existe. Si tu no la ves o no la quieres ver, fenomenal. “Scrum sin prácticas técnicas no sirve de mucho”: Tendríamos que ver qué pasaría si alguien dijera “las prácticas técnicas sin scrum no sirven de mucho”. Y ahí está el extremismo y la parcialidad. Si un equipo de PHP hace sincronizaciones diarias, desarrollo basado en funcionalidades, iteraciones, implica al cliente, hace retrospectivas, visualiza el flujo de trabajo, mantiene autogestión del equipo, reduce el context switching, renuncia a los roles individuales, tienen propiedad colectiva del código… Eso “no sirve de mucho” porque no han automatizado los tests.
@jjballano si quieres finar a cuatro grupos, yo afinaré a 5 y pondré en medio a los que piensan que las prácticas técnicas son TAN importantes como las de gestión, Y me alinearé con ellos.”Talibanes hay en todas partes”… ¿Y por ello no debeo de denunciarlo?
. Si lo que queréis es un artículo por encargo sobre los talibanes del post-it puedo hacerlo, sin duda, pero no vi mucho de esto en el open y sin embargo sí bastante de lo otro, y por ello me ha salido este artículo.
@Rafa no hablo de la “normalidad” de las empresas, entendida como la “norma” o la “media”. Hablo de lo que percibo en la comunidad Ágil española. Por otra parte, la división entre parte técnica y parte de negocio es absolutamente anti-Agil (manifiesto Ágil, cuarto principio). Y lo mismo te podría decir del manido posicionamiento “es que a mi no me dejan hacer nada respecto a la gestión, así que solo me preocupo por la parte técnica”. De verdad que así no vamos a ningún lado. Una de las conclusiones del Agile Open fue “HAZ ALGO”. No me vale lo de “no puedo / no me dejan / no esta en mi mano / no es mi culpa /yo no estaba allí / no me vieron / ha sido Tupporowsky”
. Por último, el universo no es “o TDD, o sin tests”. Eso es extremismo.
@Ángel, creo que lo que te estamos intentando hacer ver algunos, es peligroso hablar de “un grupo” de gente (que realmente habría que ver si es realmente un grupo o son indivíduos), que la mayoría no sabemos quién son y que según dices forman parte del grupo que defendemos la artesanía del software. Es peligroso en el sentido de que es fácil tergiversar el poso que queda tras leer tu post, y que luego la gente traslade el rechazo a estos indivíduos al colectivo, y por eso hay que hacer las críticas de una forma muy clara y responsable, si lo que pretendemos es sumar.
Es lo mismo que te ha comentado Alfredo Casado sobre Scrum (que permíteme decirte que has intentado rebatir con un hombre de paja). Existe gente que entiende mal Scrum (y no representa al colectivo) y hace malas implantaciones en proyectos que fracasan y que no ayudan al crecimiento del movimiento ágil. Y casualmente, mucha de esa gente es la que además se ha quedado únicamente en el proceso de Scrum sin prestar la suficiente atención a las prácticas técnicas a las que algunos tratamos de dar difusión.
Creo que el problema con tu planteamiento es el de que haya dos corrientes, la de los “malos” y la que defiendes tú, “que discute frecuentemente sobre aspectos culturales de la Agilidad, el comportamiento de las personas”… y puede parecer que nos sitúa fuera de ese grupo (y por eliminación dentro del otro) a gente que tratamos de difundir más otras cosas que consideramos esenciales (lo cual no quiere decir que no valoremos o compartamos el resto de cosas, no son corrientes excluyentes). En definitiva, que no sólo son dos corrientes, al menos no las dos que has planteado.
Perdón por repetir en parte lo que ha comentado jjballano, no me aparecía su comentario cuando he escrito el mío. Espero que aclare un poco mi posición (y con suerte la suya).
Primero, no he leído los comentarios. Segundo, no estoy metido en el mundo ágil-scrum-loquesea, y de hecho hasta me ha costado seguir el post
(¿TDD? Habrá que googlear…)
Pero después de leer el post, me quedo con ganas de decir… que no me parece mal que, en cualquier movimiento, haya grupos “extremistas”, “puristas”, “talibanes”… o como queramos llamarlos. Los defensores de cualquier postura “extrema”, hacia cualquiera de los lados, son los que mantienen la “tensión” de las ideas, los que nos hacen reflexionar sobre lo que hay “más allá” de nuestras propias convenciones.
Luego es responsabilidad de cada uno el hacer una síntesis de ideas, analizando todas ellas sin prejuicios e incorporando lo que nos parezca que tienen de sensato. Pero si no existen esos extremos, corremos el riesgo de caer en la autocomplacencia.
No estoy muy puesto en el mundillo ágil en España, pero creo que lo que describes es otra versión más del poner los focos sobre la técnica. Algo a lo que creo que los técnicos, y especialmente programadores/desarrolladores tendemos de forma natural… Después de todo, ¿acaso no somos lo que construimos los programas? ¿No nos hemos dedicado a esto porque nos gusta? Como dice vellebue, tendemos a ser extremistas, y porqué no decirlo, arrogantes a veces.
Sin embargo, a mi modo de ver, creo que la parte más importante de lo que son los principios ágiles (o al menos, como yo los interpreto) tienen mucho más que ver con salir de esa visión “código-céntrica” y los ubergeeks* programando en su cueva e integrar mucho más las diferentes áreas necesarias. Se asume que el propietario del producto no tiene muy claro lo que quiere, de manera que hablamos con él y enseñamos cosas cada poco tiempo creando una conversación en la que ambos aprendemos. Hacemos trabajar en equipo de manera conjunta, para que se comuniquen y se entienda, en vez de ir cada uno a lo suyo.. Intentamos que las cosas no estén grabadas en piedra y que asumamos que nos equivocamos y hay que cambiar cosas… Todos estos puntos son, a mi modo de ver, muy importantes, porque te sacan de picar código como un loco e intentan que hables, que aprendas y que comprendas lo que el resto del equipo (y especialmente en última instancia el “cliente” o el que va usar el resultado) necesita, y después de esto, puedas ser eficiente, implementar mejoras, etc…
Creo que hay que tener claro eso tan bonito de que no hay “silver bullets”, y que el objetivo es solucionar problemas (y de manera eficiente, o no duraremos mucho), no crear código. De nada sirve tener el código más bonito, eficiente y legible del mundo si malinterpretamos el problema del cliente/propietario (algo que es muy fácil). El resto son herramientas para ese fin.
*Dicho con todo el cariño del mundo, posiblemente yo lo sea.
@alberto, he dicho que algunos de estos talibanes se alinean entre las filas de los defensores dela artesanía del software, no que los defensores de la artesanía del software sean unos talibanes, espero que esto quede claro. Por lo demás, puede que existan muchos más grupos, pero los que yo percibí en el Agile Open Spain fueron estos. No encontré colectivos de gente denostando prácticas de ingeniería y proclamando la supremacía de Scrum y los procesos sobre cualquier otra forma de mejora. Así que esta, mi impresión, es la que reflejo en el artículo.
@jaime precioso comentario. No puedo añadirle una coma
Angel me ha encantado tu post. Creo que dices verdades como puños y los propios talibanes se han retratado en sus comentarios. Para ellos mi desprecio. Solamente le hacen daño a la industria, manteniendo la terrible visión del “programador prepotente sabelotodo” que tantísimo mal nos ha echo. Y que no mejoran para nada las cosas realmente importantes de nuestra profesión.
P.D. Yo pico código todos los dias y gestiono a mi equipo. No puedo ser taliban ni aunque lo quisiera.
P.D.D. @jjballano Estás mintiendo. Ni tus palabras fueron esas, como quienes te contestamos no dijimos lo que dices que dijimos.
Hola Angel.
Es el primer comentario que hago en tu blog. Desde hace tiempo ya pude disfrutar de alguno de tus saraos, y la verdad no te he perdido la pista. Aunque no he tenido la posibilidad de asistir a ninguno de los CAS, Open Agile, etc, etc últimamente.
Quería comentarte repasando tu ppt sobre Scrumban un detalle qu creo no le veo muy claro.
Presentas un tablero con dos líneas de actuación una destinada a las historias de usuario del sprint, y otra a las tareas con mayor prioridad y que aparecen ALEATORIAMENTE a lo largo de la ejecución del sprint superior. Hasta ahí todo correcto, me parece genial el triage que describes. Lusgo describes dos burndowns uno el del sprint y otro el de kanban.
Mi pregunta es. ¿Como vas a poder gestionar un burndown de kanban si todavía no sabes a que te vas a enfrentar en el sprint?. Es decir desde que cantidad de puntos de historia, horas, días vas a descender en el burndown.
Se me ocurre utilizar el valor medio en contingencias o tareas urgentes que hayas utilizado en otros sprints pero. ¿De que nos va a servir?
Saludos y gracias.
Buena pregunta y comprensible duda, Carlos. Si te fijas, en el ejemplo de la presentación el equipo se plantea un objetivo de dedicar un máximo de 25 puntos a Kanban – ese sería el objetivo de burn-down. Luego, lo que hacen es que puntuan las tareas Kanban “aleatorias” que aparecen durante el Sprint *después* de terminarlas.
Este 25 puede provenir de la media que hemos medido en otros sprints o del objetivo porcentual que este equipo se plantea como “incertidumbre”.
Por ejemplo, podemos tener un equipo que es capaz de hacer 100 puntos por sprint en media, y se plantea un objetivo de que el 80% de su velocidad se dedique a proyectos planificados y estabilizados, reservando un 20% para bugs, evolutivos, pequeñas tareas, urgencias… Crearían un burn-down de 80 y otro de 20.
Este 20% también puede usarse como un “buffer” o una capacidad de “slack”, es decir, en caso de tener un apuro en el proyecto podemos suspender los evolutivos y el bug-fixing para obtener un extra del 20% (eso sí, estaremos típicamente comprando deuda técnica y luego habrá que pagar los intereses
).
Espero haber resuelto tu duda. Si no es así, aquí estamos
Lo entiendo. Era lo que suponía.
Pero realmente creo que lo que estás planteando es intentar llevar un seguimiento de lo que está fuera del sprint y que en la mayoría (perdón en muchos) de los casos nos arruina el sprint.
Partes de un valor medio de objetivo que se conoce de sprints anteriores y que sobrepasado hace comprometer nuestro sprint. Pero todavía distaría mucho para ser un tablero kanban a la usanza. Planteable igual sólo para equipos de mantenimiento correctivo y no evolutivo.
Para equipos multidisciplinanes en operación: mantenimiento correctivo, preventivo y evolutivo me parece un escenario muy recomendable el que planteas.
Gracias y un saludo.
Hola Angel, por fin encuentro un hueco para comentar, con las ganas que tenía… más vale tarde….
Al respecto del tema que planteas, las (por simplificar) dos visiones del asunto son inevitables, pero también necesarias! No me refiero a los “talibanes”, claro, estoy muy de acuerdo en que no es un término válido para el tema que nos ocupa. Me refiero a la pasión que ponemos en el debate ambas partes (ojo, si, son dos partes, pero creo que más unidas de lo que pudiera parecer). La diversidad favorece al grupo, sólo es necesario entenderse, vaya, no pasar de un conflito de nivel 2…
Desde mi prespectiva de “gestor” y en honor a la verdad, debo reconocer que me llama la atención la buena acogida que tiene mi perfil en los saraos ágiles a los que he podido asistir (este año CAS y AOS). De hecho, parece que se agradecería la presencia de más gestores en los eventos, tanto para evangelizarlos (cierto, a palos, si hiciera falta) como para conocer su visión de la jugada
En concreto en el AOS de Barcelona, una de las cosas que más me ha llegado es La PASIÓN con la que algunos de los representantes de lo que tu llamas “anarco-sindicalismo del teclado” buscan las mejores formas de entregar verdadero VALOR a sus clientes. Software que funciona, responsabilidad, honestidad, etc… Estas expresiones salían contínuamente de la boca de representantes cláramente posicionados.
Tanto es así, que los más avanzados/osados optan por prescindir de ningún nivel intermedio de interlocución con sus cliente, que es el negocio en si, asumiendo la responsabilidad de satisfacer las necesidades de sus clientes directamente. No hay excusas para el fracaso, porque esa es su apuesta para el éxito. Ole, ole y ole por ellos.
A mi juicio la apuesta personal es el germen del verdadero cambio. El verdadero enemigo del agilismo: Una vez más, el MIEDO. El miedo a que la propuesta se vea pervertida, el miedo a que los intereses de unos pocos acaben matando el cambio. Una vez más, miedo al cambio.
El agilismo propone un cambio muy, muy profundo que debe calar en lo más hondo de cada uno de nosotros. Insisto en que es más fácil querer aprender que pretender enseñar. ¿Y cómo podemos inculcar un amor tal por el conocimiento que supere cualquier miedo?… Creo que la respuesta tiene un Nobel esperando. De momento, perseverar con el mensaje…
Si, es cierto que las afirmaciones categóricas (no eres ágil sin XP ¿?) suelen tener poco fundamento, pero… también suelen conseguir pocos seguidores. Ahora bien, si a un equipo, en su contexto, lo que le funciona de verdad para entregar más valor a sus clientes es aplicar TDD…. que lo protejan con su vida si es necesario!!
Por último, también es cierto que no se aplican las mismas “recetas” en una empresa de 6 desarrolladores del más alto nivel técnico, que en un grupo de 200 desarrolladores distribuidos geográficamente y cada cual de su padre y de su madre. Pero es que ahí está la gracia del asunto… Si te dan la receta de las magdalenas de la abuela, sabes de sobra que no te van a quedar igual: Afecta la harina que usas, el horno que tienes, pero sobre todo te falta la mano de la abuela…
Es responsabilidad individual llevar la práctica del agilismo a buen puerto. Hay que ser muy necio para, llegado el fracaso, culpar sólo a las prácticas de ingeniería o al modelo de gestión. Se trata de adaptarse constantemente al cambio, no de esperar a que llegue caido del cielo.
Es cuestión de ser honesto con uno mismo y con los demás a tiempo completo. Si en las empresas esto nos parece muy dificil, es porque nos hace mucha, mucha, mucha falta!
Saludos!
Quizás para argumentar en contra de los talibanes del agilismo puedas usar… el propio agilismo. Si pretenden hacer algo 100% técnicamente excelente… entonces no están yendo paso a paso, incremental e iterativamente hacia su objetivo. Se les podría preguntar cómo pretenden llegar a un entorno ágil (sea como sea que lo entiendan) si no son ellos mismos ágiles (pequeños pasos, siempre corrigiendo el rumbo del barco, hasta llegar al faro ideal).
Lo primero decir que cualquier talibanismo es malo, no creo que haya dos bandos, como bien ha dicho otro compañero hay cuatro o más bandos… y por supuesto no estoy de acuerdo en que nadie pueda decir que sin “x” no hay agilismo..
Tal vez la tensión que sientes se deba a (es una sensación que tengo yo), que en mundo agil lo que más veo es managers y directores de proyecto, no programadores, y por tanto puede surgir alguna tirantez, el programador tiene que estar todo el día picando y viene un tio guay que cobra mucho más que el programador y que flota sobre las nubes y le dice como tiene que hacer las cosas… (por favor no lo entendaís mal, es una metáfora y una exageración de la realidad…), tal vez el programador se sienta un poco jodido…. y por tanto te sale con el rollo de tdd y todo eso..
Yo no me siento mal con los scrum managers, pero echo de menos más programadores en las listas de agilismo…
Yo creo que el agilismo se puede aplicar en todos los niveles y que no dependen de técnicas sino que es más bien una forma de pensar en la que hay que usar unas herramientas (kanban, tdd, etc…)
Por cierto, he visto la presentación del boxer y estoy de acuerdo, aunque yo concretamente practico la eskrima (desde hace poco), a ver si hacemos una exhibición y te vienes…
Ahí va! Redios xD Tribe stage 4 my friend
Pingback: El paso sostenible | Alta Cuncta