Interesting Links for 20-05-2018

[andrewducker]

This is the very opposite of my experience with Scrum/Agile. Comes across as both needy and arrogant, and I'd hate to have to work with the person who wrote it.

(tags: development software agile programming )

Estonia To Become The World’s First Free Public Transport Nation

(tags: transport Estonia )

The theocratic democracies of Iran and the UK

(tags: religion iran uk politics government )

Why do LGBT LDs get so annoyed when people say the Lib Dems "acheived equal marriage"?

(tags: libdem marriage lgbt )

Five whys and the cult of the root cause.

(tags: process philosophy learning )

Tomorrow's cities: The park with four seasons under one roof

(tags: cities thefuture nature environment )

Targeting job ads at the CEO of the company you want to work for

(tags: advertising jobs )

The prime minister is boiling the Brexiteer frogs: the water is getting hotter and none of them has jumped out of the pan

(tags: UK europe )

Evidence that drinking baking soda can promote an anti-inflammatory environment

(tags: inflammation )

Tories take four-point lead over Labour in latest survey

(tags: politics polls Labour Conservatives )

The cold war nuclear bomb warmed by chickens

(tags: history nuclearweapons chicken )

Comments

[skington]

To take a narrow point about scrum: can we at least agree that daily stand-ups are legitimately terrible? The only purpose that I can see is to crack the whip and make sure that everyone has something salient to report every day.

[ironymaiden]

no. people who "crack the whip" at standup are legitimately terrible.

standup is particularly good for raising blocking issues and quickly getting help to solve them.

[skington]

But why wouldn't you ask via email, or IRC/Slack? What's the point in having a daily meeting for this sort of thing, which means you can't do anything productive in the half hour to hour before the meeting?

[andrewducker]

Why can't you do anything productive before the meeting?

[skington]

If I know that I have a meeting in 30 minutes, and the next thing I'd normally do would require at least an hour of interrupted, concentrated work, my only option is to piss about on the Internet for the next half hour. If the only purpose of a daily standup is for people to say “yup, everything's going fine here” or “I'm stuck, I need help”, then don't have it be a synchronous thing; instead, assume that people are doing fine, and make sure that there are ways for people who need help, to get help, at any time during the day.

[ironymaiden]

I find a scheduled, expected work interruption to be a much better use of everyone's time and focus. much better than interrupting coding flow or waiting hopefully for someone to notice a message.

I am particularly confused by this dead half-hour thing. you know when the meeting is happening. you could come in earlier or later to adjust size of the block of time before the meeting, or use that time for other admin tasks.

have you talked about your issues with standup in retrospective? clearly the timing and format isn't working for you. maybe there are adjustments that could be made. one of the things I appreciate about the two-week sprint is that you can always try something for two weeks and see how it goes.

[skington]

As it happens, we dropped sprint partially because we weren't doing one thing for a fortnight and then switching to something else. (How would that even work, anyway, if you couldn't neatly divide all the work available into fortnight-sized chunks?)

But for the brief period when we did, by dint of people working flexitime and in different time zones (US, UK and Russia), the scrum meetings were unavoidably in the middle of the working day. And there's no telling where you'd got to before a scrum meeting became imminent; maybe there's only 15 minutes between the natural stopping point and your meeting, but maybe if you've finished something and your next thing is going to be large and consequential you might be unlucky and need 2 hours of uninterrupted time. Maybe I'm lucky, but I don't normally have an hour of admin stuff to do every day.

Look, it's not like we're waterfall-worshipping brutes; we have version control, continuous integration and code review, we do test-driven development, we refactor our code base to avoid tech debt, and all sorts of other sensible things that most programmers would naturally do without being told about them by someone trying to sell a buzzword-ladel book or course. It's just that on the narrow point of daily scrum meetings, we didn't find them useful.

[ironymaiden]

ah, missing data point! yes, I agree that scrum doesn't work well with distributed teams - been there. it was indeed a bad fit and an unrewarding chore, someone always got screwed on timing, it was easy for people to tune out of meetings or feel left out. (we had enough people to reorganize by geolocation, but obviously that's not a fit for everyone.)

[andrewducker]

I've used it with half the team in Edinburgh and half in India, seemed to work fine.

(Although I prefer teams in one location in general)

[elf]

That Scrum/Agile article... It’s well known that creative people lose their creativity if asked to explain themselves while they are working.

Depends on the person and the project. Some thrive if they're explaining as they go along; more can work well with frequent breaks to review progress and confirm that they're working in the direction they want. And many, many people will make better works if they stop partway through and run a checklist of their end goals and check whether they're making the progress they expected.

Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.

AHAHHA HAHAHAH HAHA no.

I mean. Yes. Of course they do. We all want to work in a company where we decide when and how to use our specialty skills. But if you want a job that's "just code until you have achieved Awesome," start your own business or join a nonprofit. For everyone else... someone who is Not The Programmer will be deciding what the important projects are, and what the deadline is for those projects. In a well-run company, the decision people are taking a lot of feedback from the engineers so their plans and timelines are reasonable.

The worst thing about estimates is that they push a company in the direction of doing work that’s estimable. This causes programmers to favor the low-yield, easy stuff that the business doesn’t actually need

This, I can see as a real problem. Insisting on projects that can be easily estimated, and worse, projects broken into pieces where progress can be measured in two weeks, can be the death of a software company; not everything's going to fit on a chart. But a good manager should recognize that, and be able to tag some projects "no est avbl" and explain to upper management that it's being worked on, but there's no specific and useful progress markers that can be shown.

Anything that’s actually worth doing has a non-zero chance of failure and too many unknown unknowns for estimates to be useful.

I think this has fallen into hyperbole. I suspect there are plenty of parts of every large software project that are worth doing AND relatively easy to estimate how much effort will be required for them. I also suspect these are mostly boring and that software engineers hate doing them.

Technical debt falls in this category - "we know how long it'll take to update the entire database to match the new software requirements, and that's X hours of work that will not improve a damn thing but will allow the company to survive into next year."

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it.

Erm. The problem with that isn't Agile; it's managers who don't understand that "show what can get done in this two week production cycle" doesn't mean "show how much we'll earn in this two week profit cycle."

... and so on. I can see he's got some points, but most of them seem to be "Agile/Scrm is trendy AF right now, and a lot of businesses are grabbing keywords from it and using it to reinforce their current hierarchy, rather than using it as intended to give some structure to a creative process that's hard to justify to shareholders."

Agile etc

[agoodwinsmith]

I can't remember why I wanted to know about it - I think I was still reviewing job postings and a technical writing job listed knowledge of Agile as valuable - but when I read up about it I wasn't impressed. The focus seemed to be on preventing programmers and writers from doing too much. Just enough programming to barely do the job, and even less writing up the documentation for the programming.

I suppose many companies are working on planned-obsolescence software - something that will be discarded long before it breaks, but I thought that I wouldn't care to work for a company which was only interested in barely-adequate work.

Agile seemed to be both buzzy-trendy and designed to protect and glorify people who like to count things. I mean: there's nothing as satisfying as something well counted.

Baking soda.

[agoodwinsmith]

Thank you for this article.

[(Anonymous)]

Five whys and the cult of the root cause.

For example, you turn on your computer and see smoke rising from the cabinet. You brilliantly deduce that the smoke is probably a symptom of a deeper problem. Should you treat the symptom or fix the root cause? Most of us would treat the symptom by shutting off the power, even though we realize this does not address the root cause.

Actually, I think you'll find that 'electricity is flowing through this thing' usually is the root cause of it overheating and smoke pouring out of it. Stopping electricity flowing through it is fixing the root cause; any of the downstream problems can then be fixed at leisure.

For example, people who type produce spelling errors; in many cases the root cause of these errors is that they never learned to spell

But in many, many more cases the root cause is that they learnt to spell perfectly fine, but their fingers happened to hit the keys in the wrong order. I suspect that the ratio of 'never learnt to spell' : 'can spell perfectly well but hit they keys in the wrong order' errors is something like 97: 3.

For example, let’s say that while sailing you get an alarm indicating high water levels in the bilge of your sailboat. Your immediate intervention may be to pump water out of the bilge. After the water is pumped down you may observe a crack in the hull which you can temporarily plug until you return to port. When you return to port you can have the crack in the hull investigated and repaired. The optimum place to intervene has shifted from pumping, to plugging, to hull repair; thus, it is time dependent.

No one doubts that. The advice to look for root causes is because without it, many people would either set a permanent pump running; or would patch the hole and then set sail again without bothering to repair the hull. Those people are now having Gordon Lightfoot write songs about them.

When you have identified the root cause, you might well realise, 'well, that's what we need to do to fix the problem , but we can't until we're back in port. And we won't make it back to port unless we make a temporary patch. And we can;t do that until we've pumped out the water so we can get at it.'

But until you've identified what's gone wrong, you can't even do that.

What a terrible article.

[coth]

That Agile article was interesting. He has clearly identified some of the failure modes available to the method. While also clearly exposing his own worries and lack of experience.

[skington]

Could you clarify this please? Which criticisms are due to lack of experience with agile / scrum?

[coth]

Not lack of experience with Agile/Scrum, but lack of more general experience. The article describes various types of management/organisational disfunction and attributes them to Agile/Scrum, but you could perfectly well demonstrate those disfunctions via other means.

(I've never worked on an Agile team, but have been around to participate in and watch systems development via a variety of methods for a good many years.)

[miramon]

The Scrum/Agile article is one of the worst things I've ever read on the subject. The author not only totally misunderstands Agile, they even totally misunderstand Waterfall, which takes a lot of work. It's as if it was written by someone who believes that their personal experience is universally applicable and that every project in every area has to work the same way.

[coth]

That's a good way of saying what I thought.