Friday, October 12, 2018

Zwinność kulturowo rozmiękczona

Tu, nad Wisłą, ze zwinnością (agility) wydarzyło się coś niedobrego. Zapraszam to krótkiej rozkminki.

Weźmy taki cytat ze Scrum Guide (dotyczy on roli Product Ownera): "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

I z polskiego tłumaczenia: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny"

Dostrzegasz coś intrygującego?

responsible vs. accountable

Responsible oznacza odpowiedzialność w takim sensie, że ktoś ma coś w swoich obowiązkach, bo na przykład zostały mu te obowiązki przydzielone.

Accountable oznacza mocniejszy rodzaj odpowiedzialności np. prawnej, czyli odpowiedzialności za konsekwencje.

Zatem tłumaczenie oddające sens angielskiego zdania powinno brzmieć: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu zostanie z nich rozliczony". Jedno słowo wiele zmienia, co?

Podobnie rzecz się ma Zespołem Deweloperskim: „Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”

Zatem Zespół Deweloperski zostanie rozliczony za brak przyrostu (increment) produktu na koniec sprintu.

Niuans kulturowy

Moim zdaniem mamy tu do czynienia z różnicą kulturową. Anglosaska - jak mniemam - prosta i konkretna zasada rozliczenia została w polskim tłumaczeniu rozmyta i rozmiękczona w ogólną odpowiedzialność.

Zgaduję powód. Sęk w tym, że rozliczyć ma w języku polskim mocno pejoratywne konotacje. "Rozliczę cię" oznacza mniej więcej tyle: "Słuchaj gościu, jak coś pójdzie nie tak, to ty za to bekniesz. Poniał?"

Głębiej o accountability

Powiem więcej. "accountability" oznacza taki rodzaj (silnej) odpowiedzialności (za konsekwencje), który został przyjęty dobrowolnie. Na przykład CEO jest accountable za organizację i zostanie rozliczony za ew. sukcesy i nieprawidłowości. Ważne jest to, że on o tym wiedział od samego początku i zgodził się na to "rozliczanie" w momencie przyjęcia nominacji.

W tak rozumianym rozliczaniu nie ma nic negatywnego. Ktoś otrzymuje pełnię władzy: przywileje oraz konsekwencje. Prosty deal.

Czego chce Scrum?

Posługując się już przedefiniowanymi wyżej pojęciami, można powiedzieć, że Scrum chce od swojego praktyka pewnej dojrzałości.

Chce, aby PO, DevTeam czy SM, zanim podejmą decyzję, że używają Scruma, zatrzymali się na moment. Niech się zatrzymają, popatrzą na możliwe przywileje, na potencjalne konsekwencje i świadomie powiedziedzą: "Tak, chcę być rozliczony za swoją pracę."...albo nie.

Rzecz jasna możliwość rozliczania implikuje ze strony organizacji konieczność przydzielenia autonomii, decyzyjności i tak ogólnie nie wpieprzania się w paradę.

Kolorowy coach

Tu kudos dla Bartka za insight.

Weźmy jeszcze jeden cytat na temat tego, co tam Scrum Master powinien: "Coaching the Development Team in self-organization and cross-functionality"

I po polskiemu: "Coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności".

No więc rzucili się ludzie na kursy kołczigu i adżajkołczują. No, ale looknijmy sobie na OxfordDict czymże jest ten coaching?

O, żesz w mordę, madafaka! Co ja paczę???

  • "Train or instruct (a team or player)"
  • "Teach (a subject or sport) as a coach"
  • "Give (someone) instructions as to what to do or say in a particular situation"
  • "Give (someone) professional advice on how to attain their goals"

Zatem jeśli Scrum Master coach Zespół Deweloperski, to oznacza, że ten Scrum Master jest naumiany Scruma i generalnie ogarnia temat. Następnie jego zadanie polega na tym, aby nauczyć Scruma zespół. No i może ludzi poza zespołem, przynajmniej na takim poziomie, żeby kumali o co chodzi.

Nie oznacza to, że statutową metodą pracy Scrum Mastera jest "metoda coachingowa", czyli zadawanie pytań tak, aby delikwentom samo wyjajiło się, co im dolega. Może to robić, jak będzie ku temu powód. Moje doświadczenie podpowiada mi jednak, że takich chwil jest naprawdę niewiele.

Nawiasem mówiąc "metoda coachingowa" zakłada, że klient ma pełnię kompetencji do rozwiązania swoich problemów. No więc życzę powodzenia w pracy tą metodą, gdy zespół nie zna i nie umie Scruma.

Ej, a wiecie jak deweloperzy mówią na takich adżajlkołczów, co to w każdym próbują znaleźć wewnętrzne dziecko i proszeni czy nie proszeni serwują sesje coachingowe tuzinami? "Kolorowe pisaki"...sam słyszałem.

Także, ten...wyluzuj. Po prostu wyluzuj.

Continuous attention to technical excellence...

No więc jak taki #kolorowyCoach w pośpiechu przygotowuje się do certyfikatu, to czytając po łebkach adżajlmanifesto, skupia się tylko na wartościach, zapominając, że jest tam też parę bardziej szczegółowych wytycznych.

Między innymi taka: "Continuous attention to technical excellence and good design enhances agility". O co chodzi?

Coraz częściej dochodzę do wniosku, że pierwszym blokerem do uzwinnienia się jest architektura. Co z tego, że nasz supersystem powstał w sprintach i nawet miał wizję i rołdmapę, skoro to monolit liczący 2MLOC?

Gdzieś popełniliśmy błąd. W którymś momencie zwinność odkleiła się od technologii i stała się wyłącznie: kulturą, mindsetem i procesem.
Tak się nie da.

Biznes dzieje się szybko. Żeby szybko produkować dla tego biznesu potrzeba metod, architektur, technologii i skilla, które umożliwią osiągnięcie tej szybkości. Bez tego zostają tylko kolorowe pisaki...

A na deser międzyfunkcjonalność

W oryginale: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment"

I w rodzimym dialekcie: "Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu."

Nie wiem czy tylko ja wymiękam z tą "międzyfunkcjonalnością"?

Neologizm - jak przypuszczam - "międzyfunkcjonalność" należałoby rozumieć przez analogię do np. "międzywydziałowości", czyli jako coś co się dzieje "pomiędzy granicami wyznaczonymi przez funkcjonalności". Czy ja wiem?

Jeśli już kuć nowe słowa, to ideę oddawałoby "pełnokompetentny": "Zespoły Deweloperskie są pełnokompetentne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu." Ewentualnie "pełnoumne" :)

Thursday, September 6, 2018

Jestem Scrum Masterem, co mam robić?

Śmieją się developerzy ze ScrumMasterów, że ci nic nie robią. Niby żartem, niby po przyjacielsku, ale boli. Gdy ScrumMaster zostaje ScrumMaster jedne z pierwszych pytań, które sobie zadaje to:
  • No i co ja mam teraz robić?
  • A co jeśli zapomnę jak się programuje?
  • A co jeśli znudzi mi się programowanie
Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy:
  1. Framework by Guide
  2. Jakość techniczna
  3. Wartości i wyjście poza zespół
  4. Nieustanny tuning DoD
W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy:
  1. Framework by Guide
    • Zaimplementowanie w pracy zespołu ról: SM, PO z biznesu, SM, DevTeam
    • Zaimplementowanie w pracy zespołu: sprintów stałej długości, DoD, Planningu, Review, Daily, Retro, regularnego refinementu PBL, Product Backloga, Spring Backloga
    • Biznesowe cele sprintów
    • Zaimplementowanie w pracy zespołu: biznesowego inkrementu produktu na koniec sprintu, współpracy między zespołem a PO, która nie wymaga sztywnego DoR
    • samoorganizacja Zespołu deweloperskiego
    • Doprowadzenie do tego, aby testerzy byli pełnoprawnymi członkami Zespołu scrumowego, a nie podzespołem w zespole
  2. Jakość techniczna
    • Wdrożenie 1-3 metryk kodu oraz systematyczna praca nad ich poprawianiem; propozycja na początek CC oraz LOC na poziomie metod i klas
    • Zmierzenie długu technicznego, przygotowanie planu jego spłaty i wynegocjowanie tego z PO
    • Wdrożenie Continuous Integration -> Continuous Deployment -> Continuous Delivery
    • Wprowadzenie regularnego Code Review w zespole wraz z narzędziem, który je wspiera
    • Wdrożenie Test/Behaviour Driven Development
    • Wdrożenie automatycznych testów funkcjonalnych wraz z narzędziem, które je wspiera; nauczenie PO i/lub interesariuszy formułowania wymagań w formie scenariuszy
    • Wdrożenie Domain-Driven Design, nawiązanie współpracy z ekspertami domenowymi, wdrożenie Modelling Whirpool
    • Regularne Architectural Kata
    • Regularne Refactoring Kata
  3. Wartości i wyjście poza zespół
    • Doprowadzenie do sytuacji, w której prace zespołu są niezależne od innych jednostek organizacji
    • Pomoc managerowi zespołu w na nowo zdefiniowaniu swojej roli w stosunku do zespołu scrumowego
    • Doprowadzenie do określenia zasad współpracy pomiędzy jego/jej zespołem a innymi zespołami i/lub jednostkami organizacyjnymi
    • Stymulowanie wewnętrznych inicjatyw typu "craftsmanship": wewnętrzne konferencje, warsztaty, szkolenia, mini-społeczności skupione w okół danych technologii albo ról (np. gildie)
    • Eksponowanie osiągnięć zespołu na zewnątrz organizacji: konferencje branżowe, artykuły w prasie i na portalach branżowych
    • Wdrażanie i promowanie empirycznego podejścia do pracy tj. wprowadzanie przejrzystych metryk przy jednoczesnym uczeniu organizacji jak z nich sensownie korzystać
  4. Nieustanny tuning DoD
    • Doprowadzenie do sytuacji, w której "Done" oznacza "dostępne dla klientów"
    • Praca na skróceniem time to markiet, time to feedback
    • Dążenie do sytuacji, w której ani zespół ani organizacja nie potrzebują Scrum Mastera, gdyż jego obowiązki zostały osmotycznie przejęte przez członków zespołu i innych pracowników organizacji, którzy bezpośrednio dostarczają wartość dla jej klientów

Tuesday, August 28, 2018

SegFault



Cieszę się, że to właśnie ONI zrobili nową konferencję.
Z każdym z chłopaków miałem okazję wielokrotnie współpracować i myślę, że łączą ich trzy rzeczy:
  • absolutnie niedogmatyczne podejście do programistycznych mód
  • alergia na bullshit
  • olewczy stosunek dla autortetów

Nie wiem jak dla Was, ale dla mnie to pachnie totalną konferencyjną innowacją. Do zobaczenia we Wrocławiu!