Emphasizing flow through the reduction or elimination of batching of work items is desirable but this is not always efficient or practical.
So what are some of the factors which might force us to batch work items?
Whether it is equipment, materials or people's time, constraints are a common reason for batching work.
Let's say we wanted to build a fence for a customer. While it might be better for the home owner for us to complete the full work for one section of fence at a time so that if the work spans multiple days the homeowner would progressively be receiving value, we might be forced to dig all the post holes first because we only have the use of an auger on the first day.
Maybe we are writing a software application which needs to have both English and French messages and we have no one on our team who can do the translation. If we only have access to a translation service for a week, we might need to batch the translation of all the screen messages and until that is done we can't ship the product.
Sometimes there might be a mandatory dependency that prevents completion of subsequent work activities till a preceding one is completed for the entire batch. When building a house, you would normally wait for the entire concrete foundation to be ready before we'd start building on top of it. When frosting a cake, it doesn't matter if half of the cake is baked - we'd wait till it is fully baked.
Economies of scale or a minimum requirement on how many work items can be efficiently produced might be another reason to batch work.
If I want to bake cupcakes, although the cycle time to bake and frost one cupcake is likely to be less than that of completing a dozen identical ones, the costs of wasted energy and ingredients from doing them one at a time would start to add up. Unless I have a customer who is willing to pay me that much more to justify producing single cupcakes, I'm likely to make them in batches.
This applies even if I'm trying a recipe for the very first time. While the volume of ingredient wastage would be reduced by baking a single cupcake, the benefits of baking a batch are still greater.
Or maybe I need to print some color business cards for newly hired staff from a printing agency. While there would be a per card cost, the overhead costs of setup, proofing and shipping might justify waiting till there are a few new hires rather that printing each set individually.
While some of these factors might present opportunities for continuous improvement to our delivery process, others are unlikely to be reduced or eliminated. We may wish to avoid batch work, but we do need to be pragmatic and accept that context counts.
A question which I'm asked regularly during my classes is what the best place is to start an agile transformation within a company? Given a choice, I'd prefer to use the cop-out (but correct) answer "It depends", but otherwise I usually respond that you'd want to do both a top-down and bottom-up approach simultaneously.
A common approach for major organizational changes is to start at the top with executive leadership, creating a coalition of commitment and support towards a shared vision for the future. This is critical with agile transformations for a number of reasons:
But there will also be the need to have engagement at the delivery team level. If individual team members are comfortable with how things are working and have no sense of urgency about the need for change, then their support will be superficial. Their buy-in is needed to:
While these outcomes are needed, a key benefit of taking this top-down & bottom-up approach is that it will create a "sandwich effect" squeezing those middle managers who are unwilling to change how they work. Without that outcome, it is unlikely that an agile transformation will succeed.
I usually advise my students to encourage their team members to not provide padded work estimates, but rather to make schedule contingencies visible and tie these contingencies to milestones rather than to individual activities.
This is intended to counter the potential confluence of Parkinson's Law (work expands so as to fill the time available for its completion), Student Syndrome (let's wait till the very last possible moment to start an undesired activity) and Murphy's Law (anything that can go wrong will go wrong).
While this behavior might be true in some circumstances, it is based on a rather Theory X view of the world. Student Syndrome hurts no one other than the student procrastinating on starting their homework assignments or preparing for an exam. With projects, the impact of delays from one team member ripple downstream to others so with the exception of that small minority of Homer Simpson-like workers most of us want to do a good day's work.
So if the fault doesn't lie with the individual contributors, where else could we look for answers?
Today's Dilbert cartoon provides us with better root causes for this behavior - the system which people work in or the managers they work for.
How could the system affect work completion? Poorly thought out performance measures are one way:
Managers can also inadvertently cause staff to complete work on time, but rarely early by:
If we recognize that project activity durations are more likely to follow a lognormal distribution than the nice symmetrical normal distribution which we hope for, then we should praise team members for completing work early (within quality, safety, health and other constraints) rather than introducing impediments which discourage them from doing so.
Lean thinking encourages us to focus on maximizing value delivered to stakeholders rather than maximizing the utilization of the people, equipment or material resources contributing to value streams.
Two reasons for this recommendation are:
While managers might accept the above in principle, they might raise some concerns. If we don't maximize the utilization of our team members, how will they be adding value when they aren't contributing directly to the value stream or streams they are part of? After all, we are paying them for a full day's work so shouldn't we expect a full day's work out of them?
While some managers might worry that their team members' slack time will be misused for slacking off, there are multiple productive ways to use this freed up capacity including:
Without some free capacity, your team members might be inspired to quote Scotty from Star Trek: "I've giv'n her all she's got captain, an' I canna give her no more."
I'm always happy to learn something new when it relates to the topics which interest me and even more so when it is something which I should have run across long ago. During an event this week, a participant shared that their secret facilitation power is holding space for the participants. I must have been living under a rock for the past three decades as I'd never heard of this term even though it is a core component of the Open Space approach which has had significant influence in the broader agile community.
When holding space was first described to me, it sounded almost identical to creating psychological safety within a team but after reading further I feel that there is an overlap between the two approaches rather than an equivalency.
While there is no single accepted definition for holding space, here are two frequently referenced ones which helped me better understand the concept:
What are some of the similarities between the two concepts?
But there appear to be a few differences too, including:
Our abilities to hold space and to create psychologically safe environments are complementary but are both equally critical to becoming effective leaders.