5 ms·

There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very defi

There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next cycle * process building fundamentals -- once you learned you need mechanisms to preserve the results. Checklists, templates, documentation, automation, infrastructure as code, etc. Everything else is result of the learning. As we go, we spot problems or improvement opportunities and we decide how to fix it together. A lot of these fixes come from agile literature. Nobody said you have to reinvent everything. But now that we have implemented it in response to our actual problem we know why it is there which is way better than just implementing it without understanding. Along the way people learn they have power to change things in a realistic way and not only they are welcome to do so but it is actually their job. Which is exactly the goal of all of this and yet completely missing when you put forward a book and say the process has to be implemented exactly as in the book.

davidthewatson 4y ago
Nothing has resonated more with the way I work than this. Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle. It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent. The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate. This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.
azangru 4y ago
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works) > improvement loop In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle. > once you learned you need mechanisms to preserve the results In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)
- Juliate 4y ago
  The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environments as the exact opposite.
  - azangru 4y ago
    If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when the same applies to scrum? Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.
    - marcus_holmes 4y ago
      > scrum is as good a place to start as any No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning. If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints". Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.

davidthewatson 4y ago

Nothing has resonated more with the way I work than this. Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle. It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent. The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate. This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.

azangru 4y ago

What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works) > improvement loop In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle. > once you learned you need mechanisms to preserve the results In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)

Juliate 4y ago
The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environments as the exact opposite.
- azangru 4y ago
  If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when the same applies to scrum? Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.
  - marcus_holmes 4y ago
    > scrum is as good a place to start as any No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning. If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints". Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.