Posts tagged agile

ACE, dzień drugi (jeszcze lepszy)

Czas opowiedzieć Wam o drugim dniu Agile Central Europe. Według mnie był on jeszcze lepszy od pierwszego (nie sądziłem, że to możliwe). Sądząc po twittach, sporo osób podziela tę opinię. Ale do rzeczy…

Zuzana Sochova – Company Culture as the Key Agile Milestone

Ta sesja była jedyną, która mnie nie zachwyciła. Nie byłem w stanie odnaleźć jakiejś kluczowej idei w całej prezentacji. Największą wartość dla mnie miał wstęp do prezentacji, kiedy Zuzana opowiadała o swojej pracy. Wiąże się ona z wytwarzaniem (zgodnie z metodyką Scrum) oprogramowania typumission-critical, np. dla aparatury medycznej. To żywy dowód że można i że lekkie metodyki nie są dla lekkoduchów:-)

Pawel Lipinski – Being an agile nearshore team

Na tą sesję czekałem z niecierpliwością odkąd poprzedniego dnia przysłuchiwałem się dyskusji moderowanej przez Pawła Lipińskiego i Pawła Brodzińskiego o tym, czym jest agile. Nie zawiodłem się. Paweł bardzo konkretnie opowiadał o budowaniu wysokowykwalifikowanego zespołu, który jest w stanie realizować najtrudniejsze praktyki agilowe – TDD oraz Pair Programming. Ta prezentacja to właściwie takie how-to, wyjaśniające wszystko krok po kroku. Nie mogę się wprost doczekać, kiedy będę sam mógłe je wykorzystać. Trzymajcie za mnie kciuki! BTW, Paweł ocenia ACE bardzo wysoko.

Pawel Brodzinski – The Kanban Story – Ups and Downs of Implementing Kanban

Paweł wprowadził nas w nastrój prezentacji starą prawdą: 90% complete means 100% incomplete. Zapobieganie sytuacjom 90% complete jest bardzo blisko związane z Kanbanem. Bardzo podobało mi się wzbogacenie prezentacji odniesieniami do popularnych filmów, np. Matrix. Z resztą możecie zobaczyć sami tutaj.

Warte zapamiętania było spostrzeżenie na temat samego procesu wytwarzania: garbage in — garbage out. Kanban nie jest cudowną metodą, która uzdrowi Twoją firmę. Jeśli na wejściu proces zostanie zasilony miernej jakości specyfikacjami (user stories, use cases itp), wyprodukowany zostanie kod nie mający wiele wspólnego z rozwiązywanym problemem.

Warto posłuchać całej prezentacji Pawła (jak tylko będzie dostępne video na stronie ACE), ponieważ oprócz bardzo dobrej merytorycznie treści, jest w niej ukrytych jeszcze kilka takich myślowych klejnotów. Dobry przykład: adjust tools for people, not people for tools. Polecam. Dla zainteresowanych, tutaj ACE w ocenie Pawła.

Robert Dempsey – Distributed Agile in a Multicultural World

Robert mówił o bardzo trudnych rzeczach: wyzwaniach związanych z budową wielonarodowego zespołu. To bardzo trudny temat, ponieważ prelegent musi się bardzo starać zainteresować widownie. Nie może liczyć na zbawienny efekt stosowania wielu chwytliwych skrótów (TDD, PP).

Na szczęście Robert wyszedł z tej próby obronną ręką. Prezentacja była tak dynamiczna, że nie byłem w stanie znaleźć czasu na twittera. Ważną jej częścią było porównanie pewnych aspektów związanych z pracą i prowadzeniem biznesu w różnych kulturach (USA, Europa, Azja). Prelegentowi udało się pokazać (przynajmniej według mnie) prawdziwe różnice między ludźmi wywodzącymi się z różnych środowisk narażania się na przypięcie łatki “amerykańskiego ignoranta”.

Tutaj możecie poczytać, co Robert sądzi o ACE.

Gwyn Morfey and Laurie Young – The Sword And Other Tales

Ta sesja była wspaniałym ukoronowaniem bardzo dobrego dnia na konferencji. Momentami miałem wrażenie, że panowie Gwyn i Laurie są profesjonalnymi aktorami. Sesja była pełna świeżych, innowacyjnych idei, jak choćby przygotowanie slajdów jako zdjęć rysunków namalowanych na tablicy.

Rzeczą, którą na pewno zapamiętam, choćbym zapomniał wszystko inne z tej konferencji, jest The Great Sword Of Integration. Zainteresowanych zapraszam do obejrzenia video, jak tylko będzie dostępne. Naprawdę warto.

Celem sesji było przedstawienie prostych narzędzie (jak wspomniany miecz) rozwiązujących skomplikowane problemy. Jednym z takich narzędzi, które bardzo chciałbym użyć w swojej firmie jest Standard Wall: tablica, na której można przyklejać swoje pomysły dotyczące pracy zespołu, np. standardów pisania kodu. Głosowanie odbywa się poprzez postawienie kropki przy danym pomyśle. Pomysły z wymaganą ilością kropek są realizowane. Proste, prawda?

10 things… – Marc Löffler

Marc był nieoficjalną gwiazdą ACE. Jego dwie prezentacje były jednymi z najlepszych, mimo iż trwały w sumie… 10 minut. Dotyczyły tego, co można w scrumie spie… Jedna z nich dotyczyła Scrum Mastera, a druga — zespołu. Tutaj możecie zobaczyć tę pierwszą. Naprawdę warto poświęcić 5 minut.

Podsumowanie

To już niestety wszystko. Konferencja się skończyła. Pocieszające jest, że za rok odbędzie się ACE 2011.Ja na pewno tam będę. Was wszystkich także zachęcam.

VN:F [1.9.13_1145]
Rating: 5.0/5 (2 votes cast)

ACE, najlepsza konferencja na jakiej byłem (ostatnio)

Jeśli ktoś śledzi mnie za pomocą twittera, wie że ostatnie dwa dni spędziłem na konferencji Agile Central Europe 2010. Konferencja właśnie dobiegła końca (w chwili, gdy piszę te słowa). Zostawiła po sobie dwa uczucia: zadowolenia oraz niedosytu. Zadowolenia, ponieważ była to jedna z najlepszych konferencji, w jakich miałem przyjemność uczestniczyć. Niedosytu, ponieważ dwa dni to bardzo mało. Chciałoby się jeszcze kolejne dwa, aby móc lepiej poznać wszystkich wspaniałych ludzi, którzy przybyli do Krakowa, aby przekazywać i chłonąć wiedzę i doświadczenie. Ale dość tej ściemy — przejdźmy do konkretów, czyli co się na konferencji działo. Z racji dużej ilości materiału postanowiłem w dzisiejszej notce opisać tylko pierwszy dzień.

Rachel Davies – Retrospectives

Pierwsza prezentacja dotyczyła… retrospektyw, czyli wyciągania wniosków z popełnionych błędów oraz odniesionych sukcesów. Tak, Panie i Panowie, sprint retrospective to nie czas dzielenie się nowymi niesamowitymi pomysłami, tylko na rzetelną analizę przeszłości oraz wyciąganie wniosków na przyszłość. Te dwie części — dotycząca przeszłości oraz przyszłości — powinny być odpowiednio zbalansowane. Scrum pozbawiony retrospektyw to, według Rachel, dzień świstaka.

Rachel zwróciła uwagę na bardzo ważną kwestię dotyczącą retrospektyw: skuteczność wprowadzania uzgodnionych poprawek w życie. Często zdarza się tak, że uczestnicy spotkania dojdą do bardzo dobrych wniosków, zaczną je nawet wprowadzać w życie, jednak ostatecznie żaden z pomysłów nie zostaje doprowadzony do końca. Sposobem na poradzenie sobie z tym problemem może być zdefiniowanie meta-procesu (wymyślony przeze mnie buzzword) — procesu (Scrum, Kanban?) zarządzającego wprowadzaniem innowacji do głównego procesu budowy oprogramowania. Ciekawą ideą jest także mierzenie velocity w takim meta-procesie dla określenia skuteczności innowacji.

Maria Diaconu & Alexandru Bolboacă - Software as a craft

Dwójka prelegentów z Rumunii postanowiła zaprezentować ideę ruchu software craftsmanship. Bardzo spodobała mi się definicja profesjonalizmu, którą zaproponowali Maria i Alex. Otóż według nich profesjonalizm to umiejętność tworzenia dobrego i czystego kodu co najmniej tak szybko, jak złego i brudnego. Oprócz ogólnie znanych idei prelegenci przedstawili także jedną, o której ja do tej pory nie słyszałem: Code Retreat. W dużym skrócie, jest to praktyka polegająca na tym, że grupa programistów spotyka się w jakimś zacisznym miejscu i rozwiązuje kilka przygotowanych problemów. Każdy problem jest rozwiązywany wielokrotnie na wiele różnych sposobów. Po każdej próbie wytworzony kod jest omawiany, a następnie kasowany. Kolejne próby mogą mieć nakładane pewne sztuczne ograniczenia, np. nie wolno stosować pętli/instrukcji warunkowych.

Pomysł Code Retreat spodobał się Adamowi i mnie i postanowiliśmy spróbować zorganizować w Krakowie eksperymentalną sesję Code Retreat, prawdopodobnie w maju. Jeśli ktoś z Was jest chętny, aby w tym uczestniczyć, proszę zostawić swoje namiary.

Thomas Sundberg - Clean Code

Na tę sesję bardzo czekałem i bardzo się zawiodłem. Być może gdybym przeczytał abstrakt, wybrał bym konkurencyjną sesję Moniki Konieczny (która podobno była świetna). Jestem głęboko przekonany, że Thomas Sundberg ma odpowiednią wiedzę i kwalifikację, jednak nie umiał tego przekazać słuchaczom.

Sesja polegała na przeglądaniu kolejnych przykładów z książki Clean Code Boba Martina. Niestety czytałem ją dosyć niedawno i wszystkie te przykłady miałem jeszcze w pamięci. Dla mnie było to zmarnowane 60 minut. Na szczęście była to jedyna taka wpadka na całej konferencji.

Paweł Lipiński & Paweł Brodziński – Agile — a mindset or a toolbox?

Była to pierwsza sesja open space, na jakiej byłem podczas ACE. Obaj organizatorzy mają ogromną wiedzę na temat prowadzenia projektów i ogólnie tworzenia oprogramowania. Przysłuchiwanie się ich dyskusji (i czasem dorzucanie swoich “trzech groszy”) było wielką przyjemnością. Ostatecznie dyskusja odeszła nieco od oryginalnego tematu i przerodziła się w sesję Q & A dotyczącą prowadzanie projektów. Nie udało się dojść do porozumienia, czym jest ten cały agile, ale właściwie nie oczekiwałem tego. Z opiniami organizatorów można zapoznać się na ich blogach: tu, tu oraz tu.

Dla mnie najważniejszym take-away było stwierdzenie Pawła Lipińskiego, że tłumaczenia agile jako zwinny zatraca część znaczenia oryginału. Agile powinno być tłumaczone raczej jako skuteczny, efektywny. Takie tłumaczenie wiele zmienia w rozumieniu tego ruchu i jego celów.

Simon Roberts – Making Scrum Stick: Sustainable Scrum Transitions

Simon przedstawiał swoje doświadczenia w przeobrażaniu organizacji o tradycyjnym podejściu do tworzenia oprogramowania w organizacje agileowe. Z prezentacji Simona zapamiętałem dwie ważne kwestie.

Transformacja scrumowa jest najbardziej efektywna, jeśli przeprowadzana jest jednocześnie od góry i od dołu. Zarówno podejścia top-down, jak i bottom-up realizowane osobno mają mniejsze szanse powodzenia niż skoordynowane działania kierownictwa i szeregowych pracowników.

Scrum musi zostać wbudowany w DNA organizacji (bardzo ciekawa analogia), aby w momencie napotkania problemów organizacja nie powróciła do starych praktyk. Chodzi o to, aby wszystkie procesy organizacji zostały oparte o idee związane ze scrumem i ruchem agile — dopiero to gwarantuje, że przeobrażenie będzie trwałe, nie powierzchowne.

VN:F [1.9.13_1145]
Rating: 5.0/5 (4 votes cast)

Customers should care if you are agile

Although I understand Paweł’s point in his anti-bullshit (not ani-agile!) post, I have my own thoughts on the subject of customer-vendor relationships. They are based on what I see here, in Poland, so if it is different in your country — good for you :-)

Why should customers care if you are agile? It’s simple. Because so-called agile methodologies bring some concepts which are valuable to them. These concepts include:

  • focusing on customer needs
  • releasing early

These, in my opinion, are things customers should care because, objectively, these things help achieve business goal earlier and more accurately. Customers should, in their own interest, choose vendors who are able to implement agile concepts. The problem Paweł raised is that customers are unable to verify whether you are really Agile or it’s only marketing bullshit. I think that problem (at least in some cases) is slightly different. It is customers not willing to verify if you are agile, or generally, if you are competent. As long as formal agreement is fulfilled, they don’t care. And they loose money on software which has poor quality, isn’t very useful (but fulfils specification) and is delivered (possibly) on time.

The thing I like most in agile methodologies is transparency of software development process. Anybody, particularly the customer, can see how I am doing in any moment. Do I know how to manage a team (if there is such a role as manager)? Do the team know how to create quality software? These are all verifiable if customer is really on site and cares about project. And if she doesn’t like my way of development, she can quit in any moment, because she pays for my time, not for abstract software product.

So, in my opinion, is not ‘Agile’ label customers should care, but Agile principles. They make software development process more beneficial from customer’s point of view. They also allow customer-vendor relations to me based on facts (about your process), not on marketing bullshit. This is contrary to my current experience which is:

Get the customer, tell him what she wants to hear about Agile, CMMI, or whatever, and make her sign the contract. THEN we will figure out what we have to do…

Natural reaction for such behaviour is customer being extremely careful and, initially not knowing Agile, focusing on preparing more and more detailed specs so that vendors couldn’t cheat. The only ‘agile’ they experience is the marketing’s one, so I am not surprised that they don’t like it and don’t care about it.  Vendors, on the other hand, produce more and more marketing bullshit about their process and it’s closed circle.

The outcome is (besides customers not being happy and not knowing why) that small new vendors who are willing to be Agile and focus on software craftsmanship are fighting a loosing battle because all they can provide is a transparent development process and real quality, not the sophisticated marketing bullshit.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)