Dlaczego agile nie działa w Twojej firmie? 7 symptomów teatru, feature flags w .NET i CI w 15 minut

Ile godzin w tym tygodniu zjadły Ci spotkania o robocie zamiast samej roboty? Daily, planning, refinement, review, retro. A potem jeszcze status dla managera - bo tych wszystkich spotkań najwyraźniej wciąż za mało. Agile miał nas uwolnić od biurokracji, a w wielu firmach stał się po prostu jej nową wersją. Tyle że teraz biurokracja ma kolorowe karteczki i nazywa się "ceremonią".

Od razu zastrzegam: to nie jest tekst przeciwko agile. To tekst przeciwko jego podróbce - teatrowi agile, w którym zostały same rytuały, a zniknęło to, po co je wymyślono. I nie, to nie jest wina scrum masterów. Scrum master, który całe dnie klika w Jirze, zwykle jest ofiarą systemu, a nie jego autorem.

W tym artykule dostaniesz 7 symptomów, po których rozpoznasz teatr agile w swojej firmie - do każdego prosty test, który zrobisz w minutę. Potem zobaczysz, dlaczego firmy w to brną i czym jest prawdziwa zwinność. Będzie też kod, bo prawdziwa zwinność to nie karteczki, tylko inżynieria: feature flags w .NET i CI na GitHub Actions, które wdrożysz w jedno popołudnie. Na koniec 4 poziomy działania, czyli co Ty, jako programista, możesz z tym realnie zrobić. Bez rewolucji i bez rzucania wypowiedzeniem.

Wersje: przykłady kodu są przygotowane w .NET 10 (minimal API) z oficjalną paczką Microsoft.FeatureManagement.AspNetCore. Zadziałają też w .NET 8 i 9 - w pliku CI wystarczy wtedy zmienić wersję SDK.

Kult cargo, czyli daily z kokosów

Żeby zrozumieć, co się stało z agile, cofnijmy się do 1945 roku, na wyspy Pacyfiku. W czasie wojny lądowały tam amerykańskie samoloty pełne zaopatrzenia: jedzenie, ubrania, sprzęt. Dla mieszkańców wysp były to dobra, jakich nigdy wcześniej nie widzieli. Po wojnie samoloty przestały przylatywać.

Wyspiarze zrobili więc coś logicznego - ze swojej perspektywy. Zbudowali pasy startowe. Wieże kontrolne z drewna. Słuchawki z kokosów. Odtworzyli całą formę i czekali, aż samoloty wrócą z towarem. Nie wróciły. Bo forma to nie treść.

To zjawisko nazywa się kultem cargo. Programiści znają też jego branżową odmianę: cargo cult programming, czyli kopiowanie kodu i wzorców bez zrozumienia, po co w ogóle istnieją. Schemat jest zawsze ten sam:

1. Kopiujesz rytuały.
2. Oczekujesz rezultatów.
3. Rezultaty nie przychodzą.

Dokładnie to samo robi dziś wiele firm z agile. Kupują rytuały: daily, sprinty, story pointy, tablice. Ale nie kupują wartości, które za tymi rytuałami stały: zaufania do zespołu, krótkich pętli feedbacku i odwagi do zmiany planu. A rytuały to nie wartości.

Mówiąc wprost: wiele firm robi dziś daily z kokosów - i dziwi się, że samoloty nie przylatują. Jak poznać, że Twoja firma buduje pasy startowe z bambusa? Oto 7 symptomów.

Symptom #1: daily, które jest apelem

Daily miało być krótką synchronizacją zespołu: kto ma bloker, komu trzeba pomóc, co robimy dziś. 15 minut, w trakcie których ludzie rozmawiają ze sobą.

A jak to wygląda w praktyce? Każdy po kolei recytuje do managera: "wczoraj robiłem taska, dzisiaj dalej robię taska, blokerów brak". Nikt nikogo nie słucha, bo każdy w głowie układa swoją kwestię, a reszta czeka na swoją kolej i scrolluje telefon. 40 minut z życia, codziennie.

Test. Gdyby jutro manager nie przyszedł - czy to spotkanie w ogóle by się odbyło? Jeśli nie, to nie jest daily. To apel poranny.

Symptom #2: story pointy przeliczane na dni

Story pointy miały służyć do zgrubnego porównywania złożoności zadań, żeby zespół mógł planować. Nie były obietnicą terminu.

Ale potem ktoś z Excela zapytał: "to ile to jest w dniach?". I nagle 1 punkt = 1 dzień. Punkty stały się zobowiązaniem, velocity stała się KPI, a zespoły zaczęto porównywać między sobą.

Zespół szybko się uczy. Skoro velocity to ocena - zawyżamy wyceny. I nagle zmiana koloru przycisku ma 8 punktów. To prawo Goodharta w czystej postaci: kiedy miara staje się celem, przestaje być dobrą miarą. A w praktyce przestaje cokolwiek mierzyć.

Test. Czy velocity Twojego zespołu pojawiła się kiedykolwiek w rozmowie o ocenie rocznej albo w porównaniu z innym zespołem? Jeśli tak - wasze punkty już nic nie znaczą.

Symptom #3: Water-Scrum-Fall, czyli sprint jako mini-waterfall

Wygląda to tak: zakres ustalony rok wcześniej, deadline ustalony rok wcześniej, wymagania spadają z góry. Ale pracujemy "w sprintach", więc jesteśmy agile. W branży ma to nawet swoją nazwę: Water-Scrum-Fall (termin spopularyzował w 2011 roku Dave West, analityk firmy Forrester). Wodospad pocięty na dwutygodniowe kawałki to nadal wodospad.

Najlepsze jest to, że sztywny zakres sprintu obowiązuje tylko zespół. Bo kiedy management wrzuca w środku sprintu "pilny" ticket, zakres nagle robi się bardzo elastyczny.

Test. Czy na koniec sprintu możecie wdrożyć zmiany na produkcję? Nie pytam, czy wdrażacie. Pytam, czy technicznie i organizacyjnie w ogóle moglibyście. Jeśli release i tak jest raz na kwartał, sprinty są tylko sposobem cięcia kalendarza.

Symptom #4: retro, po którym nic się nie zmienia

Retrospektywa to serce całej metody - to tam zespół ma naprawiać swój proces. Ale jeśli od pół roku na tablicy lądują te same karteczki, action itemy nie mają właścicieli, a retro jest pierwszym spotkaniem do skasowania, "bo gonimy sprint"...

...to zespół uczy się jednej rzeczy: mówienie o problemach nie ma sensu. I przestaje mówić. Na retro robi się cicho, wszyscy piszą "było ok" - a firma ogłasza, że zespół jest zadowolony.

Retro bez zmian to nie retrospektywa. To grupowa terapia bez terapeuty. I bez efektów.

Test. Wymień 1 rzecz, która realnie zmieniła się po waszych ostatnich 3 retro. Cisza? To jest Twoja odpowiedź.

Symptom #5: Product Owner, który niczego nie ownuje

W teorii Product Owner to osoba, która podejmuje decyzje o produkcie. W praktyce często jest sekretarzem backlogu: przepisuje wymagania z góry do Jiry, a każdą zmianę priorytetu musi eskalować 3 szczeble wyżej i czekać tydzień na odpowiedź. Backlog spada z góry, a roadmapa jest zabetonowana na rok do przodu.

Manifest Agile mówi: "reagowanie na zmiany ponad podążanie za planem". Trudno jednak reagować na zmiany, kiedy plan jest przybity gwoździami do ściany na 12 miesięcy.

Test. Ile czasu zajmuje u was decyzja o zamianie priorytetów 2 zadań w backlogu? Jeśli odpowiedź liczy się w tygodniach, nie macie Product Ownera. Macie Product Listonosza.

Symptom #6: "jesteśmy agile, bo mamy Jirę"

Jira to narzędzie. Możesz w niej robić agile i możesz w niej robić najczystszy waterfall świata. Ona nie ma zdania.

Ale w teatrze agile to tablica staje się produktem. Burndown musi ładnie opadać, więc przed prezentacją jest "korygowany". Statusy tasków muszą się zgadzać, więc programiści spędzają pół godziny dziennie na klikaniu - czasem więcej czasu idzie na aktualizację zadań niż na sam kod. Proces obsługuje narzędzie, a nie odwrotnie. Pierwsza wartość manifestu - "ludzie i interakcje ponad procesy i narzędzia" - została odwrócona o 180 stopni.

Test. Czy ktokolwiek u was kiedykolwiek "poprawiał" wykres przed pokazaniem go wyżej? Jeśli tak, nie raportujecie rzeczywistości. Malujecie scenografię.

Symptom #7: nikt nie widział użytkownika

Na koniec mój ulubiony symptom: nikt w zespole nigdy nie rozmawiał z prawdziwym użytkownikiem.

Cały sens krótkich iteracji to szybki feedback od ludzi, którzy faktycznie używają produktu. Wypuszczasz mało, uczysz się szybko, korygujesz kurs.

A jaki feedback dostaje typowy zespół? Opinię dyrektora na demo. Demo robi się dla stakeholderów, nie dla użytkowników, a zespół często nawet nie wie, kto na co dzień korzysta z jego produktu. Czyli iterujemy... wokół gustu jednej osoby, która z produktu nie korzysta. To nie jest iterowanie. To kręcenie się w kółko - tylko szybciej niż kiedyś.

Test. Kiedy ostatnio ktokolwiek z Twojego zespołu widział prawdziwego użytkownika? Nagranie sesji, rozmowa, choćby ticket supportowy przeczytany w całości. Jeśli musisz się zastanowić - masz odpowiedź.

Ściąga: 7 symptomów i 7 testów

Zbierzmy wszystkie symptomy w jednym miejscu, razem z testami:

Policz na spokojnie, ile z tych 7 symptomów widzisz u siebie:

• 0-2: macie normalne problemy, da się żyć.
• 3-4: gracie w teatrze, ale scena jeszcze się nie zawaliła.
• 5 i więcej: zapamiętaj ten wynik - wrócimy do niego przy ostatnim poziomie działania, na końcu artykułu.

Dlaczego firmy grają w teatr agile?

Skoro to wszystko tak słabo działa, to skąd się bierze? Przecież nikt rano nie wstaje z planem "dzisiaj zmarnujemy czas 20 programistów". Powody są 3.

Powód 1: firmy kupują proces, nie kulturę. "Transformacja agile" w praktyce to szkolenie, licencje na narzędzia i zmiana nazw stanowisk. Project manager zostaje scrum masterem - często z tymi samymi obowiązkami i tym samym stylem zarządzania. Proces można kupić fakturą. Kultury nie.

Powód 2: prawdziwa zwinność wymaga oddania kontroli. To powód najważniejszy. Zwinność to zaufanie, że ludzie najbliżej problemu podejmą dobre decyzje. A dla wielu managerów to przerażająca perspektywa. Dlatego ceremonie, które miały służyć zespołowi, stają się narzędziami nadzoru nad zespołem. Daily do kontroli. Punkty do rozliczania. Burndown do pilnowania.

Powód 3: rytuały łatwo skopiować, wartości nie. Wokół rytuałów wyrósł cały przemysł: certyfikaty, konsultanci, frameworki skalowania. Martin Fowler, jedna z legend naszej branży, nazwał to wprost w wystąpieniu z 2018 roku: "agile industrial complex", czyli przemysł, który sprzedaje firmom agile w pudełku i narzuca go zespołom z góry. Ron Jeffries, współautor Manifestu Agile, poszedł jeszcze dalej. W tekście "Developers Should Abandon Agile" (2018) napisał, że programiści powinni może porzucić "Agile" przez wielkie A, bo to, co firmy praktykują pod tą nazwą, częściej im szkodzi, niż pomaga.

Manifest Agile: ani słowa o sprintach

I tu jest puenta, którą warto zapamiętać. Manifest Agile z 2001 roku to 4 wartości i 12 zasad. Przeczytasz go w 3 minuty. Oto te 4 wartości:

• ludzie i interakcje ponad procesy i narzędzia,
• działające oprogramowanie ponad obszerną dokumentację,
• współpraca z klientem ponad negocjację umów,
• reagowanie na zmiany ponad podążanie za planem.

I wiesz co? Nie ma tam ani jednego słowa o sprintach. Ani o story pointach. Ani o daily. Ani, o dziwo, o Jirze.

Wszystko, z czym dziś kojarzy się "agile", to dobudówki. Czasem sensowne, ale wciąż dobudówki. A fundament większość firm zostawiła na placu budowy.

Czym jest prawdziwa zwinność?

Czym w takim razie jest zwinność, jeśli nie ceremoniami? Moja robocza definicja: zwinność to odpowiedź na pytanie, jak tanio i jak szybko Twój zespół może zmienić kierunek. Nic więcej. Zmienił się rynek, klient, priorytet - ile kosztuje was skręt?

I tu dochodzimy do rzeczy, o której teatr agile zapomniał całkowicie: zwinność jest przede wszystkim techniczna. Mówi o tym nawet 9. zasada manifestu: ciągła dbałość o techniczną doskonałość i dobry design zwiększa zwinność. W praktyce zwinność składa się z 4 elementów:

• Krótkie pętle feedbacku, czyli CI/CD.

• Małe paczki zmian, czyli małe pull requesty.

• Bezpieczeństwo zmian, czyli testy, dzięki którym nie boisz się refaktoryzować.

• Deploy ≠ release, czyli oddzielenie wdrożenia kodu od udostępnienia funkcji użytkownikom - za pomocą feature flag.

Możesz mieć wszystkie ceremonie świata. Ale jeśli wdrożenie na produkcję to ręczny rytuał raz na kwartał, w sobotę o 3 nad ranem, ze wstrzymanym oddechem - nie jesteście zwinni. Jesteście co najwyżej punktualni. Czasami.

A teraz najlepsza wiadomość: te techniczne rzeczy w dużej mierze zależą od Ciebie, nie od zarządu. Poniżej 2 techniki, które dadzą Twojemu zespołowi więcej zwinności niż wszystkie ceremonie razem wzięte.

Deploy to nie release: feature flags w .NET krok po kroku

Scenariusz z życia: przepisujesz proces checkoutu w sklepie internetowym. Klasyczne podejście teatru wygląda tak: zmiana żyje na osobnym branchu przez 6 tygodni, potem wielki merge, wielki release i wielka modlitwa.

Podejście zwinne: mergujesz do maina od pierwszego dnia i wdrażasz na produkcję, ale nowa funkcja jest wyłączona flagą. Deploy i release to 2 osobne decyzje. Zobacz, ile to kodu. Spoiler: mniej niż jedno daily :)

Setup: 2 minuty. Tworzymy projekt minimal API i dodajemy 1 oficjalną paczkę od Microsoftu - FeatureManagement:

dotnet new web -n SklepDemo
cd SklepDemo
dotnet add package Microsoft.FeatureManagement.AspNetCore

Cały kod feature flagi. Program.cs wygląda tak:

using Microsoft.FeatureManagement;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFeatureManagement();
var app = builder.Build();

app.MapGet("/checkout", async (IFeatureManager features) =>
{
    if (await features.IsEnabledAsync("NowyCheckout"))
    {
        return Results.Ok("NOWY checkout: 1 krok, płatność od razu");
    }
    return Results.Ok("Stary checkout: 3 kroki");
});
app.Run();

Jedna linijka rejestracji w kontenerze DI (AddFeatureManagement). Potem w endpoincie wstrzykujemy IFeatureManager i pytamy: czy flaga NowyCheckout jest włączona? Jeśli tak - nowa ścieżka. Jeśli nie - stara, sprawdzona. Oba kody żyją obok siebie na produkcji. I to jest w porządku, bo to stan przejściowy, a nie dług - pod warunkiem, że po pełnym wdrożeniu usuniesz starą ścieżkę i samą flagę. To cały kod: 14 linijek.

Flaga w konfiguracji. Flaga siedzi w appsettings.json, w sekcji FeatureManagement:

{
  "FeatureManagement": {
    "NowyCheckout": false
  }
}

Startujemy z wartością false. To oznacza, że możesz zmergować i wdrożyć tę zmianę na produkcję dziś, a użytkownicy nie zobaczą żadnej różnicy.

Włączasz flagą, wyłączasz flagą. A teraz najlepsze. Uruchamiasz aplikację (dotnet run) i wchodzisz na /checkout - odpowiedź to "Stary checkout: 3 kroki". Zmieniasz false na true, zapisujesz plik, odświeżasz przeglądarkę... i widzisz "NOWY checkout: 1 krok, płatność od razu".

Bez restartu aplikacji. Bez redeployu. Bez brancha i wielkiego merge'a. Domyślna konfiguracja z appsettings.json przeładowuje się w locie, a FeatureManagement od razu widzi nową wartość. I tak samo możesz funkcję wyłączyć: w 10 sekund, kiedy coś pójdzie nie tak. Bez rollbacku o 2 w nocy.

Poziom wyżej: stopniowy rollout. Zamiast włączać nową funkcję wszystkim naraz, możesz użyć wbudowanego filtra procentowego:

{
  "FeatureManagement": {
    "NowyCheckout": {
      "EnabledFor": [
        {
          "Name": "Microsoft.Percentage",
          "Parameters": { "Value": 10 }
        }
      ]
    }
  }
}

Nowy checkout dostaje na start 10% ruchu. Patrzysz na metryki i błędy, po dniu podkręcasz do 50%, potem do 100%. To jest prawdziwe iterowanie z feedbackiem - od realnych użytkowników, a nie od dyrektora na demo.

Jedna praktyczna uwaga: filtr Microsoft.Percentage losuje przy każdym sprawdzeniu flagi, więc ten sam użytkownik może raz trafić na nowy, a raz na stary checkout. Jeśli zależy Ci, żeby dana osoba konsekwentnie widziała jedną wersję, sięgnij po filtr Microsoft.Targeting, który na stałe przypisuje użytkowników do grup (wymaga wskazania, kim jest bieżący użytkownik).

W realnym projekcie flagę trzymasz zwykle nie w pliku, tylko np. w Azure App Configuration. Wtedy przełączasz ją z panelu, dla całej farmy serwerów naraz. Zasada jest dokładnie ta sama.

CI w 15 minut: GitHub Actions

Druga rzecz, którą wdrożysz w kwadrans, to podstawowy CI na GitHub Actions. Tworzysz w repozytorium plik .github/workflows/ci.yml:

name: CI
on: [push, pull_request]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'
      - run: dotnet restore
      - run: dotnet build --no-restore
      - run: dotnet test --no-build

Kilkanaście linijek YAML-a i od teraz każdy push oraz każdy pull request automatycznie przechodzi build i testy. Komendy dotnet uruchamiają się w katalogu głównym repozytorium, więc powinien tam leżeć plik solucji albo projektu. Nikt już nie zmerguje czegoś, co się nie kompiluje, i nikt nie usłyszy "u mnie działa".

To jest krótka pętla feedbacku w praktyce: informacja zwrotna 3 minuty po pushu, a nie na demo za 2 tygodnie.

To jest zwinność. Reszta to wpisy w kalendarzu. Feature flagi plus CI - 2 techniki, 1 popołudnie pracy. A Twój zespół zyskuje więcej realnej zwinności, niż dało mu ostatnie pół roku ceremonii.

Co możesz zrobić od jutra: 4 poziomy działania

Znasz już symptomy, przyczyny i kod. Ale pewnie myślisz: "fajnie, tylko ja nie jestem prezesem, ja tu tylko koduję". Dlatego ta część jest najważniejsza. Oto 4 poziomy działania - od najłatwiejszego.

Poziom 1: Twój kod, Twoje zasady. Zacznij od rzeczy, na które nie potrzebujesz niczyjej zgody. Nie potrzebujesz uchwały zarządu, żeby robić małe pull requesty (orientacyjnie maksymalnie 200-400 linii zmian). Mały PR to szybszy review, mniej bugów i mniejszy stres przy merge'u. Nie potrzebujesz też pozwolenia, żeby dopisać test do kodu, który właśnie zmieniasz, ani żeby zautomatyzować powtarzalne czynności. Jakość to nie jest coś, o co się prosi. To coś, co się robi.

Poziom 2: 1 eksperyment na retro. Zaproponuj na retro jeden eksperyment. Nie rewolucję - eksperyment. To prosty psychologiczny trik, który naprawdę działa. Na hasło "zmieńmy nasz proces" ludzie się jeżą i bronią status quo. Na hasło "eksperyment na 2 tygodnie, potem oceniamy" wzruszają ramionami i mówią: no dobra, spróbujmy.

Dobry eksperyment jest konkretny, mierzalny i ograniczony w czasie. Nie "poprawmy komunikację", tylko np.:

"Przez 2 sprinty robimy daily bez rundki statusów - mówimy wyłącznie o blokerach i decyzjach, maksymalnie 10 minut. Po 2 sprintach oceniamy i decydujemy."

Po 2 sprintach macie dane, a nie opinie.

Poziom 3: mów językiem biznesu. Kiedy chcesz przekonać ludzi nad sobą, nie mów o narzędziach. Mów o ryzyku, czasie i pieniądzach. Zdanie "chcemy pipeline'u CI/CD, bo tak się powinno robić" nic dla biznesu nie znaczy. Za to takie zdanie już tak:

"Dziś zmiana idzie na produkcję 2 tygodnie i co trzecie wdrożenie coś psuje. Po zmianie pójdzie w 1 dzień, a wdrożenia przestaną być wydarzeniem."

Na takie zdanie dostaje się budżet. Tak się wygrywa z teatrem: nie walcząc z ceremoniami, tylko dowożąc wyniki, których ceremonie nigdy nie dowiozły.

Poziom 4: wiedz, kiedy odpuścić. Ten poziom dotyczy szczególnie tych, którzy w teście doliczyli się 5 lub więcej symptomów. Mało kto mówi o tym uczciwie, ale czasem trzeba odpuścić.

Nie chodzi o to, żeby rzucać papierami po jednym głupim daily. Chodzi o to, że jeśli od 2 lat proponujesz zmiany, przynosisz dane, robisz eksperymenty - i nic, konsekwentnie nic się nie zmienia - to organizacja właśnie komunikuje Ci, kim jest. To nie jest bug do naprawienia. To jej feature.

Masz ograniczoną energię zawodową. Możesz ją palić na walkę z betonem albo zainwestować tam, gdzie Twoja praca coś zmienia. Kultura jest ważniejsza niż proces, a rynek .NET jest duży. Wybór należy do Ciebie - ważne tylko, żeby był świadomy, a nie wynikał z przyzwyczajenia.

Podsumowanie

Agile w wielu firmach to teatr: rytuały skopiowane bez wartości, które miały im towarzyszyć. Zbierzmy najważniejsze wnioski:

• Teatr rozpoznasz po 7 symptomach: daily-apel, punkty przeliczane na dni, Water-Scrum-Fall, retro bez zmian, PO bez władzy, Jira jako cel i zero kontaktu z użytkownikiem.

• Przyczyną nie są ludzie, tylko system: firmy kupują proces zamiast kultury, boją się oddać kontrolę zespołom, a rytuały łatwo skopiować.

• Prawdziwa zwinność nie mieszka w Jirze, tylko w krótkich pętlach feedbacku, małych zmianach, testach i inżynierii.

• Deploy ≠ release: feature flags w .NET to 14 linijek kodu, a podstawowy CI na GitHub Actions to kwadrans pracy.

• Możesz zacząć od jutra, od własnego biurka: małe PR-y, testy, feature flagi i 1 eksperyment na retro. A jeśli po latach prób nic się nie zmienia - świadomie zdecyduj, gdzie inwestujesz swoją energię.

Jeśli takie konkrety Ci pasują, mam coś dla Ciebie. Prowadzę społeczność programistów .NET - jest nas już ponad 10 000. Raz w tygodniu wysyłam maila: najważniejsze newsy ze świata .NET bez lania wody, techniczne mięso jak w tym artykule i rabaty na moje kursy, dostępne tylko dla społeczności. Zero spamu.

Jeśli chcesz dołączyć, zostaw swój adres tutaj: modestprogrammer.pl/vip. Powodzenia - i niech Twoje samoloty wreszcie zaczną przylatywać.