By the late 1990s, software development was facing an existential crisis. Project after project was continually delayed, budgets wildly exceeded and customers let down. It seemed no matter how well engineers planned projects or how meticulously they documented requirements when products finally did launch, customers found software that didn’t work or was difficult to use and failed to deliver the value it was supposed to.
The linear or ‘waterfall’ approach to planning software projects, where developers moved from one task to the next, clearly wasn’t working and something had to change. So in the spring of 2001, a group of forward-thinking engineers met to debate a better way.
At the centre of their discussion was how to deal with uncertainty. Because, unlike manufacturing a physical product, where there’s a detailed specification, a predictable cost of materials and a clear outcome, the end-state of software is not so easy to predict — especially at the beginning of the process.
The fact is many things can change over the lifetime of a software development project. Customer needs may change, technical changes, or a shift in the market, such as a competitor launching a similar product before yours, could mean you need to change direction. Software engineers required a system that would allow them to deal with these challenges while focussing on rapid delivery.
At the end of the session, the group outlined a philosophy. Called the Agile Manifesto, at its centre was this critical phrase. “We value responding to change over following a plan.”
To better deal with uncertainty, the Agile Manifesto advocates working in smaller cycles at the end of which engineers would take the time to pause and reflect on what has been achieved before deciding on the next step.
Work is organised around a number of ‘sprints.’ Once completed, the team studies the data gathered and makes a judgement on whether the project is still on track or if the current thinking is flawed and they need to change direction.
The Agile methodology makes software development dynamic rather than prescriptive, with teams using tools such as a Kanban Board to help them visualise what needs to be done and where the bottlenecks in the process lie. As a result, it gives everyone a big-picture view and encourages collaboration and learning—improving flexibility and responsiveness while reducing cycle times and work-in-progress.
Similarly, a process of iteration, transparency and continuous improvement also lies at the heart of OKRs. Regular check-ins allow teams to monitor progress and make informed decisions based on real data. While conversations, feedback and recognition (CFRs) help to strengthen connections between those involved, ensuring everyone understands the company’s priorities and their role in helping it achieve its goals.
However, there are key differences. In Agile, work is assigned to an individual by the Scrum Master who controls the backlog. Periods of work or ‘sprints’ can be as short as one day or as long as a few months. OKRs work at leadership, team, and individual levels, both top-down and bottom-up, with everyone typically working in annual and quarterly cycles.
OKRs help businesses move from the typical Agile-defined output or ’work done’ to a metric that measures a business outcome or ‘what is achieved.’