1

I am trying to get some feedback on a methodology I would like to try with my team. Two problem areas I want to try and adapt this process to addess are:

  • A mix of time-critical (contracted deliverable) features mixed with other features
  • Measuring the relative value of effort by different team members and developing incentives

Currently we have been using a basic Scrum style process. I like the idea of Kanban but I think in a development environment the WIP and team organization should be a lot more flexible. So I have been thinking about what I'm tentatively calling Reverse Auction Kanban.

In the basic summary form the Product Owner would basically put forward items that they think are ready or needed to be developed as if they were a standalone project. Engineers and QA could then bid on the work. The lowest bidding engineer or engineering group would then get the work assigned to them and would then need to deliver the work. Part of the ongoing incentive is that MBO/bonuses could be given based on the total points of work delivered by an individual.

So some examples:

  • Say I need a new screen developed. Maybe a senior web developer thinks it is worth 100 points. But perhaps a but maybe a junior developer wants more experience with web development. So he can bid 80 points to get the work. Because we release monthly I do not really care if the senior developer could do the feature in two days compared to the junior guy's three.

  • Same situation but now say the customer needs this page in 1 week. Now the Senior developer raises his price to 200 points and the junior doesn't think he can get the work done in time. But the junior developer talks to the senior developer to place a joint price of 150 (The senior would take care of some of the tricky things and let the junior fill in the rest)

Features that have a high value to the business could be given a higher starting bid price. So in the above examples perhaps the Product Owner looks at past point values for page development and sets the starting price at 200 points. But in the second example the page would start at 500 points.

The Product Owner and other managers would be the arbitrators of the delivered product and accept the work at which point the points bid would be credited to the engineers. Over the course of a project or year the managers can keep track of the total points spent by the individuals and then award bonuses or other incentives to people who have done the most points of work.

What are people's thought on this model and what are some of the challenges or benefits you could see with such a model? Where does QA fit into a model like this? Would they be involved with every item as a team member or perhaps as the acceptance committee?

Thanks for sharing your thoughts,

Jason

  • 1
    You could be on to something here and I encourage you to keep trying. A significant issue that you need to resolve is that there are few if any features worked on end-to-end by one person. So, you may have to bid at each pull point. Also, you could create friction on the team if it becomes hyper competitive. You don't want the senior engineer saying to the junior engineer, "you won the bid, now it's your problem". – GuyR Oct 22 '11 at 12:49
1

Interesting concept, but I honestly I don't think this type of a model will work and could have serious consequences on your staffs motivation and productivity.

A distraction: During an iteration you want your team working on the highest priority items that have been added to the iteration by the product owner (at least I do).

A points based system will have people bidding on what they "want" to work on which in most cases is not the highest priority story / work item in the iteration backlog. Trying to figure out who "won" the bid, not to mention the bidding process itself is only going to distract your team from the iteration.

Individuals and Interactions: If you want to hand out incentives to staff, yes I'm down with basing it off of performance. However, don't base it off of how many story points or "completed bids" were accepted by the PO over the course of the year.

The team leader and team members will know who is performing and who is not.

  • Have regularly scheduled one on ones with your team members.
  • Have your team complete peer 360 reviews

Also, note there are many different types of performance. Take for example your senior developer and junior developer scenario. Have the two "pair" on the story / issue. When completed let the junior developer burn the story up as it's only going to boost their confidence and ability. You can't measure the value that senior developers who can impart knowledge like this and work with team members in such a fashion bring to a team

Working Software: The end goal of every iteration should be working software. Burn down / burn up / velocity etc..charts are your guide to knowing if your on track throughout a project or iteration.

Your customer doesn't care which developer won the most bids and completed the most story points. They care that the software is delivered on time, without defects, at the cost negotiated and works as expected.

Its a team game....

  • This answer relates to Scrum but the question was about Kanban. In Kanban, everything that gets on the board is expected to be worked. Kanban is a PULL system so people already work on what they "want" - nothing wrong with that if it does not disrupt the flow. Where in Kanban does it talk about it being a "team game"? Also, handing out individual incentives based on Peer reviews could discourage open and honest communication. – GuyR Oct 22 '11 at 15:26
  • Where in Kanban does it talk about it being a "team game"...your kidding right? – Jesse Oct 22 '11 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.