Pensándolo de una manera amplia, tener "equipos de desarrolladores" es equivalente a crear equipos de "vendedores" o de "torneros".
Lo que no es lo mismo que crear "equipos de desarrollo", que tienden a ser multidisciplinarios. Eso abre un poco más la idea del ciclo de vida completo o el "End 2 End" como se le suele llamar, contenido en el equipo completo.
TOSD va un poco más allá: donde no necesites equipos, no los crees. Hacerlo puede burocratizar de manera muy penosa la creación de valor y la entrega en tiempo.
Fascinating; I've never heard of this term before. What's surprising to me, is that we at Peerdom (software company, Switzerland) naturally gravitated towards this model because we simply couldn't afford management or bureaucracy. Which begs the (suggestive) question: Why should a company ever want to afford management or bureaucracy when there are models working without it?
Why would companies stay in command-and-control mode (a.k.a. "management") and NOT move to decentralized & democratic? I have written a lot about that, in several books, and on my Substack, for example.
The term TOSD. It looks like I‘ve been living under a stone for too long, not knowing this approach and term for it. Thanks for communicating it to the public!
You are confusing repeatable work with incremental work.. if you know exactly what you're building and exactly how you're going to build it, you dont need Scrum or Sprints. You can just do away with lean.
Thanks Niels, I'm eager to learn where my understanding is wrong.. upon re-reading my earlier comment, I realize it sounds argumentative.. I'd like to rephrase:
In my understanding, in production systems, for mass manufacturing we don't need a time-box as it's the same repeatable process, regardless of the batch size. However we do need it at the prototype stage where we know we want a certain result, but yet to figure out the how through iterative and incremental development. There the time boxing helps us inspect and adapt at frequent intervals.
Hi Dav. Thank you for reframing. We really won't get anywhere if we exchange messages telling each the other that we are wrong. So thank you for moving beyond that. I appreciate it.
From what you are writing, I am not sure anymore if you are interested in "production" (industry/manufacturing) or software development.
Here, we should maybe stick with the topic you are actually interested in. Otherwise the topic becomes too complicated to handle in a thread like this, I think.
Scrum is an artefact of its time when teams were scattered across buildings and the physics of knowledge work, while known among software engineers like Fred Brooks Jr. wasn't anywhere nearly as well appreciated as it is now.
I have found it useful to explain to my coachees and customers how Scrum can be better-understood as a management hack to make software delivery possible when you have no intention of changing anything in management writ large.
Nobody is going to be totally happy and there will be loads of trade-offs, but maybe one day an epiphany will happen and things like flow will make sense.
This is why I always recommend starting a transformation with Deming to help focus on what matters...
Put simply, you can adopt a Scrum stance and not have to change anything in the systems of management that created the need for Scrum in the first place. That's why it always has muted success wherever it's tried.
I understand that are trying to say "first change the system then bring in Scrum", instead of "Scrum is conceptually flawed (like batch processing) and can never work", which is what I am saying in my article.
I figure that you didn't care to read my article. Fine by me. But then why comment on it here?
Niels, I read your article and I think we're in vehement agreement. I'm just coming at your argument from a different angle. It's like Ackoff's observation of what an orange looks like and how it depends whether you cut around the circumference or pole-to-pole. You see the same orange, just from different perspectives.
Pensándolo de una manera amplia, tener "equipos de desarrolladores" es equivalente a crear equipos de "vendedores" o de "torneros".
Lo que no es lo mismo que crear "equipos de desarrollo", que tienden a ser multidisciplinarios. Eso abre un poco más la idea del ciclo de vida completo o el "End 2 End" como se le suele llamar, contenido en el equipo completo.
TOSD va un poco más allá: donde no necesites equipos, no los crees. Hacerlo puede burocratizar de manera muy penosa la creación de valor y la entrega en tiempo.
Fascinating; I've never heard of this term before. What's surprising to me, is that we at Peerdom (software company, Switzerland) naturally gravitated towards this model because we simply couldn't afford management or bureaucracy. Which begs the (suggestive) question: Why should a company ever want to afford management or bureaucracy when there are models working without it?
Why would companies stay in command-and-control mode (a.k.a. "management") and NOT move to decentralized & democratic? I have written a lot about that, in several books, and on my Substack, for example.
Thanks for commenting. What do you mean by "this term"?
For more about Time-Oriented Software Development (TOSD), visit http://www.timeoriented.dev
The term TOSD. It looks like I‘ve been living under a stone for too long, not knowing this approach and term for it. Thanks for communicating it to the public!
Well, we only created the concept this year and we published it in October - together with the BetaCodex Network research paper: https://betacodex.org/white-papers/paper/introducing-time-oriented-software-development-26
So Time-Oriented Software Development (TOSD) is REALLY new. It's certainly not you having missed out on it before!
Can't wait to dig deeper into this! I can only thank again for sharing all this work and research.
You are confusing repeatable work with incremental work.. if you know exactly what you're building and exactly how you're going to build it, you dont need Scrum or Sprints. You can just do away with lean.
Thank you for commenting, Dav. You are confusing things, as your use of the distinction between "repeatable and incremental" indicates.
But don't mind. We do not have to agree.
Thanks Niels, I'm eager to learn where my understanding is wrong.. upon re-reading my earlier comment, I realize it sounds argumentative.. I'd like to rephrase:
In my understanding, in production systems, for mass manufacturing we don't need a time-box as it's the same repeatable process, regardless of the batch size. However we do need it at the prototype stage where we know we want a certain result, but yet to figure out the how through iterative and incremental development. There the time boxing helps us inspect and adapt at frequent intervals.
Hi Dav. Thank you for reframing. We really won't get anywhere if we exchange messages telling each the other that we are wrong. So thank you for moving beyond that. I appreciate it.
From what you are writing, I am not sure anymore if you are interested in "production" (industry/manufacturing) or software development.
I have recently written in detail about abandoning "batches" and capacity thinking in both industry/manufacturing/production https://betacodex.org/white-papers/paper/slave-to-the-rhythm-get-to-time-oriented-work-systems-fast-24 and in software development https://betacodex.org/white-papers/paper/introducing-time-oriented-software-development-26
Here, we should maybe stick with the topic you are actually interested in. Otherwise the topic becomes too complicated to handle in a thread like this, I think.
Appreciate your response. Great article by the way, thanks for sharing.
Scrum is an artefact of its time when teams were scattered across buildings and the physics of knowledge work, while known among software engineers like Fred Brooks Jr. wasn't anywhere nearly as well appreciated as it is now.
I have found it useful to explain to my coachees and customers how Scrum can be better-understood as a management hack to make software delivery possible when you have no intention of changing anything in management writ large.
Nobody is going to be totally happy and there will be loads of trade-offs, but maybe one day an epiphany will happen and things like flow will make sense.
This is why I always recommend starting a transformation with Deming to help focus on what matters...
Thank you for commenting.
What are you trying to say, with regards to software development? I cannot make sense of what you wrote.
Put simply, you can adopt a Scrum stance and not have to change anything in the systems of management that created the need for Scrum in the first place. That's why it always has muted success wherever it's tried.
I understand that are trying to say "first change the system then bring in Scrum", instead of "Scrum is conceptually flawed (like batch processing) and can never work", which is what I am saying in my article.
I figure that you didn't care to read my article. Fine by me. But then why comment on it here?
Niels, I read your article and I think we're in vehement agreement. I'm just coming at your argument from a different angle. It's like Ackoff's observation of what an orange looks like and how it depends whether you cut around the circumference or pole-to-pole. You see the same orange, just from different perspectives.