Comments on: Perpetual multivote for pull scheduling

By: Personal Kanban: Tangible Tasks Produce Prioritization | Personal Kanban

Personal Kanban: Tangible Tasks Produce Prioritization | Personal Kanban — Mon, 26 Oct 2009 21:02:08 +0000

[...] and Eric Willeke asynchronously put their heads together and came up with Perpetual Multivote. This process recognizes that good decision making has both temporal and social components. As [...]

By: Corey Ladas

Corey Ladas — Thu, 16 Jul 2009 15:38:40 +0000

There are value, cost, and investment factors for every feature. Different participants have insight into each of these. Voting and auction schemes might allow the participants to contribute their particular expertise at a lower cost than a more analytical or negotiated approach. For example, a design improvement might not look like a “feature” to the customer, but it reduces the cost of new features in the future. The sales guy won’t see that, but the architect will. So sometimes the architect should get his way, and we want a way to let him get his way occasionally for least fuss and least cost.

By: Chad Albrecht

Chad Albrecht — Mon, 13 Jul 2009 19:02:27 +0000

To speak to Eric’s point a bit, I think we should always evaluate features in terms of their dollar value. If we are to use ToC and Throughput Accounting to evaluate productivity then we must always think about our activities in terms of ‘The Goal’ which is to make money. I’ve documented this in a bit more detail here:

http://blog.chadalbrecht.com/p.....tures.aspx

On you concept of multi-voting, I would be interested in exploring the evaluation criteria that is used by each voter.

Thoughts?

By: Multi vote Kaizen board « Lean and Kanban

Multi vote Kaizen board « Lean and Kanban — Thu, 16 Apr 2009 20:54:39 +0000

[...] multivoting the team can vote on which item is the next highest priority to be pulled once a slot becomes [...]

By: Greg Starling's Agile Software Development Resource » Kanban Board for Lean Software Development

Sat, 25 Oct 2008 09:59:30 +0000

[...] backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on using perpetual multi-vote to schedule this [...]

By: Corey Ladas

Corey Ladas — Wed, 22 Oct 2008 18:59:55 +0000

Whoops! Looks like the spam filter might have whacked some legitimate comments. Profuse apologies if I lost your comment.

Corey

By: Corey Ladas

Corey Ladas — Wed, 08 Oct 2008 19:02:25 +0000

Hi Olav,

I agree that such a durable coalition in a multivoting scheme would be dysfunctional behavior. I would consider the case you present as a failure mode. Somebody would need to be responsible for seeing it as such and proposing a remedy. Do you think that adding a chance element would help?

I have to say, I like adding your time element to vote allocation, especially since we’ve already added a new time element to classic multivoting. Indefinitely repeated games often have different characteristics and equilibrium strategies than one-time games.

By: Olav Maassen

Olav Maassen — Tue, 07 Oct 2008 16:22:02 +0000

To me it sounds very much like (forgive me for using this word) democracy. The big problem I have with using democracy in systems is the majority dictatorship.

In your example this can happen for instance when the voting committee has a size of 7 and 5 members always vote the same and inspect the board daily if not hourly. The other 2 members have no way of influencing the priority.

Assuming everybody is equal, this situation would be unfair.

To prevent this from happening give everybody an amount of votes per time unit. Let’s say 1 vote per 2.5 workdays. The voting rules stay more or less the same with only one change:
votes are lost when the item gets picked up to work on.
This allows the silent minority to accumulate points on a story they feel is important while the majority still gets to pick most stories.

I could elaborate more on this, but the textbox is too small

By: Corey Ladas

Corey Ladas — Tue, 30 Sep 2008 18:03:07 +0000

If I felt like business value was under-represented, I would either change the composition of the voting committee in favor of consumer stakeholders, or change the allocation of votes in favor of consumer stakeholders.

Exposing value estimates may have educational merit beyond its decision-making merit. I would tend to think of that as a separate problem, and I might encourage (but not require) stakeholders to share the reasoning behind their votes.

By: Eric Landes

Eric Landes — Tue, 30 Sep 2008 17:54:21 +0000

So you are trusting the wisdom of your stakeholders on this. Maybe I need to be more trusting! I want to force that information on the feature, because I don’t feel that happens at a feature level currently for my group.

Being an internal shop, that might be different than someone developing commercial software. I am proposing that we force some type of Business Value estimate on each feature on submission. Thoughts?