Loading ...
Sorry, an error occurred while loading the content.

option kanban for priority scheduling

Expand Messages
  • Corey Ladas
    I just put up a new article, which I submit for the consideration of the experts: http://leansoftwareengineering.com/2008/09/21/options-have-value-options
    Message 1 of 43 , Sep 21, 2008
    • 0 Attachment
      I just put up a new article, which I submit for the consideration of the experts:


      Real options are an enhancement to, or perhaps an explanation of, the priority filter concept for backlog management.

      A kanban is used to make claims against the productive capacity of some resource. If I have a kanban, I can give it to you in exchange for an object or process of real value. The value of a kanban depends partly on time. The most relevant temporal data about a kanban are:
      • time of creation
      • time of redemption
      • time of delivery
      ...from which we calculate lead time and cycle time. A regular kanban represents a commitment--a real claim against real resources. When a kanban is exchanged, it is with an expectation of certainty that the work order will be satisfied.

      Planning decisions, by contrast, involve uncertainty about work that we might perform in the future. Work requests placed at the end of a deep backlog do not represent a commitment to deliver. Pending work requests are always temporally contextual. They can only represent current understanding and intent, and the world will change before they enter production. The longer the backlog is, the greater the uncertainty about relative priorities and lead times.

      Such uncertainty is not a problem as long as we are always able to determine a satisfactory answer for what to do next. You can't utilize more capacity than you have, and adjustments to capacity have a lead time of their own. Your plans and priorities are sufficient as long as you always know what to do next. An efficient planning process is just barely sufficient to provide that information.

      The priority filter is an attempt to define a planning process that directly represents the distribution of uncertainty of pending work requests. The work requests themselves are represented as kanban-like tokens. However, a kanban as we've described it really only works within the context of carefully controlled queues and processes. A kanban is a commitment, when what we really need is an option. Still, the kanban is a convenient representation for visual control, so what's stopping us from defining a new kind of option kanban for planning purposes? Nothing!

      Like a real kanban, we want to encode information about the scope and value of the request, but the temporal information we need will be different. I will argue that there is only one thing about time that we need to know about our option token: the expiration date.

      Placing a token in one of our priority buffers amounts to buying an option to schedule the work for production. The price of the option is set by the capacity of the buffer. The expiration date is calculated from the purchase date and a duration that is also bound to the buffer. So, the priority 3 buffer might have a capacity of 8 and a duration of 30 days. When a new token is placed in the buffer, we calculate the expiration date and the token begins to age. Our priority 3 option gives us the right to bid for any higher-priority options that become available. Availability of a priority 2 option triggers a comparison of priority 3 tokens to select one for promotion. All of the p3 tokens are ageing, and any that are not exercised before their expiration date are cancelled. A cancelled option might return to the deep backlog, or it might disappear entirely. Age then becomes a first-class consideration for competition, where a nearly-expired token may be promoted over a higher-value token that is brand new.

      In this way, we work our way up the priority ladder, incrementally investing as our certainty improves, until we finally earn the right to buy a real kanban that we can exchange for the real goods or services offered by our production system. It's only when we can afford to buy a real kanban that desire becomes demand and the lead time clock begins. If we end up getting cancelled, it will likely be while it is still cheap to do so. We're only out the cost of our options, which should have been much cheaper than the cost of a real kanban, which we only want to buy if we're certain that it's for something that we want.

    • Landes Eric (CI/AFR2-NA)
      In my scenario, the decision to implement a feature would happen by having the developer pull from the top of the list. We
      Message 43 of 43 , Sep 26, 2008
      • 0 Attachment

        In my scenario, the decision to implement a feature would happen by having the developer pull from the top of the list.  We allow the vote plus some weight or rules using our cost equation to place all current feature requests on the list in order of importance. 
        Is that the decision you are talking about?
        Eric L. 

        From: real_options_discussion@yahoogroups.com [mailto:real_options_discussion@yahoogroups.com] On Behalf Of chris.matts@...
        Sent: Thursday, September 25, 2008 5:33 PM
        To: real_options_discussion@yahoogroups.com
        Subject: Re: [real_options_discussion] Re: option kanban for priority scheduling

        So here is the question.... ..

        How do we make decisions... ....

        (Not commitments)

        ------------ ------

        From: "Landes Eric (CI/AFR2-NA) " <eric.landes@ us.bosch. com>
        Date: Thu, 25 Sep 2008 14:38:33 -0400
        To: <real_options_ discussion@ yahoogroups. com>
        Subject: RE: [real_options_ discussion] Re: option kanban for priority scheduling

        To be honest the 5 per customer came about in talking about another similar implementation (the open source stuff I mentioned earlier).  The customers get 5 votes to spend.  Currently new items go into the kanban on a weekly basis, after our status meeting.  And that was my assumption on how we'd select any new features. 
        Are you assuming that once one feature is done (out of the kanban), let's pick the next item at the top of the list?  That might change my mind on the 5 votes (tokens).  In some ways, I would like to see what happens between the groups as teams realize how the system works :-)  But would 1 vote eliminate that?  I think if we can add some weig h! t for business value, that we can get around your piling on scenario.
        Eric L.

        From: real_options_ discussion@ yahoogroups. com [mailto:real_ options_discussi on@yahoogroups. com] On Behalf Of Eric Willeke
        Sent: Thursday, September 25, 2008 1:58 PM
        To: real_options_ discussion@ yahoogroups. com
        Subject: Re: [real_options_ discu s! sion] Re: option kanban for priority scheduling

        why five per customer? Do you think there are customers that can't agree with themselves on what's the next most important? If your goal is to get the one next most important thing, it seems like one vote is ideal.

        Also, run a couple simulations in your mind... is your result going to be that each group piles on their single next item, so that a group with more voting power could always win until other groups work together to prevent that?

        On Thu, Sep 25, 2008 at 1:48 PM, Landes Eric (CI/AFR2-NA) <eric.landes@ us.bosch. com> wrote:

        We are in a little different scenario.  Our group is internal dev group for a large global manufacturing company.  While we don't have licenses per se, we do internal chargebacks.  So votes would only go to existing customers, not potential ones.  We aren't really trying to sell our services, although I believe we should be!
        So I'm initially thinking each customer gets 5 vote tokens.  We don't have thousands of people who would qualify at what I'm calling the customer level.  Probabl y! hundreds.  And I'm not sure what percentage would actually vote on features, that would impact the scheme.  So giving customers multiple vote tokens would enable them to pile on features, or even split them amongst their top 2 or 3. 
        Once a vote token is in the Kanban, the customer does not get it back until the feature is done (my definition of that is released to the wild).  However, they can change their mind but I think we'd have to put rules in place for changing tokens.  I hadn't thought about the negative votes and rules, we would need to experiment with that. 

        Sent: Thursday, September 25, 2008 1:13 PM

        To: real_options_ discussion@ yahoogroups. com
        Subject: Re: [real_options_ discussion] Re: option kanban for priority scheduling

        How votes get allocated, and reset is an interesting problem. Last year we discussed but did not implement a few voting schemes..... .

        1. one per customer.
        2. One per license.
        3. Per revenue.

        When do you reset the tokens?

        Do prospective client get different treatment to existing ones. ( Business value conflict between company and customers )

        And so it went.....

        ------------ ------

        From: "Landes Eric (CI/AFR2-NA) " <eric.landes@ us.bosch. com>
        Date: Thu, 25 Sep 2008 12:41:21 -0400
        To: <real_options_ discussion@ yahoogroups. com>
        Subject: RE: [real_options_ discussion] Re: option kanban for priority scheduling

        Ok, I'm a little slow Eric, I didn't get the idea behind the token originally.  So customer A casts 3 votes (we give them 5 let's say) for feature Y.  A slot in the kanban opens up and we put feature Z in the kanban.  Now  customer A goes back to the list and sees a new feature AA that has more value for them.  They then remove 2 votes ! from feature Y and place those 2 on feature AA.
        I'm really liking this idea for our group.  We are just implementing a gl o! bal solution for my company, the first time we have done this.  Our biggest fear is underrepresentation from Europe and Asia.  I think this would help eliminate some of this. 
        Eric L.

         </ IV D!>

        Sent:/ B!> Thursday, September 25, 2008 11:41 AM

        To: real_options_ discussion@ yahoogroups. com
        Subject: Re: [real_options_ discussion] Re: option kanban for priority scheduling

        When the top item gets pulled, the vote tokens return to the pool, where they can be recast at any time.

        Continuous multivoting.  I like this idea a lot.  I've seen a lot of multivotes, but they were always one-time shots.

        On Thu, Sep 25, 2008 at 8:20 AM, Eric Willeke <eric.willeke@ gmail.com> wrote:

        Why not have a token for a vote - it'd probably ne e! d to be electronic given the dispersal of most teams, but each person can see the proposal list, put their ! vote on one, and it's there until they move it, or get the notification that their voted item is finished.

        On Thu, Sep 25, 2008 at 11:15 AM, Corey Ladas <coreyl@...> wrote:

        Yes, multivoting is the right sort of idea, as long as we can keep the vote current at all times...without holding any meetings.

        On Thu, Sep 25, 2008 at 8:01 AM, Landes Eric (CI/AFR2-NA) <eric.landes@ us.bosch. com> wrote:

        Would this be something close to what you are thinking of for the market and collaborative approach?  This is a simplified idea, stolen from some open source project that does som e! thing similar :-)
        ! Give all stakeholders a number of votes.  They can vote on any feature when we are ready to put new features in the kanban.  Each vote = 1 point, and the stakeholders (there needs to be a larger community of stakeholders now, not just the 5 or so that attend weekly status meetings, but all affected customers) can spread their votes or put all their votes in one basket.  We're thinking of a wisdom of the crowds effect here. 
        I also think we need to do something for business value with this idea, but I'm not sure what.  Maybe the costs associated with not doing it add votes to the total?  This part is a little weak.  !
        I would love to get more of our internal customers involved in this part of the decision process.  Involving more customers along with using data to support a feature as a good business decision, could tremendously alter our development enviornment.

        From: real_options_ discussion@ yahoogroups. com [mailto:real_options_ discussion@ yahoogroups. com] On Behalf Of chris.matts@ gmail.com
        Sent: Wednesday, September 24, 2008 12:16 PM

        To: real_options_ discussion@ yahoogroups. com
        Subject: Re: [real_options_ discussion] Re: option kanban for priority scheduling

        Trust me, we are about to ditch pretty much all that stuff. We will be left with "how long to implement given x or y or z developers." ........ But that is jumping to the punch line. Let's work through it.

        ------------ ------

        From: "Corey Ladas" <coreyl@...>
        Date: Wed, 24 Sep 2008 08:52:08 -0700
        To: <real_options_ discussion@ yahoogroups. com>
        Subject: Re: [real_options_ discussion ]! Re: option kanban for priority scheduling

        Okay, interesting that you mention Todd Little, because the priority buffers are meant to be a representation of a Cone of Uncertainty.

        I could comment on the list further, but before I do, I think that it's impractical to try to keep a! ll of that information current.  I'm looking for a loosely collaborative, intuitive, emergent, market-like method that produces useful results, instead of an analytic method that produces "precise" ! results.  Why does a story get voted up or down on Digg?  Who knows, it just does.

        On Wed, Sep 24, 2008 at 1:22 AM, <chris.matts@ gmail.com> wrote:

        Doing this from blackberry so apologise for formatting and briefness. This deserves a longer answer.


        Love the list. It is a great start. One thing most obviously missing is..... How do we determine the business value? The business value is massively unstable compared to the other ! items. How d! o we det e! rmine it?


        Before I start, I assume the goal is to deliver value to the business rather than satisfy an IT or process metric.

        Factors to consider:

        age of the request - who cares? Unless it is fixing a bug against an SLA. Rather, when the bug is raised, the penalty dates for an item should be specified.

        the time needed to complete the item - spot on. Otherwise we do not know the last exercise date to hit a target date. Also the value is very time sensitive. Remember this "time" follows a log normal distribution ( Todd Little paper should be mandatory reading )

        availability of resources needed to complete the item - s a! me as item above. We only care about the total time. Not five minute job plus a month to hire someone. In effect, if we need to hi r! e a resource, the card is a blocked option. If one person can complete in 1 month, and two take three weeks, the business decision maker should know abou t! this.

        dependencies on other items in the list - then it is not an MMF. Business decide on value which require an MMF but the Kanban system often delivers features.

        the value of the item if you deliver it as soon as possible - this is really the same as the next item which is the general case.

        the time sensitivity of that value - spot on. This is the general case, even incorporates Da v! id's "Cost of Delay". I hope this is something that will get further development. The time "patterns".

        the cost to complete the item if you start it now - Next item is general case

        the time sensitivity of that cost - I agree - but I woul d! like to understand more of what you mean here.

        ....notice that most of these depend on current context, and no single

        individual likely has the answers to all of the questions.

        ------------ ------

      Your message has been successfully submitted and would be delivered to recipients shortly.