At ALM Chicago last month, I did a talk titled Breathing Data, Competing on Code. It was a lot of fun, and a big part was applying ideas from Tempo to software development. I did this once before at the SoCAL Lean/Kanban meetup, but this time, I took the ideas in a significantly different direction. It’s an hour-long talk, so you’ve been warned. The talk was pretty well-received, so looks like I am gradually improving at this talking-head game.
There are also quite a few bits that are somewhat interactive, so you may lose the thread during those parts.
About Tempo
Great stuff. You packed a lot in for a one hour talk. It was quite interesting to see many Ribbonfarm/Tempo themes applied to domains (programming/software management) I’m very familiar with.
One bit of feedback. The developer archetypes didn’t really resonate with me. Or at least the archetypes seemed as if they model slimmer slices of real people than most archetypes do. Most good developers I know are varying combinations of all or most of the archetypes you mentioned. But perhaps you intended it that way given that most of your audience seemed to be manager-types not developers. Also, as a decently seasoned developer, it’s pretty rare now that someone will build something that’s completely mysterious to me so the wizard archetype doesn’t make sense anymore.
Yes, this talk was primarily for IT middle managers. Simplified accordingly.
All the archetypes you mention are ones you SHOULDN’T overrule. Are there any archetypes you should? As you say, if forgiveness is given always or never, it’s meaningless in either case.
I didn’t say you should never over-rule. Only that you shouldn’t over-rule them in some areas, at some times. Plot/character is a good way to keep things fluid. Sometimes the plot state will let you over-rule where the character will not, and you get to pick. The key to forgiveness flexibility is deciding which frame to apply when. The frames provide the justification, not the decision itself.
But yeah, that may not have been clear in the talk itself.