Constraints: They’re not just for design

I recently partnered with Harvey Mudd College psychology professor Debra Mashek to help her students learn about scrum as part of her Psychology of Collaboration course. As I reflect on what we learned that day, I’m struck by the value of constraints that scrum brings through the basic ceremonies.

That’s me setting up our first activity, backlog grooming.

Constraints on design

Designers have often called out the value of constraints, even saying that constraints are what differentiate design from art. Constraints such as business goals and user goals help us focus on the right problem, instead of what seems hip at the moment. Technical constraints help us know where the sweet spot is for faster, incremental enhancements versus where we need to partner with many teams to change system capabilities in support of big wins.

A student team busy at work, with some team members building stuff and others referring back to their scrum board.

The daily stand-up meeting

In the scrum workshop, I spoke briefly about each of the major scrum ceremonies as we moved through the cycle. In some cases, I specifically called out that the ceremony uses artificial constraints to force a certain kind of communication. For instance, the daily stand-up meeting, in its most basic format, asks team members to state their news and listen to each other without chasing each juicy topic. Some teams push against this and reshape their daily stand-up into a daily working session. Some teams skip it altogether in favor of emailing or posting the updates once (or more) per day.

I told the students we’d stick with the basic script for two reasons: first, to learn the vanilla scrum model, and second, to focus on the value of the constrained communication method. As I see it, the stand-up, in its vanilla form, focuses on helping team members plan their work for the day: It clearly identifies areas where team members need to collaborate more, get or stay in sync, or possibly shift work to avoid duplication. The meeting uses constraints on communication that are sometimes awkward and clearly artificial, but it focuses use of that time and use of the entire day in its wake.

The retrospective

The retrospective also uses constraints to guide communication toward very specific ends. In this case, we use constraints to provide a low-risk context in which to expose ways we could improve our approach to work. By providing a structure for framing our ideas — and by building it into the basic cycle of work — it becomes natural to simply state things like, “we’re not sharing ideas soon enough,” or “our approach to QA isn’t providing feedback soon enough.”

A student team working on their retrospective, looking for the key themes in their collected ideas.

Switching hats: constraints in action

I’ve seen firsthand a team that gave up the retrospective since it seems superfluous after working together a long time. By doing so, the team gave up the value of the constraints imposed during the retrospective: it lost the special way a retrospective brings out ideas about improving our ways of working. Stepping in and out of the various scrum ceremonies often requires us to switch perspective. It’s kind of like the design studio technique of wear a different hat: Trying to design something as if you were a different brand. For instance, how would you solve this problem if you were Ritz-Carlton? How about if you were McDonald’s? Putting on that perspective is a way to use constraints to guide us to new ways of seeing the world. We can use that approach in design and also in our broader process, as scrum does.

I originally published a version of this on our internal UX blog at ADP.