We have recently had a new line manager start to manage our Scrum team. He is immensely experienced in our field but is relatively inexperienced at Agile/Scrum. He has extensive technical expertise in embedded software (the team's domain) that would go to waste if not utilised properly.

However, the team is wary of making a line manager part of the Scrum team. The general consensus is that the line manager should not be part of the Scrum team at all. There are a number of issues that may crop up, e.g. the team may start "reporting" to the manager (i.e. a daily status update!), the manager may start to micro-manage team members etc etc.

As it currently stands, he has already said that he feels like an outsider within the team. We really want to make use of his technical skills, we'd be foolish if we didn't because we are a relatively inexperienced and young team of twenty somethings.

What would be the best approach to integrate a senior "technical" line manager in a Scrum team and make him feel like he is part of the team?

3 Answers 3


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.

This seems to me to be a common problem. Old habits being what they are, it is not easy to overcome the tendency of experienced managers to manage people and, all too frequently, problems as well!

However, a Scrum team is a (or would ideally be) a self organising team, and a peer group. If the new guy has tasks to complete from the backlog he has to be integrated into the team. To be effective and accepted he/she has to behave as a team player. And the team has to give him the opportunity to do so.

If the new guy still has line manager responsibilities, even if these involve other team members, then he must conduct these outside the team environment and “team space”. Joining a Scrum team does not isolate people from the day to day necessities of corporate life and no-one should expect that it will. Corporate life goes on! But you do not need a team member who starts the manage the team. The team manages itself and the journey to the goal too!

Lose the job title when participating within the team, and as advised above, get the guy some Scrum training (if he hasn’t had any), explain the ways of working, hold a team event to give everyone the opportunity to bond, and give the new team a chance. I think you may find that this former line manager has skills that the team can benefit from, and not just technical ones.

  • Great answer, I wish I could accept both! Thanks for your input. Sep 20, 2012 at 4:19

The question is whether the manager would be responsible for actively creating your deliverables, or is he really simply providing information and organizational skills. In scrum speak, is he a "pig" or is he a "chicken?" If he's actively helping with the coding and the testing and actually has real tasks with real deliverables in each Sprint, he should definitely be part of the team. Otherwise, he's a SME that you should utilize as needed.

That said, get the poor guy some training in Scrum before he starts messing with team dynamics.

  • he is responsible for our deliverables, so he's a "pig" in Scrum speak. The way the team sees it, he is responsible for quality from a high-level point of view (architecture, integration with other systems like hardware etc.) but not necessarily part of the coding/testing. And yes, we definitely need to get him some training! Sep 19, 2012 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.