A longer answer to a good question asked after my talk at SDC 2009. Someone asked if they should give in and let their line manager attend their team’s iteration retrospective. The short answer is clearly no (in the safe assumption that the manager in question wasn’t participating in the day-to-day work of the team).

However we’ve all come across managers who through insecurity or a desire to control (or indeed both) insist on coming along. In this case there are a number of things you need to establish, in pretty much this order:

Find out why your manager thinks they need to attend. What are their objectives? If it’s to find out what’s going on in the project, tell them to observe your daily stand-ups from time to time, or your review of the iteration deliverables, or improve whatever status reporting you’re sharing. A retrospective is not the place for this. If it’s an interest in what the team is planning to do to improve their practice (from their perspective)/performance (from the manager’s), copy the manager in on the retrospective actions, and arrange a brief meeting to go over them . Turn the (potential) conflict into an opportunity for better communication.

Explain what the retrospective is for. Tell the manager that the team will be talking about tools, techniques, ways of facilitating designing and coding - heavy duty geek stuff - to help them get their day-to-day work done better.

Tell the manager that they’ll inhibit conversation. If you’re lucky, you’ll be able to do this freely and openly, though in the circumstance we’re looking at here it may be unlikely. You might be able to play on their authority (”the team are a little in awe of you”) although that can backfire, as they may see it as an opportunity to break the ice (if this is a genuine desire, ask them to take the team out for beers one evening).

If all this fails, and you can’t escape by (for example) scheduling the retrospective at a time when you know said manager is occupied or away, then you’ll have to deal with said manager in the retrospective. Perhaps you could arrange to do something essential and highly technical (review of SCM branching, discuss pros/cons of moving to a new version of development tools, talk about ways of improving design discussions). Or structure your retrospective as a workshop in which you look in detail at some aspect of the project (performance in a particular area of code or infrastructure for example). All being well, this will get the message across. Then (of course) hold the real retrospective (sans Manager) in the coffee shop or pub afterwards.