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.