itsreallynotme
That's impossible.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
You just made that up.
Oh, I agree. My language was for emphasis, not representative of an emotional state. It's interesting to talk to someone who thinks that the same process can save a bad team and make a good team better. That though had certainly never occurred to me.
It takes a lot to noticeably hurt a good team's productivity. But it's mean, just fucking mean, to punish a good, productive, communicative team with more process because you also manage crappy teams.
In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.
If I'm managing 5 job sites ... once a day sure beats nothing
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.
That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks.
"etc. Pretty much what actually happens at a construction site"
That communication happens continuously, throughout the day. If isn't happening continuously, throwing a standup at it ain't gonna fix it.
The thing that suggests to me that you and I wouldn't work well together is that you make broad value judgements based on twisted interpretation and extrapolation of these comment threads.
Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site.
Tom: "Yesterday I.."
Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?"
Good teams communicate while they build, and know where each other are.
That's not what Agile consultants are selling.
"So how do you build things that take thousands of programming hours to complete?"
By programming for thousands of hours. Through the process of programming, I'd try things out, use what works, dump what doesn't, write tests first where it makes sense, last where that makes sense, not at all where that makes sense, buy hardware where it will save me time and money or work better, interface with it by writing code, step back, look at some mistakes, rip them out, replace them with nothing if I can, or less bad mistakes if I can't replace them with nothing.
You know, programming.
If in addition to my process of programming someone wants me to tolerate some other meddlesome process, well, it depends how meddlesome that process is. If they want me to use a particular IDE, they can fuck right off. If they mandate I write code in a particular order, they can fuck right off.
On the other hand, if they are awesome people with awesome product, I'll engage in standups (or whatever), and I'll write my cards and move them along (or whatever), and burn down my time (or whatever). But I won't pretend that it part of the process of programming, or that it's speeding things up.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.