The biggest problem for an engineering team is when you don’t have problems

Team with a Goal

“If your team is not coming up with problems, it’s a bigger problem.” When Rajeev Nair first uttered these words, it took a moment for me to fathom what he meant. I didn’t say much then, but it explains how we look at engineering in GO-JEK.

The notion that everything runs as per protocol is what kills the joy of coding. As a team, we’re wired to create more problems and solve. Any successful team needs to be opinionated; creative differences is what makes us push harder and think deeper. Accepting these myriad of problems and trying to solve for them means your team is far more confident to confront, question and think what’s best for the customer.

We started with a team of 4 developers and 1 Product Manager. Now we have a team of 22 including designers, Quality Analysts (QA), developers and product managers. And we’re still growing! We work in the ‘Driver Platform’ team and individually, we’ve embraced failure, but as a team, we’re winning every day. The team has now embraced this simple axiom:

If I fail more than you, I win…

We decided to speak more of our problems. It’s easier to sometimes pen it down if you’re hesitant to speak. We all wrote it down, grouped it into areas and discussed. And importantly, we started solving:

1. We moved to Kanban with a set of Scrum rules.
2. No Sprints.
3. Dev Huddle before picking up stories. Product Manager, Dev and QA should be the part of this process.
4. Desk Check every story before sending it for QA.
5. Not picking a new new task till we complete the whole life cycle of a story from TO-DO to DONE
6. Having a Code Freeze and Definite Releases for apps.
7. Saving repetitive QA tasks by concentrating on Automation. Oh, and I can confidently say we’re doing some truly cutting-edge kick ass work here.
8. Last but not the least, taking end-to-end ownership of a task and stories.

How has this helped?

1. Moving from Scrum to Kanban board helped us measure bottlenecks in a process. We added the maximum story limit for a column. If any column gets blocked, it turns Red. These visual cues helped the team get more efficient and push out stories before picking a new task.
2. Sprints are a rush to do the work without figuring out the quality of the output. Now, we allocate the work every week and understand business context before prioritising what needs to be done.
3. Before starting development, the manager, QA and developer sits together and kicks off the story to understand the flow. This helps the team apportion time and better understand workflow.
4. In the desk check, both the PM and Designer validates stories to see if the business criteria has been met and design is impeccable. Only after this check the stories are sent for QA.
5. Having code freeze and definite release dates helped the team plan and manage work on the QA side. The QA team can now work far more efficiently as code freeze prevents any new code to be added on the builds after testing is done. Declaring release dates helps other teams plan accordingly.
6. Automating UI and API testing will help the team to deliver faster as the time for doing a Full Cycle Test can be saved.
7. Owning end-to-end story flows helped the team perform better. Switching context while working, slows down the team. Hence, completing one task and then picking up afresh is always productive.

To sum it all up, collectively, we’re pushed to question. Creating more problems is what defines good engineering. We’re always trying to fish out a problem and discuss as a team. Our flat hierarchical structure allows us to be inquisitive and fail making GO-JEK a great place to write code.

Oh, and one last thing. We’re hiring! For any roles in Engineering, Design or Product Management, or anything at all, visit www.gojek.jobs