Agile important bits

There is a lot of Agile talking and I think it has reached a point where it is, if not standard, at least a common way of doing software. But, even if there is a lot talking about Agile methodologies, and companies telling that the are doing Agile, are they really doing it? I’m not so sure. When relating to Agile, I always come back to the source, which is the Agile manifesto. I really like its simplicity. Let me copy it here

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The first time I read it, I must say I wasn’t impressed. Yeah, sure… Great values, dude. But after spending more time, I come to see that as a really good set of values that, in mi opinion, work really well for software development. In practice, I think there are some of those values that are somehow “forgotten” over the day to day operations. I’ve been thinking about what are the ideas that, again in my opinion, are the ones I consider the best way of implementing those values. Consider them my personal “Agile highlighted parts”

Never-ending learn

Well, maybe not in 21 days, but that's the spirit...

Well, maybe not in 21 days, but that’s the spirit…

In my opinion, the single word that is capital in software development is “LEARN”. The same thing applies to Agile. Agile is about being constantly learning. Change (which is also a very important word) is just a consequence of this learning process, the outcome. Because we learn how to do things better, we change our way to work. Because we truly understand the problems of the customer, we can develop what the customer needs (which may not be what the customer has in mind in the first place). This learning process should not view restricted to the developers. It is also applicable to the rest of the people involved, including the customer. If the customer is not willing to learn in the process and refuses to accept feedback, then the process is much more difficult. That could be the single most important risk in Agile, as that will make the collaboration difficult and adds a lot of friction. Even in products aimed for mass consumption, this process can be present one way or another. For example, recently there has been a lot of discussion about iOS 7, and how consumers have learned how to use a touch screen and elements that were present on previous versions to help usage are no longer needed as average consumer know now what it is about. Refusal of learning can also be a problem in Agile. There are people that do not like the constant effort and the change in mindset that it implies.

Team centric view.

The team in Agile is king. When I say “a team” I am not referring to a list of people put together on the same building working on the same product. A team is much more than that. It is people working towards the same goal, but also effectively working close together and helping each other. Just as a soccer team needs players with different abilities, so does software teams. The people working on the same product will have to be, with high probability, multidisciplinary. That has not been usually the case on software companies, where you have the testing department in one side, the design department in another, and the R&D department detached from the rest of teams, communicating through big documents and formal meetings. That creates the need of strict interfaces, and negotiation between the parts to agree how to exchange information.

Some development talk is full of wibbly-wobbly... timey-wimey... stuff

Most development talk is full of wibbly-wobbly… timey-wimey… stuff

Instead, a team will try to learn and improve how to work and exchange information. Asking constantly, “how can I make the work of X easier?”. To be able to do that, you have to know and understand what are the problems that X will face, and the only way of knowing that is to work closely with them. That is more difficult that it looks. We developers are usually very “machine centric”, tending to try to fix everything with a script, or adding a new feature that complicates the system. It is not simple to learn about how and why other “non-techies” people (sales, designers, etc) are doing the things they are doing the way they are doing them. We prefer to keep running out scripts and our UNIX commands. We talk our techie talk of threads, classes, recursion and functional programming. But the learning of the”domain knowledge” is really what makes the difference between a good team and a great one. And that knowledge can only be achieved constantly learning from one another. Both the developers understanding the real problems of the customer, but also, in some cases, the customer understanding how the team works and what is possible on a certain amount of time. Creating a good team is very important and challenging. But also accepting that it is formed by different individuals, with different capabilities, strong and weak points, is probably one of the most difficult parts in any organisation. I always think that the most challenging task is to deal with people, which, no matter how “good cultural fit” is achieved, will be individuals different from any other one. Acknowledging it and being able to make everyone on the same page is difficult, but capital for highly successful teams.

Interact in a constant, but structured fashion

While interaction is really important, some balance need to be achieved with interrupting ongoing work. Agile is not about “hey, we can change all at any point”. I know, the name is a little misleading. It about knowing that you are going to change stuff, and deciding what at certain points. One of the details that I found out more efficient in that are sprints and stand up meetings. Both are tools to structure the conversation while providing constant feedback.

Stand up meetings

Doing stand up meetings in the best way is more difficult that it looks. It needs to be kept very simple, fast, and with as little noise as possible. Basically each participant need to say, keeping it simple: What did I do yesterday? What I am going to do today? Are there any problems in the way? And listen carefully to the rest of the people to be aware of the work being done on the team, and to see if you can give support to anyone (during the meeting or later, if more than a few minutes are necessary). Being actually standing up and in a different room helps, as you tend to keep things up to the point, eliminating distractions. One interesting part is not the meeting itself, but the time that previously is used to structure your mind into what you’re going to say. That helps a lot in planning and in keeping you focused, as everyday you’ll have to explain what have you done. Focus is paramount in software development. Another important thing is to keep that as a strong habit. There are always moments when it looks like no one is saying something new, and it feel as redundant. If the meeting is all about the same things for a long time, then is clearly a problem (your tasks are not as small as they should). But the benefits in terms of constant feedback and focus are not achieved until some time. I also think that managers/product owners should be present on the meeting, and probably participate actively. Remember, it is part of the learning process and it’s a very good opportunity to show how the team is working and what are the management tasks. A proper star up meeting reduces the need to interrupt the work of the day with typical “what are you working on?” questions, and detects very fast problems and blockers. It structures communication to channel it.


Well, it does not scream "sustainable pace", but still...

Well, it does not scream “sustainable pace”, but still…

While the standup meetings structures the communication between the team, Sprints structure the communication between the team and “the external world”. The idea of the sprint is to produce something that can be shown, and ideally works, even if it’s small and not complete. That gives feedback and then the goal for the next sprint can be decided. While having a simple objective for a sprint can be good, I don’t think is necessary. A simple grouping of tasks with no particular meaning together may well be the objective. I don’t like the word “Sprint”. I think is not fortunate, as it will not give the idea a long term race, but a strong burst in effort. Software projects are long, and teams should find a comfortable development speed, or the quality of the result will suffer. I’d prefer something like “stage” (using bicycle race metaphor), because the main idea is that they should have a sustainable pace. The sprint objective is not a contract signed by blood of your firstborn. It is a reasonable objective that the team honestly thinks can be achieved.  Let me get back to  couple of ideas there. What can be achieved on a sprint is something that can only be decided by the team. They are the only ones with the knowledge of what is possible and what is not. Estimations are that, assumptions. A typical problem in software development is unrealistic deadlines by management, that will be used as weapons against the developers, and the natural response from developers is to produce “safe” estimations, much bigger that they should, so they can be protected. This is not a good thing, and it is a reflection of distrust. The way to overcome that is to treat estimations as that, and try to improve them, without punishment for  mistakes. Let me rephrase it: Estimations will be wrong. Often. The objective should be to improve them, and to not be wrong by a huge margin. Dividing work in small tasks will help, but that’s an inherent problem.

Make it work

I consider myself a pragmatist. At the end, everything should be done not for the sake of it, but because it helps towards an end. As with a lot of good ideas, people has fallen too often in “Agile cargo cult”, just following processes without thinking why, or without analysing who are the people on charge of doing it. Again, analysing and learning what’s going on is important, to enable the best concepts applied to a particular team.

Wrath of Khan and failure

SPOILERS AHEAD: I will comment a couple of things about Star Trek Into Darkness, so, if you haven’t seen it, and don’t want to know some plot details, you may not want to read this. Just watch the movie and come back, I’ll be here waiting ;-)

Oh, there were plenty about Star Trek II: The Wrath of Khan (and a little of Space Seed), but being a movie from 30 years ago, I doubt they can be considering spoilers.

so 80s

so 80s

Star Trek II: The Wrath of Khan is, no doubt, a fan favourite. It has a great combination of a powerful story, iconic moments, connection with the TV series roots, and that extra Shakespearean touch that keeps everything together. But I want to focus in a particular aspect, one of the stronger themes than runs through the movie.

And that is to grow old. The fact that in particular (here Admiral) Kirk is not young any more is presented through the whole movie. He becomes an unexpected father. He needs to use reading glasses.

But, over all, he has to face the consequences of his previous actions. Especially failed ones.

Kirk starts the movie as that invincible fleet captain that has faced all possible risks and dangers (“Risk… risk is our business! That’s what this starship is all about…”) and has been triumphant on each and every occasion. Getting as far as cheating on Kobayashi Maru (a training mission designed to present failure to cadets) because, well, he simply don’t believe in non-win situations. During The Original Series, basically every single opportunity to take the bold approach to fix a problem is taken, with amazing success.

But, just as the movie starts, we discover that there has been something unexpected during this time. Khan and his crew were left at the end of Space Seed on a harsh planet, basically so they can get a challenge worth of genetically engineered supermen. At the same time, the rest of the universe won’t have to worry about their conquest aspirations. But there was a mistake. That challenge has mutated into a nightmare, even for men like Khan. Enterprise crew (and Starfleet, for what matters) just forgot about the issue, moving to the next exciting adventure the following week. But the truth is that it has been a disaster. Kirk failed without noticing it.

Ok, so Kirk goes to fix the problem and saving the day. He is even able to use some tricks and cheat Khan a couple of times, giving the impression that he is defeated, but managing to save the day at the eleventh hour. As usual, on the other hand.

I have been -- and always will be                             -- your friend... Live. Long. And.                             Prosper.

I have been — and always will be — your friend…

But, then the final moment arrives. Kirk truly faces a real non-win situation. Spock sacrifices himself to save the full ship, in a move that Kirk couldn’t anticipate. And here is the genius on the script. Spock dies. He truly does! There are no tricks, no last minute saving, no technobabble that reverts death. Spock is dead, he is no more, has ceased to be, expired and gone to meet his maker. For real. For the next 2 years (until the next Star Trek movie) Spock was totally dead. And this is extremely powerful from the point of view of drama. It is not common at all for a big budget movie, and it was a big bold move for Star Trek.

Because Kirk faces the moment he has feared for his whole life. The moment of failure. Yes, sure, it’s not a total failure, the ship has been saved. But he has been able during his whole career to end every adventure making a comment with Spock and McCoy at the bridge without a scratch. Death is for Red Shirts and aliens, not for him or close friends.

And that’s the main point of it. Failure really sucks. It hurts a lot. That’s why no one wants to fail. No matter how many times we say “failing is the first step in succeeding“, or how we repeat the mantra of “fail often, fail early“. Fail small sucks less, but still sucks. But it is unavoidable. Kirk was able to deal with it because, well, he is a fiction character. But in our lives, the truth is that we fail constantly. And the way of dealing with it is not denying that fact, or cheat our own Kobayashi Maru, living in a “I don’t believe in non-win situations” bubble. The way of doing it is trying to make each failure the seed of a new success, to learn from our errors, to keep us motivated to better ourselves. Even if it hurts every single time.

That’s one of the main reasons why Star Trek Into Darkness didn’t really move me inside. While there are some superficial similarities/homages, the character of John Harrison does not have any particular meaning for Kirk or Spock. He does not represent any personal failure for them or haunt from the past. And the end is yet-another-protagonist-almost-die-to-be-saved-by-a-gimmick, lacking the deep meaning of The Wrath of Khan.

Crítica despiadada de “Todo va a cambiar” de E. Dans

Influido y presionado desde Twitter, he decidido leerme el libro “Todo va cambiar”, de Enrique Dans. Sinceramente, ha sido un suplicio, y la idea es hacer un resumen para que nadie más tenga que hacerlo… :-D

Primero, unas ideas preconcebidas. No me gusta nada Enrique Dans. Lo encuentro el paradigma del gurú de Internet que simplemente habla sin tener mucha idea, que intenta comunicar a base de repetir las mismas ideas que hacen otros, y con un sobramiento de sí mismo desmesurado. Hay un lugar para “los comunicadores”, gente que se encarga de recopilar ideas y darles un tratamiento único. Hacerlo bien es difícil y hay que reconocerlo. Hay otros que se dedican a poco menos que copipegar todas las ideas que pueden, y encima lo cuentan peor que el original. Eso sí, parece que es una especie de gurú del 2.0 y que tiene muchos seguidores. Pues vale.  El que espere una crítica amable, puede dejar de leer :-D

Dicho mis ideas generales sobre Enrique Dans, vamos a lo que es el libro. En general, me resulta un libro prescindible e infumable (que es todavía peor). Principalmente se dedica a recopilar ideas muy manidas, a saber: Web 2.0 bueno. Derechos de autor, malo. Nuevos paradigmas. Compañías que no evolucionan. Google bueno, Microsoft, malo.Todo esto aderezado con un estilo de escribir aburrido y pagado de sí mismo, con contínuas referencias personales un poco metidas con calzador.

Creo que lo peor que tiene el libro es que su concepto debería ser algo que inspirase, que te animase a hacer algo, pero el 90% del tiempo está comentando los mismo ejemplos de siempre (Amazon, eBay, Google, Microsoft, etc), y no resulta inspirador. Comparado con, por ejemplo, Seth Godin, se le ven las carencias. Por ejemplo Brainwashed (traducido al español en el blog Desencadenado) o Bootstrapper Bible son buenos textos que te impulsan a pensar, a cargar las pilas, a intentar hacer algo… El que Enrique Dans te cuente sus batallitas de pionero internauta, pues no te da el mismo impulso… Así que tenemos dos opciones: O bien lo que dice el libro te lo sabes y ya lo has hecho (ya has cambiado) o bien, si no lo sabes, le falta la parte de verdaderamente animar a hacer algo. Por eso digo que es prescindible.

Aun así, hay libros prescindibles y animados de leer, que aumentan tus conocimientos. No es el caso, el estilo (al menos a mí) me resulta soporífero y cada pocas páginas tengo que darme de cabezazos por alguna metedura de pata o algunas de sus “perlas”. Además, se hace difícil para el profano al ahondar en términos excesivamente técnicos, y los pocos que se explican se hacen de manera bastante farragosa. Curiosamente, para ser un “libro 2.0″, es raro que no incluya enlaces y referencias a muchas páginas para apreder más. Si me da por pensar mal, será para que no se noten las carencias.

Para los que no tienen ganas de leerse el libro (y, desde aquí, no se lo recomiendo a nadie), he decidido hacer un resumen, capítulo por capítulo con las cosas más cargantes que aparecen…

  • Después de un prólogo firmado por Vint Cerf, con sobreabundancia de términos técnicos en inglés y entiendo que fuera de lugar para un libro “generalista” (sospecho que se escribió en inglés), viene la introducción. sin duda, una de las joyas del libro, que relata las maravillosas aventuras de un pionero, un visionario en esto de los ordenadores, un gurú. Claro que sus “visiones” producen más risa que otra cosa a cualquiera que haya estado relacionado con ordenadores los últimos 15 años, pero bueno. Al tratarse de un tema “cercano”, el estilo es menos “plomizo” (comparado con el resto del libro), pero mucho más “sobrado”.
  • Música, películas, mentiras e Internet. El primer capítulo es una sucesión de topicazos, argumentos mil veces repetidos ya hace años, y aderezados con una serie de pedantes referencias históricas. Los argumentos son los de siempre sobre el tema copyright, y es un tema taaaan manido. David Bravo explica lo mismo de manera muchísimo más amena (y hace 5 años) en “Copia este libro”
  • Las evidencias del cambio. Explicando las bondades del software libre y cómo la Wikipedia es mucho mejor que la Enciclopedia Británica (entre otros ejemplos de cómo la tecnología mejora nuestras vidas, con ejemplos). Tampoco escatima en poner por las nubes a su padre y abuelo, pero incluso ellos tendrían problemas con los cambios. Y pensar que mi abuelo usaba un ordenador e Internet, siendo una de las personas más negadas para temas técnicos que he conocido… Pero el gran descubrimiento del capítulo es el hecho de que la palabra “Viagra” se puede deletrear de 600.426.974.379.824.381.952 (son 21 cifras) de manera que sea reconocible por los humanos. Viene de este artículo, que obviamente, es más una broma que otra cosa… Entre otras cosas, porque acepta cosas como “aVbIPARGIRNam” como una forma de deletrear “Viagra” de manera (perfectamente) reconocible por los humanos… Sin embargo, creo que es un gran número para definir el ego de Enrique Dans en relación al ego de una persona normal, es decir, su ego es 600.426.974.379.824.381.952 veces superior al de una persona normal, o 1 edans veces…
  • La disrupción tecnológica (cuando lo vemos venir). Habla de lo rápido que pueden darse procesos de cambio. También tiene “detalles”, “los productos bit” y “los productos átomo”, que viene siendo “información” y “cosas físicas”, claro que dicho así resulta menos lioso y Enrique Dans dice textualmente: “Pero nadie le dijo que la lectura de este libro iba a ser fácil”. Creo que debería ir en la contraportada, a modo de advertencia. Otro detalle: “cuando llegué en 1996 a los Estados Unidos tras haber recibido durante toda mi vida una educación en inglés británico, el acento californiano me suponía ciertos problemas de comprensión”. Si escribe eso, o no ha hablado con un británico en su vida (supongo que con algún californiano sí) o se las da de que sabía inglés británico mejor que la Reina antes de llegar a California.
  • La evolución de la comunicación. Básicamente una evolución, desde nuestros ancestros comunicándose a base de aullidos, hasta los blogs. Curiosamente, no comenta nada específico de Twitter o Facebook.
  • Introducción a la red. La neutralidad de la red. Resume la idea de la neutralidad de la web y cómo “oscuros intereses” pueden interferir, junto a ideas como que es un derecho, etc…
  • Los costes de transacción y comunicación. O cómo las empresas “antiguas” tendían a crecer verticalmente (llevando el control de producto desde la materia prima hasta la venta al por menor) y ahora se tiende a especializarse y a poder trabajar repartidos por el mundo. Deja claro que conoce bien cómo funciona Weblogs SL.
  • La generación perdida: La resistencia a la tecnología. Los típicos comentarios de que Internet es fabulosa y en España tiene muy mala prensa. Que hay sitios peligrosos, pero no es para tanto, y que las empresas tienen que adaptarse y no rechazar los cambios tecnológicos, o serán aparcadas. Otra vez, nada nuevo.
  • Una nueva generación. Lecciones sobre cómo educar a tus hijos en la tecnología. Me parece un capítulo especialmente peligroso (y posiblemente polémico), ya que diserta sobre el uso de las tecnologías en niños y adolescentes, resumido en “los niños utilizan de manera más natural las redes sociales y saber usarla mejor” y critica cosas como el uso de filtros o restricciones el uso de los ordenadores en niños. Me parece peligroso porque entra en un terreno sumamente resbaladizo, como es la educación de los hijos, y evita el siguiente problema. Si el padre sabe poco o nada de Internet, ¿cómo debe educar a su hijo al respecto? No es nada fácil responder a estas preguntas, incluso por (verdaderos) expertos, pero Enrique Dans sienta cátedra con una rotundidad bestial.
  • La red y el neohumanismo. Aparentemente, vivimos en sociedades en las que la identidad individual ha sido cercenada. Y sólo lo recuperaremos por Intenné. O eso dice. A mí me parece una tontería como un castillo, será que no soy un gurú que marca tendencias. Y volvemos a la idea de que no eres nadie si no estás en Google posicionado como un experto. Chorrisandeces de esas que Andrés, en Marca Propia, se encarga de desmontar todos los días. El mundo no es sólo Internet (y lo dice alguien que trabaja en el ramo y para quien Internet es MUY importante).
  • Un caso práctico: Microsoft. Hacer leña del arbol caído siempre es interesante, y Microsoft es una compañía que se presta como pocas a calificarla como “el Mal Absoluto”. Pero de ahí a contar la historia de Microsoft como se cuenta en este capítulo, hay un mundo. Porque se dedica, básicamente, a ponerlos a caer de unburro, relativizar sus éxitos y ahondar en sus fracasos. Además, nos volvemos a encontrar “perlas” de las que me llama la atención esta: “Los mejores lenguajes de programación son PHP, Perl o Python.” Vamos, que nos tomamos muy a pecho las arquitecturas LAMP (también hace referencia a Apache) :-D Resultado, “Microsoft es la historia de una falta de adaptación”. Y mira que Python es mi lenguaje de programación favorito ;-)
  • La evolución de la web. Varios ejemplos de empresas exitosas en Internet, como Google, Amazon, YouTube o eBay. Los ejemplos de siempre, vamos.
  • Un caso práctico: Google. En comparación con el anterior, todo loas a Google. Algunas explicaciones de cómo funciona su buscador (aunque pasa de puntillas frente a otras alternativas que había, en su momento y califica a Yahoo de “directorio”), y, curiosamente, una reseña sobre el tema de la privacidad, que se salda diciendo que Google “es muy transparente” y que en cualquier momento podemos borrar las cookies del navegador…
  • La evolución de la tecnología: del ordenador a la nube. Cambiar de un procesador de textos con datos en local, a “la nube”, ese concepto etéreo que parece que las cosas no se guardan en ningún sitio, pero están muy seguras. Aviso a navegantes, procurad tener copia de las cosas realmente importantes que tengais en la nube. Ningún sistema es seguro al 100%
  • Nuevas herramientas para nuevos escenarios. ¿Slashdot es un blog? Este capítulo trata sobre lo guays que son los blogs y lo fácil que es escribir en uno y hacerse un reputado experto y gurú. Además de algunas reseñas a Twitter y a Digg.
  • La sociedad hiperconectada. Blogs (de nuevo), comentarios, twitter, respuestas de las empresas a usuarios que se quejan en Internet, comunidades, trolls interneteros… Tiene pinta de repetición de otras fuentes, a veces está deslavazado y repite machaconamente ideas de otros capítulos como “El efecto Streissan”.
  • Revisando los papeles: Participación y comunidades. ¡Móntese un blog si no lo tiene! Es muy importante, pero si lo abandona, nadie le echará de menos…
  • El futuro. Aquí Enrique Dans nos obsequia con lo guay que es su vida con el uso de la tecnología y cómo podremos disfrutar de parte de ella si nos conectamos a Internet, participamos, compramos y hacemos nuestra vida más tecnológica… Las gestoras de derechos seguirán luchando por conservar el poder e impedir el libre intercambio de archivos. Las telefónicas querrán no ser neutrales. Los “viejos poderes” intentarán impedir los derechos digitales, pero no podrán. Todos podremos ser creadores y se democratizará la creación. Se eliminarán intermediarios. El mercado se fragmentará aún más y habrá un nuevo modelo económico. Todo ha cambiado ya. Si no has oído música de violines al leer esta parte y has aplaudido al final, es que ya has oído lo mismo desde hace unos 10 años mil y una veces… Yo al menos, exijo que se narre con garra…

En resumen, me ha parecido infumable. No sólo habla de los mismos (y típicos) ejemplos una y otra vez, sino que lo plaga de referencia que oscilan entre lo irrelevante y lo pedante, y el autobombo más descarado. El libro es aburrido, lleno de términos desconocidos para el que no está pendiente de la informática e irrelevancias para el que está pendiente.