Koniec roku, czas podsumowań. Tym razem nie dzielimy się naszymi planami, bo po prostu sukcesywnie wdrażamy je w życie. Zerknijmy więc „jak było”, a „jak będzie” zobaczycie wkrótce.
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
Jak zapobiec konfliktom z wespołach? A może nie powinniśmy im zapobiegać? Czy jest możliwe, że konflikty są nam na rękę? Dzisiejszy post traktuje o nieoczywistych aspektach konfliktu i jak z nimi sobie radzić. A czasem jak sobie nie radzić.
Mówi się że wszystko co nowe, to zapomniane stare. Jeżeli uznamy to powiedzenie za prawdę, to musi ono dotyczyć również i Scruma, którego oficjalna historia liczy 20 lat. Czy może być tak, że ten framework istniał dużo wcześniej? I, co ważniejsze, jak odpowiedź na to pytanie pomoże nam budować lepsze zespoły dzisiaj?
Muda to dobrze wszystkim znane marnotrawstwo. Ale nie jest to jedyna przypadłość, której warto unikać. W dzisiejszym tekście poznamy także Muri, czyli przeciążenie i Mura – nierówną produkcję. Zapraszam na krótką lekcję japońskiego.
Czy zespoły powinny mieć wolną rękę do ustalania sposobu pracy i wręcz być „puszczone samopas”, aby znalazły najlepszą i najbardziej efektywną drogę? Niektórzy krzykną „tak, oczywiście”, a inni będą wieścić katastrofę. A odpowiedź jak zwykle brzmi „to zależy”.
Założeniem Scrum jest stwierdzenie, że jeden Produkt to jeden Product Backlog. Nawet patrząc z punktu widzenia nazwy – lista wymagań dotyczy produktu (Product) a nie produktów (Products). Dlaczego więc można spotkać konstrukcję zawierającą jeden Backlog i wiele różnych Produktów?
Co przychodzi wam na myśl, kiedy ktoś pyta o obowiązki Scrum Mastera? Czy jest to „prowadzenie wydarzeń Scrumowych” albo „pilnowanie zasad Scrum Guide”? Czy może „rozwiązywanie problemów zespołu”? Wymieniłem te trzy, bo, w moim doświadczeniu są to najbardziej rozpowszechnione odpowiedzi na to pytanie. Ośmielę się postawić tezę, że najważniejsze obowiązki tej roli są często przeoczone. Dlatego nazywam je „nieoczywistymi”.
Gdyby tytułowe pytanie zadał mi mój przełożony lub rekruter poprowadziłbym temat w stronę astronomicznie wysokich kwot. Na szczęście, ten post nie dotyczy moich osobistych zarobków, dlatego postaram się być obiektywny. Pewnie widzieliście kontrowersyjny film na kanale #białko o tym, czy Scrum Master powinien zarabiać 30 tysięcy złotych miesięcznie. Główny wniosek był taki: „zależy od tego ile on/ona dostarcza firmie”. Chciałbym dziś pokazać, jak możemy ten zysk ocenić.
Testy w Scrum? To jak wkładanie kija w mrowisko. Przecież zespoły tylko robią robotę, a testuje klient, zewnętrzni testerzy albo w ogóle ktoś jeszcze inny. Tylko czy tak naprawdę powinno być i czy to jest dobry pomysł?
Kiedy publikowałem na LinkedIn ankietę dotyczącą czasu trwania Daily, nie miałem wątpliwości, że pojawią się głosy na opcję „Powyżej 15 minut”. Jak myślicie, ile ich było? Czy faktycznie 15 min to za mało, aby przeprowadzić skuteczne Daily? Wyniki będą zaskakujące.
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]