Batches? We don’t need no stinking batches! (Or do we?)

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.

Categories: Agile, Project Management | Tags: , , | Leave a comment

Think top-down and bottom-up for agile transformations

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:

  • Delivery teams don’t work in isolation and hence buy-in to change how things are done will be needed from all supporting areas including human resources, finance and procurement.
  • There will be the need for funding investments such as training, coaching, tooling and potentially even staffing new positions.
  • Without changing existing portfolio intake practices and performance measures (e.g. shifting from a focus from maximizing utilization to maximizing value), it will be hard to achieve the full benefits of the transformation.
  • To shift the established behaviors of middle management towards an agile mindset, the executive team needs to model the desired target behaviors first. Not only will the executives need to be coached to get there, they must also agree to hold each other visibly accountable to this new way of working.
  • There needs to be a unifying vision for the transformation as well as a roadmap for how to get there. The executive team must be fully engaged in the creation of these key deliverables.

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:

  • Develop the details of the new ways of working and inspect and adapt those over time.
  • Feel comfortable designing and conducting experiments and having the occasional setback with those.
  • Be willing to take on new roles and responsibilities.
  • Be open to providing stakeholders with a greater level of transparency into their work and work flow than they have been used to.
  • Collaborate openly with contributors from other functional areas whom they previously might have just cooperated with.

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.

Categories: Agile, Facilitating Organization Change | Tags: , , , | Leave a comment

Why project work doesn’t get completed early…

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:

  • If staff are measured based on utilization, then completing work in less time means they are either going to be reprimanded or handed more work which they might not be able to complete by working a sustainable pace.
  • If they are paid based on the hours they work, they could be tempted to work to plan to avoid being financially penalized for completing early.
  • If they are measured based on the accuracy of their predictions (I.e. they are penalized for being early or late), then the work will tend to be completed exactly on time.
  • If they are forced to fill out weekly timesheets and the process to do so is onerous, it might be easier for them to just copy planned time over as actual time within their time recording system.

Managers can also inadvertently cause staff to complete work on time, but rarely early by:

  • Penalizing team members who complete work early on their future tasks by setting unrealistic target dates
  • Giving them additional projects or operational activities to do rather than letting them use that slack time productively
  • Breaking their focus by interrupting their work with urgent but un-important tasks

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.

Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , , | 1 Comment

Create a free website or blog at

%d bloggers like this: