How Scrum Uses Constraints

Ever notice how Scrum gives you a Sprint, a Sprint Goal, and a Definition of Done... and then tells you to figure out the rest yourselves? That's not Scrum being vague. It's Scrum being clever. In this video, I look at Scrum as a system of constraints, the same idea Cynefin uses to explain why some work needs tight rules and other work needs room to breathe. I'll cover: What a constraint actually is (hint: it shapes the work, it doesn't script it) Governing constraints: like a Definition of Done that locks quality in place Enabling constraints: like a Sprint that gives a team room to probe and adapt Why complex work needs enabling constraints, and complicated work can live with governing ones One question to ask about your own team: are your constraints shaping the work, or scripting it? Once you see Scrum this way, a lot of it stops looking like rules and starts looking like good design. The two main types of constraints come from Dave Snowden's work on Cynefin (building on Alicia Juarrero), there's a lot more nuance to it than two boxes, but two is plenty to change how you run your next Sprint. If practical facilitation and a bit of theory you can actually use is your thing, subscribe; there's a new short video every week. Comments, questions, ideas, and feedback, is as always, more than welcome :).