Recently, when I was thinking about the priorities of a project I’m working on, I used as a source of inspiration the Maslow’s hierarchy of needs. This hierarchy is usually depicted as a pyramid, as you can see in the image below. According to this theory, human beings have some basic needs that must be addressed before anything else. I believe that this is true also in the case of a project: we must be able to identify which requirements are absolutely necessary, and which ones may wait until the basic needs were satisfied.
Last week KashKlik presented at the Demo Day, the event that concludes TheHive accelerator by Gvahim. There were more than a hundred people in the audience, including a panel of investors that judged the startups that participated at TheHive together with us.
KashKlik team during the event (from left to right): Ariel, Jacob, Galina and Hayim.
Below is the video of my pitch, followed by questions from the panel (in English):
From TheHive’s site:
TheHive was created in 2011 as the entrepreneurial branch of Gvahim, a nonprofit organization aiming at providing new immigrants with the tools to succeed in the Israeli labour market. Alongside Gvahim’s career programs open to a wide range of sectors, and special channels dedicated to medical professions and software engineers, TheHive responds to a specific tendency among new immigrants, who are more prone to launch into entrepreneurial adventure than the average population.
The accelerator is a multinational entrepreneurial environment where Olim, returning citizens and Israeli entrepreneurs all operate in a shared working space, with a wide mix of talents and ideas, to create a truly international atmosphere.
The 5-month Start-up accelerator program includes:
- A community of international entrepreneurs who learn from, motivate and support each other.
- Participation in the Google Launchpad: a one-week bootcamp at the Google Campus in Tel Aviv.
- Access to capital: Connections to top investment firms, VCs and angels.
- Top-tier mentors.
- Office space in a creative co-working space in its two centers: Tel Aviv University and Ashdod.
- Training, networking and office hours with experts.
In decision-making, we try as much as we can to impact future results based on our previous experience. But every decision is also based on the assumption that its positive consequences will be greater than any possible negative outcome. Therefore, we should treat decisions as experiments. We should always preserve the option of reconsidering our decisions in the future, when we will be able to measure their real impact.
When making decisions, we should also prepare the tools and mechanisms that will allow us to collect feedback and evaluate the obtained results. In the methodology of Agile software development there are several such tools, including Burndown charts and Velocity charts. These charts help us measure the progress in the delivery of new features, providing immediate feedback that indicates if the execution is according to our plans.
Another fundamental concept in Agile methodologies are the Retrospectives. They are a planned opportunity for teams to analyze their own performance and discuss if there is any need to change the current processes. Thus we never assume that we are already following the most effective process and nothing needs to be changed. An integral part of the Agile mindset is the focus on continuous improvement, always looking for opportunities to deliver better results.
For example, a software development team may decide to adopt Test-Driven Development (TDD). The expected results may include improved quality and better design. But this decision should be considered an experiment. After some period of time, the team should verify if indeed TDD is having the intended consequences, and if there is no drastic negative impact such as a big increase on the time required to develop and deploy new features.
By treating decisions as experiments, and by having the tools to measure their results, we can be sure we are making progress in the right direction.
Most people look for ways to increase their productivity. Many of them believe that they will be more productive by handling several tasks simultaneously, what is known as “multitasking”. But this is actually a trap! By trying to perform many tasks in parallel we just lose our focus and reduce the quality of our work. To be more productive we should actually avoid multitasking!
Posted in Efficacy
Today lots of people complain about being always connected to work. A recent study shows that:
- 45 percent of workers feel obligated to respond to emails after hours.
- 42 percent of employees feel obligated to check in with work while on vacation.
- 47 percent feel guilty if they don’t work when sick, either on site or from home.
This situation certainly has many disadvantages, including the increase in work-related stress and the reduction of leisure time people spend with their family and friends. However I think each person has also the opportunity to enjoy the advantages of being always connected and able to work from anywhere.
The extreme example are the Digital Nomads, people who travel while they continue to work with clients or employers. They are able to visit new places and learn about other cultures and lifestyles, as if they were tourists, while at the same time they continue working remotely an making money.
But it is also possible to be a Digital Nomad part of our time. In the same way that we can travel for a business-related conference and enjoy our free time for tourism, we can travel mostly for tourism and enjoy some of our time to do work, without feeling guilty.
It may be very nice also to work near our home instead of working from home. We can work from places that inspire us, such as a beach, a park, a restaurant with a nice view or even a beautiful library. Such changes in environment probably have a positive impact in our creativity.
So I suggest this as a new-year-resolution for 2018: instead of complaining about being always connected to work, let’s find new ways to feel better while working remotely.
Happy New Year!
Posted in Efficacy
Software developers are constantly told that they should avoid Technical Debt. But very frequently it is difficult to resist the temptation. Why not implement a good-enough temporary solution that satisfies all the functional requirements? The main problem is that very often this solution ignores completely the non-functional requirements. It is not efficient, nor robust, nor maintainable, nor scalable. I think this problem may be very nicely illustrated with the pictures below.
1) Functional requirement:
The dashboard must have a knob to control the air-conditioning.
2) Functional requirement:
The back-window must have a wiper.
3) Functional requirement:
The door must have a lock.
4) Functional requirement:
The car must have a side-mirror.
5) Functional requirement:
The car must have four tires.
Sometimes I find some amazing content on the Web which I want to share with all the readers of my blog. The picture below was created by Anna Vital, and I think it presents in a very concise form some amazing bits of wisdom. It reminds us the importance of our attitude when dealing with challenges. Enjoy!
Posted in Efficacy