4 ms·

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 mi

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

by dtech 5y ago

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.