- Working software over comprehensive documentation. W odróżnieniu od budownictwa, nie można zaprojektować makiety systemu wraz ze szczegółową dokumentacją techniczną. Nie ma też bezwzględnych zależności wynikających z praw fizyki i chemii. Warto zauważyć, że software jest formą dokumentacji. Linie kodu to przecież tekst. Należy wybrać taką formułę dokumentacji, aby była jak najmniej pracochłonna i maksymalnie użyteczna. Nie wolno jednak rezygnować z dokumentacji - np. schematy przepływu danych będą konieczne w każdym projekcie IT.

- Customer collaboration over contract negotiation. Typowy błąd w umowach na wykonawstwo systemów IT to koncentracja na nieznanym zakresie i negocjowaniu jako rzeczy z góry znanej. Regulacje dotyczące współpracy stron są często pomijane, a to one właśnie są najważniejsze. Musi być więc jasne, kto, z kim, przy czym i jak będzie współpracował. Współpraca jest po prostu fundamentem projektu, szczególnie współpraca pomiędzy użytkownikami a programistami, analitykami czy konsultantami.

Zobacz również:

• 9 cech wielkich liderów IT

- Responding to change over following a plan. Formalna umowa, karta projektu (lub inny statutowy dokument projektu) musi ustanowić dobrą formalną podstawę do zarządzania zakresem, począwszy od dopuszczenia wprowadzania zmian w zakres prac. Bez zarządzania zmianą szybko okaże się, że próbujemy realizować coraz bardziej nierealistyczny plan.

Z Agile Manifesto można wyprowadzić kilka ważnych zasad, których przestrzeganie daje dużą szansę na osiągnięcie oczekiwanych korzyści przy akceptowalnych nakładach, terminach i ryzyku.

Cnota 1: Naucz się pływać w zakresie

Agile Manifesto w dwóch z czterech punktów kładzie nacisk na zarządzanie zakresem. Pływanie zakresu, czyli jego precyzowanie i zmienianie, jest zjawiskiem normalnym. Nie wolno z nim walczyć. Szkoda czasu. Pływanie zakresu trzeba okiełznać. Nie wolno nam wierzyć w dane na początku opisu zakresu. Należy to raczej traktować jako punkt startowy do dyskusji o zakresie. Dyskusja ta skończy się dopiero wtedy, kiedy skończy się użytkowanie systemu. Czyli długo po zakończeniu projektu. Dlatego tak ważne jest ustanowienie sprawnych zasad sterowania zakresem w trakcie projektu i sterowania rozwojem systemu w przyszłości, w trakcie jego eksploatacji.

Zrozumienie zjawiska pływania zakresu jest równoznaczne z przygotowaniem przez project managera odpowiedniej organizacji pracy. Musi być jasne, kto, z kim i o czym będzie rozmawiał, kto będzie zatwierdzał, testował, oceniał zmiany etc. Pomyśl więc o roli głównego analityka odpowiadającego za logiczną spójność budowanego systemu.