Culture is what you celebrate. Rituals are the tools you use to shape culture.

Yet very few of us think much about ritual design.

A standard piece of software development practice that many teams let lapse, or merely let lapse into being sub-optimal is “Friday wins”, sometimes called sprint demos or sprint reviews. But you can take what can be a flaccid and repetitive meeting and make it a valuable ritual by grounding it in values.

This came up in a conversation with a team recently, and rather than save the thoughts for a “grand theory of ritual” post, I’m experimenting with just sharing quick notes.

When I’m designing Friday Wins here are the handful of values I’m thinking about in my ritual design:

Learning oriented - learning oriented cultures look forward to and eagerly participate in reviews. If your team dreads postmortems, or has lackluster end of sprint reviews, likely you aren’t facilitating a learning oriented culture. Rather than saving reflection for when something has gone wrong, make the cadence of a weekly Commit-Reflect cycle the heart of your software process, and make reflection a thing to look forward to.

Call it “Friday Wins” vs “Sprint Review”.

Organizational awareness - the insight that you can’t predict who needs what information in a complex system drove NASA’s original “systems management” insight, and most high performing technology organizations since. (see also Team of Teams). Friday Wins should be maximizing for ambient awareness and chance encounters.

Don’t silo wins by team. Invite the largest number of people who can reasonable attend. Invest in making attendance easy (support for remotes, no meeting policies, etc).

Shipping - if you’ve worked on one of my teams you know that I believe that a relentless focus on shipping is primary driver of team effectiveness. Shorter cycle times have been shown to lead to both higher productivity and higher happiness. Value and learning are both primarily captured only after a project is finished. Confidence is gained most quickly in production. etc etc. If shipping is one of your values, center it in in your rituals.

No presenting work at wins that’s almost done, almost done waiting for a PR, will be merged to master next, is merged to master but hasn’t been deployed. Wins need to align with your values.

Modern software is cross functional - graphs count as wins, UIs count as wins, analysis of customer request behavior counts as win, a new training module rolled out to the company counts as win.

How software is made is important (part 1) - most modern companies can only succeed when there is a high degree of mutual respect between different disciplines within the company.

One small part of that is Friday Wins including people who aren’t on the software engineering team. (this is a value that is distinct and in addition to Organizational Awareness)

How software is made is important (part 2) - in a “tech company” or “tech led company” the value and limitations of software is generally understood to some degree. As software continues to transform more problem areas it is important that the process of building software is understood and respected (in both its strength and limits). One key building block for this is making sure high prestige individuals outside of engineering demonstrate that they care not only about results but about the process.

Invite the CEO to wins.

Inclusive and high energy - this is a weekly celebration. We have rules (time limits, only things in production, etc) but it should be something people look forward to. (or you should burn it down). That means both everyone should have a way to participate, even if you didn’t have a “win” this week, and that everyone should be expected to participate, and that as a leader you need to make that a thing people look forward to.

Have an alternative method for playing e.g. show a win or answer a weekly “icebreaker” like question.

Be prepared to draw folks out who don’t recognize their own wins, and occasionally be prepared to put the win in the larger context of the goals.

These are the things that I think about when I’m designing an end of week ritual. A lot of these values will bubble up in other rituals I design (like LPORs, a mid-week review of launching projects).

The point isn’t that this is how to design your sprint reviews, the point is be intentional in how you design your rituals.