Dzisiejszy tekst został napisany w stu procentach na klawiaturze. Ale wśród naszych ostatnich tekstów znajdziecie i takie, które powstały przy pomocy konwersji tekstu na mowę. Jeden z nas korzysta z tego sposobu od dawna, a drugi wypróbował go dopiero ostatnio. Czy się przekonał? A może okazało się, że lepsze jest wrogiem dobrego?

Dzisiaj tekst o dwóch rzeczach związanych z planami i harmonogramami. Z jednej strony chcemy opowiedzieć o tym, jak budować plany, a z drugiej przestrzec przed ich zbytnią ich szczegółowością.

Są takie miejsca, gdzie wszyscy się do siebie uśmiechają, współpracują i sprawiają wrażenie świetnie zgranych. Czar pryska w momencie, w którym ktoś wyciąga nagrania ze spotkania bądź odwołuje się do spisanych ustaleń z przed miesięcy bądź lat. Zwinnie? Nieszczególnie.

Dzisiejszy tytuł jest co najmniej dwuznaczny. Czy chodzi o przejście na agile w dwa miesiące czy bardziej o to, jak stosować podejście zwinne dla inicjatyw i projektów trwających tak krótko? Dla odmiany nie będę Was trzymał w niepewności – chodzi o to drugie.

Nie zawsze wygrywa empiryzm czy transparentność. Czasami naginamy rzeczywistość do granic możliwości i udajemy, że jest inaczej, niż to faktycznie jest. Skąd się bierze agile’owa fikcja i dlaczego tak niektórych do niej ciągnie?

Temat jakości w metodykach zwinnych jest od zawsze kontrowersyjny. Z jednej strony mamy ludzi mówiących o tym, że MVP to tak naprawdę PoC, czyli Proof of Concept. Z drugiej strony mamy osoby twierdzące, że każda wersja oprogramowania powinna być „potencjalnie wdrażalna”. Zaś z trzeciej – tych, którzy narzekają na niską jakość rozwiązań powstających w agile’owy Czytaj dalej…

W tym roku plany wakacyjne eksplodowały zasadniczo każdemu, kto nie miał zamiaru spędzić cieplejszych miesięcy w domu. Ale to przecież sytuacja wyjątkowa, prawda? Bo zwykle, jeżeli chodzi o nasze plany wszystko idzie zgodnie z nimi, nieprawdaż?

Podstawy, filary, fundamenty, baza – każda koncepcja potrzebuje być zbudowana na stabilnych zasadach. I taka też jest szeroko rozumiana zwinność. Ale nie możemy zapominać o pierwotnym źródle agile, jakim jest po prostu zdrowy rozsądek.

Potrzeba biznesowa, czyli „business need” jest tym, co powinniśmy spełniać w ramach naszych agile’owych procesów. Niestety, w większości przypadków po prostu realizujemy zlecone prace, bez jakiejkolwiek optymalizacji wytwarzanej wartości. Agile to dla nas tylko sposób na realizację waterfallowego projektu.

Bardzo nie lubię rozwiązywania problemów poprzez wprowadzanie procesów, narzędzi i mechanizmów kontroli. Być może powinienem być bardziej otwarty. Jest przecież szansa, że czasami takie rozwiązania są niezbędne. Ale wydaje mi się, że jest ich o wiele mniej niż się wydaje większości zwolennikom kontroli.