Organization and presenting training - Kanban basics, 11.2016 - :-)

Kanban - English description,
Kanban - Polish description

Scrum #2 quiz

Quiz's difficult but very short. http://surveyanyplace.com/s/scrum2quiz

Simple scrum quiz

I would like to publish simple quiz to check your knowledge of Scrum. It's simple and about general definitions of Scrum, good luck. http://surveyanyplace.com/s/scrumquiz1

AgileByExample 2014 Wrażenia - Part 2/2 [Polish]

“NoEstimates”

Jedną z najbardziej wartościowych prezentacji w mojej opinii była „NoEstimates - Alternatives to Estimates” Henri Karhatsu. Idea NoEstimates nie przeciwstawia się całkowitemu zakazowi używania estymacji. Postulat ten podpowiada kiedy nie trzeba używać estymacji, w jakich momentach można zachować się inaczej bez wsparcia się wynikiem z estymacji i co robić, aby nie odwoływać się do estymacji.

Z sesji wybrałbym następujące punkty:

1 Nie zawsze w projekcie sytuacja wymaga podania estymacji czasowej zadania. Warto najpierw zastanowić się:

Czy dany problem jest rozwiązywalny,

Czy warto go teraz rozwiązać,

2 Czasami też warto najpierw zadać pytanie:

Jak ważne jest to zadanie w porównaniu do innych zadań.

Jaki jest możliwy deadline na to,

I jakie są konsekwencje przekroczenia deadline-u. (http://blog.karhatsu.com/2014/10/cost-of-delay-and-artificial-deadlines.html)

3 Można też zastanowić się jak pomóc w inny sposób w podjęciu decyzji niż podawanie estymacji (odsyłam do posta na ten temat http://blog.karhatsu.com/2014/03/need-to-estimate-part-ii.html ).

4 Kiedy nie trzeba wyliczać estymacji czasowej?

Jeśli zespół cyklicznie dostarcza funkcjonalności, User Story na czas, które są estymowane np. w punktach to można przyjąć, że estymacja czasowa zadań jest zbędna.

Na poparcie tego stwierdzenia można przytoczyć definicje “Manifesto for Agile”, w którym nie ma słowa o estymacji (http://agilemanifesto.org/ ) , a wręcz “Agile Manifesto" zawiera odważne sformułowanie, aby odnajdywać lepsze drogi do tworzenia oprogramowania:

“We are uncovering better ways of developing software by doing it and helping others do it.”

Po prostu to robić, a nie tylko zakładać.

5 #NoEstimates hash tag został utworzony w celu dyskusji nad tym tematem.

Definicja Woody Zuill #NoEstimates jest to hash tag związany z tematem odkrywania alternatyw co do “wymagania estymacji” w celu podjęcia decyzji podczas tworzenia oprogramowania.

Odsyłam do autora blogu na ten temat: http://blog.karhatsu.com/2014/06/about-definition-of-noestimates.html

6 Zostały przedstawione nierówności, które dają do myślenia:

Chęć otrzymania czegoś != Potrzebowanie czegoś

"Potrzebowanie" estymacji != Potrzebowania estymacji

7 Inny temat do zastanowienia:

Estymacja - > Fałszywa pewność, rzadko redukuje niepewność

Najlepszy sposób na usunięcie niepewności w tworzeniu oprogramowania -> przekazywanie działającego software-u.

Przykład: Jeśli chciałbyś zainwestować w projekt, który wy estymowany został na 1 milion dolarów. Czy wydałbyś 50k więcej, aby dowiedzieć się więcej o projekcie (drip funding).

Można wykorzystać podejście Build-Measure-Learn (LeanStartup - Eric Ries)

Podsumowując. NoEstimates zawiera proste, a czasem banalne porady, które jeśli są używane częściej niż zwykle, mogą pokazać, uwypuklić prawdziwe problemy w procesie, produkcie, zamiast łudzić się, że będzie dobrze w wyznaczonym przez NAS czasie!

“Fail”

Spośród prezentacji, które przedstawiały ciekawostki, konkrety, akcentowały coś co już wiemy chciałbym przedstawić sesje “What went wrong (and what can we learn form it)”.

Czasami mimo najlepszych chęci, poprawnych decyzji produkt poniósł całościowo totalną porażkę.

Wyobraźmy sobie, że projekt stworzenia i wdrożenia samolotu Boeing 787 Dreamliner opóźnił się o 5 lat, a koszt projektu końcowy został przekroczony o 500% względem prognozowanego na 32 miliardy dolarów. Możemy, pomyśleć, że takie sumy, projekty nas nie dotyczą. Jeśli te firmy i inne osoby spoglądają na te porażki i powody z jakich się zrodziły to warto abyśmy my na to spojrzeli i mogli wyciągnąć wnioski.

Porażka projektu Dreamliner spowodowana była skupieniem się tylko na wartości dla akcjonariuszy. Projekt początkowo był nastawiony tylko na zdobycie maksymalnych oszczędności. Niestety takie podejście sprawiło, że pojawiły się opóźnienia, których nikt nie był w stanie oszacować.

W kolejnym przykładzie Kate Terlecka przygotowała świetne zdjęcia, które pokazują jak przy tworzeniu produktu ważne jest myślenie w pierwszej kolejności o kliencie.

Czy wiadomo, że wielką porażką potentata samochodowego Volswagena było świetne auto Volkswagen Phaeton? Otóż powód tej porażki związany był z tym, że Volswagen zaprojektował i stworzył auto perfekcyjne, ale nie dla klienta, który był skojarzony z ich marką. Nikt, go po prostu nie chciał kupić.

Na koniec tej sesji przytoczony został cytat Charles Darwin, który według mnie najlepiej obrazuje jak ważne jest w firmie, produkcie i procesie jak np. Agile dostosowywanie się do zmian:

"it is not the strongest of the species that survives. nor the most intelligent . but rather the most adaptable to change"

Charles Darwin

Podsumowanie

Moim zdaniem najodważniejszą prezentację przedstawił Paweł Skolimowski z tematem "A dead Scrum Master is a useless Scrum Master". Według mnie trzeba mieć dużą odwagę i pasję, aby prezentować trudny temat porażek Scrum Mastera na podstawie własnego cennego doświadczenia. Paweł przedstawił jak ważne jest realistyczne wdrażanie praktyk scrum-owych przez dobry kontakt z klientem, zaufanie, budowanie więzi czyli po prostu przez wprowadzenie oddolnych zmian. Dla mnie była to najlepsza prezentacja.

W mojej opinii udział w konferencji nie był czasem straconym ponieważ konferencja poruszała trudne elementy pracy w Agile oraz te strefy pracy z projektem, produktem w grupie na które trzeba zwrócić większą uwagę.

O organizacji konferencji:

Biorąc pod uwagę tematykę, można było stworzyć więcej interakcji z uczestnikami, np. brakowało choć sprawdzenia, czy formuła po pierwszym dniu odpowiedziała na potrzeby słuchaczy lub czy “klienci” mają inne wymagania. W końcu Agile jest to zwinne dostosowywanie się do wymagań klienta. :-)

----------------

Jeśli zainteresował Cie temat/zawartość post-a i mógłbyś wpisać mi swój komentarz, aby ten post był lepszy. Proszę wypełnij formularz:

Google form

Twój komentarz jest szalenie ważny dla mnie.

Mail jest opcjonalny i może służyć tylko do współpracy nad tym artykułem. Z mojej strony mogę zapewnić Cię, że dane nie zostaną udostępnione.

DZIĘKI

AgileByExample 2014 Wrażenia - Part 1/2 [Polish]

W ostatnim czasie uczestniczyłem w Agile By Example 2014. Na konferencji przedstawione zostały ciekawe praktyki, pomysły i tematy do przemyśleń.

Wśród zaprezentowanych wystąpień, najbardziej interesujące według mnie były:

1 Deweloping Great Scrum Masters, Lean Startup for Agile Product Management - Ángel Medinilla, - trafne spostrzeżenia, energetyczne forma.

2 Feedback candies - Krzysztof Czajka, - ciekawa praktyczna metoda,

3 A dead Scrum Master is a useless Scrum Master - Paweł Słowikowski, - bardzo ważne spostrzeżenia oparte na doświadczeniu,

4 How to build MVP with Walking Skeleton and Story Mapping - Andrzej Winnicki, - przedstawiona nowoczesna metoda tworzenia MVP oparta na praktycznym wdrożeniu,

5 Staying On Track - Pawel Wrzeszcz, cenne, proste sugestie warte przypomnienia,

6 The Antimatter Principle - Bob Marshall, ciekawa forma prezentacji, temat do przemyślenia,

7 NoEstimates - Alternatives to Estimates - Henri Karhatsu, - praktyczne, proste uwagi odnośnie estymacji

8 What went wrong - Kate Terlecka, ciekawa forma prezentacji o dostosowywaniu się do zmian.

9 Lessons in Gravity: Helping Good Ideas Reach Escape Velocity - David Hussman, - David nakreślił (własnym rysikiem) tak obszerny temat o projektowaniu, myśleniu, wspieraniu tworzenia, że można by stworzyć obszerny artykuł.

Zanotowałem niektóre key note-y:

skupienie na meeting-u, np. Steve Jobs zawsze pytał czemu tu jesteś, w komunikacji na meeting-ach powinno być używane zrozumiałe nazewnictwo, minimum viable learning.

i wiele, wiele ciekawych...

Konferencja miała cztery formy wymiany wiedzy: key note-y, integracja poza salą, open space discussion i pytania do eksperta.

Można było skorzystać z dwóch sal, na których równolegle przedstawiane były dwie linie prezentacji. Niestety trafiły się prezentacje z nieprzemyślaną formą lub słabym przedstawieniem przez prelegenta- czasami była to autoreklama.

Zamiast wykładu można było skorzystać z open session discussion lub zadać pytania ekspertowi.

“LeanStartup”

Najbardziej przebojowe prezentacje przedstawił Ángel Medinilla. “Developing Great Scrum Masters”, “Lean Startup for Agile Product Management” prezentacje te to po prostu była bomba energetyczna. Na pierwszą niestety nie wybrałem się, co później okazało się błędem.

W tym czasie Lukasz Szóstek w sesji "Just how much upfront design and architecture do you need?" próbował udowodnić, że projekt Philipsa multimedialnego odtwarzacza dla biegaczy, był słusznie realizowany w modelu Waterfall. Zaprezentował kilka ciekawych przykładów projektowania skomplikowanych algorytmów metodą Waterfall. Osobiście nie zgodzę się, że nie dało się tego projektu realizować według Agile. Tym bardziej, że Philips z nieznanego powodu zamknął projekt. Według mnie była to kolejna prezentacja pokazująca trzeźwe spojrzenie na różne typy projektów informatycznych i ich skomplikowanie.

Temat “Developing Great Scrum Masters” można zobaczyć pod tym linkiem: http://www.infoq.com/presentations/hire-scrum-master.

Natomiast “Lean Startup for Agile Product Management” zawierał podstawy LeanStartup http://en.wikipedia.org/wiki/Lean_startup . Prezentacja rozpoczęła się w kuriozalny, a zarazem śmieszny sposób. W małej sali kinowej nie wypełnionej do końca co chwilę przychodziły osoby i zajmowały miejsca. Trudno to zobrazować, ale sala wypełniła się po brzegi, kanapy przy prelegencie, schody, wolny teren przy drzwiach, tak , że osoby musiały zaglądać do sali przez uchylone drzwi :-).

Padła nawet propozycja, aby zamienić salę z małej na główną na czas tego jednego wykładu.

Dla osób, które pierwszy raz czytają o LeanStartup, mogę powiedzieć że jest to nowa dziedzina tworzenia produktu opisana przez Eric Ries i Steve Blank. Podejście to opiera się na Agile oraz na myśli jak stworzyć produkt w małych działających kawałkach zwanych MVP. LeanStartup jest obecnie najnowocześniejszym, bardzo trudnym podejściem tworzenia najtrafniejszych produktów. Podczas sesji poruszone były podstawowe elementy LeanStartup:

- zrozumienie wartości jaką ma mieć produkt dla klienta,

- myślenie o problemie, a nie o rozwiązaniu,

- zwrócenie uwagi na wartość finansową produktu,

- cykliczne wdrażanie produktu,

- budowanie celu i liczenie metryk,

- zarządzanie backlog-iem,

- usuwanie niepotrzebnych funkcjonalności - “Kill a Feature Day”

Dla osób, które znają już ten temat, to prezentacja w ciągu kilkudziesięciu minut tylko w barwny sposób ukazywała podstawy LeanStartup bez praktycznych przykładów, czy też sugestii. Wydaje mi się, że ten temat był wybrany dla osób nie znających w ogóle LeanStartup. Czy bym polecił tą prezentacje?

Myślę, że tak, bo forma przedstawienia tematu przez Ángel Medinilla była naprawdę godna uwagi: energia, ekspresja i sporo humoru. Polecam wszystkim zobaczyć na żywo prezentację Ángel Medinilla.

AgileByExample 2014 Wrażenia - Part 2/2

----------------

Jeśli zainteresował Cie temat/zawartość post-a i mógłbyś wpisać mi swój komentarz, aby ten post był lepszy. Proszę wypełnij formularz:

Google form

Twój komentarz jest szalenie ważny dla mnie.

Mail jest opcjonalny i może służyć tylko do współpracy nad tym artykułem. Z mojej strony mogę zapewnić Cię, że dane nie zostaną udostępnione.

DZIĘKI