Post written by Brett Gibson, CEO at SilverFern Software

We like to educate. In fact, we even have a board game we use frequently to help clients visualize workflow and facilitate collaborative systems thinking.

We recently introduced this game (created by a fellow New Zealander, Heaven forbid) to a selected group of cross-functional internal change agents.

They seemed extremely engaged and excited by the benefits of Kanban and receptive to the collaborative approach required by each other’s input.

It was a great session on software delivery, where the players identified bottlenecks in process from a full systems picture. Amongst other things, we discovered that optimizing one functional area did not ensure better throughput of software.

Important lessons and great stuff if you’re in to that sort of thing. We are, and so too was this group.

Here’s something interesting, however: In order to represent the productivity of a developer in this game, dice are rolled…

This is always an interesting conversation topic and uncovers a host of questions like the ones below. Take a look and let us know what you think: 

1. Is it realistic to portray developer productivity this way, on the randomness of a 1-6 scale?

2. Is the daily life of a developer really that unpredictable?

3. If it is, then what does that mean for project planning and estimations?

4. When you ask a developer how long something might take, how do you account for interruptions, daily “emergencies”, or the business demands for their knowledge? What’s your “padding” for those factors against that guesswork – surely padding itself is guesswork game too? Now your project planning is nothing more than a game of predicting padding on top of other guesswork.

5. Can you really keep a developer in a productivity bubble away from the demands of the daily operation of a company? Does that solve any problem, create more or just move the problem to others?