Zwinność w praktyce

Obecna fala popularności metod zwinnych ma też swoją ciemną stronę. Wszyscy chcą być zwinni, wszyscy chwalą się udanymi transformacjami, zmniejszaniem Time-To-Market, zwiększaniem samoorganizacji, a dookoła narasta hałas, mgła, dym oraz opowieści dziwnej treści… Zdarza mi się spotykać osoby, które swoje pojęcie o metodach zwinnych opierają na swoich doświadczeniach z firm, które „stosują pół Scruma i mają JIRĘ”.

Dlatego opowiadając ludziom o podejściu zwinnym często zaczynam od pewnej metafory, której celem jest uporządkowanie pojęć. Pozwólcie, że ją opiszę.

Czytaj więcej »Jak być zdrowym i zwinnym?

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… Czytaj więcej »10 różnic pomiędzy SAFe and LeSS

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…

Czytaj więcej »Pewien pomysł na podsumowanie sprintu

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.

Czytaj więcej »Czyj jest ten plan?

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?

Czytaj więcej »Scrum Master 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…

Czytaj więcej »Dokument czy mapa?

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ć!

Czytaj więcej »Po co nam ten Product Owner? (historia ilustrowana)

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?

Czytaj więcej »Nie używamy metryk, bo…

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:

Czytaj więcej »Dlaczego trudno być dużym i zwinnym

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.

Czytaj więcej »Dlaczego Scrum nie działa – część 2