Presentation at the Scan-Agile conference

Bas Vodde

Nov 3, 2008 — 1 min read

Last week, I was at the Scan-Agile conference in Helsinki. I did a completely new presentation which I called "Journey through product development literature". It was a new style of presentation that only consisted of quotes from different books. I had a lot of fun making and doing the presentation.

I got some requests to list the books I talked about. Here they are:

Hackers & Painters - Paul Graham
How to Read a Book - Adler, Van Doren
Dynamic Manufacturing - Hayes, Wheelwright and Clark
Toyota Culture - Liker, Hoseus
Just in Time - Ohno
8th Habit - Covey
Clean Code - Martin
Hard Facts - Pfeffer, Sutton
Cross-Functional Teams - Parker
Flexible Product Development - Smith
Winning with Products - Cooper
Product Development Performance - Clark, Fujimoto
Revolutionizing Product Development - Clark, Wheelwright
Fast Cycle Time - Meyer
Designing Team-Based Organizations - Mohrman, Cohen
The Discipline of Teams - Kaztenbach, Smith
Wisdom of Teams - Katzenbach, Smith
Leading Teams - Hackman
X-Teams - Ancona, Bresman
Reflections on Quality - Crosby
Teams at the Top - Katzenbach
Leading Self-Directed Teams - Fisher

Not all of the books are recommended reading though :) Some of the really good (and modern) ones are "Leading Teams", "Fast Cycle Time", "Toyota Culture" and "Hard Facts"

Empowered Product Team vs. LeSS Feature Team

Recently, while discussing with a potential client, I learned of their interest in adopting a Product Operating Model. This prompted me to study the concept in greater depth. It wasn’t my first encounter with Marty Cagan’s work; I had read his book Inspired long time ago and have

Requirement Areas are NOT around product modules

Baseline vs. change is an important distinction in product development. Missing that contributes to a common misguided practice in creating RAs (Requirement Areas) around product modules. Product module is about baseline, while RA is about change. Instead of creating RAs around product modules, we create RAs around product changes. Let’

Getting started

I have often been explaining how a LeSS adoption gets started on various occasions, so I decided to write it down as an article, not to avoid doing it any more - I will still do it as the interaction alongside it is irreplaceable - but to make it a

LeSS adoption without frameworks

I have advocated to balance framework focus with experiment focus in the use of LeSS. As the framework focus is already strong, I’d like to elaborate more on the experiment focus. Is it possible to adopt LeSS without adopting its frameworks? I think yes, as that is actually continuous

Read more

Empowered Product Team vs. LeSS Feature Team

Requirement Areas are NOT around product modules

Getting started

LeSS adoption without frameworks