Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view.

Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well.

What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback.

A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?

It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.

I'm not GP, but let me try to explain.

The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution.

On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.

Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups.

The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science.

The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging.

I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do.

Personally, I've been on both sides of this pattern and I would rather still have standups.

As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.

If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems).

Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock.

As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help.

Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.

>What if I don't want a team mate to look at something I'm working on?

>What if I just want to focus on building, not explaining and sharing?

>it makes them share if they are thinking incorrectly about something

>it makes them easily replaceable

I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable.

Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......

This mentality is the root of the problem (from the dev perspective). The GP commenter is saying "these processes don't help me to feel that I've done my job better."

And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."

> it makes them easily replaceable

I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.

Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.

Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.

I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.

Do you care how useful the thing you're building is for the people you're building it for? How well it fits in with what other people on the team are building? If any of your teammates have ideas that could be helpful, or have learned things that might be of interest to you?

I've often been the guy who comes in to help untangle a messy code base, and an entrenched "just let me build shit" attitude appears to be a chief predictor of unextensible and inflexible design. Even when not in a managerial role, I don't like to see people working in silos because experience has taught me that I'm gonna have to deal - as a fellow dev - with repercussions of poor design sooner or later.

If daily standup has any role whatsoever in those questions, your process is horrifically broken.

I'm not sure how much that micro-managing aspect is peculiar to agile and how much is just inherent to working on a team.

> It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.

That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo.

Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit.

[1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.

That sounds like hell. The sense of ownership, achievement, and subject matter expertise when driving projects from ideation to completion is everything I like about my job. Working on scattershot, atomized tickets from an assembly line would be awful.

Unfortunately, we do not live in Utopia. In reality, politics, competition and self-interest play huge role in the workplace. In some companies, admitting a mistake or showing vulnerability in front of the wrong crowd can be very damaging for your career there.

1. Agile is not personally great for programmers.

2. Agile is good for managers.

3. Managers run the business and make sure it exists.

4. Programmers need the business in order to have a job.

5. Agile is therefore good for the business,

6. And therefore Agile is good for Programmers, though not personally.

Unfortunately, you have been taught and are executing Agile in the completely wrong fashion. My first guess would be, you are actually working in Waterfall, but your managers have labeled it Agile and cherry-picked the parts they liked.

Agile has a remarkable resemblance to both communism and faith healing: Every time I say it doesn't work, a true believer replies and says I wasn't doing it right or I didn't believe in it enough.

I would disagree with almost every claim on this list.

I don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much).

The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.

Agile is good for managers who are unable to evaluate their programmers otherwise.

4. Managers need the Programmers, to make sure the business exists.

5. Agile may or may not be good for Programmers.

6. Agile may or may not be good for the business.

Agile is good for managers in that it gives them a feeling of being in control.

Agile is not actually for managers, in that productivity suffers a lot, less software with real value is produced.

But software productivity is notoriously hard to measure, so it is ignored.

My, how very Douglas Adams of you =)

It's a crime that Scrum is allowed to call itself "Agile". Look at the Agile Manifesto again, then look at Scrum. Almost complete opposties.

Yes, it's a little disappointing that the term "Agile" pretty much now refers to Scrum.

If you don’t want to explain or share, I don’t want you on my team.

I’m confident I can identify some interval at which you don’t want to explain or share, either. For example, every 30 seconds.

Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.

Because you work in the team.

A boss used to say to us, you haven't proven you know how to do it until you've done it twice. This is, as I recall, also the guy who would pigeonhole people who built things that they couldn't hand off to others. He fed us some bullshit line about being 'too important' to work on the new cool stuff. It was a hard lesson but I learned pretty quick to put extra time in to make my code obvious to others instead of just me. Boost your truck number if you ever want new scenery.

(Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)

There's still code review right? And if you're off building something more involved, then hopefully that code review is happening on a weekly basis with at least 2 people reviewing it so that there's input and ideas and corrections happening. It's brutal to see someone waste time on building out unnecessary parts, etc. Plus it's also useful to reduce bus factor, have other people in the loop to pick up the work if necessary.

ah the black hole programming movement! We've been there with "waterfall", which was a disaster. Not explaining and sharing is counter to working on a team. If you are a one man army, and no one knows what your code does, or if it can be compiled or deployed without errors, then that is bad for your company.

are you really on a team then?

A manager usually has several distinct projects in the air, with ICs working on them in groups of 1-3. Someone's work isn't relevant to you just because you report to the same manager. The "team" for standup, sprint planing, etc. is really several teams, each tuning out while the others speak. And because small groups can communicate fine informally, the relevant-seeming part of the team-level ritual is always a rehash of what the project staff already know.

That sounds like a bad structure then. Standups ought to be for the teams of small groups, not the convenience of the manager.