Skip to content
PopcornFlow Template
PopcornFlow Template
Popcorn Flow
Supporting Materials
Find me Online
More
Share
Explore
Supporting Materials

icon picker
Thoughts and Notes

Low Friction Experiments

Low friction experiments is really the key idea that interested me in Popcorn flow and lead me to developing this tool. In my work I've always seen team retrospectives and change experiments as the activities more often fail to achieve their intended outcomes, and more seriously, be completely abandoned and forgotten about after a few weeks as people lose interest.
I think part of that has been how complex and the experiment systems were designed, how difficult they were to maintain, and how much effort they took. Even the idea of making root-cause analysis a required step, to people without any training in the practice, just made things more difficult. Too often I've seen people with no exposure or training in root-cause analysis be asked to facilitate a 5 Whys session with their teams. So in Claudio's talk when he said he wanted people to just post their anecdotal problems or observations and that root-cause analysis would just slow momentum (at least I think he said that) it made sense.
I would rather be in the position to introduce root-cause analysis, Kanban's Service Delivery Reviews or Toyota Katas to a team if I saw that they were already implementing and learning from multiple experiments a week.
I like PopcornFlow as a method designed to make change continuous by helping people easily design and execute on small experiments. I'm curious about other ideas to remove the drag factors to change and experimentation, so let me know if there are other things you've tried that help reducing the friction to change and accelerate experimentation in an organization.

Data Validation

One feature I spent time trying to implement was data validation on all of the different fields. For example, I've made it so problems and observations, options, and experiments can't go further along in the PopcornFlow if they have information missing. That validation can only check to see if a value exists however. I tried to put in validation to make sure you've entered a time in the Duration field, as opposed to gibberish, but I wasn't able to figure out a method to do that in Coda.

Balancing the number of pages

One of the design goals of this doc was to make it something teams could easily pickup. The heavy use of buttons you see in tables were intended to help that by automatically creating references to problems/observations and options as new experiments got added. But as a result the number of tables, and buttons started to grow.
I spent a few hours thinking about and designing the flow of the app. I thought about if all the standard PopcornFlow states were appropriate for the Coda doc, and at what point should users be made to enter information like expectations, durations and review dates for experiments. I'm interested in any feedback if you've tried out an alternative flow and have found something that works better.

Experiment Owners

I've left it out of the doc right now, but another practice I always actively encourage with teams is if there's an action item coming out of a retrospective, that there should also be one or two people also identified as responsible for executing it. I don't know if assigning experiments to people is really aligned with the idea of reducing experiment drag and keeping the system low friction, so for now I just left it out. Again, if that's something about which you have some feedback to share, please do.
Low Friction Experiments
Data Validation
Balancing the number of pages
Experiment Owners
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.