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…


Scaling Agile

It has been a long time since my last post. I know. What can I say – moving is difficult. Especially when you are moving to a new apartment that you just renovated. Even more difficult when you do it with children.

We had a Trello board for the renovation (see Renovating the apartment) but this doesn’t necessarily mean that everything would turn out as it should. There are always the unknowns, the unexpected, the things that are out of your reach, and there is always the contractor that doesn’t show up when he needs to.

Anyway, a lot has changed since my last post. Sadly :-(, I left the startup I worked in (SQream) and happily :-), I started recently working as an Agile Coach in CyberArk. The most evident meaning of this, is that it is time to scale up. If till now I dealt with 2-3 development teams, here in CyberArk there are that many in a single group, and there are several groups such as this.


So how do you scale Agile? Well, there’s SAFe and there’s LeSS (is it by chance that both have a small ‘e’ amongst other capital letters?). SAFe has a very clear yet complex structure to it. Just look at the picture below. A lot of instructions on what to do, which roles to introduce and how to make it work. On the other hand, LeSS talks about less roles, trying to keep it simple and let you find out how to answer the difficult questions during the adoption.

The SAFe framework. Very detailed and prescripted.

As I am new to both, I am still struggling to figure out which one makes more sense to me. LeSS sounds like my first Scrum coach, which had very few answers and usually answered my questions with more questions. Though this was frustrating at times, it made me think. SAFe sounds like my second Scrum coach, which was much more helpful with examples, best (good, for the LeSS readers) practices and answers to many of my questions. From him I learned by example. Maybe this means that the best approach is to learn, and maybe even try, both.

LeSS Framework – looks much simpler, yet leaves a lot unanswered

What do you think?

Renovating the apartment using Trello

Hi there,

It’s been a long time since I last posted in this blog. I reckon that’s because I was too busy at work and at my second work – my wife and I started a project of renovating our new apartment, which is taking quite a lot of percentage or our (used to be) spare time.

Tamar and I discovered that even when you take an interior decorator and a contractor to design and perform the actual work, as the owners of the apartment you have so much on your hands that it seems like the project owns us and not the other way round.

As an agile practitioner, I was disturbed with the chaos we initially had and tried to find a constructive way of following the work being done, the backlog and the impediments. Soon enough I found the perfect tool for this – Trello. I knew Trello of course from work, having boards on numerous projects and flows, but didn’t quite use it at home yet.

So I started filling in the lists and items and the current board looks like this (sorry it is in hebrew):


This board reflects the status of the apartment (including the actual planned move) 4 weeks before D-Day.

In the beginning, that seemed to be enough, but lately, when the time started to be short, and every day matters, my wife and I started to have nightly sessions on the project, discussing the status and reflecting it on the board. We actually started to have “dailies” you could say, where each of us answer the three questions – what do we know was done since last time, what is planned to be done till next time, and what are the impediments. We also go through the backlog and prioritize it according to the new knowledge we have accumulated.

How will the project end? We will probably know that only in a few weeks time…

Oh, and May the 4th be with you, always (thanks Ben!)

[Reblog] Say “agile” one more time

Here is a nice blog post about Agile, and how it can be wrongly misused/misunderstood: Say “agile” one more time

you mean agile

While reading it, I thought again about the idea of Agile being old, dead, inappropriate to the current industry. Is it really? I think it really depends on what you mean by Agile. If you mean that you must follow all the Scrum artifacts and ceremonies, no matter what, then it might be good for you, but it might also be misleading you to places you don’t want to be (like in Galina’s post). If, instead, you understand agile, and any of its frameworks, as a mindset of quick feedback loops, a way to organize your teams (as opposed to chaos) and a way to help the people focus on the correct things, then probably Agile is still good for your needs.