The Myths of Innovation

I am reading The Myths of Innovation. I felt somewhat obligated because the name of our team is "Premium Innovation". I would hardly compare us to Xerox PARC, but we generally roll as Scott Berkun describes (although we have a long way to go).

If I feel frisky when I am done, I will do a proper review, but I like this quote from a section called "Ideas and Filters".

. . . Instead of binary switches – open vs. closed, creative vs. routine-- we want a sliding scale of openness that we can control. If you want new ideas, you have to slide toward openness, turning some filters off, exploring thoughts you'd ordinarily reject off-hand. Do this until some interesting ideas are found; then, gradually turn more filters on until you're left with a handful that are both good and practical for the problem at hand. Choosing which filters to apply when has much to do with successful innovation; it's not just having an open mind, it's also knowing when to postpone certain judgments, and then when to bring them back in. If a mind is always open, it never finishes anything; if a mind is never open, it never starts.

It reminds me a lot of Lean thinking. Specifically, set based design.

Lean book

I'm wrapping up Implementing Lean Software Development.

I highly recommend it.

The Poppendiecks rock.

It is pretty hard to argue with much of anything they say.

Here is a good video of Mary presenting to Google if you don't have time to read it - it will give you a taste of Lean SW Dev.

Push vs. Pull Systems

Interesting post by Dan Creswell who links to John Hagel.

Update Also see this earlier post by Dan.

I liked this table in the paper.

Talks about Lean based pull systems in manufacturing applied to systems. H.o.t.

Push Programs	Pull Platforms
Demand can be anticipated	Demand is highly uncertain
Top down design	Emergent design
Centralized control	Decentralized initiative
Procedural	Modular
Tightly coupled	Loosely coupled
Resource centric	People centric
Participation restricted Few participants	Participation open Many diverse participants
Efficiency focus	Innovation focus
Limited number of major re-engineering efforts	Rapid incremental innovation
Zero sum rewards Extrinsic rewards dominate	Positive sum rewards Intrinsic rewards dominate

Rubber Match

This week is the rubber match between the Space Men and the Flex Men at work.

We've covered a lot of ground in this phase of the project. A lot of it was fighting learning curves and getting infrastructure stood up. We spent a lot of time using Lean set based decision making on what technology we wanted to use. This was good in that we are more confident in our decision, but bad in that it cost time. The good news is we wouldn't have picked the technology we ended up with if we had used a traditional "place your bets early" approach. So it worked. Yay.

It is inevitable yet annoying that the first rev. of any piece of software has to pay the first rev. tax of standing up infrastructure, figuring out methodology, forming/storming/norming/hopefully-performing, and learning rapidly in general.

The team makes its choices (as Sarge would say) and lives with the repercussions. We made a lot of good choices luckily, but we certainly made some bad ones. The bitch of it is you never really know which choices were good and which choices were bad unless they were very right or very wrong. You are always left wondering what if we did this - what if we did that?

And so it goes - here comes the rubber match between the Space Men and the Flex Men. I am using this phrase incorrectly, but I felt like using it anyhoo, so so what!?. It really is the integration week. When we take a lot of reasonably well tested Jini/JavaSpaces code (unit, integration, and FIT) and try to integrate it with Flex code.

For better or worse, we split our small team into two - one focusing on the backend JavaSpaces side and one focusing on the Flex UI side. This was mostly due to fighting learning curves, but was also due to working styles and geography. We wanted to try a lot of things and splitting the team at the time seemed to be a way to cover the most ground with technology and methodology. We'll never know if this was a good decision. But we made our choices.

A team where everyone is skilled in all areas of the system is obviously best. But you can't just wave a wand and make this happen. You have to get there iteration by iteration choice by choice.

Wish us luck this week - the rubber match is going to hurt! :)