Gotowe i cofnąć

Artykuł
04/10/2013

Autorzy: Ken Schwaber i David Starr, Scrum.org

Styczeń 2012

Dostarczanie gotowego przyrostu jest krytyczne dla odniesienia sukcesu w zwinnym tworzeniu oprogramowania.Używając przykładów rzeczywistych i teoretycznych, autorzy pokazują różnicę między postrzeganiem pojęcia "gotowe" i jego funkcjonowaniem w rzeczywistości, oraz jaki to ma wpływ na powodzenie projektu.Za pomocą tych przykładów, autorzy przechodzą do demonstrowania narzędzi i strategii, które może ułatwić zespołom zrozumienie definicji gotowości i metod komunikacji zależności, stanu i znaczenia pojęcia „gotowe”.

Dotyczy

Zarządzanie cyklem eksploatacji aplikacji; Team Foundation Server

W tym artykule:

Wprowadzenie
Przejrzystość utracona w firmie Anny
- Co ludzie myśleli, że się działo
- Co się faktycznie stało
- Lekcja
Dług techniczny w firmie Nanomedtronics AZ
- Co ludzie myśleli, że się działo
- Co się faktycznie stało
- Lekcja
Dług techniczny zwiększa się przy wielu zespołach.
Planowanie wydań w Datum Corporation
- Co ludzie myśleli, że się działo
- Co się faktycznie stało
- Lekcja
Techniki wielkoskalowe do generowania gotowych produktów
- Scrum of Scrums
- Ciągła integracja
Wnioski

Scrum jest iteracyjną, przyrostową metodyką zgodną z manifestem Agile.Zespoły używają go, aby szybko dostarczać zwiększoną ilość „wykonanych zadań” lub używanych funkcji oprogramowania w każdej iteracji lub Sprincie.

„Gotowe” jest prostym, ale często błędnie interpretowanym słowem.Dla mnie to oznacza gotowe, ukończone i zakończone.Gotowość oznacza, że nic nie pozostało do zrobienia.Produkt gotowy jest łatwo zdefiniować; jednak dostarczanie gotowego przyrostu pozostaje jednym z podstawowych i trudniejszych wymagań metody Scrum i zwinnego programowania.

Zwinne programowanie wymaga dostarczania ukończonych, gotowych do użytku przyrostów oprogramowania z każdego Sprintu.Większość zespołów Scrum i zwinnych generuje niekompletne, częściowo wykonane przyrosty.Gdy zespół Scrum jest pytany, dlaczego wymagania zaległości produktu nie były ukończone w sprincie, członkowie zespołu często odpowiadają "Nie mamy czasu".

Ten dokument rozwiązuje problemy związane z gotowymi przyrostami na przykładzie faktycznych studiów przypadków z początków metodyki Scrum.Wymienione nazwy i miejsca zostały zmienione , ale na pewno poszczególne osoby rozpoznają się i swoją ciężką pracę.W tym artykule wszystkie sprinty są miesięczną iteracją, chyba że zaznaczono inaczej.

Przejrzystość utracona w firmie Anny

Anna potrzebowała zautomatyzować otrzymywanie przez jej dział informacji o zmianach tytułów właściwości.Firma, dla której pracowała przy budowie i eksploatacji rurociągów gazowych dla prawie całej Ameryki Północnej.Jej dział przetwarza i wypłaca odszkodowania osobom będącym właścicielami gruntów, przez które przechodzi.Informacje tytułowe, które dotarły do działu Anny, to wydruki lub dokumenty na temat zmiany właściwości.Wolumin sprawiał trudności, więc Anna chciała zautomatyzować proces płatności oraz tantiem.

Nasz zespół programistyczny zaproponował stworzenie systemu tantiem dla Anny przy użyciu Scrum.Sprawiło to, że każdego miesiąca miałaby ona do sprawdzenia użytkowy fragment oprogramowania.Miała również prawo do zmiany zdania co miesiąc na temat tego, co nasz zespół będzie czego dalej.

Pod koniec trzeciego sprintu mieliśmy informacje z jednej z prowincji i zintegrowaliśmy je ze starszymi danymi.Możemy to zademonstrować za pomocą prostego rozwiązania SQL.Anna była zachwycona, ponieważ większość zaległości produktu jej personelu pochodziła z tej prowincji.

Chciała, abyśmy nauczyli jej pracowników SQL, aby mogli natychmiast rozpocząć korzystanie z oprogramowania, które zostało dostarczone przez zespół programistyczny.

Czy to znaczy, że chciała go używać?Z pewnością nie zinterpretowała ukończenia sprintu jako ukończenia oprogramowania!

Powiedzieliśmy to Annie możliwie ostrożnie.Była wściekła.„Co masz na myśli mówiąc, że to niegotowe?”Zobaczyłem pierwszy przyrost, drugi przyrost, a teraz chcę zacząć go używać.Wdróż go i naucz nas języka SQL, tak abyśmy mogli go używać.”

Zaczęliśmy odczuwać zaniepokojenie.Powiedzieliśmy Annie, że to zostało zrobione.Ale nie był to tego rodzaju gotowy produkt.Zostało to zrobione, aby pokazać jej, ale wystąpiły problemy, które nadal wymagały rozwiązania, zanim można było używać oprogramowania:

Nie można przetworzyć niektórych rekordów przychodzących.Zamiast je wyrzucać, potrzebowaliśmy instrumentu do ich przechowywania i zarządzania nimi.
Kilka pól w rekordach przychodzących wydawało się być użytych do celów innych niż udokumentowane.Co możemy z nimi zrobić?
Pola w istniejącej bazie danych zawierały wskaźniki lub informacje, która wyglądały jak informacje referencyjne.Było to w całej bazy danych.
Podczas uruchamiania kanałów przychodzących i kwerend bazy danych system kilka razy ulegał awarii.Wyglądało na to, że dane zostały uszkodzone podczas tych awarii.

Anna zapytała nas, jak długo potrwa, zanim jej typ gotowego produktu będzie użyteczny.Oszacowaliśmy, że są potrzebne dwa inne sprinty, aby przyrosty były użyteczne.Powiedziała, aby kontynuować i przygotować to do wykorzystania przez jej dział.Następnie „poprosiła” mnie o spotkanie następnego dnia rano.

Następnego dnia rano pojawili się tam: Anna, jej przełożony i dyrektor ds. rozwoju.Wyrazili swoje rozczarowanie faktem, że wcześniej zachwalana przeze mnie przezroczystość nie była widoczna.Uważali oni, że powinienem poradzić sobie z nierozwiązanymi kwestiami inaczej niż po prostu rejestrując je jako błędy.Zostały zakłócone, ponieważ postęp odzwierciedlony w raportach wygaszania dostarczonych wszystkim był nieprawidłowy.

Po spotkaniu polecenia dla nas były następujące:

Zbadaj i popraw te cztery błędy.
Zakończ i wdróż pierwsze trzy przyrosty, tak aby dział Anny mógł zacząć go używać.
Popraw nasze umiejętności inżynieryjne i przetestuj automatyzację, tak aby nasza definicja gotowego produktu była taka sama, jak definicja Anny (nadające się do natychmiastowego wykorzystania przez firmę).
Zmień sposób rejestrowane usterek, tak aby wymóg nie był uważany za zrealizowany, dopóki usterki nie zostaną naprawione.

Dowiedzieliśmy się, że byłoby to dobra okazja do nauki, gdyby wszyscy odrobili swoje lekcje.

Co ludzie myśleli, że się działo

Opracowany przez nas plan bazowy systemu reprezentuje zdarzenia uznane przez udziałowców i Annę za możliwe.Zespół projektowy raportował postęp, który wyglądał na zgodny z planem, a zainteresowane osoby ufały jego wynikom.

Zespół projektowy faktycznie uważa, że zrobił wszystko prawidłowo, wskazując, że praca była wykonywana zgodnie z ustalonym planem.

Co się faktycznie stało

Prędkość jest miarą i historycznym zapisem wydajności zespołu projektowego dla sprintu.Prędkość jest mierzona dla każdego sprintu i używana do ustanawiania wzorców wydajności.

Nasz zespół programistyczny potrzebował stałego tempa ośmiu ukończonych jednostek pracy w każdym sprincie, aby sprostać planowi.Gdy istnieje zagrożenie spowolnienia naszej prędkości poniżej 8, nie zakończyliśmy wszystkich prac na tych elementach.

Dostarczona przez nas funkcja działała całkiem dobrze, ale nie była wystarczająco kompletna, aby mogła być użyta lub skompilowana.Zamierzamy to poprawić później.Gdy powrócimy do oszacowania niezrealizowanej pracy, dodawanych jest 14 jednostek pracy.

Biorąc pod uwagę, jakie trudności sprawiały początkowe tytuły własności, przerobiliśmy cały plan w celu odzwierciedlenia prawdopodobieństwa dwudziestomesięcznego harmonogramu.Dział Anny wydawał przyrosty co ok. dwa miesiące, udostępniając w ten sposób nowe dane.Nowe zautomatyzowane źródła obniżyły ogólną ilość pracy ręcznej tak bardzo, że sytuacja wydaje się dziwna, gdy system działa dwadzieścia dwa miesiące od uruchomienia.

Lekcja

Prawdziwa przejrzystość wymaga, aby każdy wyświetlających przyrost widział i rozumiał go tak samo.Przezroczysta kontrola przyrostu powinna umożliwić Annie zarządzanie ryzykiem i uzyskanie przewidywalności.Jednak ponieważ przyrost nie był przezroczysty, ona nie może skutecznie planować.

Na początku projektu Anna ustanowiła cel dla wersji.Po sprincie 1 oceniła postęp w osiąganiu celu przez sprawdzenie tego, co wydawało się jej użytecznym przyrostem.Podjęła decyzję, co należy zrobić w Sprincie 2 w oparciu o przyrostowy postęp w osiąganiu celu.Jeśli uważałaby, że nasze postępy były niewystarczające, mogła anulować projekt.

Na końcu sprintu 3 Anna uważała, że zostało zrobione 3/10 całości, co oczywiście było niepoprawne.

Niestety musi wystarczyć to co pokazuje każdy przyrost.Zaległa praca spowodowała bezużyteczność przyrostów w dziale Anny i niejasności dla inspekcji.

Nieprzezroczystość podczas kontroli przyrostu przypomina zakrywanie termostatu zimną, mokrą ścierką.Termostat niewłaściwie odczytuje rzeczywistą temperaturę pokojową i mógłby niepoprawnie zainicjować ogrzewanie, w przypadku gdy włączone powinno być chłodzenie.

Bez przezroczystych przyrostów zainteresowane strony nie mają właściwego zrozumienia tego, co faktycznie się dzieje i mogą podjąć niepoprawne działania, które nie mają sensu.

Krótko mówiąc bez pełnej przejrzystości zdolności zespołów do inspekcji i skutecznego dostosowania zostaną utracone.

Dług techniczny w firmie Nanomedtronics AZ

Dług techniczny to praca wcześniej odłożona, która musi zostać ukończona zanim oprogramowanie będzie mogło zostać uznane za gotowe.Dług techniczny przyjmuje wiele form, na przykład słabego projektu, powielania kodu lub nieprzetestowanych funkcji.Poniższy przykład ilustruje przyczynę i wpływ zadłużenia technicznego jako niewykonaną pracę w projekcie na czas.

Nanomedtronics AZ była małą nową firmą programistyczną.Mieli jeden zespół Scrum pracujący nad nowym wydaniem ich krytycznego produktu; oprogramowanie używane przez nano roboty do udrażniania zatkanych tętnic szyjnych pacjentów cierpiących na nadciśnienie krwi.

Co ludzie myśleli, że się działo

Po uruchomieniu zespołu wyznaczono zadanie przekształcenia wybranych elementów zaległości produktu w gotowe (nigdy więcej pracy niezrealizowanej, przydatnej, potencjalnie możliwej do dostarczenia) w sprincie jednego miesiąca.Zespół miał wszystkie umiejętności, aby w pełni przełożyć wymagania na gotowy produkt przyrostowy.

Gdy zespół scrumowy rozpoczął pierwszy Sprint, zobaczył, że było 80 jednostek pracy, które muszą być wykonane w ciągu 10 miesięcy.W związku z tym zespół programistyczny sumiennie wybrał 8 jednostek pracy w każdym sprincie.Uzasadnieniem było to, że jeśli ledwo osiągano by poziom 8 jednostek na Sprint, zostałyby one ukończone w ciągu 10 miesięcy ustanowionych przez firmę.

Zespół projektowy przedstawiał działającą kompilację przyrostową na koniec każdego sprintu.Wszystkie zewnętrzne objawy wskazywały, że metoda Scrum działa i firma Nanomedtronics AZ był na drodze do dostarczenia produktu zgodnie z planem.

Co się faktycznie stało

Co nie było jasne (poza zespołem programistycznym), należy stwierdzić, że każdy dostarczony przyrost faktycznie zawierał kiepskie implementacje, niekrytyczne błędy, powtarzającą się logikę i ogólnie niechlujny kod.Ponadto przyrosty nie zostały w pełni przetestowane, ponieważ zespół programistyczny przestał testować przy pojawieniu się deficytu czasu w sprincie.Zespół projektowy przestrzegał harmonogramu, a w celu jego utrzymania często był obniżany poziom jakości.

Zespół ciężko pracował i zbudował produkt w ciągu 10 miesięcy.Klient był zachwycony i przygotował się do wdrożenia i używania oprogramowania.Jednakże zespół programistyczny skumulował 48 jednostek niewykonanej pracy, pokazanej na rysunku jako nowe zadłużenie techniczne.

Zakończone i niewykonanej pracy

Zespół Nanomedtronics AZ nie rozważył wszystkich działań i pracy wymaganej do ich wykonania.Oto kwestie, które nie zostały uwzględnione przez zespół, a nie są wyczerpujące.Istnieje wiele więcej rzeczy, które mogłyby zostać uwzględnione.

Analiza
Projekt
Analiza zależności
Testowanie wydajności
Testy stabliności
Refaktoryzacja
Badanie reakcji immunologicznej
Integracja z pracami innych zespołów pracujących nad produktem
Testowanie integracja z pracami innych zespołów, więc przyrost jest sumą wkładów wszystkich zespołów
Informacje o wydaniu
Internacjonalizacja dla sześciu kultur, gdzie produkt będzie sprzedawany
Testowanie akceptacji użytkownika
Testowanie regresji
Przeglądy kodu

Pracę opisaną powyżej należy wykonać, aby utworzyć pełną, zintegrowaną wersję przyrostową przed zakończeniem sprintu.Jednak większość zespołów programistycznych nie kończy wszystkich wyżej wymienionych prac.Zostawiają nieco "niewykonanej" pracy w każdym Sprincie.Tworzy to przyrosty cechujące się słabym projektem, zduplikowany kodem, zbyt skomplikowaną logiką, nieprzetestowanymi funkcjami lub możliwościami lub innymi rodzajami wad.W ten właśnie sposób zespoły tworzą dług techniczny w oprogramowaniu.

Firma Nanomedtronics AZ dowiedziała się, że jej produkt zawiera wszystkie funkcje niezbędne do dostarczenia go klientom, ale również zawiera wiele usterek i brakuje mu opakowania i wykończenia niezbędnego do faktycznego ulokowania produktu na rynku.Zespół projektowy przypadkowo utworzył w dzienniku zaległości dodatkową pracę, której wykonanie zajęłoby kolejnych 6 miesięcy, przy założeniu, że prędkość zespołu wynosi 8 jednostek na sprint.

Oczekiwanie przez 6 miesięcy na wysyłkę produktu było nie do zaakceptowania przez kierownictwo firmy i produkt dostarczono z niewykonaną pracą po zaledwie 3 miesiącach.Utracony potencjał to nie tylko 3 miesiące opóźnienia w wysyłce produktu, ale w obniżona możliwość dodawania nowych funkcji, ponieważ zespół projektowym musi obecnie z poradzić sobie z brakami technicznymi w przyszłych sprintach.

Lekcja

Dług techniczny utrudnia prawdziwy postęp i zakłóca przejrzystość wymaganą dla podejmowania empirycznych decyzji przez Właściciela produktu i udziałowców.Dług techniczny zostanie spłacony poprzez czas spędzony na technicznych poprawkach lub straty spowodowane opóźnieniem wysyłki lub słabą jakością.

W większości sytuacji co najmniej 50% niezrealizowanej pracy pozostaje w produktach przy ich wydaniu.W związku z tym cofnięta praca staje się zinstytucjonalizowana jako bieżący dług.Dług techniczny powoduje niestabilność oprogramowania i może wywołać negatywne decyzje biznesowe, takie jak inwestowanie w pisanie oprogramowania od nowa lub całkowite porzucenie produktu.

Dług techniczny zwiększa się przy wielu zespołach.

Zespół programistyczny musi starannie wybrać tylko tyle pracy, ile może zrobić w sprincie.Zespół projektowy szacuje ilość pracy na podstawie własnego doświadczenia.Mimo wszystko zespół musi stosować nowoczesne praktyki inżynieryjne, takie jak zautomatyzowa kompilacja i testowanie regresji, aby wiele osiągnąć.Jeśli nie są zastosowane, ręczna praca zwykle przeciąża zespół przy czwartym lub piątym sprincie.

Rozważyć zespół programistyczny trzech programistów i dwóch specjalistów kontroli jakości.Codziennie programiści ewidencjonują kod do systemu kodu źródłowego.Jest testowany i błędy są wykrywane oraz przekazywane odpowiedniemu programiście.Czas, który upływa między sprawdzaniem kodu i wad wykrywanych i zgłaszanych.W tym czasie inni programiści mogli zaewidencjonować kod na istniejący nieprawidłowy kod.Nakład pracy wymagany do rozwiązania początkowego problemu jest obecnie większy.Jeśli zespół programistyczny dysponuje placówką do ciągłego kompilowania testowania, błąd zostałby wykryty natychmiast.Ktoś mógł to zanalizować, naprawić, a następnie przejść dalej.Dodatkowej pracy i strat można było uniknąć.

Wiele organizacji używa więcej niż jednego zespołu scrumowego do tworzenie oprogramowania.W takim przypadku problem zadłużenia technicznego opisany w powyższej sekcji staje się znacznie większy.Możliwości sprawdzania kodu pod kątem błędów są znacznie większe.Koszt korygowania rosnącej niestabilności oprogramowania rośnie wykładniczo w miarę postępu pracy.

Planowanie wydań w Datum Corporation

Niedawno pracowałem z inną firmą, powiedzmy Firmą A, zajmującą się tworzeniem oprogramowania infrastrukturalnego.Główne linia produktów zatrudnia ponad 800 deweloperów, w tym 250 programistów.Infrastruktura do rozwoju była częściowo automatyczna i częściowo ręczna.Testy często opóźniają kodowanie o kilka dni.Czas między sprawdzaniem programistycznym w wadliwym kodzie i jego wykryciem oraz zgłoszeniem wynosił dziesięć lub więcej dni.

Aby zminimalizować złożoność związaną z tak dużą liczbą programistów, każdy zespół pracował nad własnym rozgałęzianiem kodu.Menedżerowie ds. rozwoju pomagali w organizacji wymagań zaległości produktu, aby zminimalizować zależności.Jeśli każdy zespół programistyczny scala swój kod z wierszem głównego kodu codziennie, ilość potencjalnych przeróbek byłaby zminimalizowana.

Jednakże kierownictwo uznało, że to zajmie za dużo czasu.Kierownictwo postanowiło scalać wszystkie rozgałęzienia kodu w kod główny co trzeci sprint.Testy integracji wykryłyby wszystkie usterki, które następnie zostały usunięte.Wersja release candidate będzie gotowa do końca każdego trzeciego miesiąca.

Co ludzie myśleli, że się działo

Na poniższej ilustracji pokazano harmonogram i cykl planowanych wydań:

Harmonogram planowanym uwolnieniu i cyklu

Oryginalny plan zakłada, że:

9 sprintów
3 wersje release candidate, a następnie pełna wersja
Dział projektowy zatrudniający 800 osób

Co się faktycznie stało

Jeśli data wydania tej organizacji wypadła po dziewięciu miesięcznych sprintach, produkt nie był gotowy do wydania.Szósty release candidate miał ponad 5 000 usterek, a ponad 2000 wymagań dotyczących zaległości produktu nie było spełnionych.Zastanowiło nas, jak to możliwe.Firma Microsoft otrzymywała wersję Release Candidate co trzeci miesiąc.Po zbadaniu okazało się, że prezentacja pochodziła z rozgałęziania kodu każdego zespołu programistycznego.Integracja nie nastąpiła.Testowanie integracji nie nastąpiło.

Aby utrzymać prędkość wymaganą dla daty wydania, zespoły deweloperów odłożyły wszelkie prace integracyjne, co spowodowało powstanie dużych zaległości technicznych.Wynikiem był ośmiomiesięczny poślizg w stosunku do zaplanowanej daty wydania.Wyrazy „wersja release candidate” nie miały znaczenia.

Na poniższym rysunku pokazano rzeczywisty czas projektu oraz czas potrzebny do stabilizacji.

Rzeczywiste projektu plus czas potrzebny do stabilizacji

Wersje release candiste miały częściowo działające funkcje z gałęzi kodu dla każdego zespołu.Pięć miesięcy „stabilizacji” było wymaganych przed opublikowaniem.Jedna szczególna wada, która opóźniała dostawę bardziej niż inne czynniki to „niska wydajność”. Ten problem został zarejestrowany w pierwszym sprincie.

Lekcja

Różne zespoły pracujące nad tym samym oprogramowaniem ostatecznie scalają swoje prace.Integracja oprogramowania, aby zapewnić, że działa, zmniejsza ryzyko integracji i powinna następować często.

Oczekiwanie na scalanie pracy wielu zespołów jest kuszące, ponieważ umożliwia opóźnienie kosztu scalania.Jednak ten ostateczny koszt opóźnienia jest wytłumaczalny przez dużą liczbę uczestniczące zespołów i dużą liczbę oddziałów, które muszą być zintegrowane.

Techniki wielkoskalowe do generowania gotowych produktów

Osiągnięcie przez wiele zespołów stanu "gotowego" jest trudne.Zaangażowanych jest wiele zespołów.Istnieją zależności między zespołami i gałęziami kodu.Chociaż ta złożoność skali powoduje koszt, jest osiągalna i oferuje ogromne korzyści podczas wspólnej pracy zsynchronizowanych z sobą zespołów.

Istnieje kilka technik, które są przydatne podczas jednoczesnej współpracy wielu zespołów.

Scrum of Scrums

Gdy wiele zespołów Scrum pracuje nad tym samym projektem, potrzebują techniki koordynowania ich pracy.Zalecam „scrum scrumów”. Jest to codzienne zdarzenie, odbywające się niezwłocznie po scrumie dziennym każdego zespołu.Bierze w tym udział ktoś z uprawnieniami technicznymi z każdego zespołu.Każdy przedstawiciel zespołu opisuje, nad czym jego zespół właśnie pracuje.On lub ona pisuje następnie, nad czym planują pracować w ciągu nadchodzącego dnia.Na podstawie tych informacji przedstawiciele próbują zidentyfikować wszelkie potrzebne przeróbki, wszystkie nadchodzące zależności i wszelkie prace mogące wymagać zmiany harmonogramu.

Scrum wielu Scrumów okazał się być użyteczny w wielu organizacjach.Jednak jest to niewystarczające.Zależności i przeróbki mogą być pomyślnie lub niepomyślnie identyfikowane, ponieważ problemy są przewidywane, a nie znane.Nieoczekiwane zależności powodowały tworzenie nowej wersji i niepowodzenie testów.Niektóre zespoły poświęcają więcej niż 50% każdego sprintu na opracowywanie i ponowne opracowywanie zależności.

Ciągła integracja

Programowanie ekstremalne (XP) wymaga ciągłej integracji i testowania integracji prac zespołu.Dlaczego nie rozszerzyć tego na wszystkie zespoły?Bez względu na to, czy istnieją dwa zespoły, czy jest ich pięćdziesiąt, są one potrzebne do utworzenia zintegrowanego, przetestowanego pod względem integracji przyrostu na końcu każdego sprintu.Aby to zrobić, zespoły muszą często integrować swoją pracę.W związku z tym, że wszelka niezintegrowana praca może zawierać nierozwiązane zależności, ciągła integracja jest najlepszym rozwiązaniem.

Ciągła integracji całej pracy przypomina techniki produkcji odchudzonej.W wierszach produkcji odchudzonej wiele technik jest używanych do oceny jakości produktu podczas całego procesu produkcji.Gdy występują odchylenia lub problemy z jakością, linia produkcyjna jest zatrzymywana.Ciągła integracja i testowanie integracji oferują takie same techniki tworzenia oprogramowania.

Mimo że to trudne, zalecam, aby każdy zespół i członek zespołu przestał pisać kod, jeśli kompilacja ciągła lub test nie powiedzie się.Każda dalsza praca potencjalnie dokonuje się na błędach, powodując całą falę kolejnych usterek.Jeśli jest używana integracja ciągła, zespoły pracują ściśle ze sobą w celu uniknięcia błędów integracji.Poprawiają się nawyki w pracy, ograniczane są straty oraz rośnie jakość.

Większość organizacji przyjmujących metodykę Scrum nie zaczyna od wszystkich umiejętności i oprzyrządowania inżynieryjnego potrzebnych do zbudowania gotowego przyrostu.Rygorystyczny program osiągania gotowych przyrostów musi być uruchomiony i prowadzony.Grupy mniej niż 50 osób szybko osiągnąć stan, gdzie zajmują się już gotowym przyrostem w ramach sprintu.Organizacje zatrudniające ponad pięciuset programistów często potrzebują wielu lat, aby dojść do takiego poziomu.

Cofnięcie przyrostów tworzy straty i uniemożliwia zespołom osiągnięcie prawdziwej dynamiki.Rzeczywisty koszt zaległej pracy to o wiele więcej niż brak cechy lub funkcji w przyroście.Koszt obejmuje zużyty czas na ponowne planowanie i pracę niezbędne w przypadku, gdy kompilacja przyrostowa nie jest w rzeczywistości gotowa, a także koszty niższej przewidywalności i wyższego ryzyka.

Wiele organizacji chce korzyści wynikających ze zwinnego programowa i stosuje metodykę Scrum, aby je uzyskać.Dostarczanie gotowego przyrostu jest krytyczne dla odniesienia sukcesu w zwinnym tworzeniu oprogramowania.Zespoły powinny rozpocząć od takiego sposobu zdefiniowania wykonanego zadania, jaki będzie miał dla nich sens, a później rozwijać tę definicję wraz z upływem czasu.Dopiero wtedy osiągną prawdziwą dynamikę.