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 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!


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 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

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