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.

El fin de la cultura de masas

Hoy, en Las Penas del Agente Smith hacían un divertido experimento respecto a la famosa frase de Pio Barjo de que “el nacionalismo se cura viajando”. No estoy demasiado de acuerdo con ese planteamiento, creo que, además de viajar, hace falta un estado mental adecuado, pero obviamente ayuda 😉

Este viene a colación a un concepto que me gustría desarrollar en este blog, y es el tema de la “cultura personal” (a falta de un término mejor).

Hasta hace muy poco tiempo, el concepto de “cultura nacional” ha sido, en nuestro entorno al menos, la manera principal de entender el mundo y las relaciones con los demás. De hecho, es una visión del mundo que sigue plenamente vigente, y nos definimos por nuestras nacionalidades, español, francés, etc. Incluso tenemos ideas políticas en las que las nacionalidades son parte importante. Lo que subyace en esta forma de entender el mundo, que viene desde el siglo XIX, es la idea de una cultura nacional propia y distintiva. Cada cultura nacional tiene una serie de elementos propios que la diferencian, como es el caso (muy claro) de la lengua, pero también de fiestas propias, gastronomía, organizaciones territoriales, leyes históricas, etc, etc. Esta cultura, además, es relativamente estable y cambia lentamente.

Este sistema de entender el mundo, bueno, ha tenido su sentido histórico y ha sido (¡y sigue siendo!) muy importante, pero creo que, con la llegada de las nuevas tecnologías y el desarrollo del “mundo pequeño”, irá desapareciendo, o al menos, teniendo menor importancia a favor de una cultura completamente personal e individualizada.

Todas estas tecnologías, junto con los cambios sociales que han traído consigo, nos permiten superar barreras, que hacían la aparición de las culturas masivas inevitables:

  • La barrera geográfica. A día de hoy es posible viajar de una parte a otra del mundo en cuestión de horas. A una escala más pequeña, es posible vivir y trabajar a unos cientos de kilómetros de distancia, o incluso entre lugares más distantes utilizando puente aéreo o teletrabajo. Hay millones de personas que son emigrantes/inmigrantes, de una manera muy dinámica.
  • La barrera de la comunicación. A día de hoy hay más gente que es capaz de expresarse y entender más de un idioma del que haya existido nunca. La lengua franca actual, el inglés,  es practicada no sólo por una élite, sino por gran cantidad de gente que es capaz de comunicarse entre ellos. La comunicación entre diferentes partes del mundo es prácticamente instantánea.
  • La barrera de la clase. La sociedad (al menos la occidental) está más amalgamada que nunca. Las divisiones entre clases o grupos sociales son más pequeñas. Los grupos sociales ya no son prácticamente estancos, como podía pasar antiguamente con la nobleza. La diferencia entre grandes sectores (hombre/mujeres, jovenes/adultos, etc) es más complicada. La afluencia de inmigrantes de distintos lugares del mundo crean nuevos grupos sociales, más pequeños y menos homogéneos. 
  • La barrera de la personalización. Cada vez es más fácil fabricar pequeñas cantidades de manera productiva. Cada vez los servicios pueden ser más personalizados. Hace no muchos años, de productos como la lecha, había dos tipos, normal y desnatada. Ahora puede haber cientos de tipos.

Todos estos elementos permiten que, cada uno de nosotros esté en contacto con muchos más elementos que anteriormente, y podamos configurar una culura mucho más “a la carta”, que incluya componentes que antes hubiésemos asumidos como “extraños”, de manera mucho más natural.

Si antes queríamos irnos a vivir a otro país, debíamos renunciar a muchas cosas de nuestro lugar de origen, el idioma, las noticias, la música, el contacto familiar constante, etc. Ahora mismo podemos “llevarnos” muchas de estas cosas de manera fácil, volver frecuentemente en viajes cortos, etc.

Igualmente, podemos “traernos” muchas manifestaciones culturales de lugares lejanos: cine (americano, europeo, iraní), gastronomía(italiana, mexicana, japonesa), música (africana, latinoamericana, alemana), etc.. En el pasado, estos “contagios” se producían de manera pausada, y normalmente se consumían igualmente de manera masiva. Sin embargo, ahora se posibilita que este contagio sea más directo y mucho más individualizado, sin necesidad de pasar un filtro previo de que “la sociedad”, en su conjunto, lo acepte como interesante o incluso propio.

Por supuesto, estamos todavía al inicio de este cambio. Hemos sido educados en un sistema en el que el mundo “separado” y las culturas de masas son la manera de entender la vida, y especialmente con un matiz nacionalista que defiende “lo tuyo” frente a “lo de fuera”. Los cambios sociales son muy lentos, tardan generaciones. Y no todo el mundo parte de la misma situación ni tiene los mismos recursos.

Sin embargo, creo que esta “atomización” cultural es inevitable en el largo plazo ya que, como seres humanos individuales, tenderemos a buscar nuestra combinación favorita de elementos culturales entre todos los que tengamos disponibles. Y cada vez tenemos más elementos culturales al alcance de la mano.