Sunday, March 19, 2017

Book review: Team of Teams




Team of Teams: 

The Power of Small Groups in a Fragmented World 

General Stanley McChrystal, Tantum Collins, David Silverman, Chris Fussell 


A great book on how to generate a flexible and agile organization prepared to win in a complex world. The authors explain how they created a culture and an organization composed of a network of autonomous teams that at the same time have a shared purpose and a common context.
The most impressive thing about this book is that they described a real story of a deep transformation from a very difficult starting point:

  • A huge military task force 
  • A very solid command and control culture 
  • Several separated organizations 
  • Security risks about sharing information 

So no excuses… It can be done even in the most difficult contexts.

An indispensable book for anyone interested organizations that are adaptable, agile and prepared for this fast-paced, changing and interconnected world.

Note: An interesting podcast with one of the authors bosslevelpodcast interview McChrystal

The two pillars of agile software development




I like being agile and I can say without embarrassment that I have some experience in promoting this way of working and culture... From this experience I can say that what works in the long term is a way of working that put focuses on two things:

  • A healthy culture focused on people (collaboration, respect, team work, creativity...) 
  • Looking for quality and technical excellence (for example XP practices are a great starting point).

Too much focus on methodology without technical practices or without a lot of effort in the culture will probably end in a cargo cult agile and a failed change opportunity...

In summary, for me, from the three main points of agile (culture, methodology and practices), by default, I prefer culture and practices... A healthy culture shared among all the company, a minimal agile process and good technical practices, generate a good flow of outcomes with a sustainable pace...


By the way, this spirit fits very well with Extreme Programming (XP) and with Software craftsmanship.

Needless to say that with a good culture you can reach the rest of necessary ingredients, but it is necessary to have a clear vision of the destination and spend time and effort....

For sure, this is only my opinion and is only based on my experience, but, you know, this is my blog... :)

Sunday, March 12, 2017

interesting Talks/Podcasts (March)

From the talks I've heard / seen lately, these are the most interesting:

Development:



Culture and leadership:



In spanish:




Monday, February 27, 2017

Applying the DRY principle

Post previously published in Spanish Aplicación del principio DRY


I always have very clear that in software development is very important to have each business concept in one place only. On the other hand, is also true that the code duplicity is a problem that we should try to avoid or at least limit and remove systematically when needed.

But, sometimes, we follow the DRY principle blindly, without having in mind that each decision have a cost, so I will expose in this post some points that can help us to decide whenever we should remove the duplication or when we can live with it.
  • We should differentiate between duplication of business concepts, rules, validations, flow, etc and duplication at the implementation level (for example source code with small duplication). 
  • The duplicity of business concepts and definition should be avoided as much as possible.
  • Sometimes duplicity at the code level can be a tip saying that there is an abstraction waiting to be discovered, an emergent behavior of the system or a pattern common in our application. Is important to minimize, but it is not a drama if there is "some" amount of duplicity. But be aware that you should be very careful to not generate a premature abstraction. In my experience premature abstractions are much worse than duplicity.
  • If you develop using TDD is better to duplicate code to reach green, and once in green and well covered by the tests, refactor to eliminate the duplication.
  • Depending on the language (C++, python, java...) there are some kind of duplicity that have a high cost of elimination or don't have an idiomatic solution. In these cases we must eliminate duplicity when the result is easier to understand (not only for you, but for the whole team). In the face of doubt, readability must always prevail.
  • It is important to know that when we eliminate duplicity we usually create a common class, a library, a method or any other artifact that allows us to reference / use it from several parts of our code. This is a dependency between the client code and the code to be reused. Dependency is one of the strongest relationships between code and is always an important cost so you should have this in mind when evaluating whether we should eliminate duplicity or not.
  • We should always depend on artifacts that are more stable than ourselves, that is, if we extract common code to a library, but the API of this library changes all the time, this mean that we have created a bad/wrong abstraction and the maintaining cost will increase a lot.

In summary:

  • Is important not to have duplication for business concepts (low level duplicity is less important).
  • We should always evaluate the danger of creating a premature abstraction.
  • We should evaluate the trade offs between the cost of adding a new dependency vs the maintainability cost improvements derived from removing the duplication.
  • If readability is lost by eliminating duplicity, we are doing it wrong.
  • Is better to follow a process of use, use, reuse, and later create the abstraction (instead of directly creating the abstraction).

If you can't afford to wait before creating an abstraction or you can't eliminate/modify the abstraction once you detected that is not the correct one, your problem is that you are generating a great problem and worse complexity than the one generated by leaving a small duplicity.

Although the DRY principle may seem simple to understand, its application, as always in software development, is not simple or systematic.



Sunday, February 26, 2017

More interesting talks (teams, agile, others...)


From the talks I've seen lately, these are the most interesting.

Tuesday, February 21, 2017

Honey badger Team

One of the most impressive things about this last year is the great tech team generated at TheMotion. Another impressive thing is the platform, but it deserve another blog post...

When I arrived to TheMotion, I couldn’t say that the tech team had bad members, but the practices were not the best for the level of change and the scale required.

For example, some silos started to appear (front end, back end, video, etc), there was a tendency to generate feature branches that lived forever and the deployment and infrastructure was semi manual and without a good cadence for putting increments in production. For example, there were two environments, staging and production, and sometimes a feature could live in staging for more than a week before going to production.

Another “weird” practice was that the code was owned by only one developer, so there was some kind of “pipeline” for development for each feature that generate tons of integration work and coordination problems.

This was the starting line, but with some work, mentoring and sometimes being a little bit “radical” with the approach about agility, all of these practices and tech culture changed for the better.

From the beginning, the eagerness to learn and to make continuous improvements allows us to change our behaviour very deeply. You can have the fortune to work with very talented people, but if each one work individually and they are not aligned, the result can be worse than working with no so talented people that work as a team. So it was clear to me that the most important thing was to align all this talent to share a vision, practices and culture.

I think that having enough “mentoring power” for the size of the team is key. For example, I can myself teach some of the XP practices, but this is not enough when the team have ten members. To improve this, the collaboration of Modesto San Juan and Alfredo Casado from Carlos Ble y Asociados (now codesai) was key, because the message was clear and the impact of three persons focused on transmitting the practices was powerful enough to generate the change… It's always important to have critical mass and generate early adopters that helps to spread the change :-)



In parallel to introducing modern agile practices, there was another change going on… the generation of a high performance team. A team of people that trust each other, that want to learn together and that have no problems to have conflicts or propose different technical solutions… I can’t explain how we made this change, from a group to a team… I can only say that if you treat people as adults, try to help anyone and learn from others, the magic can happen. It is like being a gardener, you can plant flowers and take care of the environment (protecting the team, being an example of the change that you want, making the culture explicit, etc), nothing more, only water the garden.

In this case, the magic happened and the group growth to become a teama great development team, the Honey Badger team :-)



Right now, our practices include, continuous delivery (several times a day), TDD, simple design, immutable infrastructure, infrastructure as code, collective ownership and we work as a high performance team with our own identity and a high level of trust…. And this change only in 15 months…

Some of the actual Honey Badger team at https://www.themotion.com/about/