po polsku niżej

I suppose I was really lucky picking up agile methods. Somehwere around 2001 I was asked to replace a System Architect that couldn’t communicate well with a development team and the lucky part was that team was a) half-full of great programmers and b) already excercising full-blown Extreme Programming (XP).

It wasn’t the smoothest ride, we all had to learn a great deal but maybe because of that this project put me on the right track: Agile and Scrum are all about people, evertyhing else is just tools. Over the years I have joined or led many more teams and always, always there was something to be gained from introducing at least bits and pieces of agile methodologies and Scrum in particular.

Since then, the biggest challenge has been to get the guys at Orange Labs on board. The team was great but not convinced by Scrum ideas and the best developer actually actively disliked it based on previous experiences. By now they are not only running all the projects in an agile way but actively evangelizing the approach—great for them, good for Orange Labs :)

In the grand scheme of things, the biggest challenge right now is, in my opinion, the Product Owner role. Of course there are still many development teams that would benefit from introduction of Scrum but the methodology is by now widely recognized, one can easily find coaches and trainings. The next step—the missing one—is the education of their potential customers and I believe it is going to be a difficult one. Introducing Scrum to a development team is harder than it looks but it can be seeded slowly, managed step-by-step, well strcutured, and fertilized with introduction of an experienced Scrum Master but breeding a good Product Owner is something we have much less understanding of.

First of all, you need to find a person that cares about the product. Sounds trivial but go and talk to an employee of a mid-size or a big company who is responsible for communication with the subcontractor. He or she would have been most probably handed down this task from a manager and would have no decisive power over the development choices. And agile is all about adaptation, right?

Secondly a PO must be a good communicator with appreciation of the work done by the subcontractor—again not all that common since most of the clients think they now best what has to be done and often even have an opinion about how it should be executed.

Lastly, the job of PO takes a lot of time. I have yet to meet a client that would trust me on this subject. Especially at the beginning of the project it is likely going to be more that a full-time job.

In the end it all boils down to tweaking the culture of the organization and that is, unfortunately, the most difficult part to change. The bright side is that the culture is possible to change and those who try enjoy big benefits.

po polsku:

Moja przygoda z metodykami zwinnymi zaczęła się dość niespodziewanie wiosną lub jesienią 2001 roku. Manager z ,,sąsiedniego” departamentu spotkał się ze mną żeby wybadać czy nie chciałbym spróbować uratować projektu, który utknął u niego. Jako jeszcze stosunkowo mało opierzony architekt w Philips Research zgodziłem się niewiele się zastanawiając.

Z perspektywy czasu widzę, że tego dnia zaczęło się kilka rzeczy. Po pierwsze, seria akcji ratowania projektów, która z przerwami trwa do dziś. Po drugie silne podejrzenie, że w projekcie, w którym uczestniczy więcej niż 3 - 4 osoby sprawy techniczne są znacznie łatwiejsze do opanowania niż sprawy międzyludzkie. Wreszcie, po trzecie, że zwinne podejście do prowadzenia projektu coś w sobie ma. Szczególnie to ostatnie podejrzenie było dość niepokojące z punktu widzenia architekta systemów. Dotąd teoria, kursy i starsi koledzy sugerowali, że każdy problem można a nawet trzeba ,,ogarnąć” z góry, zaplanować rozwiązanie, zaprojektować w szczegółach, oszacować i dopiero wtedy zaczynać działać a tymczasem w praktyce zaczęło wychodzić, że to ani nie jest tak do końca skuteczne ani nawet możliwe.

Koniec końców projekt zakończył się umiarkowanym sukcesem ale stał się początkiem mojej przygody ze zwinnym podejściem do projektów, która z czasem została jednym z moich fundamentalnych zalet z punktu widzenia pracodawcy. W tamtym projekcie po raz pierwszy spotkałem Ruud-a (dziś szefa i coach-a w Industrial Logic), po raz pierwszy dostałem zespół pracujący w Extreme Programming i po raz pierwszy zespół, a przynajniej jego spora część, była dużo bardziej doświadczona ode mnie. Dziś wydaje mi się, że ta kombinacja bardzo wcześnie nauczyła mnie, że pierwszym, najważniejszym i najtrudniejszym zadaniem osoby prowadzącej projekt jest zadbanie o zespół a nie o technikalia, opinie szefów czy, nie daj Boże, tabelki w Excelu.

Stąd też pewnie wynika moje przekonanie, że na dzień dzisiejszy my, którzy rozumiemy na czym polega siła zwinności powinniśmy zacząć intensywnie edukować osoby pretendujące do roli Product Owner-a. Na rynku jest już sporo trenerów i kursów potrafiących pomóc zespołom programistycznym, spora z nich część potrafi autentycznie pomóc zespołom i rozumie, że np. Scrum to nie jest wyłącznie zbiór pewnych osób, procesów i artefaktów tylko sposób myślenia i pracy. Jednak osoby ze sfery biznesowej nadzorujące pracę programistów czy zlecenioborców nadal bardzo rzadko mają pojęcie o co chodzi w tych zwinnych metodykach, jak działać z takim zespołem i jak nie przeszkadzać im w zrobieniu jak najlepszej roboty. Dodatkowo w naszym kraju wzajemnie zaufanie wsród obywateli i biznesów jest na rekordowo niskim poziomie, więc nie wszystko da się rozwiązać przez kopiowanie wzorców z ,,Zachodu”.