Agile,  Praca,  Zarządzanie

Nigdy nie będzie dobrze

Postanowiłem się dziś podzielić obserwacją tak oczywistą, ale najwyraźniej nie na tyle by była ona powszechnym rozumieniem. Otóż: nigdy nie będzie dość szybkich zespołów developerskich.

Dlaczego? Ano dlatego, że wymyślanie potrzeb oraz funkcji w oprogramowaniu, które mogłyby je zaspokajać jest bardzo szybkie. Sam pomysł to krótki błysk w duszy i przebieg impulsów po neuronach – jest! Eureka! Zapisanie go, ew. przedyskutowanie to kwestia godzin. Ale realizacja może trwać dni, tygodnie, miesiące nawet. Jeśli dodamy do tego dość typową sytuację, kiedy wymyślających (zwanych elegancko „interesariuszami”) jest istotnie więcej od implementujących widać wyraźnie, że jest niemożliwością doprowadzenie do sytuacji, w której każdy pomysł („wymaganie”) jest realizowane bez oczekiwania. Z tego właśnie powodu praktycznie zawsze wymagania czekają a ich lista rośnie.

[Opisując to językiem procesów tworzenie oprogramowania to – na wysokim poziomie ogólności –  etap, na którym jednostki pracy są wytwarzane bardzo szybko, po którym następuje etap przetwarzający je dużo wolniej.]

Jeśli chwilę pomyśleć rzecz jest – jak to już napisałem wyżej – oczywista. Prosta logika mówi, że nie może być inaczej. A jednak mimo to w praktycznie wszystkich organizacjach, z którymi miałem do czynienia, jest ogromny nacisk na to, żeby zespoły działały szybciej. Tak jakby organizacje chciały osiągnąć to marzenie, idealny stan, w którym powiedzą sobie „mamy już wystarczająco szybki development”. Realizuje się to głównie przez odruch zatrudniania (stąd taka popularność tematu „skalowania Agile” – jak się już tych ludzi zatrudni jakoś trzeba ogarniać współpracę pomiędzy nimi).

I w sumie nie ma w tym nic złego gdyby nie to, że nie widać by co najmniej taka sama energia i zaangażowanie były poświęcone na dobre wybieranie tego, co będzie realizowane. A to jest rzecz absolutnie najważniejsza. Mając ograniczony zasób jakim są możliwości i energia developmentu należy przede wszystkim zadbać o to, by nie marnować go na rzeczy o niskiej wartości. Każde wymaganie, każdy pomysł powinno się trzy razy obracać w palcach, oglądać pod światło i porównywać z innymi żeby mieć absolutną pewność, że w danej chwili nie ma naprawdę nic ważniejszego co developerzy mogliby zrobić.

To jest kolejna oczywistość, dużo bardziej zresztą uniwersalna niż tworzenie oprogramowania – wszędzie ważna jest koncentracja. Niby wszyscy o tym wiedzą, ale w 9 przypadkach na 10 kiedy np. w ramach warsztatu zwizualizujemy kierownictwu ile mają otwartych inicjatyw i projektów to jest wielkie zdziwienie. Po czym oczywiście jedno z pierwszych pytań jest takie: co zrobić, żeby development szybciej pracował? Może zatrudnijmy więcej programistów?

Myślę, że lekarstwem na to może być powtarzanie w kółko oczywistości, od której zacząłem ten wpis: „nigdy nie będzie wystarczająco szybkich zespołów”. I dodawanie „zatem zastanówmy się jak najlepiej wykorzystać to, co mamy”.

Jak to konkretnie zrobić? Ano stosując empiryzm, nie pakując się w wielkie inicjatywy bez zweryfikowania małym (i tanim) eksperymentem, że warto, stosując biznesowe metryki (np. kwantyfikację celów biznesowych) i weryfikowanie na ile dana planowana funkcjonalność je poprawia – i tak dalej. Dużo narzędzi i praktyk wykraczających poza zakres tego artykuliku (o części z nich mówimy na szkoleniu dla Product Ownerów, o innych na różnych warsztatach). Czyli robiąc wszystko co się da, żeby właśnie jak najlepiej wybierać rzeczy, które trafią do realizacji.

Ale to są narzędzia, a najważniejsza jest świadomość, że w ten sposób osiągniemy więcej niż koncentrując się na powiększaniu zespołów. Teraz już ją masz, więc do dzieła! Bo choć nigdy nie będzie dobrze, to jednak może być lepiej. 🙂

komentarze 2

  • Wiktor Żołnowski

    A ja sie nie do konca zgodze z autorem… O ile co do tego by dobrze dobierac prace dla zespolow nie mam zastrzezen to jednak stwierdzenie ze nigdy nie bedzie (nie bylo) wystarczajaco szybkich zespolow jest dalekie od prawdy. Widzialem juz sporo wystarczajaco szybkich zespolow…
    Po pierwsze takich zespolow, ktore bylyby w zupelnosci wystarczajaco szybkie gdyby nie dysfunkcyjny kontekst w ktorym sie poruszaly.
    Np. Beznadziejne zarzadzenie procesem (proces – czyli cos wiecej niz Scrum), mangerowie i dyrektorzy, ktorzy zatrudniali zbyt wielu (w wiekszosci niekompetentnych – „bo innych nie ma”) developerow ktorzy potykali sie o siebie na wzajem i krecili sie w kolko. Widzialem zespoly ktore zmienialy kontekst i cele 5-10 razy w miesiacu przez co nigdy nie dowozili. To nie jest tylko kwestia doboru wymagan, to kwestia braku PODSTAWOWEJ wiedzy na temat zarzadzania u wiekszosci managerow w IT. I nie mowie tutaj o wiedz o Agile, Scrum czy nawet Management 3.0 – to wszystko jest spoko i cool i nawer czasem pomocne, ale samo-organizacja != samo-zarzadzanie.
    Po drugie widzialem tez zespoly ktore faktycznie byly wystarczajaco szybkie.
    Mialem/mam przyjemnisc pracowac z kliemtami, dla ktorych nasze zespoly sa „wystarczajaco szybkie”. I to wcale nie byla nasza zasluga… Twynik ciezkiej pracy ich managerow, ktorzy sa po prostu swietni w tym co robia. Managerow ktorzy nie skupiaja sie na tak nieistotnym szczegole jak velocity zespolu, lecz potrafia zarzadzac wszystkim dookola tak by zespoly pracowaly „wystarczajaco szybko”. Owszem, odpowiednie dobieranie wymagan to kluczowy aspekt zarzadzania, ale z pewnoscia nie jedyny. Wystarczy przeciez tylko przyjac zalozenie ze velocity/capacity/mozliwosci zespolu sa srednio stale w dluzszym okresie czasu i nagle caly paradygmat zarzadzania w IT obraca sie o 180 stopni i wszystko nagle zaczyna dzialac. Nie jestem pewien, ale wydaje mi sie ze wlasnie to (a nie inne bajki opowiadane na konferencjach) stoi za sukcesem #noestimates. To tez wynika z wielu innych teorii zarzadzania popartych badaniami…
    Zespoly sa, lub moga byc wystarczajaco szybkie. To mamagerowie nie ogarniaja.

    • andy

      Ciekawe, piszesz, że się nie zgadzasz, a potem się zgadzasz. Cały mój tekst jest o tym właśnie, że należy „przyjac zalozenie ze velocity/capacity/mozliwosci zespolu sa srednio stale w dluzszym okresie czasu” i skupić się na tym co dajemy zespołowi do robienia.

Komentowanie

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *