One of my favourite activities is teaching (potential) Product Owners about their roles and responsibilities on a Scrum Team. The thing I spend the most time on is this: “time is rigid, scope is flexible.” In the Scrum projects I’ve been working on at a digital agency for the past few years, quotes don’t contain a detailed list of features. Product Increments made within Sprints are successful in achieving their Sprint Goals, but are not always — on a functional level — what was originally envisioned.
Every once in a while, I encounter a client who needs to describe every detail beforehand. Or who wants every feature fully fleshed out in design “before the sprint.” That feeling is understandable. Some managers long for control, and they want a clear view on value for money.
As a Scrum Master and agile professional, and based on my experience as a project manager, I advocate that time should be rigid and scope should be undetermined and flexible. This can sound like giving up control. I am here to tell you: you are gaining a more valuable form of control, plus flexibility, support, and overall happiness. My advice, in the lyrics of the 1995 hit by TLC: “Don’t go chasing waterfalls.”
The Cynefin Framework, developed by Dave Snowden to help leaders understand the nature of their challenges before deciding how to respond, maps problems into five domains.
The Complex domain is characterised by unknown unknowns where cause and effect can only be identified in retrospect; emergent practice, not best practice, is the appropriate response. Scrum is explicitly designed for this domain. Software development lives in the Complex domain. Requirements continuously change. Technology continuously changes. Stakeholders and end users are unpredictable. The notion that software development can be fully planned and designed beforehand is, at its most charitable, optimistic
I once worked in a conservative environment where building a website was compared to the complexity of producing a brochure. That’s what it is, right? An online brochure. In a field where requirements continuously change, planning everything in advance is a reliable recipe for disappointment.
I remember working in a typical waterfall method: detailed wireframes leading to fully fleshed designs, leading to a development phase, ending with a single feedback cycle before launch. If a client came up with a new insight mid-project, I’d park it as an “author’s change” and hold it off. They’d agreed to the design already; new additions were not really allowed. The process was rigid. And when the client put their foot down anyway, new features were added, the timeline extended, and the project finances came back under heated discussion.
The devil’s triangle
Project managers will recognise the project management triangle, also called the “triple constraint” or “iron triangle.” In Dutch we call it the *duivelsdriehoek*, which translates loosely as “devil’s triangle.” It maps the field of tension between scope, resources, and time. Expand one and you inevitably compress another. Quality sits at the centre.
In practice, the contest is almost always between scope and time. They get treated as universal truths: an unstoppable force meeting an immovable object. Someone always loses. There is always a sacrificial lamb. When either scope or time are fixed, the consequences are predictable: quality gets reduced, or the pressure on resources, people and costs alike, becomes enormous.
Scope is rarely reduced. Deadlines are sacred cows. What gets sacrificed fastest is quality, or the wellbeing of the people doing the work. In IT, crunch time was treated as a given, simply to be expected. Who pays for those extra hours? Usually nobody. The project runs over budget, over energy, and over the health of the team. The client rarely picks up the bill.
Applying Scrum in a project-based environment
Many software teams have moved to agile approaches precisely because of this. Scrum accepts that customers will change their minds about scope and that unpredictable challenges will arise for which a predictive approach fails. Changes are not treated as violations; they are accepted, analyzed, and absorbed. Empiricism in Scrum rests on three pillars: transparency, inspection, and adaptation. The 2020 revision reframed Scrum around generating value through adaptive solutions for complex problems. This evidence-based empirical approach acknowledges that the problem cannot be fully understood up front.
Applying this in a project-based digital agency context means working with uncertainty from the outset. There is a budget allocated to a project, a new website for instance, which combined with a broad outline of functionality, determines the number of Sprints in scope. Continuous development is not always viable given product type or budget constraints. I am talking specifically about project-based environments where development opportunities are fragmented and created through emerging needs and available resources.
Often there is a strategic or conceptual phase at the start: exploring starting points that give the Scrum Team valuable input for the work ahead. This might look like planning everything beforehand. It is not. These starting points are input. The development, and the making of all definitive choices, happens inside the Sprints.
Time is rigid, scope is flexible
I have seen clients arrive at project kick-offs with enormous MoSCoW lists of wishes and demands, asking for reassurance that every feature will be included in the quote. That anxiety is understandable, it is about value for money. What I tell them is this: everything goes on the Product Backlog. From there, the work becomes a collaborative negotiation about what creates the most value inside a Sprint.
During the Sprints, there is continuous communication and cooperation across the Scrum Team to deliver fully functional Product Increments. The goal is to create the most value within the set time. Sprints are time-boxed and finite. So: time is rigid, scope is flexible. The what is determined by the Product Owner; the how is determined by the Developers.
The Product Owner’s role inside this is central. They give direction and purpose to the whole team, carrying significant responsibility and significant freedom in equal measure. Choices about simplifying or expanding functionality rest with them. When new needs emerge, the Product Owner re-prioritises the Product Backlog accordingly.
What I have noticed working in Scrum teams inside project-based environments is a genuine shift in the client-contractor dynamic. Where there used to be rigid contract logic, you asked for X and X is what you get, there is now mutual understanding of each other’s constraints and the complexities of software development. Trade-offs can be discussed openly. The implications of choices become visible. Direct communication prevents needless feedback loops. That efficiency and flexibility create space for extra nuance, extra care, extra features: the feeling of overdelivery.
Then there is the shared pride. The sense of something built together. Psychological safety, the shared belief that the team is safe for interpersonal risk-taking, is the foundation on which this kind of collaborative ownership becomes possible. Google’s Project Aristotle (2016) identified it as the single strongest predictor of team effectiveness. In the Sprints where I worked as Scrum Master, I noticed a direct correlation between a Product Owner’s mastery of scope management and the quality of what was delivered, and between that quality and the atmosphere in the room.
Teams that trust the process tend to enjoy the work.
“Don’t go chasing waterfalls
Please stick to the rivers and the lakes that you’re used to
I know that you’re gonna have it your way or nothing at all
But I think you’re moving too fast”