Podczas mini-konferencji SAFe@Space miałem przyjemność opowiadać o różnicach między frameworkami LeSS i SAFe – oraz o pytaniach, które warto sobie zadać. Slajdy z tej prezentacji można znaleźć poniżej. 10 differences between SAFe and LeSS from Stanislaw Matczak (zdjęcie: Adam Szmukała)
Planowanie sprintu przypomina planowanie kolejnego etapu pieszej wycieczki. Jesteśmy w punkcie A. Rano wstajemy i planujemy przebieg trasy na dzisiejszy dzień. Planujemy, że na koniec dnia chcemy znaleźć się w punkcie B. W trakcie naszej wycieczki spotykają nas różne niespodzianki – okazuje się, że mapa jest nieaktualna; że nie ma mostu, z którego chcieliśmy skorzystać; że drogę zagradza nam wysoki płot. Musimy sobie radzić z niespodziankami i wymyślać rozwiązania problemów. Finalnie, na koniec dnia rozbijamy obóz i sprawdzamy, czy jesteśmy w miejscu, do którego planowaliśmy dotrzeć. Być może tak jest. A być może jesteśmy zupełnie gdzie indziej…
Wiele zespołów IT na całym świecie działa w bardzo podobny sposób.
Mamy Klienta. Klient ma wizję – chciałby mieć system, funkcjonalność czy możliwość wykonywana pewnej operacji. „Chciałbym, żeby nasz system mógł eksportować dane do Excela”. „Chciałbym mieć możliwość podglądu stanów magazynowych”. „Chciałbym mieć możliwość szybkiej konsolidacji list mailingowych z wielu źródeł”. Klient ma pieniądze, które może wydać na urzeczywistnienie tego pomysłu. Czasami jest to żywa gotówka, ale najczęściej jest to po prostu możliwość dedykowania czasu pracy jakiegoś zespołu na potrzeby realizacji tej wizji. Klientowi przeważnie zależy na czasie – chciałby mieć swoją funkcjonalność jak najszybciej.
Szkolenie z framework’a LeSS rozpoczyna się takim pytaniem: „After years working in large multisite offshore development, our key advice?”. Chwila napięcia, werble i na następnym slajdzie pada odpowiedź: “Large – don’t. Multisite – don’t. Offshore – don’t”.
Większość framework’ów zwinnych sugeruje, aby wszyscy członkowie zespołu pracowali w jednej lokalizacji. Ale praktyka jest często inna: w większości firm, w których pracowałem, członkowie zespołu byli rozproszeni po wielu lokalizacjach. Jak może zatem wyglądać praca Scrum Mastera w zespole rozproszonym?
…czyli o różnicy między zapisywaniem dokumentu z wymaganiami, a tworzeniem mapy historyjek.
Tworząc oprogramowanie często zaczynamy od jakiegoś konceptu lub wyobrażenia – próbujemy określić, co nasz system ma robić albo jaki problem ma on rozwiązywać. Bardzo często narzędziem do zapisania tego konceptu staje się edytor tekstu. Tworzymy dokument, który opisuje kształt naszego rozwiązania. Bardzo często dokument ten otrzymuje tytuł „Analiza wymagań systemu XYZ”.
W samym pomyśle zapisania koncepcji lub wymagań nie ma nic zdrożnego. Natomiast często w praktyce bywa tak, że praca nad systemem oparta o obszerny dokument tekstowy niesie za sobą niepożądane skutki uboczne…
Zdarza się czasami, że rozmawiam z kimś, używamy tych samych wyrazów, wydaje się, że rozmawiamy o tym samym – i niespodziewanie w rozmowie pojawia się niezrozumienie lub zdumienie. Często wówczas odkrywamy, że co prawda używamy tych samych słów, ale zupełnie inaczej je rozumiemy…
Kiedy rozmawiam o wytwarzaniu oprogramowania, takie niezrozumienie często pojawia się przy terminie Właściciel Produkt. Zdarza się, że ktoś mówi „tak, mamy oczywiście właścicieli produktów” – a później okazuje się, że opisuje rolę menedżera albo kierownika projektu.
Po co nam Właściciel Produktu i czym ta osoba różni się od Kierownika Projektu? Spróbujmy to sobie narysować!
Na portalu AgileBrains Przemek napisał bardzo dobry tekst „Metryki w Scrum – Jak mierzyć efektywność wdrożenia Scruma?”. Po przeczytaniu tego artykułu można odnieść wrażenie, że bardzo łatwo jest zacząć mierzyć i odkrywać nowe wymiary efektywności. Bułka z masłem. Albo kawałek ciastka, jak mawiają Amerykanie.
Tymczasem w organizacjach, z którymi pracowałem, bardzo rzadko spotykałem się z używaniem wartościowych metryk. Dlaczego tak jest? Dlaczego mamy dostępnych sporo ciekawych metryk – a tak rzadko ich używamy?
W 2012 roku Henrik Kniberg opublikował krótki film, w którym wyjaśnia ideę „Agile Product Ownership in a Nutshell”. Filmik zdecydowanie warto obejrzeć – a ja dzisiaj chciałbym wykorzystać obrazek z tego filmu do zastanawienia się, dlaczego dużym organizacjom IT trudno jest zwinnie rozwijać produkty.
Naszkicowany przez Kniberga obraz zwinnego wytwarzania produktu wygląda tak:
Kiedy decydujemy się na pracę we framework’u Scrum, to oczekujemy z tego jakichś korzyści. Zresztą obiecuje nam to sam Scrum Guide mówiąc, iż dzięki Scrumowi możemy „wytwarzać produkty o najwyższej możliwej wartości”.
Czasami jednak wprowadzamy takie rzeczy jak „sprint”, „backlog” i „właściciel produktu” – a jednak nie dostrzegamy żadnych benefitów. Mamy poczucie, że tracimy czas na planowaniach, stand-upach i przeglądach, a nie dostajemy nic w zamian…
Przyczyny takiego stanu mogą być oczywiście różne – w tym tekście chciałbym omówić jedną z nich, którą jest brak barier chroniących zespół deweloperski.
Zdarzyło mi się kiedyś usłyszeć takie słowa „No to mamy tego Scruma, ale mamy mały problem z Właścicielem Produktu…”. „Hm, a co to znaczy: mały problem?” – zapytałem. „W zasadzie to problem polega na tym, że go nie ma…”.
Scrum Guide mówi jasno: żeby nazywać swoją pracę Scrumem, musisz mieć wszystkie elementy opisane w tym przewodniku. Jednym z najważniejszych elementów Scruma jest rola Właściciela Produktu – jeżeli go nie ma (albo jeżeli z jakiegoś powodu nie pełni swojej roli, albo jest więcej niż jedna osoba zarządzająca backlogiem), to po prostu nasza metoda pracy nie jest Scrumem, tylko czymś innym.
I tutaj często pojawia się kolejne zastrzeżenie: „Ale nasz produkt jest tak skomplikowany, że nie ma żadnej osoby, która potrafiłaby go zrozumieć i pełnić taką rolę!”. Przyjrzyjmy się zatem, w jaki sposób różne metody i frameworki radzą sobie z problemem zarządzania złożonym backlogiem.
