Zarządzanie Agile w projekcie uruchomienia operatora MVNO

1. Agile a projekty Telco
Lessons learned

2. ale o co chodzi ?
Zarządzanie Agile w projekcie
uruchomienia operatora MVNO
GaduAIR
Od Stycznia 2008 do Maja 2009

3. kim jesteśmy ?
Grzegorz Machniewski Dawid Mielnik
• Do lipca 2010 dział Telco • Do lipca 2010 dział Telco
w GG (dyrektor IT) w GG (dyrektor)
• Przed GG IBM, Outbox • Przed GG Citi, DRSA
• Po GG Voiceware S.J., • Po GG Voiceware S.J.,
Moberia sp. Z o.o., XEO Moberia sp. Z o.o.
Games sp. Z o.o.

4. usługi internetowe a
usługi telekomunikacyjne
typowe..

5. software to niewielka część
• 5 zespołów, ok 15 osób
• Zespoły software
• BSS, VAS
• Zespoły nie software
• Core Network, VoIP, Operations

6. zewnętrzni dostawcy i
partnerzy
• Huawei
• AMG
• Polkomtel
• Gemalto
• Arvato
• Call Center Poland
• Kolporter, Billbird, Euronet, Polski Tytoń, Sprint, ... (dystrybucja)
• Allegro, Effortel

7. wewnętrzne działy
• "klienci" • "dostawcy"
• Business • Admini
• Marketing • Server dev
• Sprzedaż • Web dev
• Zarząd • GG klient dev
• Księgowość • Mail dev
• Bezpieka • QA

8. SCRUM się nie sprawdzał

9. SCRUM się nie sprawdzał
Planowanie sprintow
wyzwaniem
• organizacyjne - 5 zespołów o skrajnie
różnych taskach
• określenie zakresu który był by realizowalny
przy tak wielu zmiennych, zależnosciach nie
będących po kontrolą zespołów

10. SCRUM się nie sprawdzał
Problemy z odbiorami od
zewnętrznych dostawców
• Terminy - częste obsówy
• Funkcjonalność - nie działa lub działa nie
zgodnie z zamówieniem, albo działa
bardzo niestabilnie

11. SCRUM się nie sprawdzał
Inne problemy z dostawcami
• Komunikacja
• Długie czasy rozwiązywania niektórych
problemów
• Rotacja zespołu dostawcy

12. SCRUM się nie sprawdzał
Problemy z terminami od
wewnętrznych dostawców
• Konieczność wpasowania się w inne harmonogramy nie
do końca spójne z naszymi
• Walka o kompromisy i nadawanie wyższych priorytetow
dla naszych taskow, a nastepnie ich egzekwowanie

13. SCRUM się nie sprawdzał
Zmienne wymagania
wewnętrznych klientow i
biznesu

14. SCRUM się nie sprawdzał
Dużo nieprzewidywalnych
pożarów które rozwalały sprint

15. SCRUM się nie sprawdzał
(dodatkowa refleksja)
Metodologia Agilowa to mniej
papierologji i formalności
a to niestety działa na naszą
niekorzyść z dostawcami

16. ... czego finałem było:
• Planowania sprintów były długotrwałe i w nudne dla
wiekszości osób (analogicznie z retrospekcją)
• Żadnego sprintu nie udało sie zamknąć w czasie, a
zdażały się takie w których żaden backlog nie został
zrealizowany z uwagi na nieprzewidziane rzeczy
• Frustracja u nas, w zespołach i u naszych klientów
wewnętrznych - napięte stosunki z dostawcami
• Zawalane terminy

17. Postanowiliśmy coś z
tym zrobić ...
Krok 1
• Skasowaliśmy ogólne planowania na korzyść szybkich planowań w
indywidualnych zespołach
• Każdy zespół mial indywidualny backlog i sprint
• Rozluźniliśmy trochę pojęcie sprintu i wszystkego co się z tym wiąże
• Zaczęliśmy codziennie priorytetyzowac zadania zgodnie z tym co
sie pojawialo
• Zaczęliśmy definiować nowe stany dla taksów które czekały na coś
niezaleznego od zespołu

18. ... Jak się pózniej okazało
zmieżaliśmy w stronę ScrumBana
• Przełomowe było 1 spotkanie Agile Warsaw
poświęcone Scrum vs. Kanban
• Okazuje się że to jest narzędzie którego
potrzebujemy
• Zauważyliśmy że niektóre praktyki naturalnie
sami wcześniej zaczęliśmy stosować
• Szkoda ze tak późno się o tym dowiedzieliśmy

19. SrumBan dużo bardziej
się sprawdzał
Krok 2 - przejście na ScrumBana
• Zlikwidowaliśmy sprinty i ich planowania, na korzyść
planowania, estymacji i priorytetyzacji ad-hoc - codziennie
• Narzucenie limitów na ilość tasków w statusie WIP na osobę
• Wywłaszczenia / najwyższy priorytet dla fackupów i błędów
ponad zwykłe taski
• Rearanżacja zespołów - 3 zespoły: devel, telco i operacje
• Indywidylne statusy tasków dla każdego zespołu

20. Task board Telco

21. Task board Devel

22. Task board Operacje

23. ScrumBan - obserwacje
• Mieliśmy przyjemność pracować w nowej aranżacji przez 2
miesiące
• Ewidetnie zmniejszył sie poziom frustracji związany z samym
procesem
• Widać było ewidentny wzrost produktywności i jakości w pracy
zespołów
• Skrócił się czas od zgłoszenia do realizacji jakiegoś tematu przez
dział
• ScrumBan nie rozwiązał wszystkich naszych problemów, ale
większość związanych z procesem, zwiększajac komfort pracy

24. Pytania?

25. Dziękujemy.