I am a huge fan of Maarten Dalmijn and highly respect his opinions and love his most recent book. That said, I struggle with this idea and would love feedback on it. My $0.02 - I also know that more and more companies want all three locked, and quality isnt an optional flex - its a given. They want to know what they are going to get, when they will get it and how much it is going to cost. And in 2025, my bet is that will become more of the norm. I almost have a feeling like the Golden Days of flexible scope are numbered. They days of "let's fix the date and give you however much money you need, and you just build what you can and whatever you get done in that time, it'll be the most important stuff. And all the rest will just float." I think those are in the rearview mirror in some regards. So the question for us is how do we be agile when all 4 of these things are locked? I think that's the question of 2025 and the foreseeable future.
Author of 'Driving Value with Sprint Goals' | Helping teams to beat the Feature Factory | Speaking, Training and Consulting all over the world @ dalmyn.com
Question on reddit: "Isn't agile a mini waterfall ? Instead of planning and executing a complete requirements, we create a requirements enough to be finished within sprint duration? Which means any change to requirements or scope mid sprint should be treated similarly to any change or scope in waterfall?" Answer: "No, because scope MUST be flexible even during the Sprint. Let's use our trusty old friend the Project Management iron triangle to make this point. During the Sprint: - Resources are fixed (team size doesn't change and if it would increase or decrease, in both cases it would slow the team down during the Sprint, because people need time to get up and running). - Time is fixed (Sprint duration) - Quality is fixed (Definition of Done) So, given these constraints. The scope must be flexible. The goal of the Sprint, that's the intent: what are we trying to achieve and why does it matter? that acts as an anchor. Complex work means surprises means inevitable scope changes even DURING the Sprint. So, if anybody talks about surprises as 'scope creep', then they didn't get the memo.
I literally made a similar post on this today.
On time, budget and scope? .... Yeah right. I can't even do a bathroom reno on time budget and scope. You can want it all yo want. Doesn't mean it's gonna happen. New product dev is filled with uncertainty. Locking the corners of the triangle wont make that go away
It's easy... we pretend all 4 are locked...nobody REALLY checks quality... and scope flexes at the end once we can't pretend any more.
Scope can change, as long as the work is done. I regularly allow teams so say drop an acceptance criteria or business rule - as long as they produce bug-free, integrated, and demonstrable code. Aren't those the marks of success for a Scrum team? Why penalize failure. Because of how I teach story writing, adding "scope" is so simple it's barely worth commenting on. I just published a 500 word blog on that here this week.
Maybe it's just me, but the scrum and agile groups I've followed on Reddit 1) don't have much traffic, or seem to be primarily folks who are either 2) learning, or 3) have had really *bad* scrum experiences. So I need a shaker-full of salt when reading Redditor comments. Maybe a margarita, too!
Ah, the golden days of flexible scope, where the only thing that was fixed was… well, nothing. 😅 But seriously, it's true – with everything locked down tighter than my gym schedule (which, let’s be real, is more of a suggestion), agility is gonna need to work overtime. How do we stay nimble when the only thing flexible is our ability to adapt? Looks like 2025 is gonna be the year we all start doing yoga, but with deadlines. 🧘♂️ #AgilityIn2025 #TheGoldenDaysAreGone
All of these are choices. You don't have to do anything. HOWEVERRRR (read that with a very thick R), if organizations want to set themselves up for disappointment, fixating all four aspects is a great start.
You can lock scope, schedule, budget... and quality... but that doesn't mean you will succeed. Wanting something to be so doesn't make it so, regardless of how positively you think. Reality will bite. This al comes from a desire for control. Managers (and management) continue to believe despite all evidence to the contrary that arbitrarily locking all project parameters to (hopefully) eliminate variance is the key to control. Managers (and management) needs to realize that in non-repetitive knowledge work there is variance and ignoring this with wishful thinking dooms the org to failure. Therefore, focusing on reducing variance across the domains of work is essential to increasing predictability and control. Yet, too often managers insist on doing more of what doesn't work. I can give you predictability, with decreasing variance, across the life of a project... and in doing so give you (management) options. In the uncertain world we live in, that's as good as it gets. It's good enough, because nothing else is better.
I take the risk out of your software development projects and make them valuable, efficient, and predictable.
2wI think an important key is Maarten Dalmijn is talking about complex work, which is really the only arena where Scrum is that helpful. With complex work, it would be impossible for the business itself to fix all those factors because they themselves don't know what you're going to end up with. They might be able to fix those factors for a very short runway with a well-defined short term goal (in a sense, that's what a sprint is), but it should be virtually impossible for them to do it with a larger product concept. As soon as a company says, "Here is the list of features that we're building come hell or high water" then it's no longer complex work. And why someone would use Scrum to attack that plan is beyond me.