Wednesday, October 21, 2015

Who is the Decider?

When it comes to decisions regarding software, it is generally the business who decides what needs to be done, when to do it, what will not be done, and even how to do it. There are so many decisions to be made, some requiring intimate knowledge of the business at hand and others requiring technical expertise.


When the development group is external to the business, and clear objectives are established in what is to be delivered, the lines between decisions that the business makes and the development company makes can be made clear by contract and/or convention. Conversely, when the technical team resides within the business, those lines can be a bit more blurry.
Through working closely with those in the business areas, who are intimately familiar with the working of the business, some technologists (particularly those working on applications used by the business) gain a deep understanding of the processes and value streams of the business. They can, therefore, be well informed partners in maximizing value through applying technological solutions in ways that enable efficiency, productivity, and even opening new revenue streams.


Careful and proper application of technology can help achieve these. Improper application of technology can hinder flow, agility and efficiency. It may end up costing the business dearly. Therefore, it is imperative to successful application of technology that technology experts are included in decision making, especially regarding matters involving application of technological solutions.


It may be beneficial even to have a few key technological resources involved in other decision making processes since there would be opportunities that evolve as a result of having technologically adept minds in the mix. Put another way, a certain portion of a board, committee, or other decision making body should be representative of technology (perhaps even representing different sectors of technology depending on the decisions and the business).

Saturday, October 17, 2015

Kanban, Can it Work Anywhere?

Kanban is a system in which cards are used to visualize a workflow through a value stream. Sure it finds its roots in manufacturing, and yes it has wound it's way into software development. Let's ponder for a bit whether this system would work in other contexts.


First, here is what we know about Kanban:


  • Not a process itself.
  • Supports a pull based system.
  • Enables visualization of work through a value stream.
  • Visualization enables measurement, which enables Kaizen (reducing waste).
  • Waste is downtime in the value stream.


Being a person who is either impatient, or who values efficiency - one activity that I recognize could use Kanban is the deli counter at a supermarket. I'll take a stab at applying Kanban and suggest how it might improve the process.


If you visit a supermarket deli, typically you would take a number and wait around for the next worker to help you with your order. You'll be asked what you need and they'll keep it in their head and usually have to ask a few times per order item to clarify. Most deli counters will take you a sample and ask if the thickness is ok. Perhaps they will work on one thing at a time and ask again what's next after each one until your transaction is complete.


If we introduce Kanban into this system, the first thing we need are order cards and customer cards. The orders would come in from the customer on an order card. This would contain information about each order item - item type, brand, quantity, thickness, etc. The order card would be taken by the worker one at a time and the customer would receive a corresponding card with a number on it. When the order is ready, it is delivered to the customer at the counter, the customer exchanges their numbered card for their order items.


But wait, I'm sort of getting ahead of myself here. We should not change the process just yet, but only use kanban cards to represent exchanges of information and goods in the current process. Let's try again -

First - customer grabs number kanban and waits until number is called. Once number is called, customer gives number to worker.

Worker passes customer an order kanban for the first item and a kanban for a sample. Customer gives worker first order item kanban and an order item sample kanban. Worker makes a slice of the first order item and exchanges it for the sample kanban. Now the customer either approves of the order, or declines and either changes the order or leaves.

If the customer approves (we'll look only at the happy path for sake of brevity), then the worker completes the order item. Once the item is complete, it is exchanged for the order item kanban. If the customer wants anything else, repeat.

It's easy for us to see that there are multiple opportunities for waste in this process. This is evident because the number of transitions at best are 5n + 2 where n is the number of items. For three items there would be at least 17 transitions. The number of times between transitions that the customer is idle are 2n + 1. The worker is never idle, however they are wasting a lot in transitioning.

One improvement would be to have the customer place the whole order, then pick it up later after they've had a chance to shop for other items in the store. Or the customer can have the whole order on some card with standard thicknesses and indicate whether or not they want a sample. There can be special instructions if needed. This would reduce waste by the worker and reduce lead time (where the customer is waiting).

In an even better world, where Kaizen and Just in Time is valued even more, the customer would receive their order JIT as they are checking out!  I would suggest placing the deli between the registers and entrance. Customers would stop by the Deli, get samples and place their order. When checking out, the deli items would be paid for by the customer, then delivered JIT bagged and ready to go into their cart along with other items.

This example serves to show how Kanban and other principles of TPS can be used to improve existence - no more wasting time at the deli counter. But this can be used to improve development processes as well as other IT processes. Wonder if it could improve the lead time on government initiatives?