How often should a manager meet with his subordinate who is a team leader

In a lot of teams, including mine, the product owner is also a manager for some or all of the team members, so it's hardly uncharted territory. It does pose some difficulties, and for some teams is wholly unworkable, but this is what helped for us:

• The manager and the scrum master must have an open relationship. It won't work if the scrum master is afraid to address issues with the manager.
• The manager must have enough self awareness to realize when his actions are causing problems, and have enough self control to step back, at the very least when the scrum master brings it to his attention.
• The team must be confident enough to stand up to the manager when it is in the best interest of the process.
• The best thing may be for the manager to not always be there. When we noticed people doing the daily status update to the manager, he stopped coming to the scrums for a while. Some of our team members are still uncomfortable with increasing an estimate with him present, so he often steps out during more sensitive parts of our estimation meetings.
• Some meetings are explicit scrum meetings, like your daily standup, iteration planning, and retrospective, but you generally also have design meetings and reviews that are part of making good software. The latter are a lot more important to have experienced technical guidance in than the former.

You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead?

If you want to make use of that hour you have with the whole team, you may want to consider running a retrospective. You can introduce the retrospective with simple honesty on your part: tell them that you don't feel the previous meetings have been productive and that you want to try something different to help everyone to benefit from the hour they have together.

In retros where I work, we will have three columns on a whiteboard, usually putting a smiley, meh, and sad face at the top, e.g. :), :|, and :(. Then the team members get to put anything on the board that they would like to talk about with the whole group.

In the happy column, you can celebrate successes (like congratulating Alice and Bob on the release of a project they worked on together), and you can declare victory with new processes you're trying (like the new bug tracker is much better than the old one).

In the meh column, you put things that aren't exactly happy or sad for the week. Maybe you purchased licenses for the new version of your IDE, and somebody hasn't seen any advantages of the new IDE -- they could put that on the board to figure out if everyone else feels like the upgrade was worthless or if other people have found ways that it is actually superior to the previous version.

In the sad column, you put things that haven't gone well for the week. Identifying the pain points for the week is probably the biggest benefit of a retrospective in my opinion. The whole team gets to discuss solutions to a real problem. On teams that all work on a single codebase for instance, someone might say that the FooBar class is unmaintainable and has been the cause of hours of debugging. Suddenly you find out that everyone else on the team has also lost multiple hours this week to FooBar, but nobody spent any time to clean it up. In that case, the team may collectively decide it makes sense for someone to spend time refactoring that code next week.

After everyone writes their proposed topics on the board, I like to briefly go over each topic and have its author give a 10-30 second explanation of the topic. This section of the meeting is easy to derail, so you'll have to be careful to keep people on topic -- e.g. someone will say that X has been a problem, and someone else starts talking about a solution to the problem; solutions shouldn't be discussed until after voting. In introducing the topics, you may find ways to group together multiple, closely related topics.

After the introductions, everyone gets three votes that they can distribute among the topics however they see fit. Finally, the votes are tallied, and whichever topics have the greatest number of votes is what the team discusses. For each topic, determine if there is an action that needs to be taken. Celebrating a success usually doesn't have an action item, but refactoring specific code can be assigned to one person. The action items should usually be completable by one person, but sometimes they are "whole-team" action items such as being mindful of having good commit messages.

Most retros tend to focus on topics in the sad column, and virtually no retros discuss everything that's written on the board. The meeting tends to finish whenever time is up. Immediately after the meeting, see that the action items are assigned to specific people; do this in whichever way makes sense for your organization.

I've had great success with retrospectives. They are a great way to build cohesion in a team, and they're a great way to reflect on the previous week and to refine your process. I think that if you try these out with your team, they will be much more engaged for your meetings.