Do czytania

  1. Zwinność sprowadzona do najbardziej istotnych składowych Agile. ⏩ https://age-of-product.com/agile-primitives-beyond-frameworks/

  2. Znacie moje zdanie na temat krytyki roli Scrum Mastera przez Marty Cagana, jednak staram się lepiej zrozumieć jego wizję tej roli jako Delivery Managera. ⏩ https://www.svpg.com/the-delivery-manager-role/

  3. Macie do przekazania zespołowi niezbyt dobre wiadomości? Łapcie garść wskazówek pomocnych właśnie w takich momentach. ⏩ https://newsletter.weskao.com/p/delivering-bad-news-thats-not-your-fault

  4. Konkretna i przydatna instrukcja, jak krok po kroku przeprowadzić warsztat Opportunity Solution Tree. ⏩ https://docondev.substack.com/p/opportunity-solution-trees

  5. Sensowna krytyka tercetu zespołowego, które odpowiedzialność odbiera inicjatywę zespołowi. Głos za większą “krosfunkcjonalnością” zespołu. ⏩ https://afonsofranco.substack.com/p/a-different-lens-of-seeing-a-product

  6. Czy Scrum Master to niepotrzebny koszt? Ciekawe pytanie i argumentacja autora. Chciałbym się z nim spotkać 1:1 i porozmawiać, albowiem jako osoba, która uważa, że moją rolą jest stać się niemalże redundantny dla zespołu, jestem w stanie sobie wyobrazić, że wchodzę w nowe miejsce i nie mam co robić - jednak od 15 lat nigdy się nie nudziłem w zespołach. ⏩️ http://mdalmijn.com/p/are-scrum-masters-too-much-overhead

  7. Przydatne pytania i podpowiedzi, które pomogą nam rozpoznać, czy dobrze delegujemy, wspieramy autonomię zespołów oraz, czy nie popadamy w mikro zarządzanie? ⏩️ http://jrothman.com/mpd/2024/10/how-to-create-more-autonomy-and-finish-more-work-with-just-enough-delegation

  8. Przyznam się szczerze, że przez niemałą część artykułu zastanawiałem się, czy w końcu autor dojdzie do czegoś ciekawego, bo do tej pory mówił o banałach - i się doczekałem. Nie myślałem nigdy w ten sposób o zgłoszeniach klienta, a stosowanie BEAM ma dużo sensu. ⏩️ http://gojko.net/2024/09/30/from-bugs-to-beam

  9. Ciekawy wynik badania, według którego zaledwie 6% ficzerów, jakie dostarczają zespoły, jest adaptowane przez użytkowników tego produktu. ⏩️ http://mindtheproduct.com/users-engage-with-6-of-product-features-product-benchmark-findings

  10. Stefan Wolpers wykonuje ogromną pracę, aby dzielić się wiedzą ze społecznością Agile. Wcześniej było coś o fundamentach Agile, a teraz o procesie ich inkorporacji w organizacji. ⏩️ https://age-of-product.com/transformation-agile-primitives/

  11. Premie i kary w organizacji to bardzo skomplikowany temat, w którym z reguły stoją po stronie “lepiej nie”, w kwestiach dodawania ich do codzienności zespołów. Ten post porusza ich wątek w kontekście podejmowania decyzji i wpadek, które zdarzają się wszędzie. ⏩️ http://ferd.ca/carrots-sticks-and-making-things-worse.html

  12. Świetny artykuł. Praca w trójkach to coś, co staje się niezwykle popularne i niemalże standardem w wielu organizacjach. Dla mnie to codzienność i doceniam te wskazówki. ⏩️ http://producttalk.org/2024/10/hurdles-effective-product-trio-collaboration

  13. Narzędzie ‘5 WHYs' to całkiem dobrze sprawdzony w bojach sposób na sprawdzanie “prawdziwego” źródła problemu. Jednak, czy dziś ono wystarczy? A może warto zadać inne pytania? A może ‘why not both’? ⏩️ http://dianastepner.substack.com/p/beyond-the-five-whys-the-power-of

  14. Był materiał kwestionujący istotę Scrum Mastera w zespole i organizacji, więc w duchu sprawiedliwości teraz przyjrzyjmy się Product Ownerom. ⏩ https://mdalmijn.com/p/are-product-owners-too-much-overhead

  15. Bardzo dobre przedstawienie, dlaczego gonitwa za ficzerami konkurencji, to droga donikąd. ⏩️ http://swkhan.medium.com/why-trying-to-achieve-feature-parity-with-competitors-is-a-bad-idea-309de9b4d7db

  16. Troszkę czepianie się semantyki, ale zamiary autora są słuszne. O wymaganiach i tym, co jest za nimi. ⏩️ http://mdalmijn.com/p/wtf-is-a-requirement

  17. Życie kolejny raz pokierowało mnie w stronę zmiany miejsca pracy, więc materiał na temat przekazywania wiedzy, przydaje się. Choć duplikowanie ról to nieco dziwna rada. Raczej unikanie i rozkładanie silosów - to istotne. ⏩️ http://imwrightshardcode.com/2024/10/knowledge-loss

  18. Konflikty to codzienność pracy zespołu. Unikanie ich jak ognia, czy też nazywanie ich czymkolwiek innym, jest głupie. Konflikty budują rozwiązania i charakter, więc trzeba je okiełznać. ⏩️ http://sorenkaplan.com/managing-team-conflict-3

  19. Ku przestrodze! Prawda o naśladowaniu modelu Spotify. ⏩️ http://imanageproducts.com/producthead-the-backlash-against-the-spotify-model

  20. A tutaj nieco szerzej i głębiej o problemach, gdy staramy się narzucić naszej organizacji model innej, czy jakiegoś frameworka “z półki”. ⏩️ http://forbes.com/councils/forbescoachescouncil/2024/09/30/the-pitfalls-of-framework-fever-why-one-size-fits-all-approaches-fail-in-complex-organizations

  21. Łatwiej powiedzieć, aniżeli zrobić. Roadmapa usuwanych części produktu. To by był dzień, gdybym kiedyś widział takową u PO. ⏩️ http://productcoalition.com/delete-to-accelerate-transforming-your-product-with-a-reverse-roadmap-bcf63196158e

Do oglądania | słuchania

  1. Mimo że nie jestem zbyt wielkim fanem sztucznej inteligencji, to oddać muszę Henrikowi, że tak błyskawiczne prototypowanie robi wrażenie. ⏩ https://youtu.be/f4twF1r1gJU?si=xvkXpNpu_VcbTNfB

Heheszek

alt_text