Niedawno miałem przyjemność wziąć udział w pierwszym spotkaniu o intrygującej nazwie BYOP (czyt. bjop), czyli Bring Your Own Problem. Więcej o samej inicjatywie na stronie byop.pl.
Idąc na spotkanie nie miałem przygotowanego żadnego tematu, nastawiałem się raczej na słuchania i dzielenie się moim doświadczeniem. Atmosfera była jednak bardzo kameralna i pomyślałem, że może jednak…
Opowiedziałem o organizacji naszego zespołu – rozproszony i usiłujący robić Scruma – i o bolączkach wynikających z rozproszenia. Dostałem kilka cennych spostrzeżeń i porad.
Jak wygląda nasz zespół?
- Lokalizacja I – 4 bazodanowców, 1 javowiec/Scrum Master, Product Owner
- Lokalizacja II – 2 bazodanowców, 6 javowców
- Lokalizacja III – 2 testerów, menadżer
- Lokalizacja IV – 1 bazodanowiec
Ciekawym dla mnie doświadczeniem było to, że dopiero opowiadając o tym na BYOPie zdałem sobie sprawę ze stopnia rozproszenia zespołu. A także z jego wielkości (16 deweloperów).
Bolączki wynikające z takiego rozproszenia są dość naturalne
- Trudności w komunikacji na spotkaniach. Zestawy konferencyjne może i sprawdzają się nieźle, jeśli po każdej ze stron są 2-3 osoby. Jeśli jednak jest ich więcej, to bardzo trudno śledzić zdalną dyskusję. Poza tym ze względu na słabość sprzętu, różnice w akcencie i w głośności mówienia, często po prostu się nie rozumiemy. Ze spotkania, gdzie koniecznie chcę zrozumieć co kto mówi, wychodzę z bólem głowy.
- Dużo pracy solo. Słabo się znamy (część członków zespołu nigdy nie widziała się na żywo). Niektórzy często pracują z domu.
- Nie wiemy, a często i nie interesuje nas, co robią członkowie zespołu w innych lokalizacjach.
Jak dotychczas sobie radziliśmy? Zaczynaliśmy od sytuacji takiej, że w lokalizacji I są tylko bazodanowcy, w lokalizacji II (czyli w Warszawie) tylko javowcy. Wtedy myśleliśmy o tym tak, że my tu w Warszawie jesteśmy zespołem Scrumowym i rozliczamy się tylko z zadań guiowych. Na dłuższą metę okazało się to oczywiście nieprawdą – dostarczanie funkcjonalności wymaga też pracy bazodanowców, a i z pracy i doświadczenia testerów warto by skorzystać. I tylko na tym poziomie – całego produktu i całego procesu – warto optymalizować. Mój kierunek działań przed BYOPem był taki, żeby dążyć do wspierania komunikacji pomiędzy różnymi lokalizacjami. Czyli chciałem budować jeden duży rozproszony Scrumowy zespół.
Teraz o tym, co usłyszałem na BYOPie.
Utworzenie feature teamów
Jednym z pomysłów na skalowanie Scruma jest dzielenie zespołu na mniejsze. Każdy z nowych zespołów powinien być Scrumowy w sensie posiadania pełni kompetencji do dostarczania funkcjonalności – nazywamy to feature teamem właśnie.
W naszym kontekście to, co się narzuca, to 2 zespoły w lokalizacjach I i II. Mimo dysproporcji java/db wydaje się to możliwe. Kwestia odpowiedniego doboru User Stories – tak, aby te, w których więcej jest pracy bazodanowej lądowały w lokalizacji I, a te bardziej guiowe w lokalizacji II.
Co ciekawe, gdy podzieliłem się tym pomysłem z kolegami, uświadomiliśmy sobie, że to już się dzieje. Mniej lub bardziej świadomie wybieramy takie User Stories, które jesteśmy w stanie realizować przy minimalnym wsparciu osób z innych lokalizacji. Niedawno też dowiedzieliśmy się, że kolega z lokalizacji IV opuści projekt. Decyzja menedżerów, może niekoniecznie wynikająca z opisywanych przeze mnie powodów, ale to krok w dobrym kierunku.
Jeden backlog projektowy, 2 sprint backlogi
Tu najbardziej podobało mi się uzasadnienie tego kroku, jakie dostałem na BYOPie. Wprowadzenie niezależnych sprint backlogów ma dać każdemu z feature teamów poczucie własnego celu.
Realizacja tego w naszym kontekście wydaje się trochę trudniejsza, przynajmniej formalnie. Nieformalnie zawsze możemy sobie zrobić sprint backlog na tablicy w naszym biurze. Ale żeby to działało, to reszta zespołu powinna być świadoma naszego sprint backlogu i wynikających z niego statystyk. Teraz naszą wspólną „tablicą” jest Rally. Czy pozwala na zamodelowanie 1 backlogu produktowego i 2 sprint backlogów – do sprawdzenia.
Wspólny sprint w jednym biurze 4 razy w roku
Nasze sprinty trwają 2 tygodnie. Co może dać realizacja sprintu w jednej lokalizacji? Poznanie innych członków zespołu jako ludzi. Poznanie ich kompetencji i sposobu pracy – czego możemy oczekiwać, w czym są dobrzy, gdzie możemy liczyć na ich pomoc. Zbudowanie zaufania.
4 razy do roku wydaje mi się kosmicznie trudne do zrealizowania w naszym kontekście. Ale 1 sprint w roku to cel, który wydaje się jak najbardziej osiągalny i w kierunku którego zamierzam działać.
Podsumowując, dostałem kilka cennych spostrzeżeń i rad. Myślę, że pozwolą nam bardziej świadomie „zarządzać” rozproszeniem. Co ciekawe, sam proces nazywania i opisywania innym tego, jak pracujemy, był bardzo cenny.
I jeszcze słowo o samej inicjatywie BYOP. Siłą tych spotkań jest to, że spotykają się tam osoby z różnych środowisk, z różnym doświadczeniem i pełniące różne role w organizacji. Dzięki temu możemy zyskać zupełnie nowe, niespodziewane spojrzenie na problem.
.