As far as I am concerned, everything you need to know about agile is on this page: https://agilemanifesto.org/
So looking at this:
> After spending more than a decade wrestling with it - I still haven't figured out how quality assurance and test fits into the same iteration in Agile. Most teams I inherit have non-technical QA resources. Most projects I inherit have complex business logic and integration needs that aren't easily testable until some state of development "done" has been achieved. And time and time again I find myself staggering their effort slightly behind development so that test and development resources aren't taking turns sitting on their asses waiting for the other side.
That sounds like you're following "Individuals and interactions over processes and tools" and "Responding to change over following a plan" quite well. The "QA while you develop" process wasn't working for the skillset of the individuals on your team, and so you prioritized the individuals over the process, and responded to the change of understanding instead of following the plan you now knew was bad.
So, public admonishment of Agile Manifesto signatories be damned, you were doing agile, and anyone (including Agile Manifesto signatories) who tells you otherwise can be told to go read the Agile Manifesto as many times as they need to in order to reach enlightenment.
The problem is, money ruins everything.
Once you sign your name to the Agile Manifesto and the Agile Manifesto becomes famous, the tendency is to try to capitalize on that. And the ways you capitalize on it is by pretending you hold some special knowledge that you can teach in a workshop or give a certificate in it.
However, the Agile Manifesto isn't some special knowledge. It's admirable because it articulated an important set of ideals succinctly and clearly, but it's really not anything that a moderately intelligent developer doesn't intuit with enough experience, even if they can't so clearly articulate it. And you can't really teach it in a workshop or give a certificate in it, because the application is different for every team. The way you apply agile is by getting intimately familiar with the individuals involved in the team and slowly adapting the process to fit their needs: you can't choose individuals and interactions over processes and tools if you don't know what the individuals and interactions are. The agile manifesto may be about individuals and interactions over processes and tools, but processes and tools are a lot easier to sell.
This means that even if you came across the Agile Manifesto and really grokked it, and maybe even signed your name to it, you've got a powerful incentive to then go forget everything you've learned.
In a broader sense, this is why ideas have to be evaluated on their own, irrespective of who those ideas came from. Ideas can be perfect--humans can't.
Great point. Agile is what is in the manifesto, including the agile principles. Everything else is people interpreting to match their agenda. i.e. Sell consulting services, stay in the top of the food chain, etc.
As far as I am concerned, everything you need to know about agile is on this page: https://agilemanifesto.org/
So looking at this:
> After spending more than a decade wrestling with it - I still haven't figured out how quality assurance and test fits into the same iteration in Agile. Most teams I inherit have non-technical QA resources. Most projects I inherit have complex business logic and integration needs that aren't easily testable until some state of development "done" has been achieved. And time and time again I find myself staggering their effort slightly behind development so that test and development resources aren't taking turns sitting on their asses waiting for the other side.
That sounds like you're following "Individuals and interactions over processes and tools" and "Responding to change over following a plan" quite well. The "QA while you develop" process wasn't working for the skillset of the individuals on your team, and so you prioritized the individuals over the process, and responded to the change of understanding instead of following the plan you now knew was bad.
So, public admonishment of Agile Manifesto signatories be damned, you were doing agile, and anyone (including Agile Manifesto signatories) who tells you otherwise can be told to go read the Agile Manifesto as many times as they need to in order to reach enlightenment.
The problem is, money ruins everything.
Once you sign your name to the Agile Manifesto and the Agile Manifesto becomes famous, the tendency is to try to capitalize on that. And the ways you capitalize on it is by pretending you hold some special knowledge that you can teach in a workshop or give a certificate in it.
However, the Agile Manifesto isn't some special knowledge. It's admirable because it articulated an important set of ideals succinctly and clearly, but it's really not anything that a moderately intelligent developer doesn't intuit with enough experience, even if they can't so clearly articulate it. And you can't really teach it in a workshop or give a certificate in it, because the application is different for every team. The way you apply agile is by getting intimately familiar with the individuals involved in the team and slowly adapting the process to fit their needs: you can't choose individuals and interactions over processes and tools if you don't know what the individuals and interactions are. The agile manifesto may be about individuals and interactions over processes and tools, but processes and tools are a lot easier to sell.
This means that even if you came across the Agile Manifesto and really grokked it, and maybe even signed your name to it, you've got a powerful incentive to then go forget everything you've learned.
In a broader sense, this is why ideas have to be evaluated on their own, irrespective of who those ideas came from. Ideas can be perfect--humans can't.