Framework zaobserwowany, nie wymyślony
Scrum to ramy procesu, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów od początku lat dziewięćdziesiątych.
Scrum nie powstał w laboratorium, ale został zaobserwowany.
Kiedy Ken Schwaber i Jeff Sutherland obserwowali w latach osiemdziesiątych i dziewięćdziesiątych organizacje tworzące produkty software’owe, sposoby działania tych najlepszych, wykazywały pewne podobieństwa. W tym samym czasie, dwóch naukowców z Uniwersytetu Tokijskiego, Hirotaka Takeuchi (pracujący równocześnie dla Toyoty) i Ikujiro Nonaka, opisało niezwykle podobne korelacje w tekście: The New New Product Development Game. Ken i Jeff, zainspirowani artykułem Japończyków, zaprezentowali Scruma po raz pierwszy na konferencji OOPSLA w 1995 roku.
Zarządzaj Produktem, nie procesem.
Sam w sobie Scrum nie jest procesem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik.
Chciałam jednak napisać o czymś ważniejszym. Scrum nie jest procesem wytwórczym. Scrum to rama procesu do zarządzania Produktem. NIE projektem. To kluczowa kwestia. Scrum musi też być uzupełniony o praktyki i narzędzia oraz zaadaptowany do konkretnych warunków, aby mógł działać. Sam nie jest kompletny – jest za lekki.
Scrum prawdę ci powie, zwłaszcza trudną.
Scrum pomaga odkrywać nieefektywności praktyk zarządczych i technik inżynierskich by można je doskonalić.
Scrum służy wykrywaniu nieefektywności. Scrum pokazuje problemy. I to jest ten nasz problem z bajorkiem. Tak jak w poprzednim odcinku wspomniałam, wina jest przypisywana wypompowanej wodzie, a nie lodówce czy krokodylom.
