Programista w Scrum’ie jest przeszczęśliwy, jest słuchany, koledzy pomagają mu się rozwijać, w spokoju jest w stanie tworzyć dobre rozwiązania. Kod jest czysty, przetestowany, można spać spokojnie. Nic dziwnego, że Scrum jest metodą rektutacji – ale czy warto?
ScrumBut
Scrum Master w postaci PM, PO jako CEO, i raport tygodniowy – to już nie jest Scrum lecz ScrumBut, w tłumaczeniu “Scrum, ale….”. Opiszę ten temat w innym artykule a tutaj chciałbym się skupić na podejściu firm i ich ofercie dla programistów.
Nie spotkałem wiele osób, które po zapoznaniu się z zasadami Scrum, stwierdziło jednoznacznie, że pracowali zgodnie z zasadami frameworka. Zawsze były jakieś odstępstwa, a to firma inna, projekt, klient wymagający. Tutaj uwidacznia się trudność we wprowadzaniu reguł – z jednej strony chcemy mieć dobrą komunikację w firmie, a z drugiej w przeciągu ostatnich 6 miesięcy nie wdrożono żadnej zmiany w tym kierunku.
Oczekiwania
Taką sytuację, gdy firma mówi, że pracuje zgodnie ze Scrum’em, ale tak naprawdę nie jest, można uznać jako mówienie nieprawdy w najlepszym przypadku, a w ekstremalnych sytuacjach – kłamstwo rekrutacyjne.
Podczas wielu rozmów na temat Scruma ze znajomymi prowadzącymi firmy programistyczne, agencje interaktywny, software house dowiedziałem się jedno. Kiedy ich poziom wiedzy na temat zasad został usestymatyzowany – jasno większość stwierdziła – nie chcemy Scruma, nie wprowadzimy go. Takie reakcje mnie smucą jako entuzjastę ale też jest i dobra strona, im więcej osób jest świadomych wymagan ale tez i korzyści – tym lepiej.
Czemu tak się dzieje?
Scrum: Czyli jak zrobić dwa razy więcej, dwa razy szybciej
Jeff Sutherland
Czy ten tytuł nie jest zachęcający? Wszystkie publikacje zachęcają do wprowadzania Scrum’a pokazując same pozytywy. Nic dziwnego, że firmy są gotowe eksperymentować. Lecz akurat w tym przypadku nie tędy droga. O ile wprowadzenie metodyk Kaizen, Lean Startup jest łatwe to o tyle Scrum jest dość trudnym frameworkiem.
Rezultat
Wynik jest prosty do przewidzenia – ktoś kto pracował w Scrum’ie, nie wyobraża sobie innych zasad pracy. W przypadku rekrutacji, której efektem jest stanowisko “Mid Executive Programmer JS&Mysql” w zespole “Utrzymanie”, osoba, która pracowała w samoorganizującym się zespole – nie odnajdzie się. Możemy być prawie pewni, że jeżeli firma nie jest w trakcie transformacji Scrum, i jest to standardowa sytuacja – nasz nowy pracownik zmieni miejsce pracy w niedalekiej przyszłości.
Jeżeli więc mówisz na rekrutacji – tak mamy Scrum a go nie masz i o tym wiesz to kłamiesz.
Podsumowanie
Pierwszy zespół Scrum w firmie powinien zostać stworzony na poziomie prezesów, osób zarządzających. Pomijam tutaj program pilotażowy, który tylko daje nam informację o korzyściach, a jedynie pisze już o konkretnej implementacji. Potem poprzez kadrę menedżerską wartości powinny zostać przeniesione na poszczególne entuzjastycznie nastawione zespoły. Lecz pomimo tak wielu poradników wskaźnik sukcesu wdrażania Scrum wynosi 30%*.
- Informacja pochodzi z książki ”Tworzenie oprogramowania w 30 dni”, powołując się na John P. Kotter