Relatiile intre diversele roluri tind sa duca la formarea unor subgrupe in cadrul echipei. De regula, aceste subgrupe sunt:

• grupul pt. arhitectura;
• grupul de analiza
• grupul de proiectare;
• grupul de implementare;
• grupul de instalare;
• echipa de interventie rapida ("tiger team").

Grupul pt. arhitectura

Este format din arhitect si unul sau mai multi abstractionisti. la distribuirea sarcinilor in cadrul acestui grup se va aplica urmatoarea regula: responsabilitatea pt. o categorie de clase va fi alocata unui singur abstractionist, iar responsabilitatea structurii de ansamblu - unui singur arhitect.
Astfel, arhitectura globala a sistemului este controlata de arhitect, iar microarhitectura fiecarei categorii de clase este controlata de un abstractionist (chiar daca acesta poate avea in sarcina mai multe categorii de clase; ideea este ca de aceeasi categorie de clase sa nu se ocupe mai multe persoane).
In cazul proiectelor mari grupul de arhitectura poate fi suplimentat si cu alte roluri, ca: asigurarea calitatii, integrare, analiza.
Grupul de arhitectura trebuie creat la debutul proiectului si va fi mentinut pana la faza de intretinere (chiar daca in acest punct grupul va include alte persoane decat initial).

Grupul de analiza

Se formeaza la inceputul ciclului de viata, cand are loc colectarea cerintelor. De obicei acest grup este format din analisti, la care se adauga eventual controlori de calitate si o parte a grupului de arhitectura (care trebuie sa cunoasca indeaproape toate detaliile privitoare la cerinte).
Rolul echipei de analiza este mai estompat pe durata fazei de proiectare, urmand sa devina mai pregnant in portiunile de inceput ale fiecarei iteratii din faza de evolutie.

Grupul de proiectare

Se formeaza spre sfarsitul fazei de analiza, cand incep sa fie explorate diverse alternative de proiectare.
Acest grup este format din abstractionisti si cativa ingineri de aplicatii, fiind supervizat de arhitect.

Grupul de implementare

Incepe sa se formeze in faza de analiza, dar varful de activitate il va avea pe durata evolutiei.
In cazul proiectelor OO de obicei se intalnesc o multime de grupulete de implementare care se ocupa de:

• concretizarea comportamentului unor scenarii (ceea ce presupune asamblarea unor clase in mici programe, de catre ingineri de aplicatii);
• realizarea implementarii unor categorii de clase.

Grupul de instalare

Este responsabil cu instalarea sistemului la beneficiar. Grupul este condus de un integrator si ocazional, poate fi suplimentat cu abstractionisti sau ingineri de aplicatii si cu redactori de documentatie.
Grupul de instalare se formeaza la inceputul fazei de proiectare astfel incat procesul de instalare sa poata fi pus la punct inainte ca prima versiune sa fie livrata. Varful de activitate al acestui grup se atinge in faza de evolutie.

Echipa de interventie

Are ca scop investigarea unor aspecte neclare ale sistemului, validarea unor alternative de proiectare, depistarea si inlaturarea unor bug-uri. Altfel spus, echipa de interventie asigura managerului de proiect resursele necesare pt. a ataca riscurile neprevazute care pot sa apara.
Echipele de interventie sunt grupuri puternice si adesea solitare. Ele trebuie constituite din persoanele cele mai competente in domeniul problemei de rezolvat, cum ar fi: detectivi abili in cautarea si distrugerea bug-urilor, arheologi software suficient de rabdatori si minutiosi in descifrarea codului unor programe vechi, mostenite, sau programatori hiperactivi, capabili sa incropeasca prototipuri in cateva ore sau zile.
De regula, dimensiunea medie a unei echipe de interventie este de 1-2 persoane, iar durata ei de viata este de 1-2 saptamani. Identificarea rolurilor si a grupurilor care formeaza o echipa de dezvoltare sta la baza conceptului de echipa fluida, adica o echipa in care membrii nu sunt "incremeniti" pe anumite responsabilitati, ci sunt repartizati pe roluri in functie de necesitatile proiectului si de aptitudinile personale. Cu alte cuvinte, pentru un proiect se stabilesc intai rolurile necesare, apoi sunt identificate persoanele potrivite cu rolurile.
Conceptul de echipa fluida poate fi adaptat la orice dimensiune a unui proiect, respectiv a unei echipe. Astfel:

• la proiecte mici, cu echipe formate din cate un singur membru, acel unic membru va juca toate rolurile necesare, dar nu simultan;
• la proiecte ceva mai mari, la care participa 2-7 oameni: daca echipa e formata din 2-3 oameni, fiecaruia i se vor repartiza cateva roluri, dar unul dintre ei se va distinge si specializa ca arhitect; daca echipa numara 5-7 oameni, devin evidente specializarile de arhitect, abstractionist si inginer de aplicatii.
• la proiectele de dimensiuni modeste, cu 1-2 duzini de membri, incep sa se evidentieze si rolurile secundare; la aceste dimensiuni ale echipelor incepe sa apara o corespondenta directa intre arhitectura sistemului si structura echipei, adica ierarhia categoriilor de clase se oglindeste in ierarhia arhitect-abstractionisti-ingineri de aplicatii.
• la proiectele mari regasim aceeasi structurare a rolurilor, dar la o scara mai mare, in sensul ca fiecare abstractionist la randul sau este un arhitect pentru bucata de sistem de care se ocupa si in aceasta calitate conduce o sub-echipa.

In ceea ce priveste distributia in timp a activitatii corespunzatoare diferitelor roluri, se poate spune ca exista 3 etape ("valuri") distincte:

• mai intai intra in actiune arhitectul, care va ramane pe toata durata dezvoltarii;
• urmeaza angajarea abstractionistilor, care incep procesul de descoperire in faza de analiza si il secondeaza pe arhitect pe durata proiectarii;
• al 3-lea val este format din inginerii de aplicatii care au varful activitatii pe durata fazei de evolutie.