A Scrum Master lets the technical manager use his or her skills more effectively, and mitigates the Catch-22 of technical management — promoting a strong coder to the point that he is no longer coding.

Like more and more software development organizations these days, my team practices a hybrid of Extreme Programming (XP) and Scrum practices. The blend works out quite well because Scrum is generally a management- and business-oriented methodology and XP is an engineering-oriented methodology.

Both approaches share the ideal of a self-managing team. The concept is that the developers have the best understanding of how to approach the work iteration-to-iteration, and they can organize themselves around that understanding better than a well-meaning manager who is less intimately involved with the work.

If you accept that as true (and I do), where does that leave the technical manager? Titles vary, but I’m specifically thinking about the person who the developers on the team directly report to in the org chart. Let’s call this person the Development Manager.

Many very good Development Managers in non-Scrum organizations are hip to the insights I described above. They realize that their teams are best qualified to make technical decisions. They know their team’s time is very valuable and that each developer needs uninterrupted time to get into the zone (either solo or with a pair) and get quality work done. Armed with this info, these development managers make themselves “servant leaders.” They dedicate themselves to “protecting” the team — making sure they never have to attend unnecessary meetings, are insulated from corporate politics, and don’t have to deal with issues like software licenses or faulty hardware.

This servant leadership I just described is defined in Scrum as one of the core responsibilities of the Scrum Master role. The remover of obstacles. Many XP projects have the role of Iteration Manager, which also shares this responsiblity.

So where does that leave our Development Manager? Let’s assume for this conversation that he was promoted or hired into this role after proving that he was a competent developer and had good communication skills. (For someone thrust into the Development Manager role with no hands-on development experience, I would suggest that servant leadership is probably the best approach, and that he might function day-to-day in the Scrum Master/Iteration Manager role.)

Here is my take on the appropriate responsibilities for the Development Manager:

1. Managing a self-managing team mostly means getting out of the way. He or she must actively and/or passively empower the team to self-organize.
2. Hiring is the highest yield activity of any manager, and is exponentially greater when hiring developers. He or she must pull out all the stops in hiring the best developers possible.
3. Agile methodologies are team-oriented — the team works in pairs, shares code ownership, designs together, sets goals together, succeeds or fails together — but each individual is on her own life path. The Development Manager must connect with each team member as a person, support his personal and professional growth, help him discover how he fits into the team and how he can satisfy hist needs for personal recognition and achievement inside or outside of the agile process.
4. It’s likely that the Development Manager also has some role in corporate and departmental strategy as part of the larger software development organization’s management team. Here his responsibility is both to help the overall organization define and achieve its goals, and also to help evolve an organization in which his team can execute, maximize its value, and be happy and healthy.

These are important responsibilities, but unless the team is huge or growing quickly, they don’t add up to a full-time job. Honestly, if it wasn’t for the fact that these 4 points are critically important, I would advocate eliminating the role. If possible, however, the Development Manager should regularly (as in most hours of most days) be part of the team and be a contributing developer.

This is a point of contention, to be sure. I’ve been told on various occasions that I’d have to let go of coding to be effective in my role. I think that’s probably true in teams without a Scrum Master. Bring in a Scrum Master, though, and the Development Manager is freed up to get closer to the people he is managing by rolling up is sleeves and being their peer in the self-organizing work of the project.

Thoughts, questions and alternate theories on the role of the Development Manager in Agile are welcome.

Notes: Reading this post from Rands in Repose helped me crystallize these thoughts. My mental model for my own work at Oxygen (managing a team of 5 full-time developers and 2 consultants) is that I’m 75% an indvidual contributor and 25% a manager. The freedom to focus in at a line-of-code level of detail for several hours a day would never be possible without my colleague Salim doing a great job as the team’s Scrum Master.