2

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?

Thanks

  • Why do you feel you <i>have to</i> associate each member with only one project? Agile means being flexible and responsive rather than rigidly shoehorning people into different silos. – user16583 Oct 17 '14 at 13:58
  • This is what I understood as an important concept: if you want to reduce context switching and gain in eficiency and agility, you should be focused... thus my understanding of working on only 1 project. Maybe the correct thinking should be "one concurrent project only" or "one project only in a sprint"? ??? What do you think then? – Damien Salle Oct 17 '14 at 17:26
3

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.

0

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.

0

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.