Hey! We’re going to use these things called points.

Interesting, the work is assigned points? The team sets their goal based on points. Well, that’s very interesting…what if you…can you add them up…let’s see points by engineer…what if they gave points to the whole project…Hey! We’re going to hold a retrospective at the end of each sprint.

Ohhh! A periodic meeting. To talk about how things are going! That might be a good time to…maybe we could review…let’s figure out where we dropped the ball…Hey! There’s this person called a Scrum Master.

Great! Sort of like a project manager?! Seems like it. Can they keep track of things? Can they help us keep the team in line? Can they run this report…we need to instill a sense of urgency…status checks…Hey! There are these things called user stories that sit in a backlog!

Nice! So like a specification!? If we can really nail these down ahead of time, we should be good. The more specific the better. Maybe the business analyst can write them? And this backlog? Wow, that’s helpful. Let’s get that described for the next quarter.See what’s happening? In the context of continuous improvement, constraints/forcing functions are meant to apply just enough healthy pressure on the team to catalyze the right conversations and introspection. The team uses them deliberately for a desired effect.

Unfortunately, some of the most helpful constraints/forcing functions (e.g timeboxes, WIP limits, story decomposition, retrospectives) also happen to be the most abusable by unskilled managers. They look like tools for project management (or even performance management), but they aren’t. Looks can be deceiving — they’re actually tools for continuous improvement.

There’s no silver bullet to fix this confusion. One approach is to be very, very explicit about the “why” behind the constraints you invite into your work as a team. To be fair, you really can’t blame the uninitiated from mistaking these things as potential ways to control the team and/or project.