Introduction
We’d like to tell you about a narrative that has been very useful for us in the coaching work we have been doing with several teams during the last year.
Origin
It all started during a consultancy work that Joan Valduvieco and I did at the beginning of 2019 at Trovit. José Carlos Gil and Edu Mateu had brought us to help Trovit's B2B team. We spent a week with the team asking questions, observing their work and doing some group dynamics to try to understand how we might help them.
After that week of "field work" we had gathered a ton of notes, graphs and insights that we needed to put in order and analyze. This is always a difficult task because it is about analyzing a sociotechnical system (team, knowledge, technology, existing code, organization, pressure, changes,...) which is a complex system in constant flux. In a way, you have to accept that this is something you can't wholly understand, and even less in a short period of time.
Having that in mind, we tried to do our best to get a first approximation by representing the different dynamics and processes we had observed in several causal loop diagrams. This work helped us clarify our minds and highlight how habits, knowledge, beliefs, culture and practices were creating vicious cycles, (related to some positive feedback loops in the causal loop diagram[1]), that were amplifying and preserving destructive effects for the team and its software which made their system less habitable and sustainable, and created inefficiencies and loss of value.
After that we started to think about strategies that might break those vicious cycles, either by reducing the effect of some node (a problematic habit, practice or belief), by removing an interaction between nodes in a positive loop, or introducing negative feedback in the system (new practices and habits) to stabilize it.
Donella H. Meadows in her book Thinking in Systems: A Primer talks about different types of leverage points which are places within a complex system where you can try to apply what we call change levers to make the system evolve from its current dynamics into another that might be more interesting for the team.
We detected several change levers that might be applied to the system at different leverage points to improve the sustainability of the system, such as, "Improving Technical Skills", "Knowledge Diffusion", "Knowledge Crystallization", "Changing Habits", "All Team Product Owning" or "Remote First"[2].
All of them attacked vicious cycles that were entrenched in the team's dynamics, and were valuable in themselves, but we were not sure that they would be enough to change the system's current dynamics. Something that we observed during our field work was that the team was very skeptical about the probabilities of success of any initiative to improve its situation. They had gone through several failed attempts of "Agile" transformation before, and this has left them in a kind of state of learned helplessness. Why had those previous attempts failed? Would ours succeed using our change levers?
We started to realize that there was a deeper force at play that was exacerbating the rest of the problems and would reduce the effect of any of the other change levers. We realized that they would be useless unless the team had enough slack and company support to apply them. The deeper and stronger force that was inhibiting the possibility of having that slack and support was the very conception of what value meant for the company, it was a cultural problem.
We then came up with a new change lever: "Redefinition of Value". This was the most powerful change lever of all the ones we had detected because it was a cultural change[3], and it would increase the probabilities of success of all other change levers. Being a cultural change also made it the most difficult to apply.
Redefinition of Value
What was this "Redefinition of Value" change lever about?
The culture of the team was understanding value only as producing features for their clients as quickly as possible. This definition of value only includes certain kinds of tasks, the ones that directly produce features, but excludes many tasks that don't directly produce features, but that are necessary for the sustainability of the system (the business and team) itself. The first kind of work is called productive work and the second kind is called caring work[4].
Believing that only one type of work has value, (productive work), and then focusing only on that type of work is an extractive micro-optimization that might end destabilizing the system[5].
The redefinition of value we proposed was that not only producing features for the client as quickly as possible is valuable, that there is also value in keeping the sustainability of the business and team. Aside from working on productive tasks, you need to devote energy and time to work on caring tasks which are concerned with keeping the health of the ecosystem composed of the code, the team and the client, so that it can continue evolving, being habitable for the team and producing value. We think that this kind of work (caring work) has value and is strategic for a company. If you think about it, at the bottom, this is about seeing the team as the real product and establishing a healthier and more durable relationship with clients.
This idea of caring work comes from economic studies from a gender perspective. In feminist economics caring work is defined as, "those occupations that provide services that help people develop their capabilities, or the ability to pursue the aspects of their lives that they value" or "necessary occupations and care to sustain life and human survival".
We thought that for this redefinition of value to be successful, it needed to be stated very clearly to the team from above. This clarity is crucial to avoid the developers having to solve the conflicts that arise when the value of caring tasks is not clear. In those cases, it's often caring work which gets neglected.
Those conflicts are actually strategic and, as such, they should be resolved at the right level so that the team receives a clear message that gives them focus, and the peace of mind that they are always working in something that is really valued by the company.
In many companies the value of caring only appears in company statements (corporate language), but it's not part of the real culture, the real system of values of the company. This situation creates a kind of doublespeak that might be very harmful. A way to avoid that might be putting your money where your mouth is.
So with all these ingredients we cooked a presentation for the team lead, the CTO and the CPO of the company[6], to tell them the strategy we would like to follow, the cultural change involved in the redefinition of value that we thought necessary and how we thought that the possible conflicts between the two types of work should be resolved at their level. They listened to us and decided to try. They were very brave and this decision enabled a wonderful change in the team we started to work with[7]. The success of this experiment made it possible for other teams to start experimenting with this redefinition of value as well.
Is this not the metaphor of technical debt in a different guise?[8]
We think that the narrative of caring work, it’s not equivalent to technical debt.
The technical debt metaphor has evolved a lot from the concept that Ward Cunningham originally coined. With time the metaphor was extended to cover more than what he initially meant[9]. This extended use of the metaphor has been criticized by some software practitioners[10]. Leaving this debate aside, let’s focus on how most people currently understand the technical debt metaphor:
“Design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal systems qualities - primarily, but not only, maintainability and evolvability.” from Managing Technical Debt: Reducing Friction in Software Development
Technical debt describes technical problems that cause friction in software development and how to manage them.
On the other hand, the caring work narrative addresses the wider concern of sustainability in a software system, considering all its aspects (social, economic and technical), and how both productive and caring work are key to keep a sustainable system. We think that makes the caring work narrative a wider concept than technical debt.
This narrative has created a cultural shift that has allowed us not only to manage technical debt better, but also to create room for activities directed to prevent technical debt, empower the team, amplify its knowledge, attract talent, etc. We think that considering caring work as valuable as productive work placed us in a plane of dialogue which was more constructive than the financial metaphor behind technical debt.
How are we applying it at the moment?
Applying the caring work narrative depends highly on the context of each company. Please, do not take this as a “a recipe for applying caring work” or “the way to apply caring work”. What is important is to understand the concept, then you will have to adapt it to your own context.
In the teams we coach we are using something called caring tasks (descriptions of caring work) along with a variation of the concerns mechanism[11] and devoting percentages of time in every iteration to work on caring tasks. The developers are the ones that decide which caring work is needed.
These decisions are highly contextual and they involve trade offs related to asymmetries initially found in each team and in their evolution. There are small variations in each team, and the way we apply them in each team has evolved over time. You can listen about some of those variations in the two podcasts that The Big Branch Theory Podcast will devote to this topic.
We plan to write in the near future another post about how we are using the concerns mechanism in the context of caring work.
Conclusions
We have been using the redefinition of value given by the caring work for more than a year now. Its success in the initial team made it possible for other teams to start experimenting with it as well. Using it in new teams has taught us many things and we have introduced local variations to adapt the idea to the realities of the new teams and their coaches.
So far, it’s working for us well and we feel that it has helped us in some aspects in which using the technical debt metaphor is difficult like, for example, improving processes or owning the product.
Some of the teams worked only on legacy systems, and other teams worked on both greenfield and legacy systems (all the legacy systems had, and still have, a lot of technical debt).
We think it is important to consider that the teams we have been collaborating with were in a context of extraction[12] in which there is already a lot of value to protect.
Due to the coronavirus crisis some of the teams have started to work on an exploration context. This is a challenge and we wonder how the caring work narrative evolves in this context and a scarcity scenario.
To finish we’d like to add a quote from Lakoff[13]:
“New metaphors are capable of creating new understandings and, therefore, new realities”
We think that the caring work narrative might help create a reality in which both productive and caring work are valued and more sustainable software systems are more likely.
Acknowledgements
Thanks to Joan Valduvieco, Beatriz Martín and Vanesa Rodríguez for all the stimulating conversations that lead to the idea of applying the narrative of caring work in software development.
Thanks to José Carlos Gil and Edu Mateu for inviting us to work with Lifull Connect. It has been a great symbiosis so far.
Thanks to Marc Sturlese and Hernán Castagnola for daring to try.
Thanks to Lifull's B2B and B2C teams and all the Codesai colleagues that have worked with them, for all the effort and great work to take advantage of the great opportunity that caring tasks created.
Finally, thanks to my Codesai colleagues and to Rachel M. Carmena for reading the initial drafts and giving me feedback.
Notes
[1] Positive in this context does not mean something good. The feedback is positive because it makes the magnitude of the perturbation increase (it positively retrofeeds it).
[2] Those were the names we used when we presented what we have learned during the consultancy.
[3] In systems thinking a leverage point is a place within a complex system (a corporation, an economy, a living body, a city, an ecosystem) where a shift can be applied to produce changes in the whole system behavior. It would be a low leverage point if a small shift produces a small behavioral change. It's a high leverage point if a small shoif causes a large behavioral change. According to Donella H. Meadows the most effective place to intervene a system is:
“The mindset or paradigm out of which the system — its goals, power structure, rules, its culture — arises”.
As you can imagine this is the most difficult thing to change as well. To know more read Leverage Points: Places to Intervene in a System.
[4] Also known as reproductive work. This idea comes from a gender perspective of economics. You can learn more about it reading the
Care work and Feminist economics articles in Wikipedia.
[5] Sadly we observe this phenomena at all scales: a business, a relationship, an ecosystem, the planet...
[6] Edu Mateu, Marc Sturlese and Hernán Castagnola were then the B2B team lead, the CTO and the CPO, respectively.
[7] B2B was the first team we worked with. Fran Reyes and I started coaching them in February 2019 but after a couple of months Antonio de la Torre and
Manuel Tordesillas joined us. Thanks to their great work of this team, other teams started using the caring work narrative around 6 month after.
[8] Thanks to Fran Reyes and Alfredo Casado for the interesting discussions about technical debt that helped me write this part.
[9] You can listen Ward Cunningham himself explaining what he actually meant with the technical debt metaphor in this video.
[10] Two examples: A Mess is not a Technical Debt by Robert C. Martin and Bad code isn't Technical Debt, it's an unhedged Call Option by Steve Freeman.
[11] The concerns mechanism is described by Xavi Gost in his talk CDD (Desarrollo dirigido por consenso).
[12] To know more watch 3X Explore/Expand/Extrac by Kent Beck or read Kent Beck’s 3X: Explore, Expand, Extract by Antony Marcano and Andy Palmer.
[13] From Metaphors We Live By by George Lakoff and Mark Johnson.
References
Books
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Tom Demarco
Patterns of Software: Tales from the Software Community, Richard P. Gabriel
Filters against Folly: How to Survive despite Economists, Ecologists, and the Merely Eloquent, Garrett Hardin
Managing Technical Debt: Reducing Friction in Software Development, Philippe Kruchten, Robert Nord, Ipek Ozkaya
Articles
Leverage Points: Places to Intervene in a System
, Donella H. MeadowsPositive feedback (or exacerbating feedback) (Wikipedia)
Leverage points places to intervene in a system (Wikipedia)
Twelve leverage points (Wikipedia)
Care work (Wikipedia)
Feminist economics (Wikipedia)
System Dynamics (Wikipedia)
Causal loop diagram (Wikipedia)
Bad code isn't Technical Debt, it's an unhedged Call Option, Steve Freeman
Kent Beck’s 3X: Explore, Expand, Extract,
Antony Marcano, Andy Palmer
Top comments (0)