Setting Objectives in Agile Environment

Traditionally, Objectives are/were set based on the role of the individual defined by the Company/Job.

While some individuals can be rigid with their roles — say QA Manager or UI designer, the scope of the tasks are bound to change with agility and being nimble becoming the new normal. In startups, the roles of the individuals are, at best blurred, if not totally absent. The tasks can cross the roles, a QA Manager can become an customer support engineer, UI designer can become UI engineer.

The changes creep in from different venues:

  • Company shifts the product direction
  • Employee Attrition
  • New Opportunity in Sales (including chasing unicorns)
  • Crisis situation at a customer place — Fire fighting
  • Over-committing to a pushy customer
  • Individual expanding the scope — signal vs noise
  • Mis-estimated Features — Hitting Icebergs

Then, does it really make sense to set-up Objectives? the Objectives that are set today become obsolete the next day, if not within the next hour.

Besides, Objective setting can be a tiresome process, almost giving a feeling that, the time spent on setting the objectives, could be better spent on executing those tasks.

If we avoid setting Objectives, the team can lose focus on what it really set out do and setting objectives that are never met can affect the morale of the team.

— — — — — — — — — —

A Company, will inadvertently have — Management and Team! (comprising of 1+ humans with perception abilities). Management measures the success by the commitments met and individuals measure the success based on the accomplishments in successfully executing a task, learning or perfecting a skill.

In the long run (which is usually 2 or 3 months in a startup), not tasting the success or being aware of what has really been achieved amidst the changing priorities can lead to an frustrating impasse between the management and individuals.

Management points out that tasks are never delivered on-time.

The team blames the management for changing the task priorities.

Management claims, that it thought that the team can handle it, and if it couldn’t it should have pointed out earlier.

Team frets, it expected that the management knew the tasks that were at hand and how much time it took, it left the prioritization to the management.

And so on..

— — — — — — — — — —

Transparency is the key to accountability, and accountability helps people focus on doing the right thing. The objective setting and changing of them needs to be made transparent and accountable.

One way to do this is to put the objectives into the 80–20–0 category rule:

  • 80% planned objectives,
  • 20% learning objectives and
  • 0% impromptu objectives, that everyone claims should never be there.

Under each objective:

  • Define the expected deliverable as Key Result
  • Set the Completion Criteria for each Key Result that will foster raising the bar towards perfection
  • Review the Key Results in Weekly/bi-Weekly meetings with emphasis on the planned and learning objectives.
  • If an impromptu task was taken up by the individual that resulted in impacting the planned/learning objective, add the impromptu deliverable item to the Impromptu Objectives category.

(Use the judgement on calling out the Impromptu tasks, the idea is to review these tasks at the end of the quarter, to check for improvements)

At CloudByte, we are using the tool for OKRs.

In the follow-up post, I will provide some examples on typical objectives, their deliverable (key result) and their completion criteria.