I know that the agile concept "requires" the teams to be small, autonomous and self-sufficient.
But if the diversity of projects objectives and required technologies make it impossible to form small and autonomous teams because each member controls a specific technology and thus must work in 10 different concurrent projects... how can I define my agile team?
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'm working in a business unit of about 50 people. We are working just 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. We have about 150 ongoing projects, 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.
On top of that today we have lots of bottlenecks: each individual member of the group has a specificity required in various project, and the other members are not proficient (enough) on this other technology.
So I find it really hard to redefine the structure of our business unit to be abel to generate Agile-compatible teams where all members are only allocated to one project. Same complexity to tr yto allocate a project to only one of these agile-teams... We need that all developpers 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?