My 2c (as a developer who has done some engineering / project management earlier, in companies):
The informal technique of Management By Wandering Around (MBWA) can help. I've used it in projects that I handled. It is known to have been used at HP (Hewlett-Packard), and has been written about in books on management (I read it in one such book, and applied it some), but since it is a somewhat obvious thing (at least in hindsight), it's likely to have been known much before.
The basic idea of MBWA is: instead of only relying on formal reports such as weekly status reports and such, to track / monitor how things are going, and to be able to take corrective action, walk casually, now and then, around the work area of the team (whether cubicles or individual offices for team members, the same concept applies), and chat with them (not all at the same time, maybe one or two at a time), and/or be there a while at their desk and watch what they are doing, for a bit. You can learn a lot about good and bad or potentially not so good things that are going on, with the team's (individual's) work, some of which might not surface via the regular / formal reporting mechanisms.
Worth a try, IMO, and can also be fun, since you get to interact with your team members in more casual settings. In fact, if you observe a team member doing something not quite right, or something that can be improved, telling them about it informally in such a setting, can be taken by the team member in a better spirit, than if given as a lecture or reprimand in a formal one-one-one or team meeting.
Edit:
>and/or be there a while at their desk and watch what they are doing, for a bit.
Of course, you have to do this in the right way. It should not come across as though you are watching over their shoulder as they do their work - anyone would feel uneasy with that. Can do things like talk with them, ask "how is it going?", "having any issues?", ask pertinent questions about some piece of code or some output or test or design point, etc., and offer suggestions for fixes or improvements as appropriate (both on the specific point and any small process or technique that can help avoid such issue in future - good examples (for junior devs) would be the kind of things that are discussed in books like Code Complete.
Update:
https://en.wikipedia.org/wiki/Management_by_wandering_around
Also relevant:
https://en.wikipedia.org/wiki/Gemba