Doświadczenia płynące z wdrożeń metod i praktyk Lean i Agile – podsumowanie spotkania PAUG

Poznan Agile User GroupComiesięczne spotkanie poznańskich sympatyków agile – czyli popularny PAUG – odbyło się tym razem nie w pierwszy poniedziałek miesiąca, tylko wyjątkowo w czwartek. Prelegent, Paweł Brodziński, akurat tego dnia prowadził szkolenie w Poznaniu i w ten sposób narodził się pomysł, aby skorzystać z okazji i zaprosić Pawła na PAUG’a.

Formuła BYOP (ang. Bring Your Own Problem) – metoda grupowego rozwiązywania problemów – stosowana w miarę regularnie od pewnego czasu, sprawdza się bardzo dobrze, stąd i tym razem spotkanie podzielone zostało na część warsztatową (BYOP) oraz prelekcję zaproszonego gościa.

Część pierwsza: Bring Your Own Problem

Sesje BYOP jak zwykle nie zawiodły, tym razem dotyczyły trzech trzech tematów:

  • miar oraz metryk dla małego zespołu,
  • usprawnienia procesu pracy administratorów systemowych,
  • rozwoju agile’a w organizacji opartej na strachu.

Problematyka mierzenia procesu zainteresowała mnie najbardziej i tej sesji poświęciłem najwięcej czasu. Chciałbym podzielić się kilkoma przemyśleniami uczestników, które uważam za wartościowe, a które nie są wystarczająco zrozumiałe na załączonym zdjęciu lub w ogóle nie zostały wymienione.

Efekt pracy grupy nad tematem "Metryki w małym zespole"

Efekt pracy grupy nad tematem „Metryki w małym zespole”

  1. Pomiar prędkość (ang. velocity) jest dobrym pomysłem, jednak należy pamiętać o tym, że możemy jako zespół mieć bardzo dużą prędkość i jednocześnie robić zupełnie nie to, co powinniśmy. Wniosek jest taki, że warto mieć kilka miar, tak aby nie wyciągać pochopnych wniosków tylko na podstawie jednej z nich.
  2. Przepustowość procesu (ang. throughput), czyli liczba realizowanych zadań per jednostka czasu wg badań Larry’ego Maccherone, na które powoływał się Paweł Brodziński, to „najlepsza proxy miara produktywności” (dla chętnych – Larry opowiada o tym w tym video)
  3. Cost of delay to również ciekawa miara, mówiąca nam o wpływie, jaki wywieramy, decydując się na opóźnienie realizacji zadań. Może okazać się przydatna podczas rozmawiania o terminach ze stakeholderami, bo jak pokazuje życie, nie zawsze przysłowiowy priorytet “ASAP” jest faktycznie aż tak pilny (inna sprawa, czy w ogóle jest ważny)

Część druga: prezentacja “Doświadczenia płynące z wdrożeń metod i praktyk Lean i Agile”

Paweł rozpoczął prezentację od obserwacji, że od dłuższego czasu pojawia się z tą prezentacją w różnych miejscach i zastanawia się, jak przekazać jej treść tak, aby była zrozumiała. Być może prezentacja była już po kilku iteracjach poprawek (co sprawiło, że jest bardziej czytelna), jednak w mojej ocenie komunikat był prosty, zrozumiały i czytelny – zanim spróbujesz konkretnej praktyki agile lub lean, spróbuj zrozumieć, co za nią stoi.

Badania, od prezentacji których rozpoczął się wykład, są bezlitosne – ok. 70% inicjatyw zmian się nie udaje. Jeśli nawet próbujemy brać przykład od najlepszych, zazwyczaj kopiujemy to, co jest najbardziej widoczne (praktyki), ale już niekoniecznie najważniejsze (pryncypia oraz wartości).

Prelegent jako jeden z przykładów podał case Amazona, który wrzuca kod na produkcję co 11,6 sekund. Wg. Pawła, gdyby ślepo i bezrefleksyjnie stosowali “Scrum by book” w kontekście timebox’ów, nie byli by tak zwinni ze względu na ograniczenia wynikające z długości iteracji oraz zasady mówiącej o oddawaniu potencjalnie zbywalnego przyrostu na koniec Sprintu.

Poznańscy słuchacze zareagowali na to stwierdzenie refleksją, że najprawdopodobniej nie każde wdrożenie dostarcza wyczuwalną wartość dla użytkownika, a wysoka częstotliwość zapewne wynika ze skali aplikacji. Sam nie jestem do końca przekonany do tego przykładu, ponieważ Scrum to jednak framework i jeśli jest taka potrzeba oraz możliwość, to zrealizowana pierwszego dnia Sprintu funkcjonalność może od razu zostać wrzucona na środowisko produkcyjne, bez względu na trwanie iteracji.

Innym, w mojej ocenie trafniejszym przykładem jest implementacja gemba walk w firmie zajmującej się tworzeniem oprogramowania. Technika ta polega na pojawianiu się managementu firmy w miejscu, gdzie faktycznie wykonywana jest praca, celem lepszego zrozumienia procesów w firmie oraz szybszej likwidacji marnotrastwa (ang. waste). Paweł zwrócił uwagę, że o ile może to mieć zastosowanie w środowisku produkcyjnym, o tyle w firmie, gdzie to ludzie oraz interakcje między nimi tworzą faktyczną wartość, chwilowa obecność managera może być niewystarczająca i zbyt powierzchowna, aby głębiej zrozumieć istotę problemów. Nie do pominięcia jest również ryzyko wynikające z teorii złożoności, mówiące w uproszczeniu o tym, że samo pojawienie się managera w zespole (“systemie”) powoduje, że zespół zaczyna zachowywać się inaczej, adaptując się do zaistniałej zmiany.

Przykładów oczywiście było zdecydowanie więcej, jednak nie chciałbym omawiać ich wszystkich, tak aby potencjalny słuchacz, który trafi na prezentację Pawła na żywo, miał szansę usłyszeć je po raz pierwszy.

Sama prelekcja trwała ok. półtorej godziny, treść była dobrze dobrana do grupy docelowej, co generowało ciekawe pytania oraz interesujące, chwilami wręcz emocjonalne dyskusje w trakcie samej prelekcji. Poziom konwersacji stał na wysokim poziomie, co zauważył prelegent i nie zawahał podzielić się swoim przemyśleniem z resztą świata:

Tym akcentem zachęcam wszystkich do pojawienia się na kolejnym PAUG’u w Poznaniu, a także do wspierania i udzielania się na spotkaniach w innych miastach.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x