How We Work in Gizra

It’s been almost two years since I joined Gizra. At the beginning – as always when you start a new job – I was not sure what to expect and was a little bit afraid. And my first day did not go really well. Let me tell you a little story about it.

We were in the middle of the summer when I accepted the job, and we decided the week when I would start. Moving a couple weeks into the future, it was the Sunday before the day I would start early in the morning, on my way to a remote beach when I got a message from Gizra about when we could have a kick off call that morning. That is when it hit me: in Israel, the week starts on Sunday, not Monday! I just had a few minutes to send an email saying I could not work that day before losing all the signal on my phone for the next five or six hours.

The first thing I thought was: this might be the stupidest way to lose a job. The next one was: if tomorrow I still have a job, this is going to be an interesting ride, full of bumps on the road. I was one of the first distributed workers of the company and that was just the first thing we had to learn when working with people so diverse.

Learning the Gizra Way

Before starting, I spent most of my spare time getting prepared, studying the technologies used by the company, reading the blog, and that’s how I got to “The Gizra Way” website. I’ve heard about “The Gizra Way” before, but for me it was just marketing speech, a way to bring attention to what the company does and how it does it. But I did not know what that meant on the daily basis or if it even had a real meaning with value.

So I read the Gizra Way website hoping to figure out this thing. It did not help. Well, don’t get me wrong, it actually helped me a lot. I learned about the company, its origins, how they work, and much more. But it did not answer my question: What the heck is the Gizra Way?

Fast forward more than a year later. I had a meeting with Rachel, who is in charge of the Business Development and Strategy. She was interviewing different people in the company and she told me she thought I understood really well what was The Gizra Way and asked me to explain it. My answer: I still did not really know what were we talking about.

Now, a year later, here I am, writing about it. Because now I think I know what is The Gizra Way. Even if it might be my own perception of what it is, it is really simple: it’s how we work in Gizra. But, as this is just my opinion, I do not want to write this from only my point of view, as it might be different from all the other people in the company. So, I asked other people from the company in different roles to tell me how do they apply The Gizra Way to their daily jobs. I did not ask them what is The Gizra Way, because I believe no one really knows.

The People

Rachel does Business strategy and development. Or in other words, she evaluates our workflows and tries to find ways to improve our processes, between us and between the client and the team. Gizra is a ~20 people company and there is a person fully dedicated to find ways on how we work.

Use value driven googles in everything I do - like the blog about how we decide what to develop, it is the same with every process I decide to invest.

In her job, Rachel focuses in what gives real value to the client or to the team. Sometimes, this means telling the client “you should not develop that.” She also helps us improve how we work or how to make smaller the distances between the people who are distributed around the world. Sometimes, we just stop doing something because the value we receive is not worth it with the time we invest. She asks herself if there is really room to improve the workflow, that her time invested on working the workflow will result in time saved and better used for Gizra.

Amitai, as CTO, makes sure the development level stays as high as possible. In his daily job, when not visiting clients or talking on conferences, he has calls with the different members of the team going over existing issues and trying to find the best way to solve them.

I try to get people out of their comfort zone, and push them a bit to better solutions - “There must be a better way”, and “what’s the essence” as our guidelines.

He always keeps an eye on what we do and how we do it. You never know when he is going to jump into an issue and ask you to change everything. He forces us to give our best and try to improve.

Liat is the UX/UI specialist. She defines requirements with the clients and makes sure we are thinking (also) about the user while implementing.

Recommend the client to develop only what is necessary and to give up features that do not serve business goals.

Again, we come to the same point: always evaluate what the client really needs. Keep it simple. Also, do not forget the user and what gives value to them.

Noam is one of the Project Managers or as we call them, account managers. He transforms a client’s desires into a definition of the real needs and budget and translates it to a productive communication with Gizra’s team.

Timebox == Budget

Here, in Gizra we work with a system we call “Time boxing.” Every issue is given a time box. It is similar to an estimation, but not exactly the same. An estimation usually means, this issue is expected to be done in this time. Well, how often does this happen? Estimations fail. A lot.

Time boxes is not when it should be done. It’s thinking in a different way. If I’m half way on the time box and this issue is not nearly done… What is wrong? It is a moment to raise your hand and let the account manager know what is going on. Sometimes, this means: stop working on this, because we will waste the client’s money. Other times it’s, let’s talk with the team lead or other developer, and’s discuss how we can implement it. Sometimes it means increasing the time box because something we did not expect, appeared.

Noam also tries to push the clients to interact more in GitHub with us. This means fast feedback when needed and a transparent workflow, as the client will see what the developers are doing and will be part of the development process.

Efrat is the Executive director. She manages the company.

When everything is on fire, always find the essence and deal with it first

Efrat is the person that faces the crisis situations, when everything is tangled. And for her, the way to untangle it is to analyze the current situation, break it into pieces, and then handle the most valuable/critical part first. It might feel wrong to “neglect” parts of the problem; but in her experience, it’s the other way around.

Aron is one of our developers and also a team lead. A team lead is the person who leads a project from the technological perspective, while the account manager leads it from a business/client perspective.

Developers tend to overvalue individual achievement, but external help can speed up the things significantly and can lead to a better result

Again, Aron talks about how time boxing helps his work. It avoids sitting in a problem for too long. If he is stuck, due to the time boxing, either it forces him to reach a solution via thinking out of the box, or forces him to ask for help.

Orit is in charge of the human resources and she is the operations director.

Always try to do things better, learn from the mistakes and share with the colleagues the lessons learnt

She always tries to do things better, learn from her mistakes, and share with the colleagues the lessons learnt, if she can. She tries to keep it real by being upfront and transparent.

Did you see any similarities between their different approaches to their daily work? I found some:

Focus on Value

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 1st principle of the Agile Manifesto

Transparency

Business people and developers must work together daily throughout the project. 4th principle

Communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 6th principle

Timeboxes

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 8th principle

Leaving the Comfort Zone

Continuous attention to technical excellence and good design enhances agility. 9th principle

Simplicity

Simplicity–the art of maximizing the amount of work not done–is essential. 10th principle

Question What You Do

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 12th principle

Conclusion

It is quite common for people to confuse Scrum, Lean, Kanban or other specific organizational frameworks with Agile. Agile is a simple manifesto and twelve principles. Scrum and the others are frameworks that originally come from the Agile Manifesto, but it is easy to forget those principles and that will cause teams to fail in the same way we use to do when we were using waterfall development.

But when those principles are core to your company values, it does not matter what tool do you follow, you will be truly agile.