How to structure our organization and define agile teams in a multiple concurrent projects context?

Question

I know that the agile concept requires the teams to be small, autonomous and self-sufficient, but how to organize teams when forming small and autonomous teams is almost impossible as each member controls a specific technology and thus must work in 10 different concurrent projects?

Any best-practice on defining a business unit structure to be able to apply agile management and cope with concurrent projects and understaffing issues?

I find it really hard to redefine the structure of our business unit to be able to generate Agile-compatible teams where all members are only allocated to one project.

Same complexity to try to allocate a project to only one of these agile-teams. We need that all developers work concurrently on various projects.

I could do a complete business unit Kanban, but we are 50 people, so I anticipate hell when having to manage Backlogs and team meetings.

Any advice on if/how to structure our group to allow for agile project management?

---

Further details

Business unit structure:

• about 50 people
• about 150 ongoing projects
• working like a small company with Project managers, SW developers, mechanical and electronics engineers, workshop technicians etc… with a very wide field of technologies to manage
• all customer specific projects (we do not develop and sell products, but specific "engineering" projects)
• minimum project time 6 months, maximum 4 years
• R&D projects only, so requirements are changing during the project

Projects have their uncontrollable lifecycle with intensive periods followed by lengthy dead time due to delay in the clients feedback, waiting for purchased components, or just fixed long timeframe but at low intensity.

Bottlenecks we have:

• each individual member of the group has a specificity required in various project
• other members are not proficient (enough) on this other technology

Answer 1

Create stable scrum teams of about 5 to 9 people per team

To create stable scrum teams, follow these recommendations from Roman Pichler:

1. First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role... Having the right individuals on board is most likely the biggest success factor for any development effort.

2. Second, minimize any changes to the Scrum team within and across releases. It takes some time for a group of individuals to become a true team – a tightly knit unit with members that trust and support each other and that work together well.

Group the 150 projects into 5 or 6 clusters based on key technology or, preferably, by market. Assign each cluster to one team. Of course, you will find that sometimes the skills needed to complete a project is on another team. Plan for some cross training. Hold twice weekly Scrum of Scrums meetings to coordinate such cross-team dependencies and priorities.

Answer 2

We are in a similar situation, where we have a few 'experts' that need to be spread between teams, however our core teams sound slightly more stable. We have a long term goal of fully independent teams, but in the short term our experts are sitting outside of teams and either slot into a team for a sprint, or work with multiple teams at once. They don't really do any work independently and are focused on helping teams learn how to do their tasks, to reduce the dependency on them over time.

Answer 3

Damien,

You could look at the overall objective of the project and then divide it into EPICs. These EPICs can have EPIC managers. The EPICs then get divided into Features and Components. There will be overlap from one team to another as they will be cross-functional.

You might want to look at Scaled Agile Framework for complex projects on longer durations.