I’m coming back to this technical user story which like chewing gum seems to have stuck to several people’s shoes. I’m bouncing off a few twitter conversations and Damien’s article who was kind enough to respond to me and reference my previous article. And what’s more, potentially proposes a roundtable / workshop-debate at agile france 2013 on the subject (I don’t know if that will happen).
I’ll remind you of something fundamental: what I present is my opinion today. I try to explain it, to confront it. I can be wrong. I can be wrong often. I can change my mind, I can not change my mind. Etc. etc.
KISS of thought
In my way of approaching subjects I try to respect the “KISS of thought”. Keep it simple stupid. This agile motto means quite simply, and you’ve understood: that in my opinion, to get through it, we must succeed in synthesizing simple thinking (KISS is generally used for code, hence the analogy). Simple thinking isn’t thinking simply, it’s bringing thought back to a simple aesthetic, to an elegant conceptualization, but not in the refined sense, in the stripped down, streamlined sense. It’s the only way to evolve healthily in our complex world it seems to me. If we arrive with a complicated thought system, we drown. In any case, that’s my case. I must lack the equipment.
In short, it’s perhaps mainly because of the “KISS of thought” that I differ a bit from my companions (Damien, Claude, etc.). Where they seek in good faith solutions, openings, alternatives, I refuse to, or at least I try to respond differently.
Deviations for deviations
Damien mentions projects with significant technical debt (which we all unfortunately encounter). He thus invokes the necessity under cover of benefits of refactoring user stories aka technical ones. But the refactoring is heavy there! and it couldn’t have been anticipated (there I ask to see despite everything… and what about refactoring throughout dev?). I don’t want to justify deviations (technical user story) by deviations (we have enormous technical debt), otherwise it’s the beginning of the end.
Yes but Pablo, we’re stuck so what?
- I’ll remind you of what I wrote previously
- you can do technical user stories on the condition that it itches you, scratches you, and that you question yourself so that it doesn’t happen again in the future or is greatly diminished.
In the case of the very large project requiring refactoring mentioned by Damien in a KISS perspective and to go all the way with the approach: make refactoring the heart of the project. The project is nothing more than a technical project. Its business has become the technical. Satisfying the PO and stakeholders is refactoring.
It’s not cheating, it’s thinking differently. Either we don’t include technical user stories in a backlog, or we decide that the entirety of the project is technical. KISS. The other solutions are confessions of learning, of failure, stopgaps (and that’s not a drama either… for goodness sake). The other solutions will teach you to “learn wrong”, to “think wrong”.
Naturally I’m not for this solution. My experience makes me think that reviewing a huge application purely technically is often doomed to failure (note for readers: I’m often wrong). It’s not the thinking, the agile culture, in my eyes. Better in my eyes: we take back, iteratively, an application, and therefore technical user stories don’t exist and the technical question is treated under cover of functional aspects. In the end I don’t change my opinion :)
Long term and ROI
I quote Damien: “The PO’s role isn’t to satisfy users. It’s to maximize the return on investment of the product. The difference, for me, lies on two levels: taking into account all the project stakeholders, on the one hand, and taking the long term into account on the other hand”.
Long term and ROI to justify technical user stories? I don’t understand.
Naturally technical aspects must take these objectives into account. How does that justify technical user stories? No I don’t understand. On the contrary I insist on the freedom that is thus given to technical aspects by freeing them from the burden of justification: a user story is business BUT you are the technical guardians of technological relevance, its continual updating (refactoring), and its scalability, etc. The technical user story is dead, long live the technical!
No tyranny
Sorry David, I failed. I didn’t put FUN in my post. But I get the impression you’re digging your heels in based on your “tech” suffering. I don’t want to, can’t, convince you. I’m just telling you that from my experience (what I’ve lived through) this approach is experienced as a liberation and a reappropriation of a real status for devs/techs, etc. There must not be tyranny of the business and there must not be tyranny of the technical. It’s almost ultimately the best justification for that unloved scrummaster.
This “fear”, “frustration”, “disgust” that you describe, I’ve also encountered it in the “opposing camp” (the business). So once again: There must not be tyranny of the business and there must not be tyranny of the technical. Everyone has their place in this ecosystem.
However, we’ll settle this over an arm wrestle at agile open sud.
A few tweets with JB whose content I’ve taken up above. The link he mentions from Jim Highsmith. For me we’re exactly in the justification of deviations by other deviations. We need to take the problems at their source, quite simply. So Jim Highsmith’s arguments, yes… but no. He’s right, but that’s not our subject. He describes deviations. I describe my mode of thinking (agile I hope).