5 ms·

Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ https://agilemanifesto.org/ and https://agilemanifesto.org/princi

Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html The problem is people take the main points and use them to justify their own wants and needs. These are the main points: * Individuals and interactions over processes and tools This does not say you should not have any processes and tools. * Working software over comprehensive documentation The problem with this is you now have people who don't like writing documentation claiming that agile says "You shouldn't write any documentation" or "I don't need to comment my code as the agile manifesto says you shouldn't"... * Customer collaboration over contract negotiation This does not say "you should not have a contract". * Responding to change over following a plan People interpret this as "We shouldn't plan anything. If you are planning then you aren't doing agile".

dtech 5y ago
It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.
- xondono 5y ago
  * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… I know a lot of people don’t consider it this way, but the backlog IS documentation. The second most popular tool after Jira in Scrum teams is drumroll Confluence. * Contract negotiation: Scrum defines a specific role (PO) with the main task of handling contract negotiations. * Responding to change: Even the tools will complain if you change things mid sprint (because you’ll ruin the all important metrics!).
  - iamflimflam1 5y ago
    https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile", or specifically "Dark Scrum". This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird.
  - tsimionescu 5y ago
    > And then you grab any Scrum guide and you’ll see: > * roles and processes: (Scrum master, product owner,…) > * tools: Scrum now is almost synonymous with Jira. > * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… This is all perfectly in line with the Agile manifesto, as long as teams are empowered to customize all of them as they see fit. For example, if the team decides that for them long daily scrums that are also an opportunity for code review is better, and so they spend 1h every day doing mostly code reviews during the daily scrum and are happy and productive with this, perfect: we valued people and communication over processes and tools. If, conversely, they get told that Daily Scrum must be a stand-up meeting taking 15 minutes or less, then they're not actually being Agile (someone is valuing the Scrum process more than people and communication). Any team of people will follow a process and use some tools to do so. Scrum is a half decent starting point for a team moving to Agile, as are Kanban or XP or others. Ultimately you have to start with some process, then keep tweaking until the team, management, customers etc are all happy. Having no process at all (how do we decide if we should work on X?) is a tool for disaster. Having a very rigid process (don't talk to Jim directly, wait till Daily Scrum), or following tools slavishly (I can't work on this until you log a ticket and pull it in the sprint), is as well.
dstroot 5y ago
https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/
- corpMaverick 5y ago
  Now I am curious about the background image. And a little disappointed that there is no principle page.
- ChrisMarshallNY 5y ago
  I love that! Thanks for sharing it! - A refugee from the Corporate Machine

dtech 5y ago

It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.

xondono 5y ago
* Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… I know a lot of people don’t consider it this way, but the backlog IS documentation. The second most popular tool after Jira in Scrum teams is drumroll Confluence. * Contract negotiation: Scrum defines a specific role (PO) with the main task of handling contract negotiations. * Responding to change: Even the tools will complain if you change things mid sprint (because you’ll ruin the all important metrics!).
- iamflimflam1 5y ago
  https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile", or specifically "Dark Scrum". This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird.
- tsimionescu 5y ago
  > And then you grab any Scrum guide and you’ll see: > * roles and processes: (Scrum master, product owner,…) > * tools: Scrum now is almost synonymous with Jira. > * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… This is all perfectly in line with the Agile manifesto, as long as teams are empowered to customize all of them as they see fit. For example, if the team decides that for them long daily scrums that are also an opportunity for code review is better, and so they spend 1h every day doing mostly code reviews during the daily scrum and are happy and productive with this, perfect: we valued people and communication over processes and tools. If, conversely, they get told that Daily Scrum must be a stand-up meeting taking 15 minutes or less, then they're not actually being Agile (someone is valuing the Scrum process more than people and communication). Any team of people will follow a process and use some tools to do so. Scrum is a half decent starting point for a team moving to Agile, as are Kanban or XP or others. Ultimately you have to start with some process, then keep tweaking until the team, management, customers etc are all happy. Having no process at all (how do we decide if we should work on X?) is a tool for disaster. Having a very rigid process (don't talk to Jim directly, wait till Daily Scrum), or following tools slavishly (I can't work on this until you log a ticket and pull it in the sprint), is as well.

dstroot 5y ago

https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/

corpMaverick 5y ago
Now I am curious about the background image. And a little disappointed that there is no principle page.
ChrisMarshallNY 5y ago
I love that! Thanks for sharing it! - A refugee from the Corporate Machine