What Charity Showed Me About Flow

The other day, I participated in a charity event for Feed My Starving Children. This post is not to show how good of a person I am, for one does not do charity for recognition’s sake (the actual act of charity is reward enough). However, before I talk about some of the things that struck me as I was participating, I’d like to note that FMSC is a very worthy organization, worthy of one’s time, and if you see fit, worthy of one’s donation.

A FMSC event, at least as I have seen, is organized thus: they come in and take over an organization’s large room, and fill it with packing stations. At these stations, teams of around 10 (not sure on exact number) work together to measure out an amount of various ingredients, which make up a single meal, into a bag. The bags are then sealed, boxed, and sent to be placed on pallets, loaded up and shipped out. Folks participate in a two hour shift. They do a brief training before, and a brief after action review. Super high level view, but I think you get the idea. Here’s one of their videos, if you’d like to see some in action.

During my particular shift, I was working “Warehouse”, which is designation for the folks who support the table crews. I thought, firstly, that it might require less attention and activity than a packing table job (I was wrong!!). I also thought it would be interesting to see the flow of activity from place to place (I was right!). I was also joining a buddy of mine, who had worked the previous shift (his wife helps organize this whole event through the church of which they are a part, so shout out to Alicia and Journey of Faith church in Redondo Beach) doing this job by himself, for the most part.  It didn’t sound too difficult, however, we expected higher volume this shift due to crew makeup (more adults), and so we had a third gentleman as a member of our little logistics crew.

The finishing table consists of weighing each box as one of the “runners” delivered it to us, to ensure it was in the acceptable weight range (and therefore correctly packed based on quality controls no doubt done at the filling stations), sealing the boxes, marking the date and shift, and loading them onto a pallet. Once a pallet was fully loaded, another crew took our product and finished it for shipping. We quickly decided on roles, I would weigh and verify the boxes as they came in, my friend would settle and seal the boxes tightly, and the third member would mark the boxes once sealed, and load them onto the pallet.

Off goes the horn, and away we go. We have a bit of lag time at the beginning, as the teams begin to get their bearings and begin production. As the first few boxes begin to arrive to us, our flow works well, and the first few boxes go off without a hitch. However, the teams are now getting their stride, and runners are bringing full boxes more quickly. We run into our first issue, when multiple runners arrive at the same time. Only one box can be weighed at a time, so the runners dropped the boxes and moved on to the next. Unfortunately, the input and output stream get mixed, and we have no way to tell which boxes have been already weighed. Therefore, I needed to reweigh a few to ensure they were all correct, and none were missed. Quickly, we shifted, and I grabbed a marker, figuring that if I marked shift and time as I verified boxes complete, then we would know what can be sealed without me having to watch.  We powered through our bottle neck, and got back on track. In a lull between some boxes, we discussed the change as a team, so we all knew how boxes were shown as verified. Yay, problem solved!

We kept ticking, and fillers kept filling. We were receiving boxes from one a few at a time (which would be a great study on asynchronous delivery, but I will try to stay just where I was for now), but our process held up, and we were processing items through pretty well, continuing flow. That is, until there was an issue with one of the pallets that we had already finished, and my buddy had to pull off to help get that fixed. While we adjusted, and worked the best we could, this had multiple effects. For example, we’d suddenly lost a large portion of our processing ability, and we both had to fill in his role, while still trying to do our part, which from positioning was inefficient. Our team was too small to handle losing a member, and our process too tightly coupled. Due to this, we developed a bottleneck nearly immediately. Since work was piling up in the center of our process, when I went to help with that, work began to pile up at the beginning of our queue. This also had an effect the efficiency of the runners, as we were not as prepared to accept work from them. My friend was only away for about 5 minutes, but we had piled up about 7 boxes into our bottleneck by the time he’d returned. When he returned, we still had items mid process, and it took us about 15 more minutes to clear out our bottleneck and get back to a state of flow, where we were processing input as it arrived (about 3 times as long as he was gone!).  From this, we learned that if someone stepped off for an issue or a break, we had a member of the support crew (who could fill any role, as they were from FMSC) fill in. They may not have been as efficient, as they had to adapt to our flow, but it helped avoid major bottlenecks.

There were other various instances of inspect and adapt during the process, that I was aware of: reordering the table gave a visual indication of flow direction (improving the experience for the runners, and limiting mixing of processed and unprocessed data), orienting the boxes in the same direction as they came of the scale (facilitating both verification marking and sealing), and improvements on preparations for pallets (facilitating removal of completed work, and preparations for the next load). All of this, in a single two hour session.

A few key takeaways:

  • Don’t wait for a retrospective to inspect and adapt. Constantly be looking for ways to improve, and experiment (but make sure your team is aware!)
  • Achieving system flow is more important than achieving local optimization. Any improvements I make to my process are for naught if they negatively effect other parts of the flow.
  • Losing team members to “special projects” hurts the individual and the team. The individual loses connection, and the team may not have the skill or work ability to replace. The effects are far reaching, and a small gain at one point can cause a much greater loss elsewhere. If it’s good enough for one of us, it’s good enough for all of us; if it’s not good enough for all of us, it’s not good enough for any of us.
  • If the world was perfect, we’d all have exactly enough work to keep us busy without over loading. The world is not perfect. Flow is hampered when there is more work then can be done in a given period. Overloading a part of the process flow has far reaching effects before and after the single point. It is therefore better to do less than is possible, then to try to do more (when it can be set up that way!).
  • Above all, doing something for someone else is an uplifting experience. The rising tide raises all boats, so elevate someone else to elevate yourself. It feels good, and who knows what you might learn!

Our shift, by the way, was at that time the most productive shift of the event at the time. It was more than double of the previous shift my friend had done. We had no major issues, and everything went off pretty well. Past experiences can sometimes prep us for the future, but always remember that something may just come and blow your expectations away.

Once again, FMSC is a great organization, so if given the opportunity, I recommend supporting them as you see fit. Thanks to everyone that helped, and I hope that in some small way, both my efforts that night and my interpretations of them after the fact, helps you.


Scrum Teams vs.Online Team Gaming Mechanics

In a great blog post from Coding Epiphany from 2015, cross functional Scrum Teams were compared to RPG parties, mainly focused team makeup, skill specialization versus crossing roles and forming a team as you go.  It’s awesome and nerdy.  I had a similar idea, but instead of that comparison, I wanted to compare a Scrum Team to Team Mechanics from online gaming, mainly MMORPG or maybe some team based shooters. Continue reading

The Case for Dedicated Scrum Masters

“All our Scrum Master, Bob, does is sit around all sprint. I mean, he’s there for our Daily Scrums, and Sprint Planning. He goes to our Sprint Review and watches the stakeholders, and he asks a lot of questions in our Retrospectives, but what does he do the rest of the time? It’s not like he’s writing code…”

Have you heard something similar to that before? Maybe even said it yourself?  It’s a pretty common refrain, and one of the driving forces behind the idea that we can have part time Scrum Masters, and still be as effective as we think we should be.  Continue reading

Where Should We Go For Dinner? Decision Making and the Fear of Rejection


We are all faced with decisions to make every day. Paper or plastic, regular or decaf, what’s for dinner… so many choices. When we’re alone, we take into account our own feelings, bias and knowledge, and usually come up with some kind of action or response, often because we have to or that guy who really needs a coffee is right behind you.  However, once you start adding other people to the decision making process, things start to get muddy. Take, for example, the classic dinner conversation:

Person A: What do you want to get to eat?

Person B: I don’t care, whatever you want is fine.

A: I dunno, either, that’s why I asked you. Well, what about Pizza?

B: Nah, I don’t feel like having pizza.

A: Oh… OK. Well what do you feel like?

B: I dunno, you pick.

I’m sure just about everyone has been on one side or the other of that conversation.  The thing is, this conversation happens all the time in every group of people. Observe:

Teammate 1: I propose we spend an extra hour each week doing research on new methods of data access.

Teammate 2: I’ll go with whatever the team says.

Teammate 3: Doesn’t matter to me.

Teammate 4: I agree with 2.

Teammate 5: <Crickets chirp>

And so on and so on…

So what happens here? Well, either the team goes with the suggestion, based on one person’s input, or no one feels strongly enough about something, so the question lingers. Let’s look at what can happen in these cases:

  • The team goes with the suggestion, and they like it: The team will be more willing to go with the suggestions of Teammate 1 without thinking critically about it. The team has given up ownership and self-organization to one member. Teammate 1 may feel the burden of being “the guy/gal with the ideas”, and stress over needing to come up with all the plans.
  • The team goes with the suggestion, and it fails: The team can engage in finger pointing at Teammate 1, after all it was his/her idea, and I never said I actually agreed. Teammate 1 feels called out, leading to rifts in the team, or causing him/her to withhold new ideas from the team, even if they’re good. Other members of the team see how Teammate 1 was treated, and are now wary of putting their ideas out there.
  • Lacking motivation, the team maintains the status quo: If there was a potential issue, it continues unaddressed. Teammate 1 is left in limbo, unsure whether to push forward with his/her idea, or to drop it. Teammate 1 feels disrespected, since no one was willing to consider his/her idea long enough to form an opinion. All teammates recognize group apathy, and choose not to share new ideas.

For Agile teams who want to be high-functioning, this is a major problem. There is a lot of psychology behind why, as humans, we prefer not to make decisions. You can find that on the web, so I’m not going to go into that here.  In my experience, however there is one major force in play:


People fear giving their opinion.  By giving an opinion, you open yourself to rejection. You open yourself to conflict. You open yourself to looking weak because you are ill informed. And you open yourself to the worst thing ever: the possibility of being wrong. Nobody wants to be wrong. When you are wrong, it’s even harder to admit it. Sure there are other possible reasons, like a lack of respect for the questioner (so much so that you can’t be bothered to have an opinion), or being too distracted to answer fully (generally better to state as such), but generally when faced with a normal decision to be made, if we choose not to give our opinion, it is out of fear.

People feel like by saying “I’ll go with the team” they’re providing tacit approval to ideas their teammates come up with.  In reality, all they’re doing is passing the buck and hoping someone else will do the thinking for them.  It’s a disservice to the the both the person asking, and the person answering.

So what do you do if you really don’t have an opinion? Well, communicate and negotiate. For example, “I don’t really understand what an extra hour of research will do for us. What do you think we have to gain from this?” Once you understand the question, do your teammate the service of giving your honest opinion.  If you disagree, have an open and honest conversation as to why. If you really agree, give a firm agreement, and stand behind your statement.  Nothing is gained by delaying conflict if it needs to happen, and much can be lost if feelings are hurt.

The best thing? You can apply this anywhere! Let’s look at the ideal way of handling the “Dinner Problem”.

Person A: What do you want to do for dinner?

Person B: I hadn’t really thought about it, do you have any suggestions? What do you feel like having?

A: I don’t really want anything fancy, quick and easy for me. What about you?

B: I’m still not really sure what I feel like having, can we go somewhere with a lot of choices?

A: Quick, easy and lots of choices? You know, there’s that food truck night at the local school tonight, why don’t we go there?

B: OK, I can agree with that. Sounds like an adventure!

Well, that seemed a bit too easy, maybe we can dream about that last one…