Fast and Agile Development Tips from a CTO

1-on-1 with Wanari’s server-side CTO

Part Two

What and how can a CTO do to achieve his team’s maximum efficiency? This is what I had set out to uncover when interviewing Wanari‘s CTO, a software engineer with 12 years of experience, Norbert Farkas or as he is lovingly called by his colleagues, Pókmalac*.

This is part two of a two-part series (because it’s an in-depth interview and I think it’s easier to digest all the advice not all at once). If you haven’t read Part 1, it’s more about where Norbi comes from and what he does to keep his team in sync with the larger picture of the entire company. So, if you haven’t read Part 1, you can do so here.

Now without further ado, let’s dive in!

Me: What sort of processes have you put in place to get things done fast?

The surprising thing about me is that I haven’t put any processes in place here. It has always been my team and I, that came up with the greatest ideas that has helped us a lot to be where we are right now. When we face challenges we talk about it as a team, we find solutions as a team. We put together a detailed process as a team that we will follow thereafter. I have seen how, when people get involved, they go one step further to stick to working processes. When they were a part of the decision making process, new processes always work better. All the processes we have are agile or lean and they probably aren’t a lot different than that of other companies. What makes them faster, I believe, is the commitment the whole team has towards making things happen.

One exercise I always try to do with my team is to look back on what we did. You might see us doing that at least once a month. So it is very easy for us to start a new process because we decide on it together. Of course I find the rebellions in my team too but I look at it very positively because it strengthens the process covering the gaps of any possible loophole.

I have tremendous faith in the skills of my team. (The Ed: copyright @realdonaldjtrump) No doubt they are fast coders. I suppose what might take more time for us as a team is the preparation rather than the actual coding itself. The understanding of the requirements from the client makes a huge difference when it comes to the timeline for delivery. We’ve noticed often that my team thinks of possible challenges of the project architecture during our preparation meetings. So at the preparation stage you might see the project scope/features/requirements going back and forth between my team and the client. We put an emphasis on this because we’d rather code a great feature once than have to re-code many times over until it becomes great. By the way this doesn’t happen with all the clients but we do spend a lot of time on preparing ourselves before we actually start coding. We do have some very technical customers and some not so much, but that is where our preparation exercises help.

Preparation starts with the planning of architecture. Thereafter, I sit together with the team and ask them to decide which area they feel they would like to work on. Again, I am not the sole decision maker. I create the issues and the team decides who does what. We decide on the sprints and we go ahead and work together as a team to achieve our goal. I have never pulled out one single person when something didn’t go as planned, it’s rather the team that is to answer. I give a lot of effort to holding regular sprint retrospectives, which has certainly helped us a lot to achieve great things with this mindset. The takeaway here is to make things happen as a team.

CTO giving an interview – unusual sight! 🙂

Me: We sometimes co-develop with software houses just like us, with your experience working with them: how does Wanari stand out when it comes to timely delivery of projects?

In one single word, empowerment. We have a very flat organisation here. I have seen the decision making process take a long period in other organisations. This affects the project timeline, especially when it comes to the planning period of the project. Everyone here is empowered to make decisions on their own. We hardly have any control mechanisms here; just a bunch of processes that seem to constantly validates our empowerment.

When gaps in the decision making process pops up my team immediately clarifies: up to which limit can we make decisions on our own; and when do we need to consult a senior or our supervisor. A lot of these questions are being answered at our sprint retrospectives. We have a very good understanding of what we are capable of and about our time management skills. I honestly cannot remember a recent occasion when we were not able to be one step ahead of the client’s deadline.

Me: How do you feel about being good at timely delivery and still being agile?

Agile makes it all better. We spend a lot of time preparing for the sprint with the client and that is what makes things faster. We haven’t faced challenges when an issue in a sprint had completely changed after reviewing it with the client. That is because there was a lot of preparation with the customer before the sprint begun.

Though there have been instances when money took over the client’s interest of being agile, but now we are in the position of choosing who and what we work with. That’s why at Wanari we are proud to say “We build software we would use. And we are picky.” meaning that our quality standards don’t allow for a product that crashes or even one that has code that breaks if you add a line. This allows us to give a warranty with every project. If it has an issue, you can come back and we will fix it for free.

Me: Has there been any challenges down the road you have learnt a great deal from?

If a deadline is approaching us before we have anticipated, then that is where the magic begins. We drop meetings and retrospectives immediately. We put as many issues as we can into one bigger sprint. Once we have achieved the deadline we will carry out the final retrospective and brainstorm what we need to do right the next time. We sometimes might have to decline any incoming requests if we feel we are battling with time. If and when it happens, then our PMs are one step ahead of us to make sure the client is aware of what is more important to develop within the scheduled period of time. After the challenges we faced in the past, we have realized; understanding the full scope of the project from the client and getting them involved from the very early stage is what makes things smoother and faster afterall.

Me: What is the one advice you can give to a CTO who might be battling with time & client deadlines?

Don’t code too early! It is the biggest lesson I have learned after all these years working at Wanari and for various types of clients/projects.

All in all

I hope this interview is at least as beneficial to you, as it was for me. If you wish to know more about our people, check out our Wanari Highlights hashtag on Facebook. If you are interested in the services we provide, please don’t hesitate to get in touch with me directly. Last, but not least, please share your thoughts in the comments, any and all feedback is appreciated!

Yours, Ron

member photo

Ron is a seasoned executive who now helps Wanari clients make practical and beneficial, business-transforming decisions.

Latest post by David Ron

Fast and Agile Development Tips from a CTO