Like most people I enjoy watching random things on YouTube. I’m not a huge fan of Disney, nor do I have anything really against them. I stumbled along this view about the history of Disney’s FastPass and immediately got scared about the hour and forty minute runtime. After listening to it a little I started noticing similarities to project management.

I highly recommend giving it a watch, but here is what I picked up from it and how I connect it to project management, Agile, Lean, and vaious methodologies:

Service Rate vs. Arrival Rate - Right off the bat you get a couple of wonderful terms. The first two are service rate (the rate at which items come off the queue) and arrival rate (the rate at which new items come onto the queue). Interesting, I don’t equate service rate to either Lead time (elapsed time to complete a request from when it is first requested) or Cycle time (elapsed time to complete a request from when work first begins) in methodologies like Kanban. Both of these times include, in the Disney metaphor, completing the ride. So service rate would be Lead time minus Cycle time in a rate form. Think of it as “features crossing the line of commitment per week.” Taken with arrival rate, you can start to look at how fast the backlog is growing. Is this a metric useful for anything? Maybe to help your customer focus on what they need. If the backlog is growing at a rate faster than the team could ever hope to finish it, is it useful to continue to add to it? Valid questions that likely depend on the customer, project, and situation. If nothing else it gives awareness and a starting point for conversations if the features being added are needed just wanted.

Balking - This is not waiting (leaving the queue) due to the length of the queue or, for our purposes, not requesting a feature (or removing it from the backlog) because it would take too long to get worked on. To quote the video, “Time becomes a currency they must spend.” I love that quote! When your customer is asking for features and setting their priorities they are spending the currency of time. Which ever feature they believe is worth more gets done faster. While I don’t believe time estimates are a good approach, using general time when stacking priority of work can help the customer make better decisions. For example, “There are twenty features you want. Because of the rough size and nature of these, we can get maybe five done this release; which five do you want the team to spend their time on?” I think this is a great way to frame an often difficult discussion when the customer want everything all at once.

Backfilling - Another great quote (originally by Bruce Laval), “FastPass increases rides per capita by backfilling less attended attractions.” This is an interesting quote and made me think of how it could be used as a metaphor in Agile or Lean. It reminds me of Kanban’s moving people around to help unblock. E.g. If there are too many tickets to test, developers should move over to help QA instead of picking up another ticket to work on; even if they would be less efficient at testing. Looking at it this way, Kanban is a series of queues where tickets are the riders and people are the rides. A ticket waits in queue for work to begin, it waits in queue for development to code it up, and waits in queue for QA to start testing. WIP limits (work in progress) are effectively the wait times. “Backfilling less attended attractions.” would be the ticket “deciding” to go to a developer for testing instead of to the QA team that is already filled with tickets. I know this is a stretch, but again it is interesting to think about.

Tiered Systems - According to the video, FastPass+ originally let people pick 3 rides, no matter what the rides were, but then later changed to a tiered system where the most popular rides (e.g. Space Mountain) were grouped together and people could only choose one from that group. This is a concept I can get behind! If there are five flashy (non-core) features your customer wants and a bunch of smaller core features, you could strike the deal that they can pick one per release. That way you can still deliver the anticipated items while getting the core requirements done. I can see this approach more with projects that have the marketing, user driven, sales features where there are customer voices that want to add things to “sell” and ignore the defects or critical backbone work. Maybe rank your features into tiers and let them pick a specific amount from each tier and keep a few slots for the team to pick. This would work better with a Scrum type of methodology or one that has larger releases planned out more in advance, or newer projects that needs the main infrastructure finished first.

Broken Rides - One thing the video touched on several times is what happens to the lines when a ride breaks down. In regards to FastPass+, the video talked about how people could book their rides way in advance. “FastPass+ was basically guaranteeing that an attraction was available 60 days in advanced… causing even longer lines when something broke.” This caught my attention because it is exactly why waterfall doesn’t work with software projects. If at the start of a project you are guaranteeing some piece of work (on the critical path) would be done 60 days away you are setting yourself up for failure when some problem arises. However, I also see this with Scrum teams using long sprints or collect a lot of sprints into a single release. In general I see this as a problem with promising both what is in a release and when the release will be (both scope and time). It is nice to see this problem from a different perspective.

Standing vs Slowly moving - Another fun quote from the video “…people prefer to spend 20 minutes walking at a steady pace, rather than 20 minutes of standing.” This is the same thing for features and our customers. In project management this is all about communication. When a feature is not progressing (often because it is blocked by something), if you are not updating your customer it is equivalent to the feature “standing still.” Even the most basic updates like, “Sent the other system admins an email, but we are waiting to hear back” gives the customer some relief and understanding of what is going on. No, progress is not being made, but they are made aware that the team hasn’t abandoned the feature or ignored their (the customer’s) needs. That is the slow moving. To bring in the service rate from earlier, if the customer is waiting and the team has a low service rate(due to some other priorities or prerequisites that need to get finished) reminding the customer of their favorite feature’s place in the larger road map also enacts this “slow moving” concept. Half of my backlog grooming meetings are reiterating why priorities were originally set the way the are. Then we go into what may need to be adjusted or changed.

Inelastic Demand - In a lot of my previous points I note a difference between feature that a customer wants to get done and a feature that must get done. The latter is called inelastic demand, where the demand will not decrease regardless of the wait time (no balking). I can think of several features, both large and small, that qualify for this label. I can think of several more that my customer would say qualify for this label, but actually do not. That, to me, is the interesting tie-in to project management. For rides it is easy. The video gives examples of new Star Wars rides, and Harry Potter rides with 10 hour wait times, where they are the only reason people came to the park. In software development, these are core features that the software must do; the reason a user will even consider using the software. To be clear, I did not state “…consider using the software verses your competitors” because core features are not just what distinguishes your product, but what makes your product even be a product in the first place. For a scheduling software it is the ability to schedule or for a point-of-sale software it is taking payments (e.g. the most basic point-of-sale system you don’t need products, just type in the number and perform the transaction). These core features and requirements have inelastic demand as they must get done and you cannot go to market until they are.

Overall, this was a fun video that I absolutely enjoyed. I don’t often sit with a pad of paper writing notes on something I watch on YouTube. There were other notes I took that I need to go back and rewatch to either understand better or figure how it could fit in the project management world (if I can spare the time). I highly recommend taking a look and, if you are a fan or foe of Disney check out other videos by Defunctland (Kevin Perjurer). If you have thoughts on my critiques or other connections you made in this video let me know in the comments.

Of course, Thank you again Defunctland for such a great video!