Hacker News Reader

Hacker News

Comment by iamflimflam1 | Hacker News Reader

Parent Full thread

iamflimflam1

Indeed - the principals of the manifesto are very easy to read:

https://agilemanifesto.org/

and

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

View on HN

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.

* 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!).

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.

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

https://www.halfarsedagilemanifesto.org/

Now I am curious about the background image. And a little disappointed that there is no principle page.

I love that!

Thanks for sharing it!

- A refugee from the Corporate Machine

Reply on news.ycombinator.com