Book Review: Por Un Scrum Popular: Notas para una Revolución Ágil

This post is in Spanish because the book is in Spanish and is not exactly a translation, it have a different content than the original.

Por Un Scrum Popular: Notas para una Revolución Ágil

Tobias Mayer (Autor), Alan Cyment  (Autor, Traductor)

La lectura de este libro me ha resultado de lo más sorprendente. El libro está compuesto de una serie de ensayos cortos de Tobias Mayer complementados por anexos creados por Alan Cyment. Con este formato se ha generado una especie de diálogo entre los dos autores, Tobias, como el autor original de los ensayos y Alan (de cierta manera uno de sus discípulos), como coautor y traductor.

Para cada ensayo Alan amplia la idea original, la pone al día o aporta nuevas ideas y en algunos casos incluso la enfrenta de forma constructiva.
Debido a este formato, el resultado es excelente, es muchísimo más que una traducción. Una gran idea.

En cuanto al contenido, para mi, este Scrum que describen es el esencial, el basado fuertemente en valores y cultura, el que habla de una forma distinta de trabajar a nivel de toda la empresa y no describe/prescribe un método de organización y gestión para equipos de desarrolladores.

Ni que decir tiene que estoy completamente alineado con el Scrum descrito por Tobias o por ese Scrum (orgánico) descrito por Alan en el que la reflexión en las retrospectivas y el timeboxing generan un marco para permitir que lo que sea necesario brote.
Cada uno de los ensayos nos puede aportar una profunda reflexión sobre cómo trabajamos y cómo nos relacionamos como organización.

Si buscas un libro que describa la mecánica de Scrum, este NO es el libro. Pero si conoces Scrum, consideras que somos personas incluso mientras trabajamos, este libro te puede hacer reflexionar, abrirte nuevas vías…

Un gran libro...

Recordando el descubrimiento de Scrum Orgánico

Después de interesarme por XP y por muchas de las prácticas técnicas, comencé a interesarme por Scrum, pero lo entendía como un método para organizar el equipo, con sus artefactos, y algunos principios pero secundarios. Pero no fue hasta que asistí al curso de Scrum Master impartido por Alan Cyment y Ariel Ber (Madrid Nov 2010) que mi mente no hizo el “Click” y comencé a entender el profundo cambio que requiere Scrum en la forma de trabajo. Cristalice todas estas ideas mientras Ariel nos ayudaba a introducir agilidad en el equipo de desarrollo de Scrum en Alea Soluciones.

Comencé a ver el trabajo como interaciones y relaciones entre personas y Scrum como un marco en el que de forma orgánica se podía mejorar esa forma de trabajar mediante el coraje, la comunicación y otros valores que nos reconociesen como personas completas y no como máquinas…

Con la lectura de “Por Un Scrum Popular: Notas para una Revolución Ágil” he recordado / revivido parte de los cambios en mi forma de trabajar e incluso de vivir que he ido realizando desde el 2010… poco a poco, experimentando, arriesgándome…

También me ha recordado que equivocado es olvidarse de las bases y la cultura y hacer cambios superficiales que no estén completamente alineados con lo que creemos.

Así que, no olvidemos, cada poco tiempo, revisitar nuestras convicciones de base, nuestro sistema operativo como comentan en Drive, experimentar, mejorarlo y continuar. :)

Gracias Alan, Ariel y tantos otros que me hacen pensar…

Relacionado

• http://www.eferro.net/2015/02/los-dos-pilares-del-desarrollo-agil-de.html
• http://www.eferro.net/2014/09/micro-nota-sobre-evolucion-de-mis-soft.html
• Interesante nuevo proyecto de Alan y Ariel  http://liqueed.org/index.html http://blog.agilar.org/2014/04/30/leancoops-first-draft/

Referencias:

• https://twitter.com/acyment
• https://twitter.com/berariel
• http://liqueed.org/index.html
• Drive Daniel H. Pink
• The People's Scrum
• Por un Scrum popular

Book Review: Understanding the Four Rules of Simple Design

Understanding the Four Rules of Simple Design

by Corey Haines

Great technical book with tons of distilled advice about software design. It is mainly focused design at a class level, but some of the advice can be extrapolated to a macro design level.
I enjoy a lot the book and it is easy to read and to understand, but it requires at least a medium level of OO design experience to learn from the content. Definitively not a entry level book.

The contents of the book come from the experience of Corey Haines hosting many code retreats. At this code retreats, the problem to solve is always the same (Conway's Game of Life), so Corey show lots of different designs for the same problem. Using this problem and code as a base, he explains the four rules of simple design proposed by Kent Beck in the initial XP book…

This book can help any developer to improve his designs skills and interiorize how to implement elegant and simple designs in his programs. Lot of wisdom.

Even the foreword from Kent Beck contains advices that are pure gold

Agile is not a recipe for success...

Post previously published in Spanish agilidad no es una receta para el exito

Agile is not a recipe for success, is a recipe for failure...
Fail fast, cheap and learning during the process... Agile will not avoid the failure, but it will help to avoid failing in the same way, at the same problem or using a ton of resources.

Agile assume the following:

• We will fail to estimate.
• We will fail to understand the customer's requests.
• We will fail to select technologies.
• The requirements will change (always).

So agile proposed:

• Estimate very small chunks (or no estimate at all).
• Deliver running systems to obtain feedback and adapt the system to the real need of the customer.
• Use agile practices to have under control the technical debt and to allow maintenance/evolution of the system with a reasonable cost.
• Maximize the amount of work not done.
• Create code with good quality to make very easy to adapt it to future changes.

And all of this using very fast/small cycles (timeboxing, iterations, continuous delivery), so even if we fail is very difficult that this failure generates a great problem.

And all this process reinforced with a continuous improvement process (with retrospectives and team improvements).

Embrace Failure

Embrace Change

Embrace Chaos

Why I use the term "software craftsman"

I like to think that I can consider myself a professional software developer after 20 years or working on it. Since some years ago I feel very aligned with agile software development movement and lately with the software craftmanship movement. I started to be interested in agile in 2002-2003 and in the software craftsmanship in 2012.
Currently when I try to describe myself I use the words “software craftsman” as an equivalent to “software developer, continuously trying to improve his skills and craft”.

Let me explain what I mean by “software craftsman”:

• I mean being professional as software developer
• Trying not only to create working code, trying to create simple, easy to maintain code.
• Trying not only to create the code that the business required, also trying to help the business to growth (with different solutions, even without using code). Adding steadily value to the business.
• In order to be a good professional there is a strong need to learn and improve our skills, tools and practices. Or even look for new ones.
• IMHO a good process for learning or improving ours skills is participating in the community of professional software developers. In this process the mentor / apprentice format works very well to improve our skills.

Why not using the “agile software developer” denomination?
In fact, for my, this definition can be a good option, but currently, the term agile is even more confuse that craftsmanship.

For me, at least in my experience, the development of applications and systems has more in common with a craft than with an engineering. Engineering is the application of mathematics, empirical evidence and scientific knowledge, so it is possible to plan, predict and control. IMHO software development for non trivial systems requires sense and respond and other approaches can derive in a false sense of control.

Some kind of software efforts are more adapted to a engineering approach (algorithms, compilers, software for science), but in my case, this is the exception, not the norm.

So, currently in my linkedin profile I indicate that I work as Software Craftsman… I also indicate that I work as a Shaman, but this is different history :-)

References:

• https://8thlight.com/blog/micah-martin/2008/09/21/definition-of-software-craftsman.html
• Curing Agile Hangover with Craftsmanship
• Software Craftsman Sandro Mancuso
• Apprenticeship Patterns
• Modern Agile

aws-sdk-go spikes and small examples

I am developing the initial support for aws checks for the library https://github.com/aleasoluciones/gochecks

gochecks library allow us at TheMotion and at AleaSoluciones to create programmatically highly concurrent monitoring apps.

This post is an autonote with the initial spikes created using the aws-sdk-go

aws_golang_examples