Mind the WIP to Become Effective, Not Merely Efficient

Mind the WIP to Become Effective, Not Merely Efficient

“Efficiency is doing things right, while effectiveness is doing the right things.”

We’d all like to be efficient.  We’d love to show our boss how cheaply we can get something done, compared to all her other options.  We’d like to have extra time, maybe to clean up, beautify, or just goof around.  Efficiency is the hallmark of mass manufacturing.  If we build it for less, we have more profit to put in our pocket.  But did you ever consider that when we build software in situations where resources and dates are fixed that you’re making a huge, risky bet?  I venture to say that you’d rather ship 80% of your product features on a certain date (and have least valuable 20% left over for “the next time around”) than be 90% done on everything and have absolutely nothing to ship on that due date.

You probably have 2 questions at this point.  “How could that be?” and “How can I be effective, and not merely efficient?”  The answer to both questions is found in three tiny letters – WIP (work in process).

It all begins with estimation

Let’s take an easy example for this piece.  Here’s a list of things that we’d like to develop some software for and release to our new website in the next 90 days:

  • Allow website users to search for and display lists of items in our warehouse
  • Give website users the ability to display pictures and details for an item that they select
  • Give website users the power to display real time inventory status for an item that they are looking at
  • Give website users the ability to create a “shopping cart” of quantities of items that they select
  • Allow website users to complete a transaction and pay with credit card(s), PayPal, direct checking account, or any combination thereof

Assume that since we only have 90 days, the Delivery Team that we have, is the army that we will use. The 90-day window is non-negotiable, because we paid a zillion dollars for a Super Bowl ad that will drive traffic to our website on that fateful day.

If you’re a traditional, plan-driven project manager sort of person, you probably do this project by first decomposing the software stack into components that we’ll put together, and then create a project plan that pulls people, time, and dependencies together and convinces us that everything will be fine.

  • Database for the warehouse items
  • Component to access database
  • Website functionality for search
  • Website functionality for display
  • Website functionality for real time inventory
  • Website functionality for adding, displaying, deleting, and modifying items in the shopping cart
  • Component for integrating our warehouse system with the website real time inventory status
  • Component for implementing the shopping cart on the server
  • Component for credit card processing
  • Component for PayPal processing
  • Component for checking account ACH processing
  • Component for payment coordination between the various processing options

OK.  Got the list.  Get some estimates from various people.  Assign developers against the tasks.  Adjust estimates to make everything fit inside that 90 day window (Tell me that you’ve never done this.  Be honest!).  Announce “It’s going to be tight, but the plan demonstrates that we can do this.  So, let’s get going!”

With software, the odds of everything working in your project plan are a lot like your odds of hitting the Trifecta

But here’s the rub.  Estimates are made for things that we haven’t previously done.  We use our best effort to understand and give meaningful honest estimates.  And we do.  But the uncomfortable truth is that effort-based estimation for software construction is highly variable, due to a variety of factors:

  • Uncertainties with how to do things that we’ve never previously done.  For example, we’ve never tried to interface with our mainframe based warehouse system before.  We may find little nooks and crannies of problems and issues which we must solve to permit the integration that we never considered when we gave our limited “happy path” estimate.
  • Uncertainties around what things we should actually build.  For example, should that real-time warehouse inventory level stop people from adding items into their cart? Stop them from completing a transaction? Or just ask them if they want to place the item on backorder?  We’ve never done this with customers before, and we can’t be sure that customers will bring us enough value to cover our costs of development, since we’ve never before given customers this ability.  If we have to re-do a lot of work for a fully fleshed out feature, that could cost a lot.
  • Uncertainties based on who actually does the work.  Your best developers may be 10 times (or more) productive than your least capable ones.

And then we completely hide that variability in estimates by expressing a single number for the estimate.  The estimate, even though it is expressed as a single number, is really a probability curve.  It might look something like this:

Graph Source

And, finally, we completely compound and confound the problem by linking the tasks together with scheduling dependencies.  “We can’t start/finish this task before finishing/starting that one” (either because of software functionality dependencies or resource dependencies). Our project is a hope, wish, and desire that everything goes according to plan, even though we mathematically know that things will go wrong, and will start to cascade through the chain of scheduling dependencies.  If we start creating the compounded probability of arrogated estimates, we start to see that the nice peak on our bell style estimate distribution curve starts becoming very short and wide.  And our chances of hitting our estimate square on are about as likely as picking the “win, place, and show” horses, in order, at the track.

Yet somehow, seeing everything fit together in a nice Gantt chart that magically ends right on target makes us feel safe and sound.  At least when we start.  But without fail, almost every project plan that I’ve been around goes sour quickly.  One late dependency quickly snowballs into an avalanche of late tasks that just compound and worsen. Blame starts getting metered out.  Morale goes through the floor, and when we’re living the day before the game, we try to integrate everything, and nothing is working.  And now that the business sees the real time inventory status in action (when it sort of works) they aren’t sure that they want it, as they now realize that when people see that an item won’t be in stock for a couple of weeks, they may decide to go elsewhere!  But we’re so afraid that pulling out the code will break 20 things against the middle.  So, it’s part of the deployment, like it or not.

Our attempt to be hyper-efficient and get each and every feature working the day before the end suddenly becomes an #EPICFAIL when things don’t work on Super Bowl Sunday.

That’s horrible!  What’s a Mother to do? 

What if we turned this on its head?  Let’s say we start with a single ranked ordered list something like this?

  1. As a website user, I want to search for items to purchase using words in an item’s description, so I can find things to buy.
  2. As a website user, I want to display an item’s description, price, and primary picture, so I can decide if I want to purchase it.
  3. As a website user, when I click the “Buy It Now!” button on an item’s display page, I want a quantity of one item placed in my shopping cart so I can purchase it when I’m done shopping.
  4. As a website user, when I click the “Proceed to Checkout” button, I want my shopping cart displayed with checkout options.
  5. As a website user, when I click the “Purchase Now!” button with the “Debit My Checking Account” option clicked, I want an ACH setup to my checking account for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: this transaction is free through our bank.  Yay!
  6. As a website user, when I click the “Purchase Now!” button with the “PayPal” option clicked, I want my PayPal account to be debited for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 1% merchant fee on PayPal transactions.
  7. As a website user, when I click the “Purchase Now!” button with the “Mastercard” option clicked, I want my Mastercard account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 2% merchant fee on Mastercard transactions.
  8. As a website user, when I click the “Purchase Now!” button with the “American Express” option clicked, I want my American Express account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 4% merchant fee on Mastercard transactions.
  9. As a website user, when I want to be able to change quantities and delete items in my shopping cart when I am checking out so I don’t get frustrated with a shopping cart that is not exactly what I want to purchase.
  10. As a website user, I want to display an item’s auxiliary pictures, to help push me to clip the “Buy It!” button.
  11. As a website user, I want to display an item’s real time inventory status, to help me decide if I want to buy the item now.  Note: the website user may decide to not buy the item when they see that it’s not in stock.
  12. As a website user, when I click the “Purchase Now!” button with the “Multiple Credit Card” options clicked, I want the ability to setup a complicated transaction [details to be thought through], so I can become a happy and loyal customer.  Note: we have to figure out technically what happens here, how to back out of scenario such as having one card going through and a subsequent card failing.
  13. As a website user, I want to backorder an item that real time inventory shows as out of stock so I can eventually purchase the item.  Making this happen will invoke a workflow involving eMails, order cancellation, and other things.

Notice what happens when we start to develop one thing at a time, in this order, and get feedback from the business as we complete each of these items.  If we got some of the details wrong (it happens all the time!), we can immediately get that right before we move on.  When the business says “Good!” on each item, we then get our deployment to stay “always ready to ship”.  If we run out of time, we may not have every feature completed, but we always have something to show on Super Bowl Sunday.  We’d like to get through the whole list, but we don’t even really know the details for some of this yet.  But we have enough to get started.

What was different?

That’s easy.  We minded the WIP.

We made sure that we had the highest value items worked first, and did one thing at a time (“Single Stream Flow”, in Lean terms).  We were always ready to ship.  That allowed us to work right up to game time without fear that integration would ruin things.  We didn’t have to worry that we wouldn’t get to go home for the next two days, subsisting purely on Mountain Dew and day old pizza.  We concentrated on delivering value one step at a time, from most important to the least.

That pivot to focusing on business value, rather than figuring out the optimal plan that gets us to done can be a huge mindset change for some organizations.  Sometimes, managers are afraid that someone won’t have something to do when the team is working through the business value ordered backlog of functionality to create.  But remember, every time we add to our WIP, we create the potential that dependencies will keep us from being ready to ship.  We create the potential to very efficiently work on lots of stuff at once, but have nothing to show for it when the clock runs out. That’s not very smart.  And it’s awfully risky. It sure isn’t an effective way for your organization to work.

The prime directive is effectiveness – efficiency is only secondary

I don’t know how it works for your business, but for mine, I’d rather deliver 80% of the highest business valued items and leave the remaining 20% of lowest value items for sometime in the future.  I really don’t want to be 90% done with everything, but having nothing to show for it when the clock runs out, because that last 10% was needed to get anything to work.

For me, Meatloaf said it best, almost 40 years ago.  “I want you, oh, I need you.  But there ain’t no way I’m ever gonna love you. Now don’t be sad, oh, ’cause two out of three ain’t bad.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.