Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Working as an independent professional since 2009.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Is it risky? do you need advise?
  • May I pair with you to write better code?


Upcoming public training courses:

  1. [in English] May 5, 6 & 7
    TDD - Train the Trainers (iSQI)
    Potsdam, Berlin
  2. [en Español] 23, 24 y 25 de Abril.
    Curso de TDD con examen de certificacion iSQI
  3. [en Español] 29, 30 y 31 de Octubre.
    Curso de TDD con examen de certificacion iSQI


  1. I'll be at SocratesUK 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for the ‘Retrospectivas’ Category

A week to remember in Barcelona

Last week was awesome, I went to Barcelona to run two training courses. Well, one of them was my yearly session at the Postgraduate on Agile Methods at La Salle (Universitat Ramon Llull). The first postgraduate in the world on Agile Methods. I explain eXtreme Programming, together with my good friend Rubern Bernardez,  during 6 days (3 weekends).

PMA 2013/2014

PMA 2013/2014


This has been my third year at the PMA and it's been really nice. The selection process for participants went very well thanks to Xavier Albaladejo and so the group was excellent. People have made an endeavor to understand the XP practices and the values behind. Even project managers, people that have been away from code for years, were test-driving the exercises in pairs.  The fact that decision makers come to the class and get to appreciate the benefits of clean code and XP is very important in my opinion.  Because they can encourage and tell developers later. In the group there were testers and developers too. The different mindsets together were very interesting when facing code. Enriching experience for everybody. Thank you all for this great PMA edition. Special thanks to Xavi and to Quim Ibañez for his kindness and support.


During the week, I gave one of my TDD training courses, this time open to the public. In general, public courses are more energizing than in-house, because people are willing to learn and participate. They have to pay for their ticket or ask their companies and that makes a difference. This time I got to know several members from the Barcelona Software Craftsmanship Community. The level in the training was very high, in fact, it was more an exchange than a teaching session. There were many interesting discussions and retrospectives whilst looking at the code in the projector.  It's been also very nice to meet old friends and observe how they have progressed over the last couple of years. Specially Manuel Rivero who has made an outstanding progress in his career and now let me learn from him.


TDD Training in Barcelona

TDD Training in Barcelona (open to the public)

This experience reminds me my first open course in Madrid in 2010, when I got to know people that are now good friends and that today, run their own training courses on TDD and clean code or lead teams. So I believe that we have started here a wonderful relationship and that we will cross roads soon again. There was magic in the air.

I have to say thank you to my good friend Javier Gomez for all the support and the hosting,  as the event happened in Ricoh Spain. In this kind of courses I get to know great programmers that usually end up being colleagues or collaborators at some point ;-)

Coding dojo - Barcelona Software Craftsmanship

Coding dojo - Barcelona Software Craftsmanship


Thank you very much also to all the folks that came to the coding dojo that we had on Monday evening, hosted by Barcelona Software Craftsmanship, thanks to Manuel Rivero, Beatriz Martin and Jaume Jornet. In my opinion the community is very healthy in Barcelona, congratulations.

My experience at the IronHack


I am one of the lecturers/mentors of the first IronHack edition, a training program for people who want to become professional developers. My part takes only three days and it's been this week. Three full-day hands-on sessions on JavaScript, TDD and testing techniques. The experience has been fantastic for me.


During the class at IronHack

When I knew about this idea of training people with any background so that they become developers in only 8 weeks, I thought... shit man, how the hell are people going to learn and assimilate all the contents and concepts in such a short period of time? That's impossible! But I was invited as a mentor by Mauricio Morales and his energizing message made think that I wanted to know how this accelerated training academies works. So I accepted the invite to experience something new, to experiment and learn. And it's been totally worth joining the teachers team :-)

The best thing it's been getting to know the people. IronHack staff are great guys and the participants/students are brilliant. They are doing their best to understand all these new techniques and tools despite of their different backgrounds. People that progress faster take their time to pair up with the people that are struggling, helping them speed up the pace and learn. The people with less programming background are very patient and motivated. Well, all of them are very motivated, this is what is exciting in there.

For me it's been a challenge because I am used to train developers but not beginners. Some of the folks were developers but some of them were pretty new to software development.  And difficulties is what make me learn the most, so I've learnt important lessons that will help me out in the near future. Anyway I am quite satisfied with my work and specially with their effort.

Now, as you may imagine, this training does not entitle all the students to consider themselves senior software developers right after the end of it, it's just too short! But I don't think that is the objective. They are learning from passionate professionals that work every day in "the real world". One or two different guys like me every week. They are getting to know the best techniques we know, how we think and work so that they are learning from our mistakes. What has taken years for some of us is summarized in hours during the training. Internalizing them is going to take sometime to students but it's still faster than some traditional training methods.

I believe this concept is good even if it only serves to add some pressure on other training methods. We need better developers and providing different training alternatives sounds right to me.

If in the future I meet a single person from this fantastic group and she tells me that what we practiced in the class was  useful in her career, then my objective will be accomplished. If they write code with care from now, I'll be totally satisfied. Code for other human beings, not for machines which is what some people believe after other training programs.

I want to say  THANK YOU to the guys behind IronHach: Ariel Quinones, Gonzalo Manrique, Israel Guitierrez, Xavi Leal, Mauricio Morales and company.

And of course THANK YOU to the intrepid participants: Sergio Revilla, Daniel Bardaji, Daniel Castillo, Agustin de la Villa, Alejandro Dominguez, Daniel Cusan, Marta Fonda, Fernando Moreno, Ruben Kanna, Imanol Yañez y Jaime Muñoz.



2013-11-27 17.58.59

Tuenti office with my friends: Miguel Angel Garcia, Joaquin Engelmo, David Santiago, Imanol Yañez and Marta Fonda

And I visited Tuenti for my first time, finally!

Yesterday was a very intense day because right after the full-day session at the IronHack, I went to Tuenti offices (Madrid) to give a talk to software engineers.  Last week my good friend Kini and Jose Lorenzo sent my an email inviting me to do so. I didn't prepare slides because I didn't feel like giving another talk with slides I felt more like having a discussion. I just prepared a few ideas based on my experience and my point of view to start up the discussion. It was along the lines of professionalism, XP and specially practices like TDD and BDD. Fortunately people were participating in the discussion with a lot of interest. I am not very good at counting but I guess there were more than 50 people. Tuenti gathers some of the most talented developers in the country, not only Spanish developer but also from other countries.  It's a very nice place, looks  very cool as a place to work. I've been listening how good people are in Tuenti for a long time so I am glad I got to know people in person that I only knew from twitter and really enjoyed sharing experiences with them. I hope to meet this group more times in the future.

Case study: Audience Response

Wow, AgileTestingDays 2013 it's being awesome! I gave my talk today, a practical "live coding" session. Last week I created a real-time application to communicate with the audience so that when I am speaking they can tell me if they are understanding or if they want me to repeat ...
So we started off using this app on my session. Interestingly enough the session was about building the tool again. From Cucumber specifications, all the way down to the GUI and the hub (server).

You can find the actual code of the application here and more importantly, the process I followed to write it, because I checked-in the code on every green test so by looking at the diffs, you'll figure out how code evolved.
Unfortunately the wifi didn't work well so I couldn't really take advantage of the app. Next time I'll bring my own wireless router to create our private LAN.

In order to prepare the session, I rewrote part of the app again myself. In here you can find this second iteration, again with a test committed at a time. By looking at the commits you can follow part of what I did during my session. You can take the code and practice yourself from this particular commit, comparing your moves with mine ones to see what we can learn.

Find the business specifications of the app here and the step definitions (glue) in here.

Now, the session didn't go bad, but it didn't go as well as I'd like. I did quite bad with the timing.I would have needed 90 minutes rather than 45 to illustrate the process properly. When I was preparing the talk, I wrote the code on my own and it didn't take much time, but presenting it's a different story, I've learned that I need about twice as much time.

2013-10-31 01.24.06But I am satisfied because several people understood the process and got value from it. Next time I run this session, it will go much better. And you know what? I've been approved by The Code Cop! Look at this picture.


I'll be happy if you were attending the talk and can give me some feedback in the form of a comment in this blog. As a reward, one person out of the people commenting will be randomly selected and I will run a free 90 minutes session for her/his company (remotely, videoconferencing), doing this same exercise properly with Q&A session.

James Lyndsay and Bart Knaack from The Test Lab have used an instance of the app for testing purposes and people have found several defects. I am happy for that because I didn't do any exploratory testing or even took care of network failures or latency problems. Thanks for that guys!

This exercise will be part of my upcoming book on Agile JavaScript for Rich Internet Applications. I expect to have the book done in 2014.

If you want to have a look at the sample deployed app on Heroku, use these urls:
Load a page in the browser with this url (as a speaker).
Then load the page as the audience in other window.
Then just interact.

Thank you very much for all your support, I really appreciated you invested your time on my talk. If are there questions please let me know of find me tomorrow in the conference to catch up or hang out :-)

A week in the UK

Talking at SkillsMatter

Last week was very intense indeed. I gave my first talk at Skills Matter (video here).

BDD for RIAs with JavaScript - Skills Matter from Carlos Ble

I must say I am not content with my talk because my English was rubbish but on the other hand I am glad that it provided value to some attendees. That is why I did it. I am also glad because it gave me the opportunity to meet very nice people (we were having some chats before the talk, and afterwards in the pub). And I will do better the next time :-) I have learned several lessons.

First one, I will not give talks right after landing a plane. The fact that I could arrive late if the flight or the train was late, made me very nervous, I went running to the venue and it doesn't help to concentrate. I must fly the day before.

Second one, when I talk in English, I must have pretty much everything I want to say written in cards so that if I can't find the words, I can just read. My English is not too bad when I am relaxed but under pressure, it's much harder to find the words and pronounce. When giving a talk, I pay close attention to attendees, timing and the way I am expressing myself. All these concerns difficult my capacity to talk in English.
I'll be talking advanced English lessons with natives, aiming to get fluent some day. But in the meanwhile I must have the written speech as a backup.
When my friend Ivan Stepaniuk and I gave a talk in the Agile Testing Days last year, everything was written and it went better. Also the fact that we were two guys made it easier.

Third one, audience's feedback is different depending on the culture. When I talk in Spain I can clearly read faces and see if they follow me or not. But this time it was really hard for me to now if they were following me. I must not loose concentration regardless of my difficulties interpreting audience's feedback, but just keep going unless they actively ask.

Fourth, talking with braces is f***g annoying! :-)

If I keep practicing and taking lessons, with the help of a trainer I'll become better.

Participating in the SocratesUK open space

The following days I participated in the #socratesuk open space, organized by the London Software Craftsmanship Community.
2013-09-21 18.31.10

A great event in the countryside, an incredible venue.

It started with lightning talks and a fish bowl. The next two days there were talks, discussions and time for pairing with people. Pairing was the part I enjoyed the most. After dinner people used to meet in the bar to talk, drink and pair.
The last day we spent the morning hiking together along the countryside in a beautiful sunny day.

2013-09-19 16.23.52

Rachel Davies did an excellent job facilitating the whole event. And people were friendly and willing to share and learn

Having everything in the same place was very handy to meet different people. And the food was good. I've learned, shared, and met very nice people. It's been totally worth participating.

Thank you very much to the organizers and all the participants.
2013-09-22 10.26.53

I'd like to participate in Socrates Germany next year as well as Socrates UK.

Several people said we must organize Socrates Canarias. What do you think? shall we? :-)

See more pictures here





¿Agile Spain o España Agil?

No puedo decir que esté contento con cómo lo he hecho en la organización de AOS2013 y no me gustaria que este post fuese punto de discusión sobre lo ocurrido en AOS. Para eso esta la lista de correo. Roberto Canales ha escrito también un extenso post sobre su experiencia y he comentado en él.
La organización sabemos que el efecto sorpresa con el idioma no estuvo bien y que fallamos en la comunicación. Tambien sabemos que Yeray y yo no habiamos preparado bien el discurso de apertura y que los nervios nos jugaron una mala pasada. Ya le he pedido disculpas a Yeray. Solo puedo disculparme por la parte que me toca.
En lo positivo de esta primera experiencia internacional, queda que eBay se ha interesado por varios desarrolladores canarios, y que al menos uno, ya está iniciando el proceso de entrevistas. De hecho Ben, el jefe de desarrollo me contó que estaba impresionado con la calidad de la gente aquí. No sabía que hacíamos estas cosas. Ni siquiera Sergio, su compañero español que emigró ya hace unos años a Londres.

Ahora quería compartir con los lectores de mi blog ideas que llevo pensando hace ya tiempo.
¿Está evolucionando la comunidad Agile Spain? ¿Hacia donde debe ir? ¿Estamos mejorando continuamente?

En los ultimos meses estoy viajando por Europa conociendo mucha gente interesante en conferencias y con la suerte de estar haciendo clientes fuera. Y estoy encantado por esta suerte, por las ayudas que estoy recibiendo. Estoy aprendiendo y tambien aportando, compartiendo.
Y me he dado cuenta que en practicamente toda Europa, los eventos de IT, se hacen con el inglés como idioma oficial, porque asi puede participar mas gente. Algunos lo hablan
mejor, otros peor, pero nos entendemos aunque sea a veces con gestos y generalmente la gente es muy tolerante y respetuosa cuando ven que uno está haciendo el esfuerzo de comunicarse.
En parte ha sido por obligación porque en España la cosa ya no me va tan bien como antes. Los clientes están dejando de apostar por la calidad (que es una de las cosas que la agilidad aporta), estan tirando los precios y contratando menos.

Creo que en España no le estamos dando la oportunidad a los demas profesionales del habla no hispana, a que vengan y nos cuenten lo que saben. Ni tampoco tenemos nosotros la oportunidad de contarles lo que sabemos.
Estoy viendo que mucha gente interesante y que nos puede aportar cosas, se está marchando del país (no diré nombres pero hay unos cuantos que conozco de primera mano), se nos está fugando el conocimiento. Y es bueno para ellos pero es malo para los que se quedan.
Estamos perdiendo oportunidad de crecer y mejorar.

Paises emergentes como Polonia, donde los desarrolladores tienen buena formación, se están abriendo a hablar inglés y están consiguiendo que empresas interesantes de países con fuerte desarrollo tecnológico les conozcan. Y esto no solo se traduce en puestos de trabajo interesantes sino que tambien es el inicio del cambio cultural. Que las empresas extranjeras se instalen allí hace que las empresas locales tengan que empezar a plantearse si su cultura laboral es adecuada. Es al menos un punto de reflexión para empleadores y empleados locales.

Creo que muchos queremos que la relación entre empleadores y empleados sea mas sana en España. Me parece que ahora está un poco pervertida en algunos entornos. Pero no tenemos ejemplos cercanos de otras formas de trabajar. Si no ves otros ejemplos, es dificil aprenderlos y cambiar. ¿Qué pasaría si nos abriesemos al mundo?

Que todo el mundo hable inglés en este país, es totalmente imposible. Ni siquiera se si sería bueno. Pero que las personas que trabajamos en software, en IT, no podamos comunicarnos en inglés, nos pone en desventaja. Todos los libros técnicos se escriben en inglés. No recuerdo que ningun castellano parlante haya inventando ninguna nueva técnica de desarrollo. Siempre lo importamos. Vale que luego lo aprendemos y puede que lo mejoremos, pero la tendencia la va marcando el mundo de habla inglesa. Entonces si no puedes con el enemigo, únete a él, ¿no? De hecho cuando le vas conociendo ves que no es el enemigo, que quieren que seamos amigos :-)

No debe ocurrir que por querer abrirnos, deje de entrar gente nueva del país a los métodos ágiles. Es decir, no cerrar puerta a quien definitivamente tiene problemas con el inglés. Y no dejar de hacer divulgación en castellano. Pero al mismo tiempo abrir las puertas a los de fuera.
Creo que ahora mismo no tenemos ninguna puerta abierta para ellos. Conocen del buen hacer de los españoles que han emigrado. Y muchos de esos no van a volver. Y cuando vuelvan, muchos querran que nos abramos para traer lo que conocen que es bueno ahí fuera.

Creo que es una oportunidad para que encontremos más y mejores ofertas de empleo. Para mezclarnos más y no llegar a ser endogámicos. Y el momento es ahora, que vivimos una crisis de valores y económica, una etapa de transición que nuestra generación no había visto antes.

Yo sigo el trabajo de ir dándome a conocer fuera y buscando colaboraciones con gente de otros países. Para aprender más, para compartir más. Buscando la manera de asistir a formaciones con los autores de los libros que leo. Y tengo ganas de ayudar a cualquiera que esté en esa línea. Estoy contento porque ya he podido aportar mi granito de arena y alguno de mis amigos ha encontrado fuera un trabajo que le ilusiona mucho. Que piensa que le trae crecimiento personal y profesional. Por supuesto mérito suyo pero estoy contento de haber podido poner en contacto a gente.

La comunidad española me ha aportado muchísimo en los años anteriores y siento que debo aportar yo tambien todo lo que pueda. Ahora mismo me da la sensación de que está estancada. Nos preguntamos por qué la gente que lleva tiempo ya no va al AOS ni a la CAS. Y a algunos ya casi no se les ve el pelo por España. Afortunadamente aparece gente nueva y con ganas, pero desaparecen algunos de los que nos pueden enseñar mucho. Y como he dicho, dejan de venir otros que no saben hablar español.
Me gustaría echar una mano a que demos el siguiente paso. Y para mí el siguiente paso es abrirnos al mundo.

Mi propuesta:

- AOS y CAS totalmente internacionales. Durante al menos unos primeros X años de transición, que haya tracks en español para que quien no quiera o pueda hablar en inglés se pueda expresar. Es más, que haya tracks en Euskera si se hace en Euskadi como la próxima CAS. Es la lengua materna de muchos posibles asistentes. Para que seamos totalmente tolerantes y no le cerremos la puerta a nadie. Pero que el evento sea totalmente internacional.

- Que siga habiendo eventos en español en todas las comunidades locales para hacer divulgación y que no deje de venir gente nueva. Tenemos coding dojos, coaching dojos, charlas, etc... y esta muy bien que sean en español.

¿Qué significa hacer el evento internacional? Que el resto del mundo se crea que de verdad es internacional. Y que les apetezca venir. El twitter oficial debe publicar siempre en inglés. Adicionalmente se puede crear otra cuenta de twitter en español pero yo descartaría esa opción. La web debe estar totalmente en inglés. Buena parte de la organización del evento se tiene que defender con el inglés hablado para atender a los que vengan.
La entrada del evento (CAS) tiene que tener un precio suficiente como para poder pagar los gastos de viaje, al menos a europeos. En el caso del AOS es gratis (pensamos que deberia cobrarse simbolicamente algo como 20 euros para evitar los problemas de plazas que hemos tenido).

Esto significa que la entrada seguramente sería más cara que en la actualidad. Y hay muchas formas de interpretarlo. A mi me gusta verlo como que aún así, me sale mucho mas barato ver a speakers internacionales aquí, que ir a verlos a Londres, pagandome viaje, estancia y un precio de entrada mucho más caro.

Mi forma subjetiva de verlo es que esto es abrir puertas nuevas, sin cerrar otras.

Yo me ofrezco a esforzarme por traer sponsors y speakers de otros países y a ayudar en la organización con mi inglés de andar por casa. Suficiente para entenderme con la gente. Y espero que cada día mejor.

Jorge Uriarte me comentaba que la CAS de este año es internacional porque traen varios keynote speakers de fuera y se permiten charlas en ingles. Pero las comunicaciones (twitter) se están haciendo en español y la web está en español (aunque también está inglés). Los eventos internacionales no tienen la web en varios idiomas.
Porque el espíritu no es que se forme el grupo de los extranjeros por un lado y el grupo de los españoles por otro, y que no interactúen. El espíritu es que el idioma oficial del evento sea inglés.
Dar entender a la comunidad internacional que les vamos a tratar bien, que se van a sentir igual que en Bélgica, Alemania, Holanda, etc...
Digamos que los tracks en español y en otros idiomas regionales deberían gestionarse de otra manera. O tal vez cómo hace la comunidad Gnome a veces, que tienen el evento español un dia antes o despues y luego el evento internacional. Es decir, que no se quite la oportunidad pero que desde fuera no quede sensación de que hacemos dos grupos. Más que nada porque fuera hay muchos eventos con los que competir y para que vengan, los que hagamos aquí tienen que resultar realmente atractivos.
De hecho será bastante dificil hacerla atractiva para los de fuera, es todo un reto.

No será fácil ir en esta dirección, no será sin críticas, pero hay mucho que ganar y pienso que, poco que perder. Siempre y cuando las comunidades locales sigan haciendo trabajo de divulgación.

Después de llevar años en difernetes comunidades, desde los grupos de usuarios de Linux, pasando tímidamente por Gnome y Mono hasta la comunidad ágil, se que este tipo de opiniones crean polémica pero mi intención no es seguirla ni dedicar mi energía a ello. Es ayudar en lo que creo que nos toca hacer ahora.

Bueno, ya he parido este pedazo de post. A por unas birras ahora. Gracias por leer :-) Comentarios educados son siempre bienvenidos.


The best coding dojo ever


I've got goosebumps on my arms most of the day. And it doesn't happen very often. This is the most emotional coding dojo I've ever facilitated. It's been in Gran Canaria, at the Universidad de Las Palmas de Gran Canaria (EII ULPGC).

The last day in college for some students, where many of them were thinking of their uncertain near future. Asking for recommendations and expressing many doubts.

More than 50 people coding together for more than 8 hours, in an incredible atmosphere.



How did we get here?

There is only one book on TDD in Spanish so far. Published by my friends and me back in 2010, under the creative commons license. Creative commons is like a virus for this. One year ago a real master, Jose Juan Hernandez (@jjhernandez) decided the book was nice to teach his students how to write clean code. We didn't know each other. In fact I didn't know the book was being used at the University. Jose Juan has been coding since 1985 and I do believe he is a software craftsman, now that I've seen him coding and teaching.
A couple of months ago he contacted me  see if I could give a talk to his students, about TDD in the real world™ and the encounter was excellent. The coding dojo proposal came along right after that.

Why has it been so good?

Guillermo and I

Several factors in here. Jose Juan has been teaching TDD, Refactoring, Patterns and Clean Code to his students the whole year. No only the practices but the values. This is the reason we believe he is a master, because his students have embraced and internalized his values and principles.

  1. So about 30% of the students were familiar with the techniques, and we asked them to pair up with those not exposed to automated tests and example driven design before. And they explained everything to others with passion. 
  2. In a regular coding dojo the facilitator does not necessarily teach. Her goal is facilitating. In this case though, we've been teaching people, so it's been half of a training session. With direct feedback on their work, based on our experience.
  3. We were 3 guys facilitating: Guillermo Pascual (@pasku1), Jose Juan and me. And the sinergy it's been huge.
  4. Everyone was absolutely willing to learn and share. Passionate people, warm and friendly.
  5. It's been a total win-win event. We (facilitators) have felt very useful and appreciated, it's been fulfilling. Some people have discovered a new way of understanding their careers, and what "caring about code" means.
  6. The retrospectives following every iteration were very participative, people were able to discuss among them.

Jose Juan

What's next?

  • This is a milestone in the Canary Islands software development community, I can feel it. Something is changing...
  • Let's keep on practising together. The AgileCanarias community is growing and it's a good starting point  o meet new people and learn new stuff. The Tenerife group is kind of mature and stable now, let's do the same in Gran Canaria. And let's join the two groups for dojos and local conferences.
  • We have the Agile Open Space this year in Tenerife. Join us, it's a great opportunity to discover more.
  • Now you know there are different ways of writing software. Keep on learning, it's a never ending path.
  • When is the next coding dojo, who will organize and facilitate it? :-)

I want to facilitate a dojo, what should I know?

  • Manage people's expectations. In general a coding dojo is not a training session. Be honest with participants and help beginners as much as you can. Otherwise they'll be scared, run away and take a wrong idea about what it is.
  • A dojo is a space for innovation, try different things all the time, you don't have to follow the manual on the go. Just use your imagination and empathy.
  • Ask someone experienced to facilitate it before doing it yourself, if possible.
  • There is an interesting new book on this by Emily Bache (haven't read it yet), foreword by Uncle Bob Martin.
  • Check out this video by Emily Bache:


  • Jose Juan and Guillermo Pascual.
  • All the participants, of course. Without them, there is nothing to do.
  • Jorge Castellano for his pictures and video. Pictures will be uploaded soon here. Jorge already uploaded some pictures to twitter. Just search for the hashtag #dojoULPGC
  • Fran Santanta for his support and organization. Fran brought journalists from local newspapers and TV, apart from the food and everything else.
  • Mario Hernandez Tejera for his company, hospitality and sharing his interesting/wise thoughts.
  • All the colleagues who work with Jose Juan for his support and energy.
  • JM Beas, Xavi Gost and other folks from Agile Spain, as they introduced me to coding dojos.

This is the related thread in the AgileCanarias mailing list.

fotos de Jorge Castellano
Guillermo Pascual y Carlos Ble



Wow! Agile Dev Practices 2013

So exhausted after the conference

Oh man, what a conference, I am just destroyed as you can see.

AgileDevPractices 2013 has been the first edition of an excellent conference. It was a big surprise for me when Jose Díaz from Diaz & Hilterscheid asked me to select the talks from the many proposals received. I was also responsible for the major part of the program. I didn't choose the keynotes and some other talks. Fortunately the conference has been very successful in my opinion, given that it's the first edition.  I have learned a lot and most importantly, I've met incredible people.

I landed in Berlin on Sunday to have dinner with my good friend Vicenç García-Altés, enjoy Potsdam's beer (Potsdamer Stange) and get ready for my workshop on Monday. The workshop went very good thanks to the energy and effort of the attendees.

Improvised theater

The speaker's dinner on Monday was very nice. It was close to the hotel so we saved a lot of time that was used for hanging out. I remember very interesting and fun conversations with many speakers. Back in the hotel's bar conversations kept going till midnight.

Thanks Kishen and Ellen for the pictures!

The dinner on Tuesday was very special too. Two awesome actors performed theater in front of us improvising the scenes based on notes written by us (the audience). I was specially lucky because they asked me to participate on a particular part. I had to move my arms and hands as if they were his. I had an incredible time over there in the stage, a lot of fun. I could have been performing for a long time. This man made it sooo easy for me to move.

The food and wine was lovely. People were willing to meet new people and jumping from one table to another to join conversations. Everybody was very opened to have conversations about business, practices, experiences or just funny jokes. This has been in my opinion the greatest point in this conference. Everyone got the chance to do a lot of productive networking.

There was no planned activity for Wednesday evening and a bunch of us run a coding dojo with JavaScript following the randory style. After that we went to a Russian-Italian-YeahWhatever restaurant where I almost pee in my pants because of the laughs, but this is something I better tell you in the next conf.
Having no planned activity on Wednesday was a great opportunity. The day after, during the lunch time, Vagif Agilov and Gaspar Nagy facilitated a very interesting BDD refactoring dojo, again as a non-planned yet excellent activity.

eBay has been one of the sponsors this time. They had a stand with very kind people, muffins and stickers and were there looking for talented agile developers. This is another good example of the many benefits one can get from attending this conference, ... exciting career opportunities! If you practice BDD/TDD regularly along with other XP practices and have also experiences with other agile methods, contact me and I can forward you to eBay for their teams in London or Berlin.

All the talks I attended to, were good for one reason or another. There were a few talks where the talk itself wasn't very good but then the questions and discussion made them very interesting. They keynotes were astonishing. I specially enjoyed the keynotes by Peter Saddington, Ellen Gottesdiener, Papa Chris Matts & Olav Maassen, and Pawel Brodzinski. And I really appreciated the fact that all of them got the time to hang out with me and others. It was not that they came in just for their keynote and run away right after. It was great talking to you guys! 

All slides will be send to attendees soon. Some speakers have also published them, just search for the hashtag #agileDevPrac on twitter.

Can we do better next time?

Don't take me wrong, the conference was worth every single hour and penny. In fact, I feel that I need a week's holiday. However, we are agile, aren't we? And so now that the conference has finished is time to think retrospectively aiming to improve future editions.

Talks in the program were tagged with the level (beginner, advanced, expert). Some talks didn't match the tagged level according to attendees. I believe the level was defined by the speakers themselves but I can't ensure that in all cases. Considering that AgileDevPractices gathers top level experts from all over the world, as an attendee, I expect an advanced talk to tell me things that I (as a practitioner) can understand but still be innovative, teaching me something new. For an "expert" level session I would expect the speaker to treat me like an expert in the subject, meaning that he/she is bringing cutting-edge stuff. If I have to be selecting talks for next editions, I will ask speakers to justify why talks are tagged with "advanced" and "expert" levels.

The second thing we could improve are talks titles. I asked several people why did they choose the talks they attended to, and most of them said they just read the titles, not the descriptions. So titles are very important and they must be self-descriptive (like good code). If I have to be selecting talks for next editions, and I find a title which seems controversial or hard to understand, I will ask speakers to justify the title or change it. A speaker might be tempted to write an appealing title for her/his talk to grab the attention of the potential audience. However, for such an important conference I would ask for honest, clear and concise titles, rather than for marketing strategies. I don't say this happened many times in this edition though.

Last thing I remember we can improve is handling last-minute program changes. This time there were several speakers that couldn't come eventually so the printed program was outdated. The website was updated and there was a big printed and updated time table in the lobby, but still I felt some confusion sometimes. I think we can probably use a mobile application next time to keep everyone updated using phones.

I am wondering now whether it is possible to make the last day as energizing as the first one, because some of us were really tired at the end. Some speakers told me they prefer to talk in the first day rather than in the last one. How can we work around this? Any suggestions?

Thank you very much to all of you!

First of all, a big thanks to Jose, Madeleine and Uwe for their huge effort and the incredible opportunity they have given to me.

Second, to all attendees and speakers. I have met so many nice people that I am not going to write names in here, to avoid missing any of them. Because every single conversation has been important and fulfilling for me. I expect new professional collaborations to emerge from this encounters.

Hopefully I will see you in the Agile Dev Practices next year! :-)

If you write a blog post about the conference, please let me know, I'll be happy to add a link here. Posts published so far:


As I told to some people in Potsdam, remember that we are organizing an open space in the Canary Islands in June. It's a free community event. The perfect excuse to visit the canaries for holidays with you family. We are planning leisure activities. It starts the 21st, but in the afternoon, so you can still attend to the Test Automation Day in Rotterdam the 20th, and fly to Tenerife the next day :-)  In case you want to know who is already planning to attend and show others that you are participating, join this list.

See you soon!


Con una entrada de trabajo tremenda los sprints semanales se han ido terminando sin consecución de las metas esperadas. Cada semana con un poco más de atasco y menos objetivos cumplidos. Uno de los factores principales es que los criterios de aceptación no estaban claros y ello provoca trabajo en vano.  Por falta de análisis se toman decisiones equivocadas que tienen un alto coste y una estimación imposible (estimar sin saber con precisión lo que se necesita es "duro"). Se hace muy difícil calcular el valor que se aporta al negocio y la prioridad de la tarea. Se invierte un tiempo en planificación y retrospectiva del sprint para que no se termine la tarea.

Así que hemos pensado que hasta estabilizar la situación, dejamos los sprints semanales y hacemos un sprint por cada historia de usuario. Lo primero que se hará con la historia es sacar con la máxima precisión los criterios de aceptación. Escribiremos tests end-to-end al inicio de la historia (siempre que el codigo legado nos lo permita) que validarán su consecución. Así sabremos con exactitud lo que está terminado y sabremos que funciona. Además la figura del middle-man que traduce las charlas con el cliente en historias y criterios de aceptación se diluye un poco y todo el equipo se encarga de analizar y conseguir esos criterios: Más cohesión entre análisis-negocio y desarrollo.

El equipo de QA se convierte en un cuello de botella por deficiencia del proceso (o ausencia). Decidimos que los responsables de QA tendrán un pequeño meeting diario para ver cómo van las incidencias. Los jueves se hará especial esfuerzo en probar todo para confirmar que se puede desplegar en producción.

Además dedicaremos el último pomodoro del día a probar entre todos las tarjetas que están en estado "listo para UAT" para que lleguen más filtradas al equipo de QA.

Es prioritario reducir al mínimo la distancia entre el código que hay desplegado en producción y la rama principal del control de versiones. El ideal es poder desplegar en cualquier momento la rama principal, ya que usamos ramas para funcionalidades que están sin terminar. No obstante, a veces nos gustaria desplegar aunque haya funcionalidad a medias. Por eso vamos a intentar seguir puliendo la técnica de feature branches y además añadir en alguna ocasión feature toggles.

La información del kanban al final de la semana no va a parar a ningún documento histórico ni estadístico. Esto va a cambiar ya, para que tengamos el registro más fiable posible de costes en el corto, medio y largo plazo. Me encargo yo mismo. Esta información lógicamente no será pública :-)

La mejora contínua sigue adelante y en estas semanas hemos avanzado con paso firme en lo siguiente:

  • Hay menos interrupciones. Antes de interrumpirnos entre nosotros nos preguntamos por skype o email y al terminar el pomodoro hablamos entre nosotros.
  • Estamos más concienciados con probar a mano las tarjetas antes de pasarlas al equipo de QA.
  • Cada día nos preocupa más la deuda técnica y pensamos más antes de programar.
  • Las reuniones diarias (daily meeting) van cada vez más fluidas, tardamos entre 10 y 15 minutos.
  • Las reuniones de retrospectiva son más directas y nos dan más información.
  • El número de tests automáticos sigue creciendo y su calidad también. Hemos alcanzado ya los 500 tests con javascript.
  • Hemos hecho varias mejoras de arquitectura sin que el cambio sea muy costoso ni traumático.
  • Hablamos más unos con otros y discutimos sobre código y arquitectura en el proyector antes de lanzarnos a programar lo primero que se nos ocurre.

El camino es largo, pero vamos mejorando hacia XP. Sólo hay que seguir vigilando para no retroceder y seguir practicando la honestidad, la valentía de hacer lo que es bueno para uno mismo (y eso será lo mejor para el equipo) y el sentido común. Ser consecuentes con lo que se hace y constantes con las prácticas.


RS: Aprovechar la experiencia

En el sprint de esta semana nos hemos dado cuenta de errores cometidos semanas atrás. Las acciones más importantes ahora para seguir mejorando, son:

  • Que cuando reimplementemos una funcionalidad (o una similar a otra que ya tuviesemos), contemos con las personas que desarrollaron la primera versión. Lo ideal es que las personas que estuvieron en el primer desarrollo estén haciendo pareja con quienes se enfrentan al problema por primera vez. Si no es posible, al menos deben sentarse a hablar de las dificultades que surgieron con la primera implementación y las soluciones que se encontraron.
    Lo primero será tratar de evaluar si se puede reutilizar parte del código existente. No siempre es fácil tomar esta decisión pero por lo menos hacer un estudio rápido de la situación. En caso que se pueda reutilizar, estudiar qué se debe refactorizar y a qué se le pueden añadir tests. En caso que haya que reescribirlo todo por completo, tener presentes las ideas que ayudaron más al buen funcionamiento de la primera implementación. Esto es: aprovechar la experiencia que ya tenemos.
  • Separar muy bien lo que es importante de lo que es urgente. Si todo es urgente, dejamos de saber lo que es importante. Nos ha pasado y nos ha perjudicado. Cuando digamos que algo es urgente, tendremos que saber que corremos peligro de dejar atrás lo imporante.
  • Tratar de evitar la entrada de imprevistos durante el sprint. Tiene que ver con lo anterior. Si surge una necesidad el jueves y no es bloqueante, debemos plantearnos esperar a abordarla el lunes, es decir, en el siguiente sprint. La idea es no romper la planificación semanal. Cuando la rompemos, nos distanciamos de los objetivos propuestos y entonces dejamos de ser predecibles. Ser predecibles es una de nuestras metas porque así sabremos cada vez mejor, cuánto podemos tardar en entregar funcionalidad con valor para el negocio.
  • Evitar hablar de "terminar tareas" y hablar más de poner en producción tareas que suman valor. No sirve querer terminar, sino querer desarrollar piezas que mejoran la experiencia del usuario. Cuando pensamos en terminar, es más fácil hacerlo mal (porque lo urgente quita de enmedio a lo importante). Rara es la semana que no se introducen nuevos requisitos en funcionalidad que estaba "terminada".

Esta semana estoy muy contento con la labor técnica del equipo:

  • Se ha respetado en todo momento que todos los tests pasen
  • Se han añadido tests para demostrar bugs
  • No recuerdo que se hayan escrito métodos nuevos de más de 10 líneas.
  • No se han introducido números mágicos ni código duplicado
  • Se ha prestado bastante atención a la code review y los commits han sido muy claros.

Es importante vigilar bien que sigamos por el buen camino, porque estamos en un punto en que retroceder lo andado no es muy dificil.

Buen comienzo de semana a todos :-)

RS: planificación de sprint

Nuestros sprints son de una semana, empiezan el lunes y terminan el viernes. Planificamos en el daily standup meeting del lunes por la mañana. Pero el daily no queremos que pase de los 20 minutos (mejor seria no pasar de los 15). Asi que las últimas dos semanas, terminabamos el meeting sin haber cerrado la planificacion semanal, sin tener las tareas estimadas y por tanto, sin conocer cuál era el objetivo a cumplir. Eso hace que al terminar la semana no sepamos si lo hemos hecho mejor o peor. Dejamos de ser predecibles cuando pasa esto.

Por este motivo, la reunion del lunes podrá estirarse hasta un máximo de una hora con tal de que todos podamos estimar y comprometernos a entregar determinada funcionalidad el viernes, o por lo menos a intentarlo.

Aunque nuestra hora de meeting son las 9.30am, el lunes desplazaremos la hora lo que haga falta para que estemos todos. Esta semana faltaron personas que al no estar en el meeting de planificación no pudieron aportar su conocimiento. Eso llevó a que yo escogiera como prioritaria una tarea que en realidad no lo era, porque ya teniamos una funcionalidad parecida, hecha en código existente pero no lo sabíamos. Era una funcionalidad que conocía la persona no estaba. La tarea que se ha implementado hacía falta pero no era tan prioritaria en el sprint de la semana que ha terminado.

Por otro lado existe preocupación porque no estamos colocando las clases en los namespaces más adecuados, ni los ficheros en las carpetas adecuadas. El problema es que si no están en un lugar intuitivo podemos repetir funcionalidad. Para esto la code review juega un papel importante, por lo que hay que seguir haciendo incapié en ella. A parte de eso, la persona que detecte que se ha puesto un fichero en el sitio incorrecto o un namespace que no corresponde, debe actuar de manera concreta, bien modificando el código o bien avisando por email a los compañeros, diciendo exáctamente por qué no es correcto y cómo solucionarlo.

En el código legado sigue habiendo horrores que nos están haciendo daño pero la preocupación por la ubicación de clases y ficheros es un tema recurrente así que vamos a intentarla solventar, tomando acciones concretas y constructivas.

Esta semana hemos resuelto graves problemas de concurrencia que teníamos. El trabajo ha sido duro porque hemos invertido mucho tiempo y escrito pocas líneas de código y eso da mala sensación, pero el resultado es muy bueno. Hemos aprendido bastante y sabemos qué cuestiones debemos considerar desde ya, para que nuestro código esté preparado para la concurrencia. Escribiré un post sobre nuestros descubrimientos con Linq2Sql y concurrencia pronto.

En las últimas semanas hemos hecho muy poco pair programming porque buena parte del equipo pensaba que así avanzaríamos más teniendo la fecha de entrega muy cercana. La realidad es que no podemos cuantificar si ha salido adelante más trabajo o no, pero lo que sí hemos hecho es introducir deuda técnica y aumentar en desconocimiento de lo que los demás hacen, lo que lleva a la duplicidad del código. Falta comunicación. Sabemos que la próxima semana volvemos a nuestro ritmo habitual, intentando hacer las cosas lo mejor posible y sabiendo que cuando dos personas trabajan juntas y bien concentradas, nos acercamos más a ello.