19

Full disclosure: I am working as a lead developer for a team of around 6 developers, not as a project manager. But this seemed like a good place to ask.

Background: Recently the team is covering more client support requests than we are larger developments. This makes it hard working with Scrum methodology (as we would normally) because we cannot plan multiple weeks ahead at a time as we may get critical support requests. For this reason we are looking to adopt kanban to manage the team workload.

My question: when working (with or without kanban) on a more support oriented workload, what are the differences in responsibilities between the project manager and lead developer?

Specific examples include:

  • who is responsible for managing support requests raised by the clients? Who should be monitoring for new requests/tickets and who should triage them as they come in?
  • who is responsible for managing team workload and monitoring individual developers progress?
  • who is responsible for setting the release schedules and which issues/tickets constitute the next release?
  • who is responsible for prioritising the support requests between multiple customers?

P.S. I know that roles and responsibilities vary a lot between different companies, but in my company the roles seem to be slightly blurred in some areas so I would be very interested how other people define these roles.

  • Hi Rob, I think your question is very appropriate for our site. Thanks for putting so much effort into clearly outlining the background and the actual questions. +1 – jmort253 Oct 10 '12 at 8:11
  • Thanks jmort. And thanks to Deer Hunter for sorting out my grammar! – Rob Bird Oct 10 '12 at 16:49
  • This is a great question, something I've been recently pondering myself. Looking forward to the answers. Thanks Rob. – Kosta Kontos Oct 16 '12 at 7:25
  • The company I work for has the support liaise with the PM via an Investigation. The PM Reviews it and determines whether he can answer the question based on documentation, or he will assign a various amounts of resources, based on the severity level of the issue. Those resources then prioritize the support request and the new features/enhancements they're working on based on the priority level. Never do the developers stop working on backlogged issues and new stuff, but they're all available for support if required. Devs then review everything and provide the answer based on an SLA or logabug. – Randy E Oct 18 '12 at 22:07
10

IMO, all four of the activities you cite are things that should be handled by a project manager and/or product manager. If you are currently performing this activities, then you are acting as project/product manager and lead developer. (Time to ask for a raise.)

I would structure things a little differently rather than just adding kanban to the process (and this is not addressing the fact that you probably need a real PM/PM). If you just add kanban, it is probably still going to be difficult to get new development done because dev cycles are going to be chopped up by the barrage of support requests. You need to avoid the chop.

I would structure things by assigning at least 2 of the devs to new development per sprint. The devs can rotate from sprint to sprint, but you need to have some people dedicated to new development and generally unavailable for developus interuptus. The dedicated people should not be pulled off the new development unless the support work absolutely, positively cannot be handled by other developers.

During a sprint, if the support developers run out of support-type work, then they can either help the feature developers finish the features selected for the sprint, or they can maybe pull something out of the backlog to work on (it will be tough to keep this to pure scrum in this way).

But this will ensure that you are always making consistent progress on the feature backlog while keeping up the expected support.

And what's with all the support issues? Are these quality problems or something else? If they're quality problems, then it sounds like you need to do some serious work on the quality control processes.

  • Great answer Kent (and not just because you said I should ask for a raise!). There are lots of interesting points in your answer which are very relevant to my situation. Thanks for addressing the specifics of my problem. – Rob Bird Oct 10 '12 at 16:59
  • I'm not entirely sure how we would implement your suggestion though, as it is a little bit more complicated in our situation. The team actually covers about 6-7 projects (some more active than others so resource levels vary per project) and the developers are each familiar with a different mix of projects. The work varies from data or configuration changes to bugs and small feature developments. – Rob Bird Oct 10 '12 at 17:02
  • Ah. I didn't realize that you had the team spread out over so many different projects. That changes my answer. Perhaps Kanban would be more appropriate in your situation if developers are mostly dedicated to their projects and you can have support requests coming in on any of the projects at any time. That's a tough situation to deal with from a "team" perspective. – Kent Oct 10 '12 at 19:12
9

My rule of thumb:

  • Lead developer is responsible for the technical and architectural well being of the product

  • Team lead is responsible for the team cohesion, team improvements and the well being of the developers

  • Project manager is responsible for the coordination between projects, customer development and delivering the project on time by helping/supporting the teams which are involved in the process

If there is a situation when the responsibilities aren't 100% clear, then the lead developer, team lead and project manager shall have a conversation and make a decision together. Team workload is a good example: there is a demand from project management, and the lead developer and team lead should response to this demand and tell project management if the team can take more under the current circumstances without risking overburdening or product quality.

  • Thanks for answering Zsolt, this is a very useful rule of thumb. I was actually looking for specifics though, so for example you didn't mention who was responsible for managing team workload or tracking of support requests. – Rob Bird Oct 10 '12 at 17:06
  • @RobBird you are absolutely right, those are missing from my answer. I'll add them shortly. – Zsolt Oct 11 '12 at 6:57
  • @RobBird, done. I used the team workload in my answer. Concerning support requests: it is again a conversation between the three. Project management should make a decision when to take care of the support request using the input from the lead developer and team lead. If the team has some slack then it is an easy thing, or it may happen that the next feature will solve the issue etc. There is a pattern here. Project management makes the decisions, the rest should give information and support so that PM makes good decisions. – Zsolt Oct 11 '12 at 7:44
2

I would treat the support requests as issues and track as you would for projects. In short the PM should be managing all scheduling and putting processes and systems in place that allow the developers to do their work with minimum interruption and allow the lead developer to work on quality, code review, etc. The PM should be seeking the lead developers advice on all aspects of planning and scheduling. And all decisions around this should be backed up with discussion - i find its useful to have an all team meeting on a Monday morning to review the week's schedule, then a meeting between lead developer and PM on a Friday to review the week and update the following week's schedule.

I've added responses to each of your questions below:

• who is responsible for managing support requests raised by the clients? Who should be monitoring for new requests/tickets and who should triage them as they come in?

The project manager should be the first port of call for any new work coming into the team, and developers should have a system for logging requests as issues if the client goes direct to individual developers. The developers should have processes and a PM in place that allows them to focus on their work and not the scheduling of new work (other than prioritising their existing workload). Certainly the PM should be liaising with the client to make sure that support requests are raised via him/her. The PM should attempt to triage the requests or speak to you as lead developer if any more information is needed.

• who is responsible for managing team workload and monitoring individual developers progress?

The team lead should monitor workload and report any issues to the lead developer and PM. An astute PM should be on top of this because any workload conflicts will affect delivery of the projects/closure of issues. The lead developer should be aware of workload and progress but the accountability for ensuring work is done on time sits with the PM.

• who is responsible for setting the release schedules and which issues/tickets constitute the next release?

The PM is accountable for this but this should be done in collaboration with the lead developer and team lead.

• who is responsible for prioritising the support requests between multiple customers?

The PM again should be doing this but also in collaboration with the lead developer and team lead to ensure that any prioritisation will not adversely affect any existing work.

1

Looks like you have transitioned to the software maintenance phase, and are heavily multitasking while being apparently at least a bit understaffed (hence @Kent 's intuition about pay raise). Cannot help thinking that two of your questions regarding triage & priority setting a) overlap and b) cut across the competencies of team members:

who is responsible for managing support requests raised by the clients? Who should be monitoring for new requests/tickets and who should triage them as they come in?

who is responsible for prioritising the support requests between multiple customers?

Since triage involves knowledge of customers' business (the monetary and reputational value of each support request) and specific estimate of man-days per request, your PM (or the most externally-oriented team member) and you (or the developer generally responsible for a particular project) as the lead developer have to come to consensus on scheduling and resource allocation.

who is responsible for managing team workload and monitoring individual developers progress?

These are two different functions.

  • Workload management is just another name for resource allocation/scheduling (see above); there should be as little request reshuffling between developers after initial allocation to avoid unproductive time losses.

  • Kicking developers' rears to get things done in time is more of a PM's role.

As for the remaining two questions:

who is responsible for setting the release schedules and which issues/tickets constitute the next release?

there is nothing useful that an outsider like me can say. Doesn't your company have a release policy in place? If you and your PM have solved request prioritization problem, the scope of the next release logically follows from company-imposed time constraints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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