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.

Advertisements

Agile Meetups and the Local Community

One of the greatest things about Scrum and Agile is the community of which we are all a part of.  Generally speaking, Agile Professionals, Scrum Masters and Agile Coaches are some of the nicest, most helpful people you can meet, and it shows in the community.  There are many blogs, online communities, and local meetups, all provided free of charge, where aspiring Agilists can go to gain knowledge and learn about different view points and techniques from some of the greatest and most prolific practitioners in the industry.  Local meetups embody this ideal, where a novice can attend a lean coffee, ask a question and get answers from peers, and often from very experienced Scrum Masters or Coaches who attend due to the love of Agile.

I’ve been attending Agile Meetups for years now here in the Los Angeles area, mostly with a group called Agile/Scrum LA.  They usually meet once a month, sometimes as an organized presentation event, but more often as an informal gathering known as Lean Coffee.  In Lean Coffee, the attendees each select a topic or question they’d like to speak on, write it on a card, and give a brief overview to the group.  The group then votes on which issues they are most interested to talk about, and the ideas are stack ranked for discussion. Then, a time boxed discussion is held about the topic, where the group can discuss more in depth. At the end of the time box, the team gives a thumbs up/down vote on whether to continue the discussion, or to move on to the next topic.  It’s a great event, using a microcosm of what makes Agile and Scrum work to talk about other things Agile.

I also recently started attending events down in Orange County, including my first Agile Drinkup.  This was an even more informal event, where a group of folks interested in Agile got together, had a few beverages, and just talk about some of our concerns, commonalities and community. It was great fun for me just to get out and pick the brains of people who have great experience being in this space, and the networking I was able to do may possibility help me find my next role as my search continues.

All in all, I heartily encourage anyone who reads this to take some time and join an Agile meetup. It’s one night a month, and the experience gained is far greater than the time cost. Also, the hours are applicable for the Scrum Alliance continued learning for certifications, so that’s a good bonus as well. I will post links to a few of the meetup groups I’m a part of below. Thanks for reading, and if you know of any other meetup groups in this space, please leave a comment below!

Agile/Scrum LA – Co-Hosted by Tyler Feiga & Jhade Barnes – A great group local to the West LA/South Bay area of Los Angeles. Lean coffee and some presentations.

Agile Coffee – a SoCal Lean Coffee Group – Co-Hosted by Vic Bonacci and Brett Palmer – Local to Orange County, I’ve had some great discussions here.

Agile Drink Up – Hosted by Dan Brown – I’ve only been once so far, as a co-hosted event with Agile Coffee, but I definitely plan to continue attending. It was a great time, and great conversations.

Thanks to all of the Agile Meetup Organizers for all that you do!

User Stories

Wow, it’s been a long time since I’ve posted!  Let’s rectify that!

I recently had a friend, who is moving into a new role working with a Scrum team, ask me about writing user stories, and if there was any specific training around creating them. After we finished the discussion, I recalled that I had created a presentation regarding user stories a while back. I’d like to share the presentation, and make some comments.

Power Point – User Stories

The presentation is linked above.  During this talk, it was important to emphasize the idea of “Outcomes over Output”, as the recipients of the presentation had historically been very directive and focused on directing output from contributors.  Changing this is a two-way street, as self-organization requires not only commitment from the team to organize themselves, but also commitment from leadership to allow for that organization to happen.  User Stories are one tool in that process, moving away from directive “micro-management” and more towards inclusive co-leadership.

This is just one in a series of presentations I’ve given in a series I’ve called “Ongoing Agile Education”. It was provided to a group who understood the basics of Agile, allowing for greater focus and discussion on a single topic.  If there is interest, I do have other Power Point presentations from this series that I may be able to post.

As always, I appreciate your feedback!

Estimation: Story Points and Time to Complete Are Not The Same

Story points are a pretty ubiquitous part of Agile by now.  In Agile, we use the idea of story points to add a layer of abstraction to estimation, to allow us to estimate based on relative size, and to stop ourselves from ascribing a false level of precision to our estimates. One thing that is always described as an Agile Anti-Pattern is basing your estimates or story points on how long one believes something will take to complete. Let’s take a bit more of an in depth look at why that is.

The premise

Throughout this example, I’ll be representing work being done in the form of eating apples, and other foods may make a guest appearance.  Apples are generally of a similar size and makeup to one another, and assuming there are no worms, they are also of similar complexity and risk, so we’ll use those to represent items of work that are also of similar sizes and makeups.

Everyone doesn’t work at the same rate

Let’s start with two apples. We’ll give two different people one each of those apples. Without any other context, you may believe that these two people will take about the same amount of time to finish eating those apples, and that may, in fact, be true. But what if one of those folks is a child? Or a world class speed-eating champion? The time they will be working on eating the apple may vary, but the outcome is the same: one eaten apple.

It’s the same when looking at work. Two people may take a different amount of time, even working on the same item, due to a number of different factors. That doesn’t change the size of the item being worked on, or the value you’ll derive from it’s completion.

Outside factors can change the time to complete

Other factors can also effect how long it takes to do something, without changing the size of what you’re doing. Let’s take one person eating one apple. Did said person just eat a huge lunch? Maybe they’re having dental issues? Any number of factors can change how long it will take to eat the apple, without changing the size of the apple.

The same can be said about a story.  There may be outside dependencies or blockers slowing down progress on an item, but that doesn’t change the size of the story itself, just the speed at which it can be done. Padding estimates due to known external factors comes with it’s own set of concerns, but suffice it to say that it doesn’t do any one any favors. (Note: This is assuming similar levels of uncertainly and complexity. Stories lacking clarity or those which are highly complex should be estimated higher… it’s a good lead in to another post for another time)

Improvements are not properly reflected, or hard to see

This time, lets take one apple, to be shared by a family. This family can take bites of the apple, and pass it around until it’s finished. By doing this, the family can eat one apple in 20 minutes, so lets say it earns them one “food point” in 20 minutes.  The family talks about it, and they determine they can share the apple better by slicing it, and eating pieces at the same time. This lets the family eat two apples in the same 20 minute time period.  Now, if they base the “food point” on the time it takes to eat the apple, and they said 20 minutes is the basis for a food point:

pointper20mincorrect

 

This means by improving their apple-eating methods, they actually decreased how many points an apple is “worth” in their scale. Note the apples haven’t changed in size, complexity or value.By doing this, the family’s velocity is 1 point, as they are still doing 20 minutes of work, however they completed twice as much.

Now, let’s base the points on the work item itself, by saying 1 apple = 1 point. Originally, they had completed 1 point per 20 minutes, and now they can complete 2 in the same time frame.  Therefore, their velocity increased from 1 to 2. (Also, look how much more simple that math was! Work smarter not harder…)

At the end of the day, both of these mean the same thing: twice as much work is being done in the same time period. However, by basing our abstraction on the work as opposed to the time the work “should” take, it is far easier to track how much our actions effect our output.

In conclusion

With estimation, we take a guess as to how big things are, to help us plan and scope.  We understand it is a guess, so we abstract this guess, so that we focus more on being roughly right as opposed to precisely wrong. When we abstract, it’s important to base our abstractions on values that can the most consistent and easiest to compare to a baseline, and in most cases, its generally work being done.

Questions about this, or comments? I’m always up for a good discussion. Please drop me a line in the comments below!

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

Return of the Zan

Welcome back everyone, to the return of my little blog, the newly re-christened Zangile Manifesto.  It’s been some time since I’ve posted, but I’ve had some requests to get back to it, and I did miss posting, so here we are.

My plan is to be less forced regarding posting, less regimented, and more free form. Hopefully I can make posts more varied, with some quick takes mixed in with some of the longer form posts that made up most of my posts the first time through.  In the time I’ve been neglecting my blog, I’ve obtained my CSPO, so hopefully I’ll be able to bring some more varied information and viewpoints as well. I’d love to get your feedback on topics and responses as well.

One more piece of housekeeping, as soon the updates propagate throughout the various servers out there, I should have a new address with which to find my blog: zangilemanifesto.com! All the old links should still work, however, I take it as one more step to being a bit more professional with this blog, and taking it a bit more seriously!

Thanks for reading, and please leave a comment below!