The Value of Caring Tasks in Our Environment

Added to Process

In this interview I had the great pleasure of speaking with Antonio de la Torre (Toño), who from his native Spain has been doing valuable technical mentoring for various companies.

Toño has been working for a long time at Codesai, a flat-hierarchy developer company with a passion for the technical side of Agility. He is a frequent speaker at conferences in his country and a very representative figure in the Software Craftsmen community.

He chose to speak about the value of the technical caring tasks in our environment, more specifically that code can be seen as a vital piece of an ecosystem that needs to be cared for and maintained in a sustainable way. Toño began by mentioning that the type of training and mentoring that they have been offering had been focusing on teaching TDD and automation of deployments, and in that way they realized that learning these practices require a large investment of time. Perceiving the value of all these technical practices is precisely the great cultural change that has to occur within companies, he said.

Preserving the ecosystem requires careful tasks and these tasks cover not only the code, but also the team, the product, and the company itself. According to Toño, taking care of the team, for example, produces a positive impact on the retention of talent, which in turn will positively impact the code, the product and the company.

Toño observed that, for example, delivery times are very tight and this ends up preventing developers from giving the necessary care and affection to the code. It is precisely these tight times that end up generating technical debt that must then be paid, but this is where the problem arises if companies do not invest in the care of their ecosystems, care that includes cleaning code that was done quickly and without affection.

Technical debt leads companies to also generate organizational debt that will eventually restrict their Agility. Using the metaphor of the ecosystem that Toño raises, if companies do not replant and take care of their ecosystem and only dedicate themselves to trying to harvest, then eventually their ecosystem will collapse causing damage to the same company.

One of the practices that Toño has used with his clients is to include caring tasks in the backlog, and to make the Product Owner and the company aware that 20% of the time of a Sprint should be invested in them. Another of the practices that he found very valuable comes from the ‘concerns’ raised in Consensus-Driven Development. These ‘concerns’ can be written down by any member of the team and then discussed, prioritized, and worked on by the team. ‘Concerns’ anticipate technical debt by acting before it is even introduced. The ‘concerns’ give rise to the caring tasks that are then entered in the backlog.

For Toño, ‘concerns’ are a way of continuous improvement, kaizen-style, that also promote decision-making in a flat hierarchy, since it is the developers themselves who decide which ‘concerns’ will become caring tasks and the order in which they will be worked.

In his experience, many times convincing companies to invest that 20% in caring tasks also has to do with breaking developers’ cultural paradigm, because they have become accustomed to advancing quickly due to pressure without paying much attention to code quality, and now they must slow down and put more care and affection in their code.

Once this cultural paradigm has been broken, the next step according to Toño is to invest in the knowledge of how to do good caring tasks. The last step would then be to resist the pressure and not end up regressing and returning to the old habits inherited from the cultural paradigm that is intended to change.

The final recommendation that Toño offered was to make visible the caring needs that the code has. The next step would then be to decide on a starting point to begin improving the code, an improvement that will eventually have a positive impact on the next functionality that passes through that piece of code.

About the Author

Juan es un capacitador, expositor y pensador alternativo. Desde que Juan se expuso a Scrum a principios del 2007 se comprometió a continuar aprendiendo y aplicando Scrum en los equipos y organizaciones donde trabajo. Su camino lo ha puesto en los roles de ScrumMaster, Scrum Trainer, y Product Owner. Juan cumplió el 2014 con todos los requisitos del Scrum Alliance para ser un Certified Scrum Trainer® (CST) y es ademas un LeSS Friendly Scrum Trainer.

Como CST y LeSS Friendly Scrum Trainer Juan ha entrenado a más de cuatro mil trescientos estudiantes en cursos de CLB, CSM, CSPO. A-CSM y A-CSPO en diez países del continente americano. Juan también a dado cursos privados para compañías como: Citibanamex, Marsh, Slalom, Deloitte, Walmart, CGI, SAIC, Express Scripts, T.Rowe Price, Time Warner Cable, ViaSat, Garmin, Moffitt, Kyva Systems, Blue Book Network, Insurance Auto Auctions and BlueCross BlueShield.

Juan fue miembro voluntario del Board de Directores del Agile Alliance donde sirvió por dos periodos consecutivos de tres años hasta el 2019.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.