Wyobraźmy sobie nowoczesną łódź podwodna, wyruszającą na misję bojową. Świetnie przygotowana załoga doskonale radzi sobie z obsługą okrętu. Wszystkie systemy są naszpikowane elektroniką, a całość spina wysokiej jakości oprogramowanie.
Okręt zbliża się w strefę walki. Pomimo sugestii doradcy, że warto by było ocenić, co znajduje się na horyzoncie, oficer dowodzący jest zdania, że łódź jest tak nowoczesna, iż nie ma sensu użyć peryskopu. Uważa, że wszystko co ważne, wskazuje nam aparatura pokładowa, a załoga nie raz już płynęła na misję, więc wiedzą doskonale, co mają robić.
10 minut później łódź zostaje trafiona torpedą wystrzeloną z wrogiego okrętu. Łączność z naszym statkiem zostaje utracona. Znajdująca się w pobliżu jednostka potwierdza jego zatonięcie. Misja kończy się niepowodzeniem.
Jak to się ma do Scruma?
Ta niepozorna historia ma wiele wspólnego z pracą nad rozwojem produktu. Poznałem ostatnio zespół, który pracuje w nowoczesnej technologii. Starają się wytwarzać kod wysokiej jakości. Mają dostęp do narzędzi oraz wiedzy, która pozwala im dobrze wykonywać swoją pracę. Rozmowy zespołu dotyczą zazwyczaj szczegółów technicznych, rysowane są diagramy, omawiane interfejsy oraz komponenty.
W tym wszystkim jakby zapominali, że istnieje świat nad powierzchnią wody. Że użytkownika nie interesuje jak coś jest zrobione, tylko co mu to daje. Że ma być użytecznie oraz intuicyjnie. Że w ogóle jest jakiś użytkownik, który nie jest systemem, komponentem czy klasą, tylko żywym organizmem, który ostatecznie będzie z tego korzystał.
Zapominają użyć peryskopu, aby wyjrzeć na powierzchnię i ocenić, jak ich praca ma się do sytuacji na polu bitwy. Tracą przez to informacje, które pomogły by im lepiej przeprowadzić misję. Ryzyko niepowodzenia wzrasta. Świat pod wodą wygląda inaczej, niż ten rzeczywisty.
A może zamiast używać peryskopu, lepiej wykonać pełne wynurzenie?