Introduction

SEEKAsia has introduced OKR during MM2016, it has replaced the measurement we used to have such as company metric, product success metric, team performance/improvement metric or even individual growth plan. Frankly to say, do you able to tell that you are 100% understand what is OKR? What it tries to achieve? I need to be honest with you, I do not know the answer at the very beginning.

So what is OKR?

OKR stands for Objectives and Key Results. The objectives are the direction or goal we want to achieve and heading towards. The objectives should be aiming high and difficult to achieve and push you out of your comfort zone as you may say as a stretch goal.

According to Stretch goals definition, you need to stretch yourself beyond what your mind might think is safe. You are said to be successful if you can achieve 60% to 70% of your goals. On the other hand, if you are able to achieve 100% of the target then it means that your goals weren’t ambitious enough. You didn’t really stretch yourself.

Key results are the measurement to measure your progress toward the goal. This is the how you will get there. Let me share in a more simple way for you to understand.

From the picture, the objective is to reach New York from London, so the key activity is to buy boat and sail x days to the west to reach New York. The question now is how you know you sail and reach New York? The answer is you need a compass to know your current location and destination location to make the adjustment to sail west in right direction. This compass is the key results. Key results tell you how close you are to the destination and align you to the right direction. OKR without key results is not OKR!

This example shared from here. Recommended to watch it.

Chapter 1 - Begin the journey of OKR

In the early day when the MAGIC team looks into DELIVERY OKR – increase # of deployment by 100% (in another word, make your # of deployment X 2), we have tried few methods to achieve this.

• Method: Practice hotfix branch to replace normal branching deployment
• Benefit: Reduce duplication test in Dev, Qa, Stage servers, cut 3 same testing to become 1 will help to speed up the time to deliver the feature to market.
• Detail(How): Engineers will need to branch out from master branch, write their code for the required functionality to meet the acceptance criteria and go thru pull request before merge to master, create a tag and deploy to live.

With this practice, we started to surface up few problems

Challenge #1 – dependency on story/solution

When multiple engineers work on the same feature/story, we created a different branch to make our changes but this eventually causing engineers to wait for each other solution to merge. When merging, engineers need to resolve conflict and optimize code before self-testing the whole feature working as expect or not. After verified by engineers on the functionality, engineers will release to staging test. By this experience, this increases the communication between engineers to sync up the solution, dependency on each other and waiting time which delay testing and deployment.

Challenge #2 - single test environment shared by all engineers.

Another problem surface up pretty obvious was when multiple branches ready for testing, staging only able to test one by one or branch by branch and not multiple engineers test separately at the same time. This causing waiting time and in sequence to test each story.

Challenge #3 – essence of OKR

Finally, the biggest problem of all, team practice all the new practices for a period of time but the essence of OKR seem to be forgotten. It’s become usual practice without trying to improve further or aware any potential to improve. This is a signed team just know OKR but not the real OKR purpose.

Chapter 2 - Starting the gear

When we change our way to get some result, doing 1 thing is not enough, you will face problems or challenges, and it’s ok, that means you are on the path of changing. So, we – the Magic team start to look into what is the challenges we need to overcome after the 1st change.

Great! We moved fast and aware what the problems along the way, so we retro it out and discuss for improvement on these issues.

Challenge #1 – dependency on story/solution

The first issue for dependency on branches, we started to slice story to be more independent with mostly INVEST model. By slice down to small story without any dependency, the code will be smaller, fast to test and deploy.

Challenge #2 – single test environment shared by all engineers

The second issue for the bottleneck in the staging environment, by slicing story to smaller, the testing period will be shorter and fast to release to others. Team also encouraged to use local vagrant to switch branch to test out which help on testing multiple stories by multiple engineers at the same time.

Challenge #3 – essence of OKR

Finally, the biggest and challenging issue is to get engineers to fully understand OKR by refreshing this topic with the team. There is a session to go to again for the team to refresh how and why OKR important. By that session, team took this opportunity to refresh again and set for next quarter to improve from previous quarter

Chapter 3 - The OKR

Continuous process of improvement, new tool new practice, let’s continue to do something different.

By new quarter, new hope, new start, team go back to zero and started on by going thru WHY, WHAT, HOW for OKR and dive in to set for brand new Q4 OKR. By the end of the session, there is a better clear picture on OKR and hooihooi - our ADL helped to draw this picture to elaborate from top to bottom and bottom to up for the company.

1st OKR – One-time pass

By introducing this one-time-pass, we want to ensure story cards move from TODO - DEVELOP - TESTING - REVIEW - DONE in 1 time. Meaning this story moves from developing to testing and straight to deploy without back and forth from testing to develop where most of the time are bugs found from engineers. This would required engineers to fix it and retest again which is not efficient.

Key Result: # of bugs per sprint where we set max 3 bugs allowed.

Activities:

• Shift left testing by practice pairing and BDD in the early stage to create a shared understanding of the product requirement among PO, engineer and test engineers. Missing or misunderstand requirement is frequent issues happen in the team.

2nd OKR - minimum 5 story per sprint

The idea for this is we want to ensure our team to deliver values as fast as possible and by doing this, we ensured slicing down the story to be smaller with values so we can learn early and improve on it. Previously there a lot of tasks or spike which not really deliver any values to users and by practicing this, we know we need to deliver value to the user each sprint.

Key Result: # of story with DOD deployed in each sprint = Min 5

Activities:

• DoD of the story: ready for deploy / deployed to production

• Practice INVEST model to write a better story with the title, description (feature/benefit), acceptance criteria.

• Start Story Mapping practice – to provide everyone the big picture & easy for collaborate

• Practice discuss the user story with big picture, system flow and have a quick walkthrough on the UI of the system

3rd OKR – short-lived branch

This is a practice where the moment you create the branch, within 4 days, this branch need to delete or close. This objective is to help the team to deliver fast which eventually triggers engineers to think how we able to achieve this by practicing smaller story and facilitated branch to test and deploy to production.

Key Result: life span of branch = Max 4 days

Activities:

• Derived from the activities in 1st and 2nd OKR and trigger team member try to find any other method to complete the user story within the 4 days life span of a branch. However, after tried for some time, we found out that there is an area improvement for this key result - life span of branch = Max 4 days. As from Todo-Prepare-Develop-Testing-Review-Done column, the team member can only start to create the branch when in Develop column, from developing column till Done column if take 4 days it still meets the key result but the story not delivers fast when adding on the preparation task at prepare column.

Chapter 4 - Counting, counting, counting…Where are we now?

So the next work to complete was how we count # of deployment. Is every deployment from Jenkins we count it or how?

Back to the purpose of # of deployment, we want to improve the way we working daily and by this meaning, anything 1 off work, we will not count it because it does not help on or improve the way we work. For example, bug fixing, L1-L5 issue, manual configure server or manual deploy code to the server, all this do not help the way we work daily which not proudly to said we improve our # of deployment. Manual configuration not really achieve the purpose of this OKR. We set it very strictly to count what matter and the essence of having # of deployment as OKR.

Chapter 5 - So what’s next?

Great! FY18 Q1 started and MAGIC will retro how we can improve further where we do not achieve fully on # of deployment. This retro probably to refresh up and start again how we can improve together and what we can do better. Probably also to get new OKR setting down and team bottom up to align to company new direction.

Wait… Near the end of the story but I need to share what I experience and questions to ask.

Chapter 6 - Finale

I have facilitated on OKR to teams in Penang and there are common questions asked that probably you can share your opinion on it.

• What the different between OKR vs KPI in SEEK Asia?
• How about duplication in Personal KPI and OKR?

From what I shared with all the teams, OKR should not be used for performance reviews where you do not want set stretch goal on personal OKR and not able to achieve it will impact on your year-end performance reviews. This will create side effect where no one willing to aim high because when you fail, it’s hurt. While we promote OKR as a tool to continuous improvement, collaborate among all the teams to improve business as a whole, should we also revisit the KPI performance measurement now which is more individual accountability and anchors the attention on the job description?

Let get this questions and feedback on OKR slack channel to discuss.