Overall, this is a mixed bag. The general motivation and high-level concept is good, but even at the manifesto level some of the specific statements seem pretty bad.
Pros:
- General concept of leveraging asyncronous communication and minimizing disruptions to workflow; most organizations could probably benefit from considering this in their process improvement efforts, because its something that many don't do well,
- Preference for documented process (which is very important for team ownership of process and continuous bottom-up experimental and evidence-driven process improvement), and again its a place lots of organizations, of all types, seem to fall down on.
Cons:
- The idea that product owners can just assign priority; I think the best priority concept to come out of the agile tradition is that the product owner determines the value of a work item to a client, and the team estimates the effort of the item, and the priority is assigned in descending order of value/effort ratio.
- Related to the above, the idea that you can dispense with backlog grooming with no replacement. Backlog grooming is essential to get work properly divided into reasonably sized chunks (to avoid wasted effort on an improperly-scaled item) with independent value, and to assure that they are in a state ready to assess both independent value of the chunks and the work effort associated with them to set priority.
- Related to both of the above, the idea of skipping planning meetings, which aren't frequent so as to pose significant flow barriers, and for which (aside from shifting things that require the input of the team to being done without input by the PO) the manifesto provides no real alternative.
- skipping daily standups (proper daily standups should be scheduled so as not to be interruptions in workflow, and are designed to enable flow, not impede it, but providing both an important venue to address barriers and by constraining the disruption to other people that trying to do so by broadcast rather than regularly scheduled brief meetings would impose.)
- (mostly tangential, but, hey, its false and its right up at the top) the premise that "Scrum" (a top-down defined process-over-people-do-it-by-the-prescribed-Scripture-as-interpreted-by-your-centrally-Certified ScrumMaster®-or-you're-doing-it-wrong methodology) is implementation of Agile, which prioritizes, as the first element of the Agile Manifesto, people and interactions over processes and tools, is, while popular, dead wrong. Lots of the things in the Scrum guide are things that Agile organizations have found work for them and so do -- but Scrum is pretty much the opposite of Agile, and is the exact kind of packaged one-size-fits-all solution that the Agile Manifesto was a reaction against.
Pros:
- General concept of leveraging asyncronous communication and minimizing disruptions to workflow; most organizations could probably benefit from considering this in their process improvement efforts, because its something that many don't do well,
- Preference for documented process (which is very important for team ownership of process and continuous bottom-up experimental and evidence-driven process improvement), and again its a place lots of organizations, of all types, seem to fall down on.
Cons:
- The idea that product owners can just assign priority; I think the best priority concept to come out of the agile tradition is that the product owner determines the value of a work item to a client, and the team estimates the effort of the item, and the priority is assigned in descending order of value/effort ratio.
- Related to the above, the idea that you can dispense with backlog grooming with no replacement. Backlog grooming is essential to get work properly divided into reasonably sized chunks (to avoid wasted effort on an improperly-scaled item) with independent value, and to assure that they are in a state ready to assess both independent value of the chunks and the work effort associated with them to set priority.
- Related to both of the above, the idea of skipping planning meetings, which aren't frequent so as to pose significant flow barriers, and for which (aside from shifting things that require the input of the team to being done without input by the PO) the manifesto provides no real alternative.
- skipping daily standups (proper daily standups should be scheduled so as not to be interruptions in workflow, and are designed to enable flow, not impede it, but providing both an important venue to address barriers and by constraining the disruption to other people that trying to do so by broadcast rather than regularly scheduled brief meetings would impose.)
- (mostly tangential, but, hey, its false and its right up at the top) the premise that "Scrum" (a top-down defined process-over-people-do-it-by-the-prescribed-Scripture-as-interpreted-by-your-centrally-Certified ScrumMaster®-or-you're-doing-it-wrong methodology) is implementation of Agile, which prioritizes, as the first element of the Agile Manifesto, people and interactions over processes and tools, is, while popular, dead wrong. Lots of the things in the Scrum guide are things that Agile organizations have found work for them and so do -- but Scrum is pretty much the opposite of Agile, and is the exact kind of packaged one-size-fits-all solution that the Agile Manifesto was a reaction against.