Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.
Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> What specific needs are met by daily status updates?
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
A manager has a duty to "catch" (as you put it) underperformers, to help them improve.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
The engineer did not choose to represent themselves in weird daily show-and-tell meetings. The commit history is there regardless. You could just look at that.
You are not answering my question. No, you ask your acquaintances who work in law, finance or medicine. Neither does academia have any "stand up". What specific needs do CRUD software projects have that are met by infantilizing daily status reports? What needs for daily status reports do these projects have that the Linux kernel doesn't?
> Professionals outside of software don't do that.
What, and I mean this in the nicest way possible, the everliving fuck are you talking about?
Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.
The scrumbags may have ruined software, but that certainly isn’t the world.
You make your not entirely unreasonable points sound like the output of a zealot.
"Stand up" meetings are not hand offs in the ER. Continuous integration with automated testing is.
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
Many teams have short daily gatherings — especially now that so many teams are fully distributed, it’s good for everyone to come together like that.
But while every team member talks about the difficult bugs they’re facing, sometimes the actual code tells a different story and can reveal that a team member is struggling to get working code together in any reasonable amount of time.
It sounds like you could just read their code and the meeting was unnecessary. Linux kernel developers are distributed but don't do daily status update meetings.
Does French law mandate trial periods or 3 month notice periods? You can usually negotiate those away. Reference checks or trial period but you should really not require both, that's an employer problem.
Europe pays lower than the US but pays better than other regions. There are many countries with low pay and poor labor rights. We should try to have high pay and better labor rights.
Yes the 3 months notice is legally enforced in France with a few cases where it can be waived - including both the employee ans employer agreeing to skip it.
Note that this notice goes both ways: when an employee resigns or is let go.
Yup. I think this was a sideways swipe at my analogy so I'm going to double down now because I'm right. You would never get your food before closing at a restaurant if the cooks had to do sprint planning and provide estimates and deadlines. For some reason this is not only acceptable but preferred in software industry.
That attitude works well in other professions. If you want to become a managing partner at a law form you are expected to have chops. Why should software engineers accept micromanagement by laymen?
How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.
In my view, it's fine if it's not treated a performance metric, for the individual devs.
I saw a lot of questionable tactics stem from this. It's like when you play capture the flag, and focus on the "KDR" metric, as is often done.
Critical people who were saving the teams life and working their fucking asses off would get grilled and questioned; not intentionally, but as a natural extension of these processes. Meanwhile, people that scored easy points would get a pat on the head, then sit silently during the sprint review; thankful that they got the easy path this sprint.
It got to the point of absurdity. I think it could make sense to look at sprint points during planning, but then the total bank of points goes to the team; who scored what should be anonymous... this was one of those ideas you have that you know you can never share, lol.
I agree, but a lot of big companies are all in on Agile and you (as a developer) don't really get a lot of say on the matter.
Some high-paid consultants got paid a lot of money to sell it to the CEO, who then mandates it....so we are stuck with it ...until those same consultants have some other methodology-du-jour to sell.
Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.
Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.
While thats true, business leaders still need to realize developing software is not the same sort of economic activity as running a horseshoe press or something. Machine can’t just be ran faster. You can’t also just plug another machine in the wall and expect it to know exactly what to do and double your output. Roadblocks often emerge that cannot be foreseen at all short of taking even more time to speculate on these potential blocks down the road.
Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.
> There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people need to be paid out of budgets, etc. I'm a dev and I hate being micromanaged, but usually people really do need to know when the code will be done.
Not so much for mathematicians proving conjectures. Which is nice for them. I guess.
That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.
I'm sorry, I can't imagine any business anywhere that would allow all software project estimates to have a precision of "about a year".
We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired.
Estimated is hard, leadership often fails to understand how hard it is, and it should always be accepted with a bunch of caveats, but it _is_ a very useful tool.
How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.
Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.
Hello waterfall my old friend. How have you been doing?
But seriously.. there's levels to planning. There's strategic planning which is less often and then implementation of delivery stages which is more on going. It is helpful to know if something will be delivered in 2 weeks or 2 months. The problem is when the dev team says 2 weeks but discovers more and knows it will be 6 weeks but the deadline is firmly set to the initial 2 week estimate.
Probably because software engineers are not mathematicians. Also, you're not doing foundational research or breaking away at the edge of human knowledge either. Similarly, mathematicians are not immune to deadlines either.
Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.
Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.
The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.
An obsession with technical knowledge being superior to everything else is one of the most grating things about this community.
> The non-technical managers and agile coaches are the problem.
No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".
> That's why the best software projects don't have them.
There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.
> Linux kernel developers don't run story ticket velocity poker sprints.
The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.
Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?
Every what?