The biggest benefit of Scrum over other traditional frameworks like Waterfall is its focus on short, incremental sprints, and adaptability to change. With Waterfall, outcomes are defined and agreed upon at the beginning of the project, often with a detailed scope and project spec. A plan is derived from these specs by working back from a point of completion in the future, with time, budget and dependencies worked out linearly. The product of this approach is a roadmap that outlines all the software development work that needs to be completed up to the point of release. The downside? If anything changes along the journey, timelines, dependencies, and often budgets need to be completely reworked; the plan is broken and must be created again.
Scrum, on the other hand, is concerned with short incremental sprints toward a desired endpoint. Detailed plans are replaced with lean specs or “stories” and regular reviews which measure the outcome of each sprint. Those reviews should answer the question, “Has the work we’ve done moved us closer to our desired goals.”
Scrum’s power comes from its ability to manage work toward an unknown, unique, or never attempted outcome. The framework systematically and incrementally manages the process of solving a problem that’s never been solved before. Waterfall, in contrast, works best when the processes and work involved are predictable and have been attempted before. In a custom software development is hard to find these types of problems, because of nature that if we build something custom, it means that there is no other solution on the market.
It’s the difference between building a car and a rocket ship.
Space technology is relatively new, building a rocket ship takes several incremental steps and iterations to get right. The work that leads to SpaceX landing a rocket on a ship is a great example.
Car construction, on the other hand, is a very well-understood engineering challenge that has been solved numerous times. Building a bridge is low on iteration, high on time, and cost planning, and this is where waterfall is often used.
How do OKR and Scrum compare?
Scrum is a highly prescriptive framework with specific roles and ceremonies. The benefits of Scrum include transparency, project visibility, and constant communication. The team collectively decides what work they can complete in short “sprints” which makes scrum a very democratic process.
OKR also has a set of rules, although not as codified as Scrum. Those rules determine what an Objective can be, what Key Results are, and how they work together to measure the achievement of goals. Like Scrum, OKR has timeframes, however, these are a lot longer (quarterly and yearly) than two-week sprints. OKRs are created above sprints and they are answering on the question of how to achieve business goals.
How to combine Scrum with OKR?
The first step is to define the OKR goals and their measures – key results. These should be the goals for the product that the development team is building. I recommend starting with quarter-level goals, which is good practice for short-term goals in the OKR world. After defining the goals and metrics that show how the team is going to achieve the goal, you can start integration with the Scrum team.
Go and organize a joint meeting, during which you explain to the scrum team how OKR methodology works, and why the defined goals and measures are essential for achieving business goals – your “why”.
It is worth starting to ask questions about how the Scrum team can support the achievement of the defined goals of OKR. Very soon, it will turn out that your team will generate a lot of ideas that more or less support the achievement of goals.
For example:
The team creates a mobile application that allows you to bid on items for charity.
OKR goal for the quarter: Increasing the number of people who take part in the auction
KR: Increasing the average number of people bidding on an item from 3 to 6
Team ideas generated during the meeting:
-
Adding functionality that will allow the bidder to send information to friends about the auctioned item
-
sending bid information on Twitter
-
push notification by the issuer of the article that he should send information about the auction to his friends
-
analysis of auctions in which the number of bidders is well above average
-
performing the mechanism of the daily report what the average number of people bidding on the item
These ideas were not previously in the product backlog. The team was focused only on creating new functionalities.
It will soon turn out that your team’s way of thinking will be more business-oriented towards achieving the goals recorded with OKRs, which I wish you very much.
