[jollofricepeas]

Agreed.

Note that ALL of these can be summed up in one phrase that I tell my teams often…

TIGHTEN

YOUR

FEEDBACK

LOOP

This is literally the key to life (besides 42) and everything. Want a better relationship with your partner, pet, friends, boss, code, family then tighten the loop.

[dgb23]

That’s very good advice for day to day tactical approach:

- small changes, fixes, additions

- tests, optimizations, refactoring

It’s what you do to move forward iteratively with approaching deadlines.

But to not get stuck in local maxima you need some time off from feedback loops and tactics. You need time to think, design, experiment, sleep. You need time for creative, strategic thinking. Processes, rules, feedback loops, deliverables etc. are all a hindrance to that.

[afro88]

Also, getting an app up and running. Often times it's better to hack away at a (truly minimum) mvp and then iterate on that. Than try and iterate your way to an mvp.

[mike_d]

That is exactly the failure of all the various management methodologies - they are built on the false assumption that all feedback is valuable and if something isn't going right you must not be getting enough feedback. What is the value in getting bad data faster? Can we not trust a developer to build something without deferring on every decision?

We need to get back to engineering as an art form, not factory work.

[andrei_says_]

But isn’t it the managers’ implicit goal to make it as predictable, modularized / interchangeable as factory work and workers.

the Agile Industrial Complex realized they can sell that vision to managers, despite it being unachievable.

That promise is so alluring, it’s blinding.

[mathw]

My company have mandated that my team use sprints, despite us having previously proved that sprints are a bad way to handle our workload (we used a kanban-like system for a glorious year or so and we were actually way more productive in a measurable manner, and also a lot less annoyed). The reason? Predictability.

Except you can also measure that we're not hitting any predicted goal times, ever, because our sprint system is incompatible with the nature of our work supporting live systems and simultaneously developing new features. We're regularly taking on work from outside the sprint half an hour after sprint planning, because something exploded and we're the ones who have to fix it.

It's completely impossible, but the vision of predictability has blinded management.

The number of times there's a card on the retro board under "Stop doing" that just says "sprints" on it...

[andrei_says_]

I believe this has to do with managers being required to constantly estimate cost, time, and ROI with precision, minimizing risk.

I like Basecamp’s shape up methodology: make bets of efforts that are worth 6 weeks of the team’s time, commit to the best one, timebox it. If it takes longer than 6 weeks, throw it away. This way the risk is limited to six weeks.

Few managers would be willing to stake 6 weeks of a team’s time though.

[webmaven]

> I believe this has to do with managers being required to constantly estimate cost, time, and ROI with precision, minimizing risk.

Well, they think they're minimizing risk, but at best they're just minimizing uncertainty, and the result is predictably low productivity.

[sveme]

That needs to be balanced as well, same as all things. A retro every two weeks is a lot and brings too much overhead into the process. Same with the constant refinements and groomings and plannings and whatever. A team or a subteam needs to have uninterrupted autonomous time to dive deep and get things done. That's fulfilling work, from my perspective. Rhythmitize work into periods of quiet, focused implementation work and team work where people investigate, research and plan new features and refactorings.

[jollofricepeas]

Here’s what we do:

- Kanban (no sprints)

- (45 min) Weekly grooming session

- Thrice weekly stand ups (async)

- (1 hour) Retro every two weeks (sometimes we skip it or it becomes a show-n-tell)

- (30 minute) 1:1’s monthly for seniors, every other week for juniors unless requested more frequently

- Optional (1 hr) themed mob sessions / office hours throughout the week. You bring a problem and the group that shows up will work on it with you. Seniors/IC’s are required to hold office hours at least once a week.

- NO OTHER MEETINGS; engineers are asked to block out their lunch/personal time and refuse any non-essential meetings. They have the right to request meetings be rescheduled to appropriate times or moved async.

- NO MEETINGS OF ANY KIND ON FRIDAYS

[exitb]

Doesn’t it become something akin to micromanagement, when tight enough?

[meheleventyone]

If all you concentrate on is short term improvements then... sort of?

Making iteration faster let’s you see the results of changes you make faster, that’s the benefit. If you’re iterating faster than you can make meaningful changes then you won’t see any change by definition.

Iteration length is also context dependent. For a multiplayer game I really like being able to see my changes immediately when working on it, I love being able to iterate with other devs on some idea where each iteration is in minutes and we’re chatting about it together but we only test the game itself “as it’s meant to be played” with anyone outside the team once a week. That’s part logistical and partly anything shorter than a week doesn’t usually show enough progress. If there’s some bigger change we’ll also keep our work iterations but pause the larger play tests until it is done.

Short as possible is good advice but you’ve got to look at your own context and make sensible decisions. You can also look at it like following a gradient, if you’re unable to make bigger changes then you’ll just be optimising towards some local maximum.

Micromanagement itself is more about the amount of agency to decide what to do at each iteration.

[r_hoods_ghost]

Even worse it means you are always reacting to the latest or "loudest" issue (like the CEO wanting a feature implemented that no one will use but will impose a maintenance burden) and never standing back to evaluate what is valuable for the majority of customers or product.

[snovv_crash]

It doesn't necessarily mean that management is giving the feedback.

It could be coming from tests, from CI, from the QA team, from customers, from other engineers in your team, or, failing all that, then yes from management.

But if management is giving feedback that is hard to reconcile with everything else, at this point you can point to CI, the previous tests that were added based on other requirements, feedback you got from customers etc. as justification for your existing actions. It means you're operating with a lot less assumptions because you get data validating what you're doing (and where you should fix things) every step of the way.

[exitb]

If I had a perfect understanding of both technology and the problem domain, I wouldn't need feedback. Yet, usually we find ourselves in a different situation of less than perfect understanding of both, so we seek feedback to avoid going in a wrong direction. The less understanding, the more of it we seek. But there has to be a logical limit to that, otherwise we could come to a conclusion that things could be accomplished by someone with nearly no expertise, given enough feedback.

The secret lies in the fact that neither giving, nor receiving feedback is free.

[laserlight]

I would like to interpret “feedback” in the parent comment as communication. And I think we should distinguish between frequent communication and micromanagement. One may report to their manager frequently. Doing so has the benefit of letting manager communicate back any context they might have regarding the current status. Perhaps, that problem has already been solved in some other situation. Or, the manager has experience in a similar domain and can give direction. Unless the manager dictates a direction, doesn't leave enough room for decision autonomy, or begins working on a solution rather than leaving it to the engineer, I wouldn't call it micromanagement.

[ac50hz]

In my experience, if the management, processes and teams aren’t trusted then it can turn into unwelcome micromanagement.

Engaging with people, who have different motivations and reasons for being in a job, and stripping away often unhelpful implied titles of rockstar programmer to QA robot, can help everyone to see the big picture and in turn to see how their contributions, their cogs, fit into that picture.

Production-line programming can be left to new automated systems, whilst we can embrace and capitalize on people exercising their intellect for productive, feedback-oriented work.

[qikInNdOutReply]

Its also a good way, to destroy programers productivity. Put them into large offices, interview them on the project status every hour on the hour.

[laserlight]

Be careful, because tighter feedback loops might result in a lower signal to noise ratio. When noise is reacted as signal, things might become worse. To be clear, I'm not arguing against tight feedback loops. Our current feedback frequency might be looser than the optimal, after all. We need to be more cautious with what we are doing, though.

[irfn]

and dont forget that feedback means measuring data accurately without biases.