Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP)

This is one of the reasons I'm always singing the praises of Kanban over Scrum. Scrum encourages busy work on too many things. Kanban encourages ruthless focus on a few things that need to be done next, and what is blocking it. Scrum encourages "agile cosplay" with folks taking on things they shouldn't be doing now to make the right (imaginary) story point total for the sprint (which of course gets gamed as points get estimated to fit). Kanban encourages teaming up to get the hard stuff out of the way now.

I have led a team in a transition from an over-done scrum to minimal Kanban process and talked to many others who did the same, from small startups to AAA game companies, and they all loved it. I've never heard one dev say they thought it was more productive to have scrum. As far as I can see, Scrum makes middle managers, "scrum masters" and people who don't care how much work actually gets done happy. Kanban actually helps development go faster.

If anyone's interested, Microsoft press has a great light book on. The WIP limits are a key part.

Somewhat related. I'm annoyed when people complain about their workload.

Staffing is a management problem. If you don't have the budget to hire people, just do your best and let the work pile up. It's literally not your problem.

The worst thing you can do is to go "above and beyond", not only do you burn out but you're signaling to management that your workload is fine. Because all most people see is the bottom line -- is xyz task done or not.

A good point is made.

If you're in a hole, the best way out is not to keep digging. It's hard to see that you have to accept a delay but a delay is exactly what you need when you're not making good progress. Slow down, finish shit, move on. Same with load. Sometimes just gotta do less at once.

- the worst code quality is when engineers who aren't already experts in a specific thing can't experiment. This is multiplied 10x for junior engineers.

- the most qa rejections happen when engineers need to work 10-12 hours straight to complete a feature and it will always be sub par even at the end. You pay shortly for problems because you didn't let anyone think deeply.

- at some point you need to be able to declare bankruptcy and abandon work because otherwise you'll sink.

This is incredibly useful advice that essentially everyone who gets to make decisions in this space hates

This article makes sense to me as a developer and an occasional manager of developers and a former student of psychology and honestly if you meet and talk to people who do actual work in any capacity sometimes in your life and had any honest assessment of their day-over-day work over any appreciable period of this time you will have a hard time avoiding this conclusion

But businesspeople and especially high-level investors are rewarded for ignoring it. I've been in a few C-suite and board meetings and while you occasionally see the folks there talk about their underlings, they tend to mostly talk about abstract measures of outputs, with "velocity" being a popular term in tech orgs in particular. If they mention a worker by name, they tend to be high-ranking, perhaps a manager, but usually they are getting a lot done fast, or used to be and now aren't. Seldom is the latter kind of conversation had with remorse, sympathy, or the slightest hint that the prior state was a direct cause

Developers, especially experienced ones, often know what they need to get work done. They are often realistic about how much work to take on. They are incentivised to take on too much anyway, because the culture of business is fundamentally deeply broken

As far as I can tell, there has been no point since the invention of factories and metrics at which this has not been true, the rule rather than the exception among the entire classes of owners and high-level managers. And what's worse is that often competent ones of these can get some clout by delivering results by realizing this, but as more of them are added to the decision-making process, their ability to resist this tide, either socially or through direct loss of power, diminishes

I think that for programmers, if you’re working on more than 2 features, you’re working on too much.

Cal Newport’s latest basically says: Take in fewer things. Work at a natural pace. Produce at the highest quality. I think that’s correct.

The core idea here is the subject of “The Goal” by Eli Goldratt. It’s a short novel and presents the case very clearly, although in terms for a factory not a software shop or a grocery store checkout line. It’s a great read, I recommend it.

Since it’s a business book, perhaps easier to sell to management than a blog post?

https://en.m.wikipedia.org/wiki/The_Goal_(novel)

> Like the radio cookie tin the Germans were searching for, the problem is painfully obvious and immediately visible: we’re overextending ourselves with work.

At my organization, I think the reason is organizational structure and focus time. When I look at all the WIP tickets I have open, most of them would be easy to close, if only I could get unblocked on them.

Structurally, if you have a lot of managers with control over their little fiefdoms, and you need to get sign off from all of them to do something, that can take weeks: I have a couple tickets right now that can't be closed until I either find time for a meeting with 7 busy people, or schedule 7 individual meetings. In the middle of summer, with vacations and all, that's not easy.

Engineers at our organization, which is remote first, have done a great job of protecting their focus time. But one negative consequence of this is that they can't be interrupted even when they should be. If I need to ask the Lord of the Backend Engineers a question, I know he's not going to respond to me until the last half hour of his day, when he does all the stuff he considers beneath him, including communicating with other people. And it's probably going to be a terse, one-sentence response that requires another followup the next day.

I really don't think there's too much work for any reasonable company, I think the lack of throughput is due to communication issues, or in a larger sense a cultural issue related to how we expect to interact with each other. I'm not ready to say this is a remote work problem, because my last organization was 100% remote, and didn't have this issue at all.

I don't know if I'm bought in on their reasons why this is the case, but the observations seem true to me. The times I've moved the fastest are also the times when everyone is not fully busy.

This is true of large teams, small teams, and every type in between, in my experience.

Personally I find myself radically under-extended by the typical one-thing-at-a-time mentality. One at a time feels like accepted dogma, and pushback feels extreme & immediate if I as a dev attempt anything else. Businesses really want exact control & certain knowledge over how I spend every minute of developer time.

And I think it's such a waste, in my view. When I write code or make designs, usually the first couple cuts aren't great! They usually work, but how I lay out interfaces & how the code is structured tends to be pretty so so. Insight is garnered over time & experience.

Hammock Driven Development (Rich Hickey) speaks to me a lot. Sit back and reflect; consider what we are doing, how it's going. Reconsider the possibilities. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Now, if work wants to pay me to spend 2/3rds my time just reflecting & pondering one thing at a time, I think that would work. But what makes sense to me is to have a couple things in flight, ideally staggered at slightly different phases of development, and to shift between them as the whims take me. Give myself time to decompress & reflect on one thing, by picking up another item that I've been pondering for a while.

It feels so unnatural & suboptimal, what we do to developers. The expectation of constant productivity in one task feels like such a recipe for bad code. I have no idea how so many people do it. It boggles my mind seeing folks able to stay to task, able to power through, without these pauses & times for reflection.

I wish so much there was some affordances, some option, something available for those of us who don't work well one task at a time. I want to be juggling more of the world at once, switching on and off tasks, having intervals & spacing between working specific areas of the code. I just don't see this perspective mirrored at all in the world, don't see anything at all that reflects what works for me, that reflects how hard it is for me to feel good about my work when I'm managed down, as though a machine that just has to turn a crank until it's done. My mind just is not that fast & direct, not that quick to settle and resolve the complexities of system; I need some dwell times built in. I don't know what would happen to velocity, but quality would be much higher & I'd be so much better able to flow, to latch onto tasks I was much more primed for. Please, someone, give the Hammock Driven Devs a chance.

isnt this more of a mythical man month issue

"adding manpower to a software project that is behind schedule delays it even longer"

we need more doctors and more cashiers

more doctors, and more cashiers will solve the queue issue at hospitals or at stores

problem is .. "mythical man month" .. adding more developers wont solve the problem

this article possibly misses the point, it doesnt suggest adding more devs whic is good i guess, it just suggest doing less work .. because you will do less anyways, so why do it while stressed, when you can do it while relaxed .. so you end up doing more or less the same, but with higher morale, all of this is good, but it doesnt solve the real problem .. "HOW TO DO MORE"

(you can of course decentralize your team, decouple your products, add more teams, etc.. but .. well)