Monday, December 16, 2013

What does Agile mean to you?

Not so long time a go, I was on the conference about Agile (AgileByExample - great conference by the way) and one of the sponsors has a win-tablet contest. To win brand new Nexus you had to post on their facebook wall answer for a question:
What does Agile mean to you?
I posted 2 answers but the contest was setup and someone else won my Nexus (just kidding of course). Conference was over but the question was coming back, ringing in my head. What the hell is Agile ? Is it methodology (ugly word), nickname for Scrum, XP or maybe just a buzzword? Other questions emerged: Who could be agile? Developer? Analyst? CEO? Housewife? My confusion was rising… I knew that I had to start from the beginning. What is called Agile by most of the people? For sure one of those:
  • TDD
  • Scrum
  • Kanban

What are the similarities?

TDD gives me flexibility to change my code anytime and I know that it will work as I'm expecting. Scrum (same as Kanban) helps me to deal with changing (or just discovered) customer's requirements. Main difference between agile approach and its opposite: waterfall (or simply planned end-to-end process) is ability to handle change. So simply agile means being adaptive.
Adaptation is very important thing, in fact it's a matter of live or dead.
It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. Charls Darvin
So if you don't want to end up like mammoth or dinosaurs, be adaptive! I think that the reason why nowadays start-ups and small innovative companies are so successful. They are adaptive!

You don't want to end up like mammoth

Adaptive: another buzzword?

But not to get from one buzzword to another, what is my definition of being adaptive. I believe that there is a philosophy behind it. I come to terms with fact that I'm not able to plan and control everything (believe me, that it took me a while). Maybe for some of you it's obvious, but I'm programmer. When I write println("hello world"), the text is printed out. Moreover in the real world I am expected to make promises and fulfill them (those are named estimates, plans, sprint backlogs etc). So sometimes I may have illusion that I'm in control. That means that: I may think long enough and come up with solution or plan that will work! And will always work… cause it's smart and made well.

Wanna play?

And here comes Agile…

There is no a such thing as perfect plan, solution or even estimate. Some things are better than the other, but usually you don't know how good they are until you try. The solution is to start with something small, try it out and then change. Repeat that cycle forever (I call it: try-change cycle). There is always temptation to spend more time on planning and invent a perfect solution. But in my opinion it's better to spend that time on trying out. The other problem is that, in big organizations to change something you must have well-documented-bullet-proof plan and blessings from the CEO or managers. That's the reason why such organizations are almost incapable to change. So if you are working in such organization remember: it's much better to change one team (call it pilot project) immediately than spend a year to make a plan that will change organization. If your team will be successful it would be much easier to spread the change. On the other hand, if your first solution will fail you may easily change it (remember, be adaptive!).

She is definitely Agile!

Agile is direction not destination

Bottom line is, be adaptive, prefer try-change cycle over thinking on master plan. Always start with something small, try it out (as it is) and then if it doesn't work well enough, change it. Remember! You are never there, something that may work today but tomorrow world will change. You should never-ever end try-change cycle. That's my definition of agile and anyone could be agile: student, developer, programer, CEO, housewife, literally anybody. I tried to be agile in my personal life and no surprise here, it works!

Are we there yet ?

Beware

Beware you will meet salesmen that will tell you that there is a magic pill called Scrum or whatever. You just buy it or make a certificate and you are agile! Just like that! If you believe them, it means that you are not agile enough. I don't say that making certificates or training doesn't make sense, just remember that those are just tools to become agile, not the agile itself.

Beware agile certificates!

Disclaimer

Everything you just read it's my personal option. I'm not considering myself as agile guru or coach. I just think that I understood what agile means to me and I want to share this though with you. Thanks for reading that, if you disagree or have some more insights about agile just leave a comment or drop an email.

Photos

Photos on CC license taken from Flickr:
Mammoth, SquirrelLandscape, Beware sing

Tuesday, October 15, 2013

How to make workshop conference ? - Warsjawa 2013

If you wonder "How to make workshop conference ?", you know that's could be extremely difficult. There are hundreds of attendees and workshops are usually quite small (at most 30 people). Programming workshops usually needs infrastructure as access to internet, large display, microphone speakers. So you need about 20 rooms with equipment and lot's of organizers to solve "bugs" when they show up. You know Murphy's Law, and you know that "bugs" will appear shortly after conference will start. It sounds like a head ache, doesn't it ? But If you want to know how to do it, and how to turn that conference in success, ask Warsjawa organizers. They have the magic formula. Warsjawa 2013 was spectacular success. Every thing went really smooth!
Creative attendees that was something we were counting on
This year I had a great opportunity to be on the other side (together with Jan Zborowski and Pawel Stawicki). I was trainer on "One day with challenging client" training. That's training made by SoftwareMill which main goal was to create similar to real-life case and get attendees involved. On that case we show up traps that team members could be caught. Many of those traps are not the traps set up by "evil client" but by the team itself.  On the other hand we demonstrate good practices that make communication with client more efficient. We teach attendees a bunch of simple guidelines that could improve their relations with customer and increase project success rate.
Q&A session
Attendees were really great, all tree teams managed to deliver working solution. On Q&A session we had a great opportunity to talk about everyday problems. I hope that this training will help them in their every day work. It's not a silver bullet but some technics should be useful (I was attendee at this training once and I use them often :-) ) Big thanks to one of the organizers , Adam Chudzik was helping us during the training, his was very eager to help and we really appreciate that.

My, speaking with passion
After finishing my workshop I was really tired but event though I took usability training workshop with Mateusz Kaczmarek and Michał Trzaskowski. Workshop was fine and that was nice trip out of my comfort zone. I learned a bit about usability testing. It was nice introduction to the Human-Computer Interaction course that I just started on Coursera.

Having beer with another Łukasz
The conference after party was at "Mam ochotę". I met a lot of Java/Scala geeks there and had a change to talk a bit about Scalar. Scalar is our new baby (SoftwareMill's), it's one-day fee Scala conference, that will take place in Warsaw at 05.04.2014. That was a great day but very exhausting.

PS 1. If you enjoy idea of "One day with challenging client", we (SoftwareMill) may run it at your company or conference.

PS 2. Next chance to attend to that training is on AgileByExample 2013 (on this friday)

PS 3. All photos were made by organizers, used by permission. To see Warsjawa 2013 gallery click here 


Thursday, October 3, 2013

Code Review is not about...


In SML we do code reviews. We do them on daily basis. Actually the point that we are now is a result of long journey that we made. We try different strategies and tools until we went to the place that we are now (but it doesn't mean that we are going to end up here).
During this journey we found many risks and traps that are waiting for a newcomer. That's what this post is all about, traps & misconceptions on code review.



Code control: many organizations uses CR for controlling codebase. Most of them are using pre-commit strategy. In many cases its because those projects are open-source with hundred of commiters. In real life this is quite rare scenario, so if you hired someone it means that you trust him enough to let him commit code to repository. I know that in some organizations there will be temptation to make procedure that will force developers to "review" and "approve" every commit, but it will not guarantee the quality. Moreover people will soon treat code review as "stupid" corporate procedure and will try to hack-it (such changing password every month e.g. people are using passwords like: mypass1, mypass2 etc.).



Hall of blame: Don't user CR for finding scape goats or guilty ones. Let's assume that there was a failure and you found a person who "reviewed" the "bad code" and blame him for not pointing it out. I will cause that development in your company will drastically slow down. People will be pointing out every semicolon not at the right place, because they will be afraid of being scape goat. Your team members will start feeling unconfident and the lack of trust.


"Code" of duty: Don't push on your developers to much. If you force them to make review every day for an hour, soon they will hate it and treat as unfunny duty. Code review is about learning, praising others and giving feedback so it's very social activity. CR could be fun, don't spoil it.




I'm not my code: If your code was reviewed by someone and he left some comment (sometimes even not too nice), don't get angry. He isn't saying that you are a poor developer. That wasn't his intention nor code review is about that. All he did, was criticizing some piece of code (not the author). Code review is all about code, not about you. Don't treat code review tool as forum with "trolls" and people fighting each other. When you will be writing comments try not to be rude or too strict. Try to imagine that your are on the other side reading it.

To sum it up, there is plenty of ways to make code review wrong. Those 4 are the one that I experienced or anticipated, so beware. I promise to write post about "what code review is about".

If you wan't to try out code review tool (fruit of our experience & practices) visit codebrag.com

Used photos:
1. "The Puppet Master" by Henk
2. "ready for duty" by Leonard John Matthews
3. "Polar wolf's argument" by Tambako the Jaguar

Thursday, July 11, 2013

Gdzie kucharek sześć, tam nie ma co jeść - czyli Confitura 2013

W tym roku zdobyć wejściówkę na Confiturę było trudniej niż na niejeden koncert super-mega gwiazdy. Renoma konferencji rośnie i należy się z tego cieszyć. W tym roku doszły mnie słuchy, że "uwaga, uwaga" nie będzie obiadu. Wielu wieszczyło klęskę, puste sale i pojawienie się band głodnych programistów napadających na przechodniów konsumujących kebaby. Jak się jednak okazało plotki były mocno przesadzone. Obiad był, w formie nieco skromniejszej niż zwykle. Ale po kolei.



Rozpoczęcie konferencji, odbyło się z wielką klasą. Panowie z kapituły powitali nas w fartuchach niczym szefowie kuchni w towarzystwie kociołka w którym robiona była konfitura. Bardzo było to pomysłowe i doprawiło konferencję nutką poczucia humoru. Na otwarciu przekazano także symboliczną nagrodę dla firmy Javart za to, że wspierała ona Confiturę (wcześniej Javarsovie) przez wszystkie edycje. Szkoda tylko, że zabrakło w tej chwili ś.p. Pawła Cybulskiego dzięki któremu to wsparcie miało miejsce. Brawa dla kapituły za nagradzanie firm wytrwale budujących społeczność i inwestujących w nią długoterminowo.

W tym roku do wyboru było 5 równoległych ścieżek. Ja swoją rozpocząłem od Storma. Prezentacja pozwoliła zrozumieć elementarne pojęcia jak "spout" i "bolt" oraz zapoznać nas z przyjemnym API które ma Storm. Prowadzący pokazał jak łatwo można uruchomić sobie prostą topologie oraz jak łatwo można budować te bardziej skomplikowane. Co prawda z prezentacji nie można było wynieść wiele więcej, ale mi to specjalnie nie przeszkadzało ponieważ wcześniej bardzo niewiele o Stormie słyszałem, a prezentacja zainteresowała mnie tą technologią. Po krótkiej przerwie wybrałem MapReduce z Moniką Nawrot. Prezentacja także zaczynała się od podstaw i odpowiedzi na pytanie: "Po co nam to całe przetwarzanie w chmurze". Później mogliśmy poznać więcej szczegółów działania funkcji map, reduce i shuffle. Prowadząca pokazała także parę przykładów implementacji z wykorzystaniem Flume, która usprawnia i ułatwia korzystanie z MapReduce'a.

Następnie zaś byłem na moim zadaniem najlepszej prezentacji na Confiturze 2013 czyli z "Czego być może nikt nie powiedział ci o JS, a co jednak powinnaś/powinieneś wiedzieć". Mój firmowy kolega Michał Ostruszka okazał się świetnym prelegentem. Nie tylko przygotował ciekawą prezentację, ale także zaprezentował ją w sposób sprawny, lekki oraz z poczuciem humoru.

Następnie była przerwa obiadowa, podczas której miał nastąpić armagedon wieszczony przez Inków na grudzień 2012. Na szczęście nic się nie stało. Okazało się, że obiad był! Co prawda w formie trochę skromniejszej niż rok temu (gulasz i kanapki), ale każdy kto studiował musi przyznać, że w porównaniu do studenckich obiadów były to nie lada frykasy. Ja po skonsumowaniu gulaszu poszedłem uzupełnić dietę o warzywa oraz mięso (czyli na kebab). Bardzo fajnie, że ta przerwa była na tyle długa, że można było sobie wyskoczyć na kebab czy piwko i spokojnie wrócić na dalszy ciąg wykładów.

Następną prezentacje niestety przegadałem na konferencyjnych korytarzach. Ale cóż to także ważny aspekt konferencji, spotkać długo niewidzianych znajomych czy poznać nowe osoby dzielące tą samą co my pasję. Następnie posłuchałem Tomasza Borka o jednej z bolączek naszej profecji, a mianowicie o różnicach kulturowych dzielących Europę oraz Indie. Myślę, że ta prezentacja pozwoliła mi lepiej zrozumieć naszych kolegów zamieszkujących subkontynent indyjski. Przy następnej sposobności na pewno przetestuje zdobyte informacje.

Kolejnym moim wyborem była prezentacja Marcina Zajączkowskiego o testach mutacyjnych. Temat o którym parę razy słyszałem, natomiast nigdy zgłębiłem  Prezentacja Marcina odpowiedziała na najważniejsze moje pytania. Dowiedziałem się jakie mamy do dyspozycji narzędzia, jakie są ich ograniczenia oraz czy da się tego użyć w prawdziwym projekcie.

Na koniec posłuchałem prezentacji Michała Bartyzla o architekturze systemów. Była to ciekawa historia kilku prawdziwych projektów z morałem. Morał był dość oczywisty, ale często o nim zapominamy, otóż przy podejmowaniu decyzji co do rozwiązań, należy wziąć pod uwagę wiele czynników także tych "biznesowych" i "organizacyjnych", a nie ulegać wyłącznie technicznym nowościom i zachciankom programistów :-)

Potem było rozdanie nagród. Nie wiem czemu, ale jakimś dziwnym trafem nigdy nic nie wylosowałem (na żadnej z edycji). Może w żelatynie jest jakiś kod typu:
while (!lastname.equals("Żuchowski")) { lastname = losuj(); }
:-)

Kapituła przyznała także nagrodę specjalną Jackowi Laskowskiemu, którego każdy chyba zna i który jest ojcem chrzestnym nie tylko Confitury ale także Javarsovii.




Potem razem z grupą szczęśliwych entuzjastów Javy oraz technologii około JVM-owych udałem się na przystanek gdzie czekał na nas "Confitura Bus" sponsorowany przez mojego pracodawcę czyli SoftwareMill. Po podróży w miłym gronie znaleźliśmy się na Spoinie. Na Spoinie można było się nie tylko spoić (piwem ufundowanym przez Touk) ale także pojeść pizze i pograć jedną z wielu gier barowych (cymbergaj, piłkarzyki, bilard oraz kręgle). Można było porozmawiać z Konradem Malawskim o pracy w Ebayu i Scali, zagrać w kręgle z dumnie reprezentującym barwy CitiBanku Jackiem Laskowskim o honor firmy (sorry Jacek, następnym razem się odegrasz). Impreza była naprawdę przednia i trwała dość, długo. Ja jak rasowy kopciuszek zawinąłem się lekko po północy (gdy zegar wybijał po raz 193).

Podsumowując: konferencja bardzo fajna, impreza po prostu super! Kapituła jak zwykle spisała się na medal. Naprawdę myślę, że uszczuplenie budżetu na obiad to był dobry krok. Także, dzięki temu udało się zorganizować tak fajną Spoinę. Lokalizacja w postaci kampusu UW, rewelacyjna. Największe 2 mankamenty poprzedniej edycji czyli brak klimy oraz zbyt gęste ustawienie stoisk sponsorskich zostały wyeliminowane. Jak się okazało, gdzie kucharzy sześciu tam jest i co zjeść, i czego posłuchać, i czego się napić.

Cichy bohater.



Tomek Dziurko niestety w tym roku nie mógł uczestniczyć w konferencji. Tomek dzielnie pracował całe pół roku przygotowując konferencję ale z powodów rodzinnych musiał zostać w domu. Dlatego dla mnie to on będzie cichym bohaterem tej edycji. Mam nadzieje, ze za rok będzie mógł brać udział w tym święcie społeczności razem ze mną. Zrobiłem dla niego wszystko co mogłem, czyli wypiłem jego zdrowie na Spoinie.