Każdy, kto miał do czynienia z klasycznymi projektami, doświadczył niewątpliwie tej ich fazy, w której założenia okazały się błędne, plan nierealny, a terminy niemożliwe do dotrzymania bez dramatycznego obniżenia jakości wytwarzanych rozwiązań. Rozpoczyna się wtedy gorączkowe poszukiwanie najlepszego wyjścia z sytuacji. Przy gaszeniu pożaru nie ma czasu na planowanie i analizy (zresztą, nikt się na zmianę planów nie zgodzi, czyż nie?); trzeba robić wszystko, byleby jakoś dociągnąć projekt do końca. Czasami się udaje: dokonywane ad hoc zmiany i podejmowane z marszu decyzje, zwykle sprzeczne z początkowym planem, pozwalają opanować kryzys. Coś wam to przypomina?
Jeśli zwinność oznacza umiejętność szybkiego dostosowania się i podejmowania decyzji, to w sytuacji, jak powyżej, każda duża organizacja produkująca złożone produkty (np. oprogramowanie) w podejściu kaskadowym jest w jakimś stopniu zwinna. Brzmi to niczym herezja i majaczenie, ale niezaprzeczalnie jest to jakiś przejaw zwinności. Oczywiście nie służy ona ani organizacji, ani produktom tejże, a jedynie wybrnięciu z kryzysu.
Metody Agile mają tendencję do ukaskadowiania się, jeśli zapomina się w nich o empiryzmie. Metody predyktywne, takie jak Waterfall, czasami nieco się dla odmiany uzwinniają. Należy wszakże pamiętać, że w żadnym momencie to uzwinnienie nie prowadzi do empiryzmu, co więcej cel owych zwinnych działań jest kontrproduktywny: chodzi o uratowanie planu, najczęściej kosztem produktu. Poza tym, o ile w prawdziwym Agile niezbędna jest przejrzystość działań, o tyle chwilowe uzwinnienie Waterfalla wymaga czegoś dokładnie odwrotnego – udawania, że plan jest realizowany w pierwotnej formie.
Promyk nadziei
Celem tego krótkiego artykułu nie jest wyszukiwanie różnic lub podobieństw między podejściem empirycznym i predyktywnym. Zamiast tego chciałbym uświadomić wszystkim przekonanym, że Agile u nich nie byłby w stanie zadziałać, że się mylą. Jest to kwestia braku wiary, inercji samej organizacji, braku wiedzy a często też przyzwolenia na bycie zwinnym legalnie. W praktyce większość osób pracujących przy tworzeniu np. oprogramowania ma naturalną tendencję do poszukiwania skuteczniejszych sposobów działania i lepszych rozwiązań w produktach. Szkoda, że zielone światło ku temu zapala się tylko w sytuacjach kryzysowych.