Mnie się tak właśnie zdaje, że dzielenie na tradycyjne role (programista / tester / analityk) chyba nie jest częścią SCRUMa (każdy dobiera zadania jakie może wykonać - jeśli tradycyjny tester na początku nie ma nic do roboty, to bierze zadania analityczne, pod koniec projektu tradycyjny analityk pomaga w testach itd.). Stąd się też z kolei wzięli DevOpsi - podział horyzontalny i mieszanie kompetencji, łączenie ludzi w zespołu projektowe i rozbijanie tradycyjnych pionowych silosów kompetencyjnych (dział developerski, dział administratorów).

Z drugiej strony jak się pytam kumpli jakiej metodyki używają w swoich projektach to jeszcze nigdy nie usłyszałem SCRUMa, tylko między innymi (odpowiedzi autentyczne):

• prawie SCRUMa,
• SRAM-ish (w rozmowie po angielsku),
• SCRUM-like (jak wyżej),
• i najlepsze na koniec: zaczynamy SCRUMem i kończymy waterfallem (do dziś nie wiem czy to było na poważnie ;-D ).

Nie do końca rozumiem te odpowiedzi, przecież nie ma i nie może być metodyki, która będzie odpowiednia dla wszystkich projektów. Więc to co ludzie uznają za herezję, odejście od świętych zasad SCRUMa to właśnie jest ta zwinna elastyczność, która jest niezbędna aby ta czy inna metodyka działała. Trzeba je dostosowywać i implementować właśnie do swoich potrzeb. Zawsze oczywiście trzeba to robić z wyczuciem, żeby nie przesadzić nie utracić gdzieś zalet zwinności. I czasem trzeba zrozumieć, że są projekty i są klienci u których się tego nie da zastosować w ogóle i rzeczywiście trzeba to robić waterfallem.