Objective And Key Results — Do it Agile!

If I describe myself as multi-tasker, it wouldn’t be wrong. I can go for a week long continuous coding and still have the same passion… -

Objective And Key Results — Do it Agile!

If I describe myself as multi-tasker, it wouldn’t be wrong. I can go for a week long continuous coding and still have the same passion about it on Monday. But if you are a multi-tasker, it can help you to keep your brain versatile and help you not to get bored with the repetitive tasks.

The multi-tasking context was important here because last few months have been hard-pressed in terms of designing, architecting and coding stuff (no regrets, no complaints, only passion) but at the same time I have been hearing a lot about agile objectives and key results, a bunch of good articles came across with few talks and emails. I retrospected my Agile Development experience with this opportunity and tried to deduce an analogy for the new challenge — Agile Objective and Key Results (A-OKRs).

Yes, it sounds interesting, but at the same time “old”. It is old because if you search agile objectives or agile goal settings-, you will see the ton of articles on it. And all starts with describing agile methodologies, then slowly mitigates its essences in implementing objectives. At the end, it is writer’s dilemma of describing agile objectives.

Giving more context to it, being an engineer, I see, setting an objective and tracking key results is somewhat cumbersome activity and duplicates my efforts from the engineering stuff. After having a discussion with people from the engineering domains who are passionate about the stuff they do, they don’t differ much. As a matter of facts, engineers may not be good in maintaining key results if it is just a sugar candy that his/her management team (in some cases HR team) wants them to have it.

> But I would say give it a try and you will see the value. You can get the same cheered-up feeling in accomplishing the objective that you get while running your 1000 lines of code successfully in a single attempt. This post is about my slight break from the coding and sharing my personal experience that I gained in keeping track of the objectives.

Let me break down what I learned from the Agile development and how setting your personal or professional objectives can take a help from the these learnings. Let’s dig in for some prepositional topics from Agile methodologies:

Scrum — If I don’t go with Google (as you can get a lot of articles/books explaining scrum in depth), Scrum helps you to deliver a product in iterations (sprints) from cross-functional and self-organizing teams who participates in empirical feedback with demos and scrum plannings (sprint planning, daily stand-ups, review, retrospection, backlog prioritization etc-).

eXtreme Programming(XP) — As [per](http://www.extremeprogramming.org/), five essential ways to success are communication, simplicity, feedback, respect, and courage. You wouldn’t be explicitly implementing it, but you are an eXtream programmer if

1. Contributing in a collaborative environment. 2. If you are forced to take a break from your coding routine so that your customer can be happier — High Stakeholder Satisfaction 3. If you do a peer review or participate in one 4. If you get a \constructive feedback* often than never 5. You are fearless to rapid and changing requirement 6. You prefer to deliver something than deliver that perfectly 7. Test Driven Development (TDD)- The practice that I love about TDD that it prepares you for the things that you can break if your code doesn’t go right. In fact, it may make your development efforts easier you have thought the requirements through better before implementing it.

Refactoring — It is code restructuring technique in a disciplined way. But a question is, why will you do that? The code you write today is not going to support all the requirements and new standards coming to you tomorrow. Refactoring enables developers to easily evolve the code to fulfill the new requirement.

Continuous Integration — In simple words, it is the practice where you regularly integrate code with the central repository ensuring that the integrated system is functioning as expected. As it is explained very well why to have this practice in place-

> Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove. — Martin Fowler

If you are in agile development, you probably use one or more methods as described above or a modified version as per your requirements.

Now let’s talk about analogical takeaways from the agile development learning to A-OKRs —

> “DO NOT” set a long-term objective-

It’s a thumb rule! you already have your grounds covered as a long sprint can never be as successful as compare to small sprints delivering the pieces of the long sprint. Even if you need to have a year long objective, set it for quarterly, even better if you can break it for monthly.

> Set a collaborative objective over individual objectives-

If it is not self-learning objective or objective related to developing a skill, set it as a team objective. Points —

1. Visibility and easily accessible by your team members 2. As it is a public objective, you can request for 360 feedback (VERY important) at any time. 3. Like scrum planning, you can invite your peers for your objective setting and discuss it with the team before setting it. 4. Don’t just swallow your success/achievements on your objective just by yourself, share the experience with the team, can be a small note on your key results (metrics) or even better if you can share it over a meeting. Think about it as your sprint end demo for deliverables! 5. Always retrospect your objective before closing it and there is nothing better if retrospection is done with the team (contributing peers).

> Participate in constructive feedback for your OKRs and team’s OKRs

Feedback is really important to achieve your objective successfully and make it as a practice. The focus is given to constructive (it doesn’t mean that you are not supposed to give negative feedback) feedback because it is very important if you receive a feedback, translate it to a constructive version. So you need to ask questions if there are unknowns in the feedback and while providing a feedback, leave no unknowns known to you. For e.g. instead of saying, “Your communication skills are good”, provide it as “You demonstrate a high degree of confidence while providing onboarding process to customers”.

> Very important- Quantifiable, Measurable key results (metrics)

Once you have an aspirational objective, you set your key results to measure the progress of your objective. With the measurable key results, you get tangible evidence that you add up in accomplishing your objectives.

> Revisit your objectives regularly

As you don’t refactor your objective once it is set, but revisiting your objective where you are in terms of progress and key results, it’s very important. The revisiting process warrants you to red flag if someone else is aligned to your objectives or cascade it down as an alarm if you are dependent on someone else objective.

> Continuous updates to your key results

Don’t wait for your hourglass to run out of the sand and then do an update. If you have an update, reflect it in your objective, it helps you to estimate the effort left in achieving the rest of the progress.

> Knowledge Driven Objective and Fearless key results

There is no one but you, who knows the correct water level of your knowledge. Use the knowledge to set an objective with fearless key results that are achievable and at the same time, challenge your limits. With these challenges, you can curate your knowledge if there are certain skills need to be acquainted.

> Automate your key results updates

I follow DRY (Don’t Repeat Yourself) aggressively and make sure to automate it if I have to attempt any process the second time. The same analogy is applicable to the key results if updating the key results is a duplicated effort as it is already being captured in your sprint projects then Automate it! With the use of APIs or Automation methods provided by objectives setting platform, you can easily reflect your progress done on your projects to your key results.

Feel free to add more as per your learning from the agile development experience to your objectives as a comment to this post.

Back to coding… :)