How to manage a schedule across multiple PMs when using a single team for both development & support?

Question

I work for a small company (22 people), whereby the development team works on both new features (40%) and support/maintenance tasks (60%).

We have several account/project managers who prioritise the clients tickets within Jira using a Kanban board, and we have daily stand-ups to discuss the tasks at hand, the progress, and any blockers.

The main frustration for everyone is the lack of visibility when allocating work out to a developer, and this leads to issues with some developers frequently being in high-demand. This often results in individuals getting pulled from one project to another, because PM A and PM B both have deadlines to reach, yet PM A and PM B are not really aware of each others priorities.

Sadly we're not in a position to split the team into 2 teams specialising on development and support; and with 20+ customer accounts to develop/support/maintain it would seem unrealistic to plan a developers schedule too far in advance. This is mainly due to the level of complexity and urgency of the tickets we get through, which can take a developer out for a considerable amount of time.

We've discussed internally about creating a high-level schedule for project work, and the resource needed, but we're stuck on how to progress this further because of the maintenance/support work, which makes up such a huge part of our business.

We've seen some tremendous benefits having introduced a PM methodology like Kanban, and we've seen some huge improvements in customer satisfaction and our overall cycle time. But I think we now need a clearer way of defining our schedule and giving the team visibility on this.

Any advise on how you think we might tackle this would be gratefully received.

Answer 1

You should clearly define time slots within a week where the required resources should be 100% dedicated to your project.

Like, John works Wednesday's and Friday's afternoons, Mary works Monday's, Wednesday's and Friday's full time, and so on. Incorporate the resource availability in your schedule in order to have an accurate depiction of task durations.

Doing this way, your projects may take longer, but if John or Mary need to be moved to do something more urgent, your schedule may not suffer because you will have the opportunity to exchange the dedicated days.

Based in your schedule, comunicate these resources availability to the broader audience (other PMs and SDMs) and have regular Resource Planning meetings with all the PMs/SDMs so that the overall resource allocation can be known, shaped and agreed by all without bringing unforeseen impacts to anyone.

Also, you guys should have or nominate someone who can make a decision on the conflicting priorities (in cases where people cannot reach an agreement) and take the ownership on its decision impacts.

This is a very common problem even in bigger companies that perform under the utilisation model, and the key is to have a strong Resource Plan communicated and agreed by everyone.

Answer 2

The main frustration for everyone is the lack of visibility when allocating work out to a developer, and this leads to issues with some developers frequently being in high-demand.

How is this happening? Kanban is typically used with "pull work" methodology, so work shouldn't be "allocated" to a specific developer.

You have visibility of the work (thanks to Kanban and Jira). You have visibility of the resources (central pool of Devs). It sounds like you have the pieces of the puzzle there, just no adherence to process to make it work.

How are you currently enforcing your ratios (40/60 split)? How is it meant to work (even if it isn't)? This process is vital if you want it to actually work.

How is the Kanban board not providing visibility for PM A and B of their competing priorities and where they sit on the priority list? It should be doing that.

Edits Below in relation to questions

You mention that we shouldn't allocate work to individuals, but in our scenario each developer has a different strength / level of expertise or simply has a deeper understanding of a customers setup.

Then you're creating bottlenecks. Wouldn't there be overall efficiency to be gained (even if it were in trade for some short term pain) to getting developers cross-skilled? If Dev A has always worked for Customer X...what happens when Dev A is sick? Or leaves the company?

If there is some reason why your devs can't cross-skill then Kanban as a method can still work as each person pulls the highest priority item that they can work on with their skillset. Although it sounds like the underlying problem in this instance is the lack of team cross-skill and over-dependence on individuals. That isn't a good base to work from going forward.

But if you have say 5 projects or more (along side your support work), which all have different PMs, which at some point in the development all need developer A, then how do you plan that within a Kanban board, so you're not all needing him at the same time?

You can't. Basically what you're saying is "I have one lane on my highway. How can I get 5 cars to drive on that 1 lane at the exact same time?". No matter what methodology you use, you can't. The underlying problem is a capacity problem (the 1 lane). And the capacity problem seems to be caused because you're allocating individuals instead of resources. A developer should be a developer. Yes they'll have areas of expertise, but they should be cross-functional enough to cover more than one niche or one customer.

Even if you split teams it isn't going to address the problem. PMs should have no say as to what resource they get from the pool, they get whoever is available and has the skills to work on their job at the time that it's the highest priority. That is efficient. The way you've currently got it is very inefficient.

Answer 3

You have not mentioned if you are an ISV working on one or more products which you also support in terms of defects and enhancement requests from customers. But assuming you are, you are in a very similar position to what we do. Our team is also similar sized - in fact smaller.

We are a product company (and we build and sell a Kanban product - so we put that to good use in our development environment). We have the exact same challenges that you have mentioned. Sales and Support wants us to prioritize customer-reported defects (very justifiably so) and also customer-requested feature enhancements. Product Management wants to build out the roadmap, specially new features that will help us differentiate ourselves in the market. Engineering itself wants to make performance/ security related enhancements as well as work on technical debt.

We have solved these issues by using the following processes and rules for ourselves -

1. We have kept the Dev team together (not split them by Dev and Maintenance/ Support - the latter always get disheartened if left to do only support).

2. We have a Kanban board with horizontal swim lanes for each product - and each lane has an input (Ready) queue with a well defined and respected WIP Limit. The only team that has its own lane is the Documentation team. We do have some level of specialization between client-side and server-side programming, but by and large we try as much as possible to rotate team members between different product modules/ technologies.

3. We have a weekly Replenishment meeting that is held between Sales/ Support, Engg and Product Management and we jointly decide what items will make it to the Ready queue next. This is respected by everyone and is managed on a daily basis between the Product Manager and the Engg Lead. The one IMPORTANT thing we have also decided is that between Prod Mgt, Sales/ Support and Engineering, there is a reasonable fixed allocation of new items - roughly about 60:25:15. So at any time, both the Ready queue and the main WIP columns should exhibit this ratio.

4. We have a daily standup that resolves any conflicts as also deals with any expedited items (usually production defects ONLY) - and we limit the expedited items to 1 in progress at any time.

Over the last 4 years, we have reworked our board design 3 times to make sure we have a process that works for us.

So, I'd say the key things for you to tackle are -

1. Define a prioritization/ replenishment process that everyone agrees to and respects.

2. Make sure the Backlog and the Replenished items are fully visible. If needed, define a special Backlog lane on the board itself (though, I'm not sure JIRA supports multiple Swim Lanes)

3. If needed, define personal WIP limits for each team member so no one is overburdened.

4. Establish a meeting cadence for Replenishment meetings (weekly?) and Retrospectives (monthly? release-end?) which allows all stakeholders to particiate in critical processes that ensure smooth flow of work for the entire team.

5. Over a period of time, figure out cross-training of your team members to make it possible for them to handle multiple modules/ work-types.

6. Review and reorganize your Kanban board to reflect the real process your team is following/ needs to follow.

HTH!

Answer 4

Couple of observations (which I admit are shots in the dark because I don't have the insight into your project that you do).

1) Your PM's are failing. PM's are judged according to whether projects close successfully. By not communicating with one another and deconflicting resource demands, the PMs are both failing their responsibility to their team, and to their sponsors. The PMs' must coordinate with one another to ensure mutual success. (not TTK Droid seems to have said this with more tact than I have.)

2) Maintenance/support isn't a project; it is possible that it is a portfolio of tiny projects, but unless there is a discrete and unique outcome, it isn't a project. I'm not saying this to split hairs, but to acknowledge that whatever "project management" is being done by that PM needs to be adapted. The PM in charge of maintenance is in an orange jumpsuit job - s/he cannot succeed, because the needs of maintenance/support are infinite. There is no way that this PM can negotiate in good faith with the development PM, because the support PM's need for infinite resources cannot be compared with the development PM's need for finite resources. I think that Kanban can be your salvation here, but it will require effort to plan.

3) I'm not in software development, but as I understand it, some companies have solved this by establishing a proportion of support. e.g. "We will devote 70% of our time to development and 30% to support". Then the two PM's can negotiate for individual staff time based on that proportion.

4) Both PM's are (in my not so humble opinion) obliged to communicate the problem to the respective sponsors, and propose a framework for an answer that will satisfy all.

Good luck - sounds like a problem with no good solution.

Answer 5

From some of your other responses it's clear your 'team' is really a group of individuals with their own specialities. So, for example if the team doesn't complete some work it is unlikely it was in more than one developers power to have made it happen. Hence, they are a group of individuals, not a cohesive team.

The best thing you could do long term is to make it so work could be shared between developers. There will likely always be areas of the code base and certain specialities individuals will have but if you can minimise this for routine work you will go some way to solving your issues. The other benefit of this is that you are at less risk of losing serious amounts of knowledge if a single developer leaves for some reason.

Short term... I'd suggest multiple backlog lists or labels (not sure best way to model this in Jira) so you can have one for each developer and one for general work anyone can do. This should make it clearer what is on an individuals plate so the PMs can be more aware of likely timescales when trying to schedule something. This is certainly not ideal, but it's something you can implement quickly while you move towards the above.