KashKlik Pitch at TheHive Demo Day

DemoDayLast 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

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.

 

Posted in KashKlik, Startups | Tagged , | Leave a comment

Everything is an experiment: on decisions and retrospectives

DecisionsIn 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.

Posted in Agile, Efficacy, Software Quality | Tagged , , | 1 Comment

To Increase Productivity, Avoid Multitasking

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!

Multitasking

Posted in Efficacy | Tagged | 1 Comment

Digital Nomads: The Upside of Being Always Connected and Working from Anywhere

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!

20171219_134353

Posted in Efficacy | Tagged | Leave a comment

Temporary Solutions: Technical Debt in Pictures

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.

Car Dashboard1) Functional requirement:

The dashboard must have a knob to control the air-conditioning.

 

 

 

car window cleaner2) Functional requirement:

The back-window must have a wiper.

 

 

 

lock3) Functional requirement:

The door must have a lock.

 

 

 

mirror4) Functional requirement:

The car must have a side-mirror.

 

 

 

 

tire5) Functional requirement:

The car must have four tires.

Posted in Requirements Specification, Software Quality, Technical Debt | Tagged , , | 1 Comment

Sharing Some Bits of Wisdom

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!

tips

Posted in Efficacy | Tagged | Leave a comment

Hilarious: the Disasters Caused by Emergent Design in Practice

Several people in the Agile community believe in Emergent Design. But I think that it has caused many disasters in software development projects. See below some hilarious pictures of Emergent Design in practice, with fictional conversations illustrating the kind of thinking that generated them…

stairs1) Commenting-Out

PM: Look, the requirements were changed, we will have to modify these stairs.

Dev: It will be too difficult to modify them, I will simply write new ones.

PM: So will you delete the previous ones?

Dev: No need to delete, I will comment them out, they may be useful in the future.

up and down2) Connecting Modules

PM: You designed the stairs between floors, but you did not design the connection between stairs.

Dev: This should not be a problem, after having the stairs it is very easy to connect between them.

 

components

3) Adding New Features

PM: There is a very wide space here, I think we should add some benches.

Dev: No problem, benches are very modular, I can easily plug them here.

 

 

flow4) Emergent Design

PM: You have designed the floors, but you did not design the stairs connecting them.

Dev: Don’t worry, after we have the floors it is very easy to add the stairs.

 

 

 

 

angular5) Partial Requirements

PM: Sincerely, I am not sure that the system you implemented is what the customer expected…

Dev: You can check the requirements, our system satisfies perfectly all the customer requirements.

 

 

 

 

responsive6) Choosing a Platform

PM: Ideally this system should be built on top of a land-based platform.

Dev: Land is too expensive, I suggest we use old tires instead.

PM: Are you sure that old tires would be a good technology choice for this project?

Dev: No doubt, old tires are cheap, very modular and can be combined in multiple ways.

interface7) Cross-Cutting Concerns

PM: I see in your design that there is some coupling between the building columns and the passage.

Dev: This should not be a concern, both can perform their function despite this small coupling.

Posted in Agile, Software Architecture | Tagged , | 7 Comments