I wrote this article a number of years ago, but I’ve been thinking about it again recently, so I thought I’d republish this with a few additions.
I have been pondering the Kanban commit point for some time and it occurs to me that there is a striking similarity between this and the formation of contracts in the eyes of the legal system. I’m taking this from my perspective here in Australia, however I believe that basics of contract law are very similar in many western legal systems. In all cases, if you are seeking to rely on opinions of the law applicable to you, please consult with your local legal professional. I found this as a useful way of understanding the commit point – I hope you do as well.
One of the key reasons for understanding this is the importance of the commit point to the operation of a Kanban system. This is the point from which we measure the Lead time and start to make improvements. It’s the point at which the understanding between customer and service provider have or should be of a common mind in terms of what service they’re getting and when they’ll get their output. In contract law this is referred to as a “meeting of the minds”. This sounds simple enough, but from anyone who has been practicing service delivery in practice will know, real life situations are not necessarily simple.
There are some basic concepts in contract law that may assist Kanban service providers to better understand their customers and ultimately provide an improved service.
Offer & Acceptance
Two of the key aspects of contract law are offer and acceptance. The third is consideration but for the purpose of understanding when Kanban commit point, this is not necessarily important. For the purpose of this conversation, where consideration is mentioned take it to mean simply – consideration from the customer the price paid and for the service provider the consideration is the service. Just as in contract law, I would argue that the Kanban commit point requires both offer and acceptance to be in place in order for the commitment to be made. There is often a lot of confusion because people don’t active listen for acceptance and assume that because something is on a backlog it’s committed (see also Use Options Instead of Backlogs).
This is where one party – it may be the customer or the service provider in a Kanban context, communicates to the other the basic terms. For example:
Customer offer – I’ll give you $100 if you can deliver me a widget by the first Monday of next month.
Service Provider offer – Advertises that they can deliver anyone a widget of specification AxB for $150 within 10 business days of you placing an order on their website.
Note at this stage, there is no actual acceptance of either scenario. In the Kanban world this then remains an Option of the person receiving the offer.
Additionally, the offer needs to be communicated to the other party – in terms of the Service Provider offer this could be direct to a particular customer, to a class of customers or even the world at large.
This is where the party receiving the offer clearly communicates that they agree to it (verbally, written or through conduct). To continue the examples above:
Service Provider acceptance – Yes, we’ll get this for you by that date.
Customer Acceptance – Logs onto the Service Provider’s website, fills in an order form and clicks submit.
The form of the communication can vary from something as a simple nod of the head to a formal written contract with all the detailed terms and conditions. This is a key thing to examine in your Kanban system – are your customers getting a clear signal of the acceptance? Are they even aware that you have committed and do they properly understand what this means? Are they mistaking commitment for a “receipt of the offer”?
In many circumstances, a party may come back with a counter offer, which similarly must be accepted before the contract is formed / Kanban commit point is reached. To continue the original examples:
Service Provider Counter Offer – If you give me $150, I’ll deliver it 3 business days before that.
Customer Counter Offer – I want a widget with specification AxC, I’ll give you $200 if you can deliver it in the 10 days.
Of course, at that point you may get count-counter offers and it may go back and forth until an agreement is finally made. For example, in Scenario 2 above, the Service Provider might respond by saying, “I’ll need to retool to provide that specification, therefore I can’t get it to you in 10 days, but 15”. In Scenario 1 above, there may be indications that a different class of service is involved – this may become a fixed date class of service. This is where misunderstanding can occur – it’s worthwhile summarising what the work item / outcome being agreed to is before committing it to your Kanban system.
Keeping it small
A problem that commonly occurs in practice, which Kanban systems try to control, is batch size. However, often contracts are written on the basis that it’s simpler to go through the negotiation process only once and then wait for the end outcome. That is, the contract formation process is often based on large batch. However, you might want to consider the shape of the offer when creating contracts. This will allow your Kanban system to keep its options open for longer and preserve flow. Of course, you may lose some of the certainty that large contracts bring to a business – but with some additional negotiation as a Service Provider you should find a way around that. Indeed, the regular reliable delivery that often results from Kanban implementation, will often negate the need for larger batches.
These are further offer / counter offer examples that demonstrate keeping batch size small:
Customer Offer – I need 1000 widgets at $100 each, but I’d like them in 5 months.
Service Provider – We can provide a maximum of 300 widgets per month. We’ll accept orders for 300 or less widgets per month at $100. Please notify our sales staff 1 week prior to the beginning of the month as to how many you need and we’ll deliver these by the end of the month.
In this scenario, the Customer tells the Service Provider that they’re happy with that arrangement because they get some of their widgets early. They then place orders on the first, second and third month of 300 and for 100 on the fourth month.
Customer enquiry – I need 10 widgets of specification AxB, 10 of AxC and 20 of AxD, what can you provide?
Service Provider offer – we can produce a maximum of 12 widgets every 10 days. The price for AxC specification items is $200 and the price of AxD is $250. Our online order form will prevent more orders coming in for that 10 day period once we have reached our maximum and will accept an order for the next period up to 10 business days prior to the period commencing.
Customer response – No one else can make type AxC & AxD, plus your AxB widgets are of higher quality than your competitor, so we’ll go ahead with that. Expect to see our first order shortly. They put in an order for 10 AxB and 2 AxC in the first period, 8 AxC and 4 AxD in the second period, 12 AxD in the third period and 4 AxD in the fourth.
In both the above cases, there are multiple contracts at play. Each order is a separate contract, under the terms negotiated earlier. The first part of the negotiation is around the terms of contracts, as each order is placed a separate commitment is made. Until the order is placed and accepted, these are options for both the customer and service provider.
In the Scenario 1, there are flow control mechanisms being put in place. A maximum limit is described as well as the timing.
In the Scenario 2, the order form is shut down preventing the acceptance from being communicated – this is baked into the system of work ensuring the service provider doesn’t committing to items outside of it’s capacity.
Possible drawbacks of this approach are if it is no longer fit for purpose for the customer to break things down into smaller pieces of work, then you should be prepared for your kanban system to have a larger batches and the associated variability that comes with this. Often, the variability will result in higher costs to cover the inherent risk associated with it. You may wish to describe / quote these as different terms to your customer to highlight / make visible the risk of large batch. However, there may be reasons such as competitive forces at work in your context that prevent this, so of course you should also pay attention to these. Although, this does raise the question of whether this is the right type of option to pursue for your business.
This is a different type of negotiation than normal service delivery. This is about exploring options and assessing risk. The nature of this kind of work and outcome is different, as are the parties and as such you should consider a different kind of agreement here – generally speaking, you’re “buying information” to assist with decision making.
If you’re part of the same company, often it’s for providing leaders the information they need to make the key decisions around the strategy for their company, as is often the case with product development. In the context of providing services to external clients and in the case of specialised or “one off” products, often understanding what the parties want is an essential first step. An “Idea” is often not enough to make a reliable commitment to deliver by – at least the variance for such things are often so large as to provide no solid guidance as to whether a commitment can be fulfilled.
Possible solutions to this problem are to agree to a different kind of work – it might be based on time and materials or constrained through timeboxes, number of experiments or other means. In the same way as the downstream kanban systems described above, it should be clear prior to pulling the Upstream Idea for exploration that the requestor and service provider both understand that this is the necessary first step in understanding what is to be delivered. The terms of this can also stipulate either the framework for delivery later on but should keep it options open for both parties – after all the idea may prove to be invalid for any number of reasons. Alternatively, it may leave this open for later agreement once the details of the Idea are known.
Service Delivery teams should not pull Options through the upstream discovery process without this in mind – that is, Ideas are options and should not be committed to automatically. It may also be the case that downstream systems will receive work items to explore this upstream process – you may need to ensure you have capacity to give the upstream process to ensure overall flow.
Kanban has cadences set up for dealing with this kind of thing. Typically, the “Replenishment” meeting is where work items will be committed to. Thus, prior to having these meetings, it’s often useful to understand the details above so that this meeting is run relatively quickly with a pre-understood way of working together (essentially, the “terms”). The key parts will become “system policies” – such as “ready to commit”. For upstream, the commitment would be “to explore option A”, whereas for downstream its to deliver the final service. During these sessions, usually we move the ticket to represent the work over the commit point – a signal to all involved that the contract / agreement has been formed.
There are some similarities between Kanban commit points and contract law – I hope you find it useful. Indeed, gaining a clearer understanding of the request will assist in providing services that are fit for their customer’s purpose. This “meeting of the minds” is important and may be something you’re overlooking in your Kanban system. Accepting items of work onto your system of work without understanding the nature of the agreement may well expose your business & kanban system to potentially avoidable risk. Make commitment policies explicit and well understood and build them into your process for a better outcome for all involved.