Track work with POPCORN Flow
Work challenges are opportunities to explore, experiment, and track the feedback gathered from the process of innovation
Work challenges are opportunities to explore, experiment, and track the feedback gathered from the process of innovation
I love to visualize the work. It’s easy to do — all I need is a low tech/low rent board and some yellow sticky notes. Or, a simple, inexpensive whiteboard with erasable markers. Easy to acquire, easy to set up.
Yes, but what to put on the board? Ah, that’s where the real trick lies. Knowing what information to put on the board is oftentimes half the battle.
Different teams adopt different prescriptions on how to track the work using a board. Whatever the prescription, it always boils down to something simple — track the progress of work in time by starting from the left-hand side of the board until you reach the right-hand side of the board. Leftmost side implies nascent work; rightmost side implies completed work.
That’s easy, but what goes in the middle? That’s where various prescriptions propose various types of tracking. It is difficult to argue that one type of tracking is necessarily better than other types of tracking. At the end of the day, it mostly boils down to personal preferences.
My preferred mode of tracking
I can only talk about my personal preferences, but I’m sure others will find something similar in the way they prefer to track the progress of work. To begin, I tend to perceive work as a response to challenges. Things change, and with the change we experience challenges. Taking those challenges on is a special skill because we don’t want to be caught in the situation where we are faced with chronic challenges. To avoid that trap, we must make the work that matters more visible. Still, without challenges we wouldn’t have anything to work on.
I like to start by adding a column to the board where I place problems and observations that come along the way. Once I pick the problem I plan to focus on, I move it to the next column to the right of the “Problems and observations” column. I label that column “Options”. The problem that made its way into the “Options” column should be split into several possible options. It is unlikely that a problem is so simple that there is only one option available to solve it. Having options at our disposal is always a desirable thing.
We then choose one option that seems to promise the best outcome. We move that option to the next column to the right and we label that column “Possible experiments”. Each experiment could be defined with three attributes:
Action: which action is the experiment proposing?
Duration: how long is the experiment expected to run?
Expectation: What is the expected desired outcome of the experiment?
From that position the work continues by picking one of the possible experiments and moving it to the next column to the right — “Committed experiments”.
Once the experiment gets committed, we move it to the next column to the right — “Ongoing experiments”.
The experiments selected to be worked on (i.e., the ongoing experiments), must obey the constraints of the Work in Progress (WIP) buffer. Small batches are de rigeur here. It is best if at any point in time no more than a couple of experiments are being worked on. Because we strive to keep the WIP buffer as small as possible, there could be a number of committed experiments waiting for their turn in the “Committed experiments” column.
When the experiment is finished, it moves to the column to the right — “Review”. During the review, we ask some questions, such as:
What did we expect to happen (i.e., the hypothesis)?
What had actually happened?
What did we learn?
What opportunity do we perceive?
Based on the answers to the above questions, we now move to the next column to the right — “Next”. In this column, we try to answer the question:
Based on what we learned, what do we need to learn next?
Which leads us back to the leftmost column — “Problems”. The work thus progresses smoothly from left to right.
POPCORN Flow
The columns on our board, from left to right, are:
Problems and observations
Options
Possible experiments
Committed experiments
Ongoing experiments
Review
Next
Reading the capitalized letters, it spells POPCORN. So, we can call it the Popcorn Flow (a handy mnemonic to help us recall the correct order of the workflow; originally proposed by Claudio Perrone, a.k.a. Agile Sensei).
Why is this workflow useful? It comes from the recognition that the best way to respond to challenges is to collect feedback. Rather than formulating the solution to the challenges by working in isolation, it is better to face the challenges head-on and start getting feedback by experimenting.
An example
I will use a hypothetical example to illustrate the Popcorn Flow in the workflow board. For brevity, I will present only two problems (and inhere I won’t include the experiment details, nor the anticipated duration of the experiments):
Insufficient understanding of the benefits of Test Driven Development (TDD)
Lack of actionable metrics for code quality
The first problem was solved by entertaining three options:
Ignore the problem
Suggest some reading material
Organize a tailored presentation for the staff
After some deliberation with the team, option 3 was picked to be worked on, and it generated two possible experiments:
Publish a wiki article explaining the benefits
Organize lunch ‘n learn session to present hands-on demonstration of TDD to interested audience
Out of 2 proposed experiments, experiment #2 was picked and committed to work. Once the experiment was completed (i.e., the hands-on demo session was delivered), we performed the review (i.e., a retro, or Inspect and Adapt). From the review we examined the possibility of having the next learning opportunity.
The second problem was pulled in with #3 possible options:
Let teams decide how to respond to code quality issues
Instigate code quality review by mandating PRs
Automate code quality review by adding static code analysis to the CI pipeline
Option #3 was then pulled into the next column, where it generated 3 possible experiments:
Give the team several iterations to work on improving code quality
Implement branch protection policy rules to automate PRs
Implement DeepSource tool in the CI pipeline
Experiment #3 was then picked as a committed work item.
After the experiment was completed, we spent some time reviewing the outcomes. We realized that the experiment yielded too many false positives. Moving into the Next phase, we decided to repeat the experiment by lowering the threshold in the hopes that it will reduce or maybe even eliminate the false positives.
Conclusion
Change comes with challenges. Those challenges present us with the opportunity to work. We practice picking our battles wisely and also practice knowing when to cut our losses.
Visualizing the workflow is a helpful heuristic. There are many ways to visualize the progress of the work, but such visualization cannot help solving the problem. The problem can only be solved by experimenting and gathering feedback. After accomplishing that, we apply validated learning and obtain insights into what should be done next.