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 -
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.
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.
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 -
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
Cheers!
