Zespół w Scrumie

Zespół, w zespół, zespół, w zespół... Przyszedł czas rozprawić się z zespołem po tematach Product Owner i Scrum Master. Ten temat można by przemaglować po wieloma różnymi kątami. Jednak nie w tym rzecz.
W czym?:

• zespół ma być nieduży - bo wtedy komunikacja jest prostsza i łatwiej się zorganizować;

• zespół to nie składak ("w projekcie X jestem na 30%, w projekcie Y na 50%..."), to nie działa, ludzie są niezaangażowani i sfrustrowani. Z dwojga złego już lepiej zorganizować jeden zespół, który robi dwa projekty;
• zespół się konstytuuje miesiącami - jeśli tzw. zespół jest konstruowany na 2-3 miesięczne projekty, a później rozwiązywany, to nie ma zespołu. Jest grupa ludzi. Mechanizmy zespołowe wtedy nie działają;
• rozproszone zespoły to duże wyzwanie i nieczęsto to dobrze wychodzi. Rozproszone zespoły międzynarodowe (a już w różnych strefach czasowych w szczególności) to nigdy dobrze nie wychodzi. NIGDY. Nie widziałem takiego zespołu, a sporo już widziałem. I nie jest to kwestia umiejętności zorganizowania takiego zespołu. Mieszanie różnych narodowości, pracujących zdalnie to nienajlepszy pomysł - bariera przestrzenna jest wielokrotnie wzmacniana barierą językową i kulturową;
• zespół musi mieć wyraźną przewagę ludzi doświadczonych i sprawnych nad osobami niedoświadczonymi. Chociaż nawet ze studentów można zrobić świetny zespół, tylko wymaga to ogromnie wiele wysiłku (na tyle dużo, że jest to nieopłacalne);
• czy zespół ma być samoorganizujący? trzeba wielu czynników, aby mieć dobry zaczyn, aby doprowadzić do takiej formy działania zespołu, a to się rzadko zdarza. Dlatego kluczową rzeczą jest to, że:

Osoby współtworzące zespół, powinny co najmniej współdecydować odnośnie tego co się dzieje podczas realizacji feature'ów (m. in. co się da zrobić, w jakim czasie, w jaki sposób i jak zorganizować sobie pracę).

 
Amen.