Getting happier and more efficient with Personal Kanban.

Paweł Brodziński September 27, 2013

You might remember one of recent posts of Mirek on Pomodoro. It’s only one way of tackling the problem of productivity we use at Lunar. Actually if you asked a completely anonymous no-boss at the office he might say something along the lines:

“Pomodoro? Bollocks! It’s like time boxing your day and expecting that nothing would happen during the time box that requires you attention. And you know what? People keep coming to me interrupting me so if I want to be considered a nice guy, and I do, I can’t just answer: I’m in pomodoro, bugger off, sorry.”

On a more serious note, I like Pomodoro, but my line of work doesn’t really suit the 25 / 5 minute pattern. I do a lot of things that take less than 5 minutes. Only occasionally I’m sucked into something that lasts a couple of hours.

Personal Kanban at work

At the same time my primary work is being available for the people when they need me. No matter whether it is a project-related issue, a serious chat on stuff related to employment contract or a game of Dominon. I shall be there when I’m needed.

The problem is people don’t tend to wait with discovering a problem till my pomodoro is finished.

That’s why I prefer a different approach.

Personal Kanban for the win!

Personal Kanban is a simple, but not simplistic, application of Kanban to a personal level. You wouldn’t have guessed, would you? Anyway, the basic two rules are:

  • Visualize work

  • Limit work in progress

A typical Personal Kanban implementation is a board with three columns: to do, in progress and done. Then there are work items that travel (surprise, surprise) from to do to done. Nothing fancy here so far.

The caveat is the second rule which is about limiting the number of things that are ongoing right now. This changes one’s focus to finish stuff that was started instead of just pulling more and more work from the queue.

Whenever I’m back to my computer, I just glimpse at the board to see whether I’ve been doing something already. In this case I simple come back to this task. In any other case I just pull another work item from my to do column.

Not that easy

One might say: “Whoa! Is it that easy?” Well, actually it isn’t. In fact, this is my second implementation of Portfolio Kanban and I’m doing a few things a bit differently now.

First of all, hand offs are always a problem. I mean, if completing a task requires someone else’s work too you don’t have full control on making it done. If I need Mirek’s feedback on the design of a site of one of our clients I won’t be able to answer the client till Mirek does his part.

That’s why I pay much attention to the way I define tasks for me. I prefer to have very atomic and fully controllable tasks like: ask Mirek for feedback, remind Mirek about pending feedback, remind once again, and only then answer the client. This changes the dynamics of my Personal Kanban board. More on that later.

The second thing is being serious about work in progress (WIP) limits. In this case WIP limits are not only to limit context switching thus directly improve productivity. They are also to help focusing on a single thing.

If something is ongoing I just make it done and can erase the part of my memory that kept reminding me about the task. Actually, I’d prefer to count on my memory, but over the years I’ve learned that it is so sloppy that it can’t be trusted.

The third challenge is to remember to run all the work through the board. Sometimes it really feels awkward to put something on a sticky note despite the fact that it’s going to take three minutes and you are starting to work on that right now.

You start appreciating that once you learn that, for whatever reasons (I blame Murphy’s Law), people tend to interrupt you in the middle of these three-minute long tasks even more frequently than during the bigger ones. This actually helps to avoid situations when something falls under the table just to be found six months later.

Work in progress limits

With this implementation of Personal Kanban, I’m really aggressive when it comes to WIP limits. I use the WIP limit of 1. I can only do this because I define my tasks in a way that makes them blocked very, very rarely, if ever.

At the same time this is so much of a boost to my focus that I prefer to spend a few seconds more when I add stuff to my to do column than later keep thinking about the exact status of tasks in progress.

It shouldn’t be a surprise, as human brains are simply wired in a way that we keep thinking about unfinished business. This property even has its name – it is Zeigarnik effect. Zeigarnik effect simply tells us that we humans tend to interrupt ourselves thinking about stuff that we left incomplete.

Just think – when was the last time when, while doing something completely different, you suddenly thought about that email that you were supposed to answer. It comes completely out of the blue. No inspiration from outside world whatsoever. I’ll tell you a secret – it’s your brain working as it is designed to work.

So basically that’s why I use such an aggressive WIP limit. It means that for the stuff I need to remember not now, but in a couple of weeks, I need some sort of reminders. And you know what? Any calendar app does that just fine.

It’s mobility, you fool!

The tricky part is that I’m very mobile. I don’t even have my own desk. This means that a whiteboard is hardly an option. Well, a classic whiteboard, that is. What I found somewhere in our office dungeons is a tiny 19-inch whiteboard that I can take with me as easily as I can carry my laptop.

So I take it with me whenever I’m moving to a random place of the office.

I’ve tried using the web application for that but it requires way more hassle to interact with it. Not much later, I ended up choosing work items not even looking what was in the app, thus rendering the electronic board totally irrelevant.

The outcomes

It’s not my first time with Personal Kanban, so productivity boost wasn’t a surprise. What was a surprise was the impact of the simple tweaks of defining work and limiting WIP to 1. I feel like I’m accomplishing tons of work. In fact I even see it, because I have to empty my done column every now and then.

Another nice thing is that I have a motivation to keep my backlog empty. You definitely heard zero inbox idea. It’s about not having a single email that you have to do something with. I stopped pursuing this goal long time ago.

However, with Personal Kanban it’s different. It’s like with one of these games where it is just one more game. In my case it is just one more task. They are small anyway.

At the same I believe there was no impact whatsoever on my availability for the whole team. I’m just there. If you need me, I’m happy to take a break because I know that once I’m back, I’m back to work on exactly the same thing as before.

Grind your web application! Load testing web apps with Grinder.

Wojciech Ochmanski September 5, 2013

What’s Grinder? It’s a free distributed load testing framework written in Java. It allows you to write test scripts in Jython and Clojure. I’m not going to advertise it nor describe all its features, so for more detailed information go to the Grinder website. In this post I’m going to present load testing web applications with Grinder.

Grinder runs an agent process on a machine which can create/stop worker processes. Each worker process can run tests in many threads. The console is the process that coordinates it and lets you control it using the GUI. The console also gathers some statistics and allows scripts editing and distribution. You don’t need the console to run tests on a single machine. These are the three main elements of Grinder. You can create script from scratch on your own, or use a proxy recorder. I’ll use a proxy to record script and modify it later to fit my needs. I’ll use the most recent version of Grinder which is 3.11, it also supports Jython 2.5.3 pretty wel.

First thing to do is download the proper version of Grinder from Extract it to some dir – if you want it in your repo as a dependency, then put it in the vendor dir (in case of RoR project). If not, it’s up to you where it will land (just don’t forget the path). To use Grinder 3 you just need to have at least java 6 on your machine.

Next, you probably would like to prepare a test script. You can write it from scratch (which might be quite a tedious task) or use the grinder proxy to record it. The second option is more convenient, at least it was for me. I had a couple of complex scenarios to script. But before you do that prepare a set of small shell scripts which will help you with starting proxy, console or with running a test. The first one named just sets and exports couple of required variables.

If Grinder is added to the CLASSPATH, then you can start recording a proxy. I’ve also created a small script, as recommended in the starting guide on the Grinder website.


. . /
java net.grinder.TCPProxy -console -http >

Recording proxy is started with a -console option which displays a control window that allows terminating a proxy process cleanly, -http option enables filters which allow the recording HTTP traffic. By default proxy sends output to terminal, so it’s redirected to file. Proxy listens on port 8001. You can record additional headers if the basic set is not enough for you – go to the Grinder additional headers section for a description.

Before recording script you need to configure your browser to use this proxy. In recent Firefox (v. 23) it’s Edit -> Preferences -> Advanced -> Network -> Settings.

Now the script can be recorded. Let’s say that you want to simulate 100 users signing in to your application. After starting the proxy just point your browser to your application and sign in as some existing user. You may do some more actions, it depends on the scenarios that you want to automate. When you finish recording, terminate the proxy process using the console window. This guarantees proper saving of the script. You should have something like that in the file.

The next step is to parametrize and clean this up a bit, so it will be more readable and easier to maintain. I removed requests, methods and constants referring to them that were done to external services. I also got rid of requests for images, stylesheets etc. I also corrected the methods’ name and requests’ numbering. Now each request had a separate page method which was separately instrumented where statistics were gathered for each of them. I also added a couple of helper methods for: loading users from file, getting a random user, writing response to file (sometimes helps in debugging your test). After all the modifications the script looked more or less like this:

Before you run the test, there’s one thing that you have to do and that is to prepare the properties file. It is the file that tells grinder which script to run plus how many processes and threads to create, how many times run the script, how long are the sleep times and much more. You can even set a path to a different jython version there. I had to set the grinder.jvm.arguments property to stop Grinder complaining about caches. I also turned off the console. In my test I wanted 1 process to be created and 3 threads that will be repeating the login scenario 5 times (of course each thread will run it 5 times). initialSleepTime property says each thread to wait before start random number between 0 and 10000 ms. All times are specified in milliseconds.

Grinder gives you many ways of configuring creation of processes. You can run couple of processes on different machines. Processes on different machines can create different number of threads (each load injector has different properties file). All processes might be started at the same time or you can set how many processes will be started after every period of time, even how many of them will be initially created. Here’s my file.

Finally you can run the test. Use that bash script, to do it in an easier way. Just remember to create all the necessary test data, like users, etc…


. ./
java net.grinder.Grinder $GRINDERPROPERTIES

The results you will see on your screen summary report will look like this.

It shows the number of successful tests and errors. Number of all executed tests = tests number * processes number * threads number * runs number. Total, mean, standard deviation for each of the tests is calculated only for successful ones. All data is saved to log files. Grinder organizes log files in a way, that each process saves data to a separate file called $hostname-$process_number.log. Grinder also gathers data about test executions in files called $hostname-$process_number-data.log.

When running a test with the console turned on, you’ll see a window similar to this:

Grinder console screenshot

Grinder does not generate any graph files. You can do it with other tools, that are listed on the Grinder’s links page, like Grinder Analyzer, or Ground Report. Thanks for reading and let me know how grinding your app went!

Lean Coffee at Lunar Logic

Mirek Wozniak August 5, 2013

All-company meetings are boring. Especially when you’ve got to listen to a manager’s rant about yet another robustly streamlined leveraging out of the box. Gosh.

A cup of coffee and a timer

Thankfully, we’ve got no managers. We do have company meetings, though. Once a week, to be precise. It’s called the lean coffee, even though it’s not about watered-down coffee.

Meetings democratised

We gather in the so-called sofa room every Wednesday at noon, making ourselves comfortable in the omnipresent bean bags. We work on two floors, so it’s a good opportunity to meet people you seldom see.

If you want, you may write a topic on the whiteboard, which we’ll vote on after everyone’s in place. Paweł (the no-boss) counts the votes then and we start discussing the most popular topic.

We talk about a variety of issues. We’re a transparent company, with all its pros and cons, so more often than not we talk the upcoming projects over. Or the very sales process. The lean coffee is not dead serious, so there are often questions concerning the hair colour of some people (hint: ginger) or boss’s height (hint: stilts).

Time saved

Lean coffee is timeboxed for 30 minutes, with up to 8 minutes per topic (it can be prolonged to 12 minutes if need arise). Thus, it’s exactly one pomodoro long. A half an hour is just enough for you to focus and not get tired or bored.

We’re not very strict – the routine may break, especially during hot, lengthy days or when there’s an ultra important topic on the plate. The lean coffee isn’t compulsory, so if you’ve got something big (e.g. a product shipment) to do, no one will drag you to the sofa room.

Folks entertained

Lean coffee is fun. Most of the people usually attend it, passionately interested in the company life. It’s weekly, so we don’t repeat the topics and there’s always something new to listen to. Especially when comfortably reclining in a bean bag.

Lean Coffee is sometimes called Open Coffee and it’s an open weekly event for discussing all sorts of matters, e.g. Open Coffee KrakówMore about Lean Coffee from the Limited WIP Society.

pomodoro cow timer Distractions. Distractions everywhere! Social media. Smartphones. Google Glass coming up. And you just want to get things done.

And the biggest culprit – the office itself. Fancy a coffee? Let’s go for a lunch? Have you seen the rocket dog?

Screw you. Pomodoro in progress.

Short bursts of furious work

Work for 25 minutes. Relax for 5 minutes. Repeat. Simple?

That’s how some of us, including myself, work at Lunar Logic. We set kitchen timers and  work according to the Pomodoro technique‘s rules. ‘Pomodoro’ means tomato in Italian and the name comes from the shape of the first kitchen timer its creator used.

We’re laser-focused and distraction-proof.

A pomodoro a day keeps the doctor away

But why use some fancy technique and not just sit and slam at the keyboard?

My previous boss once said that programmers should work 5 hours a day at most. Strange? Might be. Our industry values quality over quantity – one working feature is always better than three broken ones. And you work way better when you’re rested (#cptobvious).

Pomodoro technique can make that happen. If you think about the actual working time, it’s ‘just’ 12 pomodoros. Compare 5h spent on working features with 3h of short breaks in between TO 8h of chit-chatting, drinking coffee and intermittent coding.

Next will be better!

That doesn’t mean you shouldn’t try doing more work sessions – I remember noting last Friday that I could do more than 10 pomodoros. By finishing my day with a work session, for example. After all, you shouldn’t worry about having a break after you leave the office, should you?

You’ll also notice how emotionally rewarding working in pomodoro is. You Get Things Done (R). Stop wasting time. Get rid of that soul-eating feeling of guilt when a day passed and you haven’t produced anything palpable. The sun starts shining. People smile at you. Oh, wait…

The Good, the Bad and the Pomodoro

This technique has some possible drawbacks. Firstly, it’s not for everyone. I’m not a programmer and express myself in words, not code. I found it hard to yield and harness my time into little time boxes.

Secondly, there’s a problem with the “bigger” breaks, i.e. the 15-30 min after every fourth pomodoro. It’s not that easy to have a dinner under 30 min, especially if you cook by yourself. One possible solution is to devote every fourth pomodoro – preferably the 8th one, for cooking. The 25 min + 30 min of a break should suffice. After all, making a dinner is a productive activity, isn’t it?

Pomodoro is flexible, yet working for 10 and relaxing for 5 minutes isn’t the best idea. I’ve started with 20/5 and soon moved up to 25/5, because I just felt that I had too much free time! I sometimes have shorter breaks – 3 minutes, when I really feel I’m in the zone. However, skipping the break session doesn’t pay off – you’ll most probably feel tired and less productive during the next pomodoro.

One thing about the kitchen timer: I jumped up in my chair a few times when it rang. Make sure that you and your coworkers don’t… or get a digital timer.

You rule.

With Pomodoro technique, you’re the master of your fate. The tick of the clock means efficiency, not running out of time. You can stretch pomodoro over whole teams, use it to work or study.

So… how many pomodoros have you done today?

P.S. Of course, there is much more to this technique, including information on braving the distractions, to-do lists and whatnot… see for yourself! And check this post about Ping Pong Pomodoro Pair Programming by Adam Pohorecki, who used to work at Lunar Logic and pioneered the technique here :)

Put yourself on rails with a push of a button

Tomek Rusilko July 16, 2013

Rails Button Since I haven’t discovered any IDE satisfying my needs for Rails development, I have had to set up my work environment by myself.

This is a good thing because I can tune it to my needs and… a bad thing because, to be efficient, this personal IDE requires firing up several apps and/or issuing a few commands before actually starting to code.

At the very least you need 2 terminal windows (for command line and rails server), a browser window running localhost:3000 and a text editor of your choice with the app project folder opened and ready to code.

Additionally, it would be nice to have a terminal window with automated test suite (e.g. guard) and a rails console, should you need to foolproof some code on the side.

All this means writing many commands and/or clicking here and there every time you are about to begin coding, which in my case happens every single morning.

How about setting this all up in a push of a button?

Here is the recipe guiding you to get this working on Ubuntu w/gnome, bash, chromium, rvm and Sublime Text 2. I assume you already have your rails app folder, cloned from github, located in the path-to-your-project dir.

  • Make sure you have Ubuntu w/gnome, rvm, and chromium installed
  • Make sure you can start Sublime Text from command line using subl
  • Download the bash script and put it somewhere (this guide assumes: /opt/bin/
  • Add execution rights chmod o+x /opt/bin/
  • Edit your ~/.bashrc file and add following function at the very bottom:
      function dev {
      if [ "2" -ne "$#" ]; then
      echo "Usage: dev start|stop Project-folder-path" && return 1
      elif [ "start" == "$1" ]; then
      /opt/bin/ $2
      echo "$1 method not implemented"
  • Terminal configuration Source .bashrc file . ~/.bashrc or logout and login to shell
  • Create and configure gnome terminal profiles named Rails-server, Rails-guard, Rails-console. Remember to check option: Run command as a login shell, otherwise RVM may behave strangely. You can experiment with other options, you can see my preferred setup for reference.
  • Additionally you can configure terminal titles and color schemes which are a nice-to-have feature as you can tell where you are at a glance.
  • You’re almost done! Run dev start path-to-your-project-dir from your terminal window and… voila!
  • Wait a few seconds and… start coding!

Having all this set up enables me to enjoy my morning espresso 1 minute longer :)

Experiment with this simple script and feel free to post any comments with improvement tips / porting to other platforms (any mac users here?) etc.