Stand up. Walk out of office. Get on train. Arrive at user’s office. Go sit next to user. Spend afternoon understanding how they use the software you are supposed to be building.

Bin the sprint planning, retros, gantt charts, standup and whatever fucking sprint poker is.

Go. Speak. To. User.

> “Value working software over comprehensive documentation".

> So, never write documentation?

Read the phrase again, with a slightly different word in place

Prefer working software over comprehensive documentation.

I.e. working on building the thing instead of obsessing about gant charts.

You can do a Gantt chart if you want. But focus primarily on the software. That’s more important.

> And how do you define "working" software? What about features in development?

Intentionally left vague. “Working”depends on many factors that only the people involved with the building of it can know.

Mainly by getting on a train and sitting down with your users to figure out exactly what they consider to be working software. See above.

> “Value customer collaboration over contract negotiation"

You’ve not been around much contract consultancy work then?

Hey, company X we’d like some software that does Y.

Do you

1. Enter into a lengthy process to establish exact requirements and agree on exactly what needs to be delivered up front, without having touched any software, and trying to cost it all out etc etc

2. Get on a train and sit with the user developing some proof of concepts quickly to figure out what the hell it is they want.

1 is waterfall and contract negotiation. 2 is responding to change. example is a user saying “oh, actually, could we try the page header in pink instead please” after asking for it to be blue last week.

> lol. I have never talked to a customer, in my entire career.

You’ve never spoken to a user?

You need to start.

Ideally right now.

Stand up. Walk away from your desk. Find a user to speak to. Ask them what they think of the software.

> Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?

Well it’s not in the contract so I’m not going to work on that feature because we won’t get paid for it.

Even though some enterprising engineer went and got on a train and sat with the user for a day and figured out “oh shit, we’re actually building the wrong fucking thing”.

Nope, not in the contract. User doesn’t get what they want because we negotiated a contract.

> Value responding to change over following a plan

Waterfall: We have an agreement and WILL ONLY BUILD ACCORDING TO THE PLAN. We will never deviate from the plan. The plan must never change. Ever.

agile: shit, I went and got on a train and sat with the user and we’ve been building the wrong thing. Time to rethink this.

> The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)

A lot to unpack here.

No, they’re not stupid. They may be “of their time” but they’re definitely not stupid.

They seem more right the more I think about them. I think about agile a lot and how to teach the attitudes contained within the principles to my juniors.

Just to reiterate the important point there — the principles are a collection of attitudes. They are not explicit instructions.

No, it’s actually useful. Would I base an entire team methodology solely on this? No. But it informs a significant part of it.

Executives don’t care about by he agile manifesto. Mostly because no one posts about it on linked in and they’d rather pay someone ridiculous sums of money to make the team “Scrum” and fuck about doing whatever the fuck sprint poker is (execs always want to spend money instead of doing the work).

According to the LinkedIn post it made some other team really efficient. They read about it on linked in. It must be true.

—

FYI — just because you don’t understand or see the value in something does not mean it isn’t valuable.