Zbiór przemyśleń opartych na doświadczeniu, teorii i ciekawości. Bierz, co Ci się przyda.
Dlaczego Frederick Taylor mierzył czas operacji, a nie przepływ pracy? Wspólny interes firmy i pracownika, dzisiejszy obraz Taylora i osiem obszarów wiedzy.
Ukryte kolejki pracy w organizacji przypominają tablicę tablic z C++: widać liczbę zespołów, a nie pracę, która czeka w ich kolejkach. Jak je policzyć.
Rezultat pracy developera: kod i zamknięte tickety to wyniki, a rezultat to zaspokojona potrzeba użytkownika i korzyść dla firmy. Co mówią Amazon i Vogels.
Jak zobaczyć pracę, która czeka w zespole: proste ćwiczenie z tablicą, powód i wiek czekania zamiast mierzenia, czy wszyscy są zajęci.
Sprinty dają stałej cenie to, czego potrzebuje: stały koszt i termin. Ruchomy zostaje zakres, a zarządzanie nim to osobna umiejętność.
Developer czy inżynier produktu? Kod i zamknięte tickety to wyniki, rezultat jest u użytkownika. Jak AI zmienia rolę developera. Zapowiedź serii.
Enkapsulacja w organizacji: system chowa złożoność, a firma wystawia ją na zewnątrz. Dlaczego zmiana przekrojowa wymaga rozmów z wieloma zespołami.
Koszt opóźnienia (cost of delay) według Reinertsena: dlaczego 85% osób nie wie, ile kosztuje miesiąc opóźnienia, i czemu prawie nikt nie mierzy kolejek.
Gdy każda decyzja czeka na jedną osobę, kalendarz managera staje się wąskim gardłem. Jak oddać zespołowi decyzje: zakres, progi i informacje.
Shadow IT jako szara strefa: prywatne arkusze, niezatwierdzone aplikacje i automatyzacje tworzą ryzyko, o którym firma nie wie (unknown unknowns).
Historia iteracji starsza niż Agile: Shewhart, program Mercury i Royce, który wcale nie zalecał wodospadu. Iteracyjne wytwarzanie przed Manifestem.
Aging WIP w Azure DevOps: darmowy plugin pokazujący wiek otwartych work itemów i czas w obecnym stanie, czyli zapomnianą pracę. Zrobiony z Claude.
Mêtis i techne według Jamesa C. Scotta: dlaczego proces działa dzięki ludziom, którzy po cichu go łamią, i czego manager nie widzi w instrukcji.
„Jak to jest duże?” to trzy pytania w jednym: o wielkość, termin i koszt. Dlaczego estymacja w dniach je zlewa i jak rozmawiać o każdym osobno.
Czy kolumna Blocked na tablicy pomaga? Dane z historii zadań: ile wraca do pracy, ile do backlogu, ile jest usuwanych i jak to fałszuje cycle time.
Cycle time i przewidywalność: dlaczego spadek mediany nie wystarcza, gdy 85. percentyl rośnie, i jak długi ogon rozkładu wydłuża obietnice dla klienta.
Backlog z jednym zdaniem na pomysł: szaleństwo czy metoda? Co AI zaproponowało jako backlog pomysłów i czemu krótki wpis działa, jeśli prowadzi do rozmowy.
Zajętość a postęp: zajęci ludzie kosztują tyle samo co praca, która coś zmienia. Jak odróżnić ruch od postępu, zaczynając od pytania o cel.
Cel Sprintu w Scrumie: co się dzieje, gdy go brakuje, dlaczego zespół goni wtedy cały Sprint Backlog i jak jedno zdanie daje kierunek i swobodę.
Czym różni się grupa od zespołu? Wspólnym celem. Dlaczego bez niego kompetentni i zajęci ludzie ciągną w różne strony, a zajętość udaje postęp.
Specjalizacja w zespole a rozmyta odpowiedzialność: problem wielu rąk, czyli dlaczego w zespole samych ekspertów coś się sypie, a nikt nie jest winny.
Resolver, kubańska postawa „ogarnę to sam”: kiedy to zdrowa inicjatywa, a kiedy sygnał, że system przecieka. Potrzeba, pilność, odpowiedzialność, autonomia.
Organizacja jak sudoku: zmiana w jednym zespole otwiera albo zamyka możliwości w innych. Gdzie metafora działa, gdzie ma granice i czemu rozwiązań jest wiele.
Struktury organizacyjne powstają, żeby ułatwić zarządzanie, a praca pod nimi meandruje. Czego uczy pruski las z „Seeing Like a State” o schematach i roadmapach.
Teoria ograniczeń (TOC) Goldratta: dlaczego przyspieszenie każdego zespołu nie przyspiesza całości i jak pięć kroków pomaga znaleźć i usunąć wąskie gardło.
LeSS (Large-Scale Scrum) skaluje przez upraszczanie: jeden Product Backlog, jeden Product Owner, bez warstw pośrednich. Mniej koordynacji, szybsza reakcja.
Extreme Programming (XP) w praktyce: jak pair programming, TDD i continuous integration zmniejszają liczbę błędów i rozpraszają wiedzę po całym zespole.
Myślenie systemowe: dlaczego błąd wraca, gdy naprawiasz objawy, jak pętle przyczynowo-skutkowe pokazują opóźnione skutki decyzji i gdzie szukać trwałej zmiany.
Design Thinking odwraca kolejność: najpierw rozumiesz użytkownika, potem budujesz. Jak wywiady, mapa empatii i szybkie prototypy chronią przed drogimi błędami.
DevOps jako współodpowiedzialność Dev i Ops za kod od napisania do produkcji. Jak automatyczne pipeline'y i infrastruktura jako kod skracają drogę do klienta.
Marnotrawstwo w projekcie według Lean: zbędne kroki, nieużywane funkcje i błędy wykryte za późno. Jak mapa strumienia wartości pomaga je znaleźć i usunąć.
Kanban i limity WIP: dlaczego zespół spowalnia liczba zadań zaczętych naraz, jak tablica pokazuje, gdzie praca stoi, i co zmienia limit WIP.
Scrum to nie metodyka zarządzania, tylko sposób na informację zwrotną i ryzyko: po co sprint ma stałą długość i co daje podejście iteracyjne.
Prawdopodobieństwo a koszt opóźnienia na przykładzie paczki: dlaczego 98% dostaw na czas nic nie mówi o Twoim ryzyku i co pokazuje ogon rozkładu.
Zakres, czas, jakość i koszt: ten model projektu ma kilka dekad. Czy AI naprawdę go nie zmienia, czy zmienia coś, czego jeszcze nie umiemy zmierzyć?
PERT w estymacji: liczy się odległość między wariantem optymistycznym a pesymistycznym. Jak z trzech scenariuszy zrobić rozmowę o tym, od czego zależy termin.
Kenneth Arrow pokazał, czemu rynek za mało inwestuje w wiedzę. Ten sam mechanizm sprawia, że zespoły odkładają refaktoryzację, testy i dokumentację.
Prostota czy elastyczność produktu? Każda decyzja coś domyka albo zostawia otwarte. Jak ocenić, kiedy zapłacić sztywnością, a kiedy złożonością za opcję.
Koszt epistemiczny to cena wiedzy zdobywanej tylko przez próby i porażki. Dlaczego w raportach wygląda jak strata i co tracisz, optymalizując pod pewność.
Backend też ma użytkownika: czas ładowania, świeżość danych i stabilność to doświadczenie użytkownika, nawet gdy developer nie widzi interfejsu.
Weryfikacja a walidacja: zielone testy i pokrycie kodu mówią, czy zbudowaliśmy to, co chcieliśmy. Czy to rozwiązuje problem, mówi dopiero użytkownik.
Taylor czy Deming? Styl zarządzania, który szuka winy w ludziach, kontra podejście, w którym 94% problemów pochodzi z systemu, a nie z pracowników.
Kiedy spotkanie nie może być mailem: decyzje wymagające wielu perspektyw (SEO, UX, IT, sprzedaż) lepiej zapadają przy wspólnym muralu niż na czacie.
Bezpieczeństwo psychologiczne w zespole to za mało: bez wyzwań i napięcia zespół popada w stagnację i nie jest gotowy na prawdziwy problem.
Widoczność to nie transparencja: tablica z taskami i dashboard pokazują status, a transparencja to wiedza, dlaczego zapadły decyzje i co odrzucono.
Lokalna optymalizacja jako maksimum lokalne: dlaczego działy poprawiają własne metryki kosztem całości i czemu wyjście z tej pułapki boli.
Niewdrożony feature to zamrożony kapitał jak gotówka u brokera. Dlaczego wartość pojawia się dopiero po release i czemu otwarte pozycje to ryzyko.
Kopiowanie praktyk innych firm bez zrozumienia kontekstu: dlaczego model Spotify, OKR-y czy daily działają u nich, a u Ciebie już niekoniecznie.
„Jaki problem próbujesz rozwiązać?” Dlaczego to oklepane pytanie wciąż działa i czemu najlepsze rozwiązanie złego problemu to zmarnowana praca.
Co jest ważniejsze, IT czy biznes? To złe pytanie, jak mózg czy serce. Lepiej zapytać, co przeszkadza im działać razem i dowozić wspólne wyniki.
Agile jako opcjonalność: jak krótkie iteracje kupują prawo do zmiany zdania i dlaczego w niepewnym otoczeniu to cenniejsze niż sama szybkość.
Przedwczesna optymalizacja według Knutha poza kodem: trzy pytania przed usprawnianiem produktu, procesu lub zespołu, zanim zoptymalizujesz nie to.
Jak odróżnić dobrą metrykę biznesową od wskaźnika? Prosty test i trzy pytania o zachowanie użytkownika: co robi, dlaczego i co z tego wynika.
Świętowanie w zespole przy ciągłym dostarczaniu: gdy nie ma dużych release'ów ani mety, trzeba celowo tworzyć mniejsze powody do świętowania.
Output, outcome, impact i dźwignia: czym się różnią i jak połączyć to, co dostarczył zespół, ze zmianą u użytkowników i wynikiem biznesu.
Jak odpowiedzieć na pytanie „na kiedy to będzie?”: prognoza terminu symulacją Monte Carlo, 85. percentyl i rozmowa o dacie z organizacją.
Czym jest flow efficiency? Dlaczego ticket idzie 25 dni, choć praca nad nim trwa kilka godzin, i czemu organizacje mierzą zajętość zamiast przepływu.
Tolerancje w projekcie według PRINCE2: przedział budżetu, terminu i zakresu, w którym PM decyduje sam, zanim sprawa wróci do sponsora.
Praca na celach czy na zadaniach? Jak velocity, story pointy i zamknięte taski wypierają cele zespołu i dlaczego ludzie robią to, co jest nagradzane.
„Plans are worthless. Planning is everything.” Czym plan różni się od planowania, dlaczego plan bez planowania staje się pomnikiem i jak planować regularnie.
Lejek niepewności Boehma w erze AI: czy szybkie prototypy i krótsze pętle feedbacku redukują niepewność w projektach, czy dają tylko złudną pewność?
Strategia jako rzemiosło według Henry'ego Mintzberga: dlaczego skuteczna zmiana wyłania się z codziennych prób i błędów oraz jak z tego korzystać w praktyce.
Książka „10X Org” i Org Topologies: jak struktura organizacji wpływa na efektywność i dlaczego AI ani nowe procesy nie pomogą bez designu pod strategię.
Hierarchia, roczny budżet i kontrola planu to narzędzia z epoki fabryk. Pięć cech organizacji, które dziś działają, i czy da się je wdrożyć w dużej firmie.
Kultura organizacji jako macierz: fokus na rynek lub sprawy wewnętrzne i ludzie jak rodzina lub merytokracja. Cztery scenariusze i pytanie, gdzie jesteś.
Innowacje a compliance: dlaczego bramki bezpieczeństwa na końcu procesu blokują zmiany i jak wbudować standardy w pracę zespołów od pierwszego dnia.
Refinement w Scrumie: skąd 10% pojemności zespołu w starym Scrum Guide, co mówią o tym fazy Takeuchiego i Nonaki i co robić, gdy 10% to za mało.
Entropia oprogramowania: system, którego nie zmieniasz, i tak się psuje, bo zmienia się jego otoczenie. Dlaczego koszt utrzymania to warunek działania.
Interesariusz to nie klient wewnętrzny, tylko partner w ryzyku: współodpowiada za priorytety, definiuje sukces razem z zespołem i ma odwagę powiedzieć „stop”.
Tragedia wspólnego pastwiska w IT: każdy interesariusz ciągnie zespół w swoją stronę, a nikt nie dba o kod. Skąd dług techniczny i jak to naprawić.
Rok publikowania na LinkedIn w liczbach: wzrost wyświetleń o 3357%, zasięg 9 391 osób, walka z syndromem oszusta i przerwy w regularności.
Tydzień cienia to prosty eksperyment: kilka osób przez tydzień notuje, gdzie polityki firmowe spowalniają pracę. Jak go przeprowadzić i co może pokazać.
Wartość zwinności widać na poziomie portfela i decyzji o finansowaniu: sprint jako horyzont inwestycyjny, a zespół jako źródło sygnałów decyzyjnych.
Małe usprawnienia budują przewagę, ale giną w codziennej rutynie. Dziennik mikro-wygranych pomaga je zauważyć, zanim zapomnisz, co naprawdę zmieniło wynik.
Prawo Brandoliniego, czyli zasada asymetrii bzdury, w organizacji: dlaczego plotka rozchodzi się w minutę, a jej sprostowanie zajmuje tygodnie.
Samoregulacja zespołu po lekturze „Nexusa” Harariego: dlaczego autonomia bez kontaktu z rynkiem prowadzi do izolacji i jakie mechanizmy korygujące pomagają.
Kopiowanie rozwiązań innych firm to dobra heurystyka, ale tylko gdy rozumiemy mechanikę. Pobieżne kopiowanie modelu Spotify czy OKR-ów daje fasadę, nie wynik.
Od wykonawcy do partnera w Agile: zamiast dostarczać to, o co klient prosi, pytaj, jaki problem rozwiązujemy i co się stanie, jeśli tego nie zrobimy.
Efektywność a Lean: klasyczna efektywność optymalizuje to, co jest, a Lean najpierw eliminuje i upraszcza. Jak zapytać o sens, zanim zaczniesz optymalizować.
Eksperyment w zarządzaniu to nie chaos, tylko plan, który zakłada uczenie się. Kiedy planować, kiedy testować hipotezy i jak to wygląda w praktyce.
Transformacja Agile to nie ceremonie i metryki. Prawdziwa zmiana zaczyna się, gdy liczy się czas dostarczenia wartości, właściwe problemy i mniej marnotrawstwa.
Opóźnienia między zespołami w value stream: dlaczego lokalnie efektywne zespoły dają klientowi pół roku czekania i po co mierzyć cały przepływ.
Strategia a możliwości wykonawcze organizacji: cztery stany, od chaosu sterowanego i dryfu po high-trust delivery, i pytanie, czego brakuje Twojej firmie.
Dlaczego oprogramowanie nigdy nie jest skończone: system IT jako zasób, który musi ewoluować razem z potrzebami użytkowników i strategią firmy.
Zasada prostoty z Manifestu Agile, czyli sztuka niewykonywania pracy. Jak Lean i eliminacja marnotrawstwa (muda) przyspieszają zwinne zespoły.
Czym jest wartość w IT? Dlaczego „value” bywa pustym hasłem i jak nazywać ją konkretnie: przychód, retencja, koszty, mniej błędów, lepsze doświadczenie.
Myślenie zerojedynkowe w decyzjach technologicznych: dlaczego wybór między dwiema skrajnościami pomija rozwiązania pośrednie i wydłuża decyzje.
Shadow IT a bezpieczeństwo: jak kolejne ograniczenia odbierają poczucie efektywności i pchają ludzi do niezatwierdzonych narzędzi, zwiększając ryzyko.
Effort to nie timeline: dlaczego estymacja w godzinach myli pracochłonność z terminem i co naprawdę kryje się za pytaniem „jak to jest duże?”.