Twice now I have encountered an office where there are many projects being done simultaneously. The two different approaches I've seen to this is splitting people up into very small (1-2 people) dedicated teams and the opposite where everyone works on many projects (perhaps 1-3 projects) and split the time they work on each.

Luckily I was hired to work on a single project full time, with the goal of helping "refine" the software process for the group (many people work multiple projects). I have had multiple years in Agile Scrum development and have ran my own small Scrum teams with some success in the past. I have been trying to slowly introduce Scum concepts but it is difficult with programmers stuck in their ways; i.e. I am swimming against the current getting everybody on board with a ticket system. It is not however impossible to implement change.

That being said, I was wondering if there is a predefined methodology for a team working multiple projects or if hacking through each problem as it arises and hand crafting our own is the right way to go (the hacking will probably happen regardless). Our customers generally show up with money and ask for features/new development/new projects which pull people away from any dedicated tasking, so it would have to be able to handle this flux of man hours. Any input appreciated.

  • Kanban sounds like a good fit for multi-project team. But it might be problem if people are averse to tickets.
    – Euphoric
    Mar 15, 2016 at 14:25
  • 2
    Being averse to a ticket system is an unreasonable POV. How are they tracking their work now? Mar 15, 2016 at 14:29
  • Most have gotten on board, there is still a straggler or two and I'll address that. Moreover I'm wondering if trying to shoehorn Agile Scrum is the right way to go, or if there is something better out there.
    – Danny A
    Mar 15, 2016 at 14:37
  • Better in what sense? I have heard that, if you don't fully embrace agile/scrum/whatever, you're not really practicing Agile. As a developer, I would be more receptive to something that helped me stay organized and cohesive within my team. I would be averse to some half-assed Agile that was just there for the sake of being Agile. Mar 15, 2016 at 14:42
  • Obviously Agile for Agile's sake is not the goal, I'm trying to keep my team cohesive and organized. Better in the sense that you have had a successful experience with a specific methodology for the situation I'm describing.
    – Danny A
    Mar 15, 2016 at 15:10

2 Answers 2


If you can't change your team, work on a model that fits the people you have. You can gain some flexibility with fewer options.

  1. Large/lengthy projects are identified as those requiring 5 or more people. Assign them and have them focus on that project. Substitute people only if necessary (Someone leaves.). Hopefully the large projects bring in enough money to give them some priority. That's not always the case.
  2. Everything not belonging to a large project, is just put on a ticket list and individuals pick things and work on them. This gives the most flexibility and can force some people to get away from their comfort zone and learn something different. This also encourages everyone to help each other out.

The 1 and 2 team project assignments just don't give you any flexibility for holidays, sick days, new projects etc. It just gives people the option/excuse to cling to a certain area.

If you try and just let everything be a ticket item for everyone to pick and choose, then you run into the risk of some items never getting addressed. Typically they'll be the large projects that take a long time that no one wants to take on (The Year Without Pants is a great story about this at Wordpress.)

If you could select all the developers, you could adopt a particular system. Menlo Innovations takes XP programming to the extreme (no pun intended). They always work in pairs on every line of production code. Every programmer is on a rotating schedule so they change partners often and rotate projects every few weeks. This is not for most people, but since they have everyone on board, they make it work.


I'd like to take a stab at this (and it has become a long answer - please bear with me!)

From your question and the comments below that, it would appear that -

  1. Yours is a custom application (product) development shop. You build products for customers as a one-time activity; the customer owns (and might maintain) the product after you deliver it to them.

  2. On occasion, quite often perhaps, the customers come back and ask you to build extensions to their product(s) or perhaps fix defects in them. Since this might happen long after you built the product for them, your team that did it is off and doing other things or worse, they have left your company. Since the customers are paying money, you'd obviously like to do the work and get that money - and of course (continue to) retain a happy customer.

  3. You can't have product-specific teams clearly, since you don't own the products. It is likely you guys work on one technology (.Net or J2EE or Ruby or whatever) - or perhaps multiple technologies, where you have technology-specific teams perhaps?

The problem you are facing is not just of introducing Agile, you are likely facing challenges around - how to quickly respond to a new project request (making customer commitments), how to form the team which will take up a new project (which of the right-skilled people are most available and/ or by when), how to keep track of the overall work going on at any point of time and finally, how to track and plan for incoming demand. Am I on the right track? I hope so!

One other thing which is important (and it's not clear what your situation is) is what is the size of a typical project? Does it take a couple of days or weeks or months to do a typical sized project - and how many people are needed for an average project? The larger the project, the more it makes sense to form a dedicated project team, the smaller they are, the more likely that each person will handle multiple projects.

This situation is not too different from the scores of software services companies that work on custom product development projects, where teams are formed for doing projects, disbanded after the project is done, and reformed when a new project comes along. Typically, they are dealing with multiple technologies, multiple customers and of course multiple projects. AND they may be specialized in one or more specific verticals - such as Financial or Insurance or Banking products - They'd like to build strong expertise in technologies and verticals, manage their people well (high or profitable levels of utilization) and of course have long-term relationships with a growing number of customers to whom they deliver high-quality products. And of course, they want to run all their projects successfully - to time, quality and budget goals!

Depending on the size of your organization and the strategic direction they may want to go in, there are multiple options for you to organize overall, and handle incoming projects accordingly.

If yours is a small or mid-sized company - some of the following might make sense for you -

  1. Your most immediate challenge might be to manage well the incoming project demand, the mix of skills you have and to coordinate overall work well.

  2. If it makes sense, and if possible, you could organize your teams around skills - so you might have server-side developers, front-end, UI/ UX, database, etc.

  3. As each project comes in (or is being considered by your sales or management team), you might break it down by specific deliverables (tickets, user stories or requirements - whatever your current method of work-breakdown) that each team might work on. Not all projects will need all teams.

  4. Once a project is taken up, it's specific user stories (or tickets) get dropped into each team's "backlog" and each team takes them up as they finish their earlier work.

  5. Once all the individual tickets for a project are completed, there might be an integration stage followed by some system test and a UAT after which the product is released to the customer.

  6. At any point, each team can be handling tickets from different projects/ customers - and their sequence/ priority could be defined jointly by the team and your management/ sales.

For this situation, using a Kanban board such as the one below should help tremendously.

enter image description here

A board such as this helps visualize in-coming demand, the current work being handled by different teams and the relative as well as overall load on the teams.

You can get started with a whiteboard and multi-colored stickies. However you mau also want to consider a good Kanban tool, such as the one we have developed (SwiftKanban), can help you with defining custom swim-lanes for each team or type of work, defining WIP (work-in-progress) Limits that help manage and control the loading of each team, and will provide you data and metrics (like those shown below) in a very short time of your teams' delivery capability, that will in turn, help your management/ sales teams to make realistic commitments to your customers.

enter image description here

Another option - if your individual projects are really small (more like Helpdesk tickets) - you might even be able to manage with a simpler board that separates the work by work-type. Each could be handled by a different team, or your overall team handles all work types.

enter image description here

Larger shops would like to try and build long-term continuing relationships with customers and maintain dedicated teams for each customer against a minimum guarantee of work from these customers. In such cases, you could have a board that has swim lanes defined for each customer - or even a board per customer, since there might be confidentiality aspects.

Besides just the Kanban board with its benefits of visualization, WIP Limits, making policies explicit and optimizing Flow - there are also regular lean/ agile management processes to be looked at, initiated and followed - so the overall coordination and management of the work becomes smooth. These of course include Daily Standups, Weekly (or even Daily, depending on incoming volume) Replenishment Meetings that prioritize incoming projects and help teams decide which order in which to take up new and existing work, and also a monthly/ quarterly Retrospective that helps decide what's working, what is not and what needs to change.

If you have not yet invested in some Kanban learning/ training, a good place to start would be to read David Anderson's book - "Kanban - Successful Evolutionary Change for your Technology Business".

Finally a couple of words of caution - 1. Kanban is not a methodology (a common misperception)! It is a method of improving in an evolutionary - gradual - manner what you do currently.

  1. A specific tool like Kanban or methodology like Scrum is not going to solve your problem. What you need is to define clearly what problem(s) are you trying to solve - including analysis of why these problems are there currently - and what needs to be done to solve them. Kanban may be part of the overall solution that you and your team come up with.

Sincerely hope this helps. I'd be happy to answer any specific questions you have here or offline.


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.