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!
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.
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.