Deweloperzy, czyli po staremu Development Team 

Deweloper w Scrum to źródło nieporozumień. Tym bardziej ma to miejsce na polskim rynku, gdzie bardzo często bywa utożsamiany z programistą. Tak jednak nie jest!

Ten tekst przeszedł wiele aktualizacji związanych ze zmianami w Scrum Guide w listopadzie 2020. Jego stan odzwierciedla aktualne rozumienie roli Deweloperów w tym dokumencie.

Kim jest Deweloper w Scrum?

Deweloper to każda osoba dewelopująca (rozwijająca) Produkt. Są to ludzie, którzy fizycznie wykonują pracę w Sprincie po to, żeby stworzyć kolejny Przyrost. Każdy, kto brudzi sobie ręce, czyli ma jakieś zadania do realizacji w danym Sprincie jest określany mianem Dewelopera.

Jeżeli scrumowo wykańczamy dom bądź remontujemy mieszkanie, to Deweloperami będą murarze, tynkarze, elektrycy, glazurnicy i tak dalej. W przypadku tworzenia oprogramowania Deweloperami będą programiści, architekci, testerzy, analitycy UI/UX designerzy, graficy i tak dalej, i tak dalej…

Trzeba podkreślić że jest to scrumowe rozumienie odpowiedzialności Dewelopera. Zawsze, kiedy mówimy o Deweloperach w kontekście Scruma, pamiętajmy, że nie znaczy to tylko i wyłącznie „programiści” (patrz też: zwinny deweloper). To każda osoba w naszym Scrum Teamie, która rozwija produkt i przykłada rękę do tego, żeby w bieżącym Sprincie powstał wartościowy Przyrost.

Deweloperzy czy Development Team?

Przed 2020 rokiem grupa osób realizująca prace nazywała się „Development Team”. W tamtych odległych czasach, Scrum Team składał się z jednego Product Ownera, jednego Scrum Mastera i jednego Development Teamu. Ten ostatni z kolei miał liczyć od 3 do 9 osób. Powodowało to pewne problemy w rozumieniu Scruma – jeden zespół (Scrum Team) składał się z drugiego zespołu czy też podzespołu (Development Team).

Po zmianach w Scrum Guide z 2020 roku mówimy tylko i wyłącznie o Product Ownerez, Scrum Masterze i Deweloperach. Przy okazji tej zmiany wyparowało także ograniczenie mówiące o limicie 3 do 9 osób w Development Teamie. To jednak nie znaczy, że będziemy budować Scrum Teamy składające się z 20 czy 30 osób.

Ilu Deweloperów potrzebujemy?

Zespoły Scrumowe powinny być tak małe, jak się tylko da, ale nie mniejsze. Oznacza to, że w większości przypadków lepiej jest mieć dwa sześcioosobowe zespoły, niż jeden dziesięcioosobowy Scrum Team. W tej matematyce oczywiście zakładam, że odpowiedzialności SM i PO byłyby współdzielone przez te same osoby w dwóch mniejszych zespołach.

Jeden z twórców Scruma od zawsze od samego początku mówił, że zespoły w których Development Team (bo tak to się wtedy nazywało) liczył siedem osób, jak najszybciej rozbijał na dwa mniejsze. Spotkamy się także z podejściem mówiącym o tym, że zespół powinien dać się wykarmić dwoma pizzami (Jeff Bezos, Amazon). Z kolei amerykańscy naukowcy policzyli, że idealny zespół liczy niecałe 5 osób (dokładniej 4,6). Scrum Guide wspomina, że Scrum Teamy „typowo” liczą do 10 osób, wliczając w to PO i SM.

Z mojego doświadczenia gorąco mogę polecić pracę w pięcio-sześcioosobowych zespołach, do których powinniśmy doliczyć jeszcze Product Ownera i Scrum Mastera. Więcej rozważań na ten temat znajdziecie w moim tekście o idealnej wielkości zespołu.

Wiele osób powie że w dzisiejszych czasach bardzo trudno jest zbudować kross-funkcjonalny zespół, który będzie potrafił wykonać pracę od początku do końca i dostarczyć jakąś wartość. Ludzie mają coraz węższe specjalizacje i znalezienie grupki pięciu-sześciu osób, która potrafi wytworzyć jakieś rozwiązanie informatyczne jest nie lada wyzwaniem.

Tu z pomocą przyjdą nam takie pomysły jak Feature Teamy, ale przede wszystkim dzielenie wymagań na mniejsze, tak aby mała grupa osób była w stanie zrealizować je end to end. Co więcej, dzielenie zespołów w sposób biznesowy ma dużo innych zalet. Doprowadzamy wtedy do sytuacji, w której nikt nie musi zajmować się jedną wielką kobyłą, ale mamy do czynienia z drobnymi wymaganiami i mniejsza liczbą zależności.

Cechy Deweloperów

Jeżeli mówimy o Deweloperach, to przede wszystkim powinni oni być samoorganizujący się i kross-funkcjonalni. Ta druga cecha mówi o tym, że wszyscy Deweloperzy wzięci razem powinni potrafić zrealizować stawiane przed nimi wymagania od początku do końca. Nie znaczy to oczywiście, że każdy w zespole powinien zrobić wszystko. Natomiast jak najbardziej znaczy to, że każdy powinien wspierać innych w taki sposób, w jaki potrafi.

Tu dochodzimy do „obrzydliwych” dla niektórych sugestii, że programiści powinni wesprzeć testerów czy analityków w sytuacji, w której wymaga tego potrzeba chwili. Jak najbardziej się z tym zgadzam! I nie jest to nic dziwnego, bo w każdym dobrze zgranym zespole zależy nam przede wszystkim na osiągnięciu celu, a nie na robieniu tylko i wyłącznie „swojego kawałka pracy”.

Ważne, żeby ten podział pracy i sposób organizacji naszych procesów wychodził z od samego zespołu (samoorganizacja). Agile mindset mówi nam, że to oni najlepiej wiedzą jak przebiega ich własna praca i gdzie są potencjalne problemy i szanse na pomoc. Świetnie mówił o tym „stary” Scrum Guide z 2017 roku:

„Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności.” – Scrum Guide 2017

Zaufajmy Deweloperom, że najlepiej wiedzą jak zrealizować wymagania. Dajmy im wsparcie, środowisko i narzędzia do tego, żeby rozwinęli tę swoją kross-funkcjonalność i samoorganizację. Tu warto też dodać, że wszyscy w zespole powinni być zmotywowanymi profesjonalistami posiadającymi odpowiednie kompetencje twarde, a jednocześnie osobami, które potrafią i lubią pracować zespołowo. W Scrumie nie ma za bardzo miejsca na indywidualności.

Czy Scrum Master i Product Owner są Deweloperami?

Bardzo częstym pytaniem, szczególnie wśród osób dopiero poznających Scruma, jest pytanie o Product Ownera czy Scrum Mastera. Czy oni też są Deweloperami?

Na takie pytanie zwykle odpowiadam pytaniem: „Czy przykładają się oni jakoś do powstawania Przyrostu?”. Typową odpowiedzią jest, że tak bo przecież POpracuje nad Backlogiem Produktu, a SM nad procesem, w ramach którego go wytwarzamy. Nie o to jednak chodzi w moim odbijaniu piłeczki. Czy PO lub SM ma jakiekolwiek zadania do zrealizowania w bieżącym Sprincie? Czy jeżeli zajrzymy do Backlogu Sprintu, to znajdziemy tam pracę jawnie przypisaną do jednej bądź drugiej odpowiedzialności? Zwykle odpowiedź brzmi „nie”. W takiej sytuacji śmiało możemy stwierdzić, że PO i SM nie są Deweloperami. Co za tym idzie, nie powinni też pojawiać się na Daily.

Zdarzają się jednak sytuacje, w których ktoś jest na przykład „Scrum Masterem na 50%”, a poza tym też jest analitykiem czy testerką. Podobnie rola PO bywa czasami łączona z rolą architekta czy analityka biznesowego. W takich przypadkach mamy do czynienia z lekkim rozdwojeniem jaźni, bo czasami taka osoba będzie występowała jako Deweloper (na przykład na Daily), a czasami będzie realizowała swoją drugą odpowiedzialność.

Jeżeli jednak nasz PO lub SM traktuje swoją odpowiedzialność jako stanowisko i nie robi nic innego poza „scrummasterowaniem” czy „productownerstwem”, to odpowiedź brzmi: „nie, taka osoba nie jest Deweloperem”.

Zespołów… kilka

Kilkukrotnie w tym tekście padła sugestia, że duże zespoły powinny być dzielone na mniejsze. Idealnie byłoby, gdyby Deweloperów było zaledwie kilku. I to nawet jeżeli tworzymy skomplikowane produkty czy też zajmujemy się wielkimi i złożonymi systemami. Scrum działa świetnie do dwóch-trzech Scrum Teamów, szczególnie jeżeli mają one wspólnego Product Ownera i jeden Product Backlog.

Takie też rozwiązanie sugeruje Scrum Guide, który mówi, że zbyt liczne zespoły powinny zostać podzielone na mniejsze, z dokładnie tym samym PO i z jednym wspólnym Product Backlogiem. Oczywiście, w tej sytuacji mamy osobne Backlogi Sprintów, Sprinty i Wydarzenia Scrum. Warto tu jednak sięgnąć po lekcje chociażby z metodyki LeSS, która sugeruje wspólne Sprint Review i wspólną pierwszą część Planowania. Tu jednak wkraczamy w tematykę Skalowania Scruma, która jest o wiele bardziej skomplikowana niż mogłaby się wydawać na pierwszy rzut oka. Bo dwa-trzy Scrum Teamy nie wystarczą przecież do wspomnianych skomplikowanych produktów czy wielkich i złożonych systemów.

W tym temacie jak najbardziej polecam nasze warsztaty dotyczące skalowania, na których przedstawiamy sposoby na konstruowanie zespołów, a także omawiamy najpopularniejsze metodyki skalowania. Jesteśmy także dostępni jako konsultanci, jeżeli chcielibyście przeprowadzić takie skalowanie bądź transformację w waszej firmie bądź organizacji. Polecamy się!