How to Lead Your Team When the House Is on Fire

> “Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack?

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.

This is painfully accurate. I'm not sure how companies fall prey to these problems, but they seem to be incredibly hierarchical. What I means specifically is that the lower level employees and mid-level managers seem almost rabid to praise, cater to, and and be swept up by the useless whims of nearly anyone in the executive suite. It's sickening, and not because of the impacts on work. Why do so many grown adults act so pathetically servile to someone who is in a higher rung in a company? These executives don't have better ideas inherently, and due to being so far removed from the real work, are often a misinformed distraction. No one seems to think that an executive would want to be told that they are wrong, or misinformed, or missing the point. But, a worthwhile executive would want to hear exactly that. They would want to know if their ideas were actually going to disrupt work, make the firm worse off, etc. And I know what you're thinking: many executives are self-interested, and just want to see their ideas implemented, company health be damned. Yes, that's true. But then why does anyone give them the time of day? If an executive is nakedly self-interested they should be sidelined as aggressively as possible, both to neuter them and also to protect the company.

The failure mode of Agile is when the company says "we're going agile" but refuses to adapt or let the team manage itself, as well as having a fixed deadline, scope and budget which have been decided outside the team. In other words, you still have the clueless project managers, but you have to cosplay "agile" within that.

I think that almost no one from the community has any hate for "Agile" as in the manifesto. Quite the opposite.

The problem is that the Agile that is pushed in the corporate world is nothing at all related to the spirit of the manifesto.

Management took over to keep control over developers.

So you have scrum, you have scrum masters, product owners, t-shirt sizes poker, ... All of that bringing more stress to devs than having empowered them to be trusted to deliver what the real client wants.

> being an engineer in an actual “wartime mode” is like. Think about, e.g., working in the lab trying to improve radar to be able to stop the daily bombing raids.

This is slightly OT, but I believe wartime in the UK and US forced a number of cultural changes towards egalitarianism and what would nowadays be called "diversity" because things had to actually work. Being upper class in the UK would not save you from German bombers. The normally exclusionary system had to let a gay man break codes and a woman design Spitfire engines because those were the best people actually available and the outcome mattered more than saving face. This also got us the postwar settlement of universal healthcare and education.