And of course in between the time of riding some where and getting on the bus you have keep your bike someplace. With the bike share system, that's a non issue. You slide it into a stall at the station and then you're done with it.
Agile places a high value communication, especially face to face communication. You can pick up things face to face that you can't in an email.
And yet, somehow, projects like, oh, the Linux kernel, the Apache HTTPD server, and just about every other open-source project out there seem to be able to muddle along without face-to-face communication.
Besides projects are supposed to be a team effort and as a member of the team you should care what other people are doing and what issues they may be running into.
That's your job as project lead.
... and no need to put added pressure on any dev by suddenly making daily inquiries about their progress.
Then you explain to them why you are making such inquiries and, if they'd like them to stop, what they should do about it.
Open source projects are a different beast that don't operate under the same constraints that a commercial project does. You lose some efficiencies in terms of communication but for projects like the Linux kernel or Apache you have potentially an unlimited pool of developers and much more flexibility as to what gets delivered when. It should also be pointed out that for every open source success story like Apache or Linux there's lots of stuff that dies on the vine or never gets off the ground.
Look, it's clear that you're not happy with an Agile approach and some people just don't work well in that environment. It seems to me though that people who only give a crap about their part of the project and resist any face to face communication in favor of email are limited in the sorts of projects they can work on successfully.
If they've spent 2 days on something that should have taken a few hours, you as the project lead know there's trouble.
Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?
Just the fact that a developer on a daily basis has to stand up in front of their peers identify what they did and what they are currently working on helps them stay on task...
In other words, it's a way to keep people from slacking off. Surely as a project lead, you know who your good, self-motivated developers are and who your slackers (or potential slackers) are. If that's the case, then simply fire the slackers or, slightly less drastic, require daily e-mails from only the slackers and leave the better developers alone.
Agile places a high value communication, especially face to face communication. You can pick up things face to face that you can't in an email. Besides projects are supposed to be a team effort and as a member of the team you should care what other people are doing and what issues they may be running into. You may be able to help or learn from them. That won't happen if all you're doing is staying holed up in your cube sending a daily status email.
As a project lead I'm not just concerned about keeping the slackers honest. Sometimes very dedicated, very good, but also very prideful developers can be reluctant to volunteer that they're struggling with something. Sometimes the road blocks aren't technical but political. If the meetings are regular, then there's no need to single anybody out (which can have bad consequences) and no need to put added pressure on any dev by suddenly making daily inquiries about their progress.
I should also stress that in my view, agile works best in fairly small teams. I'd never have a standup meeting with 15 or 20 people. It's going to be detrimental rather than helpful if they are anything but brief.
You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.
As a project lead I found a lot of value in stand up meetings. Not all devs like them, that is for sure. The thing to remember though is just because an individual developer may find little value in it for them personally, that doesn't mean it doesn't have value for the success of the project as a whole.
If you encounter a road block at 2:00 by all means, try to resolve it, but the truth is not all developers will and often they don't have to, it can wait and they move on to something else. Then there are developers who will naturally put things off anyway (sometimes too long) or will bang away at a problem forever when they could simply ask someone else. The beauty of the stand up meeting is that problems are quickly identified even if the dev doesn't specifically mention them. If they've spent 2 days on something that should have taken a few hours, you as the project lead know there's trouble.
Just the fact that a developer on a daily basis has to stand up in front of their peers identify what they did and what they are currently working on helps them stay on task and helps you as the project lead nip problems in the bud. It also keeps everyone involved informed as to who is doing what and the current state of things as a whole. All by holding one short meeting. And if you're really doing agile, the developers are located in the same area and assembling them shouldn't take anytime at all.
The only thing that makes it not a sailing boat is that I happened to use land to make the engineering easier to describe. We can trivially change it back into a sailing boat by saying "it's a really really wide catamaran, and the mast is attached to a travelling base.
Even if you could build such a thing that would actually strong enough and flexible enough to deal with all the forces involved while still being able to float and steer, it would no longer be fast enough to accomplish the goal. Imagine what it would take just to have a mast mounted to a moveable base which would have to have a keel whose angle could be set independently of the direction of the boat.
Logic is a pretty flower that smells bad.