Several weeks ago, Josef (pseudonym), a dad from my son’s school contacted me and sent me a link to this article: “A Before-School Exercise Program May Help Children Thrive”.After reading the article, I talked to Josef and agreed with him that I will take it with the principle and carry it forward.

The next morning, I talked to the principle Oren (pseudonym). I requested to arrange a pilot - MVP - of a sports activity for about 30 minutes. Oren was enthusiastic about the idea. Due to the school’s busy schedule, we planned the activity for the following week.

Add a comment

Have you ever thought what Marathon Running and Product Development have in common?

I started my software development career in 1998 as a developer and along the way I fulfilled various other roles such as R&D team leader, project manager and product manager.

I started training as a long-distance runner in mid-2014 and run my first Marathon in October 2015.

There are several posts comparing product development to a marathon. Clearly, both are not simple tasks.

In this post, I would like to share from my personal software development and long distance running experiences aspects Marathon running and Agile Product development. 

1. Support systems

When getting ready for a marathon, one must get his/her support systems in place. Fore example, match your nutrition with your training plan.

In product development, it is recommended that the organization has upper management buy-in, CI system in place, test automation capabilities and well-defined DoD.

2. Expand your skills

Great athletes train in an additional one or two types of sports every week such as bicycling, strength training, rowing, cross training, swimming or elliptical training helps building core muscles such as abdominal and back muscles as well as hamstring, biceps, triceps muscles etc. 

Agile product development is based on technical excellence. Developers has to expand their skill sets as well as develop their core skills.

Add a comment

Unlike most of my blog posts, this one is not an opinion or some deeper insight or analysis.
It is a description of the result of an evolution of a workshop Ilan Kirschenbaum and i developed that is called a "Retrospective retreat"
The Retrospective retreat is a workshop that is very similar to code\coach retreat in which it is targeted at creating deliberate learning through repetitive practicing  of the Retrospective.

Add a comment

When I was a child I had an operation on my shoulder. It was a scheduled operation, nothing urgent. And it left me with an ugly scar on my back. Today, it’s still very notable after all those years. Also still painful during season changes.

Roll the clock forward some 40 years, my youngest son had an operation right after birth. He was in a critical condition, and, in order to save his life, the main artery and vein in his neck were bypassed to connect him to an infant life support machine (ECMO). Despite the urgency and complexity, his scar is hardly noticeable. Despite his slim chances of survival, doctors treated him in both operations - connecting and disconnecting from ECMO - such that everything, cosmetic side effects included, will be as professional as they possibly can.

What makes the difference between a top notch surgical unit to a mediocre to a poor one?

What makes the difference between a top notch software team to a mediocre to a poor one?

The books "Better" and "The Checklist Manifesto" by Atul Gawande give us a peek into the characteristics that differentiate a mediocre surgeon practice from a better-and-always-improving one.

The resemblance between a medical team and a software team is so strikingly similar, that I collected ten practices from the Operation Room (OR) that software teams would be wise to adopt. 

Add a comment


We have a bug in our industry: We over glorify bugs. We love them so much, that we use them as a primary metric for quality.

My take is that that is a bad idea. Bad, as in driving undesired behaviors that are misaligned with our desires to improve quality.

Let’s begin with an analogy, and then move to modeling this on software.

A tale of two restaurants

Joe was hungry. He was on a business trip, and it was lunchtime, and he just entered Bologna, an Italian restaurant.

It took almost 3 minutes before a host led him to a table, which was set up simply, yet invitingly. There were some loud voices from the kitchen, and Joe wondered what they are arguing about. When the waitress came back he ordered a pizza, which he noticed was recommended in reviews on TripAdvisor. While he was waiting for his order, he saw the staff going around customers - acting nice, but not overly nice, smiling from time to time, but not overly eager.

Add a comment