Would Santa Claus Make a Good Product Owner?

[article]
Summary:

The elves working on Project Santa—you know, the big delivery that happens every December 24—have decided to go agile. But Santa, the product owner, is busy and not always available to answer questions or provide guidance. What kind of suggestions and improvements should they address in their retrospective?

As it’s Christmastime, let’s take a seasonal look at life on an agile team.

You are one of the elves on the team working on iterations for Project Santa—you know, the big delivery that happens every December 24. One of the senior elves is the ScrumMaster, but there is no product owner; everyone knows Santa Claus himself is the product owner for all teams working on Project Santa.

Santa is usually available to answer questions, but leading up to the delivery phase of Project Santa, his availability becomes much less, as he is involved in visiting shopping malls, checking the reindeer, and making guest appearances around the world. Santa is an inspirational figure and his energy and enthusiasm know no bounds, but he has a lot to do, and no one questions his authority—it’s how things have always been done.

The decision to go agile was largely welcomed by the elf teams, but the unspoken question was about delivery. Working in two-week iterations gave the team more opportunity to plan and appraise progress than pre-agile times.

In those pre-agile days, a grumpy elf used to track the schedule and provide a monthly report to Santa. Santa often would take an optimistic view, until the delivery time was close—then he’d reluctantly agree with the grumpy elf to increase the working hours of the teams.

Now that the teams are agile, they’re being asked to work extra hours earlier in the process. However, the elves feel that an extra hour here and there doesn’t hurt if it means the iteration velocity could be stretched a little further.

But the real question is how to make best use of the iteration output. Project Santa has a clearly defined yearly delivery, so what use is it to complete things cleanly every two weeks? If something wasn’t finished, it could be picked up and worked on in the next iteration and no one would know.

The grumpy elf occasionally checked the burn-downs and carried over stories, but provided that everyone was ready come Christmas Eve, then it didn’t really matter. Most of the activities were complete on a lot of carried-over stories; often, they were waiting for the elves in packing to complete items.

Thanks to their newly adopted agile workflow, there was no usual scramble at the end of December, and Project Santa shipped—or, rather, flew—on time.

All the elves—even the grumpy one—celebrated another successful delivery of Project Santa. But because they are now fully committed to agile, they decided that in January, they are going to hold a project retrospective. What are some of the questions they should raise, from a purely agile perspective?

One of the first questions that comes to mind: Is Santa Claus a good product owner? Sure, he’s an inspirational figure to the teams, capable of deciding on priorities and product decisions. But if he didn’t possess magic, would he really be capable of serving all the elf teams?

Unless your product owner also has some Christmas magic, this “hero” model is not a good one. It doesn’t provide the specific guidance the teams need, and it isn’t scalable. Moreover, the ScrumMasters on each team do not have sufficient authority; they simply relay questions and issues to the one overall product owner for him to make the ultimate decision. A better method is to empower the teams more individually by appointing a product owner in each team who represents “the big guy.”

Another questions the elves might ask is, Where an iteration isn’t used to deliver something immediately shippable, then is there any harm in carrying over stories? What’s the best way to communicate the benefits of completing every iteration cleanly—predictable velocity, avoiding additional working hours, and building confidence?

To avoid carryover, ensure that the causes are discussed (even those that may be deep-rooted in history and culture) and learned from during the retrospective. Often, the cause will be that stories are insufficiently defined or too large, so large stories should be broken down where possible to create more manageable units.

Agile often clashes with existing mindsets and practices, many of which may have strong historical or cultural connections. It’s not always easy to change these routines—especially if you have a larger-than-life leader—but voicing your questions is always the best method. It will strengthen your process, your teams, and, ultimately, your product. If elves can do it, so can you.

User Comments

1 comment
Nishi Grover's picture

This is such an interesting example and some great points coming out of the story. Good read!

March 8, 2016 - 11:27pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.