Bored of your board?

Which is better, a physical board or a digital one?


Physical vs. Digital

As an Agile Coach in CyberArk, I am exposed to many groups and teams, each trying their own version of Scrumban and Agile. One of the most common practice is of course visibility, specifically, visibility of the work in progress, a.k.a the board. Most boards are digital by now, using either LeanKit, Jira or Trello, but from time to time you get to see and use actual physical boards. Obviously, these are usually used during sessions while creating the board (and later on it is digitized) but there are boards that stay there and are even updated daily or weekly.

Though there are a lot of benefits from digital boards (I remember the time I was an organizational Scrum Master in SQream, and we used whiteboards and sticky notes, but the sticky notes weren’t of the best kind and the board was right beneath the A/C – which resulted in a daily effort to pick up the notes from the floor and try to figure out where they belonged to :-)), I must admit that whenever I find a physical one, I get immediately interested and try to figure out what I can learn from it. In fact, that’s one of the ideas behind visibility (and transparency to be exact) – letting anyone see the status and engage in what the team is trying to do. You never know what kind of help you can get from someone that passes through…

The amazing thing about physical boards, is that they enable you to try out anything you would like, very few constraints, no need to ask a favor from your Jira admin, or get help from a friend on how to configure this or that in Trello or Leankit. You just do whatever you want, and re-adjust when needed. So easy… Just yesterday, my division (more about that in a future post) had a meeting where we sat and thought about challenges we would like to take on towards 2018. We didn’t know exactly what we are going to end up with, we just knew we wanted to start off with some brainstorming, and pick it up from there. So naturally we started with sticky notes, hand them on the wall and started to cluster, re-form, measure and vote on them. The “board” changed its configuration around 10 times during a 1.5 hour talk, each time answering the specific need we were trying to get.

So – what am I trying to say here?

Basically – whenever you can, try to use physical boards. They are much more attractive (at least can be, if you have at least one team member that has an eye for aesthetics), much more agile, much more effective (no need to search for them – they are there, literally) and much more visible and transparent. Even if it doesn’t make sense to use physical boards on your day to day work (and sadly there are many reasons why digital boards should be preferred), try to find the places and times where they can give you that extra presence, extra freedom and extra engagement.

Family Kanban

Last weekend was a very long weekend in Israel, having the new hebrew year’s eve on Sunday (“Rosh Hashana”). According to tradition, we had a holiday feast to enjoy, this year hosted by us (my family).

There was quite a lot of work to be done to prepare our flat, including tiding up, organizing the table, the dishes and everything towards hosting our guests.

We also had to make sure the children (ages 10, 7 and 3.5) have something to do and do not cause anymore mess than we already had.

We knew we need to get the kids on board and that’s when we had the idea – create a real board and have them on board literally.

So, I created a small Kanban board from a white board, added three columns (TODO/לעשות, In progress/עושים and Done/גמור) and wrote a few tasks on some sticky notes.

I then introduced the idea to the kids and my wife, and asked them to look at the tasks, take ownership on them (by coloring a spot on them, each with his/her own color) and move them to the correct column.

Around 4PM, my 7 year old son already created the new ‘Also Done’ column…


What can I say – the kids loved it. Especially my 7 year old son, who after a short time started to create his own tasks/cards and even added a “Break/הפסקה” task so that he can take a break and watch some TV… He also changed the TODO column to Also Done/גם גמור since there was not enough place for the done cards in the original column.

Towards 6PM, not a lot of tasks left…

We all worked as a team, figuring out which tasks to do first, asking each other to add tasks that we have forgotten and even did a short daily making sure we all know what we have left.

I always new about the idea of The agile family, but never had the chance to do it with mine. Now that we did, I can fully recommend it (smile)

#NoEstimates? why not?

Being an internal agile coach in a company, as opposed to being an external agile coach, means that you are required not only to know the theory and common practices of Scrum, Agile and so on, but also to know how the company decided to practically practice them. Each company might have different lingo, different view on how it should be done and different pains treated differently.


That’s why, as a new agile coach in CyberArk, I need first to observe how it is done here, and try to understand also why. My boss and I discussed how we should start, and decided that instead of estimating how long would it take to observe and learn, I will simply start my first sprint by joining a couple of teams and watch closely. Once I finished my first experiment, we discussed my insights and planned the next iteration.

Recently I went to a meetup on “Planning with #NoEstimates“. I went there curious to find out if there is anything behind this hashtag, feeling quite certain that estimating is something we truly need.


In my view, estimating is to planning just like estimations are to plans, i.e. Estimating is priceless while estimations are useless. Actually, both plans and estimations are worth something, since as opposed to “we don’t know how to estimate” and “a plan is always wrong”, I did see good estimations and I did have some plans that not only we could follow, but also helped while implementing them (usually, estimating small chunks, but looking at the bigger picture, yields good predictability from my experience). But it is clear, at least for me, that the process of estimating (same goes to planning) is very meaningful. It forces us to focus, learn, find out what we don’t know and think about alternatives. The estimations themselves, if taken as a whole, can help most times in driving good decisions.

Though most of the meetup was about estimations (and not alternatives to them), the very last slide was actually very interesting. It talked about doing experiments instead of estimating. The idea is to accept your ignorance and the fact that you don’t know how long it will take to do something you have never done before, and instead of guesstimating it, plan to learn by experimenting. The more you experiment, the more you learn, the less ignorant are you and the better you can do the job (and also estimate in larger confidence).

The funny thing is that this is exactly what I was doing as a new agile coach – doing experiments instead of trying to estimate something I didn’t do before…